Делаю проектна 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, по-моему, надо учитывать отдельно (вместе с времянкой внешних устройств).

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