Functional and Timing Simulation, возможен ли комбинированный способ? Опции

[dxp]

Преамбула.

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

Functional.

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

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

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

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

Недостатки.

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

Timing.

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


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

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

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

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

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

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

[Gorby]

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

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