Определение Структуры Системы

Действительно ли нам нужен VHDL? Представление Системы в VHDL: Единицы Проекта Объекты VHDL:Сигнал Спецификация Интерфейса Системы Конструкции VHDL для Описания Поведения Системы Описание Поведения при помощи Процессов Многократные Процессы в Архитектуре Определение Структуры Системы Испытание Проекта при помощи Испытательного стенда

ГЛАВА 8

Определение Структуры Системы

Содержание Главы 8

8.1. Краткий обзор Главы

8.2. Структурные Описания

8.2.1. Введение

8.2.2. Элементы Структурных Описаний

8.2.3. Компоненты и Составляющие Требований

8.2.4. Отображение Порта

8.3. Реализация Прямого Объекта

8.3.1. Прямая Реализация

8.3.2. Позиционная Ассоциация Порта

8.3.3. Именованная Ассоциация Порта

8.3.4. Сложные Порты и Сигналы

8.3.5. Порты без Связей

8.4. Компоненты и Конфигурации

8.4.1. Введение в Компоненты

8.4.2. Компоненты Деклараций

8.4.3. Компонент Реализаций

8.4.4. Конфигурации

Резюме

8.1. Краткий обзор главы

Определение систем в VHDL требует описания их ожидаемого поведения. Вы можете также описывать их внутреннюю структуру в форме связанных модулей. Секция 2 представляет основные концепции структурных спецификаций: компоненты, инстоляция и назначение портов.

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

Секция 4 объясняет инстоляцию компонент. Она показывает то, что должно быть сделано для того, чтобы использовать эти компоненты более гибко, что является более трудным путем определения структур VHDL. Также будут представлены концепции конфигурации и связывания.

8.2.1. Введение

Ключевые вопросы:

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

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

Примеры:

-- behavioral specification

-- of AND gate

entity and_b is

port (a,b : in bit;

y : out bit);

end and_b;

architecture b_arch of and_b is

begin

Y <= a and b;

end b_arch;

-- structural specification

-- of two-gate circuit

entity gates_s is

port (X1,X2,X3: in bit;

Y: out bit);

end gates_s;

architecture s_arch of gates_s is

component and_b

port (a,b : in bit;

y : out bit);

end component and_b;

signal y_temp : bit;

begin

U1: and_b port map (X1,X2,y_temp);

U2: and_b port map (y_temp,X3,Y);

end s_arch;

Рисунок:

8.2.2. Елементы Структурных Описаний

Ключевые вопросы:

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

Компонент может быть индивидуальной системой, определенный как отдельный объект и архитектура;

Компонент может быть определен внутри архитектуры с декларацией компонента.

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

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


Сигналы, используемые в отображении порта могут быть определены как порты или как внутренности системы. Внутренности системы должны быть объявлены в декларативном разделе архитектуры. Пример:

Entity Example is

Port (X1,X2 : in bit;

Y : out bit);

end entity Example;

architecture Example_arch of Example is

-- component declaration

component and_b

port (a,b : in bit;

y : out bit);

end component and_b;

begin

-- gate1: and_b port map (X1,X2,Y);

-- good example - component gate1 instantiation

-- gate2: and_b port map (Y,X1,X2);

-- bad example

-- gate3: and_b port map (a=>X1,b=>X2,y=>Y);

-- good example - port mapping

gate4 and_b port map (b=>X2,y=>Y,a=>X1);

-- good example

. . .

end architecture Example_arch;

Рисунок:

8.2.3. Компоненты и Составляющие Требований

Ключевые вопросы:

Эффективное использование компонентов – главное преимущество структурных описаний VHDL. Весь следующий раздел будет посвящен этой теме.

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

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

Instance_name: entity work.entity_name(architecture_name)

Где 'work' – имя библиотеки, где сохранены все определяемые пользователем элементы. См. следующий раздел для уточнения деталей.

Примеры:

Рисунок:

Перечень Ключевых Слов :

Реализация компонент,Декларация компонент Заметки пользователя:

8.2.4. Отображение Порта

Ключевые вопросы:

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

Отображение, которое используется в предложенном примере, называется named association (именованная ассоциация),так как каждый порт связывается с сигналом, используя явное имя порта.


Более простая форма - позиционная ассоциация, где сигналы в отображении порта перечислены в том же самом порядке как и порты в декларации объекта компонента.

Примеры:

entity Example_beh is

port(

A : in integer;

B : in bit_vector(7 downto 0);

C : out bit_vector (3 downto 0));

end entity Example_beh;

