реклама на сайте
подробности

 
Личные инструменты

Требования к написанию программ и документации для ПЛИС

Материал из ELECTRONIX.ru Wiki

Перейти к: навигация, поиск

В документе даются рекомендации, правила и руководства для создания описания цифровых устройств на VHDL (Very high speed integrated circuits Hardware Description Language) для программируемых логических интегральных схем ПЛИС, чтобы другие разработчики, участвующие в проекте, могли быстро понимать, вносить изменения и верифицировать программу на VHDL (описание цифрового устройства), а также использовать в своих разработках. Поэтому должно быть описание цифрового устройства на VHDL простым, структурированным для понимания и легко переносимым. Далее приводятся основные руководящие требования для построения такого описания, которое можно легко синтезировать и верифицировать. Одна из главных трудностей в использовании «чужого» проекта на VHDL – нехватка подходящих указаний по именованию и правилам написания программ. Эти подходящие указания по именам, правилам «хорошего тона» для написания программ и руководства для синтеза должны быть созданы в начальной фазе проекта и предписаны для всей команды разработчиков проекта.

Содержание

Цель

Систематизировать правила написания программ на VHDL для повышения эффективной работы как отдельно взятого разработчика так коллектива в целом, выработать единые требования к синтезу и верификации описанных цифровых устройств.

Указания по именованию

1. Используйте в именах только строчные буквы для всех сигналов, портов, имен переменных, констант, типов определяемых пользователем и параметров.

2. Используйте значимые имена, которые должны объяснять поведение переменной/сигнала. Выбор выразительного имени сигнала или переменной является важной, но часто игнорируемой частью процесса проектирования. Хорошо выбранное имя дает понимание, а не путает того, кто читает описание, и это верно даже, если это сам автор программы. Оно объясняет, что он означает или, что означает величина вектора или переменной. Без этой информации трудно читать описание аппаратуры и, маловероятно, что оно будет написано без ошибок. В таблице представлены некоторые из них:

rst, rst_n reset, reset_n асинхронные сбросы “1”/”0”
clk тактовая частота модуля
sclr синхронный сброс
clear рабочий сброс (никакого отношения к цепи начального сброса не имеет!!!)
load загрузка
ena, enable разрешение
inc, dec инкремент, декремент
wr, write строб записи
rd, read строб чтения
rd_int, wr_int или rd_reg, wr_reg внутренние регистровые сигналы модуля/блока

3. Используйте "clk" для названия тактового сигнала блоков/модулей, и используйте его в качестве префикса для всех тактовых сигналов, например, clk_inv, clk_96MHz, которые поступают с PLL. Кроме того, применение этого имени для всех тактовых сигналов сигнализирует о том, что происходят они от одного внешнего источника. Если внешних источников тактовых сигналов два и более, тогда добавляйте порядковый номер к имени "clk", например clk2, clk3, clk4, clk5 и соответственно для clk2_inv, clk2_100MHz, которые поступают с PLL.

4. Используйте последовательный порядок битов при объявлении многоразрядных векторов переменных/сигналов высокий к низкому - то есть от (n - 1) до 0 для VHDL. Ноль здесь используется как младший разряд, тогда все многоразрядные вектора переменных/сигналов должны быть в форме (n - 1) до 0. Эти соответствия кодирования помогут избежать ошибок при связи многоразрядных переменных между собой.

5. Добавляйте _n для указания инверсной фазы сигнала.

Примеры:
data_in_n, grand_n.

Если есть два имени, которые отличаются только символами _n, то убедитесь, что они действительно являются логической инверсией один другого.

6. Используйте поименованные константы, вместо указания непосредственных значений в тексте модуля/блока.

7. Используйте значимые имена файлов, которые должны объяснять назначение. В таблице представлены некоторые суффиксы, отражающие тип описания на VHDL:

_rtl Описание RTL модели Uart_rtl.vhd
_beh Описание behavioural модели Uart_beh.vhd
_tb Описание Test Bench Uart_tb.vhd
_pack Описание Package Uart_pack.vhd
_top Описание Top Level Uart_top.vhd

Правила написания программы

