Имеется проект на EP1C6T144I7. Портирован на EP2C8F256I8. В проекте есть SDRAM контроллер, при его проектировании в свое время вставал вопрос о реальных временнЫх задержках между логикой ПЛИС и ее выводами. Например, через сколько времени от фронта клока на выходном триггере IO элемента сигнал вывалится на вывод микросхемы. И через сколько времени от поступления на вывод микросхемы сигнал дойдет до входного триггера IO элемента (все это актуально для чтения из SDRAM). Для EP1C6T144I7 в симуляторе было установлено, что выходная задержка порядка 2.2 нс, входная - 1.4 нс. Сигнал там поступает с вывода микросхемы через элемент задержки. Значение этого элемента задержки по умолчанию указано 0 нс. На основе этих времянок выстроена схема тактирования выходного и входного триггеров - так, чтобы тактирующий фронт приходил на входной триггер тогда, когда сигнал с выхода SDRAM прошел с вывода ПЛИС до входного триггра и присутствовал на его входе с соблюдением setup/hold требований.

Аналогичное моделирование EP2C8F256I8 показало, что по умолчанию элемент задержки имеет значение максимальной задержки, которое составляет немного-немало, а целых 4.940 нс, т.е. порядка 5 нс (тактовая частота проекта 100 МГц, SDRAM тактируется с этой же чатотой). Естественно, из-за этой задержки сигнал уже не успевает достичь входного триггера, не говоря уже о соблюдении требований setup/hold, т.е. попросту во время прихода тактирующего фронта на входе данных триггера неверное значение (в симуляторе читается z-состояние, реально, очевидно, должно читать что попало, скорее всего, предыдущее значение, "запомненное" на паразитных емкостях).

Комилю проект, проверяю, что реально читается - читается все правильно (контролирую Signal-Tap'ом). Меняю величину задержки этого элемента задержки от минимума (0 нс), до максимума (4.940 нс), ничего не меняется - всегда читается правильно. Отсюда вопрос: эта задержка реально присутствует в микросхеме или это только в симуляторе видно да в Chip Editor'е? Может кто-нибудь прояснить описанный феномен?


Второй вопрос: для контроля за чтением решил использоовать In-System Memory Content Editor - при чтении из внешней SDRAM писать считанные данные во внутренний буфер (память ПЛИС), а этим инструментом контролировать содержимое буфера. На предыдущем этапе в первом Циклоне это все прекрасно работало, очень удобно было экспериментировать. Здесь же при компиляции получаю ошибку с объяснением (вольный перевод): блок памяти М4К микросхемы Cyclone II не может быть использован в режиме Dual-Clock True Dual-Port Memory, обратитесь к еррате. Обращаюсь к еррате, обнаруживаю, что действительно в ревизии А есть проблемы при записи с двух портов при определенном временном соотношении клоков может происходить сбой записи. Для разных режимов там воркэраунды предлагаются, а про In-System Memory Content Editor сказано, что это может использоваться только с исправленными микросхемами, т.е. с ревизией В. Ну ладно, понятно. Пытаюсь выяснить, какая же у меня используется ревизия, и не могу найти, где это описано. В доке не нашел ничего - на слово "revision" оно выдает только "Revision Histoty". Где есть описание маркировки так, чтоб можно было выяснить ревизию? Или, может, по дате выпуска можно определить? Где это можно глянуть?