architecture Example_beh_arch of Example_beh is

...

end Example_arch;

entity Examle_struct is

...

end entity Example_struct;

architecture Example_struct_arch of Example_struct is

signal Vec : bit_vector(7 downto 0);

...

begin

U1: entity work.Example_beh(Example_beh_arch)

port map(

A => 20, -- error for VHDL’87 only, in VHDL’93 20 is an expression

B => Vec, -- good example B is the same type as Vec

C => Vec(3 downto 0)); -– good example the same length

...

end architecture Example_struct_arch;

Рисунок:

8.3.1. Прямая Реализация

Ключевые вопросы:

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

Прямая инструкция реализации состоит из:

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

Ключевое слово entity, сопровождаемое именем библиотеки и объектом, содержащим спецификацию компонента;

Имени архитектуры, приложенного в скобках и пункта отображения порта (не обязательно) .

После того, как все определяемые пользователем спецификации откомпилированы в библиотеку work - библиотеку с компонентами реализации операторов будем называть так же work.

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

Примеры:

Ниже представленный пример показывает прямую реализацию:

Рисунок:

8.3.2. Позиционное Ассоциирование Порта

Ключевые вопросы:

Каждая спецификация отображения порта определяет связи между портами объекта (компонент) и сигналами в архитектуре, где компонент реализован.

Есть два пути отображения порта: позиционное ассоциирование порта и именованная ассоциирование порта.

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

Примеры:

entity D_FF is

port (D,CLK_S : in bit;

Q : out bit := '0';

NQ : out bit := '1' );

end entity D_FF;

architecture A_RS_FF of D_FF is

begin

BIN_P_RS_FF: process(CLK_S)

Begin

if CLK_S = '1' and CLK_S'event

then

Q <= D;

NQ <= not D;

end if;

end process;

end architecture A_RS_FF;

-- a specification of a D

-- flip-flop is given which will be

-- used by the component

-- declaration

entity COUNTER_BIN_N is

generic (N : integer := 4);

port(Q:out bit_vector(0 to N-1);

IN_1 : in bit );

end entity COUNTER_BIN_N;

architecture BEH of COUNTER_BIN_N is

component D_FF

port(D,CLK_S :in bit;

Q,NQ : out bit);

end component D_FF;

signal S : bit_vector(0 to N);

begin

S(0) <= IN_1;

G_1:for I in 0 to N-1

generate

D_Flip_Flop:D_FF port map

(S(I+1),

S(I),

Q(I),

S(I+1));

end generate;

end architecture BEH;

-- the generate statement is used

-- to define a counter of arbitrary

-- length, determined only by its

-- generic parameter

Рисунок:

8.3.3. Именованное Ассоциирование Порта

Ключевые вопросы:

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

Удобное решение этой проблемы – именованное ассоциирование . В этом типе ассоциации, сигналам поставлены в соответствие имена соответствующих портов.


Таким образом, порядок портов безразличен, и вы можете наблюдать прямые отношения между формальными портами, и фактическими сигналами.

Аассоциирование между портами и сигналами представляется символом ' = > '. Обратите внимание, что этот символ не имеет никакого отношения к символу направления информационного потока через порт.

Примеры:

entity ALU is

port(

...

OUT_SIG : out bit;

...);

end entity ALU;

architecture Structural of ALU is

signal X,Y,S,C : bit;

signal Vec : bit_vector(0 to 1)

component HalfAdder is

port (In1, In2 : in bit;

Sum, Carry : out bit);

end component HalfAdder;

begin

HA : HalfAdder port map(Sum=>S,Carry=>C,In1=>X,In2=>Y);

-- good example

HA1 : HalfAdder port map(Carry =>C,In1=>X,Sum=>S,In2=>Y);

-- good example, named port associations can be replaced

HA2 : HalfAdder port map(Sum=>S,Carry=>C,In1=>Vec(0),In2=>Vec(1));

-- good example

HA : HalfAdder port map(Sum=>S,Carry=>C,In1=>Out_SIG,In2=>Y);

-- bad example - Port types or modes do not match in component

-- instantiation

. . .

end architecture Structural;

Рисунок:

8.3.4. Сложные Порты и Сигналы

Ключевые вопросы:

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

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

Обратите внимание: Все элементы составного порта должны быть связаны с фактическим сигналом.

Также, если элементы составного порта –это индивидуально связанные сигналы, то эти ассоциирования не могут быть отделены другими ассоцированиями.

Примеры:

entity DL_e is

port (D,C : in bit

Q : out bit);

end entity DL_e;

