1. ECOM 4311—Digital System Design with VHDL
Chapter 2
Entities, Architectures, and Coding Styles

2. Objectives
Examine design entities and their entity declarations and architecture bodies in greater details
An overview of coding styles
Introducing Hierarchical design

3. Keywords
Keywords (reserved words) have a special meaning in a programming language and must be used only for their predefined purposes.
VHDL’s keywords are listed in the book
Examples are: exit not severity
access file null
after for signal
alias on function

4. Valid or invalid? 7segment_display A87372477424 Adder/Subtractor
/reset
And_or_gate
AND__OR__NOT
Kogge-Stone-Adder
Ripple&Carry_Adder
My adder

5. VHDL Identifiers
A VHDL identifier is used to identify various VHDL objects: design entities, signals, procedures, functions, processes, and so on.
Identifier (naming) rules:
Can consist of alphabet characters, numbers, and underscore
First character must be a letter (alphabet)
Last character cannot be an underscore
Consecutive underscores are not allowed
Upper and lower case are equivalent (case insensitive)
VHDL keywords cannot be used as identifiers

6. Design Units
A design unit is a VHDL construct that can be separately compiled and stored in a design library.
A design unit consists of a context clause followed by a library unit.
Compilation of a design unit defines the corresponding library unit, which is stored in a design library.
There are five kinds of library units:
• Entity declaration
• Architecture body
• Package declaration
• Package body
• Configuration declaration

7. Design Entity
ECE 448 – FPGA and ASIC Design with VHDL

8. Design Entity
A design entity is the basic unit of a hardware design. Its inputs, outputs, and the function it performs are completely defined.
A single design entity may represent the entirety of the system being designed or it may only represent a component of a larger system.
For example, a design entity can represent a single gate, a subsystem, the entire system, or any portion of hardware in between.
Multiple copies of the same design entity may appear in a larger design.

9. Design Entity Design Entity - most basic building block of a design.
entity declaration
architecture 1
architecture 2
architecture 3
design entity
Design Entity - most basic building block of a design.
One entity can have many different architectures.

10. Example: NAND Gate a b z 1 a z b

11. Example VHDL Code 3 sections to a piece of VHDL code
File extension for a VHDL file is .vhd
Name of the file should be the same as the entity name (nand_gate.vhd)
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY nand_gate IS
PORT(
a : IN STD_LOGIC;
b : IN STD_LOGIC;
z : OUT STD_LOGIC);
END nand_gate;
ARCHITECTURE model OF nand_gate IS
BEGIN
z <= a NAND b;
END model;
LIBRARY DECLARATION
ENTITY DECLARATION
ARCHITECTURE BODY

12. Entity Declaration
Entity Declaration describes the interface of the component, i.e. input and output ports.
It does not tell us how the design entity performs its function
Entity name
Port type
Port names
Semicolon
ENTITY nand_gate IS
PORT(
a : IN STD_LOGIC;
b : IN STD_LOGIC;
z : OUT STD_LOGIC );
END nand_gate;
No Semicolon after last port
Reserved words
Port modes (data flow directions)

13. Entity declaration – simplified syntax
ENTITY entity_name IS
PORT (
port_name : port_mode signal_type;
………….
port_name : port_mode signal_type);
END entity_name;

14. Ports as Data Objects
Ports are external signals and all signals are data objects.
Data objects transfer or hold values of specified types.
An entity declaration must specify each port’s type.
There are many possible types for ports. The only types we have encountered, so far, are bit and std_logic.
Data objects and types are discussed in greater detail in Chapter 3.

15. Port Modes
a port’s mode specifies its direction of information transfer.
There are five modes in VHDL: in, out, inout, buffer, and linkage
If no mode is specified, the default is in.
The port clause for the entity half_adder could be written as:
However, to make our code more readable, we will always specify all port modes.
port (a, b : std_logic;
sum, carry_out: out std_logic);

16. Port Mode IN
Port signal
Entity a
Driver resides
outside the entity
Data comes into this port and can only be read within the entity. It can appear only on the right side of a signal or variable assignment.

