Основные этапы проектирования цифровых устройств

 

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

Проектирование содержит ряд последовательно исполняемых этапов.

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

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

Классическим техническим решением, обеспечивающим надежность процедуры обмена информацией,  являются различные реализации принципа квитирования  (Hand Shake – рукопожатия). Техническая реализация полного  квитирования требует для каждого этапа взаимодействия введения в цепь обмена информацией  двух управляющих сигналов: одного от источника информации, а  другого от приемника информации, а также соответствующих информационных сигналов о завершении устройством некоторой операции.

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

На третьем этапе разрабатываются описания (в нашем случае на языке VHDL) отдельных компонент. При необходимости проверяется не только их синтаксическая, но и семантическая корректность описания.

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

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

Важнейшей составляющей  всех этапов разработки является  тестирование проекта. Процедуре тестирования уделено очень большое число работ [.].  Целесообразно, чтобы  процесс тестирования  выполнялся  не  только  после завершения описания устройства, а и в процессе создания описаний компонентов и устройства в целом. Но, к сожалению, большое число разработчиков   лишь после завершения описания проекта (а зачастую и после  его компиляции) начинает наконец тестировать проект, что приводит к неоправданным затратам времени на создание проекта. Практически для всех устройств приходится создавать специальные тестовые последовательности (TestBench). Лишь для комбинационных схем упрощенная тестовая последовательность может совпадать с таблицей  истинности для входных сигналов. Конечно, в отдельных фрагментах тест соответствует таблице истинности, и таблицы истинности являются основой для создания тестов. Для проверки, как правило,  создается не один тестовый пример, а целый ряд тестов, соответствующих различным вариантам работы устройства (как в штатных, так и в нештатных ситуациях).

Далее в  разделе  6.3  рассматривается процедура проектирования на примере устройства, реализующего  алгоритм умножения двух 4-х разрядных чисел в позиционном двоичном представлении.

Пример проектирования

 

Чаще всего разработчик получает от заказчика пожелания на разрабатываемое изделие в самом общем виде. Практически любое ТЗ (техническое задание) требует совместной работы заказчика и проектировщика над заданием. Пусть заказчик просит разработать устройство, которое  обеспечивает умножение двух двоичных кодов Din1, Din2.  Уточняем, что достаточно умножать 4-х разрядные коды (хотя в дальнейшем может потребоваться увеличение разрядности одного или даже обоих операндов), а результат должен быть 8 разрядов. Устройство необходимо реализовать на ПЛИС с минимальными аппаратными затратами и со средними временными параметрами. Анализируя различные способы реализации устройства, приходим к алгоритму умножения двух n-разрядных чисел в позиционном двоичном представлении, которое  представляется соотношением:                                                                                                            

                                                                                                        (6.1)

где  x – множимое, y_i – i-ый разряд множителя (нумерация с младших разрядов) , Z – произведение.

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

Повторяющиеся вычисления (в данном случае накопление суммы)  удобно приводить к рекуррентной форме:

z = 0;         i = 0;

xp= x; yp= y;                                                                               (6.2)

metka: z= z+ xp · yp(i);

xp = xp ·* 2;

i = i + 1;

if i <n goto metka;,

где i   =  от 0 до n – 1  – номер шага исполнения команды.

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

В рассматриваемом примере проблемы интерфейса могут выглядеть, например, следующим образом. Работа устройства осуществляется тактировано. Входной сигнал тактирования Clk.  В исходное состояние устройство переходит при подаче сигнала Reset, длительность сигнала 2 такта. Напомним, что отказ от начального сброса может  привести к тому, что при включении система окажется в неопределенном, или даже запрещенном состоянии, и будет неработоспособна.

Будем ориентироваться на создание описания, максимально пригодного для синтеза устройства произвольной разрядности, определяя разрядность операндов как параметр настройки (GENERIC n : INTEGER). Сомножители  подаются не мультиплексировано, а параллельно по двум специально выделенным шинам. Каждый цикл работы устройства начинается после подачи сигнала Start, значения   входных данных должны быть установлены до подачи сигнала Start   и стабильны в течение не менее двух тактов.  Пара сигналов Start  и Busy образуют пару квитирующих сигналов (как  было описано выше) для входной информации. Изменение сигнала Busy говорит о том, что система приступила к решению поставленной задачи.   О готовности выходных данных говорит сигнал Ready, выдаваемый устройством после завершения планируемых преобразований. Разрядность выходных данных – 2 × n  бит. Выходные данные остаются стабильными, до тех пор, пока  не будет получен от приемника данных ответный  сигнал Ack, по которому  сбрасывается флаги   Ready и Busy, а процедура преобразования может быть  повторена. Пара сигналов Ready и Ack образуют пару квитирующих сигналов, предназначенных для синхронизации разрабатываемого устройства с приемниками результатов преобразования входной информации.

