Comments 56
А вот как у myHDL обстоят дела со скоростью (и избыточностью) сгенерированного кода?
По мне так, если захотелось опробовать FPGA, то лучше сразу привыкать к синтаксису VHDL и/или Verilog (а лучше SystemVerilog), если вы хотите лаконичный и производительный код, тем более что, судя по его вставкам, нет даже отличий в названии блоков логики, аля always и always_comb.
И кстати, какие функции питона 3,6 поддерживаются, все или только ограниченное множество? Можно например numpy запустить?
Программа на Python не исполняется напрямую на ПЛИС, это просто кодогенератор, который выдаёт код на Verilog. Поэтому особенности языка никак не сказываются на, собственно исполнении. И, к сожалению, по этой же причине библиотеки для Python тоже использовать не получится.
Что транслируется в Verilog — исходный текст python-программы, или уже байт-код питона?
Про моргание светодиодом пример был неудачный, да. Переформулирую вопрос, вот написали мы какую-то функцию, например, перемножения матриц — одну на Verilog, другую на этом Python, какая будет разница в их быстродействии?
А в целом, если для FPGA появился полноценный Python — то это реально круто, и действительно снижает порог входа в разы (уж больно лениво этот Verilog изучать, вещь совсем узкоспециализированная). Если Python сильно урезанный, то конечно не так интересно, хотя все лучше чем ничего.
Что транслируется в Verilog — исходный текст python-программы, или уже байт-код питона?
Ни код, ни байт-код не транслируются в Verilog. Код для Verilog — результат исполнения программы на Python.
Основной плюс myHDL — как раз тесты. Поскольку он работает в экосистеме python, тесты достаточно легко организуются и запускаются. Кроме того, можно подключить множество библиотек для проверки правильности работы HDL-модели: например, в обработке сигналов пригодится numpy. Ещё есть режим ко-симуляции в случае разработки тестов на MyHDL, а кода — на verilog/systemverilog.
Пример организации тестов на MyHDL в более-менее серьёзном проекте можно посмотреть здесь.
Можно, в принципе, не запускать гуй квартуса, а написать скриптик для компиляции с использованием quartus_map, quartus_fit, quartus_asm. Для этого нужно будет ещё 2 текстовых файла (.qpf и .qsf) с описанием проекта, ну и сами исходники на HDL (verilog/vhdl). Если проект простой, без использования мегакорок, то можно всё проделать в текстовом редакторе, но это для настоящих джедаев командной строки.
В своё время делал интеграцию кодблокса с квартусом: писал код, ситезировал и заливал чип в C::B, а квартус запускал только для конфигурирование проекта.
http://we.easyelectronics.ru/CADSoft/integraciya-ide-codeblocks-s-programmnym-kompleksom-altera-quartus-ii-chast-i.html
Еще давно, когда узнал про FPGA сразу возникла мысль, что надо заставить его решать системы линейных уравнений. Но я так понимаю, что дело упирается в количество входов-выходов. Чтобы было интересно — надо загружать сразу много данных, а входов-выходов всего лишь порядка тысячи.
Нашел несколько работ по решению СЛАУ на FPGA, пишут — ускорение есть — по сравнению с софтовым решателем, но как-то в массе использования не видно. Ну и да — есть CUDA, суперкомпьютеры, и т.п… Но вот FPGA тоже хочется.
Но математикой придётся обойтись целочисленной.
Python прекрасно работает с дробями. Интересно, можно ли использовать питоновские функции при его конвертации в Verilog/VHDL.
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 с решением и ответом в виде дробей вполне даже привлекательно.
Поискал — нашел про плавающую точку на FPGA.
www.eetimes.com/document.asp?doc_id=1275350
вдруг кого заинтересует.
Когда узнал про FPGA сразу возникла мысль, что надо заставить его решать системы линейных уравнений
Сейчас есть специализированные штуки типа Intel Neural Compute Stick — только не знаю, заточена она только под нейросети, или на ней можно и обычную математику считать.
А так да, проще на Cuda, там все довольно просто, главное придумать как распараллелить задачу.
А есть ли свободные инструменты (не ModelSim) для моделирования VHDL?
Э… Это Python или это просто аналог Verilog/VHDL с синтаксисом Python (вместо C/Pascal)?
Чистый python
Э… "Чистый python" — в смысле, что исполняется нормальный питоновский код, и не надо въезжать в новые концепции (т.е. это с тем же успехом мог бы быть код на C или ещё каком языке общего назначения), или в смысле, что обошлись инфраструктурой питоновского интерпретатора, чтобы сделать DSL?
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.
Для меня звучит как "вы должны разобраться в программировании fpga, тогда сможете использовать связку HDL+Python".
Т.е. нет упрощения входа, есть возможность помимо новых инструментов — оставить старый и привычный. Так?
Две подряд идущие строки в verilog/vhdl выполняется паралельно с вероятностью 99%, для последовательного выполнения нужно предпринять дополнительные меры. Все потому, что verilog/hdl по факту описывает как соединить отдельные элементы ПЛИС в цифровую схему. Так что да, лучше hdl/verilog изучать как отдельные концепции.
Впринцыпе согласен с Вами. Для новичка в FPGA после классического программирования сложно осознать тонкости ПЛИС, но статья не много не об этом. Программой этот код можно назвать с натяжкой, но ведь на ПЛИС можно запрограммировать некий алгоритм обработки информации.
Неплохо было бы добавить в статью листинг VHDL для указанной программы мигания светодиодами. Тогда можно было бы сказать эффективный код или нет.
Если говорить о быстродействии, то в мире FPGA под этим подразумевается максимальная частота клока для синхронного дизайна при которой он еще выполняет заданную функцию.
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, только с немного адаптированным под питон синтаксисом.
В общем, с уваженеим к людям, кто проделал эту работу — не совсем понятна ее область применения.
ИМХО Весь смысл в том, чтобы войти в мир FPGA без знания VHDL или Verilog.
Схемотехнику и особенности FPGA изучать нужно, но только чтобы получить оптимальное быстродействие и расход ресурсов.
чуть выше кто то хотел использовать плис для решения систем линейных уравнений, но не смог — не «хватило» пинов. условно «программист» хотел что то сделать на языке высокого уровня и не смог — уткнулся в банальное непонимание как можно организовать прием-хранение-коммутацию данных. ну и последующее сохранение-выдачу. он не может запрограммировать решение своей задачи на ЯВУ? конечно может. но по факту все, на что он способен без схемотехники и хдл языков — мигание диодами. НОРМАЛЬНО нормальную задачу он не решит никогда
я об этом говорил, говорю и буду говорить — все попытки зайти в ФПГА с ЯВУ это вырождение инженерной школы как таковое. не понимая как работает инструмент, программист будет забивать гвозди микроскопом. забьет? забьет. только выхлоп со всего этого действия какой?
Не понимаю почему кто-то поставил минус.
Но насчет ЯВУ, и даже визуальщины в FPGA вы не правы — у меня программист на MATLAB/Simulink/System Generator реализует высокоскоростные PCIe дизайны за время, недоступное VHDL/Verilogеру. При этом работает и с DDR и 1GB Ethernet и другими вещами и успешно решает все поставленные задачи, хотя за все время в проекте написал от силы 100 строк на VHDL/Verilog.
Да и потом, не думаю, что Ваш программист не знаком с VHDL/Verilog. Так же думаю, он задумывался над временем распространения сигнала в ПЛИС.
В Matlab/Simulink пишут алгоритмы?
Да. Причем потом эти алгоритмы работают в FPGA на сотнях мегагерц.
Да и потом, не думаю, что Ваш программист не знаком с VHDL/Verilog.
Знаком только на уровне примерного понимания логики из чтения.
Так же думаю, он задумывался над временем распространения сигнала в ПЛИС.
Задумывался, но это же не связано с VHDL/VERILOG, правда? Он также знает, что такое клоки, констрейны и т.д, то есть FPGA-схемотехнику.
А — за все эти корки надо платить
Б — при малейшем отклонении от стандартного поведения корки все вылетает в трубу. ЯВУшник максимум напишет разработчику о проблеме и будет ждать «патча»
В — вся работа по разводке, опять же, отдается на откуп компиляторам-синтезаторам. конечный результат при этом сильно страдает
Г — вы зависите от чужого дяди, который завтра может вам просто не продать эту корку. а свой дядя уже либо отвык что то делать сам, либо вообще не знал что к чему
может оно и хорошо что «порог вхождения» ФПГА снижается, но мне за этим всем, повторюсь, видится вырождение инженерной школы. вот от этого страшно, что становимся на путь западных партнеров, у которых нет фантазии-квалификации, но есть деньги чтобы компенсировать их отсутствие (более мощным-дорогим железом), либо же просто нанять специалиста, у которых они есть. а наши инженеры умели выжимать максимум из того что имели :)
Этот подход не отличается от подхода в любой другой индустрии:
- программисты используют операционные системы и библиотеки
- электронщики вместо резисторов, конденсаторов и транзисторов используют микросхемы все большей и больше степени интеграции и миниатюризации
Вырождение инженерной школы заключается лишь в том, что происходит большее разделение труда. А рынок требует все более и более сложных решений при минимальных сроках разработки. В итоге если вы будете все делать сами с нуля, то никогда ничего не разработаете.
и таки как раз наоборот — разделение труда максимально убирается. программист может стать фпга дизайнером, не вникая в суть работы плис. за счет использования готового конструктора. качество работы при этом страдает, но тут уже все зависит от конкретных задач и ресурсов — приемлимо это в данной ситуации или нет. в большинстве случаев приемлимо. и как результат — все бОльшая деградация — и так сойдет. работает же…
зы
таки мы тоже используем корки, сокращая время проектирования. но мы при этом можем их оптимизировать и нещадно выпиливаем всю лишнюю лабуду, впустую жрущую ресурсы. и понимаем почему не надо заводить кнопку с пульта напрямую на логику. итд итп
хороший программист так и вообще должен знать как каждый оператор языка выполняется на железе — за сколько тактов, откуда берутся операнды, куда складываются результаты, итд итп. чтобы писать максимально функциональный, быстродействующий и наименее ресурсоемкий код. к сожалению таких специалистов сейчас очень мало даже в чистом программировании… что уже говорить о том, когда прогер лезет в сферу железа
К сожалению указанные вами характеристики все более и более меркнут перед тем, что хороший программист должен писать код быстро, и код должен быть повторяемым, проверяемым, поддерживаемым, кросс-платформенным, а максимально функциональный, быстродействующий и наименее ресурсоемкий — это уже во вторую и третью очередь.
И назвать деградацией то, что кто-то принялся использовать PCIe корку без вычитывания 700-страничной документации я как-то не могу и не хочу.
Где бы мог пригодиться питон (с подходящими тулзами) в хдлизме:
— автоматизация рутинных действий типа вставления BISTов во все памяти в проекте
— генерация интерконнекта модулей, создание карт IO-портов
— какое-то на уровень или два более высокоуровневное проектирование/генерация кода из мелких рабочих модулей
— [личный пример] генерация кода CRC :)
а почему все мигают светодиодом? какой в этом практический смысл в надстройке из пайтона без более удобной отладки схемы налету?
FPGA же не для этого создана была, а для быстрой обработки больших потоков данных.
Может лучше сделать такую надстройку которая хотя-бы сможет сэмулировать хотябы урезанный Printf и файловый ввод вывод?
например как я сделал на чистом верилоге, с удобным и интуитивным интерфейсом схожим с printf:
prnt.sc/mkf6gu
для удобства отладки ибо потоки данных большие и даже в модел симе это бы считалось много часов а на плис компилируется 5 минут и выполняется менее минуты включая передачу файла по уарту.
Это позволяет выводить в реалтайме любые сложные данные и даже огромные блоки данных из той же многогигабайтной ддр3 памяти (если вместо уарта подключить что побыстрее, например FT2232h)
Интересно, это кого нибудь заинтересует, или всем хотелось бы мигать светодиодом?
Мигание светодиодом — это как "Hello World" в программировании и при этом весьма простой способ показать преимущества ПЛИС перед процессорами. Примерно так:
- Сначала показываем, что мы мигаем одним светодиодиком с частотой 1Гц.
- Потом показываем, как мы с помощью copy-paste начинаем мигать 5 светодиодиками с разной частотой одновременно — демонстрируем параллелизм в ПЛИС
- потом делаем "Вуаля" и увеличиваем частоту клока в 100000 раз и начинаем мигать светодиодиками с частотами в МГцы. Глазками уже ничего не увидишь, поэтому предлагаем посмотреть осциллографом и убедиться, что светодиоды все равно мигают и с разной частотой.
И станет понятно:
- Интересно это другим разработчикам или нет.
- Удобно этим пользоваться или это решение только под Ваши, узкоспециализированные задачи.
По скриншоту с двумя строчками много понять, к сожалению, непросто.
Эх, обидно, голосование уже закончилось! Плюсик не успел поставить!
Начинаем FPGA на Python