Comments 56
UFO just landed and posted this here
Для поиграться на первых порах (и понять, нужно ли вам это вообще), и, возможно, простецких тестов, сойдет.
А вот как у myHDL обстоят дела со скоростью (и избыточностью) сгенерированного кода?
По мне так, если захотелось опробовать FPGA, то лучше сразу привыкать к синтаксису VHDL и/или Verilog (а лучше SystemVerilog), если вы хотите лаконичный и производительный код, тем более что, судя по его вставкам, нет даже отличий в названии блоков логики, аля always и always_comb.
А вот как у myHDL обстоят дела со скоростью (и избыточностью) сгенерированного кода?
По мне так, если захотелось опробовать FPGA, то лучше сразу привыкать к синтаксису VHDL и/или Verilog (а лучше SystemVerilog), если вы хотите лаконичный и производительный код, тем более что, судя по его вставкам, нет даже отличий в названии блоков логики, аля always и always_comb.
Особых отличий по скорости я не заметил на более-менее крупных проектах. Плюсы python вылезут когда придётся писать сложное тестовое окружение для верификации проекта.
Если будет возможность, проверьте мигание светодиодом в цикле из Python и напрямую из Verilog — какая разница в скорости будет? Просто в Python overhead гигантский бывает, и некоторые вещи в нем реально медленные, да и память жрут (sys.sizeof(1) = 28 к примеру — 28 байт на один Int! хотя я понимаю что это объект и все такое, но в FPGA памяти-то не так много).
И кстати, какие функции питона 3,6 поддерживаются, все или только ограниченное множество? Можно например numpy запустить?
И кстати, какие функции питона 3,6 поддерживаются, все или только ограниченное множество? Можно например numpy запустить?
Программа на Python не исполняется напрямую на ПЛИС, это просто кодогенератор, который выдаёт код на Verilog. Поэтому особенности языка никак не сказываются на, собственно исполнении. И, к сожалению, по этой же причине библиотеки для Python тоже использовать не получится.
Так и интересно, какое качество этой кодогенерации в плане скорости.
Что транслируется в Verilog — исходный текст python-программы, или уже байт-код питона?
Что транслируется в Verilog — исходный текст python-программы, или уже байт-код питона?
Вы, видимо, совсем не понимаете как устроены ПЛИС. В них никакой код не выполняется. В них на уровне триггеров и логических элементов реализуется нужная вам схема, при этом никакой памяти не используется. Т.е. если вам надо с частотой 1Гц поморгать светодиодом, то внутри будет сформирован счетчик строго на необходимое количество разрядов и некая логическая схема декодера которая при одном значении счетчика будет зажигать светодиод, при другом гасить. Термин быстродействие тут вообще не применим. Хотя вопрос эффективности структур сформированных с MyHDL интересен.
Спасибо. Если на ПЛИС уже и линукс запускают, то может кто-то и интерпретатор Питона сделал, почему бы нет. Собственно интерес как раз в том, имеем мы полностью полноценный Python или просто какое-то урезанное подмножество языка (типа Micropython для ESP32), пригодное только для самых простых операций.
Про моргание светодиодом пример был неудачный, да. Переформулирую вопрос, вот написали мы какую-то функцию, например, перемножения матриц — одну на Verilog, другую на этом Python, какая будет разница в их быстродействии?
А в целом, если для FPGA появился полноценный Python — то это реально круто, и действительно снижает порог входа в разы (уж больно лениво этот Verilog изучать, вещь совсем узкоспециализированная). Если Python сильно урезанный, то конечно не так интересно, хотя все лучше чем ничего.
Про моргание светодиодом пример был неудачный, да. Переформулирую вопрос, вот написали мы какую-то функцию, например, перемножения матриц — одну на Verilog, другую на этом Python, какая будет разница в их быстродействии?
А в целом, если для FPGA появился полноценный Python — то это реально круто, и действительно снижает порог входа в разы (уж больно лениво этот Verilog изучать, вещь совсем узкоспециализированная). Если Python сильно урезанный, то конечно не так интересно, хотя все лучше чем ничего.
На ПЛИСе можно без проблем собрать какой-нибудь простой микропроцессор или использовать более дорогую ПЛИС со встроенным аппаратным ARMом. А на нем, пожалуйста, можно Linux или RTOS поднять без проблем, но это из пушки по воробьям, проще одноплатник взять типа RPi. А если говорить о чисто аппаратной реализации функций ЦОС, то можно сделать хоть за один так частоты работы ПЛИС, но это займет очень большой процент логики и не будет работать на больших частотах, а можно разбить на много тактов — сделать конвейер. Вообще почти во всех ПЛИСах есть встроенные аппаратные блоки ускоряющие такие операции, например умножители размером 18х18. Кстати Matlab давно умеет формировать годный HDL-код для ПЛИС. Т.е. можно запилить какой-нибудь фильтр в Matlab и получить готовый код для прошивки в ПЛИС.
Что транслируется в Verilog — исходный текст python-программы, или уже байт-код питона?
Ни код, ни байт-код не транслируются в Verilog. Код для Verilog — результат исполнения программы на Python.
Вы правильно заметили, что отличий в названий блоков по сравнению с традиционными HDL нет. За счёт этого сгенерированный код получается достаточно компактный и вполне себе человекочитаемый по сравнению с высокоуровневыми генерилками типа C-to-HDL.
Основной плюс myHDL — как раз тесты. Поскольку он работает в экосистеме python, тесты достаточно легко организуются и запускаются. Кроме того, можно подключить множество библиотек для проверки правильности работы HDL-модели: например, в обработке сигналов пригодится numpy. Ещё есть режим ко-симуляции в случае разработки тестов на MyHDL, а кода — на verilog/systemverilog.
Пример организации тестов на MyHDL в более-менее серьёзном проекте можно посмотреть здесь.
Основной плюс myHDL — как раз тесты. Поскольку он работает в экосистеме python, тесты достаточно легко организуются и запускаются. Кроме того, можно подключить множество библиотек для проверки правильности работы HDL-модели: например, в обработке сигналов пригодится numpy. Ещё есть режим ко-симуляции в случае разработки тестов на MyHDL, а кода — на verilog/systemverilog.
Пример организации тестов на MyHDL в более-менее серьёзном проекте можно посмотреть здесь.
А я на несколько секунд поверил, что можно перестать запускать этот монстр Quartus с его сложным гуём.
Можно, в принципе, не запускать гуй квартуса, а написать скриптик для компиляции с использованием 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 тоже хочется.
Еще давно, когда узнал про FPGA сразу возникла мысль, что надо заставить его решать системы линейных уравнений. Но я так понимаю, что дело упирается в количество входов-выходов. Чтобы было интересно — надо загружать сразу много данных, а входов-выходов всего лишь порядка тысячи.
Нашел несколько работ по решению СЛАУ на FPGA, пишут — ускорение есть — по сравнению с софтовым решателем, но как-то в массе использования не видно. Ну и да — есть CUDA, суперкомпьютеры, и т.п… Но вот FPGA тоже хочется.
Данные можно загружать и по последовательной шине. Тогда много входов не надо. Но математикой придётся обойтись целочисленной.
Но математикой придётся обойтись целочисленной.
Python прекрасно работает с дробями. Интересно, можно ли использовать питоновские функции при его конвертации в Verilog/VHDL.
Нашёл в документации, что как бы может конвертировать питоновские функции.
http://docs.myhdl.org/en/stable/manual/conversion.html
гугл перевод:
Так что системы линейных уравнений в FPGA с решением и ответом в виде дробей вполне даже привлекательно.
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 с решением и ответом в виде дробей вполне даже привлекательно.
Как это? Т.е. имеем дело с integer и всё?
Поискал — нашел про плавающую точку на FPGA.
www.eetimes.com/document.asp?doc_id=1275350
вдруг кого заинтересует.
Поискал — нашел про плавающую точку на FPGA.
www.eetimes.com/document.asp?doc_id=1275350
вдруг кого заинтересует.
Когда узнал про FPGA сразу возникла мысль, что надо заставить его решать системы линейных уравнений
Сейчас есть специализированные штуки типа Intel Neural Compute Stick — только не знаю, заточена она только под нейросети, или на ней можно и обычную математику считать.
А так да, проще на Cuda, там все довольно просто, главное придумать как распараллелить задачу.
Про СЛАУ надо сразу указывать, какая размерность системы вам нужна, разреженная или нет. Вообще то не стоит самому городить огород про линейные системы, профессионально написанного кода — вагон и маленькая тележка, пусть даже и для CPU.
А как же chisel?
Вопрос, раз уж в тему
Есть iverilog, где можно смоделировать Verilog модель.
А есть ли свободные инструменты (не ModelSim) для моделирования VHDL?
А есть ли свободные инструменты (не ModelSim) для моделирования VHDL?
Э… Это Python или это просто аналог Verilog/VHDL с синтаксисом Python (вместо C/Pascal)?
Чистый python
Э… "Чистый python" — в смысле, что исполняется нормальный питоновский код, и не надо въезжать в новые концепции (т.е. это с тем же успехом мог бы быть код на C или ещё каком языке общего назначения), или в смысле, что обошлись инфраструктурой питоновского интерпретатора, чтобы сделать DSL?
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.
Для меня звучит как "вы должны разобраться в программировании fpga, тогда сможете использовать связку HDL+Python".
Т.е. нет упрощения входа, есть возможность помимо новых инструментов — оставить старый и привычный. Так?
Две подряд идущие строки в verilog/vhdl выполняется паралельно с вероятностью 99%, для последовательного выполнения нужно предпринять дополнительные меры. Все потому, что verilog/hdl по факту описывает как соединить отдельные элементы ПЛИС в цифровую схему. Так что да, лучше hdl/verilog изучать как отдельные концепции.
Вы в тексте называете свой код программой, но это неправильно — для FPGA нет программы как таковой. Verilog — это язык описания аппаратуры, т.е. схемы железа, модулей, связей.
И в этом ключе, начинающим Python не даст понимания, как работает FPGA, разве что позволит поморгать светодиодами, не более.
И в этом ключе, начинающим Python не даст понимания, как работает FPGA, разве что позволит поморгать светодиодами, не более.
Неплохо было бы добавить в статью листинг VHDL для указанной программы мигания светодиодами. Тогда можно было бы сказать эффективный код или нет.
Если говорить о быстродействии, то в мире FPGA под этим подразумевается максимальная частота клока для синхронного дизайна при которой он еще выполняет заданную функцию.
Посмотрите еще проекты на основе migen (или nMigen)
Стесняюсь спросить, чем приведенный вами код отличается от:
Явных преимуществ чистого конвертора Python -> HDL абсолютно не видно. Одно дело, когда в HDL синтезируются некие полноценные библиотеки (примером может быть PyTorch — который работает с CUDA).
А другое дело, когда создается новый передаст одного языка в другой. В чем идея?
Снижение избыточности кода на 5-10%? Оно того стоит?
Тестовые окружения? Да SystemVerilog и сам умеет в ООП и тому подобные вещи.
Поддержка стандартов Verilog/SystemVerilog? Сомневаюсь.
Упрощение разработки? Вряд ли — насколько я вижу это тот же SV, только с немного адаптированным под питон синтаксисом.
В общем, с уваженеим к людям, кто проделал эту работу — не совсем понятна ее область применения.
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.
Накидывать ядра ддров, езернетов и фильтров можно и в среде для ПЛИСов. Матлаб удобен для тестирования всего этого в режиме генерации и анализа данных для ПЛИСа.
В Matlab/Simulink пишут алгоритмы?
Да и потом, не думаю, что Ваш программист не знаком с VHDL/Verilog. Так же думаю, он задумывался над временем распространения сигнала в ПЛИС.
Да и потом, не думаю, что Ваш программист не знаком с VHDL/Verilog. Так же думаю, он задумывался над временем распространения сигнала в ПЛИС.
В Matlab/Simulink пишут алгоритмы?
Да. Причем потом эти алгоритмы работают в FPGA на сотнях мегагерц.
Да и потом, не думаю, что Ваш программист не знаком с VHDL/Verilog.
Знаком только на уровне примерного понимания логики из чтения.
Так же думаю, он задумывался над временем распространения сигнала в ПЛИС.
Задумывался, но это же не связано с VHDL/VERILOG, правда? Он также знает, что такое клоки, констрейны и т.д, то есть FPGA-схемотехнику.
может я действительно выеживаюсь… индустрия как раз и идет к тому, чтобы предоставлять конечному пользователю конструктор из КОРок, из которых он может собрать готовое изделие. но при этом всем:
А — за все эти корки надо платить
Б — при малейшем отклонении от стандартного поведения корки все вылетает в трубу. ЯВУшник максимум напишет разработчику о проблеме и будет ждать «патча»
В — вся работа по разводке, опять же, отдается на откуп компиляторам-синтезаторам. конечный результат при этом сильно страдает
Г — вы зависите от чужого дяди, который завтра может вам просто не продать эту корку. а свой дядя уже либо отвык что то делать сам, либо вообще не знал что к чему
может оно и хорошо что «порог вхождения» ФПГА снижается, но мне за этим всем, повторюсь, видится вырождение инженерной школы. вот от этого страшно, что становимся на путь западных партнеров, у которых нет фантазии-квалификации, но есть деньги чтобы компенсировать их отсутствие (более мощным-дорогим железом), либо же просто нанять специалиста, у которых они есть. а наши инженеры умели выжимать максимум из того что имели :)
А — за все эти корки надо платить
Б — при малейшем отклонении от стандартного поведения корки все вылетает в трубу. ЯВУшник максимум напишет разработчику о проблеме и будет ждать «патча»
В — вся работа по разводке, опять же, отдается на откуп компиляторам-синтезаторам. конечный результат при этом сильно страдает
Г — вы зависите от чужого дяди, который завтра может вам просто не продать эту корку. а свой дядя уже либо отвык что то делать сам, либо вообще не знал что к чему
может оно и хорошо что «порог вхождения» ФПГА снижается, но мне за этим всем, повторюсь, видится вырождение инженерной школы. вот от этого страшно, что становимся на путь западных партнеров, у которых нет фантазии-квалификации, но есть деньги чтобы компенсировать их отсутствие (более мощным-дорогим железом), либо же просто нанять специалиста, у которых они есть. а наши инженеры умели выжимать максимум из того что имели :)
Ваши инженеры это чьи? Из вашего прошлого века?
Этот подход не отличается от подхода в любой другой индустрии:
- программисты используют операционные системы и библиотеки
- электронщики вместо резисторов, конденсаторов и транзисторов используют микросхемы все большей и больше степени интеграции и миниатюризации
Вырождение инженерной школы заключается лишь в том, что происходит большее разделение труда. А рынок требует все более и более сложных решений при минимальных сроках разработки. В итоге если вы будете все делать сами с нуля, то никогда ничего не разработаете.
при этом и программист и электронщик понимает принцип работы и особенности поведения «элементарных частиц» этих больших блоков, с которыми они работают. в смысле библиотек и микросхем. хороший программист так и вообще должен знать как каждый оператор языка выполняется на железе — за сколько тактов, откуда берутся операнды, куда складываются результаты, итд итп. чтобы писать максимально функциональный, быстродействующий и наименее ресурсоемкий код. к сожалению таких специалистов сейчас очень мало даже в чистом программировании… что уже говорить о том, когда прогер лезет в сферу железа
и таки как раз наоборот — разделение труда максимально убирается. программист может стать фпга дизайнером, не вникая в суть работы плис. за счет использования готового конструктора. качество работы при этом страдает, но тут уже все зависит от конкретных задач и ресурсов — приемлимо это в данной ситуации или нет. в большинстве случаев приемлимо. и как результат — все бОльшая деградация — и так сойдет. работает же…
зы
таки мы тоже используем корки, сокращая время проектирования. но мы при этом можем их оптимизировать и нещадно выпиливаем всю лишнюю лабуду, впустую жрущую ресурсы. и понимаем почему не надо заводить кнопку с пульта напрямую на логику. итд итп
и таки как раз наоборот — разделение труда максимально убирается. программист может стать фпга дизайнером, не вникая в суть работы плис. за счет использования готового конструктора. качество работы при этом страдает, но тут уже все зависит от конкретных задач и ресурсов — приемлимо это в данной ситуации или нет. в большинстве случаев приемлимо. и как результат — все бОльшая деградация — и так сойдет. работает же…
зы
таки мы тоже используем корки, сокращая время проектирования. но мы при этом можем их оптимизировать и нещадно выпиливаем всю лишнюю лабуду, впустую жрущую ресурсы. и понимаем почему не надо заводить кнопку с пульта напрямую на логику. итд итп
хороший программист так и вообще должен знать как каждый оператор языка выполняется на железе — за сколько тактов, откуда берутся операнды, куда складываются результаты, итд итп. чтобы писать максимально функциональный, быстродействующий и наименее ресурсоемкий код. к сожалению таких специалистов сейчас очень мало даже в чистом программировании… что уже говорить о том, когда прогер лезет в сферу железа
К сожалению указанные вами характеристики все более и более меркнут перед тем, что хороший программист должен писать код быстро, и код должен быть повторяемым, проверяемым, поддерживаемым, кросс-платформенным, а максимально функциональный, быстродействующий и наименее ресурсоемкий — это уже во вторую и третью очередь.
И назвать деградацией то, что кто-то принялся использовать PCIe корку без вычитывания 700-страничной документации я как-то не могу и не хочу.
По данному в статье примеру создаётся впечатление, что это переписывание конструкций того же верилога с учётом специфики питона. Профит совершенно неясен.
Где бы мог пригодиться питон (с подходящими тулзами) в хдлизме:
— автоматизация рутинных действий типа вставления BISTов во все памяти в проекте
— генерация интерконнекта модулей, создание карт IO-портов
— какое-то на уровень или два более высокоуровневное проектирование/генерация кода из мелких рабочих модулей
— [личный пример] генерация кода CRC :)
Где бы мог пригодиться питон (с подходящими тулзами) в хдлизме:
— автоматизация рутинных действий типа вставления BISTов во все памяти в проекте
— генерация интерконнекта модулей, создание карт IO-портов
— какое-то на уровень или два более высокоуровневное проектирование/генерация кода из мелких рабочих модулей
— [личный пример] генерация кода CRC :)
извиняюсь за дурацкий вопрос мимо тостера:
а почему все мигают светодиодом? какой в этом практический смысл в надстройке из пайтона без более удобной отладки схемы налету?
FPGA же не для этого создана была, а для быстрой обработки больших потоков данных.
Может лучше сделать такую надстройку которая хотя-бы сможет сэмулировать хотябы урезанный Printf и файловый ввод вывод?
например как я сделал на чистом верилоге, с удобным и интуитивным интерфейсом схожим с printf:
prnt.sc/mkf6gu
для удобства отладки ибо потоки данных большие и даже в модел симе это бы считалось много часов а на плис компилируется 5 минут и выполняется менее минуты включая передачу файла по уарту.
Это позволяет выводить в реалтайме любые сложные данные и даже огромные блоки данных из той же многогигабайтной ддр3 памяти (если вместо уарта подключить что побыстрее, например FT2232h)
Интересно, это кого нибудь заинтересует, или всем хотелось бы мигать светодиодом?
а почему все мигают светодиодом? какой в этом практический смысл в надстройке из пайтона без более удобной отладки схемы налету?
FPGA же не для этого создана была, а для быстрой обработки больших потоков данных.
Может лучше сделать такую надстройку которая хотя-бы сможет сэмулировать хотябы урезанный Printf и файловый ввод вывод?
например как я сделал на чистом верилоге, с удобным и интуитивным интерфейсом схожим с printf:
prnt.sc/mkf6gu
для удобства отладки ибо потоки данных большие и даже в модел симе это бы считалось много часов а на плис компилируется 5 минут и выполняется менее минуты включая передачу файла по уарту.
Это позволяет выводить в реалтайме любые сложные данные и даже огромные блоки данных из той же многогигабайтной ддр3 памяти (если вместо уарта подключить что побыстрее, например FT2232h)
Интересно, это кого нибудь заинтересует, или всем хотелось бы мигать светодиодом?
Мигание светодиодом — это как "Hello World" в программировании и при этом весьма простой способ показать преимущества ПЛИС перед процессорами. Примерно так:
- Сначала показываем, что мы мигаем одним светодиодиком с частотой 1Гц.
- Потом показываем, как мы с помощью copy-paste начинаем мигать 5 светодиодиками с разной частотой одновременно — демонстрируем параллелизм в ПЛИС
- потом делаем "Вуаля" и увеличиваем частоту клока в 100000 раз и начинаем мигать светодиодиками с частотами в МГцы. Глазками уже ничего не увидишь, поэтому предлагаем посмотреть осциллографом и убедиться, что светодиоды все равно мигают и с разной частотой.
Так Вы напишите про это статью.
И станет понятно:
По скриншоту с двумя строчками много понять, к сожалению, непросто.
И станет понятно:
- Интересно это другим разработчикам или нет.
- Удобно этим пользоваться или это решение только под Ваши, узкоспециализированные задачи.
По скриншоту с двумя строчками много понять, к сожалению, непросто.
Блин, нормуль! Не знал об этом, респект за ценную инфу! Для работы с СОМ-портом питонья либа есть. Теперь ещё оказывается и верилогом из него можно рулить! Осталось только сделать виджет типа gtkwave для jupyter чтобы прямо там же показывало. И можно вообще с железом работать прямо в jupyter notebook, вообще из него не выходя! За одно там же считая модели, под которые это железо разрабатывается! Пожалуй я написанием такого виджета займусь… Большой плюс за статью!
Эх, обидно, голосование уже закончилось! Плюсик не успел поставить!
Эх, обидно, голосование уже закончилось! Плюсик не успел поставить!
UFO just landed and posted this here
Собственно в gtkwave, написав тестовое окружения можно посмотреть как будет вести себя плата, более подробней про моделирование можно прочитать в моей второй статье: habr.com/ru/post/442010
Sign up to leave a comment.
Начинаем FPGA на Python