Digital Systems Design 2

Digital Systems Design 2 VHDL: Modeling Structure Ref. “VHDL Starter’s Guide”, Sudhakar Yalamanchili, Prentice Hall, 1998

Modeling Structure with VHDL • There are three basic approaches that can be taken in modeling/designing a digital system: • Using behavioral descriptions of a component with concurrent signal assignment statements. • When using CSAs becomes infeasible due to the complexity of the event calculations, then one can resort to using one or more processes and sequential statements to model/design a specific behavior. • Finally, the third approach is to describe the model of a system simply in terms of the interconnection of its components. • When using the approach of describing the model based on interconnection of its components the following strategy is applied: • The modeling is focused on describing how each component is interconnected, and • The behavior of each component is assumed to be provided. • Such strategy describes only the structure of a system without regard to the operation of individual components and is referred to as a structural modeling. Veton Këpuska

Describing Structure • Block diagrams are commonly used as tools for representing structural descriptions. • Assume example of a full-adder described previously: Veton Këpuska

a sum a c carry b b ports Describing Structure • In the following schematics the interface description of the half-adder and OR-gate component is presented. Veton Këpuska

Describing Structure • The following guideline is recommended when using structural approach to VHDL design: • Describe inputs and outputs (e.g., of the full adder). • State the type and mode of the input/output signals (e.g., single bit, input or output signal). • List of all components needed (e.g., two half adders and one two-input OR gate). • Describe unambiguously interconnection of the listed components: • Each component should be assigned unique label (e.g., HA1, HA2, O1). • Each signal must be labeled with unique name as well (e.g.,s1, s2, s3). • Additional annotations are the labels for all the ports (e.g., ports of the two half adders and OR gate). Veton Këpuska

Describing Structure • The number of features that a formal VHDL structural description might posses: • The ability to define the list of components • The definition of a set of signals to be used to interconnect these components • The ability to uniquely label, and therefore distinguish, between multiple copies of the same component. Veton Këpuska

