Комментарии 24
Представители фирмы Xilinx уверяют, что развитие и внедрение высокоуровневых средств — это единственная возможность в будущем вести разработку для все бОльших и бОльших чипов FPGA. Традиционные средства просто не будут справляться с этим, и вероятно, Verilog/VHDL уготована судьба ассемблера, но это в будущем.
ИМХО это неправда. Не вижу проблем использования HDL языков при создании сложных СФ-блоков. Они достаточно высокоуровневые и вполне читаемые. С наглядностью того же Verilog при соблюдении минимальной культуры написания кода вообще мало какой из современных языков может сравниться.
А вот настоящую на мой взгляд причину я слышал на какой-то конфе в США. Заключается она в том, что большим парням не нравится то что HDL-разработчиков мало, их приходится хантить и много платить. А разработчиков ПО — много, и с ними проблем нету. Пользуясь тем что FPGA ныне ломовые и особо в оптимизации по ресурсам не нуждаются — им очень нравится мысль всех HDL-разработчиков поувольнять нафиг и посадить писать плиски 3х-копеечных индусов.
И видимо в конечном итоге так все и будет. HDL останется только в компаниях, занимающихся микроэлектроникой, а со временем уйдет и оттуда.
Однако, прочитав статью, я для себя понял, что пользоваться вот этим всем нельзя. Ерунда получается. Хотят высокоуровневый язык, чтоб «не думать», но не получается: то тут галочку в настройках нужно поставить то тут снять, потом проверить в неллисте, что получилось, если получилось плохо, то переделывать… Ну и смысл в этом какой?
Никакой высокоуровневый язык не сможет автоматически поставить регистры в логических функциях так, как это бы сделал инженер. Просто потому, что в чистом языке типа C++ этой информации нет. Компилятору нужны какие-то дополнительные настройки, но лучше бы эти настройки вписывать по месту прямо в код программы (но тогда получится Verilog/VHDL).
На мой взгляд, с помощью C-подобных высокоуровневых инструментов можно с некоторой осторожностью описывать модули в которых данные двигаются только вперед.
Собственно в этой статье как раз такой пример функции r=a*b+c*d;
В принципе, если я правильно понимаю, кажется, что так думают и создатели вот этих инструментов.
Например, Khonos SPIR compiler:
Standard Portable Intermediate Representation for Parallel Compute and Graphics.
SPIR, это такой байткод, который генерируется из OpenCL программы (или из программы пиксельного шейдера для видеокарты). Программа по возможности преобразуется в форму SSA (https://en.wikipedia.org/wiki/Static_single_assignment_form)
то есть каждая переменная должна использоваться только один раз при движении данных в функции только вперед. Вот тогда каждая SSA переменная и получается регистром в FPGA.
Я даже как-то думал написать преобразователь SPIR байткода в Verilog. Думаю это не сложная задача.
Никакой высокоуровневый язык не сможет автоматически поставить регистры в логических функциях так, как это бы сделал инженер. Просто потому, что в чистом языке типа C++ этой информации нет. Компилятору нужны какие-то дополнительные настройки, но лучше бы эти настройки вписывать по месту прямо в код программы (но тогда получится Verilog/VHDL).
На мой взгляд, с помощью C-подобных высокоуровневых инструментов можно с некоторой осторожностью описывать модули в которых данные двигаются только вперед.
Собственно в этой статье как раз такой пример функции r=a*b+c*d;
В принципе, если я правильно понимаю, кажется, что так думают и создатели вот этих инструментов.
Например, Khonos SPIR compiler:
Standard Portable Intermediate Representation for Parallel Compute and Graphics.
SPIR, это такой байткод, который генерируется из OpenCL программы (или из программы пиксельного шейдера для видеокарты). Программа по возможности преобразуется в форму SSA (https://en.wikipedia.org/wiki/Static_single_assignment_form)
то есть каждая переменная должна использоваться только один раз при движении данных в функции только вперед. Вот тогда каждая SSA переменная и получается регистром в FPGA.
Я даже как-то думал написать преобразователь SPIR байткода в Verilog. Думаю это не сложная задача.
Однако, прочитав статью, я для себя понял, что пользоваться вот этим всем нельзя. Ерунда получается. Хотят высокоуровневый язык, чтоб «не думать», но не получается: то тут галочку в настройках нужно поставить то тут снять, потом проверить в неллисте, что получилось, если получилось плохо, то переделывать… Ну и смысл в этом какой?
Верификация проще, если доверять синтезу в САПРе, а также использовать стандартный интерфейс (я думаю, все поддерживают AXI), то можно верифицировать модуль на уровне матлаба или С. Что гораздо быстрее и не требует покупки Questasim/VCS. В матлабе, конечно, такая функциональность тоже дорогая (я думаю, все равно не дороже САПР от Cadence/Mentor), а вот в случае других HLS, верификация на С будет сравнительно быстрой и дешевой.
Никакой высокоуровневый язык не сможет автоматически поставить регистры в логических функциях так, как это бы сделал инженер. Просто потому, что в чистом языке типа C++ этой информации нет. Компилятору нужны какие-то дополнительные настройки, но лучше бы эти настройки вписывать по месту прямо в код программы (но тогда получится Verilog/VHDL).
На мой взгляд, с помощью C-подобных высокоуровневых инструментов можно с некоторой осторожностью описывать модули в которых данные двигаются только вперед.
Говорят, что Simulink -> System Generator -> Intel/Xilinx позволяет делать что угодно, причем моделировать можно на уровне симулинка, что опять же попроще, чем в RTL. Разбираться с настройками придется и в САПР для верилога тоже.
А зачем SPIR нужен применительно к FPGA, если Altera/Xilinx уже давно как нативно умеют в OpenCL?
С наглядностью того же Verilog при соблюдении минимальной культуры написания кода вообще мало какой из современных языков может сравниться
Штоа? В языке без пользовательских типов данных, структур, многомерных массивов в портах, параметризации наличия/отсутствия портов, с бесконечными строками инлайн-вэйверов типа «spyglass disable_block» для затыкания линтеров? Где нельзя понять ни строчки, если ты не сам их вчера написал?
Где нельзя понять ни строчки, если ты не сам их вчера написал?
Ой ли. То то я уже лет 5 ковыряю чужие открытые IP и даже правлю в них бажики.
И как-то до сих пор получалось обходиться без встроенных инструкций и многомерных массивов в портах.
Каюсь один раз мне помог бы массив — писал параметризуемый коммутатор AXI. Пришлось шины собирать в трубу [NUM*64:0] и внутри блока через Generate раскладывать по интерфейсам.
В контексте статьи к вопросу о необходимости понимания железа и понимания работы HLS при использовании таких средств интересным может оказаться чужой опыт. По ссылке диссер, где ребята реализовывали нейронную сеть (что-то вроде SqueezeNet) на ПЛИС и пытались использовать для этого HLS, во что воткнулись и как пытались это разруливать (спойлер: не разрулили).
Около 4-5 лет назад довольно активно использовал Xilinx HLS, если руку набить, то модули получались по качеству сравнимыми с аналогами, написанными на верилоге, так что инструмент вполне рабочий. Но у него, как и у решения Альтеры есть большой минус — зависимость от вендора ПЛИС, что ограничивает переиспользование кода. Опять же, я не заметил сильной экономии времени в масшабах всей разработки устройства. Да, первая версия IP блока появляется в 3 раза быстрее, но для получения производительности, сравнимой с ручным кодированием на hdl, нужно было потратить сравнимое время.
Есть хорошие инструменты, которые должны работать с разными целевыми архитектурами — такие как маршрут Simulink-System Generator-Intel/Xilinx, а также платформо-независимые среды Mentor Catapult или Cadence Stratus, но их использование пока ограничивается еще и стоимостью.
Есть хорошие инструменты, которые должны работать с разными целевыми архитектурами — такие как маршрут Simulink-System Generator-Intel/Xilinx, а также платформо-независимые среды Mentor Catapult или Cadence Stratus, но их использование пока ограничивается еще и стоимостью.
Лет пять назад пытался в матлабе синтезировать какую-то нейронную сеть (какую не помню, чисто из интереса), сначала в Си — заработало. Потом тнкнул галочку Verilog, Matlab задумался и сказал что не может синтезировать блоки экспоненты (по сути ядро нейрона).
Возможно, там надо было поиграться с настройками и тд и тп., но у меня такой задачи небыло. Потом потыкал еще примеры от матлаб, они конечно синтезировались, но без подстроек выглядили довольно топорно.
Может с той поры что-то изменилось, но как и у автора сложилось впечатление что в деле создания хайлевел инструментов для ПЛИС, еще работать и работать.
Возможно, там надо было поиграться с настройками и тд и тп., но у меня такой задачи небыло. Потом потыкал еще примеры от матлаб, они конечно синтезировались, но без подстроек выглядили довольно топорно.
Может с той поры что-то изменилось, но как и у автора сложилось впечатление что в деле создания хайлевел инструментов для ПЛИС, еще работать и работать.
с экспонентой лучше поступить так:
1. всё равно в плавающей точке на фпга вычислять очень расточительно поэтому делают квантизацию например в 16 бит и вычисляют в фикс точке, где реально экспонента будет изменяться в 8-10 битах.
2. заранее рассчитывают табличку экспоненты и в ПЛИС размещают ROM-Lookup table трансляцию X в Y согласно предварительно рассчитанной табличке экспоненты получая результат
1. всё равно в плавающей точке на фпга вычислять очень расточительно поэтому делают квантизацию например в 16 бит и вычисляют в фикс точке, где реально экспонента будет изменяться в 8-10 битах.
2. заранее рассчитывают табличку экспоненты и в ПЛИС размещают ROM-Lookup table трансляцию X в Y согласно предварительно рассчитанной табличке экспоненты получая результат
Вот тоже встречаю варианты для ПЛИС с табуляцией функций, в т.ч. сигмоида, только вместо плавающей точки всё чаще попадаются с числами с фиксированной точкой.
Спасибо за совет, если еще раз столкнусь с таким буду знать куда копать.
В своем проекте, который тогда реализовывал на плис, я и вовсе переделал весь конвеер в целочисленные вычисления получилось очень быстро и дешево (по ресурсам). А так преобразовать всю математику, где можно, в фиксируемую точку перед проектировании самой схемы, это обязательный шаг.
Только в одном месте, где нужно было делить два числа, решил заюзать плавающую точку, благо ресурсов было много и это был последний этап.
В своем проекте, который тогда реализовывал на плис, я и вовсе переделал весь конвеер в целочисленные вычисления получилось очень быстро и дешево (по ресурсам). А так преобразовать всю математику, где можно, в фиксируемую точку перед проектировании самой схемы, это обязательный шаг.
Только в одном месте, где нужно было делить два числа, решил заюзать плавающую точку, благо ресурсов было много и это был последний этап.
ИМХО автор неправильно подошел к определению высокоуровнего средства разработки под FPGA. FPGA — это логика, сигналы, схема, только зашитые в один чип. А схемы лучше не писать, их нужно рисовать. Описывая схему в C или m-коде — вы просто пытаетесь преобразовать один текст в другой. Причем ни C ни m-код никак не лучше не приспособлены для FPGA, чем VHDL/Verilog. Вариант автоматической генерации кода из m-скриптов или C был просто придуман для того, чтобы разработчики могли хоть что-то из своего запихивать в FPGA, но для новых проектов это костыли.
А вот HDL Coder/DSP System Generator в связке с Simulink дает гораздо более лучшие результаты, чем m-скрипт или C. Мало того, там все можно промоделировать и проверить работу алгоритма, не генеря код. Потому что умножитель там — это блок. Сигналы — это линии между блоками. Задержка — это задержка, регистр — регистр и т.д.
Мы уже почти 10 лет используем Simulink для программирования FPGA и код получается > достаточно эффективный при гораздо более высокой скорости разработки.
Этим я хотел подчеркнуть, что даже в таком простом примере при использования HDL-coder знания архитектуры FPGA и основ цифровой схемотехники необходимы
Тут вы правы, единственное, что подчеркну — в указанной фразе нет слов VHDL или Verilog. Т.е. знание архитектуры FPGA, основ цифровой схемотехники не означает необходимость изучения этих языков. И это важно, так как указанные вещи легко изучит любой электронщик, или схемотехник. И начнет программировать FPGA хорошо. А вот наоборот не всегда получается.
спасибо за интересный каммент, плюсую и хочу воспользоваться как поводом развязать дискуссию:
Затравка: графика конечно хорошо, и я сам бы рад был бы, получить отличный инструмент. Но есть пара нюансов, хотелось бы выяснить решены ли они:
1. Наглядность: исходный код более нагляден чем схемы. Схемы распологаются в 2д и содержат стопятьсот переходов и именованных шин куда попало, а код линеен. И опять же таки оформление в 2д на порядок сложнее чем текста, степеней свободы больше и поэтому будешь тратить просто уйму времени на именно оформление и редко когда получается хотябы терпимо, обычно это просто «блевотина из макарон»
2. Удобность: почти в любой среде разработки можно подсветить переменную или имя блока или тип блока и он подсветит, сделает анализ: сколько где и как используется, отрефакторит, переименует и тд. Это очень важно: «код который не нужно изменять — мёртвый код».
3. Отслеживание изменений: Как понять что было изменено без сравнения фото? И как понять какие были изменения? в случае 2д схемы можно чуток пораздвигать для наглядности и вроде бы не изменилось по факту (да да а бывает вроде бы казалось бы не изменилось да вот подсоединилось и во совсем не заметно при беглом просмотре тех же эл.принципиальных схем-что бесит)
4. Контроль целостности: в 2д схемах невозможно всё впихнуть на лист и часто доп параметры скрыты в менюшках и тд, ладно если ты делаешь часики, а если нейрочип на пару тыщь дсп блоков и 2 миллиона регистров это критично, стандартный кейс — возвращаешься к своему коду через год, в побочной ветке для особого заказчика и попробуй найти что именно для него было сделано кастомное.
5. Контроль сборки: во всех средах есть текстовые файлы того как куда чего будет расположено и сконфигурировано, их удобнее править, чем например тыкать в стопятьсот опций одного только пина, а пинов например тыщи… в тексте можно задать все свойства сразу группам по маске или регэкспу.
6. Командная работа: с текстом работать проще, всё равно все интерфейсы выраждаются в виде списков бит регистров параметров и тд. Камменты тоже это текст, описание действий тоже текст и тд — всё текст!
7. метапрограммирование: как делать шаблоны функций? как сделать поведенческое описание функции: задав только входы и выходы в зависимости от состояний и с условиями перехода между состояниями? Как сделать универсальный генератор например тысячи дсп блоков произвольной ширины и конфигурации? (например известно что некоторый дсп умножают биты шириной 3х99 а другие 15х7 а третьи 3х3 и их лучше в лутах реализовать и тд) Про структуры полностью определяемые входными данными я вообще молчу.
8. Как переносить текстовый код от других отделов, например математиков-теоритиков: они дадут опять таки текстовый код от питона или си или какого нибудь R. А верилог например легко реализуется на си и обратно, нужно лишь чуток механически переписать синтаксис.
9. совместимость с другими утилитами: они все на вход принимают именно текст, да тот же гитхаб, конверторы кода, и тд
И самое главное, последний гвоздь преткновения в крышку скепсиса:
10. Симуляция: я спокойно могу просимулировать всю структуру нейрочипа в сборе со скоростью миллиард умножений в секунду получив потактовую точность симуляции и срезы сигналов в нужных точках и времени. Одновременно прогнав весь валидационный датасет за адекватное время гарантировав что у меня всё работает во всех случаях побитово точно с моделю что мне дали — это единственный гарантированный способ понять ты завершил работу или нет.
Как ВСЁ это сделать графически?
(извиняюсь за резкую критику но разработка под FPGA это инженерная индустрия для больших команд, больших наборов данных и пока не решить хотя-бы большую часть этих вопросов смысла в граф редакторах я не вижу, но я рад новым знаниям и с удовольствием попробую что либо новое. Я был рад пользоваться SoC билдером от альтеры ровно до тех пор пока не разболелись глаза от пиксель хантинга (слишком много попытались впихнуть в маленький экран) и открытия стопятьсот окошек.)
Затравка: графика конечно хорошо, и я сам бы рад был бы, получить отличный инструмент. Но есть пара нюансов, хотелось бы выяснить решены ли они:
1. Наглядность: исходный код более нагляден чем схемы. Схемы распологаются в 2д и содержат стопятьсот переходов и именованных шин куда попало, а код линеен. И опять же таки оформление в 2д на порядок сложнее чем текста, степеней свободы больше и поэтому будешь тратить просто уйму времени на именно оформление и редко когда получается хотябы терпимо, обычно это просто «блевотина из макарон»
2. Удобность: почти в любой среде разработки можно подсветить переменную или имя блока или тип блока и он подсветит, сделает анализ: сколько где и как используется, отрефакторит, переименует и тд. Это очень важно: «код который не нужно изменять — мёртвый код».
3. Отслеживание изменений: Как понять что было изменено без сравнения фото? И как понять какие были изменения? в случае 2д схемы можно чуток пораздвигать для наглядности и вроде бы не изменилось по факту (да да а бывает вроде бы казалось бы не изменилось да вот подсоединилось и во совсем не заметно при беглом просмотре тех же эл.принципиальных схем-что бесит)
4. Контроль целостности: в 2д схемах невозможно всё впихнуть на лист и часто доп параметры скрыты в менюшках и тд, ладно если ты делаешь часики, а если нейрочип на пару тыщь дсп блоков и 2 миллиона регистров это критично, стандартный кейс — возвращаешься к своему коду через год, в побочной ветке для особого заказчика и попробуй найти что именно для него было сделано кастомное.
5. Контроль сборки: во всех средах есть текстовые файлы того как куда чего будет расположено и сконфигурировано, их удобнее править, чем например тыкать в стопятьсот опций одного только пина, а пинов например тыщи… в тексте можно задать все свойства сразу группам по маске или регэкспу.
6. Командная работа: с текстом работать проще, всё равно все интерфейсы выраждаются в виде списков бит регистров параметров и тд. Камменты тоже это текст, описание действий тоже текст и тд — всё текст!
7. метапрограммирование: как делать шаблоны функций? как сделать поведенческое описание функции: задав только входы и выходы в зависимости от состояний и с условиями перехода между состояниями? Как сделать универсальный генератор например тысячи дсп блоков произвольной ширины и конфигурации? (например известно что некоторый дсп умножают биты шириной 3х99 а другие 15х7 а третьи 3х3 и их лучше в лутах реализовать и тд) Про структуры полностью определяемые входными данными я вообще молчу.
8. Как переносить текстовый код от других отделов, например математиков-теоритиков: они дадут опять таки текстовый код от питона или си или какого нибудь R. А верилог например легко реализуется на си и обратно, нужно лишь чуток механически переписать синтаксис.
9. совместимость с другими утилитами: они все на вход принимают именно текст, да тот же гитхаб, конверторы кода, и тд
И самое главное, последний гвоздь преткновения в крышку скепсиса:
10. Симуляция: я спокойно могу просимулировать всю структуру нейрочипа в сборе со скоростью миллиард умножений в секунду получив потактовую точность симуляции и срезы сигналов в нужных точках и времени. Одновременно прогнав весь валидационный датасет за адекватное время гарантировав что у меня всё работает во всех случаях побитово точно с моделю что мне дали — это единственный гарантированный способ понять ты завершил работу или нет.
Как ВСЁ это сделать графически?
(извиняюсь за резкую критику но разработка под FPGA это инженерная индустрия для больших команд, больших наборов данных и пока не решить хотя-бы большую часть этих вопросов смысла в граф редакторах я не вижу, но я рад новым знаниям и с удовольствием попробую что либо новое. Я был рад пользоваться SoC билдером от альтеры ровно до тех пор пока не разболелись глаза от пиксель хантинга (слишком много попытались впихнуть в маленький экран) и открытия стопятьсот окошек.)
Воспользуюсь возможностью присоединится к дискуссии).
По поводу 2D схем, тут не всё так однозначно: предыдущий автор указывает на высокоуровневые схемы, где целые вычислительные компоненты, фильтры и прочее, они на порядки проще для понимания, чем исходный код. Что более важно, они понятны специалистам по цифровой обработке сигналов, математикам и прочим предметным специалистам, а то, что им не надо будет погружаться в VHDL/Verilog, имхо, большой плюс. В то же время, код гораздо проще, чем копание в низкоуровневых схемах RTL.
По поводу средств рефакторинга, здесь всё не так уж и радужно, например в Xilinx Vivado интелисенс появился только в версии года где-то 2017.
Имхо, графические инструменты нужны не для замены текстовых, а для их гармоничного дополнения. В Xilinx есть тулза IP Integrator, в ней можно выбирать IP-ядра из библиотеки ядер, и мышкой расставлять на экране, а затем соединять шинами, добавлять клоки, сбросы, конфигурировать адреса. Большинство ядер поддерживают интерфейс AXI. В результате, за пару кликов мыши можно сгенерить вполне себе рабочую инфраструктуру и не писать однотипный инфраструктурный код (boilerplate code), т.е. время разработки можно сократить существенно и не переизобретать велосипед в стандартных вещах, а заниматься написанием своих основных ядер, кастомной логики, которые затем легко в эту инфраструктуру интегрируются.
По поводу 2D схем, тут не всё так однозначно: предыдущий автор указывает на высокоуровневые схемы, где целые вычислительные компоненты, фильтры и прочее, они на порядки проще для понимания, чем исходный код. Что более важно, они понятны специалистам по цифровой обработке сигналов, математикам и прочим предметным специалистам, а то, что им не надо будет погружаться в VHDL/Verilog, имхо, большой плюс. В то же время, код гораздо проще, чем копание в низкоуровневых схемах RTL.
По поводу средств рефакторинга, здесь всё не так уж и радужно, например в Xilinx Vivado интелисенс появился только в версии года где-то 2017.
Имхо, графические инструменты нужны не для замены текстовых, а для их гармоничного дополнения. В Xilinx есть тулза IP Integrator, в ней можно выбирать IP-ядра из библиотеки ядер, и мышкой расставлять на экране, а затем соединять шинами, добавлять клоки, сбросы, конфигурировать адреса. Большинство ядер поддерживают интерфейс AXI. В результате, за пару кликов мыши можно сгенерить вполне себе рабочую инфраструктуру и не писать однотипный инфраструктурный код (boilerplate code), т.е. время разработки можно сократить существенно и не переизобретать велосипед в стандартных вещах, а заниматься написанием своих основных ядер, кастомной логики, которые затем легко в эту инфраструктуру интегрируются.
Что более важно, они понятны специалистам по цифровой обработке сигналов, математикам и прочим предметным специалистам, а то, что им не надо будет погружаться в VHDL/Verilog, имхо, большой плюс.
как дополнительное средство для общения с разработчиками математики и алгоритмов если его использовать полностью согласен очень хорошая штука и лучше чем голый верилог. Но надо знать меру.
В то же время, код гораздо проще, чем копание в низкоуровневых схемах RTL.
Только вот в них приходится копаться чтоб обеспечить верифицируемость, а в нашей фирме единственный способ доказать что реализация соответствует теоретической модели — полное побитовое совпадение выхода с эталонной моделью и соблюдение ТЗ — т.е. достаточно быстрая реализация, а этого добиться можно только настройкой глубже чем визуальная схема. Простейший пример: часто бывают узкие места, например один вид памяти требует 100 тактов для начала передачи пакета, а другой вид памяти например 101 тактов, при их взаимном соединении можно получить 100100 тактов ожидания, вот тут и приходится погружаться в дебри настройки визуальной среды а иногда переписывать это на верилоге
(правда сейчас визуальные среды разработки понимают смысл поточности и не требуют каждый раз декодировать адрес если пакеты идут одни за другим — получше стало, да и согласование не такое грубое делают — выходит вместо 100100 тактов всего 102 например, но раньше, лет 10 назад был ужас-ужас, падение скорости было порой просто адовое).
А насчёт совместимости с текстом: раньше когда я начинал осваивать ООП в 90ых ещё до делфи был визуальный редактор для TurboVision, вот там можно было контролы и диаграммы выделить, скопировать, вставить в код и поправить и обратно в визуальный редактор диаграм и потоков данных вставить уже с правками, потом они эту систему купили и применили в делфи — было очень удобно и наглядно, интересно, есть ли подобное сейчас, а то, то что я видел получается слабо читаемым (например на XML)
а код линеен
Без ветвлений что ли?
Вот насчет версионирования да, проблемы вырастают и при сравнениях (diff) и при совместной разработке.
нет, я про то что ветвления если и есть, то они либо снизу, либо сверху по тексту,
но не как где то там далеко-придалеко за краем экрана справа притаилась шина мелким шрифтом среди полсотни других имён и шин.
но не как где то там далеко-придалеко за краем экрана справа притаилась шина мелким шрифтом среди полсотни других имён и шин.
Но шина (графическая связь) всё же нагляднее, чем флаг, который выставляется в одном месте кода, сбрасывается где-то в другом, а читается еще в нескольких.
«далеко-далеко мелким шрифтом» — это, в принципе, одинаковая проблема что для диаграмм что для кода, и решается одинаково — правильной декомпозицией по уровням детализации. Код разбивают на модули, классы, функции — так и схема тоже разбивается на блоки и субблоки.
«далеко-далеко мелким шрифтом» — это, в принципе, одинаковая проблема что для диаграмм что для кода, и решается одинаково — правильной декомпозицией по уровням детализации. Код разбивают на модули, классы, функции — так и схема тоже разбивается на блоки и субблоки.
1. но ошибок, недоглядок и упущений при использовании 2д схем с высоким уровнем детализации всё таки существенно выше, т.е. это хороший показатель что гораздо больше людей не замечают что либо где нибудь. А детализацию не всегда можно понизить успешно — порой смысла нет от десятка блоков соединённых полусотней сигналов каждый. Порой доходит до смешного: например есть УправляющийАвтомат и сотня АЛУ узкой специализации каждый, все сигналы в итоге описываются документом и в конце концов все на диаграмму соеденений УА и АЛУ вообще забивают и начинается правка именно текстового перечня под тыщу страниц с детальным описанием сигналов в зависимости от специализации АЛУ.
Это был пример неудачной практики который я застал. Мне интересно было бы взглянуть на удачный пример.
2. Порой необходимо как то изобразить перечисления например от M экземпляров или, в зависимости от N каналов или иных факторов, как это поудачнее сделать чем например у меня получилось примерно так (слева дерево сумматоров, справа массив умножителей с накопителями — всё обычная линейная алгебра 1д и 2д КИХи но параметризируемые по количеству и ширине шины):
prntscr.com/o8vnxo
вышло вообще криво, интересно как правильно изобразить подобное, в научных статьях тоже особо не выходит хорошо отобразить подобное.
Это был пример неудачной практики который я застал. Мне интересно было бы взглянуть на удачный пример.
2. Порой необходимо как то изобразить перечисления например от M экземпляров или, в зависимости от N каналов или иных факторов, как это поудачнее сделать чем например у меня получилось примерно так (слева дерево сумматоров, справа массив умножителей с накопителями — всё обычная линейная алгебра 1д и 2д КИХи но параметризируемые по количеству и ширине шины):
prntscr.com/o8vnxo
вышло вообще криво, интересно как правильно изобразить подобное, в научных статьях тоже особо не выходит хорошо отобразить подобное.
Ой, вы как-то сильно много вопросов затронули в одном комментарии, боюсь можем потерять ветвь дискуссии очень быстро. Замечу, что я работаю в домене систем управления на основе ПЛИС в основном для силовой электроники, поэтому может быть буду некомпетентен по некоторым вопросам.
- Наглядность: исходный код более нагляден чем схемы. Схемы распологаются в 2д и содержат стопятьсот переходов и именованных шин куда попало, а код линеен. И опять же таки оформление в 2д на порядок сложнее чем текста, степеней свободы больше и поэтому будешь тратить просто уйму времени на именно оформление и редко когда получается хотябы терпимо, обычно это просто «блевотина из макарон»
Говнокод можно сделать и в коде и в 2D легко. Схемы также легко ложатся на иерархическую архитектуру, поэтому красиво оформить можно и в 2D. Еще раз хотелось бы отметить — так как из-за особенностей ПЛИС сигналы и блоки в схемах также превращаются в физические сигналы и блоки в ПЛИС, то схема очень легко читается. Ограничение по степеням свободы, наверное, на руку, так как труднее сделать неправильно.
Что еще интересно — тот же Matlab предлагает специальные инструменты, например, для рисования автоматов состояний. Это вещь, я скажу, потому, что никакой HDL код не будет нагляднее, чем диаграмма в Stateflow.
- Удобность: почти в любой среде разработки можно подсветить переменную или имя блока или тип блока и он подсветит, сделает анализ: сколько где и как используется, отрефакторит, переименует и тд. Это очень важно: «код который не нужно изменять — мёртвый код».
Это есть и в графических средах и достаточно давно.
- Отслеживание изменений: Как понять что было изменено без сравнения фото? И как понять какие были изменения? в случае 2д схемы можно чуток пораздвигать для наглядности и вроде бы не изменилось по факту (да да а бывает вроде бы казалось бы не изменилось да вот подсоединилось и во совсем не заметно при беглом просмотре тех же эл.принципиальных схем-что бесит)
Это также есть, я где-то приводил комментарий на Хабре, как это работает. Да, наверное хуже текста, но оно очень быстро совершенствуется.
- Контроль сборки: во всех средах есть текстовые файлы того как куда чего будет расположено и сконфигурировано, их удобнее править, чем например тыкать в стопятьсот опций одного только пина, а пинов например тыщи… в тексте можно задать все свойства сразу группам по маске или регэкспу.
Тут надо понимать — контроль сборки и исполняемые алгоритмы для меня это разные вещи. Конечно контроль сборки можно и нужно делать в тексте. Но во многих случаях вы настроите все для проекта один раз и будете возвращаться к этому этапу очень редко. На это будет тратиться мало времени.
- Командная работа: с текстом работать проще, всё равно все интерфейсы выраждаются в виде списков бит регистров параметров и тд. Камменты тоже это текст, описание действий тоже текст и тд — всё текст!
Я уже написал выше: в ПЛИС интерфейс — это сигналы, а сигналы — это линии и стрелки, описание действий — это вентили и регистры. Эти вещи научились рисовать задолго до текста.
- метапрограммирование: как делать шаблоны функций? как сделать поведенческое описание функции: задав только входы и выходы в зависимости от состояний и с условиями перехода между состояниями? Как сделать универсальный генератор например тысячи дсп блоков произвольной ширины и конфигурации? (например известно что некоторый дсп умножают биты шириной 3х99 а другие 15х7 а третьи 3х3 и их лучше в лутах реализовать и тд) Про структуры полностью определяемые входными данными я вообще молчу.
Помоему вы описываете IP Core Generatorы. Т.е. если вам нужен умножитель 3х99, задаете это в параметрах блока и он автоматически синтезируется. Мало того, в большинстве случаев достаточно задать типы входных сигналов, например Ufix15_7(15 бит, 7 бит после запятой) и Ufix 31_7 и генератор кода автоматически сделает нужный умножитель из DSP блоков или LUTов, как вы захотите, выбрав флажек. Может я не правильно понял, но тут нет проблемы вообще.
- Как переносить текстовый код от других отделов, например математиков-теоритиков: они дадут опять таки текстовый код от питона или си или какого нибудь R. А верилог например легко реализуется на си и обратно, нужно лишь чуток механически переписать синтаксис.
Не знаю, как у вас, но мои математики работают в Matlab/Simulink, так как моделирование. Они свои алгоритмы там месяцами гоняют прежде чем отдать на имплементацию, так как стоимость ошибки возрастает на порядки. Поэтому я получаю на входе модель с тестовыми кейсами, на которой я могу проверить все, что угодно без переписывания и создания новых багов.
- совместимость с другими утилитами: они все на вход принимают именно текст, да тот же гитхаб, конверторы кода, и тд
Не встречался с данными проблемами. Используем git. Matlab уже давно перешел на Xml.
- Симуляция
Эээ, Матлаб вообще-то на этом уже лет 20 как специализируется. Преимущество там — наличие кучи тулбоксов для нужного физического домена — например мы используем Simscape/Power Systems, чтобы проверять наши PLL и алгоритмы защиты. Для нейросетей там тоже точно что-то есть.
Верифицируемость — это именно наш конек тоже, мы моделируем побитно и поциклово без проблем, причем еще до того, как сгенерируется код. У людей возникает скепсис поначалу, как же ж так без Modelsimа и в продакшн, но когда они сами убеждаются, что код 100% покрыт тестами и работает и в симуляции и в железе, то быстро начинают доверять.
но разработка под FPGA это инженерная индустрия для больших команд, больших наборов данных
У меня три человека в отделе лабают на Virtex-7 легко. По PCIe там что-то в районе 8Гб/с трафика летает в реальном времени. Без модельно-ориентированного подхода мне надо было бы, наверное, человек 20 и раз в 5 больше времени на разработку.
PS интересно, почему shvlad — автор поста не подключился ни к одной из дискуссий?
Плюсую, сам до поры рисовал все в графике.
Но потом пришла необходимость максимально быстро найти найменьшее число во входном векторе на 128 значений. Решается задачка вообщем-то просто, строим пирамидку из компараторов и получаем результат всего за 7 (+2) тактов.
Но вот после рисований этой пирамидки и правки кучи опечаток с номерами шин, я понял что пора окончательно переходить в Verilog/VHDL где тоже самое делается в пару десят строчек c generate.
Графику использую только на верхнем уровнем типа: Video In Module — CPU Module — Screen Module с минимумом линий.
Но потом пришла необходимость максимально быстро найти найменьшее число во входном векторе на 128 значений. Решается задачка вообщем-то просто, строим пирамидку из компараторов и получаем результат всего за 7 (+2) тактов.
Но вот после рисований этой пирамидки и правки кучи опечаток с номерами шин, я понял что пора окончательно переходить в Verilog/VHDL где тоже самое делается в пару десят строчек c generate.
Графику использую только на верхнем уровнем типа: Video In Module — CPU Module — Screen Module с минимумом линий.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем под FPGA без HDL. Сравнение высокоуровневых средств разработки