Introductory Comments Regarding Hardware Description Languages

1
Introductory Comments Regarding Hardware
Description Languages
2
Contents

• Introductory Comments
• Comments Regarding Synthesis
• Programming Styles
• Structural Style
• Dataflow Style
• Behavioral Style
• A Comparison Between Styles

3
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

4
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.

5
A Parallel Model

• We again notes 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 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.

6
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.

7
Different Design Method Paradigms

• Hierarchical Design
• Top-down Design
• Bottom-up Design

8

• Comments Regarding Efficient Synthesis

9
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!

10

• Structural Style

11
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.

12
Observations and Basic Rules for Structural Style

• 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.
• 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 flip-flops, 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!

13

• Dataflow Style

14
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 lt expression
• signal-name lt expression1 when
  boolean-expression-1 else
• expression2 when boolean-expression-2
  else
• expressionN-1 when boolean-expression-N
  -1 else
• expression-N

15

• Behavioral Style

16
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

17
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.

18
A Comparison Between the Different Styles

• Notes
• 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.
• 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.
• 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!).
• 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.

19
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.