Рискну затронуть такую холиварную тему: сравнение двух методов разработки, графический ввод схемы и текстовое описание проекта на языках HDL Verilog / VHDL.
Какой метод лучше?
Сразу скажу, что я сторонник текстового ввода, так что наверняка моя заметка может выглядеть предвзятой. Тем не менее, вот еще важные замечания по теме:
- проект может быть выполнен хорошо и продуманно не зависимо от того, какой метод использовался, точно так же плохой дизайн можно сделать и с использованием схемотехнического представления и при описании на Verilog / VHDL. То есть, качество проекта скорее зависит от квалификации программиста, чем от выбранного инструмента (хотя у программиста могут быть свои предпочтения и специфический опыт работы со средой проектирования).
- не зависимо от представления проекта в виде HDL текста или схемы, компилятор (теоретически) должен и обязан синтезировать одинаково оптимальный образ для прошивки в ПЛИС. В любом случае компилятор будет оптимизировать комбинационную логику, удалять неиспользуемые элементы, триггера, синтезировать и оптимизировать netlist.
Теперь все таки давайте рассмотрим недостатки и преимущества методов разработки в схеме или в текстовом виде.
Условно можно выделить несколько взаимосвязанных критериев для оценки метода разработки цифровых проектов для ПЛИС и ASIC: удобство, скорость разработки, представление, портируемость, управляемость кода, надежность.
Удобство.
Удобство рисования схем в графическом редакторе определяется исключительно его свойствами. Например, разрабатывая в среде Altera Quartus II мы можем пользоваться только его графическим редактором. Хорош он или плох - выбора нет, он такой как есть, со всеми его плюсами или минусами. Даже если там есть баги или странности - смиритесь. Вы не можете использовать другой редактор схем, так как Quartus II использует свой специфический формат для записи файлов типа *.bdf (block design file). Да, сам *.bdf - это текстовый файл, но его уж точно не получится руками редактировать, там уж слишком все внутри непонятно. Получается, для своих графических файлов компания Altera - монополист и она, как любой монополист, может позволить себе выпустить не очень удобный редактор.
Почему я считаю его неудобным? Ну, скажем так, он мог бы быть и получше. Если посмотреть на другие CAD системы (PCAD, AUTOCAD) или даже не только CADы, а, например, всякие 3D редакторы (BLENDER, 3DMax), то можно увидеть несколько иную картину. Интересно, что удобство работы с графическими системами обычно достигается путем использования... строки для текстовых команд. Получается, чем меньше дизайнер использует мышь и чем чаще пользуется командным вводом для манипуляции графическими объектами на экране, тем быстрее у него спорится работа.
Ну вот в среде Quartus II для рисования схем нет такой возможности. Если нужно добавить новый компонент на схему, то приходится выполнять последовательность действий типа "правый клик мыши" => выбор в меню Insert => Symbol => далее в диалоговом окне выбор по списку библиотечного примитива => установка его на схему. Потом еще иногда требуется отредактировать свойства выбранного элемента, а это опять мышь, диалоговые окна и потом, после многочасовой работы с мышью - болезнь кисти руки, "тунельный синдром".
Сколько движений мышью и сколько кликов нужно сделать, чтобы добавить новый элемент в схему в среде Altera Quartus II?
С другой стороны, любой текстовый редактор всегда проще графической среды. Для редактирования текста Verilog / VHDL можно пользоваться встроенным в Altera Quartus II текстовым редактором или просто программой "Блокнот" Windows. Может понадобиться подсветка синтаксиса (выделение ключевых слов if-else, begin-end другим цветом), но она есть во многих редакторах, например, даже в простом notepad++.
Возможно, что сама Altera, понимая, что текстовый ввод продуктивнее, не уделяет внимания совершенствованию своего графического редактора.
Или вот еще аргумент против графики. Если человек привык к схемотехническому вводу в среде Altera Quartus II, то как быстро он сможет переучиться на другую среду проектирования, например, Xilinx ISE? С текстовым вводом все понятно, а как быть с графическим?
Скорость разработки.
Конечно, скорость разработки тесно связана с удобством среды проектирования (смотри пункт первый).
Обычно люди, которые рисуют схемы говорят, что скорость ввода их не волнует, потому что обдумывание проекта занимает гораздо больше времени, чем его отрисовка. Наверное это так, с этим можно даже и согласиться.
На самом деле я сам часто пользуюсь графическим вводом. Часто в проекте у меня бывает графический файл самого верхнего уровня иерархии. Дальше модули, включенные в иерархию это либо Verilog, либо компоненты созданные визардом Altera типа FIFO, компонент DDR контроллера, модуль SRAM или PLL, что-то еще.. Простой проект можно и нарисовать, но вот когда он постепенно усложняется со временем редактировать его становится все сложнее и сложнее. Приходится раздвигать графические объекты, компоненты, провода, шины, чтобы вставить что-то новое. Это перемещение объектов схемы занимает довольно много времени, особенно если дизайнер имеет чувство красоты и ему нравятся схемы с выровненными по сетке элементами. Может так получиться, что вместо работы над собственно проектом человек работает над перемещением компонентов. Напечатать большой графический проект на принтере становится все труднее, формат бумаги A4 уже не подходит, нужно A2 или A1, или склеивать листы.
Кроме этого, надо заметить, что скорость разработки сильно зависит от специфики и возможностей языка программирования или среды проектирования.
И вот важный момент: все, что можно нарисовать в схеме может быть описано текстовым языком HDL, но не все, что описано на языке HDL может быть легко реализовано в схеме. Приведу некоторые примеры:
- Текстовые описания на Verilog / VHDL позволяют легко делать параметризованные модули, а значит готовые модули можно будет легко использовать в других проектах, но в другой конфигурации. Например, можно однажды описать Verilog модуль для синхрогенератора видеосигнала:
module hvsync (
// inputs:
input wire pixel_clock,
// outputs:
output reg hsync,
output reg vsync,
);
// video signal parameters, default 1440x900 60Hz
parameter horz_front_porch = 80;
parameter horz_sync = 152;
parameter horz_back_porch = 232;
parameter horz_addr_time = 1440;
parameter vert_front_porch = 3;
parameter vert_sync = 6;
parameter vert_back_porch = 25;
parameter vert_addr_time = 900;
........
Однажды написал - позже использовал в разных проектах. Нужно иметь другое разрешение на экране - меняешь не сам текст модуля, а только его входные параметры, длительность строчного, кадрового импульса и бордюров. Такое казалось бы простое действие, как создание параметризованных графических модулей невозможно в графическом редакторе Altera Quartus II.
- Еще одно важное свойство проектирование в тексте на Verilog HDL - это возможность условной компиляции проекта. Вот, например, фрагмент кода проекта Amber (ARM-совместимый процессор и система на кристалле).
// -------------------------------------------------------------
// Instantiate Amber Processor Core
// -------------------------------------------------------------
`ifdef AMBER_A25_CORE
a25_core u_amber (
`else
a23_core u_amber (
`endif
.i_clk ( sys_clk ),
.i_irq ( amber_irq ),
.i_firq ( amber_firq ),
.i_system_rdy ( system_rdy ),
.o_wb_adr ( m_wb_adr [1] ),
.o_wb_sel ( m_wb_sel [1] ),
........
В проект может быть вставлен, вкомпилирован либо 5-ти стадийный процессор (он быстрее, но занимает больше логики) либо 3-х стадийный процессор (медленней, но занимает меньше логики). И эта условная компиляция происходит в зависимости от определенного параметра AMBER_A25_CORE. Невозможно использовать условную компиляцию в схемах. Условная компиляция нужна, когда проект имеет несколько вариантов реализации, например, для разных типов ПЛИС, для однотипных проектов, для включения в проект отладочных модулей, которые в финальный продукт не включаются и так далее.
- Третий пример - использование специальных конструкций языка Verilog HDL, которые позволяют генерировать и вставлять в проект взаимосвязанные экземпляры других модулей. Например, посмотрите вот такой код на языке Verilog:
module inst_loop
(
input wire clock,
input wire in,
output wire out
);
genvar index;
generate
for (index=0; index < 4; index=index+1)
begin: fu
wire o_q;
if(index==0)
func #(index) func_inst (
.fclk(clock),
.d( in ),
.q(o_q)
);
else
func #(index) func_inst (
.fclk(clock),
.d( fu[index-1].o_q ),
.q(o_q)
);
end
endgenerate
assign out = fu[3].o_q;
endmodule
Конструкция языка generate-endgenerate позволяет устанавливать нужное число экземпляров модуля func и связывать их между собой нужным образом. При этом каждый экземпляр модуля func может еще и быть параметризованным, "знать свое место": в данном примере #(index) - это передаваемый параметр позиции модуля, и поведение модуля может зависеть от этого параметра. Приведенный выше пример делает вот такую схему:
Такой цикл может создать, например, структуру из 1000 соединенных модулей. Как нарисовать такое в схеме? Сколько времени понадобится? А вдруг нарисовал такую схему, а потом нужно добавить сигнал к модулю, что все заново исправлять-перерисовывать? Это будет трудно.
Наглядность представления.
Есть еще такой аргумент в пользу графических файлов - наглядность. Якобы человеку представлять схему и реализовывать ее как представляешь проще в графике. Что тут можно возразить? Я например представляю схему, но могу сразу описывать ее на Verilog. Вообще я считаю, что человек пишущий на Verilog / VHDL должен тут же представлять себе в голове описываемую в тексте схему - это правильно и так и должно быть.
К сожалению, должен сказать, что лично у меня очень часто возникают именно проблемы чтения схем. Вот такой пример.
Я вижу в схеме стоит стандартный компонент LPM_SHIFTREG из графической библиотеки Altera Quartus II. Кто может мне сразу сказать какой сигнал имеет больший приоритет sclr или load? Что произойдет, если они оба стали активными? Может в регистр запишутся все нули, или произойдет загрузка новых данных в сдвиговый регистр? Вот я все время забываю. Смотрю на этот компонент в схеме и не могу вспомнить, что все это значит. Наверное у меня мало опыта работы со схемами..
С верилогом проще. Нет никакой иносказательности:
reg [7:0]serial_send_reg;
always @(posedge clk)
if(sclr)
serial_send_reg <= 0;
else
if(load)
serial_send_reg <= next_data;
else
serial_send_reg <= { serial_send_reg[6:0],1'b0 };
В описании на Verilog HDL приоритеты сигналов сразу видны по тексту.
И еще. Текст программы, описание аппаратуры на Verilog HDL / VHDL как правило является самодокументированным. В тексте очень легко писать комментарии. Гораздо легче писать текстовые комментарии, чем делать пояснения на схеме. Но даже если не писать комментарии, а просто давать грамотные имена регистрам reg и сигналам wire, то текст читать довольно просто. Вот фрагмент кода выше, как можно предположить из названия регистра serial_send_reg, описывает сдвиговый регистр передатчика последовательного порта.
В схемах так же можно давать имена компонентам и проводам, но кто это делает? Это редко кто-то делает, так как это дополнительно требует кликов мыши и взаимодействия с диалоговыми окнами. По умолчанию графическая среда Quartus II каждому новому добавленному на схему компоненту автоматически дает имя типа inst33, inst34, inst35... И смотришь потом на все эти inst и угадываешь их предназначение. Короткие провода между компонентами на схемах никто не именует, а зря - это наверное помогло бы читать схему.
В общем, по поводу визуального представления проекта у меня лично нет предпочтения для схем.
Правда, нельзя сказать, что с текстовым вводом вообще все гладко. Текст можно написать запутанный, можно давать неудачные имена регистрам и проводам, можно оставить устаревший комментарий (это вообще всегда сбивает с толку), можно делать глупые опечатки или допускать ошибки форматирования, которые визуально не заметны - я однажды писал про этот тип ошибок. Статья называется Verilog Gotchas. В общем, использование текстового ввода не есть гарантия качественного проекта, хотя.. есть и еще плюсы у текстового ввода.
Портируемость и переносимость проектов.
Я думаю с этим все понятно. Если разработчик желает, чтобы его разработки могли использоваться еще где-то кроме как в его ПЛИС, то он должен использовать текстовые описания на Verilog / VHDL. Так получилось, что на сегодняшний день нет единого стандарта для файлов графического описания цифровых схем. Вот и получается, что у Альтеры свой формат графических файлов, а у Xilinx свой. А еще производители микросхем ASIC не примут графический дизайн, примут в работу только текст.
Мы для нашей платы Марсоход2 занимались портированием открытого проекта Amber с opencores - изначально он был сделан для микросхем Xilinx на языке Verilog HDL. Сейчас мы его можем компилировать для FPGA Altera Cyclone III. Если ли бы проект был в виде схем я думаю у нас не было бы никаких шансов.
Вообще визуализация схем - это целая проблема. Если вам нужно показать свой проект в виде схемы какому-то специалисту, то первое, что ему нужно сделать - установить себе среду разработки, а для начала выкачать из интернета установочный пакет размером 3-4 гигабайта. И еще неизвестно запустится или нет, если у человека стоит не очень распространенная ОС на компьютере. А если я в пути и у меня с собой только планшет iPad или Galaxy Tab? Текст еще можно посмотреть, а вот схему уже трудно.
Надежность кода.
Важная составляющая процесса разработки цифровых схем - верификация. Проще говоря - это моделирование работы проекта или его модулей. В случае с текстовыми проектами процесс тестирования выглядит так: пишется отдельная программа-тестбенч. Программа тестбенч пишется на том же языке, что и сам проект. Например, проект выполнен в Verilog. Testbench так же можно выполнить в Verilog.
Программа тестбенча рассматривает ваш готовый модуль как черный ящик, все входные сигналы для черного ящика имитируются, все выходные сигналы из исследуемого модуля мы наблюдаем и смотрим, чтобы они были такими, как задумывалось. Мы программируем воздействие к исследуемому модулю и следим за его откликом. Существует много инструментов для такой верификации. Компания Альтера поставляет вместе со своей средой проектирования Quartus II дополнительную среду ModelSim Altera - как раз для симуляции проектов Verilog / VHDL. Есть открытый проект Icarus Verilog для функциональной симуляции проектов. Я им сам часто пользуюсь - очень простой инструмент.
Интересно, что производители многих микросхем предоставляют Verilog модели своих микросхем, чтобы облегчить разработчикам отладку проектов.
Есть много хороших примеров симуляции проектов на нашем сайте. Например, мы симулировали работу системы на кристалле Amber и запуск ОС Linux в системе. Это очень сложная симуляция, она включала в себя модель памяти SDRAM, саму систему на кристалле вместе с процессором, bootrom, последовательным портом, таймером, контроллером прерываний. Во время симуляции исследуемый процессор выполняет миллионы инструкций. Понятно, что такая длительная симуляция покрывает практически все возможные внутренние состояния системы. Можно надеяться, что проект правильно работает.
Теперь посмотрим, как моделировать работу системы в случае если проект выполнен в виде схемы. К сожалению тут все печально. Так как нет единого стандарта для представления схем, то нет и инструментов для тестирования. Когда-то давно компания Альтера в среде Altera Quartus II версии 9 позволяла симулировать схемотехнические проекты. Выглядело это так - нужно было в специальном графическом редакторе нарисовать все сигналы входных воздействий к исследуемому модулю. Потом запускался симулятор и он позволял посмотреть выходные или внутренние сигналы исследуемого проекта. Честно скажу, что было не очень удобно. Что-то можно было проверить, но выполнить полный тест сложной системы практически невозможно. Я не представляю себе, как можно было бы в той среде исследовать, систему на кристалле Amber.
У нас на сайте даже когда-то был обзор симулятора из Quartus II v9. Давно это было. В более поздних версиях среды проектирования Altera исключила симулятор из состава пакета. Ну правда он был не очень удачный.
Что же делать теперь? Есть только один способ симулировать схемы в среде квартуса. Открываете файл схемы и потом в меню File => Create / Update => Create HDL Design File from Current File... В результате схема конвертируется в текстовый файл на языке Verilog или VHDL. ну а дальше, все как у людей - использование ModelSim.
Не удобно, появляется дополнительный промежуточный этап конвертации. Если многократно исправлять схему и конвертировать ее для симуляции, тогда это вообще может стать мученьем.
Управляемость кода.
Многие проекты на нашем сайте, особенно для первой платы Марсоход, являются быстрыми проектами, типа "проект выходного дня" - сделал, написал статью для сайта, забыл. Однако, если идет работа на большим сложным проектом, если работа растянута во времени и особенно, если над проектом трудится несколько человек, то обязательно нужны механизмы управления исходными текстами проекта.
Часто бывает, что какая-то нужная функция когда-то работала, а потом вдруг перестала. Отчего? Почему? Кто и когда внес исправления в проект? Как отследить изменение проекта во времени?
В программных проектах для C/C++, C#, PHP, Python и всех прочих для поддержания проекта используются сервера хранения исходных текстов. Типичный пример source-control system - это системы Subversion или GIT. Эти системы позволяют вносить изменения в код проекта и сохранять промежуточные состояния проекта. Так же возможны ветвления в проекте, слияния рабочих веток проекта в основной поток проекта и так далее. Возможно когда-то придется найти кто и когда и зачем сделал некоторое изменение, может понадобится вернуться к предыдущей версии проекта. Только использование систем контроля версий позволяет держать большой проект в порядке.
Все это, конечно, применимо и к текстовым описаниям аппаратных проектов на Verilog / VHDL.
Пример наших проектов в системе контроля версий - Amber-Marsohod2 - портирование opensource системы на присталле Amber для платы Марсоход2. Весь процесс портирования есть в открытом доступе на GitHub. И это замечательно.
При использовании текстовых файлов очень просто сравнивать разные версии одного и того же модуля. Можно просто консольной командой diff в ОС Linux. Или есть средства сравнения и слияния текстовых файлов типа Meld.
А вот скажите как сравнить две схемы: чуть более старую и чуть более новую? Мне это неизвестно. Из-за отсутствия средств сравнения графических схем использование систем контроля версий становится очень проблематичным и неудобным. Вот еще один и существенный довод против схем.
Вывод я могу сделать такой. Использование текстового ввода для описания аппаратных проектов во многих случаях предпочтительней. Средства графического ввода может быть когда-то и вернутся, но только, когда и если появятся стандарты для хранения схем и инструменты облегчающие их ввод, управление схемами и их сравнения.
Подробнее...