1. Приводите в соответствие иерархию проекта с иерархией физического разбиения. Модули должны быть понятными - достаточно короткими для простоты, но слишком маленькие модули порождают слишком много ветвей в структуре дерева, и иерархия становится сама по себе трудной для понимания. Ориентиром при проектировании аппаратуры должно быть соответствие иерархии проекта - иерархии физического разбиения аппаратуры. Это упрощает генерацию и извлечение тестовых векторов и делает проще трансляцию модели в физическую структуру.

2. Делайте декларацию портов логичной и непротиворечивой. Пишете один порт на строку с описанием в виде короткого комментария к имени порта, если это не очевидно с его имени порта. Например, если модуль имеет 5 или меньше портов, их можно записывать в виде списка в следующем порядке: входы, входы/выходы, выходы. Если более 5 портов, группируйте сигналы по функциональному назначению.

3. Используйте функции и процедуры, вместо повторения кода.

4. Используйте векторы, массивы, операторы генерации и циклы для уплотнения кода.

5. Применяйте технологически независимое и совместимое с различными пакетами проектирования описание схем на VHDL. Исключением является использование блоков памяти, PLL, three-state buses, bi-directional buses и других. Избегайте использования таких элементов, так как могут возникнуть ограничения для повторного проектирования и использования, из-за их зависимости от технологии и производителя. Работу с ними лучше изолировать в отдельных модулях/блоках проекта.

6. Старайтесь избегать вставок вентильных примитивов в RTL коде. Проект на вентильном уровне трудно читать и повторно использовать.

7. Не встраивайте директивы синтеза в RTL код. Если директивы синтеза различаются в разных пакетах проектирования, то встроенные директивы могут вызывать конфликты и ограничения для повторного проектирования и использования.

8. Используйте для процессов метки (label), которые кратко поясняют работу процесса, например метка label_counter поясняет, что процесс описывает схему счетчика, а также, ставьте метки в начале и в конце процесса, что позволит быстро ориентироваться в программе.

Например:
label_counter: process (clk, en, count, rst)
             ……………
               end process label_counter;

9. Пишите комментарии соответствующие написанной программе. Это означает, что необходимо проверить комментарий на соответствие программе. Нужно модифицировать комментарий, когда меняете программу. Наличие комментария облегчает понимание программы.

10. Включайте в файл комментарий, который характеризует любое сделанное Вами изменение. Комментарий должен включать дату, имя внесшего изменение, собственно изменение и причину его вызвавшую. Это поможет другим, занимающимся поддержкой программы, следить за тем, что происходит, и разобраться в проблеме, если сделанные изменения повлекли дополнительные ошибки.

11. Описывайте процесс создания готовых ядер при использовании программ для их создания (например, CoreGenerator для Xilinx ISE). Избегайте использования таких ядер, так как могут возникнуть ограничения для повторного проектирования и использования, из-за их зависимости от технологии и производителя. Работу с ними лучше изолировать в отдельных модулях/блоках проекта.

12. Предоставляйте для функционально законченного блока, а также для проекта в целом Test bench файлы, в котором создаются внешние воздействия, максимально соответствующие работе схемы в реальных условиях и предоставляйте описания работы с данными Test bench файлами. Это помогает в дальнейшем быстрее понять и верифицировать работу модуля/блока и проекта в целом.

13. Используйте сигналы вместо переменных в VHDL.

14. Используйте графический схемотехнический редактор для создания схемы верхнего уровня проекта/модуля/блока, которую затем можно автоматически перевести в структурное описание на VHDL. Графическое представление позволит наглядно увидеть структуру проекта/модуля/блока в целом.

15. Делайте список чувствительности наиболее полным. Когда списки чувствительности являются неполными, моделирование может, не сходится между pre- и post - synthesis netlists. В комбинаторных процессах список чувствительности должен содержать каждый сигнал, входящий в этот процесс. Для последовательных блоков список чувствительности должен содержать тактовый сигнал и другие, синхронные и асинхронные сигналы. Избегайте лишних сигналов в списке чувствительности, поскольку они замедляют процесс моделирования.

Руководство для синтеза

