Чтобы было понятно самому себе ).
1. В PentEvo(Ts-Conf) доступ Z80 к DRAM осуществляется через ARBITER который принимает решение, кому предоставить доступ к памяти. Другие устройcтва, если выставили запрос на обращение к DRAM - ждут.
2. Рассмотрим операцию чтения. Z80 выставляет запрос на чтение (допустим, что к памяти больше никто не обращается кроме Z80). Время на эту операцию состоит из двух промежутков (не обязательно одинаковых): 1- принятие решения ARBITER кто будет следующим обращаться к памяти (next); 2- само обращение к памяти SDRAM (current).
3. Время (current) обращения к памяти DRAM у железа PentEvo занимает один период частоты 7 MHz (4 такта с частотой 28MHz: c0,c1,c2, c3) и не может быть меньше. Переход от next к current всегда по положительному фронту сигнала с0. Если Z80 работает на частоте 14 MHz, то вводятся такты ожидания. Будем рассматривать работу Z80 на частоте 7 MHz.
4. В процессоре PentEvo время активного состояния сигнала чтения Z80 занимает больше одного такта частоты zclk. Зеленая область на рисунке отведена для ARBITER (next), а синяя - для обращения и чтения даныx из DRAM (current).
5. В процессоре, реализованном на VHDL (Verilog) сигнал чтения активен только в синей области.
6. Что делать, пока нет новой конфигурации от TS-Labs для решения данной проблемы?
7. Есть простая идея поделить синюю область между ARBITER и SDRAM. Такое возможно, так как для SDRAM для чтения вовсе не обязательно время в один период от частоты 7 MHz. Поделить время во время активного сигнала чтения Z80 означает сдвинуть цикл Z80 относительно 4 тактов с частотой 28MHz: c0,c1,c2,с3 которые будем считать привязаны к работе SDRAM (переход от next к current по положительному фронту с0).
8. Теперь следующий вопросc – в какой пропорции делить время одного цикла (синяя область на рисунке) между next-current. Я поделил (без всяких обоснований) как 1.5 – 2.5 (единичка – период частоты 28 Mhz). Что имеем в имеющейся реализации (DevBoard) данной бредовой идеи перенести TS-Conf для z80 (в имеющейся версии) на FPGA.
Испытывал на трех DevBoard от разичных компаний Terasic, ZR-Tech и
http://www.heijin.org – не удосужился даже посмотреть что за компания, поэтому просто назвал TWARM (это скорее название магазина, в котором я покупал через интернет эту плату - DB4CE15)
- DE0: Cyclone III + SDRAM (84MHz, 16bit) - запустилось
- ZR-Tech: Cyclone IV + SDRAM (84MHz, 16bit) - запустилось
- TWARM: Cyclone IV + SDRAM (84MHz, 16bit) - запустилось.
Вроде как 2.5 периода от 28MHz хватает для чтения SDRAM 16bit, но при удлинении на один период 84MHz для реализации чтения 8bit на U8, U9 – не пошло. В тоже время для TWARM – запустилось. Скорее всего, 2.5 периода от 28MHz для чтения SDRAM 8bit (в текущей реализации) – критическое время.
9. Итого:
- сама идея адаптации TS-Conf для z80 (в имеющейся версии) на FPGA путем сдвига циклов SDRAM и z80 является жизнеспособной и я без проблем (пока не обнаружил во всяком случае) использовал для трех DevBoard для SDRAM 16bit.
- адаптация для SDRAM 8bit существует пару дней и я мало ее запускал, поэтому надо больше времени чтобы сказать что то больше.
10. Что дальше
Буду смотреть в сторону SDRAM 8bit
Делать тесты для SDRAM и менять соотношение next-current.
11. В скором будущем TS-Labs порадует нас новой конфигурацией, где этих проблем не будет. Так стоит ли на это тратить время? Если интересен сам процесс – то почему нет. Я всегда был сторонником делать (пусть и топорно), а не ждать. Спасибо MVV, что согласился протестировать мою адаптацию на U8, U9. С утра на свежую голову я склоняюсь к мысли, что проблема в критичности времени для SDRAM 8bit (в текущей реализации конфигурации).