Проектирование в условиях временных ограничений: компиляция проектов на основе ПЛИС Текст научной статьи по специальности «Компьютерные и информационные науки»

Окончание. Начало в № 12'2007

Ростислав ГРУШВИЦКИИ

RIGrushvitsky@mail.eltech.ru Максим МИХАЙЛОВ

yamaksya@yandex.ru

Проектирование в условиях временных ограничений:

компиляция проектов

Примеры использования инкрементальной компиляции

Для пояснения последовательности действий при работе с инкрементальной компиляцией в среде Quartus II воспользуемся рассмотренным в предыдущих выпусках примером [4]. Простота схемы не влияет на суть процедуры, но позволяет выиграть и в длинах кода, и в понимании выполняемых действий. Проект представляет собой трехъярусную схему, состоящую из трех простейших блоков. Нижний ярус образован 4-разрядным сдвигающим регистром (shift_register) с асинхронным сбросом и загрузкой сдвигаемых значений при единичном значении сигнала Shift. В среднем ярусе помещен 4-разрядный последовательный счетчик (counter). При достижении счетчиком максимального значения (1111) формируется сигнал переполнения (Over_flow). И, наконец, на верхнем ярусе находится выходной 5-разрядный регистр (DFF_register). Функциональная схема устройства приведена на рис. 3.

В отличие от реализации, приведенной в предшествующей статье [4], проект предполагается разбить на части (partitions), каждая из которых должна описываться в отдельном файле. И, кроме того, необходим файл, объединяющий эти части в единое целое. Принятое далее разбиение приведено на рис. 4. Разбиение проекта необходимо для

dff_register

! 4 ! з ! 2 ! 1 ■' о !

Load

En count

Reset

Shift

Clock

counter

! з ' 2 ! 1 ! о !

/ / /

shift_register

V21 1 ! 0 !

Data in

применения любого типа инкрементальной компиляции.

Составление подобного «скелета» программы (ее архитектуры) необходимо осуществлять в самом начале проектирования — на этапе раннего планирования. При планировании выполняется целый ряд подготовительных действий: выбор типа ИС, выбор расположения входных и выходных контактов, определение временных и мощностных ограничений и т. д. Большинство этих действий не связано с непосредственной работой на САПР, однако вместе с тем, опираясь на возможности Quartus, разработчик еще до этапа конструкторско-технологического проектирования может, например, получить предварительные оценки затрачиваемой мощности и временных характеристик.

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

В отличие от исходного HDL-описания каждый блок должен быть представлен отдельным файлом (листинг 1 — shift_regis-ter.vhd, листинг 2 — counter.vhd и листинг 3 — buffer.vhd). Это вызвано необходимостью выделения независимых друг от друга частей проекта для эффективного создания логических разделов. Разграничение проекта на отдельные HDL-конструкции (entity для

VHDL, module для Verilog) является вполне обоснованным с точки зрения инкрементальной компиляции. Однако если такие конструкции будут физически располагаться в едином файле, то повторной компиляции будут подвергнуты все логические разделы, даже при условии изменения кода только в одном из них. Таким образом, наличие зависимости раздела от нескольких проектных файлов автоматически вызывает перекомпиляцию всех файлов, попадающих в зону влияния этой зависимости.

LIBRARY IEEE;

USE IEEE.std_logic_1164.ALL;

USE IEEE.std_logic_unsigned.ALL;

