[Hardware Design II] Component Modelation

The growing complexity of software in Embedded Systems has been demanding more computation power, either by the implementation of more competent CPU or through Hardware components, designed for the realization of specifc tasks.

Hardware components are developed through Hardware Description Languages, describing the structure and the behavior of the circuitry to be implemented, and verified in FPGA fabric before implementation in ASIC, avoiding unwanted manufactoring cost associated to possible existing bugs in the component.

Hardware Description Languages

Hardware Descriptor Languages are computer languages dedicated for modeling the structure and behavior of digital logic circuits, as well as for precise simulation of already developed digital components. Hardware development can be done within four levels of abstraction:

• System Level — The component’s functional description is outlined through HDL constructs. Some blocks of logic might not be synthetizable, being used purely for simulation and verification purposes.
• Register Transfer Level — The design is divided into combinational and sequential logic, controlled by the system clock. RTL description is fully synthetizable and can be used for Application Specific Integrated Circuit manufacturing.
• Gate Level — The design is represented as a netlist of logic gates and storage elements. Gate Level description can be used for programming a Programmable Logic Device.
• Transistor Level — The netlist is placed in different cells of the target technology and connections are routed, in an operation known as Place and Route. After this process is finished, a layout verification is executed to assure that the circuit is ready to be executed. This level is dependent of the underlying machine, since the route and placement are done accordingly to the cell technology used in the production of the Programmable Logic Devices, and so it is normal that the vendor offer the respective tools for this process.

HDL and software programming languages paradigms are different, due to the nature of the hardware where the notion of time must be present and concurrency is applied to all processes. HDL modules are systems that constantly process a set of inputs to generate the outputs .

Behavioral Implementation

The Behavioral implementation models the circuit logic through its behavior, similar to programming a software application. Each HDL provides a set of constructs to control the execution flow of the cuircuit, such as the popular if. This type of implementation is configurable and modifiable for different use cases with little to no effort.

The generated hardware is, in its majority, unkown to the developer and less efficient, both in latency and silicon area, when compared to the Structural implementation.

The great advantage is the faster development cycle of the circuit and the fact that most use cases can be targeted with the behavioral implementation, or at least the majority of the design.

Structural Implementation

The Structural implementation models the component through a combination of logic gates (AND, OR, NOT, XOR). This approach requires a great knowledge of digital signals, as well as the concepts of the boolean algebra.

Structural implementations are based in the boolean algebra of the intended circuit, therefore the module is developed for a specific use case and not suitable for different configurations.

The generate hardware will be faithful to the logic implemented through the HDL and known by the developer, with the drawback of a higher development cycle, since the truth table and the boolean algebra for the circuit to be implemented has to be calculated before implementation.

Truth Table

Truth table is a mathematical table used for expressing the relationship between the input and the output signals of a logic circuit. In conjunction with boolean algebra can be used to express the circuit behavior through mathematical expressions.

Bolean Algebra

Boolean Algebra is a branch in Algebra which defines the possible values of a variable as truth or false, commonly denoted 1 and 0 when used for design of logic circuits.

Boolean Algebra primary operations are defined by:

• AND — Denoted x ∧ y or x AND y, satisfies x∧y = 1 if x = y = 1, and x ∧ y = 0 otherwise.
• OR — Denoted x ∨ y or x OR y, satisfies x ∨ y = 0 if x = y = 0, and x ∨ y = 1 otherwise.
• NOT — Denoted NOT x, satisfies NOT x = 0 if x = 1 and NOT x = 1 if x = 0.

The Demultiplexer Example

The Demultiplexer is a circuit that enables an input signal to be shared between several devices. The Demultiplexer forwards the input signal to the selected output line.

The behavior of the Demultiplexer, designed for connecting 1 input signal to 8 possible circuits, is described in the truth table of the figure 1.

figure 1–3 to 8 Demultiplexer truth table for a input signal set to 1.

Behavioral

A possible behavioral implementation for the Demultiplexer, described in the truth table of the figure 1, is defined in the following HDL snippet:

entity demux is
Generic ( DEMUX_SELECT_WIDTH : INTEGER := 3)
Port
(
   select : IN STD_LOGIC_VECTOR( DEMUX_SELECT_WIDTH - 1 DOWNTO 0);
   data_in : IN STD_LOGIC;
   y0 : OUT STD_LOGIC_VECTOR( 2**DEMUX_SELECT_WIDTH - 1 DOWNTO 0)
);
end demux;
architecture behavioral of demux is

MUX_BEHAV : for i in 0 to 2**DEMUX_SELECT_WIDTH - 1 generate
y0(i) <= data_in when( i = to_integer(unsigned(select)) ) else '0';
end generate;

end behavioral;

The demux entity is configurable for different number of output lines, by setting the DEMUX_SELECT_WIDTH variable to the desired value. The implementation is concise and easily understandable, but it does not give any information about the possible hardware generated.

Structural

From the truth table of the figure 1 it is possible to expess the relationship between the selector and the output lines, expressed in the table 1.

table 1— Boolean Algebra for the 3 to 8 Demultiplexer.

The structural implementation uses the mathematical expressions of the table 1 to develop the demux entity of the following HDL snippet:

entity demux is
Port
(
   s0 : IN STD_LOGIC;
   s1 : IN STD_LOGIC;
   s2 : IN STD_LOGIC;
   data_in : IN STD_LOGIC;
   y0 : OUT STD_LOGIC;
   y1 : OUT STD_LOGIC;
   y2 : OUT STD_LOGIC;
   y3 : OUT STD_LOGIC;
   y4 : OUT STD_LOGIC;
   y5 : OUT STD_LOGIC;
   y6 : OUT STD_LOGIC;
   y7 : OUT STD_LOGIC
);
end demux;
architecture structural of demux is
begin
y0 <= (not s0) and (not s1) and (not s2) and data_in; 
y1 <= s0 and (not s1) and (not s2) and data_in;
y2 <= (not s0) and s1 and (not s2) and data_in;
y3 <= s0 and s1 and (not s2) and data_in;
y4 <= (not s0) and (not s1) and s2 and data_in;
y5 <= s0 and (not s1) and s2 and data_in;
y6 <= (not s0) and s1 and s2 and data_in;
y7 <= s0 and s1 and s2 and data_in;
end structural;

As it is evident, for different number of output lines it is necessary the modify the truth table and consequently the HDL design for the desired values.

Behavioral vs Structural Resume

• Behavioral design are faster to develop but will generate hardware unknown to the developer and tend to be less efficient;
• Through Behavioral modelation it is possible to produce configurable HDL design, which can be reused for other use cases;
• Structural design required high expertise of digital systems, therefore increasing the development cycle;
• With Structural design it is possible to generated hardware, known by the developer, for a specific use case;