Рис. 6.1 Интерфейс разрабатываемой системы

 

На рис. 6.1 приведена схема системы, включающей разрабатываемое устройство. Чаще всего подобная система (её модели или прототипы) используется на различных этапах проектирования устройства для тестирования работоспособности проекта. На этом этапе проектирования разработчик подготавливает тестовые примеры и составляет программу тестирования устройства с простейшей реализацией поставленной задачи. Чаще всего нас интересует правильность функционирования системы без учета временных требований к проекту.

Если заказчика устраивает подобная формулировка задания на устройство, то можно переходить к разработке собственно операционного устройства. Ранее были разработаны и широко применялись формальные методы перехода от обобщенного  алгоритмического задания системы к структуре операционного блока [10] и [11]. В основе методов перехода лежит представление схемы обобщенного алгоритма совокупностью последовательно исполняемых операторов: так называемых операторных вершин, отображающих преобразования данных, и условных вершин, отражающих проверки входов и результатов исполнения предыдущих шагов с целью выбора пути продолжения исполнения. На основании анализа требуемого набора операторов выделяют набор используемых функциональных модулей. Операторная вершина может содержать либо одну, либо несколько совместимых во времени операций. Объединение нескольких операций в одной операторной вершине соответствует их одновременному исполнению и может стать средством повышения производительности проектируемого устройства. С другой стороны, разнесение совместимых операций в несколько последовательных операторных вершин позволяет реализовать их исполнение на одних и тех же компонентах, т. е. сократить количество оборудования за счет потери быстродействия. Последним этапом разработки является создание  алгоритма управляющего конечного автомата.  Общее правило разметки состояний состоит в следующем [11]: входу каждой вершины схемы алгоритма,   следующей за операторной, сопоставляется состояние управляющего автомата. Составление схемы алгоритма достаточно интуитивно.

Современные системы автоматического проектирования существенно упростили процедуру проектирования особенно для систем средней степени сложности. Для определения состава операционного блока необходимо,  анализируя требуемый набор действий и сопоставляя его с набором возможных реализаций в целевой микросхеме и библиотеке САПР, выбирать набор операционных регистров и преобразователей. Для реализации совокупностей операций, не представленных в библиотеке, следует предусмотреть разработку специализированных блоков, предполагая их описание в процессе создания проекта. Как правило, выбор не однозначен. Прежде всего, существует два варианта выбора: описание, хранящееся в библиотеке САПР, или функциональное описание интересующего элемента самим разработчиком. В первом случае библиотеки хранят оптимизированные под данное семейство (а иногда и данного типа ИС) описания. Работа с библиотечными элементами, как правило,  поддерживается специальными программами – менеджерами. Подробное описание элементов часто даже не включается в проект и не затрудняет чтение всего проекта. Во втором варианте разработчик в большинстве случаев создает обобщенное и не учитывающее специфических особенностей ИС описание элемента предлагаемого к реализации в выбранном проекте.  Вместе с тем, разработчик может создать описания одного и того же элемента с различной степени детализации. Чем ниже уровень описания оборудования, тем больше гибкость проектировщика в выборе окончательных решений, однако, при этом может резко возрастать текстовая сложность описания проекта. Более глубокое   участие проектировщика в разработке отдельных узлов системы (при наличии соответствующей квалификации) позволяет, как правило, реализовать более эффективную систему (наибольший выигрыш в этих ситуациях достигается во временной области, а не в  объеме затраченной аппаратуры), хотя и ценой больших временных затрат на само проектирование. В любом случае каждый операционный блок устройства должен иметь своё VHDL описание, кроме того, потребуется VHDL описание устройства управления, VHDL описание устройства целиком. Также необходимо описание  структуры тестирующей системы (краткие сведения о разработке такого описания  см. в разд. 3).

