Начинаем FPGA на Python

Технология FPGA (ПЛИС) в настоящее время обретает большую популярность. Растёт количество сфер применения: помимо обработки цифровых сигналов, FPGA используются для ускорения машинного обучения, в blockchain технологиях, обработке видео и в IoT.

Данная технология имеет один существенный минус: для программирования используются довольно сложные и специфичные языки описания цифровой аппаратуры Verilog и VHDL. Это осложняет вхождение новичка в FPGA и для работодателя найти специалиста с этими специфичными знаниями на рынке труда сложно. С другой стороны популярный высокоуровневый язык программирования Python с фреймворком MyHDL делают программирование FPGA простым и приятным. Тем более людей знающих Python на порядок больше специалистов владеющих Verilog/VHDL. Серией статей я хочу показать как легко и просто войти в область FPGA зная Python и начать делать настоящие сложные FPGA проекты на этом языке. Отмечу, что на ПЛИС python непосредственно не исполняется, а является инструментом для генерации прошивки.

Во первых нам понадобится сам python версии 3.6 (здесь и далее все операции производятся в ОС Ubuntu 18.04).

Устанавливаем myhdl:

pip3 install myhdl

В качестве «Hello World!» Напишем простую программу, которая заставляет загораться светодиоды от нажатия на кнопку. В мире микропроцессоров «Hello World!» это программа, которая мигает одним светодиодом, в мире FPGA Hello World — это мигание тысячи светодиодов. На плате есть только четыре светодиода, так что мигать будем только ими в зависимости от нажатия кнопки. Важно отметить, что весь код в FPGA в отличие от микроконтроллеров выполняется одновременно, все диоды зажигаются и гаснут одновременно. А не последовательно в случае микроконтроллеров. В роли подопытного используется плата WaveShare OpenEPM1270 с плис Altera Max II EPM1270T144C5 на борту.



Создаём новый python файл:

from myhdl import *
from random import randrange
def led_blinker(input1, led1, led2, led3, led4):
    @always_comb
    def on_off_led():
        if input1 == 1:
            led1.next = 1
            led2.next = 1
            led3.next = 0
            led4.next = 0
        else:
            led1.next = 0
            led2.next = 0
            led3.next = 1
            led4.next = 1
    return on_off_led

Чтобы узнать правильно ли работает наш код нужно средство верификации. По сути любая программа для FPGA это обработчик цифровых сигналов, соответственно разработчику необходимо убедиться что он правильно указал что делать микросхеме. Делается это через симуляцию, для этого нужно установить программу которая будет отображать обработанные сигналы. Таких программ довольно много, но на мой взгляд самая лучшая на данным момент бесплатная GTKWave. Ставится из терминала:

sudo apt-get install gtkwave

Далее в файле с прошивкой следует описать тестовое окружение. Это тоже питоновская функция:

def test():
    input1, led1, led2, led3, led4 = [Signal(bool(0)) for i in range(5)]
    test = led_blinker(input1, led1, led2, led3, led4)
    @always(delay(10))
    def gen():
        input1.next = randrange(2)
return test, gen

Здесь тестовое окружение генерирует случайную последовательность из нулей и единиц (используется питоновский модуль random).

def simulate(timesteps):
    tb = traceSignals(test)
    sim = Simulation(tb)
    sim.run(timesteps)

И инициализируем симулятор, протаскивая туда функцию окружения test_inverter. Таким образом получается матрёшка inverter → test_inverter → simulate(время в условных единицах).

После запуска скрипта в рабочей папке создаться .vcd файл и его следует пропустить через gtkwave, в терминале: gtkwave test_invereter.vcd.



В итоге сгенерировалась случайная последовательность входных сигналов input1, и то как обработала эти сигналы функция led_blinker.

После того как мы убедились, что логика отработал ровно так как мы хотели, далее следует эту функцию закинуть в FPGA. Я привык работать с микросхемами фирмы Intel (ранее Altera), данная последовательность действий аналогична и для микросхем других производителей с соответствующими САПР. На микросхему ПЛИС заливается бинарный файл, который создаёт компилятор производителя микросхемы, для Intel это Quartus, для Xilinx Vivado. Компиляторы умеют работать только с кодом в VHDL/Verilog, поэтому питоновский код следует транслировать в любой из этих языков (не принципиально в какой).