ENTITY shift_register IS PORT (

Clock

Reset

Shift

Data_in

Shift_register

IN std_logic;

IN std_logic;

IN std_logic;

IN std_logic;

OUT std_logic_vector(3 DOWNTO 0)

END shift_register;

ARCHITECTURE model OF shift_register IS

SIGNAL Shift_register_int : std_logic_vector(3 DOWNTO 0);

BEGIN

PROCESS (Reset, Clock, Shift, Data_in, Shift_register_int) BEGIN IF Reset = '1'THEN Shift_register_int <= «0000»;

ELSIF Rising_edge(Clock) THEN F (Shift = '1') THEN Shift_register_int <= Data_in & Shift_register_int (3 DOWNTO 1);

END IF;

END IF;

END PROCESS;

Shift_register <= Shift_register_int;

END model;

Листинг 1

Рис. 3. Схема устройства, встраиваемого в ПЛИС

Рис. 4. Схема проекта, разбитого на отдельные блоки

LIBRARY IEEE;

USE IEEE.std_logic_1164.ALL;

USE IEEE.std_logic_unsigned.ALL;

ENTITY counter IS PORT (

Clock

Load

En_Count

Shift_register

Counter

Over_flow

);

END counter;

IN std_logic;

IN std_logic;

IN std_logic;

IN std_logic_vector(3 DOWNTO 0); OUT std_logic_vector(3 DOWNTO 0); OUT std_logic

ARCHITECTURE model OF counter IS

SIGNAL Counter_int : std_logic_vector(3 DOWNTO 0);

BEGIN

PROCESS (Clock, Load, En_Count, Shift_register, Counter_int) BEGIN

IF Rising_edge (Clock) THEN IF (Load = '1') THEN Counter_int <= Shift_register;

ELSIF En_Count = '1' THEN Counter_int <= Counter_int + '1';

END IF;

END IF;

END PROCESS;

Counter <= Counter_int;

Over_flow <= '1' WHEN Counter_int = «1111» ELSE '0';

END model;

Листинг 2

LIBRARY IEEE;

USE IEEE.std_logic_1164.ALL;

USE IEEE.std_logic_unsigned.ALL;

ENTITY output_buffer IS PORT (

Clock Counter Over_flow DFF_register );

END output_buffer;

IN std_logic;

IN std_logic_vector(3 DOWNTO 0); IN std_logic;

OUT std_logic_vector(4 DOWNTO 0)

ARCHITECTURE model OF output_buffer IS BEGIN

PROCESS (Clock, Counter, Over_flow)

BEGIN

IF Rising_edge (Clock) THEN DFF_register(3 DOWNTO 0) <= Counter; DFF_register(4) <= Over_flow;

END IF;

END PROCESS;

Листинг 3

*£* Quart us II D:/lncremental/KiT/Unit Unit [Compi...

1 He Edt Vtew Tools Wndow

Completion Report Partition Dependent File*

[-') Legal Notice Dependent

AowSvnmwy Fter

cSrTTl How Settngs 1 :№_iegR<ci.vhd

How Non OefaJt Global SetUngs

£■”0* Elapsed me

^|(B) Hew*Log

- An4*ys6& Synthesis

^□Sunmary

• d^JSethng»

Scvce Wes P.e«d

• & 1 R»t*wn for Top-level

• dfr—JR*Otioo’output _Wfe»:mst2*

♦ ^|_J Parttion "(oayer rirvstr

- ParUwnVrft renter :rwt*

Partition Dependent Pies

Rewxxce urfcabon by Entfy

A ij Messages

(iHB Resource Usage Summary

♦ ^ | Opbmzabon ResAs

* <9-J Partition Merge

* Assembler

• & | Timng Analyzer

Рис. 5. Отчет о компиляции при выделении логических разделов

Описанный на языке УИЭЬ блок, соответствующий верхнему уровню иерархии (устройству целиком), приведен в листинге 4.

LIBRARY IEEE;

USE IEEE.STD_LOGIC_1164.ALL;

USE IEEE.STD_LOGIC_UNSIGNED.ALL;

ENTITY Unit IS PORT (

Clock

Reset

Load

Shift

En_Count

Data_In

DFF_register

IN STD_LOGIC;

IN STD_LOGIC;

IN STD_LOGIC;

IN STD_LOGIC;

IN STD_LOGIC;

IN STD_LOGIC;

OUT STD_LOGIC_VECTOR(4 DOWNTO 0)

END Unit;

ARCHITECTURE model OF Unit IS

COMPONENT shift_register IS PORT (

Clock Reset Shift Data_in Shift_register

IN STD_LOGIC;

IN STD_LOGIC;

IN STD_LOGIC;

IN STD_LOGIC;

OUT STD_LOGIC_VECTOR(3 DOWNTO 0)

END COMPONENT shift_register;

COMPONENT counter IS PORT (

Clock Load

En_Count Shift_register Counter Over_flow

IN STD_LOGIC;

IN STD_LOGIC;

IN STD_LOGIC;

IN STD_LOGIC_VECTOR(3 DOWNTO 0); OUT STD_LOGIC_VECTOR(3 DOWNTO 0); OUT STD_LOGIC

END COMPONENT counter;

COMPONENT output_buffer IS PORT (

Clock Counter Over_flow DFF_register

IN STD_LOGIC;

IN STD_LOGIC_VECTOR(3 DOWNTO 0); IN STD_LOGIC;

OUT STD_LOGIC_VECTOR(4 DOWNTO 0)

END COMPONENT output_buffer;

SIGNAL Sig_Shift_register SIGNAL Sig_Counter SIGNAL Sig_Over_Flow

BEGIN

S_R: shift_register PORT MAP (

STD_LOGIC_VECTOR(3 DOWNTO 0); STD_LOGIC_VECTOR(3 DOWNTO 0); STD_LOGIC;

Clock => Clock,

Reset => Reset,

Shift => Shift,

Data_in => Data_In,

Shift_register => Sig_Shift_register

-- END instant shift_register;

Coun: counter PORT MAP(

Clock => Clock,

Load => Load,

En_Count => En_Count,

Shift_register => Sig_Shift_register,

Counter => Sig_Counter,

Over_flow => Sig_Over_flow

-- END instant counter;

O_B: output_buffer PORT MAP (

Clock

Counter

Over_flow

=> Clock,

=> Sig_Counter, => Sig_Over_flow, DFF_register => DFF_register

-- END instant output_buffer; END model;

Листинг 4

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

Далее приводится два типовых примера использования инкрементальной компиляции. Первый пример связан с изменением исходного описания одного из блоков и поясняет общий порядок действий при работе с инкрементальной компиляцией. Второй — это классический вариант использования стратегии «сверху-вниз», при которой бригадный метод требует самостоятельной и параллельной разработки каждого блока.

Для имплементации проекта будем ориентироваться на конкретную ИС — в нашем случае ПЛИС фирмы Altera Cyclone (EP1C6Q240C8). Выбор ИС в данном случае определялся желанием использовать для реальной проверки отладочный стенд, описанный в статье [5]. Вывод у платы свободных контактов ИС на разъемы типа PLD и PLT и подключение к ним отладочного мезонина со средствами индикации и управления позволяет организовать разнообразные эксперименты и задает необходимое распределение внешних контактов проекта. Демонстрационный характер примера позволяет опустить обычно существующие временные ограничения.

Пример 1

Сначала выполняется предварительная подготовка проекта для поддержки инкрементальной компиляции и осуществляется полная компиляция. Затем следуют действия по изменению исходного HDL-описания устройства, вызванному требованиями модификации или отладки проекта. При дальнейших итерациях, связанных с повторной компиляцией, появляется возможность выбора типа списка соединений (netlist) и реализации механизма инкрементальной компиляции. Формально алгоритм можно представить следующим образом:

1. Анализ и выработка структуры проекта на основе исходного HDL-описания (команда Processing > Start > Start Analysis & Elaboration).

2. Установка режима инкрементальной компиляции (после команды Assignment > Setting > Compilation Process Setting > Incremental Compilation включить опцию Full incremental compilation).

3. Создание логических разделов проекта (Design Partitions).

4. Возможно создание и топологических регионов (LogicLock Region).

5. Выполнение полной компиляции (команда Processing > Start Compilation), при этом транслируются все разделы.

6. Изменение проекта перед повторной компиляцией.

7. Установка типа списка соединений для каждого раздела.

8. Выполнение инкрементальной компиляции (команда Processing > Start Compilation),

END model

при этом транслируются только те разделы, которые связаны с проектными изменениями.

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

Результатом исполнения команды Analysis & Elaboration является иерархия проекта, на основе которой в дальнейшем создаются логические разделы. Назначение разделов, как и многие другие действия в САПР Quartus, может осуществляться различными способами. Один из вариантов — через контекстное меню (вызывается щелчком правой кнопкой мышки во вкладке Hierarchy окна Project Navigator) установка опции Set as Design Partition (рис. 6). Также приемлемо перетаскивание мышкой частей проекта из окна навигации в окно логических разделов (окно Assignments > Design Partition Window). Кроме того, возможно порождение нового раздела непосредственно в окне Design Partitions двойным щелчком на пункте «<<new>>». Созданный раздел появляется в списке разделов проекта. Границы логических разделов должны совпадать с границами блоков иерархии. Таким образом, понятие раздела является более широким и может включать в себя одну или несколько иерархических единиц проекта. В руководстве по использованию среды Quartus [1] приводятся рекомендации по созданию логических разделов, среди которых можно выделить наиболее важные — минимизация связности разделов (сокращение числа общих сигналов) и наличие регистров на границах каждого раздела. В нашем примере помимо основного Top-раздела можно было бы создать только один дополнительный раздел для блока, предполагающего последующую автономную отладку и оптимизацию — для entity shift_register. Однако с целью обобщения текстов двух рассматриваемых вариантов создаются три дополнительных раздела.

Также различными способами может осуществляться создание топологических регионов. Один из вариантов — через контекстное меню (вызывается щелчком правой кнопкой мыши во вкладке Hierarchy окна Project Navigator) установка опции Create New LogicLock Region (рис. 7).

В завершение необходимо произвести полную компиляцию. На этом предварительная работа по подготовке проекта к инкрементальной компиляции завершается.

Теперь становится доступной возможность перекомпиляции только измененных частей проекта. Реализация этой возможности заключается в выборе для каждого раздела типа списка соединений, который выражает полученные ранее результаты трансляции. На рис. 8 изображен внешний вид окна Design Partitions при установке типа списка соединений. Для сохранения результатов монтирования проекта необходимо для выбранного раздела назначить тип Post-Fit. Чтобы сохранить только результат синтеза, выбирается тип Post-Synthesis. Разделы, содержащие измененный исходный код, подвергаются повторной компиляции автоматически (исключение составляет только тип Post-Fit (Strict)). Принудительной компиляции можно добиться установкой типа Source File (компиляция бу-

Рис. 7. Окно назначения топологических регионов

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

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

Рис. 8. Установка типов списка соединений раздела

Рис. 6. Окно назначения логических разделов

Рис. 9. Топологический вид рабочего фрагмента кристалла

за счет сохранения и повторного использования списка соединения post-fit Top-раздела, а также разделов counter и buffer. Для этого в окне Design Partitions для логического раздела shift_register (в котором были произведены изменения) выставляем тип используемого списка соединений Source File, а для остальных разделов — Post-Fit. Далее производим компиляцию. В этом случае на компиляцию будет затрачено меньше времени, чем при традиционном подходе. Результаты выделения топологических регионов можно наблюдать, а при необходимости и изменять, пользуясь редактором Chip Planner (рис. 9).

Пример 2

Второй пример предполагает использование бригадного метода — привлечение различных исполнителей для проектирования отдельных блоков устройства, разработка которых может начинаться и завершаться в различное время. В этом случае всем разработчикам раздается «скелет» общей программы (с пустыми блоками) и описание интерфейсов — правил взаимодействия блоков. По ходу разработки пустые блоки замещаются готовыми.

Текст файла верхнего уровня иерархии анализируемого проекта полностью соответствует описанию, приведенному в первом примере. Для блоков, разработка которых еще не выполнена, должны быть сформированы заглушки (такие файлы-оболочки обычно называют «stub»).

На языке VHDL такой конструкции соответствует описание блока, содержащее полное ENTITY и пустое архитектурное тело ARCHITECTURE. Для примера в листинге 5 приведено описание блока O_B (output_buffer).

LIBRARY IEEE;

USE IEEE.std_logic_1164.ALL;

USE IEEE.std_logic_unsigned.ALL;

ENTITY output_buffer IS

PORT (

Clock IN std_logic;

Counter IN std_logic_vector(3 DOWNTO 0);

Over_flow IN std_logic;

DFF_register OUT std_logic_vector(4 DOWNTO 0)

); ); END output_buffer;

ARCHITECTURE model OF output_buffer IS

BEGIN

END model;

Листинг 5

После исполнения команды Processing > Start > Analysis & Elaboration получаем иерархию проекта. Убеждаемся в задании режима инкрементальной компиляции (после команды Assignment > Setting > Compilation Process Setting > Incremental Compilation на вкладке должна быть установлена опция Full incremental compilation). На основе иерархии проекта, как и в первом примере, задаем логические разделы.

Ведущий проектировщик имеет возможность задавать глобальные установки

(assignments), которые касаются временных характеристик, параметров устройства и т. д. Проектировщики вложенных блоков (оформленных в виде логических разделов проекта) могут, в свою очередь, добавлять ограничения для своих собственных разделов.

Для каждого логического раздела, опираясь на средства LogicLock, могут быть определены соответствующие топологические регионы и заданы установки по размещению и разводке (floorplan location assignment).

Закончив перечисленные выше действия, можно выполнять компиляцию проекта (команда Processing > Start Compilation). Естественно, что после установки логических (и физических) разделов первоначальная компиляция является полной. Однако последующие компиляции уже будут опираться на инкрементальные средства САПР.

Следует иметь в виду, что кроме полной инкрементальной компиляции (описанной выше) может использоваться вариант инкрементальной компиляции только для этапа синтеза. Для установки этого режима после команды Assignment > Setting > Compilation Process Setting > Incremental Compilation на вкладке надо включить опцию Incremental synthesis only.

Различные варианты инкрементальной компиляции имеют определенные плюсы и минусы. В каждом случае целесообразный поток должен осознанно и обоснованно выбираться проектировщиком. Поддержка инкрементальной компиляции для небольших проектов может приводить к тому, что «накладные расходы» на ее реализацию будут значительными и поэтому ее применение может не давать существенного временного выигрыша. Более того, поскольку при разбиении на логические разделы не может производиться оптимизация на границах разделов, то качество суммарного проекта (прежде всего его эффективность) может уменьшаться с ростом числа разделов. Этот эффект сильнее сказывается при полной инкрементальной компиляции, чем только при инкрементальном синтезе. Поэтому при стратегии «снизу-вверх» он проявляется резче, чем при методологии «сверху-вниз». При компиляции «сверху-вниз» логические разделы не связаны жестко с результатами монтирования (post-fitting) и программа-монтировщик может выполнять определенную оптимизацию размещений. При потоке «снизу-вверх» разделы компилируются раздельно, и обычно результаты монтирования экспортируются в проект высшего уровня, не допуская тем самым оптимизацию размещения через границы разделов.

Заключение

Базовые сведения о работе с САПР Quartus II можно найти в книге [6]. Формат журнальных статей не позволяет остановиться более подробно на многих интересных и тонких местах процедуры инкрементальной компиля-

ции. Вместе с тем авторы надеются, что приведенный выше материал и примеры помогут разработчикам проектов на ИС фирмы Altera более эффективно использовать свое время и упростить разработку сложных проектов, а при необходимости также задействовать бригадный метод разработки. Детальное описание различных режимов компиляции можно найти в фирменном руководстве [1]. Авторы (в рамках своей компетенции) готовы ответить на вопросы читателей, заинтересовавшихся тематикой данной статьи. ■

Литература

1. Quartus II Version 7.0 Handbook Volume 1: Verification (Section I. Design Flows). www.altera.com

2. Описание САПР RTLvision PRO. www.concept.de

3. Компиляция в Quartus II. http://www.dsioffe.narod.ru

4. Грушвицкий Р., Михайлов М. Проектирование в условиях временных ограничений: отладка проектов // Компоненты и технологии. 2007, № 6.

5. Грушвицкий Р., Михайлов М. Проектирование в условиях временных ограничений: отладка проектов // Компоненты и технологии. 2007, № 9.

6. Комолов Д. А., Мяльк Р. А., Зобенко А. А., Филиппов А. С. Системы автоматизированного проектирования фирмы Altera MAX+plus II и Quartus II. Краткое описание и самоучитель. М.: РадиоСофт, 2002.