При разработке структуры проекта операционные устройства и их свойства прямо следуют из анализа базового алгоритма (формулы 6.1 и 6.2). В структуре устройства, во-первых, лучше всего определить два приемных регистра данных. Если даже потребовать от заказчика стабильности данных одного из операндов, то потребуется мультиплексор для смещения данных. Альтернативный вариант может ориентироваться на два регистра сдвига для двух операндов (и Reg_Shift_R).  В качестве регистра  xp (множимого) удобно выбрать загружаемый регистр сдвига со сдвигом в сторону старших разрядов (Reg_Shift_L). В качестве регистра  yp (множителя) необходимо выбрать загружаемый регистр сдвига со сдвигом в сторону младших разрядов (Reg_Shift_R). В этом случае бит множителя, учитывающийся в алгоритме, в каждом текущем цикле будет размещаться в младшем разряде регистра (Bit_Multi). Умножение   содержимого на этот бит реализуется выбором пути в алгоритме – выполнять или не выполнять прибавление частных произведений (Partial_Sym).  Для суммирования   в данном устройстве необходим регистр-аккумулятор (в алгоритме – z ), накапливающий частные произведения (Reg_Accum). Важность этого элемента (вернее важность его быстродействия) для свойств всего проекта заставляет ориентироваться на библиотечный вариант  реализации. Естественно, в схеме   необходим счетчик тактов умножения (Count_Bit), вырабатывающий сигнал Equal_Zero, который сигнализирует об окончании процедуры умножения. Последним  (в рассмотрении, но не в важности) является автомат, управляющий работой системы (Cnt_Avt). Окончательная структурная схема множительного устройства приведена на рис. 6.2.  

 

 

 

Рис. 6.2. Структурная схема умножителя

 

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

Работа умножителя выполняется под управлением автомата, алгоритм работы которого приведен на рис. 6.3.  Рисунок соответствует внешнему виду задания описания автомата  в графическом редакторе САПР HDL Designer Series фирмы Mentor Graphics. Из внешнего вида автомата видно, что это классический вариант автомата Мура. Для всех 4-х выходных сигналов можно выбрать комбинационные схемы их формирования с нулевыми значениями по умолчанию.  После поступления запускающего сигнала Start начинается работа системы. Сигнал Load, формируемый в первом рабочем состоянии Unit,   играет роль сигнала фиксирующего входные данные в регистрах Reg_Shift_L и Reg_Shift_R. Переход в состояние Unit   приводит к установлению в 1  сигнала Busy, сигнализирующего о начале работы системы. Дальше автомат переходит к циклическому исполнению состояния Count, в ходе исполнения которого выполняются действия по реализации алгоритма суммирования в соответствии с формулой (6.1). При этом прибавлением частных произведений  к результату управляет сигнал Bit_Multi с подсчетом в счетчике Count_Bit числа выполненных тактов до достижения последнего (сигнал Equal_Zero). После этого осуществляется переход в состояние Final с формированием выходного сигнала Ready, сигнализирующего о готовности результата. Из состояния Final автомат переходит в исходное состояние  после поступления  сигнала Ack. После перехода сбрасывается сигнал занятости системы Busy.

 

 

Рис 6.3 Алгоритм работы устройства управления умножителя

 

Рассмотрим особенности реализации на языке VHDL основных узлов системы.

Программа (листинг 6.1), описывающая регистр сдвига вправо Reg_Shift_R, достаточно традиционна и выполнена в соответствии с рекомендациями раздела 4 в форме двух операторов. Первый  параллельный оператор PROCESS используется  для описания запоминающей части регистра. А второй,  параллельный оператор назначения сигнала, определяет  комбинационную часть регистра. Третий оператор программы служит для определения интерфейсного сигнала схемы – Bit_Multi . Новым элементом программы является определение  параметра настройки (GENERIC m : INTEGER)[O6] , который позволит изменять разрядность всех элементов схемы путем изменения значения лишь в одной декларации файла  верхнего  уровня иерархии. Другой новой синтаксической конструкцией является фрагмент (OTHERS => '0'), позволяющий задать значение константе заранее неизвестной размерности.

Листинг 6.1

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

USE ieee.std_logic_arith.ALL;

USE ieee.std_logic_unsigned.ALL;

ENTITY Reg_Shift_R IS -- entity declaration

GENERIC ( m   :   INTEGER);

