Делаю проектна Cyclone. Работаю на частотах близких к его предельным.
при этом возникают существенные задержки обрабатываемых сигналов по сравнению с периодом клока, что приводит к следующему:
изначально делал функциональный анализ, добился требуемых результатов,
сделал временной- не пашет.
Манипуляции с сигналом у меня происходят по высокому уровню клока, я предположил, что сигнал из-за задержек сместился, сделал чтоб все происходило по низкому уровню- времянка заработала как надо.
Но теперь ерунда с функционалкой... Сделать, чтобы симулировалось нормально одновременно и в функционалке и во времянке не получилось.
Микросхемы пока до меня не добрались, поэкспериментировать с железом не могу, посему вопрос:
достаточно только временного симулирования? что в этом случае посоветуете?
чем все это грозит и какие могут быть проблемы в железе после прошивки?

Как раз временное моделирование и дает настоящий результат, а не функциональное, результаты которого весьма приближенные/предварительные! Вообще никогда не делаю функциональное моделирование.
В сущности выражение "временное моделирование" не очень корректное - точнее надо бы называть это "полное моделирование". Результаты такого моделирования у Altera весьма точны - как отмоделировали, так и будет работать.

Хотя на вопрос уже ответили, для общего развития ...
У Xilinx типов моделирования - 4:
1) Поведенческое
2) Уровня RTL
3) PostMAP
4) PostPAR

1 - работа алгоритма
2 - после того как над вашей писаниной прошелся синтезатор и выкинул "не нужные" части Вашего кровью полученного кода.
3 - после работы "размещателя" на кристалле
4 - после окончательного размещения элементов и разводкой соединений

Зачем столько типов, оставили бы только PostPAR. Если проект развесистый, времени на симуляцию будет уходить - сто тыщ мильёнов
А так можно еще выявить, в каком месте получается 2+2=35.

Vjacheslav, 3.14 Большое спасибо за ответы!
Вопрос возник вот из чего, я заводил подобную тему на Телесистемах, там многие ответили, что пользуются или функциональным моделированием, или временным, но полностью уверены, что в функциональном у них то же самое.
Я же изначально тоже всегда только времянкой пользовался, вот и подумал, может у меня неправильный подход к разработке проектов на ПЛИС?

Я и сейчас могу подтвердить, что у меня в функциональном и в временном моделировании одни и те же результаты ( в пределах интервала глобального клока). И к этому надо стремиться.

А я уже давно отказался от всех, кроме первой. И то, симуляция минимального размера кадра занимает больше 10 минут, а с латентностью - уходит не меньше получаса. А более сложные случаи - и того больше - часы.

Хотя раньше, особенно в меньшего размера однократно программируемых FPGA QuickLogic, я обычно использовал последнюю.

Сейчас - функциональная симуляция - отдельно, анализ времен - отдельно. И максимальные частоты, получаемые в железе совпадают с предсказанными Xilinx-овскими тулами с примерно 5-10% точностью.

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

Когда устройство достаточно сложное, проверить все такие "иголки" очень сложно или невозможно, поэтому нужно так писать код, чтобы их не было вообще (т.е. не было в том месте и в то время, когда они бы могли на что-то повлиять). Как именно это делать - тонны литературы существует, но основная суть проста - синхронный дизайн, тщательный разбор устройств на границе клоков (желательно использовать в таких случаях готовые, проверенные решения), учет возможной метастабильности.

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

Да, Post P&R моделирование дает более близкое поведение к железу. Но цена за это чрезмерна:

[1] чуть-ли не на порядок бОльшее время, затрачиваемое симулятором (а вот мне надо один или несколько видеокадров прогнать - дык замучаешься ждать);

[2] и крайнее неудобство при работе - все имена попереименованы, свои интересующие объекты найти - еще та работа.

В случае функционального моделирования обеих этих трудностей нет - все работает максимально быстро, удобство при отладке полное - все переменные на месте.

