[M_A 0]

Делаю проектна Cyclone. Работаю на частотах близких к его предельным.

при этом возникают существенные задержки обрабатываемых сигналов по сравнению с периодом клока, что приводит к следующему:

изначально делал функциональный анализ, добился требуемых результатов,

сделал временной- не пашет.

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

Но теперь ерунда с функционалкой... Сделать, чтобы симулировалось нормально одновременно и в функционалке и во времянке не получилось.

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

достаточно только временного симулирования? что в этом случае посоветуете?

чем все это грозит и какие могут быть проблемы в железе после прошивки?

[Vjacheslav 0]

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

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

[3.14 0]

Хотя на вопрос уже ответили, для общего развития ...

У Xilinx типов моделирования - 4:

1) Поведенческое

2) Уровня RTL

3) PostMAP

4) PostPAR

 

1 - работа алгоритма

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

3 - после работы "размещателя" на кристалле

4 - после окончательного размещения элементов и разводкой соединений

 

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

А так можно еще выявить, в каком месте получается 2+2=35.

[M_A 0]

Vjacheslav, 3.14 Большое спасибо за ответы! :)

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

Я же изначально тоже всегда только времянкой пользовался, вот и подумал, может у меня неправильный подход к разработке проектов на ПЛИС?

[sazh 3]

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

[Andrey Filippov 0]

У Xilinx типов моделирования - 4:

1) Поведенческое

2) Уровня RTL

3) PostMAP

4) PostPAR

...

Зачем столько типов, оставили бы только PostPAR.

 

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

 

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

 

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

[M_A 0]

Исходя из всего вышесказанного у меня вопрос к тем, кто пользуется только функциннальным моделированием:

В железе из-за задержек возникают всякие траблы вроде пиков, иголок, данные приходят раньше клока, иногда даже генерация выскакивает....

Как при готовом проекте это обнаруживаете и как с этим боретесь?

Я думал что такие вещи только на времянке можно увидеть, хотя чувствую что не только, а думал так по не знанию, ламер пока

[Andrey Filippov 0]

Исходя из всего вышесказанного у меня вопрос к тем, кто пользуется только функциннальным моделированием:

В железе из-за задержек возникают всякие траблы вроде пиков, иголок, данные приходят раньше клока, иногда даже генерация выскакивает....

Как при готовом проекте это обнаруживаете и как с этим боретесь?

Я думал что такие вещи только на времянке можно увидеть, хотя чувствую что не только, а думал так по не знанию, ламер пока

<{POST_SNAPBACK}>

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

 

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

[dxp 53]

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

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

 

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

 

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

 

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

 

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

 

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

 

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

<{POST_SNAPBACK}>

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

[vetal 0]

Vjacheslav, 3.14 Большое спасибо за ответы! :)

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

Я же изначально тоже всегда только времянкой пользовался, вот и подумал, может у меня неправильный подход к разработке проектов на ПЛИС?

<{POST_SNAPBACK}>

 

А вы в своем проекте уверены?

Схема должна работать при любых условиях!

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

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

 

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

 

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

Причем и функциональная и временная модели работали как нужно.

Не известно почему,но файл временных задержек, не соответствовал действительности в 2-2.5 раза. При этом использовалась самая последняя версия ПО.

[Joker 0]

Vjacheslav, 3.14 Большое спасибо за ответы! :)

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

Я же изначально тоже всегда только времянкой пользовался, вот и подумал, может у меня неправильный подход к разработке проектов на ПЛИС?

<{POST_SNAPBACK}>

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

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

[Vjacheslav 0]

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

У меня ситуация чаще всего именно такая - поэтому наплевал давно на функциональное - тем более уже давно не делаю ошибок в функции (как правило - тьфу ....).

[BSV 0]

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

А так можно еще выявить, в каком месте получается 2+2=35.

<{POST_SNAPBACK}>

 

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

[popeye 0]

Уважаемые гуру, проясните, пожалуйста, вот такой вопрос. Если у меня выполняются все временные ограничения на рабочую частоту, то какая разница, сработает ли логика между парой регистров за 50 пс до очередного фронта клока или за 5 нс до него? И для чего тогда вообще временное моделирование?

P.S. Я всегда использовал функциональное моделирование и данные временного анализатора после компиляции проекта, а времена предустановки и clock-to-out, по-моему, надо учитывать отдельно (вместе с времянкой внешних устройств).

[3.14 0]

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

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