PORT (                     

Reset, Clk              : IN std_logic;

Load, En_Right    : IN std_logic;

D_in                      : IN std_logic_vector(2**m - 1 DOWNTO 0);

Bit_Multi               : OUT std_logic

);

END Reg_Shift_R;

 

ARCHITECTURE a OF Reg_Shift_R IS

SIGNAL   Q         : std_logic_vector(2**m - 1 DOWNTO 0);

SIGNAL Q_int    : std_logic_vector(2**m - 1 DOWNTO 0);

BEGIN

base: PROCESS (Reset, Clk, Q, Q_int)

     BEGIN

                   IF Reset ='1' THEN Q <=   (OTHERS => '0');

ELSIF Clk'event AND Clk = '1'THEN

IF Load= '1' OR En_Right   = ’1’ THEN Q <= Q_int;

ELSE Q <= Q;

END IF;

ELSE Q <= Q;

END IF;

END PROCESS base;

 

Q_int <= D_in WHEN Load= '1' ELSE '1' &   Q(2**m - 1 DOWNTO 1) WHEN En_Right ='1' ELSE  Q;

Bit_Multi <= Q(0);

 

END;

 

Программа (листинг 6.2), описывающая регистр сдвига влево Reg_Shift_ L, выполнена аналогично предыдущей программе. Основной особенностью является необходимость иметь разрядность в два раза большую разрядности входных данных.  Выполнение этого требования может быть реализовано различными способами.  Один из них заключается во  введении фиктивного  внутреннего массива Q_tmp ,используемого при вводе исходных данных и объединяемого с основным при помощи операции катенации данных &.

Листинг 6.2

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

USE ieee.std_logic_arith.ALL;

USE ieee.std_logic_unsigned.ALL;

ENTITY Reg_Shift_L IS

GENERIC ( m   :   INTEGER);

PORT (                     

Reset, Clk              : IN std_logic;

Load, En_Left             : IN std_logic;

D_in                      : IN std_logic_vector(2**m - 1 DOWNTO 0);

Q                           : BUFFER std_logic_vector(2*(2**m) - 1 DOWNTO 0)

);

END Reg_Shift_L;

 

ARCHITECTURE a OF Reg_Shift_L  IS

SIGNAL Q_int    : std_logic_vector(2*(2**m) - 1  DOWNTO 0);

SIGNAL Q_tmp  : std_logic_vector(2**m-1  DOWNTO 0);

BEGIN

base: PROCESS (Reset, Clk, Q, Q_int)

     BEGIN

                   IF Reset ='1' THEN Q <=   (OTHERS => '0');

ELSIF Clk'event AND Clk = '1'THEN

IF Load= '1' ’OR En_Left   = ’1THEN Q <= Q_int;

ELSE   Q <= Q;

END IF;

ELSE Q <= Q;

END IF;

END PROCESS base;

 

Q_tmp <= (OTHERS => '0');

Q_int <= Q_tmp & D_in WHEN Load= '1' ELSE Q(2*(2**m)-2 DOWNTO 0)&'0'  

                               WHEN En_Left = '1' ELSE  Q;

 

END;

 

Программа счетчика тактов умножения (листинг 6.3),  в соответствии с рекомендациями раздела 4, содержит два параллельных оператора. Особенностью реализации счетчиков, предназначенных для внутренних целей (подсчета тех или иных событий), является их описание в форме вычитающих . Подобная организация позволяет более экономно построить фрагмент, отвечающий за определение достижения заданной границы счета (в случае вычитания это всегда все нули). Счетчик дополнен схемой определения границы, это PROCESS по имени Zero, формирующий выходной сигнал Equal_Zero.

 

Листинг 6.3

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

USE ieee.std_logic_arith.ALL;

USE ieee.std_logic_unsigned.ALL;

 

ENTITY Count_Bit IS

GENERIC ( m: INTEGER);  

PORT(

     Clk , En     : IN        std_logic;

     Load       : IN        std_logic;

     Equal_Zero : OUT std_logic

 );

END Count_Bit;

 

ARCHITECTURE AcntTakt OF Count_Bit IS

SIGNAL Count    : std_logic_vector (m-1 DOWNTO 0);

SIGNAL Count_Int : std_logic_vector (m-1 DOWNTO 0);

BEGIN

       RegCmd:PROCESS ( Clk,  Count, Count_Int)

       BEGIN

                   IF Clk = '1' AND Clk'EVENT THEN Count <= Count_Int;

                   END IF;

       END PROCESS RegCmd;

 