В итоге я почти никогда не использую P&R моделирование, а в основном только функциональное. P&R использую только в редких случаях, когда надо посмотреть/отследить какие-то конкретные времянки в каких-то конкретных точках (например, в последний раз надо проконтролировать, через сколько времени после фронта клока на триггере I/O элемента данные вываливаются на пин - интерфейс с асинхронной памятью отлаживал). Но это редкость. И пользоваться этим для отладки функционирования - имхо, мазохим.

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


Не так давно столкнулись с непоняткой: микруха MAX3128, в ней простой мультиплексор, симулятор в Квартусе (и в Альдек пробовали передавать - ровно то же самое, что и понятно) выдает время переключения около 20 нс, а реально в железе - где-то около 12-14 нс. Спрашивали поддержку Альтеры, они сказали, что, дескать, юзайте последние версии софта. А софт, понятное дело, был последней версии.

А вы в своем проекте уверены?
Схема должна работать при любых условиях!
В вашем случае получается ограничение на минимальную тактовую частоту, если вы по каким либо причинам переместите схему в более быстрый кристалл, то схема может перестать стабильно работать.
На сколько я понял, ограничения на длину конвейера, чисто символические, попробуйте воставить дополнительную ступень.



Был у меня подобный случай, на max7s, когда целую неделю пытался переписать данные из одного регистра в другой на частоте 30 МГц, при расчетной частоте схемы 80. Проблемма решилась ручным синтезом(в макроэлементы) и разводкой(компоновкой).
Причем и функциональная и временная модели работали как нужно.
Не известно почему,но файл временных задержек, не соответствовал действительности в 2-2.5 раза. При этом использовалась самая последняя версия ПО.

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

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

Был у меня случай, когда синтезатор неправильно обрабатывал VHDL-модуль. То есть логическая модель работала, а post-translate уже нет. Железка тоже естественно не работала. Надо правда сказать, что это было вызвано кривостью кода (не мной написанного) и после нескольких ударов зубилом по нужным местам все пришло в норму. В нормальной же ситуации первого и последнего типа моделирования хватает за глаза.

Уважаемые гуру, проясните, пожалуйста, вот такой вопрос. Если у меня выполняются все временные ограничения на рабочую частоту, то какая разница, сработает ли логика между парой регистров за 50 пс до очередного фронта клока или за 5 нс до него? И для чего тогда вообще временное моделирование?
P.S. Я всегда использовал функциональное моделирование и данные временного анализатора после компиляции проекта, а времена предустановки и clock-to-out, по-моему, надо учитывать отдельно (вместе с времянкой внешних устройств).

Нет никакой гарантии что Вы затяните констрейнами все пути своего проекта, тем более что сделаете это правильно, а метастабильность... Ну а использование симулятора, практически позволяет осуществить макетирование (причем с учетом диапазона температур и питания), только в большинстве "наших" проектов это выходит дороже макетирования.
Ну а если Ваш проект вход - конвеер - выход, тогда достаточно знать что констрейн для данного тактового сигнала выполнен (ну и путь логика - пин то же).

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

ВременнОе моделирование, имхо, рулит в некторых случаях, когда надо именно времянки отследить - например, при отладке интрефеса с внешним устройством (например, памяти), где жесткая времянка, становится важным, сколько времени проходит сигнал с выхода триггера I/O элемента до выходного пина. А функционалку отлаживать после синтеза и размещения с времянками, согласен, муторно, трудоемко и неразумно.

Хмм нельзя не согласиться, но
сижу над блоком(метематика + на входе выходе doubl buff), функционалка работает нормально, после синтеза тоже, а вот после ПАРА не работатет.
Начал выяснять почему (раскопал в ПАРе нужные мне сигналы) оказываеться глючит логика double buff.
но вот почему ?? там код то простой как 3рубля

А вы стакливались с тем, что после ПАР, проект не работатет, не смотря на то, что проект синхронный, все констрейны выполняються, и РТЛка правильная.
как вы с этим боролись ?

