Тогда логика подсказывает только одно - выкинуть эту проверку)Сообщение от Vslav
- - - Добавлено - - -
Все понятно, что меня смутило)
У тебя под F1 значится не F1 процессора, а F1 УКНЦ, которая в 2 раз выше.
Итак, по твоему графику подтверждается, что цикл чтения с опережающим RPLY действительно занимает 6 тактов, как на моем графике.
Остается вопрос к эксперту @Alex_K, что он об этом скажет.
Достаточно навороченно и громоздко сделан механизм разруливания ситуации, когда запрос на операцию ввода-вывода (IO_START) пришел раньше, чем закончился SYNC.
А алгоритм простейший:
1. Если IO_START пришел после окончания SYNC, то начать операцию ввода-вывода (IOP_STB).
2. Если IO_START пришел до окончания SYNC, то начать операцию ввода-вывода сразу после окончания SYNC, а пока он не кончился, снять IO_RDY (готовность ввода-вывода).
А навернули - 6 фаз тактирования IO_ST0..ST5, 6 триггеров. Думаю, что можно было это сделать компактнее)
Абсолютно ничего не известно.
Вроде, в этих вопросах, я не эксперт. Могу только сказать, что циклам обмена RPLY должно подаваться только после DIN и DOUT. Но предварительная выдача RPLY имеет смысл только для чтения, т.е. если в фазе выдачи адреса не был активен WTBT. Но тут есть тонкий момент - если устройство по фронту SYNC начнёт выдавать данные и RPLY, то на шине AD на некоторое время образуется каша из адреса и данных. Главное, чтобы устройство правильно защёлкнуло адрес (всякие переходные процессы). Процессор уже правильно защёлкнет данные, т.к. он снимет адрес и переключит линии AD в режим входов.
Я думаю, что проблемы в этом вообще нет, т.к. при опережающем RPLY устройство должно выдавать данные по DIN только на следующем такте, поэтому никакого конфликта не будет.
В общем, запишем эту особенность быстрого чтения в список найденных недокументированных возможностей ВМ2. Впрочем, применить это знание на УКНЦ мы все равно не сможем.
Ну главное, чтобы успело выдать, и с учётом всяких задержек, процессор не прочёл нули.
Мы может и не сможем. А ведь есть разработчики всяких контроллеров для УКНЦ, вот они могут и попробовать.
1801VM2-Optimized - rev 34
Текущий прогресс в оптимизации ВМ2.
Дело продвигается медленно, потому что очень сложный процессор по сравнению со всеми 1515ХМ вместе взятыми)
1801VM2-Optimized - rev 34.pdf
Пока не получается оживить проект УКНЦ.
Написал тестовые программы проверки цветных полос.
В первой обнуляю и записываю во все планы цветные полосы регистровым методом из ПП.
В эмуляторе UKNCBTL и железе вижу одинаковые картинки.
Во второй разделил программу на две части. В первой части из ПП прописываю только план 0,
а затем загружаю в ЦП вторую часть программы записи в планы 1 и 2, и снимаю ACLO с ЦП.
В эмуляторе картинка не изменилась, а в железе стала такой.
Т.е. из ЦП планы 1 и 2 (SDRAM) не прописываются, хотя из ПП планы и обнуляются и прописываются.
При моделировании все работает правильно в обоих вариантах.
При попытке задать какие-либо констрейны, кроме частот, становится только хуже.
Думаю дело в асинхронном дизайне. Будет настроение - займусь переводом БМК в синхронный дизайн.
А пока хочу сделать временное моделирование после разводки. Может оно что-то покажет.
Сейчас использую бесплатные версии квартуса и моуделсима.
Они почему-то не позволяют промоделировать после разводки.
Лучше сделать так, как в системном ПЗУ. Сначала остановить ЦП, установив DCLO и ACLO. Затем перекачать в системное ОЗУ свою программу. Ну и запустить ЦП, сняв DCLO, небольшая пауза, снимаем ACLO. В системном ПЗУ это с адреса 0160332.
Я бы не рекомендовал уходить от оригинального дизайна, пока проект не заработает.
Лучше выяснить где именно косяки, чем сразу стараться перевести в синхронную модель.
А вообще все круто - вот-вот заработает УКНЦ на ФПГА!
hobot(05.10.2020)
Собственно, я так и делаю.
hobot(05.10.2020)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
