Как Python и Jinja могут облегчить жизнь FPGA разработчику

[@nerudo]

Я буду долго гнать велосипед(й)
type TBusMux is array (integer range <>) of std_logic_vector(D_WIDTH-1 downto 0);
signal datain: TBusMux (0 to PORT_CNT-1);

И после этого все равно говорят, что VHDL многословный и избыточный.

Если серьезно, то для верилога проще делать широоокую шину разрядностью N*D_WIDTH и дальше выбирать из нее нужную часть.

[@Wigaro]

Отличная статья. Вот только теперь надо питон учить…

[@nickpetrovsky]

Как заметил nerudo наверное всё же можно обойтись только верилогом:

Мультиплексор

module simple_mux #(
parameter D_WIDTH = 8, NUM = 2
) (
// Verilog-2001:
input wire [NUM*D_WIDTH-1:0] data_i,
// SystemVerilog:
// input wire [NUM-1:0] [D_WIDTH-1:0] data_i,
input wire [D_WIDTH-1:0] data_1_i,
input wire [$clog2(NUM)-1:0] sel_i,
output wire [D_WIDTH-1:0] data_o
);

assign data_o = data_i >> (sel_i * D_WIDTH);

endmodule

Немного доводилось работать с Verilog, но точно помню что в каком-то старом синтезаторе логарифма по основанию 2 не было, а своя реализация в виде функции, вызванная много раз, почему-то вешала всё. Второй пример про регистры мне понравился. В RTL часто приходится подработать или долго руками или разобраться в чём-то новом :).
Как-то нужно было проанализировать отчёты Place & Route для разных настроек схемы, был повод познакомится с awk ближе :)

[@ishevchuk]

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

Один из возможных вариантов обхода рассмотрен на StackOverflow. Идея рабочая, но статья не об этом :)

Конечно, пример с мультиплексором был чисто для введения, и не обязательно делать автогенерилку в таком случае.

[@Kopart]

Считаю, что использования логических и/или (&& / ||) может скрыть опечатку/ошибку, которая никак себя не проявит при компиляции, но может сказаться на результат выражения в условном операторе и на работу схемы.
А вот при использовании побитовых и/или на этапе компиляции появится ошибка и привлечет внимание.

Простой пример: изначально в if использовался и/или с однобитным типом reg/wire/logic/bit, а потом его изменили на вектор, чтобы было удобней использовать в другом месте.

[@urock]

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

[@ishevchuk]

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

Да, шаблон пишется руками, то при наличии 50-100 регистров и необходимости создания такого модуля вопрос в целесообразности отпадает)

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

Конкретно в продакшене FPGA мы питон не используем для генерации Verilog-кода, т.к.:

• используем SystemVerilog (проблем с массивами в портах нет)
• красивого разбиения на IP-ядра у нас нет и система CSR проще, чем та, которую я показывал в статье

В реальной жизни мы автогенерилку, написанную на питоне, используем для генерации Сишных функций аналогичные tse_update_mac_addr из описания регистров. Это реально снимает часть рутины, когда я выдаю разработчикам какую-то новую фичу с 20-30 регистрами.

Цель статьи:
показать, что есть связка Python + Jinja, благодаря которой можно, написав шаблон, генерить различный текст, в том числе и код на Verilog'e.
Если у кого-то встанет такая задача, и он вспомнит про мою статью — буду рад, значит не зря написал)

[@tisov]

    self.num          = '{:X}'.format( num )
    self.name         = name
    self.name_lowcase = self.name.lower()
    self.bits         = []

Ох уж эти отступы, который раз встречаю, а глаза не перестает резать.
За статью +1, спасибо

[@Kopart]

Вот не могу понять, что в этом плохого и «резкого».
Использование вертикального выравнивания улучшает читаемость кода, тк повышает структурность описания.

[@tisov]

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

[@potan]

Есть много HDL более высокоуровневых, чем Verilog и VHDL, и даже Python.
Например Bluespec.

[@ishevchuk]

Как я и писал выше, в продакшене мы используем SystemVerilog.
Пример с Verilog'ом я привёл, т.к. много разработчиков, которые сидят на Verilog'e в силу исторических причин (синтезатор, старые проекты и так далее).

Как считаете, стоит переходить с SystemVerilog на Bluespec? Какие приемущества получается?

[@potan]

По отзывам значительно повышается скорость разработки и, особенно, верификации. Но стоит слишком дорого.

[@deQU]

Статья дельная, но

соблюдайте PEP8 пожалуйста