При проектировании особенно важно понимать взаимодействие между стилем HDL кодирования, различными архитектурами устройств FPGA и программным обеспечением для автоматизированного проектирования. Приложения, от которых требуется высокая производительность и плотность размещения логики, являются очень критичными к используемому разработчиком стилю кодирования. Для получения оптимальных результатов необходимо понимание архитектуры матриц FPGA, принципов работы инструментов синтеза схем и программного обеспечения конечной трассировки.

Цель RTL - создание проекта через процесс синтеза. Каждый инструмент синтеза имеет свои собственные конструкции для VHDL программ; использование этих конструкций, позволяет сделать эффективным процесс синтеза, а также упростить post-synthesis анализ. Некоторые обобщенные руководящие принципы для принятия RTL синтеза приведены следующим образом:

1. Избегайте использования конструкций, создающих различные защелки (Latchs). Инструмент синтеза может создать защелки из-за неполного или двусмысленного RTL кода. Для этого каждое if должно иметь else. Когда проектируется аппаратура, часто требуется выполнение каких-либо действий при условии "истина" и другого при условии "ложь". Даже если считаете, что условие "ложь" маловероятно (или невозможно), то else для случая по умолчанию должно быть в каждом if операторе. Нарушение пары if-else может вызвать синтезирование логики (появление защелки), отличной от RTL модели.

2. Избегайте в RTL петли комбинаторной обратной связи и асинхронной логики.

3. Используйте регистры и триггеры для последовательной логики, которые обеспечивают синхронизацию и, следовательно, более предпочтительны, чем защелки. Если необходим сброс модуля/блока, тогда вместо использования "инициализации" в декларации VHDL используйте цепи сброса сигнала для начальной инициализации регистров.

