синхронизация процесса на ПЛИС

Я новичок в fpgas, и есть некоторые тонкости синхронизации, которые я не уверен, что понимаю: если все мои синхронные процессы запускаются на одном и том же фронте, то это означает, что мои входные данные «фиксируются» на одном восходящем фронте, и мой выходы меняются на .. тот же край? следующий передний край?

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

Маркер в 205 нс показывает, о чем я говорю, op и data_write - мои входные данные. Кажется, что все «просто работает» в этом тестовом примере, но в симуляции не ясно, когда именно происходит захват. Data_write = "0001 ..." записывается на 205 нс или (205 нс + 1 тактовый цикл)? Есть ли способ получить более подробные сигналы в ISim, которые показывают время установки и удержания?

Спасибо.

Всегда есть некоторая задержка распространения через триггер. Это часто называют задержкой "от часов к Q".

Это означает, что ваши входные данные фиксируются на границе, а выходные изменяются на той же границе, но всего через несколько наносекунд. Этой задержки в несколько наносекунд достаточно (если ваши триггеры спроектированы с «нулевым временем удержания», как в большинстве FPGA), чтобы изменения не повлияли ни на какие нисходящие триггеры до следующего фронта тактового сигнала.

При функциональном или RTL-моделировании (что, вероятно, вы делаете для получения результата) задержка не будет моделироваться как длительные наносекунды. В VHDL это будет один дельта-цикл часов симулятора, что технически не время вообще. Это делает невозможным увидеть задержку на выходе симулятора. Тем не менее для имитируемых как идеальных триггеров достаточно, чтобы выходные изменения не влияли на нисходящие триггеры.

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

На желаемом фронте тактового сигнала (повышающемся или понижающемся) вход на D появляется на выходе Q. Это занимает конечное время (задержка от Clock до Q), и при условии, что нет нарушений синхронизации, D будет проходить только через один FF за раз (т. е. если к Q подключен другой вход FFs, второй FF пройдет значение Q FF1, прежде чем он изменится.

Чтобы включить синхронизацию в симуляцию, вам нужно синтезировать и разместить и направить ваш дизайн, а затем запустить постпост и симуляцию маршрута. Это будет включать все комбинации, задержки от часов до Q и т. Д. Симуляция HDL не имеет ни одного из этих таймингов, поэтому она полезна только для тестирования основных операций, а не ограничений по времени. Вы также получите отчет о сроках, в котором будут указаны ограничения скорости для конкретного домена часов, сообщено, есть ли какие-либо нарушения синхронизации, и будет показан провал во времени для различных путей. Вы можете использовать эту информацию, чтобы выяснить, где, возможно, потребуется внести изменения, или добавить правила, чтобы сообщить программному обеспечению, что нарушение не является проблемой (например, для таких вещей, как многоцикловые или перекрестные такты)

Это подразумевается как дополнение к предыдущим ответам, из которых, я полагаю, вы поняли идею.

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

С правильным симулятором дельта-задержки могут быть фактически визуализированы. ISim не делает этого, но в ei ModelSim вы можете включить дельта-расширение по краям часов. Ниже приведен пример скриншота с ошибочного стороннего IP-адреса, который я исправил.

cявляется сигналом часов, и +1т. д. являются дельта-циклами, визуализированными как время.

Если проект имитируется, когда и симуляция, и проект действительно идеальны и синхронны , без имитации задержек, вы можете, в принципе, просмотреть все изменения сигнала на определенной тактовой частоте, которые происходят немного позже этой тактовой тактовой частоты. Следовательно, в вашем примере при 205 нс data_write= 0000...это то, что захватывается. Некоторые другие логики в первом блоке изменяют сигнал data_writeна 0001...на одном фланге, и кажется , что сигнал на data_writeнесколько часов после фланга. Это «немного позже» будет одной или несколькими дельтами симуляции в идеальной симуляции (ваш пример) (не видно в ISim, но, например, в ModelSim с расширением дельты), или несколько пс / нс позже в реальном мире.

Примечание: одна важная вещь в дизайне RTL состоит в том, чтобы обеспечить постоянную выборку входных данных на тактовой частоте - даже один дельта-цикл позже слишком поздно. Ввод может быть недействительным один раз позже. Или другими словами: «не связывайтесь с ходом часов».