def convert():
    input1, led1, led2, led3, led4 = [Signal(bool(0)) for i in range(5)]
    toVerilog(led_blinker, input1, led1, led2, led3, led4)
convert()

В этом примере код транслируется в Verilog. Результат в файле led_blinker.v, его и надо будет дать Quartus для генерации прошивки FPGA:

module led_blinker (
    input1,
    led1,
    led2,
    led3,
    led4
);

input input1;
output led1;
reg led1;
output led2;
reg led2;
output led3;
reg led3;
output led4;
reg led4;

always @(input1) begin: LED_BLINKER_ON_OFF_LED
    if ((input1 == 1)) begin
        led1 = 1;
        led2 = 1;
        led3 = 0;
        led4 = 0;
    end
    else begin
        led1 = 0;
        led2 = 0;
        led3 = 1;
        led4 = 1;
    end
end
endmodule

В данном подходе к разработке прошивок ПЛИС на этот файл можно не обращать внимания и просто закидывать его в Quartus.

Скачать Quartus можно с сайта fpgasoftware.intel.com, нужна бесплатная версия Lite, её нам будет достаточно. Качаем базовую версию размер 9 GB.

Установка Quartus не должна вызвать сложностей для обычного пользователя Linux. После установки необходимо задать некоторые параметры в системе, чтобы можно было пользоваться устройством для зашивки программы ПЛИС — программатором:

1. Создаем udev правило. Для этого создаем новый файл /etc/udev/rules.d/51-altera-usb-blaster.rules со следующим с содержанием:


# USB-Blaster
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6002", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6003", MODE="0666"
# USB-Blaster II
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6010", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6810", MODE="0666"

Перезагружаем udev, используя udevadm:

sudo udevadm control --reload

2. Разрешаем non-root доступ к устройству USB-Blaster. Для этого создаем файл /etc/udev/rules.d/altera-usb-blaster.rules со строкой:

ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="666"

Это даёт rw-rw-rw- доступ к программатору.

3. Конфигурируем jtagd. Quartus использует для работы демона jtagd, который связывет софт с устройством программатора. Копируем описание из вашей директории с Quartus:

sudo mkdir /etc/jtagd
sudo cp <Quartus install path>/quartus/linux64/pgm_parts.txt /etc/jtagd/jtagd.pgm_parts

Запускаем Quartus и создаём новый проект «File» — «New project wizard», набираем имя проекта.

Далее нажимаем Next. И в меню Add Files подключаем сгенерированный verilog файл с расширением .v. Таким образом, если verilog файл будет редактироваться из python файла то он автоматически будет подхватываться Quartus, Далее попадаем в меню выбора девайса, в нашем случае это MAX II EMP1270T144C5 и ещё пару раз next. Проект создан.

В Project Navigator заходим в меню файлов и правой кнопкой мыши задаем наш verilog файл «Set as top-level entity».

Компилируем проект. Теперь в меню «Assignments-Pin Planner» конфигурируем пины на микросхеме:



Ещё раз компилируем. Теперь всё готово к программированию: Tools-Programmer. Подключаем программатор и питание к плате, в Hardware Setup выбираем свой USB-Blaster, задаём галочки как изображено на рисунке и Start.



После того как Programmer отрапортовал Successful. Можно посмотреть результат на плате:



Заключение


В этом уроке рассмотрено как создавать рабочее окружение и первый простой проект на ПЛИС на языке программирования Python.

Рассмотрено:

  • как устанавливать:
    • myHDL;
    • GTKWave;
    • Quartus;
  • Произведена настройка программатора USB Blaster в Ubuntu;
  • Разработан проект на ПЛИС на python;
  • Произведено тестирование и верификация проекта;
  • Скомпилирован проект под ПЛИС;
  • Загружен проект на ПЛИС.
Поделиться публикацией

Похожие публикации

