Introductory Comments Regarding
Hardware Description Languages
Contents
• Introductory Comments
• Comments Regarding Synthesis
• Programming Styles:
– Structural Style
– Dataflow Style
– Behavioral Style
• A Comparison Between Styles
General Design Steps when Using VHDL
(Wakerly, p. 266)
Front End
Step 1: Hierarchy/block diagram
Step 2: Coding
Step 3: Compilation
Step 4: Simulation & Verification
Back End
Step 5. Synthesis
Step 6. Fitting/place & Route
Step 7. Timing Verification
Introductory Comments Regarding HDLs
In general, the idea of describing hardware using a programming
language presents many difficulties.
As a simple demonstration of the difficulties involved, note that digital
circuits process their inputs in parallel and in continuous-time,
while programming languages process the code in discrete-time,
which is almost always equivalent to a a serial execution model.
A Parallel Model
We again note that in digital circuits, we have continuous and parallel
processing of the input signals.
We thus recognize that the architecture of a digital circuit is one of a
“live network” (similar to the graph data structure), where we can have
concurrent changes happening at all connections.
We can think of digital circuits as a traffic network, where all the lights
are green, and nearly all the roads are one-way. The signals move
Freely from the inputs to the outputs.
Basic Synthesis Problems with VHDL
The biggest problem in using VHDL is that the code can lead to
very bad hardware realizations.
This problem arises because VHDL was originally intended for
simulation. Digital synthesis functions were added afterwards.
In this course, we focus on problems that we could synthesize by
ourselves, without VHDL, and we can thus inspect (by viewing the RTL
circuits) and determine whether the synthesis is efficient or not. We
also want to maintain compatibility with FPGAs and CPLDs.
Different Design Method Paradigms
• Hierarchical Design
• Top-down Design
• Bottom-up Design
Comments Regarding Efficient Synthesis
Observations for Better Synthesis
(observations are based on Wakerly, 3rd ed, page 297)
Not everything leads to synthesis!
1. Avoid using serial-contol.
2. Make sure to define outputs for all possible inputs.
3. LOOPS get translated into serial code (loop unrolling)
The use of if-elseif-elseif-else can prohibit parallel hardware
implementations.
Instead, we prefer to use case or select, with mutually exclusive
conditions.
Use IEEE libraries!
Structural Style
Structural Style: Advantages and Disadvantages
In structural style, we provide an idealized description of the hardware
components. We give the gates, etc. In VHDL, we use component
commands.
Advantages:
We provide an efficient implementation of the circuit that can lead to
simulations of specific inputs and outputs, at specific gates, etc.
Disadvantages:
It reduces the flexibility and portability of the implementation, since
we have to re-do the work for efficient implementations on different
platforms.
Observations and Basic Rules for Structural Style
1. Since we focus on basic architectures, if needed, we should be able
to provide the structural code for any circuit. In practice, avoid
structural code unless you have to use it.
2. In hierarchical design, we want to provide efficient designs based on
efficient components. In general though, efficient components
cannot guarantee efficient, overall designs. We will need to examine
the entire design.
3. For reconfigurable logic, we use lookup tables, multiplexers, D flipflops, built-in multipliers, etc. For the built-in multipliers, we will need
to look up VHDL synthesis information from the manufacturer to
utilize such components effectively!
Dataflow Style
Dataflow
• Hardware description based on functions on the inputs
• Description of changes to the inputs without reference to the
underlying hardware
Basic example of a parallel assignment:
signal-name <= expression;
signal-name <= expression1 when boolean-expression-1 else
expression2 when boolean-expression-2 else
:
expressionN-1 when boolean-expression-N-1 else
expression-N;
Behavioral Style
Advantages of Using Behavioral Style
In behavioral style, we are only interested in defining how the circuit
works, without providing implementation details. Implementation is
handled by the design tool, which attempts to provide optimal solutions
for a specified target architecture.
Advantages:
• quick prototyping
• easy to understand the I/O
• portable designs for different architectures
• as the design tools get better, we expect implementations to
improve
Behavioral Style - Disadvantages
The big disadvantage of behavioral style is that the circuit
implementations may end up being very inefficient.
The problem is that synthesis tools based on behavioral style
descriptions have not matured to the point of providing good
implementations.
This is a problem for every style, but perhaps more so for behavioral
style. To avoid problems, use the IEEE libraries. We will have much
more on this later.
In VHDL, we usually use process instructions for behavioral style
descriptions. However, this is not a requirement.
A Comparison Between the Different Styles
Notes:
1. In terms of portability, the only thing that matters is the RTL
description that we produce from the code. The RTL description is
what is used by the synthesis tools.
2. In the final code, in the case in which we have the same hardware
components defined using different styles, we expect the structural
designs to be the most efficient, targeted for specific architectures.
3. In the final code, we can have multiple implementations, where it
is expected that descriptions in the structural style will lead to the
most efficient implementations in a limited number of architectures.
4. In hierarchical design, we could have behavioral code at the top
level using dataflow, which in turn could use structural, but not the
opposite (usually!).
5. For implementations on different architectures, after verification, we
can expect to have to re-write code written in structural style, but not
for the other two.
Possible Steps for Top-Down Design
for Efficient and Portable Design
1. You may want to attempt a behavioral style design first.
2. If your design is not efficient, then decide which hardware
components to optimize, (the most inefficient?), and attempt
a dataflow style design to improve performance.
3. If the performance of the dataflow design is still unsatisfactory,
then use structural style design.
NB: Always check the RTL representation in your
simulation to verify that you have efficient designs.