architecture DL_a of DL_e is



begin

U1: process (C)

begin

if C='1' then Q<=D;

end if;

end process;

end DL_a;

entity INV_e is

port(X : in bit;

Y : out bit );

end INV_e;

architecture INV_a of INV_e is

begin

Y <= not X;

end INV_a; -- D flip-flop based

-- on two D latch

entity D_FF is

port(D_in : in bit;

CLK : in bit;

Q_out : out bit);

end entity D_FF;

architecture D_FF_a of D_FF is

component DL_e

port (D,C : in bit;

Q : out bit);

end component;

component INV_e

port(X : in bit;

Y : out bit );

end component;

signal q_t, inv_t, inv_t1 : bit;

begin

U1: INV_e port map(CLK,inv_t);

U2: INV_e port map(inv_t,inv_t1);

U3: DL_e port map

(D=>D_in,C=>inv_t,Q=>q_t);

U4: DL_e port map

(D=>q_t,C=>inv_t,Q=>Q_out);

end D_FF_a;

Рисунок:

8.3.5. Порты без Связей

Ключевые вопросы:

Как насчет ситуации, когда некоторые из портов не связаны? Она может быть решена, определением таких портов при отображении порта как open (открытый).

Кроме того, неиспользованный порт может быть опущен в пункте отображение порта. Это совершенно законно в VHDL, но не рекомендуется, потому что нет никакой гарантии, что отсутствующий порт опущен нарочно. Это может случаться даже с опытным VHDL проектировщиком , т.к. один из многих портов может быть просто забыт. Такую ошибку в коде очень сложно найти, поэтому рекомендуется связать состояние (open) со всеми портами в компоненте отображения порта, которые не используются в данном случае.

Примеры:

...

component Open_ent

port(

In1 : in integer;

In2 : in integer :=0;

In3 : in bit_vector; -- unconstrained array

In4 : in bit_vector(3 downto 0):="0000";

In5 : in bit_vector(3 downto 0):="0000"));

end component;

...

