Симуляция функциональная Vs временная, Мой вопрос вот в чем... Опции

[M_A]

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

[dxp]

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

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

[dxp]

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

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

[des00]

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

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

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

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

[3.14]

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

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

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

[3.14]

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

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

[dxp]

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

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

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

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

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

[popeye]

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

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

[3.14]

Как понять "Нет никакой гарантии что Вы затяните констрейнами все пути своего проекта, тем более что сделаете это правильно"? Все пути СВОЕГО проекта так трудно определить, или только избранные могут сделать это правильно?

Если их три то не сложно, а если их 20, практически не возможно не ошибиться.

"а метастабильность..." А что метастабильность? Каким образом временное моделирование поможет решить эту проблему? Надо логику проектировать так, чтобы учесть эффекты метастабильности, если они должны возникать в каких-то местах.

Только симулятор позволит проверить правильность этих "развязывающих" схем. Сами говорите "Надо логику проектировать так, ..." дык а проверить?

И как симулятор учитывает диапазон температур и тем более питания? Есть sdo-файл (я пользуюсь Verilog'ом) и post-fitting netlist, и все, или я чего-то недопонял?

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

[popeye]

Только симулятор позволит проверить правильность этих "развязывающих" схем. Сами говорите "Надо логику проектировать так, ..." дык а проверить?

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

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

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

[3.14]

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

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

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

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

[CaPpuCcino]

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

[3.14]

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

Сообщение отредактировал 3.14 - Sep 9 2005, 05:02

[des00]

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

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

[dxp]

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

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

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

[Gorby]

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

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

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

DefaultForceKind = freeze Это оно?