Перекрывающиеся границы тактовых импульсов и данных в конструкциях с несколькими конечными автоматами

У меня есть общий вопрос о логических схемах с несколькими конечными автоматами. Подумайте о системе, имеющей несколько конечных автоматов с одним тактовым генератором и триггерами с нарастающим фронтом. Эти машины совместно используют некоторые из своих входных и выходных данных. Таким образом, выходы одних машин могут быть входами других машин.

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

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

введите описание изображения здесь

Но здесь входные данные имеют спадающий фронт на нарастающем фронте тактового сигнала. Мне это кажется проблематичным:

введите описание изображения здесь

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

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

Ответы (2)

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

Таким образом, вы в основном говорите, что, поскольку каждый вывод данных будет результатом одного и того же такта, всегда будет задержка данных, верно? На самом деле я сделал несколько симуляций в Xilinx с использованием Verilog и столкнулся с проблемой, о которой я упоминал в своем вопросе. Может быть, это произошло из-за того, что моя симуляция была сделана без добавления каких-либо задержек, а симуляция рассматривала все вентили идеально с нулевой задержкой?
Правильная задержка 0 от часов до ввода данных на следующий флоп никогда не происходит. Раньше я разрабатывал ASIC, и много времени и усилий уходит на то, чтобы все часы менялись одновременно и чтобы была достаточная задержка между триггерами. Если вы делаете это в FPGA или подобном, я уверен, что об этом позаботились, и вам не следует об этом беспокоиться.
@packt Если вам интересно, процесс, подтверждающий, что это так, называется статическим временным анализом. Все потоки проектирования ПЛИС имеют редактор временных ограничений, который сообщает инструменту автотрассировки, чего ему нужно достичь, и некоторый инструмент анализа временных параметров для проверки отсутствия нарушений настройки (тактовый фронт поступает раньше, чем данные).
OP, где @RoyC говорит, что для FPGA «об этом позаботились», способ, которым это делается, заключается в том, что триггеры в FPGA спроектированы так, чтобы иметь «нулевое время удержания» (вы можете найти это в Google для получения дополнительной информации) .
Спасибо, ребята, не был уверен в потоке FPGA, который Synopsys использовал, чтобы позаботиться об этом для нас.
На самом деле я моделирую дизайн, который позже собираюсь сделать небольшим проектом. Так что он не будет построен на fpga, но, тем не менее, я думаю, что понял суть. Мои коды Verilog не имели задержки, поэтому в симуляции ребра совпадали точно друг с другом. Это создало некоторые неожиданные результаты. Но добавление даже очень небольшой задержки на выходах, которая более корректно отображает реальные вентили, решило проблему. Спасибо вам всем.

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

Глядя на симуляционные формы сигналов, имейте в виду, что все сигналы, которые выглядят так, как будто они возникают одновременно с изменением часов, на самом деле меняются (по крайней мере) немного позже. По крайней мере, они должны. На самом деле у Verilog есть проблемы с условиями гонки , которые могут вызвать проблемы при моделировании. И у меня были проблемы с симуляцией в VHDL при стробировании часов, извлечении одних часов из других или назначении часов в/из массива или записи.

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

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

Перекрывающиеся границы тактовых импульсов и данных в конструкциях с несколькими конечными автоматами
СпросиСетьПолитика конфиденциальности1y, 0v