U1: Open_ent port map(

In1 => open, -- error, uninitialized IN port

In2 => open, -- OK.

In3 => open, -- error unconstrained array

In4 => open, -- OK.

In5(3) => open, -- error

...

Рисунок:

8.4.1. Введение в Компоненты

Ключевые вопросы:

Если именованный объект может использоваться как компонент тогда, почему мы должны рассматривать другие конструкции для той же самой цели? Достаточно ли реализаций объекта?



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

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

В такой ситуации для структурной спецификации достаточно, иметь декларацию интерфейса компонент (как требует система). Декларация интерфейса компонент называется component declaration(декларация компонент) и она расположена в декларативной части тела архитектуры (или пакета интерфейс).

Примеры:

Этот пример показывает компонент декларации:

-- Component declaration

-- could have been done in architecture body

component My_First is

generic

(const_val : integer := 4;

delay_val : time := 5 ns);-- default value, if not modified

-- generics are optional

port (

In1 : in bit;

In2 : in bit; -- port_name : direction type

Out1 : out integer -- ports are optional

);

end component My_First;

Рисунок:

8.4.2. Компонент Декларация

Ключевые вопросы:

Синтаксис компонент декларации и объекта подобны. Это не совпадение, т.к. компонент и объект играют подобную роль в определении внешних интерфейсов модулей.

Имеется, однако, важное различие между двумя разными конструкциями VHDL:

декларация объекта определяет интерфейс "реального" модуля, то есть системы или схемы, которая физически существует; система - отдельный модуль проекта и может индивидуально моделироваться, анализироваться или синтезироваться;

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

Примеры:

Рисунок:

Перечень Ключевых Слов :

Реализация компонент, Декларация компонент Заметки пользователя:

8.4.3. Компонент Реализация

Ключевые вопросы:

Компонент реализации очень похож на объект реализации. Это подобие имеет следующие главные элементы:

Двоеточие после метки реализации; эта метка обязательна, чтобы идентифицировать внутренность;

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

Component name (имя компоненты), как определено в компоненте декларации;

Предложение Generic map (общая карта), которое обеспечивает фактические значения для общих компонент. Generics может быть определен без значений, которые могут быть обеспечены в пункте общей карты. Если компонент определен без generics, это предложение может быть опущено;

Предложение Port map ( карта порта), который определен таким же образом как в случае прямой реализации.

Обратите внимание: точки с запятой нет после имени компоненты и пункта общей карты. Все выше названные элементы формируют сигнал реализации инструкции, и точка с запятой появляется после инструкции.

Примеры:

Рисунок:

8.4.4. Конфигурации

Ключевые вопросы:

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

Когда вы ближе посмотрите на связывание компонента, вы можете заметить, что оно очень похоже на прямую реализацию объекта. Однако, метод конфигурации более гибок и прост в понимании, если использовалась различная реализация похожих компонент. Если есть некоторые изменения, то они должны быть представлены в файле конфигурации, который является относительно коротким. Структурная архитектура останется неизменяемой. Использование прямой реализации потребовало бы, чтобы все изменения были представлены в коде.



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

Примеры:

entity AND_e is

port(X1,X2 : in bit;

Y : out bit );

end AND_e;

architecture AND_a of AND_e is

begin

Y <= X1 and X2;

end AND_a;

entity NAND_e is

port (X1,X2 : in bit;

Y : out bit);

end entity NAND_e;

architecture NAND_a of NAND_e is

begin

Y <= X1 nand X2;

end NAND_a; entity Gates is

port (A,B : in bit;

Y : out bit);

end gates;

architecture GATES_A of Gates is

-- components declarations

signal Y_s1,Y_s2 : bit;

begin

U1: and_e port map(A,B,Y_s1);

U2: nand_e port map(A,B,Y_s2);

U3: and_e port map(Y_s1,Y_s2,Y);

end GATES_A;

configuration gates_c of gates is

for GATES_A

for U1 : and_e

use entity work.AND_e(AND_a);

end for;

for U2 : nand_e

use entity work.NAND_e(NAND_a);

end for;

for U3 : and_e

use entity work.AND_e(AND_a);

end for;

end for;

end configuration gates_c;

Рисунок:

Резюме

1. Функциональное описание определяет систему в терминах ее операций, без упоминания о том, как это делать. Структурное описание определяет то, из чего состоит система и как ее подсистемы или компоненты связаны при помощи сигналалов.
2. Структурное описание позволяет иметь многократные уровни иерархии компонент, которые могут быть определены или как функциональным, или как структурным описанием. Однако, каждый примитив должен быть определен функциональным способом на самом низком уровне.
   
   
3. Компонент может быть как индивидуальной системой, определенной как отдельный объект и архитектура, так и определенной внутренней архитектурой с компонентом декларации. Чтобы использовать компоненты, они должны быть реализованы в структурной спецификации.
   
   
4. Компонент реализации –это основная инструкция в структурной архитектуре и подобно другим инструкциям архитектуры, ее компоненты реализованы параллельно друг другу.
   
   
5. Компонент реализации не полон без карты порта – ссылка фактического названия порта и формального порта.
   
   
   
   
6. Сигналы, используемые при отображении в порт, могут быть определены как порты или как внутренняя часть системы. Последний случай должен быть объявлен в декларативном разделе архитектуры.
   
   
7. Прямая реализация объекта - самый простой способ определить систему структурным путем. Единственное, что вам необходимо - откомпилированная спецификация компоненты, в которой будут инстолированы операторы реализации.
   
   
8. Карта порта, которая является важной частью реализации компонента, определяет связи между портами объекта (компонент) и сигналами ,заключенными в теле архитектуры (то есть где компонент реализован). Есть две формы отображения порта:
   
   
   • Позиционное ассоцирование порта, при котором сигналы перечислены в том же самом порядке, что и порты которые объявляются в декларации объекта компонента;
   • Именованное ассоциирование порта, при котором сигналы связаны с портами, используя имена порта вместо его расположения в пункте порта; ассоциация представлена символом ' = > '. Обратите внимание на то, что этот символ не имеет никакого отношения к направлению информационного потока через порт.
9. Компонент декларации определяет интерфейс "несуществующего" или "виртуального" модуля; он определен в пределах архитектуры и это скорее ожидание того, что компонент интерфейса должен быть создан быстрее, чем описание существующей схемы.
10. Компонент реализации очень похож на объект реализации. Его главные элементы: метка реализации, необязательный компонент ключевого слова - имя компонента, пункт общей карты (Generic map), который обеспечивает фактические значения для общих компонент, пункт карты порта, который определен так же как и в случае прямой реализации.
11. Декларация компоненты и ее реализации не достаточна для того, чтобы иметь окончательную спецификацию структурной архитектуры, потому что описание реализации компонентов все еще отсутствует. Информация, которая связывает компонент с реальными объектами и архитектурами, определена в конфигурации, которая является отдельным модулем проекта, и она может моделироваться, анализироваться отдельно от других модулей.

Далее>>

Содержание раздела

---

---