17. Port Mode OUT
Entity
Port signal z
Output cannot be read within the entity c
Driver resides
inside the entity
c <= z
Out: The value of an output port can only be updated within the entity. It cannot be read. It can only appear on the left side of a signal assignment.

18. Port Mode INOUT
Port signal
Entity a
Signal can be
read inside the entity
Driver may reside
both inside and outside
of the entity
Inout: The value of a bi-directional port can be read and updated within the entity model. It can appear on both sides of a signal assignment.

19. Port Mode BUFFER z z c c <= z
Entity
Port signal z z B c
Driver resides
inside the entity
Port signal Z can be
read inside the entity
c <= z
Buffer: Used for a signal that is an output from an entity. The value of the signal can be used inside the entity, which means that in an assignment statement the signal can appear on the left and right sides of the <= operator.

20. ARCHITECTURE BODY
An architecture body defines either the behavior or structure of a design entity— how it accomplishes its function or how it is constructed.
As such, it provides the internal view of a design entity.
architecture dataflow of half_adder is
begin
sum <= (not a and b) or (a and not b);
carry_out <= a and b;
end dataflow;

21. Entity/Architecture Pair
An architecture body must be associated by name with a specific entity declaration to form an entity/architecture pair (a design entity).
An architecture body cannot exist without an associated entity declaration.
We can have different architectures associated with the same entity declaration, creating different design entities. This typically occurs when alternative implementations of a design entity are developed.

22. Architecture Body (simplified syntax)
An architecture body is divided into two parts, the declarative part and the statement part.
ARCHITECTURE architecture_name OF entity_name IS
[ declarations ]
BEGIN
statement part
END architecture_name;
declare signals and other items used in the architecture
concurrent statements

23. Concurrent Statements
concurrent statements are able to perform their operations simultaneously (concurrently).
When simulated, these statements can execute in parallel in simulated time.
the order in which they appear in the statement part of the architecture body is not relevant.
Anytime there is an event on either input, the statements concurrently compute an updated value for each output.
sum <= (not a and b) or (a and not b);
carry_out <= a and b;
carry_out <= a and b;
sum <= (not a and b) or (a and not b);

24. Note
The terms design entity, entity declaration, and architecture body are clearly distinguished
entity declaration is often shortened to entity and architecture body is shortened to architecture. Thus, the term entity/architecture pair refers to an entity declaration and an associated architecture body.
The term design entity is also often informally shortened to entity.
So, the term entity alone might stand for either design entity or entity declaration.

25. Coding Styles
An architecture can be written in one of three basic coding styles:
A dataflow architecture uses only concurrent signal assignment statements.
A behavioral architecture uses only process statements.
A structural architecture uses only component instantiation statements.
The distinction between these styles is based on the type of concurrent statements used
We can mix two or more, resulting in a mixed style.
any description can be written using any of these styles. However, depending on the system being designed, one style may be more intuitive than the others.

26. Dataflow Style
Dataflow style describes a system in terms of how data flows through the system.
Data dependencies in the description match those in a typical hardware implementation.
A dataflow description directly implies a corresponding gate-level implementation.
Dataflow descriptions consist of one or more concurrent signal assignment statements.

27. Dataflow style half-adder description.
library ieee; use ieee.std_logic_1164.all; entity half_adder is port (a, b : in std_logic; sum, carry_out: out std_logic); end half_adder; architecture dataflow2 of half_adder is begin sum <= a xor b; carry_out <= a and b; end dataflow2;

28. Behavioral Style Behavioral style is the most abstract style.
A behavioral description describes a system’s behavior or function in an algorithmic fashion.
The description is abstract in the sense that it does not directly imply a particular gate-level implementation.
Behavioral style consists of one or more process statements.
Each process statement is a single concurrent statement that itself contains one or more sequential statements.
Sequential statements are executed sequentially by a simulator, the same as the execution of sequential statements in a conventional programming language