Комментарии 53

  • НЛО прилетело и опубликовало эту надпись здесь
      +8
      Для поиграться на первых порах (и понять, нужно ли вам это вообще), и, возможно, простецких тестов, сойдет.
      А вот как у myHDL обстоят дела со скоростью (и избыточностью) сгенерированного кода?
      По мне так, если захотелось опробовать FPGA, то лучше сразу привыкать к синтаксису VHDL и/или Verilog (а лучше SystemVerilog), если вы хотите лаконичный и производительный код, тем более что, судя по его вставкам, нет даже отличий в названии блоков логики, аля always и always_comb.
        –4
        Особых отличий по скорости я не заметил на более-менее крупных проектах. Плюсы python вылезут когда придётся писать сложное тестовое окружение для верификации проекта.
          –3
          Если будет возможность, проверьте мигание светодиодом в цикле из Python и напрямую из Verilog — какая разница в скорости будет? Просто в Python overhead гигантский бывает, и некоторые вещи в нем реально медленные, да и память жрут (sys.sizeof(1) = 28 к примеру — 28 байт на один Int! хотя я понимаю что это объект и все такое, но в FPGA памяти-то не так много).

          И кстати, какие функции питона 3,6 поддерживаются, все или только ограниченное множество? Можно например numpy запустить?
            +3

            Программа на Python не исполняется напрямую на ПЛИС, это просто кодогенератор, который выдаёт код на Verilog. Поэтому особенности языка никак не сказываются на, собственно исполнении. И, к сожалению, по этой же причине библиотеки для Python тоже использовать не получится.

              0
              Так и интересно, какое качество этой кодогенерации в плане скорости.

              Что транслируется в Verilog — исходный текст python-программы, или уже байт-код питона?
                +5
                Вы, видимо, совсем не понимаете как устроены ПЛИС. В них никакой код не выполняется. В них на уровне триггеров и логических элементов реализуется нужная вам схема, при этом никакой памяти не используется. Т.е. если вам надо с частотой 1Гц поморгать светодиодом, то внутри будет сформирован счетчик строго на необходимое количество разрядов и некая логическая схема декодера которая при одном значении счетчика будет зажигать светодиод, при другом гасить. Термин быстродействие тут вообще не применим. Хотя вопрос эффективности структур сформированных с MyHDL интересен.
                  +1
                  Спасибо. Если на ПЛИС уже и линукс запускают, то может кто-то и интерпретатор Питона сделал, почему бы нет. Собственно интерес как раз в том, имеем мы полностью полноценный Python или просто какое-то урезанное подмножество языка (типа Micropython для ESP32), пригодное только для самых простых операций.

                  Про моргание светодиодом пример был неудачный, да. Переформулирую вопрос, вот написали мы какую-то функцию, например, перемножения матриц — одну на Verilog, другую на этом Python, какая будет разница в их быстродействии?

                  А в целом, если для FPGA появился полноценный Python — то это реально круто, и действительно снижает порог входа в разы (уж больно лениво этот Verilog изучать, вещь совсем узкоспециализированная). Если Python сильно урезанный, то конечно не так интересно, хотя все лучше чем ничего.
                    +2
                    На ПЛИСе можно без проблем собрать какой-нибудь простой микропроцессор или использовать более дорогую ПЛИС со встроенным аппаратным ARMом. А на нем, пожалуйста, можно Linux или RTOS поднять без проблем, но это из пушки по воробьям, проще одноплатник взять типа RPi. А если говорить о чисто аппаратной реализации функций ЦОС, то можно сделать хоть за один так частоты работы ПЛИС, но это займет очень большой процент логики и не будет работать на больших частотах, а можно разбить на много тактов — сделать конвейер. Вообще почти во всех ПЛИСах есть встроенные аппаратные блоки ускоряющие такие операции, например умножители размером 18х18. Кстати Matlab давно умеет формировать годный HDL-код для ПЛИС. Т.е. можно запилить какой-нибудь фильтр в Matlab и получить готовый код для прошивки в ПЛИС.
                  0
                  Что транслируется в Verilog — исходный текст python-программы, или уже байт-код питона?
                  Ни код, ни байт-код не транслируются в Verilog. Код для Verilog — результат исполнения программы на Python.
            +1
            Вы правильно заметили, что отличий в названий блоков по сравнению с традиционными HDL нет. За счёт этого сгенерированный код получается достаточно компактный и вполне себе человекочитаемый по сравнению с высокоуровневыми генерилками типа C-to-HDL.

            Основной плюс myHDL — как раз тесты. Поскольку он работает в экосистеме python, тесты достаточно легко организуются и запускаются. Кроме того, можно подключить множество библиотек для проверки правильности работы HDL-модели: например, в обработке сигналов пригодится numpy. Ещё есть режим ко-симуляции в случае разработки тестов на MyHDL, а кода — на verilog/systemverilog.

            Пример организации тестов на MyHDL в более-менее серьёзном проекте можно посмотреть здесь.
            +4
            А я на несколько секунд поверил, что можно перестать запускать этот монстр Quartus с его сложным гуём.
              0

              Можно, в принципе, не запускать гуй квартуса, а написать скриптик для компиляции с использованием quartus_map, quartus_fit, quartus_asm. Для этого нужно будет ещё 2 текстовых файла (.qpf и .qsf) с описанием проекта, ну и сами исходники на HDL (verilog/vhdl). Если проект простой, без использования мегакорок, то можно всё проделать в текстовом редакторе, но это для настоящих джедаев командной строки.

                0

                В своё время делал интеграцию кодблокса с квартусом: писал код, ситезировал и заливал чип в C::B, а квартус запускал только для конфигурирование проекта.
                http://we.easyelectronics.ru/CADSoft/integraciya-ide-codeblocks-s-programmnym-kompleksom-altera-quartus-ii-chast-i.html

                –1
                Можно чайниковский вопрос?
                Еще давно, когда узнал про FPGA сразу возникла мысль, что надо заставить его решать системы линейных уравнений. Но я так понимаю, что дело упирается в количество входов-выходов. Чтобы было интересно — надо загружать сразу много данных, а входов-выходов всего лишь порядка тысячи.
                Нашел несколько работ по решению СЛАУ на FPGA, пишут — ускорение есть — по сравнению с софтовым решателем, но как-то в массе использования не видно. Ну и да — есть CUDA, суперкомпьютеры, и т.п… Но вот FPGA тоже хочется.
                  0
                  Данные можно загружать и по последовательной шине. Тогда много входов не надо. Но математикой придётся обойтись целочисленной.
                    0
                    Но математикой придётся обойтись целочисленной.

                    Python прекрасно работает с дробями. Интересно, можно ли использовать питоновские функции при его конвертации в Verilog/VHDL.
                      0
                      Нашёл в документации, что как бы может конвертировать питоновские функции.
                      http://docs.myhdl.org/en/stable/manual/conversion.html

                      Function calls are mapped to Verilog or VHDL subprograms
                      The converter analyzes function calls and function code. Each function is mapped to an appropriate subprogram in the target HDL: a function or task in Verilog, and a function or procedure in VHDL. In order to support the full power of Python functions, a unique subprogram is generated per Python function call.


                      гугл перевод:

                      Преобразователь анализирует вызовы функций и код функции. Каждая функция сопоставляется с соответствующей подпрограммой в целевом HDL: функция или задача в Verilog и функция или процедура в VHDL. Чтобы поддерживать всю мощь функций Python, для каждого вызова функции Python генерируется уникальная подпрограмма.


                      Так что системы линейных уравнений в FPGA с решением и ответом в виде дробей вполне даже привлекательно.
                      0
                      Как это? Т.е. имеем дело с integer и всё?
                      Поискал — нашел про плавающую точку на FPGA.
                      www.eetimes.com/document.asp?doc_id=1275350
                      вдруг кого заинтересует.
                      +1
                      Когда узнал про FPGA сразу возникла мысль, что надо заставить его решать системы линейных уравнений

                      Сейчас есть специализированные штуки типа Intel Neural Compute Stick — только не знаю, заточена она только под нейросети, или на ней можно и обычную математику считать.

                      А так да, проще на Cuda, там все довольно просто, главное придумать как распараллелить задачу.
                        0
                        Про СЛАУ надо сразу указывать, какая размерность системы вам нужна, разреженная или нет. Вообще то не стоит самому городить огород про линейные системы, профессионально написанного кода — вагон и маленькая тележка, пусть даже и для CPU.
                        +2
                        А как же chisel?
                        Вопрос, раз уж в тему
                        Есть iverilog, где можно смоделировать Verilog модель.
                        А есть ли свободные инструменты (не ModelSim) для моделирования VHDL?
                          0
                          Для симуляции VHDL есть GHDL
                            0
                            Ага. Нашёл. Малоизвестный проект. В OpenSuse не собирается:(
                          +3

                          Э… Это Python или это просто аналог Verilog/VHDL с синтаксисом Python (вместо C/Pascal)?

                            0

                            Чистый python

                              0

                              Э… "Чистый python" — в смысле, что исполняется нормальный питоновский код, и не надо въезжать в новые концепции (т.е. это с тем же успехом мог бы быть код на C или ещё каком языке общего назначения), или в смысле, что обошлись инфраструктурой питоновского интерпретатора, чтобы сделать DSL?

                                +1
                                docs.myhdl.org/en/stable/manual/preface.html:

                                Conversion to Verilog and VHDL
                                Subject to some limitations, MyHDL designs can be converted to Verilog or VHDL. This provides a path into a traditional design flow, including synthesis and implementation. The convertible subset is restricted, but much wider than the standard synthesis subset. It includes features that can be used for high level modeling and test benches.

                                The converter works on an instantiated design that has been fully elaborated. Consequently, the original design structure can be arbitrarily complex. Moreover, the conversion limitations apply only to code inside generators. Outside generators, Python’s full power can be used without compromising convertibility.

                                Finally, the converter automates a number of tasks that are hard in Verilog or VHDL directly. A notable feature is the automated handling of signed arithmetic issues.
                                  +2

                                  Для меня звучит как "вы должны разобраться в программировании fpga, тогда сможете использовать связку HDL+Python".
                                  Т.е. нет упрощения входа, есть возможность помимо новых инструментов — оставить старый и привычный. Так?

                                    +1

                                    Две подряд идущие строки в verilog/vhdl выполняется паралельно с вероятностью 99%, для последовательного выполнения нужно предпринять дополнительные меры. Все потому, что verilog/hdl по факту описывает как соединить отдельные элементы ПЛИС в цифровую схему. Так что да, лучше hdl/verilog изучать как отдельные концепции.

                            +4
                            Вы в тексте называете свой код программой, но это неправильно — для FPGA нет программы как таковой. Verilog — это язык описания аппаратуры, т.е. схемы железа, модулей, связей.
                            И в этом ключе, начинающим Python не даст понимания, как работает FPGA, разве что позволит поморгать светодиодами, не более.
                              0

                              Впринцыпе согласен с Вами. Для новичка в FPGA после классического программирования сложно осознать тонкости ПЛИС, но статья не много не об этом. Программой этот код можно назвать с натяжкой, но ведь на ПЛИС можно запрограммировать некий алгоритм обработки информации.

                                +1
                                А для новичка в классическом программировании после ПЛИС сложно осознать тонкости классического, давайте напишем генератор кода питона из верилога…
                              +1

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

                                0
                                Посмотрите еще проекты на основе migen (или nMigen)
                                  +3
                                  Стесняюсь спросить, чем приведенный вами код отличается от:

                                  module led_blinker(input input1, output led1, led2, led3, led4);

                                  always_comb begin
                                  if (input1) begin
                                  led1 =1;
                                  led2 =1;
                                  led3 =0;
                                  led4 =0;
                                  end
                                  else begin
                                  led1 =0;
                                  led2 =0;
                                  led3 =1;
                                  led4 =1;
                                  end
                                  end

                                  endmodule


                                  Явных преимуществ чистого конвертора Python -> HDL абсолютно не видно. Одно дело, когда в HDL синтезируются некие полноценные библиотеки (примером может быть PyTorch — который работает с CUDA).
                                  А другое дело, когда создается новый передаст одного языка в другой. В чем идея?

                                  Снижение избыточности кода на 5-10%? Оно того стоит?
                                  Тестовые окружения? Да SystemVerilog и сам умеет в ООП и тому подобные вещи.
                                  Поддержка стандартов Verilog/SystemVerilog? Сомневаюсь.
                                  Упрощение разработки? Вряд ли — насколько я вижу это тот же SV, только с немного адаптированным под питон синтаксисом.

                                  В общем, с уваженеим к людям, кто проделал эту работу — не совсем понятна ее область применения.
                                    0
                                    В метапрограммировании. Вы не пишете схему целиком, а шаблон или скрипт, который её породит. При этом вы можете возложить на скрипт всякую вспомогательную работу, например, у вас два разных конвейера, которые надо синхронизовать на выходе, причем длины конвейеров определяются параметрами. Ваш скрипт может рассчитать и автоматически вставить линию задержки на выходе одного из конвейеров.
                                    –1
                                    никогда с программирования высокого уровня нельзя будет нормально войти в ФПГА. этого нельзя сделать не зная схемотехники в целом и особенностей конкретных ПЛИС. максимум вот такая развлекуха со светодиодами или нечто подобное.
                                      –1

                                      ИМХО Весь смысл в том, чтобы войти в мир FPGA без знания VHDL или Verilog.
                                      Схемотехнику и особенности FPGA изучать нужно, но только чтобы получить оптимальное быстродействие и расход ресурсов.

                                        +2
                                        использование ФПГА подразумевает задачи чуть более серьезные, нежели мигание диодами. такие, с которыми не справятся и микрухи.

                                        чуть выше кто то хотел использовать плис для решения систем линейных уравнений, но не смог — не «хватило» пинов. условно «программист» хотел что то сделать на языке высокого уровня и не смог — уткнулся в банальное непонимание как можно организовать прием-хранение-коммутацию данных. ну и последующее сохранение-выдачу. он не может запрограммировать решение своей задачи на ЯВУ? конечно может. но по факту все, на что он способен без схемотехники и хдл языков — мигание диодами. НОРМАЛЬНО нормальную задачу он не решит никогда

                                        я об этом говорил, говорю и буду говорить — все попытки зайти в ФПГА с ЯВУ это вырождение инженерной школы как таковое. не понимая как работает инструмент, программист будет забивать гвозди микроскопом. забьет? забьет. только выхлоп со всего этого действия какой?
                                          0

                                          Не понимаю почему кто-то поставил минус.
                                          Но насчет ЯВУ, и даже визуальщины в FPGA вы не правы — у меня программист на MATLAB/Simulink/System Generator реализует высокоскоростные PCIe дизайны за время, недоступное VHDL/Verilogеру. При этом работает и с DDR и 1GB Ethernet и другими вещами и успешно решает все поставленные задачи, хотя за все время в проекте написал от силы 100 строк на VHDL/Verilog.

                                            +1
                                            Накидывать ядра ддров, езернетов и фильтров можно и в среде для ПЛИСов. Матлаб удобен для тестирования всего этого в режиме генерации и анализа данных для ПЛИСа.
                                              +1
                                              В Matlab/Simulink пишут алгоритмы?

                                              Да и потом, не думаю, что Ваш программист не знаком с VHDL/Verilog. Так же думаю, он задумывался над временем распространения сигнала в ПЛИС.
                                                0
                                                В Matlab/Simulink пишут алгоритмы?

                                                Да. Причем потом эти алгоритмы работают в FPGA на сотнях мегагерц.


                                                Да и потом, не думаю, что Ваш программист не знаком с VHDL/Verilog.

                                                Знаком только на уровне примерного понимания логики из чтения.


                                                Так же думаю, он задумывался над временем распространения сигнала в ПЛИС.

                                                Задумывался, но это же не связано с VHDL/VERILOG, правда? Он также знает, что такое клоки, констрейны и т.д, то есть FPGA-схемотехнику.

                                                0
                                                может я действительно выеживаюсь… индустрия как раз и идет к тому, чтобы предоставлять конечному пользователю конструктор из КОРок, из которых он может собрать готовое изделие. но при этом всем:
                                                А — за все эти корки надо платить
                                                Б — при малейшем отклонении от стандартного поведения корки все вылетает в трубу. ЯВУшник максимум напишет разработчику о проблеме и будет ждать «патча»
                                                В — вся работа по разводке, опять же, отдается на откуп компиляторам-синтезаторам. конечный результат при этом сильно страдает
                                                Г — вы зависите от чужого дяди, который завтра может вам просто не продать эту корку. а свой дядя уже либо отвык что то делать сам, либо вообще не знал что к чему

                                                может оно и хорошо что «порог вхождения» ФПГА снижается, но мне за этим всем, повторюсь, видится вырождение инженерной школы. вот от этого страшно, что становимся на путь западных партнеров, у которых нет фантазии-квалификации, но есть деньги чтобы компенсировать их отсутствие (более мощным-дорогим железом), либо же просто нанять специалиста, у которых они есть. а наши инженеры умели выжимать максимум из того что имели :)
                                                  0
                                                  Ваши инженеры это чьи? Из вашего прошлого века?
                                                    +1

                                                    Этот подход не отличается от подхода в любой другой индустрии:


                                                    • программисты используют операционные системы и библиотеки
                                                    • электронщики вместо резисторов, конденсаторов и транзисторов используют микросхемы все большей и больше степени интеграции и миниатюризации

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

                                                      –1
                                                      при этом и программист и электронщик понимает принцип работы и особенности поведения «элементарных частиц» этих больших блоков, с которыми они работают. в смысле библиотек и микросхем. хороший программист так и вообще должен знать как каждый оператор языка выполняется на железе — за сколько тактов, откуда берутся операнды, куда складываются результаты, итд итп. чтобы писать максимально функциональный, быстродействующий и наименее ресурсоемкий код. к сожалению таких специалистов сейчас очень мало даже в чистом программировании… что уже говорить о том, когда прогер лезет в сферу железа

                                                      и таки как раз наоборот — разделение труда максимально убирается. программист может стать фпга дизайнером, не вникая в суть работы плис. за счет использования готового конструктора. качество работы при этом страдает, но тут уже все зависит от конкретных задач и ресурсов — приемлимо это в данной ситуации или нет. в большинстве случаев приемлимо. и как результат — все бОльшая деградация — и так сойдет. работает же…

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

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


                                                        И назвать деградацией то, что кто-то принялся использовать PCIe корку без вычитывания 700-страничной документации я как-то не могу и не хочу.

                                            +1
                                            По данному в статье примеру создаётся впечатление, что это переписывание конструкций того же верилога с учётом специфики питона. Профит совершенно неясен.

                                            Где бы мог пригодиться питон (с подходящими тулзами) в хдлизме:
                                            — автоматизация рутинных действий типа вставления BISTов во все памяти в проекте
                                            — генерация интерконнекта модулей, создание карт IO-портов
                                            — какое-то на уровень или два более высокоуровневное проектирование/генерация кода из мелких рабочих модулей
                                            — [личный пример] генерация кода CRC :)
                                              +1
                                              извиняюсь за дурацкий вопрос мимо тостера:
                                              а почему все мигают светодиодом? какой в этом практический смысл в надстройке из пайтона без более удобной отладки схемы налету?
                                              FPGA же не для этого создана была, а для быстрой обработки больших потоков данных.
                                              Может лучше сделать такую надстройку которая хотя-бы сможет сэмулировать хотябы урезанный Printf и файловый ввод вывод?
                                              например как я сделал на чистом верилоге, с удобным и интуитивным интерфейсом схожим с printf:
                                              prnt.sc/mkf6gu
                                              для удобства отладки ибо потоки данных большие и даже в модел симе это бы считалось много часов а на плис компилируется 5 минут и выполняется менее минуты включая передачу файла по уарту.
                                              Это позволяет выводить в реалтайме любые сложные данные и даже огромные блоки данных из той же многогигабайтной ддр3 памяти (если вместо уарта подключить что побыстрее, например FT2232h)
                                              Интересно, это кого нибудь заинтересует, или всем хотелось бы мигать светодиодом?
                                                +2

                                                Мигание светодиодом — это как "Hello World" в программировании и при этом весьма простой способ показать преимущества ПЛИС перед процессорами. Примерно так:


                                                • Сначала показываем, что мы мигаем одним светодиодиком с частотой 1Гц.
                                                • Потом показываем, как мы с помощью copy-paste начинаем мигать 5 светодиодиками с разной частотой одновременно — демонстрируем параллелизм в ПЛИС
                                                • потом делаем "Вуаля" и увеличиваем частоту клока в 100000 раз и начинаем мигать светодиодиками с частотами в МГцы. Глазками уже ничего не увидишь, поэтому предлагаем посмотреть осциллографом и убедиться, что светодиоды все равно мигают и с разной частотой.
                                                  +1
                                                  Так Вы напишите про это статью.
                                                  И станет понятно:
                                                  1. Интересно это другим разработчикам или нет.
                                                  2. Удобно этим пользоваться или это решение только под Ваши, узкоспециализированные задачи.

                                                  По скриншоту с двумя строчками много понять, к сожалению, непросто.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое