Записки CPU designer'a

Продолжаем новую рубрику - best practice, по мнению автора канала👍

Сегодня поговорим о способах описания процедурных блоков 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

Please open Telegram to view this post

VIEW IN TELEGRAM

👍20🤯4🐳2🌚1🍌1

www.tgoop.com/cpu_design/99

1.81K viewsJan 27, 2023 at 15:18

Продолжаем новую рубрику - best practice, по мнению автора канала👍

Сегодня поговорим о способах описания процедурных блоков 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