4. Производите переключение последовательной логики по переднему фронту тактовой частоты (clk'event and clk='1') или по заднему фронту тактовой частоты (clk'event and clk='0') в модулях/блоках принимается в начальной стадии проектирования. По умолчанию, принята работа схем по переднему фронту тактовой частоты (clk'event and clk='1').

5. Разделяйте RTL код соответствующим образом на процессы с тем, чтобы процесс синтеза работал эффективнее, и могли быть легко проверены временные требования. Например, для конечных автоматов (finite-state machine) код может быть разделен на два процесса - один для комбинаторной логики, а второй для последовательной логики.

6. Фиксируйте в ПЛИС данные/сигналы на регистрах, как на входах, так и на ее выходах. На выходах блоков/модулей рекомендуется иметь регистры (reg) – иначе больше вероятность того, что задержка в комбинационной схеме (КС) на выходе блока плюс задержка в межблочных соединениях плюс в комбинационной схеме на входе следующего блока превысят время между синхроимпульсами. Это также упрощает синтез, делает выход блока/ПЛИС надежным, а задержки более предсказуемыми. Фиксация на регистре делает технологию mapping легче.


7. Исключайте из блоков/модулей многотактные пути и используйте соответствующие ограничения. Соответствующие ограничения являются такими же важными для получения оптимальной схемы, как и оптимальное описание схемы на языке описания аппаратуры. Каждый модуль или часть схемы, которые оптимизируются, должны иметь точные указания о временах прихода на входные порты и нагрузочной способности, а также о нагрузке выходных портов и максимальных задержках. Многотактные пути (МТП) или ложные пути в схеме могут привести к тому, что синтезатор создаст неоптимальную логику. Если синтезатор не знает о МТП или ложных путях, он пытается оптимизировать ненужные пути и не обратит внимания на пути, которые действительно являются критическими. Необходимо проектировать схему с наименьшим количеством МТП и ложных путей. Однако отключение нежелательных путей трудно из-за количества путей и того, что они должны быть указаны посредством отключения временных соотношений на портах модулей или на вентильном уровне. Кроме того, при любых изменениях схемы нужно изменять указания. Найденное нами решение состоит в том, чтобы удалить все МТП и ложные пути вставкой триггеров и разрывом этих путей. Эти фиктивные триггера для синтезатора представляются действительными триггерами, но в действительности для целей размещения и моделирования они воспринимаются как провод или буфер от входного порта D к выходному порту Q.

8. Делайте модуль верхнего уровня, который содержит только межсоединения. Структура, описанная на VHDL, может быть иерархична и состоять из одного или более модулей, которые могут использовать любые другие модули. Модуль, который включает любой другой модуль, является узлом дерева, а модуль, не включающий никакого другого, является листом дерева. Корень - такой тип узла, который не входит ни в один другой модуль. Хотя VHDL и допускает проектирование "леса" (множества деревьев), но иерархия будет понятной, если используется только одно дерево. Конкретно это означает, что структура должна иметь только один корень. Этот корневой модуль не должен содержать чего-либо другого, кроме межсоединений и входящих модулей. Вся интерфейсная логика должна быть собрана в модулях нижнего уровня и в модулях, подсоединяемых к корню. Наиболее важной причиной нахождения логики вне корневого модуля является эффективный синтез. САПР не сможет оптимизировать логику в подмодулях, если в корневом модуле есть промежуточная логика. Исключение логики из корневого модуля делает структуру иерархически яснее и чище. Более радикальным стилем было бы исключить логику из всех узловых модулей, хотя это может вызвать избыточные уровни иерархии и не сделает программу проще для чтения. И последней причиной исключения логики из корневого модуля является необходимость дать возможность программе-трассировщику создать хороший список межсоединений.

9. Не объединяйте в одном модуле/блоке, последовательную логику управляемую передним фронтом, и последовательную логику, управляемую задним фронтом тактового сигнала, а также модули/блоки, работающие на разных частотах. Каждый блок/модуль должен разрабатываться как одноклоковый и в нем тактовая частота должна быть как «clk», за исключением блоков стыков доменов, т.е. подсоединение к сигналу вида clk_96MHz производите только на Top Level уровне.

10. Старайтесь избегать использования арифметических операторов. Арифметические операторы при реализации требуют много логики и занимают большую площадь. Например, если требуется операция умножения или деления операнда на четную степень двойки, то можно использовать соответствующую операцию сдвига на регистре.

11. Используйте скобки для оптимизации логической структуры. Изменяйте структуру схемы, используя скобки для группирования логики таким образом, чтобы результат синтеза был ближе к оптимальному. Например, следующее выражение:

sum = a+b+c+d;

синтезатор транслирует в три последовательно соединенные сумматора. А такое выражение:

sum = (a+b)+(c+d);

транслируется в два параллельных сумматора для (a+b), (с+d) и один окончательный сумматор для суммирования этих сумм.

12. Старайтесь использовать совмещение аппаратных ресурсов - это уменьшает затраты на оборудование. Пример VHDL описания процесса, порождающего в синтезируемой схеме два сумматора на входе мультиплексора

signal sum : std_logic_vector(7 downto 0);
...
If (select = ‘1’) then
  sum <= a + b;
Else
  sum <= c + d;
End if;

Оптимизированное описание, порождающего два мультиплексора и один сумматор

variable tmp1, tmp2 : std_logic_vector(7 downto 0)
...
If (select = ‘1’) then
  tmp1:= a;
  tmp2:= b;
Else
  tmp1:= c;
  tmp2:= d;
End if;
sum <= tmp1 + tmp2;


Литература

  1. ALSE's - VHDL Design Rules & Coding Style
  2. Ben Cohen - VHDL Coding Guide and Methodologies.
  3. Rochit Rajsuman - System-on-chip Design and test
  4. Mishael Keating, Pierre Bricaud - Reuse Methodology Manual Third Edition
  5. Поляков А. К. Языки VHDL и Verilog в проектировании цифровой аппаратуры. - М.: СОЛОН-Пресс, 2003. - 320 с.
  6. Elecard's VHDL Design Rules & Coding Style [1]

Связанные темы форума

Источники

Исходный материал статьи предоставлен Денисовым Алексеем Олеговичем Данную статью "Несколько советов по проектированию цифровых устройств на VHDL для ПЛИС" с некоторыми изменениями и дополнениями автор /Денисов А.О./ опубликовал в журнале "КОМПОНЕНТЫ И ТЕХНОЛОГИИ" - 2009. - №12. - С. 31-34 [2]

@Mail.ru


Страница сгенерированна за 0.19378 секунд с 6
ELECTRONIX ©2004-2016