ch10.05.htm
来自「介绍asci设计的一本书」· HTM 代码 · 共 241 行
HTM
241 行
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac">
<TITLE> 10.5 Entities and Architectures</TITLE>
</HEAD><!--#include file="top.html"--><!--#include file="header.html"--><br><!--#include file="AmazonAsic.html"-->
<P><A NAME="pgfId=112386"></A><A HREF="CH10.htm">Chapter start</A> <A HREF="CH10.04.htm">Previous page</A> <A HREF="CH10.06.htm">Next page</A></P>
<H2>10.5 Entities and Architectures</H2>
<P><P CLASS="BodyAfterHead"><A NAME="pgfId=1204"></A>The highest-level VHDL
construct is the design file [<A HREF="../../VHDL/LRM/HTML/1076_11.HTM#11">VHDL
LRM11.1</A>]. A design file contains design units that contain one or more
library units. Library units in turn contain: entity, configuration, and
package declarations (primary units); and architecture and package bodies
(secondary units).</P>
<PRE>design_file ::=
{library_clause|use_clause} library_unit
{{library_clause|use_clause} library_unit}
library_unit ::= primary_unit|secondary_unit
primary_unit ::=
entity_declaration|configuration_declaration|package_declaration
secondary_unit ::= architecture_body|package_body</PRE>
<P><P CLASS="BodyAfterHead"><A NAME="pgfId=11086"></A>Using the written
language analogy: a VHDL library unit is a "book," a VHDL design
file is a "bookshelf," and a VHDL library is a collection of bookshelves.
A VHDL primary unit is a little like the chapter title and contents that
appear on the first page of each chapter in this book and a VHDL secondary
unit is like the chapter contents (though this is stretching our analogy
a little far).</P>
<P><P CLASS="Body"><A NAME="pgfId=278745"></A>I shall describe the very
important concepts of entities and architectures in this section and then
cover libraries, packages, and package bodies. You define an entity, a black
box, using an entity declaration [<A HREF="../../VHDL/LRM/HTML/1076_1.HTM#1.1">VHDL
LRM1.1</A>]. This is the BNF definition:</P>
<PRE>entity_declaration ::=
<B>entity</B> identifier <B>is</B>
[<B>generic</B> (<I>formal_generic_</I>interface_list);]
[<B>port</B> (<I>formal_port_</I>interface_list);]
{entity_declarative_item}
[<B>begin</B>
{[label:] [postponed] assertion ;
|[label:] [postponed] <I>passive_</I>procedure_call ;
|<I>passive_</I>process_statement}]
<B>end</B> <U>[entity]</U> [<I>entity_</I>identifier] ;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=99944"></A>The following is an example
of an entity declaration for a black box with two inputs and an output:</P>
<PRE><B>entity</B> Half_Adder <B>is </B>
<B> port</B> (X, Y : <B>in</B> BIT := '0'; Sum, Cout : <B>out</B> BIT); -- formals
<B>end</B>;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=11153"></A>Matching the parts of this
code with the constructs in BNF [10.7] you can see that the <CODE>identifier</CODE>
is <CODE>Half_Adder</CODE> and that <CODE>(X, Y: <B>in</B> BIT := '0'; Sum,
Cout: <B>out</B> BIT)</CODE> corresponds to <CODE>(port_interface_list)</CODE>
in the BNF. The ports <CODE>X</CODE>, <CODE>Y</CODE>, <CODE>Sum</CODE>,
and <CODE>Cout</CODE> are formal ports or formals. This particular entity
<CODE>Half_Adder</CODE> does not use any of the other optional constructs
that are legal in an entity declaration.</P>
<P><P CLASS="Body"><A NAME="pgfId=278523"></A>The architecture body [<A HREF="../../VHDL/LRM/HTML/1076_1.HTM#1.2">VHDL LRM1.2</A>] describes what an entity
does, or the contents of the black box (it is architecture body and not
architecture declaration).</P>
<PRE>architecture_body ::=
<B>architecture</B> identifier <B>of</B> <I>entity_</I>name <B>is</B>
{block_declarative_item}
<B>begin</B>
{concurrent_statement}
<B>end</B> <U>[architecture]</U> [<I>architecture_</I>identifier] ;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=1222"></A>For example, the following architecture
body (I shall just call it an architecture from now on) describes the contents
of the entity <CODE>Half_Adder</CODE> :</P>
<PRE><B>architecture</B> Behave <B>of</B> Half_Adder <B>is</B>
<B>begin</B> Sum <= X <B>xor</B> Y; Cout <= X <B>and</B> Y;
<B>end </B>Behave;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=43676"></A>We use the same signal names
(the formals: <CODE>Sum</CODE> , <CODE>X</CODE> , <CODE>Y</CODE> , and <CODE>Cout</CODE>
) in the architecture as we use in the entity (we say the signals of the
"parent" entity are visible inside the architecture "child").
An architecture can refer to other entity-architecture pairs--so we can
nest black boxes. We shall often refer to an entity-architecture pair as
<CODE>entity(architecture)</CODE>. For example, the architecture <CODE>Behave</CODE>
of the entity <CODE>Half_Adder</CODE> is <CODE>Half_Adder(Behave)</CODE>.</P>
<P><P CLASS="Body"><A NAME="pgfId=122425"></A>Why would we want to describe
the outside of a black box (an entity) separately from the description of
its contents (its architecture)? Separating the two makes it easier to move
between different architectures for an entity (there must be at least one).
For example, one architecture may model an entity at a behavioral level,
while another architecture may be a structural model.</P>
<P><P CLASS="Body"><A NAME="pgfId=122356"></A>A structural model that uses
an entity in an architecture must declare that entity and its interface
using a component declaration as follows [<A HREF="../../VHDL/LRM/HTML/1076_4.HTM#4.5">VHDL
LRM4.5</A>]:</P>
<PRE>component_declaration ::=
<B>component</B> identifier <U>[is]</U>
[<B>generic</B> (<I>local_generic_</I>interface_list);]
[<B>port</B> (<I>local_port_</I>interface_list);]
<B>end</B> <B>component</B> <U>[<I>component_</I>identifier]</U>;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=9972"></A>For example, the following architecture,
<CODE>Netlist</CODE> , is a structural version of the behavioral architecture,
<CODE>Behave</CODE> :</P>
<PRE><B>architecture</B> Netlist <B>of</B> Half_Adder <B>is</B>
<B>component</B> MyXor <B>port</B> (A_Xor,B_Xor : <B>in</B> BIT; Z_Xor : <B>out</B> BIT);
<B>end</B> <B>component</B>; -- component with locals
<B>component</B> MyAnd <B>port</B> (A_And,B_And : <B>in</B> BIT; Z_And : <B>out</B> BIT);
<B>end</B> <B>component</B>; -- component with locals
<B>begin</B>
Xor1: MyXor <B>port</B> <B>map</B> (X, Y, Sum); -- instance with actuals
And1 : MyAnd <B>port</B> <B>map</B> (X, Y, Cout); -- instance with actuals
<B>end</B>;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=107262"></A>Notice that:</P>
<UL>
<LI><A NAME="pgfId=100192"></A>We declare the components: <CODE>MyAnd,
MyXor </CODE>and their local ports (or locals): <CODE>A_Xor</CODE>, <CODE>B_Xor</CODE>,
<CODE>Z_Xor</CODE>, <CODE>A_And</CODE>, <CODE>B_And</CODE>, <CODE>Z_And</CODE>.
<LI><A NAME="pgfId=100195"></A>We instantiate the components with instance
names:<CODE> And1 </CODE>and<CODE> Xor1</CODE>.
<LI><A NAME="pgfId=100196"></A>We connect instances using actual ports
(or actuals):<CODE> X</CODE>, <CODE>Y</CODE> , <CODE>Sum</CODE> , <CODE>Cout</CODE>.
</UL>
<P><P CLASS="Body"><A NAME="pgfId=428199"></A>Next we define the entities
and architectures that we shall use for the components <CODE>MyAnd</CODE>
and <CODE>MyXor</CODE> . You can think of an entity-architecture pair (and
its formal ports) as a data-book specification for a logic cell; the component
(and its local ports) corresponds to a software model for the logic cell;
and an instance (and its actual ports) is the logic cell.</P>
<P><P CLASS="Body"><A NAME="pgfId=428200"></A>We do not need to write VHDL
code for <CODE>MyAnd</CODE> and <CODE>MyXor</CODE> ; the code is provided
as a technology library (also called an ASIC vendor library because it is
often sold or distributed by the ASIC company that will manufacture the
chip--the ASIC vendor--and not the software company):</P>
<PRE>-- These definitions are part of a technology library:
<B>entity</B> AndGate <B>is</B>
<B>port</B> (And_in_1, And_in_2 : <B>in</B> BIT; And_out : <B>out</B> BIT); -- formals
<B>end</B>;
<B>architecture</B> Simple <B>of</B> AndGate <B>is</B>
<B>begin</B> And_out <= And_in_1 <B>and</B> And_in_2;
<B>end</B>;
<B>entity</B> XorGate <B>is</B>
<B>port</B> (Xor_in_1, Xor_in_2 : <B>in</B> BIT; Xor_out : <B>out</B> BIT); -- formals
<B>end</B>;
<B>architecture</B> Simple <B>of</B> XorGate <B>is</B>
<B>begin</B> Xor_out <= Xor_in_1 <B>xor </B>Xor_in_2;
<B>end</B>;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=5204"></A>If we keep the description of
a circuit's interface<CODE> </CODE>(the <CODE>entity</CODE> ) separate from
its contents (the <CODE>architecture</CODE> ), we need a way to link or
bind them together. A configuration declaration [<A HREF="../../VHDL/LRM/HTML/1076_1.HTM#1.3">VHDL
LRM1.3</A>] binds entities and architectures.</P>
<PRE>configuration_declaration ::=
<B>configuration</B> identifier <B>of</B> <I>entity_</I>name <B>is</B>
{use_clause|attribute_specification<U>|group_declaration</U>}
block_configuration
<B>end</B> <U>[configuration]</U> [<I>configuration_</I>identifier] ;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=122371"></A>An entity-architecture pair
is a design entity. The following configuration declaration defines which
design entities we wish to use and associates the formal ports (from the
entity declaration) with the local ports (from the component declaration):</P>
<PRE><B>configuration</B> Simplest <B>of</B> Half_Adder <B>is</B>
<B>use</B> work.<B>all</B>;
<B>for</B> Netlist
<B>for</B> And1 : MyAnd <B>use</B> <B>entity</B> AndGate(Simple)
<B>port</B> <B>map</B> -- association: formals => locals
(And_in_1 => A_And, And_in_2 => B_And, And_out => Z_And);
<B>end</B> <B>for</B>;
<B>for</B> Xor1 : MyXor <B>use entity</B> XorGate(Simple)
<B>port</B> <B>map</B>
(Xor_in_1 => A_Xor, Xor_in_2 => B_Xor, Xor_out => Z_Xor);
<B>end</B> <B>for</B>;
<B>end</B> <B>for</B>;
<B>end</B>;</PRE>
<P><P CLASS="Body"><A NAME="pgfId=255921"></A>Figure 10.1 diagrams
the use of entities, architectures, components, and configurations. This
figure seems very complicated, but there are two reasons that VHDL works
this way:</P>
<UL>
<LI><A NAME="pgfId=255922"></A>Separating the entity, architecture, component,
and configuration makes it easier to reuse code and change libraries. All
we have to do is change names in the port maps and configuration declaration.
<LI><A NAME="pgfId=29933"></A>We only have to alter and reanalyze the configuration
declaration to change which architectures we use in a model--giving us
a fast debug cycle.
</UL>
<TABLE BORDER="1" CELLSPACING="2" CELLPADDING="2">
<TR>
<TD> <P CLASS="TableFigure"><A NAME="pgfId=105882"></A><A HREF="../../Figures/shockwave/ch10/f1001.FHC"><IMG SRC="CH10-10.gif" ALIGN="BASELINE" WIDTH="446" HEIGHT="384" NATURALSIZEFLAG="3"></A> </TD></TR>
<TR>
<TD> <P CLASS="TableFigureTitle"><A NAME="pgfId=105885"></A>FIGURE 10.1
Entities, architectures, components, ports, port maps, and configurations.</TD></TR>
</TABLE>
<P><P CLASS="Body"><A NAME="pgfId=113968"></A>You can think of design units,
the analyzed entity-architecture pairs, as compiled object-code modules.
The configuration then determines which object-code modules are linked together
to form executable binary code.</P>
<P><P CLASS="Body"><A NAME="pgfId=255927"></A>You may also think of an entity
as a block diagram, an architecture for an entity a more detailed circuit
schematic for the block diagram, and a configuration as a parts list of
the circuit components with their part numbers and manufacturers (also known
as a BOM for bill of materials, rather like a shopping list). Most manufacturers
(including the U.S. DoD) use schematics and BOMs as control documents for
electronic systems. This is part of the rationale behind the structure of
VHDL.</P>
<P><HR ALIGN="LEFT"></P>
<P><A HREF="CH10.htm">Chapter start</A> <A HREF="CH10.04.htm">Previous page</A> <A HREF="CH10.06.htm">Next page</A>
</BODY>
<!--#include file="Copyright.html"--><!--#include file="footer.html"-->
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?