29. Behavioral style half-adder description.
library ieee; use ieee.std_logic_1164.all; entity half_adder is port (a, b : in std_logic; sum, carry_out: out std_logic); end half_adder; architecture behavior of half_adder is begin ha: process (a, b) if a = '1' then sum <= not b; carry_out <= b; else sum <= b; carry_out <= '0'; end if; end process ha; end behavior;
Sensitivity List
Whenever there is an event on a signal in a process’s sensitivity list, the process is executed
Sequential assignment statement

30. Structural Style
Structural style describes a system as a hierarchical interconnection of design entities.
The top-level design entity’s architecture describes the interconnection of lower-level design entities.
Each lower-level design entity can, in turn, be described as an interconnection of design entities at the next-lower level, and so on.
Structural style is most useful and efficient when a complex system is described as an interconnection of moderately complex design entities.
This approach allows each design entity to be independently designed and verified before being used in the higher-level description.

31. Structural Style
the lower-level design entities may appear at the beginning of the file with the larger design.
Alternatively, and more commonly, lower-level design entities are described in separate design files that are separately compiled into a library.
This later approach allows for better management of large designs and for reuse of design entities as components in other designs.

32. Structural Style Example
XOR gate component
library ieee;
use ieee.std_logic_1164.all;
entity xor_2 is Entity declaration for 2 input XOR gate
port (i1, i2 : in std_logic;
o1: out std_logic);
end xor_2;
architecture dataflow of xor_2 is -- Architecture body for 2 input XOR
begin
o1 <= i1 xor i2;
end dataflow;

33. Structural Style Example (cont..)
AND gate component library ieee; use ieee.std_logic_1164.all; entity and_2 is -- Entity declaration for 2 input AND gate port (i1, i2 : in std_logic; o1: out std_logic); end and_2; architecture dataflow of and_2 is -- Architecture body for 2 input AND begin o1 <= i1 and i2; end dataflow;

34. Structural Style Example (cont..)
HALF-ADDER structure library ieee; use ieee.std_logic_1164.all; entity half_adder is -- Entity declaration for half adder port (a, b : in std_logic; sum, carry_out: out std_logic); end half_adder; architecture structure of half_adder is -- Architecture body for half adder begin u1: entity xor_2 port map (i1 => a, i2 => b, o1 => sum); u2: entity and_2 port map (i1 => a, i2 => b, o1 => carry_out); end structure;
Component
Instantiation

35. Component Instantiation
A Component Instantiation statement creates an instance (copy) of a design entity
Component instantiation statements require unique labels.
Two different forms of component instantiation:
Direct Instantiation of a Design Entity (named association)
Positional Association
u1: entity xor_2 port map (i2 => b, o1 => sum,i1 => a);
u1: entity xor_2 port map (a, b, sum);

36. Component Instantiation (syntax)
A port map tells how a design entity is connected in the enclosing architecture.
Signals in the enclosing architecture include both the ports of the enclosing architecture as well as any signals declared in the declarative part of the enclosing Architecture
In a port map, the arrow symbol ( => ) indicates the association (connection) of a design entity’s port, on the symbol’s left-hand side, to a signal or port of the enclosing architecture, on the symbol’s right-hand side. The arrow symbol is read as “connected to.”

37. Component Instantiation (syntax)
If a port is associated with an expression, the value of the expression must be a constant.
The keyword open leaves the port unassociated (unconnected). Any unused output ports of a design entity may be left open, but input ports may be left open only if a default value has been specified for the port in its entity declaration.

38. Components in VHDL
The form of component instantiation statement that directly instantiates a design entity, as used in the previous example, did not become a part of VHDL until 1993.
Prior to that, structural VHDL descriptions specified the interconnection of design entities indirectly through the use of components.

39. Components in VHDL (Example)
HALF-ADDER structure library ieee; use ieee.std_logic_1164.all; entity half_adder is -- Entity declaration for half adder port (a, b : in std_logic; sum, carry_out: out std_logic); end half_adder; architecture structure of half_adder is -- Architecture body for half adder component xor_2 -- xor_2 component declaration port (i1, i2 : in std_logic; o1: out std_logic); end component; component and_2 -- and_2 component declaration begin u1: xor_2 port map (i1 => a, i2 => b, o1 => sum); u2: and_2 port map (i1 => a, i2 => b, o1 => carry_out); end structure;
Declarative part of the half_adder architecture

