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

[M_A]

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

[M_A]

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

[Andrey Filippov]

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

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

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