Имеется проект на 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".
Где есть описание маркировки так, чтоб можно было выяснить ревизию? Или, может, по дате выпуска можно определить? Где это можно глянуть?
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Cyclone II, два вопроса.
Jun 7 2007, 13:01