library IEEE; use IEEE.std_logic_1164.all; entity full_adder is port (in1,in2, c_in: in std_logic; sum,c_out: out std_logic end full_adder; architecture structural of full_adder is component half_adder port (a,b: in std_logic; sum,carry: out std_logic end component; component or_1 port (a,b: in std_logic; c: out std_logic end component; signal s1, s2, s3:std_logic; begin HA1: half_adder port map (a=>in1, b=>in2, sum=>s1, carry=>s3); HA2: half_adder port map (a=>in1, b=>c_in, sum=>sum, carry=>s2); O1: or_1 port map (a=>s2, b=>s3, c=>c_out); end structural; Component Interconnections Component Declarations Signal Declarations Structural Model of a full adder a sum a c carry b b ports Veton Këpuska

Structural Model of a full adder • Important Remark • Behavioral model of each component are assumed to be provided elsewhere; there are entity-architecture pairs describing a half adder. • There are no implications on the type of the model used to describe the operation of the half adder. • This behavioral model could: • comprise concurrent signal assignment statements, or • Use processes and sequential statements, or • Itself be a structural model describing a half adder as the interconnection of gate level behavior models. • Note that such hierarchies are very useful and are discussed in further detail later. Veton Këpuska

Structural Model of a State Machine • Consider a bit serial adder shown in the figure bellow. On successive clock cycles, the combinational logic component computes the sum and carry values for each bit position. • The D flip-flop stores the carry bit between additions of successive bits. It is initialized to 0. • As successive bits are added the corresponding bits of the output value are produced serially on the output signal. • The state machine diagram is shown in the next slide. Veton Këpuska

A bit-serial adder: logic implementation A bit-serial adder: State Diagram (ab/z) a z Combinational logic b D Q Clk Qbar Rbar Example of Bit-Serial Adder 11/0 01/0 10/0 11/1 00/0 01/1 10/1 0 1 00/1 Veton Këpuska

library IEEE; use IEEE.std_logic_1164.all; entity serial_adder is port (a,b,clk,reset: in std_logic; z: out std_logic); end serial_adder; architecture serial_adder_struct of serial_adder is -- -- declaration of components -- component comb port (a,b,c_in: in std_logic; z, carry: out std_logic); end component; component dff port (clk,reset,d: in std_logic; q, qbar: out std_logic); end component; signal s1,s2: std_logic; begin -- -- description of component interconnections -- C1: comb port map (a => a, b=>b, c_in => a1, z => z, carry => s2); D1: dff port map(clk => clk, reset=>reset, d=>s2, q=s1, qbar => open); end serial_adder_struct; Example of Bit-Serial Adder Veton Këpuska

Hierarchy, Abstraction, and Accuracy • Observation about Structural Models: • Describe only interconnections of components. • There is no description of how output events are computed in response to input events. • Simulation is internally created by replacing components with their behavior descriptions. • If a description of a component is also a structural description then the process is repeated for structural models at each level of hierarchy. This process is repeated until all components of the hierarchy have been replaced by behavioral descriptions. • This process is referred as flattening of the hierarchy. • From this point of view the structural models are a way of managing large, complex designs. Veton Këpuska

Hierarchy, Abstraction, and Accuracy • A modern designs have several million to tens of millions of gates. It is often not feasible to build a single, flat, simulation model at the level of individual gates to test and evaluate the complete design due to: • Large amount of simulation time required, and/or • Amount of memory required for such a detailed model. • This it is common to approximate a detail model with a simplified gate level behavior providing less accurate modeling in initial stages of the design. • For example: one may have a library of VHDL models of distinct components, such as those derived from the manufacture’s component data book. These models have been: • Developed, • Debugged, and • Tested. The only model required to be written is a structural model. Designer also has to know the component entity description to correctly declare it. • When an improved model is developed it can be tested and debugged in isolation. New and improved model then can replace the old model. The need to recompile any dependent design entities is determined by the rules (to be covered later in the class). Veton Këpuska

Hierarchy, Abstraction, and Accuracy • The more detailed the model the larger the number of events is to be expected that the model will generate. • The larger the number of events generated by the model the greater the simulation time. • More accurate models will take a significantly longer time to simulate. • In general, closer to making implementation decisions, the more accurate the simulation will be needed and hence more time is invested in simulation. Veton Këpuska

Generics • Parameterization of Models: • Gate-level model may have a parameterized value of gate-delay actual value of which is determined at simulation time by the value that is provided to the model. • Having parameterized models makes it possible to construct standardized libraries of models. • The VHDL language provides the ability to construct parameterized models using concept of generics. Veton Këpuska

An example of the use of generics. Propagation delay in this model is parameterized by the constant gate_delay. Initial (default) value of is set to gate_delay 2 ns. A new value of gate_delay can be specified at the time model is used (as shown in the next example). This is done through the use of generic map(0) construct. library IEEE; use IEEE.std_logic_1164.all; entity xor2 is generic (gate_delay: Time 2 ns); port (In1,In2: in std_logic; z: out std_logic); end xor2; architecture xor2_funct of xor2 is begin z <= (In1 xor In2) after gate_delay; end xor2_func; Generics Veton Këpuska

Generics architecture generic_delay_funct of half_adder is component xor2 generic(gate_delay: Time); -- new value may be specified here -- instead of using a generic map() construct port (a,b: in std_logic; c: out std_logic); end component; component and2 generic(gate_delay: Time); port (a,b: in std_logic; c: out std_logic); end component; begin X1: xor2 generic map (gate_delay => 6 ns) port map(a=>a,b=>b,c=>sum); A1: and2 generic map (gate_delay => 3 ns) port map(a=>a,b=>b,c=>carry); end generic_delay_func; Veton Këpuska

Specifying Generic Values • Generic constant can be specified: • Using generic map construct, or • It can be specified when the component is declared: generic(gate_delay: Time := 6 ns); • In general there are at least two ways in which the values of generic constants of lower-level can be specified: • In the component declaration, and • In the component instantiation statement using the generic map () construct. • If both are specified specification value provided by generic map () takes precedence. • If neither is specified then the default value specified in the model is used. Veton Këpuska

Passing Generic Values • The values of these generics can be passed down through multiple levels of the hierarchy. • Example of passing values of generics through multiple levels of hierarchy. Veton Këpuska

library IEEE; use IEEE.std_logic_1164.all; entity half_adder is generic(gate_delay: Time := 3 ns); port (a,b: in std_logic; sum,carry: out std_logic end half_adder; architecture generic_delay2 of half_adder is component xor2 generic(gate_delay: Time); port (a,b: in std_logic; c: out std_logic end component; component and2 generic(gate_delay: Time); port (a,b: in std_logic; c: out std_logic end component; begin X1: xor2 generic map (gate_delay => gate_delay ns) port map(a=>a,b=>b,c=>sum); A1: and2 generic map (gate_delay => gate_delay) port map(a=>a,b=>b,c=>carry); end generic_delay2; Example of passing values of generics Veton Këpuska

Parameter passing through the hierarchy using generics … HA1: half_adder generic map (gate_delay => 6 ns) port map (a=>in1, b=>in2, sum=>s1, carry=>s3); HA2: half_adder … … From full_adder.vhd 6 ns 6 ns X1: xor2 generic map (gate_delay => gate_delay) … A1: and2 generic map (gate_delay => gate_delay) X1: xor2 generic map (gate_delay => gate_delay) … A1: and2 generic map (gate_delay => gate_delay) From half_adder.vhd From half_adder.vhd 6 ns entity and2 is generic (gate_delay: Time := 2 ns) … entity xor2 is generic (gate_delay: Time := 2 ns) … 6 ns From and2.vhd From and2.vhd Veton Këpuska

library IEEE; use IEEE.std_logic_1164.all; entity generic_reg is generic (n: positive := 2); port (clk,reset,enable: in std_logic; d: in std_logic_vector(n-1 downto 0); q: out std_logic_vector(n-1 downto 0)); end generic_reg; architecture behavioral of generic_reg is begin reg_process: process (clk, reset) begin if (reset = ‘1’) then q <= (others => ‘0’); elsif (ckl’eventand clk = ‘1’) then if (enable = ‘1’) then q <= d; end if; end if; end process reg_process; end behavioral; Generics Example; N-bit Register Veton Këpuska

Configurations • There may be multiple VHDL models for the same components. In such a case it would be desirable to be able to configure simulation to use a particular model. • VHDL language provides configurations for explicitly associating an architecture description with each component in a structural model. • If configuration is not supplied default binding rules apply when a number of alternate VHDL models exist for the same component. Veton Këpuska

library IEEE; use IEEE.std_logic_1164.all; entity serial_adder is port (a,b,clk,reset: in std_logic; z: out std_logic); end serial_adder; architecture serial_adder_struct of serial_adder is component comb port (a,b,c_in: in std_logic; z, carry: out std_logic); end component; component dff port (clk,reset,d: in std_logic; q, qbar: out std_logic); end component; signal s1,s2: std_logic; begin C1: comb port map (a => a, b=>b, c_in => a1, z => z, carry => s2); D1: dff port map(clk => clk, reset=>reset, d=>s2, q=s1, qbar => open); end serial_adder_struct; Component C1 implements the combinational logic portion of the state machine. There may be alternative implementations of the gate-level design of C1 for: High speed, Low power, Different vendor, Different behavioral model written for simulation, etc. One of the models must be bound to the component C1 for simulation. Configuration construct in VHDL specifies one, and only one, such binding. Note: Configuration information only binds architectural component and not the entity description. This is because the interface does not change and it is the implementation that one would like to change and this is captured in an architecture description. Example of Component Binding (Structural Model of Serial Bit Adder) Veton Këpuska

Configuration • In addition to default binding rules There are two ways in which configuration information can be provided : • Configuration specification • Configuration declaration Veton Këpuska

Default Binding Rules • If no configuration information is provided as in the preceding examples then a default architecture may be found as follows: • If the entity name is the same as the component name, then this entity is bound to the component. • If there are multiple architectures for the entity, such as for entity comb in the next slide, then the last compiled architecture for entity comb is used. • If there are no such entities with the same name visible to the VHDL environment, then the binding is said to be deferred, that is, no binding takes place until such information becomes available. Veton Këpuska

Alternative architectures for binding the combinational logic component of a state machine architecture gate_level of comb is …… architecture low_power of comb is …… a z Combinational logic b D Q Clk Qbar architecture high_speed of comb is …… Rbar architecture behavioral of comb is …… Veton Këpuska

Configuration Specification • Configuration specifications are used in the architecture body to identify the relationships between the components and the entity-architecture pairs to be used to model each component. • We can specify a particular entity-architecture pair by naming the design library within which it is located and the name of the design unit within which they are stored as depicted in the next VHDL code example. Veton Këpuska

library IEEE; library POWER; -- new library use IEEE.std_logic_1164.all; entity full_adder is port (in1,in2, c_in: in std_logic; sum,c_out: out std_logic end full_adder; architecture structural of full_adder is component half_adder port (a,b: in std_logic; sum,carry: out std_logic end component; component or_1 generic(gate_delay: Time := 2 ns); port (a,b: in std_logic; c: out std_logic end component; signal s1, s2, s3:std_logic; -- -- configuration specification -- for H1: half_adder use entity WORK.half_adder(behavioral); for H2: half_adder use entity WORK.half_adder(structural); for O1: or_1 use entity POWER.lpo1(behavioral); generic map(gate_delay => gate_delay) port map(I1=>a, I2=>b, Z=>c); begin – component instantiation statements H1: half_adder port map (a=>in1, b=>in2, sum=>s1, carry=>s3); H2: half_adder port map (a=>in1, b=>c_in, sum=>sum, carry=>s2); O1: or_1 port map (a=>s2, b=>s3, c=>c_out); end structural; An example of using configuration specifications for the structural model of a full adder Architecture Name Entity Name Library Name Veton Këpuska

Configuration Declaration • A configuration declaration provides the same ability to specify the choice of models as configuration specification, but as a separate design unit instead of being placed within the architecture body. • An example of Configuration Declaration equivalent to the already presented case of configuration specification is presented in the next slide. Veton Këpuska

A configuration declaration for the structural model of the full adder. Name of the configuration for the entity configuration Config_A of full_adder is for structural for H1: half_adder use entity WORK.half_adder(behavioral); end for; -- for H2: half_adder use entity WORK.half_adder(structural); end for; -- for O1:or_1 use entity POWER.lpo1(behaviour) generic map(gate_delay=>gate_delay) port map(I1=>a,I2=>b,Z=>c); end for; -- end for; end Config_A; name of the architecture being configured Veton Këpuska

Digital Systems Design 2