Сегодня поговорим о способах описания процедурных блоков
always_ff. Конструкция проста и понятна: фронт, список чувствительности, опиши сигналы, с которыми хочешь работать. В
always_ff, мы можем указать свойство для сигналов сброса и разрешения - синхронный/асинхронный сигнал, фронт срабатывания. Как правило, при разработке на языках Verilog/SystemVerilog, хорошим тоном считается под каждый триггер описывать отдельный блок
always, за исключением сигналов со схожим назначением, например op_a, op_b можно описать в одном always блоке.По итогу описание блока
always, в среднем, занимает 3-7 строчек. А может как-то можно сократить бездумное написание одних и тех же ключевых слов, описания одних и тех же условий?🛑Так же подумали сотрудники ETH Zurich и Болонского университета.
У pulpino есть прекрасный Common Cells Repository, где собраны различные типовые блоки. Делители clock'a, clock domain crossing, FIFO, и много другое.
Интересует нас Common register defines for RTL designs aka как описать
always_ff с синхронным сбросом и асинхронным сигналом загрузки в одну строку. Список всех дефайнов смотри в комментариях на git'e.
Почему мне нравится такой подход описания процедурных блоков:
1) единое оформление для описания триггеров — повышение читабельности кода и упрощение рефакторинга
2) соблюдение правила: 1 сигнал, 1 процедурный блок
always_ff
3) пример, как можно элегантно описывать многостадийные конвейеры через genvar
4) неявно, но соблюдаешь следующее правило — внутри тела дефайна описываешь вход в FF, выход и не запихиваешь в процедурный блок сложные комбинационные выражение, а описываешь их в других местах, например через assign или always_comb. Такой подход к описанию мне кажется максимально верным. Все как в учебниках, "облачко" комбинационной логики, триггер.Не уверен, что такой подход нужно использовать всегда и везде, но при построении сложных вычислителей, показалось удобным и наглядным.
Что думаете о таком подходе?🧐
#bestpractice