Доброго времени суток, господа форумчане. Может подобная тема уже обсуждалась, но я честно ее не смог найти.
Вопрос заключается в правильной и гарантированной передаче сигнала между компонентами. Как мне известно, это можно делать способами, которые я привел на рисунке. data_reg_1 - этот сигнал записывается по переднему фронту и так оно работает только для функционального моделирования, в временном это будет выглядеть как data_reg_0. Второй способ - по заднему фронту или по частоте смещенной на 180....мы защелкиваем сигнал по середине data_ready. Ну и data_reg_3 защелкивается гарантированно, т.к. латч для него длится аж 3 такта...
Помогите разобраться какие подводные камни? Есть ли существенные отличия? Интересует реализация в железе...

Правильная и гарантированная передача сигналов внутри ПЛИС достигается синхронизацией всех триггеров по переднему фронту тактового сигнала.

ADA007, перехват сигнала инверсным клоком, конечно, иногда облегчает жизнь. Но чаще всего, по крайней мере, в моей практике, в итоге создаёт проблемы в комбинаторной логике при использовании вкупе с остальными сигналами, защёлкиваемыми по прямому клоку. В дизайне, ведь, одни сигналы порождают другие, одно событие проистекает из других и постепенно перестаёшь отслеживать какие-то тонкости, бывшие удобными в локальном месте. А потом долго и упорно воюешь с тем, чего вроде бы не должно было быть.
В последнее время использую такое только при острой необходимости и только применительно к внешним по отношению к ПЛИС сигналам.

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

С внешними достаточно просто - либо захватываю инверсным и зафиксированное в триггере уже перезахватываю нужным фронтом, внося задержку на 1 такт, либо и вовсе работаю на более высокой, чем у данных, частоте.
А внутри ставлю конвеер с захватом промежуточных состояний и таким поэтапным проведением на выход, либо счётчик для выдержки времени и захват уже готового по нужному такту.
Как-то делал КИХ-фильтр 20-го порядка, так там такие задержки были на перемножении отсчётов на коэффициенты, что после каждой операции приходилось ставить регистр и так до тех пор, пока эта "пирамида" из комбинаторных умножителей (встроенных там не было) и триггеров не свелась к конечному регистру результата. Фактически, был организован конвеер со скоростью 1 результат за 1 такт, но с задержкой в те самые 20 тактов. Конечно, можно было бы сделать задержку на счётчике, но при смене коэффициентов-констант менялось время выполнения, да и степень использования ресурсов меняла время выполнения. Поэтому потактовая разбивка с фиксацией промежуточного результата оказалась дубовым, но надёжным решением.