Count_Int <= (OTHERS => '1') WHEN Load = '1' ELSE Count - '1' WHEN En = '1' ELSE Count;

 

Zero: PROCESS ( Clk,  Count)

                   VARIABLE i: INTEGER;

                   BEGIN

                              Equal_Zero <= '1';

                              FOR i IN m-1 DOWNTO 0 LOOP

                                          IF (Count(i) = '1') THEN Equal_Zero <= '0'; EXIT;

                                     END IF;

                              END LOOP;

       END PROCESS Zero;

 

END AcntTakt;

 

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

 

Листинг 6.4

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

USE ieee.std_logic_arith.ALL;

USE ieee.std_logic_unsigned.ALL;

 

 

ENTITY Reg_Accum IS

GENERIC (m : INTEGER);

PORT (         

       Reset, Clk             : IN std_logic;

       En                    : IN std_logic;

       D_in                      : IN std_logic_vector(2*(2**m)-1 DOWNTO 0);

       Q                           : BUFFER std_logic_vector(2*(2**m)-1 DOWNTO 0)

);

END Reg_Accum;

 

ARCHITECTURE a OF Reg_Accum IS

SIGNAL Q_int    : std_logic_vector(2*(2**m)-1  DOWNTO 0);

 

BEGIN

       base: PROCESS (Clk, Reset, Q, Q_int)

     BEGIN

                   IF Reset ='1' THEN Q <= (OTHERS => '0');

                   ELSIF Clk'event AND Clk = '1' THEN Q <= Q_int;

                   ELSE Q <= Q;

                   END IF;

       END PROCESS base;

 

       Q_int <= Q + D_in WHEN En = '1' ELSE Q;

 

END;

 

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

При ориентации на структурные компоненты   библиотеки параметризованных модулей  системы  QUARTUS II обычно удаётся  получить компонент с максимальным быстродействием для данного вида ПЛИС.  Прототипы и назначения портов этих модулей можно  найти, используя   пункты HELP/MEGAFUNCTIONS/LPM  системы QUARUS II. Конструкции GENERIC MAP и PORT MAP   оператора вхождения компонента должны учитывать конкретный вариант подключения библиотечного элемента. Недостатком ориентации на  стандартную библиотеку определенной фирмы может являться невозможность использования проекта с ПЛИС других фирм. В некоторых случаях библиотечный элемент является функционально избыточным, не видны функциональные действия внутри модуля и т.п.

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

Программа верхнего уровня иерархии (листинг 6.5),   описывающая общую схему умножителя, приводится ниже. Структура и состав таких программ достаточно традиционны и совпадают с приведенными в разделе 3 данных указаний. В декларации ENTITY   заданы внешние управляющие сигналы – начальный сброс (Reset), тактовый сигнал (Clk), запуск одиночной операции умножения (Start), а также входные и выходные информационные сигналы. Новым  элементом является элемент настройки   GENERIC  (m : INTEGER := 2); в котором и назначается разрядность умножителя. Хотя и возможно такое формирование настроек, чтобы было возможно построение устройств с  целых чисел (2, 3, 4, 5), в данном проекте выбрано формирование настроек, обеспечивающих реализацию умножителей с разрядностью, являющейся степенью числа 2 (т.е. 2, 4, 8, 16, 32, …), что чаще всего и требуется в  реальных разработках.

Раздел объявления компонентов архитектурного тела представляет используемые типовые операционные узлы:  сдвигающие регистры (Reg_Shift_L и Reg_Shift_R), накапливающий сумматор (Reg_Accum), счетчик тактов (Count_Bit), а также специально разработанный компонент – устройство управления (Cnt_Avt).

Главная часть архитектурного телав примересодержит операторы  вхождений компонентов,  то есть задает их соединения и один оператор, описывающий схему И для сигналов  Bit_Multi и En .

 

Листинг 6.5

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

USE ieee.std_logic_arith.ALL;

USE ieee.std_logic_unsigned.ALL;

 

 

ENTITY Multiply IS

GENERIC  (m : INTEGER:= 2);

PORT (

Reset, Clk             : IN std_logic;

Start                    : IN std_logic;

Busy                    : OUT std_logic;       

     D_In1, D_In2        : IN std_logic_vector (2**m - 1 DOWNTO 0);

     D_Out                    : OUT std_logic_vector (2*(2**m) - 1 DOWNTO 0);

     Ready                    : OUT std_logic;

       Ack                    : IN std_logic

);

