Да, тут надо прикинуть, во сколько раз быстродействие сериализатора и основной плисины должны быть больше, чем у проциков.
Да, тут надо прикинуть, во сколько раз быстродействие сериализатора и основной плисины должны быть больше, чем у проциков.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Сообщение от andreil
Ребята, почему вы с таким благоговением относитесь к асинхронным системам? Современный компьютер постоянно работает в режимах когда происходит множество асинхронных процессов, связанных с тем, что передача сигнала не мгновенна. Так же и сериализатор-десериализатор https://ru.wikipedia.org/wiki/SerDes так же используется повсеместно. LAN, SATA, USB, PCIe... Вопрос не в быстродействии, а в предсказуемости поведения, либо наличии обратной связи)
- - - Добавлено - - -
Потому, что это необычно, не у кого такого нет, но вот появится у тебя, у меня, может ещё у кого-то. А там уж каждый придумает, что можно будет с этим сделать, я уже несколько раз повторял, какие могут быть возможности))
- - - Добавлено - - -
Я могу по SSH одновременно управлять через сеть так несколькими Lunix машинами, по RDP Windows ПК, а как ты сможешь сделать это с ретро-компьютерами и консолями (разве что не захватить данные с видеовыхода)?
Последний раз редактировалось PavelZX; 13.10.2020 в 20:33.
А речь о современных компьютерах?
С кэшами, конвейерами и прочими... библиотекаршами?
Вот всем хорошо знакомый M1-цикл Z80
В момент времени "1" процессор выставляет сигналы чтения ПЗУ, в момент "2" (1,5 такта) считанные данные из неё УЖЕ должны быть на шине.
Допустим это стандартный спек на частоте 3,5МГц. 1,5 такта - это 1/3500000=285 наносекунд.
Допустим фактор сериализатора 8, значит нужно 9 тактов (8+1-задержка на захват), в обратную сторону столько же, итого 18 тактов. То есть только для передачи шины туда-сюда её такт должен быть минимум 285/18=15,8 наносекунд, то есть частота сериализатора 1/15,8=63,3МГц. Не проблема, умножаем на 2, получаем 126,6МГц, для ПЛИС вполне нормально, правда тут тоже синхронизация захвата входов понадобится, а это увеличивает латентность. Примем для определённости ещё по 2 такта в каждую сторону (пресловутая метастабильность) или 4*15,8=63,2 nS. В результате получаем 285/2=142,5-63,2=79,3 nS наносекунды на работу контроллера и собственно памяти. Далее следует учесть задержки в ПЛИС, так как спидгрейд, это не что иное, а максимальная pin-to-pin задержка.
На корпусе небось восьмёрочка? То есть 8 nS в каждую сторону (в реальности будет меньше, но рассчитывать на это не следует). Таким образом остаётся 79,3-16=63,3 минус пара-тройка тактов на контроллер памяти (клок 126,6МГц есличё), то есть в лучшем случае 63,3-7,8*2(3)=47,5(39,6) nS собственно для самой памяти на одно обращение к ней из одного ретрокомпа. Без учёта задержек на преобразователях уровней.
В принципе с одним процессором Z80 на клоке 3,5МГц (стандартный спек) теоретически должно прокатить.
Кстати, а какое время доступа у имеющейся памяти?
SRAM разумеется, об SDRAM можно сразу забыть.
- - - Добавлено - - -
Влад делал 4 спека в одной DivGMX.
Последний раз редактировалось omercury; 13.10.2020 в 22:10. Причина: про преобразователи уровней вспомнил
Да, знаю, как важно обеспечить "безвайтовый" режим, для точного воссоздания различных видео и звуковых эффектов в спекки. Поэтому и ставился вопрос об расположении части ОЗУ рядом с процессором, в данном случае и на адресную шину нужна будет двунаправленная передача, чтоб залить туда что-то минуя CPU...
Какой именно части ОЗУ? Ты же знаешь, сколько экранов у спектрума? Это что, две страницы будут в быстрой памяти, остальные через последовательную шину где-то там вдали в медленной? А как они переключаться между собой будут, порт 7ffd тоже на процессорную плату утащить? И более глобально, как будут коммутироваться на шину Адреса процессора адресА "быстрой" ОЗУ? А если делать на Z80 не спектрум, а что-то другое, с вообще другим расположением видеостраницы?
Последний раз редактировалось Eltaron; 13.10.2020 в 22:33.
Стоящая рядом с CPU память может выполнять роль кэша. А конвейер, кстати, можно обеспечить небольшой, с предвыборкой и даже прогнозом ветвления)
- - - Добавлено - - -
Спектрум один из немногих компов, у которого всё на CPU крутится. Его более поздние реинкарнации пошли по странному пути, сохранив эту родовую травму. Возможно будут сложности с реализации чего-то большего 128 КБайт. Не помню как там все эти дополнительные экраны в ATM turbo и прочих сделаны)
- - - Добавлено - - -
По крайней мере будет интересно со всем этим разобраться и решить все эти вопросы как-то...
Ну так а фигли калькулятором не воспользовался, прежде чем ерунду писать?
Во-во!
И по STM32F407 рядом с каждым ретропроцом для управления кэшем и предсказания переходов.
Заодно и к ним сериаЛизаторы.
Неразрешимые вопросы решать, конечно, интересно, но быстро надоедает. На деле все эти вызванные кошмарным проектированием вопросы решаются в итоге обычно просто - выбрасыванием текущих бесполезных наработок и повторным проектированием, на этот раз вдумчивым.
Наличие софта - странный путь?
Без него ЛЮБОЙ копм - просто горстка никому не нужного песка, редкозёмов и лужица припоя.
надругих десктопах находили пути для сохранения работоспособности части софта, но давали и новые возможности для создания нового. Не говорю, что такого не было на ZX Spectrum. Скорее всего ПЛИС надо было использовать очень давно, как в Sprinter-е или как-то еще. Да, тогда это было не так доступно, как теперь.
- - - Добавлено - - -
цену на них узнай - радости поубавится, а если от цены не колбасит, смотри на Stratix X, а можно еще и интеловский нейропроцессор для полного фарша прифигачить и проектировать интеллектуальный ОС!
Последний раз редактировалось andrews; 14.10.2020 в 12:18.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
