время обработки на FPGA

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

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

ISim Скриншот

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

Спасибо.

Ответы (3)

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

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

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

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

В моделировании VHDL RTL задержка представляет собой один дельта-цикл. Это занимает ровно нулевое время, но позволяет симуляции проходить упорядоченно, поскольку все обновления в текущем дельта-цикле завершаются до начала следующего дельта-цикла. Когда больше не запланировано дельта-циклов, время может двигаться дальше.

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

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

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

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

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

Расширение дельта-задержки в ModelSim

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

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

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