Преамбула.

Какой способ моделирования предпочесть? Тут уже были споры. Имхо, спорить тут не надо, надо исходить из требований задачи и достоинств и недостатков обоих способов.

Functional.

Достоинства:

1. Скорость. Процесс моделирования происходит на порядок быстрее timing, т.к. количество сущностей в процессе моделирования в соответствующее количество раз меньше.

2. Удобство. Все имена, заданные во входном описании, сохраняются, все на месте (ничего не выкинуто синтезатором/маппером, ничего не переименовано и т.д.)

Устойчивость результатов базируется на том, что если вся логика успевает переключиться между фронтами системного (глобального) клока, то поведение реальной железки не будет отличаться от функциональной модели (дизайн, ессно, синхронный). Успеваемость логики докладывает Timing Analizer. Если он не ругаецца, то все хорошо.

Недостатки.

Недостаток, собсно, один - нет реальной картины по задержкам на логике и путях трассировки. Иногда это важно.

Timing.

Тут все ровно наоборот - скорость не радует, удобство вообще никакое, зато можно конкретно отследить задежки на любом триггере и ячейке.


Теперь амбула.

Для моделирования поведения описания внутри ПЛИС в подавляющем большинстве случаев хватает функционального моделирования. ВременнОе использовал пару раз - когда просто ради интереса хотел посмотреть задежки по пути сигнала. Но когда возникает необходимость смоделировать взаимодействие с внешними высокоскоростными устройствами, тут приходится прибегать к временнОму моделированию в полный рост.

Пример: ПЛИС взаимодействует с внешней памятью (SDRAM, SCLK = 100 МГц, на нее есть моделька). Здесь появляется настоятельная необходимость учитывать задержки распространения сигналов от выхода триггера ячейки ввода-вывода до пина и наоборот - от пина до входа триггера, где фиксируется значение сигнала, пришедшего снаружи. Времена там вполне существенные по отношению к периоду клока - для Cyclone, например, от выхода триггера до пина - порядка 1680 пс, от пина до входа триггера - 1390 пс (это без учета требований по setup time (400 пс) для триггера, т.е. реально запас надо еще на это иметь). В общем, чтобы не пролететь, надо все это учитывать, согласовывать с задержками самой памяти.

И вот тут получается некоторая некузявость - с одной стороны, удобнее и быстрее моделять в функционалке, но тут в времянками на вводе-выводе никак, а они здесь важны. С другой стороны моделять весь проект в таймингах вообще не улыбает - тормоза, дикое неудобство (вплоть до того, что при синтезе какие-то ноды могут быть выкинуты, переименованы и т.д., т.е. опять их искать, смотреть, кроме того, это реально низкий уровень - там столько всякой всячины, интереса не представляющей, но вполне загромождающей проект (в симуляторе)). И ведь совершенно не требуется симулировать ВЕСЬ проект во времянках - надо-то только элементы ввода-вывода, остальное прекрасненко годится в функциональном виде.

Отсюда и вопрос: как совместить? Т.е. как произвести моделирование проекта в функциональном режиме, но с эмуляцией задержек на элементах ввода вывода. Пока приходит только нечто вроде: моделировать в функциональном режиме и вставить искусственные элементы задержки между пинами и триггерами. Чтобы это не мешалось при синтезе, ввести условную трансляцию - в симулятор это передается, в синтезатор нет.

Может еще какие варианты есть. Вообще, кто как выходит из положения, поделитесь опытом?

Если вопрос именно в sdram, то он разбирается в файле n2cpu_nii51005.pdf.

Эээ, а констрейны на что?

Если проект сделан на основе сф-блоков ( )
то разведите только контроллер сдрам!
при соединении потом остальной ПЛИС с разведенным контроллером сдвигайте clk на входе контроллера примерно на полтакта (смотря по требуемым задержкам в контроллере) или больше.

По собственному опыту: если сдрам на плате питается от ПЛИС (clk) то выдавайте ей инверсную 100 МГц. А защелкивайте данные по нормальному клоку. При этом все триггера на ножках (и In и Out) должны сидеть в IO.
Проверено, работает стабильно на Cyclone и StratixII.

Сообщение отредактировал vikk - May 11 2006, 09:51

Причем тут констрейны? Как они помогут смоделировать задержки?


Как сделать тактирование - это несколько другой вопрос. Да, без учета задержек тоже работает, хотя и на пределе. Хоцца все же видеть более правильную картину, более соответствующую действительности.

Спасибо, познавательно. Как и предполагалось, там предлагается использовать директивы translate_on/off. Видимо, так и поступлю.

При том, что необходимость изучать задержки исчезнет, если правильно задать output delay.
Кроме того, задержки на выходном io-блоке являются статическими и указываются в отчете квартуса. Нет необходимости прогонять какое-либо моделирование.


По поводу правильной картины: http://www.xilinx.com/publications/xcellon...tor-hyper49.htm

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

Кстати, а что, констрейны решают все задачи? Что, можно задать любой констрейн и он будет выполнен? Что-то сомнительно. Например, напишу, что время прохождения сигнала от выходного триггера IOE до пина равно 1 нс - будет это выполнено? Нет. Т.ч. тут тоже есть конкретные рамки. Но вопрос совсем не об этом был.


Опять не то. Моделирование мне нужно не с целью определения задержек - это я могу (и сделал) отдельно. Вполне успешно. Моделирование мне нужно для отладки взаимодействия внутренних потрохов ПЛИС с внешней памятью (это SDRAM контроллер и те устройства, которые через него данные качают). Надеюсь, Вы не будете возражать против тезиса, что в этом случае моделирование все-таки не лишне? В этом случае я бы хотел (повторяю) проводить моделирование всего проекта на функциональном уровне, но с более-менее правдоподобной картиной задержек от/до входных/выходных триггеров до/от пинов. Это удается сделать путем использования директив /* synthesis translate_off */ и /* synthesis translate_on */. Выходит, вроде, пристойно.


Спасибо, посмотрю.

Если отвечать конкретно на заданный вопрос, то можно попробовать разбить дизайн на внутренний модуль и интерфейс - выходные регистры с падами. Интерфейс отсинтезить и получить sdo. А при моделировании собрать солянку: rtl-описание внутр. модуля и интерфейс с подключенным sdo. Я так не делал, но может сработать.

У меня приблизительно такая же задача. Контроллер DDR модуля.
Есть модель миксросхемы памяти. Базируясь на ней я сделал модель модуля (DIMM).
Моделирую в Моделсиме в timing режиме. Да, долго. Но зато все видно.
Перед моделированием из прототипа платы беру примерные длины проводников, приблизительный импеданс (Протел позволяет). И смотрю на форму сигналов и на задержки по проводам в Hyperlynx. Так вот вычисленные там задержки я вбиваю руками в соответствующие сигналы в Тестбенче. Что приятно - результаты симуляции очень хорошо совпадают с поведением реального железа.
Единственная проблема - с двунаправленными шинами. Пришлось разделять их на две встречно-параллельные (туда-сюда) и коммутировать руками (стимулами).

Очень сомневаюсь, что это можно сделать с функциональной симуляцией.

Недавно нашел в библиотеке synplify. компонент ZeroOhm1. (В поставку ahdl входит) Рекомендую посмотреть. Может из него получится сделать что-то стоящее.

У меня все значительно скромнее - провода на плате достаточно короткие, задержки на них малы по сравнению с задержками на внутренних буферах ПЛИС, а темп поступления данных тоже вдвое проще, чем на DDR.