Comments 12
А я начинал с Verilog, но перешел на VHDL, поскольку он синтаксически более далек от знакомых мне программных языков. Чем сильней различаются языки - тем проще смешивать работу и переключать внимание над аппаратной и программной частями.
Ну не знаю, мне и Verilog вполне комфортно совмещать с плюсами и питоном. Но тут, конечно, каждому свое.
Я вообще паскалист и немного сишник но Verilog зашёл легче всего. При этом, я изначально ещё и инженер-схемотехник цифровых схем с более чем 20 летним стажем. И мне пришлось делать усилие на переключение своего мышления в синхронный дизайн. Это когда ты паяешь схемы из логических элементов 155й (если угодно - 74й) серии вы в 99.999% игнорируете задержки в проводах и всё у вас строго паралельно в физическом мире, есть только задержки на элемент и они нормированы. В ПЛИС же задержки в PIA соизмеримы с быстродействием самих элементов, поэтому комбинаторика там у вас может разрушиться просто от теплового нагрева во время работы. Переход на синхронные дизайн и мышление всё меняет. И дискрета работы схемы (Fmax) не всегда удовлетворяет требования. Такова плата за гибкость.
Добавлю лишь то, что когда я пишу конфигурацию то всегда смотрю RTL. И это приходит с опытом, как сказать синтезатору так, чтобы он собрал ту схему, которую я хочу. Голым программистам это сложнее, они ждут поведение не зная как оно достигается на уровне логической схемы. Схемотехник видит это сразу, например я могу понять насколько правильно работает не сильно сложный узел даже без симуляции просто смотря в RTL, экономя своё время.
Ну да, у схемотехников свои сложности при переходе, у программистов свои. Проще всего, когда особо ни в то, ни в том не разбирался😁 RTL, конечно, тоже просматриваю, но в основном беглым взглядом, подробно - только когда что-то где-то не сходится. Весь RTL проверять, это можно после каждой компиляции месяцами сидеть.
Весь RTL проверять, это можно после каждой компиляции месяцами сидеть.
С опытом приходит, что:
В уже однажды отлаженный модуль можно не заглядывать.
Какие-то [мега]функции лучше оформлять в модули, даже внутри одного *.v файла, это упрощает визуальный контроль RTL.
Когда видишь нагромождение проводов и мультиплексоров - ты явно что-то делаешь не так. В этом случае глубокий детальный анализ и не нужен.
Есть конкретный пример. Вот тут в моей статье есть код устройства на CPLD EPM7128: https://habr.com/ru/articles/896234/ В статье я специально оставил вариант кода, где все действия происходят в самом case, для наглядности читателям. А использую код, где в case только машина состояния. А действия оформлены за пределами этого case в виде условий с (FState == fsSomeState) в условиях. Это радикально сократило количество мультиплексоров (а значит утилизацию LAB и PIA). При этом синтезатор конкретно смог оптимизировать использование этих условий (выкинул очевидные дубли), которые в противном случае пришлось бы оформлять в комбинаторике как wire. Я давно понял: чем проще ты описываешь схему, тем точнее понимает тебя синтезатор. А в случае сложного описания он не просто не точно понимает, он иногда вообще не понимает что ты хочешь.
А ещё погромистам следует поломать в себе привычку думать о коде как о потоке последовательных команд. Тут это так не работает.
В уже однажды отлаженный модуль можно не заглядывать.
Чаще всего да, но он для этого должен быть отлажен и протестирован должным образом. К сожалению, в моей практике, в условиях временных ограничений, это не всегда так, и при перепаковке, при различных оптимизациях, могут, например, тайминги полететь на проверенном модуле.
Какие-то [мега]функции лучше оформлять в модули, даже внутри одного *.v файла, это упрощает визуальный контроль RTL.
Да, тоже периодически так делаю, может сделать картину красивее, главное не злоупотреблять.
Когда видишь нагромождение проводов и мультиплексоров - ты явно что-то делаешь не так. В этом случае глубокий детальный анализ и не нужен.
Ну частично спорно. В идеале, конечно, все нужно приводить к аккуратному виду, но если сроки горят, это может быть очень сложно. На наведение красоты можно потратить больше времени, чем на саму разработку.
А в целом, с подходом к модульности и простоте полностью согласен.
А я вот наоборот, пину на SpinalHDL в том числе и из-за того, что синтаксис сильно похож на C/C++. :)
Вот и мне кажется, что проще, когда имеешь дело с похожими сущностями. Про SpinalHDL, к сожалению, знаю не много, ну может когда-нибудь и до него доберусь)
Проблема похожести синтаксиса, лично для меня в том, что HDL это параллельное мышление, а те же плюсы - последовательное. И чтобы никакая усталость не могла привести к путанице, лично мне удобнее пользоваться сильно разными языками.
Я думаю, хорошо было бы добавить, что для верификации конфигураций пишется гораздо больше кода, чем для собственно синтезируемой части, которая отправляется в ПЛИС, ASIC или другую физическую реализацию.
И для верификации Verilog расширился SystemVerilog'ом с классами и множеством других средств , которые хотя и не синтезируются в регистры и логические элементы, но значительно сокращают время разработки. Значительно - это не на 5%, а в несколько раз.
М.б. те, кто много пишет на VHDL дополнят со своей стороны, но я нашёл большим преимуществом пользоваться средствами SystemVerilog для больших проектов.
Ещё в пользу Verilog - открытый бесплатный проект Icarus Verilog. Он компилирует и симулирует проекты Verilog, частично поддерживает SystemVerilog. Для удобного отображения временных диаграмм используется GTKView.
Icarus Verilog может быть полезен не только начинающим для обучения, но и в реальных проектах, потому скомпилировать и просимулировать с ним небольшой модуль бывает гораздо быстрее, чем в полноценных стмуляторах. Для какого-нибудь КИХ-фильтра удобно. И это бесплатно.
Годных альтернатив Icarus Verilog для VHDL я не знаю.
А то, что Verilog схож с C/C++ я считаю большим преимуществом. Не только проще мыслить при написании кода для ПЛИС и процессора в одном проекте. Но ещё и некоторые куски кода могут быть общими. Например, описания регистров. А это уже удобство разработки и устранение потенциальных источников ошибок.
Введение в ПЛИС: 2. Языки описания аппаратуры