END Multiply ;

 

ARCHITECTURE  structure OF Multiply   IS

 

COMPONENT Reg_Shift_R IS

       GENERIC (m : INTEGER);

       PORT (                

                   Reset, Clk  : IN std_logic;

                   Load, En_R : IN std_logic;

                   D_in           : IN std_logic_vector(m**2-1 DOWNTO 0);

       Bit_Multi   : OUT std_logic

                   );

       END  COMPONENT Reg_Shift_R;

COMPONENT Reg_Shift_L IS

       GENERIC (m : INTEGER);

       PORT (                     

                   Reset, Clk              :   IN std_logic;

                   Load, En_Left     : IN std_logic;

;                  D_in                  : IN std_logic_vector(m**2-1 DOWNTO 0);

                   Q                       : BUFFER std_logic_vector(2*(2**m)-1 DOWNTO 0)

                   );

       END  COMPONENT Reg_Shift_L;

 

COMPONENT Reg_Accum IS

       GENERIC (m : INTEGER);

       PORT (

              Reset, Clk :   IN std_logic;

              En         :   IN std_logic;         

              D_in           :   IN std_logic_vector(2*(2**m)-1 DOWNTO 0);

              Q           :   BUFFER std_logic_vector(2*(2**m)-1 DOWNTO 0)

              );

       END COMPONENT Reg_Accum;

COMPONENT Count_Bit

GENERIC   (m : INTEGER);  

PORT (

            Clk,    En   : IN        std_logic;

Load       : IN        std_logic;

Equal_Zero : OUT std_logic

                 );

END COMPONENT Count_Bit;

COMPONENT Cnt_Avt

PORT (

Reset, Clk :  IN std_logic;

              Start        :  IN std_logic;

                 Busy, En    :  OUT std_logic;

                        Equal_Zero :   IN std_logic;     

              Load, Ready :   OUT std_logic;

              Ack            :   IN std_logic

       );

END  COMPONENT Cnt_Avt;

SIGNAL Bit_Multi          : std_logic;

SIGNAL Partial_Sym     : std_logic_vector(2*(m**2) - 1 DOWNTO 0);

SIGNAL En                    : std_logic;

SIGNAL En_Add           : std_logic;

SIGNAL Load                 : std_logic;

SIGNAL Count               : std_logic_vector(m - 1 DOWNTO 0);

SIGNAL Equal_Zero                  : std_logic;

 

BEGIN

       U1 : Reg_Shift_L

       GENERIC MAP (m)

       PORT MAP(

                   Reset          =>  Reset,

                   Clk             =>  Clk,

                   Load          =>  Load,

                   En_Left     =>  En,

                   D_in           =>  D_In1,

                   Q                =>   Partial_Sym

                   );

-- ENDReg_Shift_L;

       U2: Reg_Shift_R

       GENERIC MAP (m)              

       PORT MAP (      

                   Reset          =>  Reset,

                   Clk             =>  Clk,

                   Load          =>  Load,

                   En_Right   =>  En,

                   D_in           =>  D_In2,

                   Bit_Multi   =>   Bit_Multi  

                   );

       -- ENDReg_Shift_R;

       En_Add <= '1' WHEN Bit_Multi = '1' AND En = '1' ELSE '0';

      

       U3: Reg_Accum

       GENERIC MAP (m)

       PORT MAP (

                   Reset          =>  Load,

                   Clk             =>  Clk,

                   En              =>  En_Add,

                   D_in           =>  Partial_Sym,

                   Q                =>  D_Out

                   );

       -- ENDReg_Accum;

U4: Cnt_Avt

       PORT MAP (

                   Reset       => Reset,

                   Clk            => Clk,     

                   Start                 => Start,

                   Load                     => Load,

                   En       => En,

                   Equal_Zero => Equal_Zero,

                   Busy                     => Busy,  

                   Ready       => Ready,

                   Ack                       => Ack

                   );

       --    END Cnt_Avt

                             

       U5: Count_Bit

       GENERIC MAP(m)  

       PORT MAP(

            Load       =>   Load,

                   Clk            =>   Clk,

            En             =>   En,

            Equal_Zero =>   Equal_Zero

                 );

       -- END Count_Bit;

END structure;