40. Mixed Style
library ieee; use ieee.std_logic_1164.all; entity half_adder is port (a, b : in std_logic; sum, carry_out: out std_logic); end half_adder; architecture mixed of half_adder is begin sum <= a xor b; -- dataflow concurrent statement co: process (a,b) -- start of process concurrent statement if a = '1' then carry_out <= b; else carry_out <= '0'; end if; end process co; -- end of process concurrent statement end mixed;

41. Behavior versus Structure
In describing architectural coding styles, we have made a distinction between dataflow and behavioral styles.
Both of these styles actually describe behavior of the design entity.
In the dataflow style, behavior is described indirectly by concurrent signal assignment statements.
In the behavioral style, behavior is described algorithmically using process statements.

42. Behavior versus Structure
Examination of either of these two kinds of descriptions tells us the behavior of the design entity
In contrast, in a structural style description the top-level entity simply describes the interconnection of components; it provides no behavioral information.
Ultimately, the lowest level components in a structural design must each be described behaviorally in their respective architectures. Otherwise, the top-level description cannot be compiled, simulated, or synthesized.

43. Synthesis Results versus Coding Style

44. Synthesis Results versus Coding Style
if a = '1' then
sum <= not b;
carry_out <= b;
else
sum <= b;
carry_out <= '0';
end if;

45. Synthesis Results versus Coding Style

46. Synthesis Results
When the synthesis process is completed for the half-adder description written in each style, the results are all the same

47. Levels of Abstraction

48. Hierarchical Design and structural style
As seen in the half-adder example, use of structural style is relatively inefficient when describing a system at the gate level.
The advantages of structural style become more evident as the complexity of the components used increases, requiring that the system be designed in a hierarchical fashion.

49. Hierarchical Design
The hierarchical design of a complex system begins with a top-down successive decomposition of the system’s specification into specifications for simpler component design entities.
Each design entity at a given level may be further decomposed into constituent design entities that comprise the next lower level of the decomposition.
Eventually, a point is reached where each design entity is simple enough to be behaviorally described in VHDL.

50. Hierarchical Design (cont.)
Each design entity is individually coded and then verified using a specifically written testbench.
The complete system is then implemented from the bottom up by interconnecting its constituent design entities.
This approach describes and synthesizes a complex system as a hierarchy of design entities.
Finally, a testbench is written to verify the complete system.

51. Top-Level Design Entity
The design entity that represents the entire system is the top-level design entity.
The architecture of the top-level design entity defines the system in terms of the interconnection of component design entities.
Component design entities are interconnected by signals.
Signals are analogous to wires or printed circuit board traces in a corresponding hardware implementation.

52. External and Local Signals
From the viewpoint of the top-level design entity, signals are divided into two kinds: external and local.
External signals are accessed from outside the top-level design entity.
External signals allow input to and output from the top-level design entity. Such signals are port signals (or simply ports).
Component design entities are interconnected by local (internal) signals to form the top-level design entity.
A local signal cannot be accessed from outside of its enclosing architecture body.
Local signals are simply referred to as signals.

53. Full-Adder Structural Description

54. Full-Adder Structural Description
Half-adder design entity library ieee; use ieee.std_logic_1164.all; entity half_adder is port (a, b : in std_logic; sum, carry_out: out std_logic); end half_adder; architecture dataflow of half_adder is begin sum <= a xor b; carry_out <= a and b; end dataflow;

55. Full-Adder Structural Description
Two input OR gate design entity library ieee; use ieee.std_logic_1164.all; entity or_2 is port (a, b : in std_logic; or_out : out std_logic); end or_2; architecture dataflow of or_2 is begin or_out <= a or b; end dataflow;

56. Full-Adder Structural Description
Full-adder design entity library ieee; use ieee.std_logic_1164.all; entity full_adder is port (a, b, carry_in : in std_logic; sum, carry_out: out std_logic); end full_adder; architecture structure of full_adder is signal s1, s2, s3 : std_logic; -- Signals to interconnect components begin -- Each component instantion below is a concurrent statement ha1: entity half_adder port map (a => a, b => b, sum =>s1, carry_out => s2); ha2: entity half_adder port map (a => s1, b => carry_in, sum => sum, carry_out => s3); or1: entity or_2 port map (a => s3, b => s2, or_out => carry_out); end structure;

