Имеется проект на 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". Где есть описание маркировки так, чтоб можно было выяснить ревизию? Или, может, по дате выпуска можно определить? Где это можно глянуть?

В еррате, 1 страница, последний абзац + Figure 1.

да ругаться он будет, но можно "обмануть" квартус
у меня получалось так - если "вырубить PowerPlay power optimization - OFF"
квартус перестал ругаться
проект был в ep2c256 той самой ревизии. как ни страно описаный глюк M4K не наблюдал, и тоже как и вы использовал In-System Memory Content Editor, не более 50 мгц
В вашем случае всё же не обманывать :-), купить нормальной ревизии.
ревизию как обнаружить вам уже обьяснили
скажем такая надпись
EP2C256C8N
K BAA9T0625A
ревизия будет A

Спасибо, парни! Я всю доку на Циклон2 просканил, хелп и доку на Квартус - не нашел. В еррате не ожидал это найти и не искал. А на глаза не попалось (выборочно читал).


Микрухи уже куплены и запаяны. И ревизия там стоит В. Осталось только объяснить Квартусу этот момент. Попробую сделать как Вы. Вообще, это тут у них недоработка - если есть ревизии и разное поведение, то и Квартус должен эти вещи понимать и поддерживать.

Спасибо еще раз.

а он понимает и поддерживает обе ревиизии!
лезем в assignments->settings->fitter settings-> Жмём more settings-> находим строку maintain compability with all cycloneII M4K Versions и обнаруживаем, что по умолчанию это галка в ON.

Действительно!

Необычно. У того же VisualDSP++ как-то традиционнее сделано - там просто ревизия явно указывается для проекта (или в командной строке тулзам) и все. Если не указано, то используется последняя на момент выхода релиза тулчейна.

Если еще появятся ревизии, то, надо полагать, надо будет ждать изменений в интерфейсе.

Скорее всего в этом и была ошибка. Очень большие сомнения, что на первом циклоне, с индексом скорости 8 вы реально получаете 1.4 и 2.2 нс. Так что вероятней всего так как второй циклон априори быстрее даже с темже индексом скорости, проект работает нормально.

Какая именно ошибка имеется в виду?


Если внимательно посмотреть на исходный пост, то можно увидеть, что там упоминается EP1C6T144I7. Это какой спидгрейд?

Во-вторых, чем не нравяться величины 1.4 и 2.2 нс? Это по-вашему много или мало? Эти величины взяты не с потолка, это выдает Квартус.

И опять же если внимательно прочитать исходный пост, то там можно встретить:

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

Т.е. независимо от быстроты самой микросхемы меняется настройка задержки, меняется на почти 5 нс - это весьма значительная величина, при таком изменении один из вариантов не должен работать. Тем не менее, оба работают, что и вызывает у меня недоумение.

Да хоть для 7 спида, 1.4 нс и 2.2 нс это уж очень мало для первого циклона.

Зачем недоумевать... Вы указываете какую задержку выхотите видеть, а будет ли она синтезирована так как вы хотите или нет, тут уж ничего сделать нельзя... Какая есть, такая есть. Вывод - она не меняется.

А сколько по-вашему там должно быть? И на чем это основано? Я привел величины, выдаваемые Кварутсом. Кто помимо него еще достоверно осведомлен о реальных времянках?


Если есть программируемый элемент задержки, который еще и программируется, что видно невооруженным глазом, в частности, в Chip Editor'е, то логично ожидать от микросхемы описанного поведения. Если уж родному САПРу не верить, то кому тогда можно верить и строить на этом успешную работу?

Задержки на пинах приводятся для нагрузки 50 пф, если у Вас подключен 1 вход sdram - 7-10 пф и выходные драйверы успевают отработать за малое время - схема работает.

Не понял. Я веду речь об элементе задержки, величина которого задается констрейном:

set_instance_assignment -name PAD_TO_INPUT_REGISTER_DELAY 7 -to Data*

Здесь число 7 задает максимальную задержку в 4940 пс (0 соответствует минимальной задержке в 0 пс). При нулевой задержке на этом элементе время прохождения сигнала от пина до входа триггера составляет примерно 1.3 нс. А этой задержкой общее время прохождения можно регулировать в пределах от этих минимальных 1.3 нс до максимальных 1.3 + 4.94 нс (там 8 значений доступно).

А Вы о чем?

А я о задержках на выходных падах. Сорри.

А у вас случаем вот этой ситуации нет?

However, if the pin uses the input register, one of delays is disregarded
because the IOE only has two paths to internal logic. If the input register
is used, the IOE uses one input path. The other input path is then
available for the combinational path, and only one input delay
assignment is applied.

Из PDF по Cyclone II

Это уже гораздо теплее, но все-таки не совсем то. У меня используется только один путь - через регистр, комбинационный не используется. Да и если бы вопрос стоял так, что, дескать, задаю констрейн на задержку, а она не встает (по вышецитированной причине), то это было бы вполне объяснение. А она, вроде, встает, о чем Квартус рапортует - управляемость этим параметром полная. Только вот не должно с задержкой работать, а работает. На всякий случай картинку прилагаю. На ней величина задержки максимальная. Если задать констрейн с параметром 0, то и задержка эта будем минимальной. Цифры от 0 до 7 задают величины задержки из выпадающего списка на картинке. Отсюда и подозрение, что в реале оно просто кладет на это. Либо есть еще какая-то скрытая причина, о которой я не знаю. Вот это и пытаюсь выяснить в данной теме.

А если провести эксперимент.
Этот сигнал выдать через задержку на другую ножку, напрямю и начать менять эту задержку. 2х канальным осцилографом смотреть результат?
Все таки у меня мнение что кладет он на эту задержку. Можно ли глянуть отчет после синтеза, который выдает Квартус? После Place/Routa и Mapa?

Идея здравая, как руки дойдут, обязательно посмотрю и доложу.


Вот и у меня такое впечатление складывается.


Что именно глянуть? В каком месте? На картинке выше именно после разводки, как же еще.

Эта картинка никоим образом не является ОТЧЕТОМ после синтеза. Тем более временным.
Квартуса под рукой сейчас нет приведу пример из ISE:




Эта картинка никоим образом не является ОТЧЕТОМ после синтеза. Тем более временным.
Квартуса под рукой сейчас нет приведу пример из ISE:

Эта картника является частью полного отчета (описания) выбранного в Chip Editor'е элемента в графическом виде. Там ниже картинки приведены все данные в табличном виде по всем элементам рассматриваемой ячейки. Полнее трудно придумать.


В Квартусе отчета о прохождении всех сигналов с задержками я не нашел (правда, сильно и не искал). Там есть отчеты по tcu, th, tco и т.д. Но это не то.

Не понимаю как _меню_ с вариантами задержки может являться _отчетом_ по времени прохождения конкретного сигнала?