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

6. Basic Synthesis Problems withVHDL 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-elsecan prohibit parallel hardware implementations. Instead, we prefer to use case or select, with mutually exclusive conditions. Use IEEE libraries!

10. StructuralStyle

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

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 <= 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;

15. BehavioralStyle

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.