альными средствами; результатом является коррекция SDF файла (помимо прошивки ПЛИС или разводки СБИС);

6) проверка netlista с новыми задержками; подобна п. 4, но возврат возможен к п.п. 1, 3, 5;

7) in-place оптимизация (для большинства современных ПЛИС отсутствует), в ходе которой производится выравнивание времен распространения сигналов - усиление/ослабление выходов ячеек, установка буферов/элементов задержки;

8) повтор п. 6 до тех пор, пока не будут достигнуты требуемые характеристики;

9) подготовка производственных тестов, предназначенных для поиска неисправностей в СБИС (для ПЛИС этот шаг необязателен).

Шаг 3 в этой схеме раньше выполнялся вручную, когда поведенческое описание заменялось на структурное самим разработчиком. В настоящее время существуют средства синтеза, которые позволяют получить более эффективную схему Пользование этими средствами накладывает ограничение на употребление конструкций языка в исходном коде. То есть требуется синтезируемая модель. Кроме того, чтобы многократно не переписывать поведенческую модель, следует четко представлять, какое Verilog описание приведет к синтезу того или иного элемента схемы.

Ранее в статье было продемонстрировано, как работает Verilog симулятор. Далее будут рассмотрены требования средств синтеза.

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

Как уже упоминалось, иерархические имена, initial, fork-join или primitive не поддерживаются. Временной контроль #пп игнорируется в синтезируемой модели. Событийный контроль поддерживается частично: только в блоках always.

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

Кроме этого, существуют правила описания комбинаторной логики, последовательной логики, мультиплексоров, FSM и т. п.

Комбинаторная логика синтезируется из следующих конструкций:

1) непрерывное присвоение:

assign a=b+c&d; wire b={e,f}g[1:0];

2) сигналы, описанные в функциях;

3) сигналы, описанные следующей или подобной конструкцией:

reg data out; always @(а or b or с) if(b)

data out = a; else

data out - c;

TO есть бпок always, в списке чувстви-тепьности которого перечислены все входные сигналы.

Как можно видеть в 3-ем (а иногда и во 2-ом) случае объявление сигнала с ключевым словом reg не приводит к созданию регистра. Также комбинаторная логика синтезируется в случае case, если описаны все ветви. При этом получается не приоритетный набор (как в моделировании), а набор параллельных конструкций. Также case используется для синтеза мультиплексоров.

Последовательная логика имеет ограничения в синтезируемых конструкциях. Дпя описания регистра-защелки (latch) применяется следующая конструкция:

reg data out;

always @(datajn or enable) if (enable) data out = data in;

Для регистров, работающих по фронту/срезу сигнала, применяется описание с posedge или negedge конструкцией:

reg data out;

always @(posedge clock)

data out = datajn;

Чтобы добавить синхронный сброс, описание нужно дополнить сигналом установки/сброса, но не вносить эти сигналы в список чувствительности:

reg data out;

always ©(posedge clock)

if (set sig)

data out = 1"b1;

else if (reset sig)

data out = 1bO;

else

• data out = datajn;

Для асинхронной установки/сброса конструкция должна быть изменена, так чтобы эти сигналы попали в список чувствительности:

reg data out;

always @(posedge clock or posedge set sig or posedge reset sig) if (sel sig) data out = ГЫ; else if (reset sig) data out = 1bO; else

data out = datajn;

Пользуясь этими принципами, можно описать триггер любого типа.

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

Блок case, у которого не все входные воздействия расшифровываются, синтезируется в элемент последовательной логики. Также может использоваться для описания FSM (finite state machine). Поэтому кажется более правильным воспользоваться комбинаторным case и явно описать регистр для

хранения результата (к примеру, для реализации FSM).

Офаничения, накладываемые средством синтеза на HDL язык, позволякгг описывать логику работы схемы в виде комбинаторной логики и регистров для хранения результатов. Такое описание называется RTL (register transfer level) и иногда отделяется (по смыслу) от поведенческого. Основная идея, которую хотелось бы высказать в данной статье, -это то, что следует пользоваться RTL описанием для моделирования и синтеза Данный подход является эффективным методом ведения разработки. Так как "правильное" (написанное с применением правил изложенных выше) поведенческое описание может быть автоматически синтезировано на уровень вентилей, это позволяет значительно ускорить и упростить процесс разработки. При этом, если временные ограничения были выбраны правильно (с учетом задержек в элементах библиотеки), поведение RTL (поведенческой модели) не будет отличаться от поведения нетпис-та (gate-level) и не должно отличаться от поведения готового изделия.

Завершая рассмотрение синтезируемого (RTL) кода, следует упомянуть о директивах синтеза, не являющихся элементами языка Verilog. Они задаются в поле комментария и игнорируются при моделировании, но управляют средством синтеза, например:

synopsis synthesis off SwrlteCthis string is ignored b synthesis"); synopsis synthesis on

Для уже упоминавшегося case существует директива синтеза (выбирающая синтез в последовательную или параллельную логику), которая может быть указана в поле комментария:

ambit synthesis case = full parallel mux

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

Заключение

Данная статья не является документацией по языку Verilog. Целью написания статьи было проиллюстрировать работу Verilog симулятора и показать возможность использования языка Verilog для разработки цифровых схем. При этом рассмафивались какаспекты, связанные с тестированием модели (написание испытательных стендов), так и проблемы написания синтезируемого кода Приведенные примеры и объяснения к ним должны были (по замыслу автора) показать различия между процедурными языками и языками описания HDL. Развитие CSoC и ПЛИС позволяет предположить, что все большие части проекта могут быть реализованы в виде описания HDL. В статье была сделана попытка показать, что Verilog является сильным и удобным средством для этого.