 |
Краткие теоретические сведения
|
|
|
|
При проектировании различных классов устройств рекомендуется придерживаться следующего набора правил.
Общие правила проектирования:
- Спецификация. Перед началом написания кода надо проверить существующие ядра и написать спецификацию. Спецификация должна содержать интерфейс устройства как чёрного ящика, описание функций с ссылкой на стандарты. Желательно использовать шаблон спецификации.
- Проектная документация. Если над ядром работает группа разработчиков, проектная документация должна быть написана до начала программирования, это условие того, что разрабатываемые блоки будут способны работать совместно без дополнительных затрат на их интеграцию.
- Структура директорий. Необходимо использовать строго оговоренную структуру директорий и она обязательно должна присутствовать в проектной документации и документации пользователя.
Правила разработки на системном уровне:
- Рекомендуется писать наглядные комментарии, писать комментарии к каждому новому назначению или блоку.
- Для иерархического проекта рекомендуется создавать модуль верхнего уровня, включающий модули более низких уровней, не использовать в модуле верхнего уровня логику.
- Желательно сохранять одно и тоже имя сигнала на различных уровнях иерархии.
Правила разработки на уровне регистровых передач:
- Не рекомендуется смешивать логику, работающую по верхнему и нижнему уровню сигнала. Желательно придерживаться логики одного верхнего уровня.
- Сброс (Reset). Рекомендуется создавать асинхронный сброс, работающий по верхнему уровню сигнала для всех триггеров. Такой сброс должен быть синхронизирован с тактовым генератором на верхнем уровне проекта и не должен требовать мультиплексирования на каждом входе триггера. Рекомендуется, что бы во время сброса все двунаправленные порты находились в состоянии входа.
|
|
|
- Синхросигналы. При наличии нескольких синхросигналов сигналы, которые пересекают различные области тактирования, должны быть дискретизированы до и после пересечения таких областей для предотвращения нестабильных состояний. Рекомендуется не использовать синхросигнал или сигнал сброса как данные или как сигнал запуска. Не использовать данные как синхросигнал или сигнал сброса. Желательно использовать минимальное количество областей синхросигналов в одном проекте.
- Шины. Строго рекомендуется сравнивать шины одинаковой длины. Рекомендуется начинать индексировать шину с 0. Рекомендуется использовать преобразование MSB в LSB (старший значащий разряд в младший значащий разряд). При этом бит 0 должен являться младшим значащим (LSB). Не делать шины шире, чем это необходимо. Если возможно, делать шину данных зауженной, а взамен увеличивать шину адреса.
- Тристабильные схемы. Рекомендуется избегать использования внутренних тристабильных сигналов. Они рекомендуются для внутреннего мониторинга.
- Память. Рекомендуется использовать синхронные одно и двух портовые групповые блоки памяти.
- Кодирование для синтеза. Рекомендуется использовать синхронный метод проектирования. Это позволяет избежать проблем с синтезом, временной верификацией и при моделировании. Строго рекомендуется не использовать элементов задержки. Это приводит к проблемам синтеза и проблемам временной верификации.
- Рекомендуется все внешние входы/выходы ядра буферизировать.
- Рекомендуется синхронизировать внутренние интерфейсы ядра.
- Рекомендуется избегать использования регистров-защёлок (latches). Желательно избегать использования триггеров с отрицательным перепадом синхроимпульса.
|
|
|
- Порты ввода/вывода. Рекомендуется называть порты ядра опираясь на соглашения, показанные в таблице 1 с обязательным занесением в проектную документацию.
Таблица 1 - Правила именования портов ввода/вывода
| Порт | Описание |
| *_i | Входной порт ядра |
| *_o | Выходной порт ядра |
| *_io | Двухсторонний порт ядра |
| *_clk_i | Порт входного синхросигнала ядра |
| *_clk_o | Порт выходного синхросигнала ядра |
| *_rst_i | Входной порт сигнала сброса |
| *_rst_o | Выходной порт сигнала сброса |
Не стоит использовать другие аббревиатуры кроме *_clk_* и *_rst_* для обозначения синхросигнала и сигнала сброса. Например, не надо использовать *reset* или *clock*, для избежания проблем при синтезе.
Рекомендуется использовать *n для обозначения сигналов, работающих по низкому уровню.
Правила создания проектов на языке описания аппаратуры VHDL. Они учитывают особенности языка VHDL и возможности современных систем автоматизированного синтеза для ПЛИС. Эти правила относятся к стадии разработки моделей блоков на уровне регистровых передач:
- Необходимо использовать тип std_logic для внешних портов. Нельзя назначать сигналам неизвестное значение 'x'. В некоторых случаях могут создаваться некорректные результаты при моделировании и синтезе. Использовать значения по умолчанию или инициализацию сигналов и переменных можно, хотя и не желательно, только для моделирования, но не синтеза (variable B:INTEGER:=0;). Такое назначение может привести к расхождениям при моделировании и реализации. Необходимо использовать сигнал сброса для задания всех сигналов и переменных.
- Нельзя использовать порты с буфером для чтения выходных значений. Взамен этого нужно добавлять другие переменные или сигналы с тем же выходным значением. Это связано с тем, что порты буферного типа не могут быть соединены с портами другого типа и поэтому данный тип buffer распространяется на порты всего проекта.
- Рекомендуется использовать определение компонент и констант для каждого ядра в одиночном модуле. Нужно писать один VHDL- элемент проекта в одном файле. Имя файла должно быть такое же, как имя элемента.
- Желательно не смешивать в проекте различные стандарты VHDL (например, не смешивать конструкции VHDL 87 и VHDL 93).
|
|
|
- Желательно компилировать каждый блок в отдельную библиотеку. Рекомендуется пользоваться константами и настраиваемыми параметрами (generics) для размера буферов, ширины шин и всех других параметров компонента.
- Кодирование для синтеза. Строго рекомендуется читать из переменных, затем писать в них (чтение перед записью). Если переменные сначала записываются, а затем считываются, то это приводит к созданию длинной комбинации логики и триггеров-защёлок (или регистров-защёлок). Это следует из того, что переменные получают своё значение сразу же, а не так как сигналы. Далее приведен пример неправильной конструкции, которую необходимо избегать.
PROCESS (CLK, RST_n)
Variable out_var: std_logic;
BEGIN -- PROCESS
IF RST_n = '0' THEN
out_var <= '0';
outsign2 <= '0';
ELSIF CLK'event AND CLK = '1' THEN
Outsign2 <= out_var; -- чтение
out_var <= input1 and input2; -- запись
END IF;
END PROCESS;
Необходимо включать все сигналы, которые считываются внутри комбинированного процесса, в его список чувствительности. Это делается для предотвращения появления нежелательных триггеров-защёлок.
- Рекомендуется избегать использования длинных выражений if-then-else, а взамен использовать оператор case. Это предотвращает появление декодеров высокого приоритета и делает код более легко читаемым.
- Нельзя использовать такие выражения как ‘(b <= a after X ns)’ или ‘wait for X ns;’. Такие выражения используются только для моделирования.
- Рекомендуется использовать сигнал clock enable (CE), как это показано ниже, с одним синхросигналом на процесс и не использовать два различных процесса, один для синхронизации, а другой для комбинаторной логики. Это связано с тем, что некоторые системы синтеза сами находят сигнал CE и назначают его. В противном случае ножка CE не будет задействована, что приведет к появлению дополнительной логики.
PROCESS (CLK, RST_n)
BEGIN -- PROCESS
IF RST_n = '0' THEN
Outsignal <= '0';
ELSIF CLK'event AND CLK = '1' THEN
IF (CE = '1') THEN
Outsignal <= '1';
END IF;
END IF;
END PROCESS;
- Желательно писать тестовые последовательности в двух частях, одна часть для генерации данных для проверки функционирования, а вторая часть для генерирования временных параметров протоколов шинных интерфейсов и их проверки.
- Заголовок файла. Рекомендуется использовать стандартный заголовок в начале каждого файла. Заголовок содержит базовую информацию о проекте, файле, авторе, лицензии и др. Все пункты заголовка должны быть оговорены в проектной документации.
|
|
|