57. Multiple Design File Description
Full-adder design entity library ieee; use ieee.std_logic_1164.all; library parts; use parts.all; entity full_adder is port (a, b, carry_in : in std_logic; sum, carry_out: out std_logic); end full_adder; architecture structure of full_adder is signal s1, s2, s3 : std_logic; -- Signals to interconnect components begin ha1: entity half_adder port map (a => a, b => b, sum => s1, carry_out => s2); ha2: entity half_adder port map (a => s1, b => carry_in, sum => sum, carry_out => s3); or1: entity or_2 port map (a => s2, b => s3, or_out => carry_out); end structure;

58. Homework#1 Solve the following problems from the textbook chapter2:
8, 9, 12, 13, 18, 19, 25, 29, 30

59. Quiz Given the following truth table:
(a) Write a canonical sum-of-products Boolean equation for each output.
(b) Write a complete VHDL design description of a design entity that accomplishes the function defined by the truth table. Use a simple dataflow architecture.

60. END of chapter2

61. 4-Bit Binary Adder
Circuit for a 4-bit parallel binary adder constructed from full adder building blocks

62. 4-Bit Adder - Entity LIBRARY ieee; USE ieee.std_logic_1164.ALL;
-- VHDL model of a 4-bit adder constructed from four full adders
ENTITY four_bit_adder_st IS
PORT (A, B : IN STD_LOGIC_VECTOR(3 downto 0);
SUM : OUT STD_LOGIC_VECTOR(3 downto 0);
CIN : IN STD_LOGIC;
COUT : OUT STD_LOGIC);
END four_bit_adder_st;
Cin
Cout

63. 4-Bit Adder Structural Cin Cout
-- The architecture in this case is a structural one
ARCHITECTURE structural OF four_bit_adder_st IS
-- First all the components are declared. The full adder is
-- declared only once, even though it will be used 4 times.
COMPONENT fulladder
PORT(Ain, Bin, Cin:  IN STD_LOGIC;
        Cout, Sout:  OUT STD_LOGIC);
END COMPONENT;
-- The full adders are connected by carry signals. These must
-- be declared also.       
SIGNAL C : STD_LOGIC_VECTOR(1 to 3);
-- Port map statements are used to define full adder instances
-- and how they are connected.        
BEGIN       
F1: fulladder port map (A(0),B(0),CIN,C(1),SUM(0));
F2: fulladder port map (A(1),B(1),C(1),C(2),SUM(1));
F3: fulladder port map (A(2),B(2),C(2),C(3),SUM(2));
F4: fulladder port map (A(3),B(3),C(3),COUT,SUM(3));
END structural;
Cin
Cout

64. 4-Bit Adder DataFlow Cin Cout
-- The architecture in this case is a dataflow one
ARCHITECTURE dataflow OF four_bit_add_df IS
-- Again there will be internal carry signals that are not
-- inputs or outputs. These must be declared as signals.
SIGNAL C : STD_LOGIC_VECTOR(1 to 3);
-- Concurrent signal assignments can be used to describe
-- each of the 4 outputs and the carry signals.
BEGIN
SUM(0) <= A(0) XOR B(0) XOR Cin;
C(1) <= (A(0) AND B(0)) OR (A(0) AND Cin) OR (B(0) AND Cin);
SUM(1) <= A(1) XOR B(1) XOR C(1);
C(2) <= (A(1) AND B(1)) OR (A(1) AND C(1)) OR (B(1) AND C(1));
SUM(2) <= A(2) XOR B(2) XOR C(2);
C(3) <= (A(2) AND B(2)) OR (A(2) AND C(2)) OR (B(2) AND C(2));
SUM(3) <= A(3) XOR B(3) XOR C(3);
COUT <= (A(3) AND B(3)) OR (A(3) AND C(3)) OR (B(3) AND C(3));
END dataflow;
Cin
Cout