Я с этим сталкиваюсь практически постоянно , причина этого - туча частотных доменов.
Кстати, схемы устраняющие метастабильность в ModelSime (думаю и в ActiveHDL то же) не будут работать, если специальных мер не принять.

Не после P&R, а в железе, имеете в виду? Сталкивался, но редко. Основная причина - неучет на модели асинхронности внешних сигналов и, как следствие, метастабильность (вылечивается применением синхронизаторов). Еще, как уже упоминал, налетел однажды на то, что не учел задержку от триггера до пина и обратно от пина до входа триггера (с учетом времени setup для оного триггера). Но это на стыковке с внешними делами, на моделе внешнее окружение учесть трудно, да и временной анализатор тут не помошник. Как, впрочем, и симулятор - можно отловить, а можно и не отловить - как фазы клоков/сигналов друг на друга попадут. Но внутри все работает как часы, никогда проблем не испытывал. А внешние дела надо аккуратно руками следить.

3.14
Как понять "Нет никакой гарантии что Вы затяните констрейнами все пути своего проекта, тем более что сделаете это правильно"? Все пути СВОЕГО проекта так трудно определить, или только избранные могут сделать это правильно?
"а метастабильность..." А что метастабильность? Каким образом временное моделирование поможет решить эту проблему? Надо логику проектировать так, чтобы учесть эффекты метастабильности, если они должны возникать в каких-то местах.
И как симулятор учитывает диапазон температур и тем более питания? Есть sdo-файл (я пользуюсь Verilog'ом) и post-fitting netlist, и все, или я чего-то недопонял?

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

Если их три то не сложно, а если их 20, практически не возможно не ошибиться.
Только симулятор позволит проверить правильность этих "развязывающих" схем. Сами говорите "Надо логику проектировать так, ..." дык а проверить?
Имел в виду, наихудший случай - наименьшее питание ядра и наибольшая тепература (во время макетирования ведь и температура комнатная и питание нормальное). Еще в памяти что то мелькает про директивы ModelSim по смене температуры. Еще имеется соображение, в файле ограничений можно указывать температуру и питание ядра, PAR соответственно будет пользоваться другими временными хар-ками логики, вот как это скажется на моделировании? Возможно это все передастся через SDF, надо попробовать.

Мне кажется, нельзя смоделировать поведение триггера в состоянии метастабильности, поэтому никакая симуляция не поможет.


А какими САПР/ПЛИС Вы пользуетесь? Спрашиваю потому, что для меня новость, что можно задавать температуру и питание ядра.

Возможно все
По умолчанию симуляторы, в случае нарушения setup/hold для регистра устанавливают его в X значение. После этого весь автомат рушится. Иногда это становится (твкой способ обработки ошибок) занозой в з... В случае, если симулируете в VHDL, ModelSim может глобально отключить подстановку Х, взамен оставляет старое значение регистра. В случае с Verilog возможно только указать через файл ограничений какие регистры не учитывать при нарушения зазоров (предполагается, что они первые в цепи антиметастабильности).

Xilinx(ISE) симулирую (иногда ) в ModelSim.

мдя - почитал и подумал: как до сих пор наши самолёты летают, а поезда не cxодят с рельс?
мой скромный совет таков: если хотите чтоб у вас что-то работало, не нужно выдумывать заного велосипед: делайте сначала функциональную верификацию, а затем временное моделирование - потом будет меньше гемороя - а если результаты не cxодятся - значит неправильно проектируете - возвращайтесь на логический уровень, вставляйте регистры, разбивайте на блоки, конвееризируйте

Зачем так драматично

Самое что занятно не работает именн внутрях, а не во внешних интрефесах. М не работает после P&R(сделал бак анотейт)
и в железе
Симулятор Альдек

Не, внутрях не сталкивался. Все стабильно и предсказуемо, если успевает между клоками. Тулчейн: Синплифай+Квартус. Симулятор - Альдек.

А вот с этого места подробнее, пожалуйста. Мне пришлось применить переход к другому клоковому домену с близкой частотой (100 -> 85 МГц). Как сделать, чтобы Моделсим не выдавал неопределенность, после которой все дальнейшее поведение становится тоже неопределенным?
Другими словами, какие они, Ваши специальные меры?

DefaultForceKind = freeze Это оно?

DefaultForceKind = freeze

Это оно? Или где?

Когда моделька рождается в VHDL, галка глобального отключения "Global disable X-generation for simulation".
Ну а констрейн называется ASYNC_REG, например INST "I_MK_module/WEa[*]" ASYNC_REG = TRUE;

Спасибо. Нашел. В детстве шарады у меня хорошо разгадывать получалось...
Это ж ведь и не в Моделсиме вовсе.

Возможно, что это то самое...

--8<---
To prevent "x" from propagating in your simulation, use the "+no_notifier" option to vsim command when using ModelSim Simulator (MTI)
--8<---

Оно самое. Но сами понимаете, что этим лучше пользоваться только в исключительных случаях.

Получается, что работу собственно схемы борьбы с метастабильностью проверить в симуляторе нельзя. Либо мы запрещаем метастабильность для входных регистров этих схем путем игнорирования нарушения setup/hold, либо неопределенное состояние так и пройдет дальше, нарушая работу модели, чего в железе как раз и не произойдет.

И еще возникает вопрос: а разве в модели регистра невозможно учесть время метастабильности и передавать его через SDF? Я понимаю, что это время не посчитать точно, но можно было бы задать какую-то оценку, и симулятор работал бы более наглядно: вот состояние неопределено, а вот устаканилось...

Дык вот в том то и дело, что в железе это будет работать (например 999 раз из 1000), а симулятор это сразу заметит и укажет. И потом, мы ведь выключаем детектор метастабильности только для первого регистра, так что все "чинно, благородно".

Может я чего не понял, но в симуляторах все так и работает.

3.14:
Наверно, это я чего-то недопонял.
Поясните, пожалуйста, это:


Что нам сразу заметит и укажет симулятор, что нарушено время setup/hold? И выставит "x" или просто напишет "Error..."? Так ведь мы и планируем нарушить времянку и посмотреть что будет, если хотим бороться с метастабильностью. Так что в железе должно работать 1000 раз из 1000, а иначе грош цена схеме антиметастабильности. Здорово было бы, если бы ножки ПЛИС делались красного цвета (как в ModelSim'е "x" по умолчанию), а тестер/осциллограф писали бы "x", как бы тогда отладка упростилась.


Насколько я понимаю, если триггер встал в неопределенное состояние, то он в нем так и останется по крайней мере до следующего фронта клока. У меня ModelSim так работает с альтеровскими "атомами", может у Xilinx'а иначе, но что-то не верится. А ведь в железе триггер в состоянии метастабильности пробудет какое-то конечное время, порядка 1 нс, насколько я представляю, а потом станет стабильным.

2 popeye
Когда я говорил "Дык вот в том то и дело, что в железе это будет работать (например 999 раз из 1000), а симулятор это сразу заметит и укажет." я подразумевал работу схемы без антиметастабилизатора. Говорим то об одном и том же , просто меня смутило, почему нельзя считать, что можно симулировать работу антиметастабилизатора при отключенном детекторе метастабильности на первом регистре. Это и работать будет и симулировать можно без угрызения совести если тактовый сидит на глобальной линии.

Далее по тексту, сори, это я упустил Вашу фразу "учесть время метастабильности и передавать", мне то же не понятно, что производителю мешает это сделать, наверное большаея нестабильность времени метастабильности от кучи факторов (время нарушения, температура, питание и т.п.).

Возвращаясь к теме. Недавно прочитал довольно интересную доку по поводу несовпадения функциональной модели и логики после синтеза. Вещи там на мой взгляд написаны довольно очевидные, но все равно полезные.

RTL Coding Styles That Yield Simulation and Synthesis Mismatches