EEL 4783: HDL in Digital System Design

Transcription

1 EEL 4783: HDL in Digital System Design Lecture 9: Coding for Synthesis (cont.) Prof. Mingjie Lin 1

2 Code Principles Use blocking assignments to model combinatorial logic. Use nonblocking assignments to model sequential logic. Never mix blocking and nonblocking assignments in one always block. Violating these guidelines will likely lead to mismatches in simulation versus synthesis, poor readability, decreased simulation performance, and hardware errors that are difficult to debug. 2

3 For-Loops C-like looping structures such as the for-loop can present a trap to a designer with a background in software design. The reason for this is, unlike the C software language, these loops cannot typically be used for algorithmic iterations in synthesizable code. Instead, HDL designers will typically use these looping structures to minimize typing a large array of similar assignments that operate on similar elements 3

4 Software vs. Hardware Loop This algorithmic loop uses iteration to perform a multiply operation N times. Each time through the loop, the running variable is updated. This works well in software because for every loop iteration, an internal register is updated with the current value of PowerX. 4

5 Bad Example This will work in a behavioral simulation XST will not synthesize this code without a fixed value of N Synplify will synthesize this loop based on the worst-case value of N The end result if this is indeed synthesized will be a loop that is completely unrolled into a massive block of logic that runs extremely slow 5

6 Good Example A design that manages the registers during each iteration of the loop may utilize control signals as shown in the following example For-loops should not be used to implement software-like iterative algorithms 6

7 Good Use of For Loop For-loops are often used as a short form to reduce the length of repetitive but parallel code segments. For instance, the following code generates an output by taking every bit in X and applying the XOR operation with every even bit of Y. 7

8 Combinatorial Loops Combinatorial loops are logic structures that contain feedback without any intermediate synchronous elements A combinatorial loop occurs when the output of a cloud of combinatorial logic feeds back to itself with no intermediate registers. This type of behavior is rarely desirable and typically indicates an error in the design or implementation 8

9 Bad Examples The above module represents a behavioral description that in simulation may behave as follows: when the wire a changes, the output is assigned the result of the current output XOR a. The output only changes when a changes and does not exhibit any feedback or oscillatory behavior 9

10 Inferred Latches Special types of combinatorial feedback can actually infer sequential elements. The above module models a latch in the typical manner. Whenever the control is asserted, the input is passed directly to the output. When the control is deasserted, the latch is disabled. A very common coding mistake is to create a combinatorial if/else tree and forget to define the output for every condition. The implementation will contain a latch and will usually indicate a coding error. 10

11 Functions Latches are typically not recommended for FPGA designs and can very easily become implemented improperly or not implemented at all. One example is through the use of a function call. Consider, for example the typical instantiation of a latch encapsulated into a function as shown in the following example. In this case, the conditional assignment of the input to the output is pushed into a function. Despite the seemingly accurate representation of the latch, the function will always evaluate to combinatorial logic and will pass the input straight through to the output. 11

12 Design Partitioning Partitioning refers to the organization of the design in terms of modules, hierarchy, and other functional boundaries. The partitioning of a design should be considered up front, as major changes to the design organization will become more difficult and expensive as the project progresses. Designers can easily wrap their minds around one piece of functionality, and this will allow them to design, simulate, and debug their block in an efficient manner. 12

13 Data Path Versus Control Many architectures can be partitioned into what is called data path and control structures. The data path is typically the pipe that carries the data from the input of the design to the output and performs the necessary operations on the data. The control structure is usually one that does not carry or process the data through the design but rather configures the data path for various operations. 13

14 Partitioning Principles Data path and control blocks should be partitioned into different modules. Because the data path is often the critical path of the design (the throughput of the design will be related to the timing of the pipeline), it may be required that a floorplan is designed for this path to achieve maximum performance. The control logic, on the other hand, will often have slower timing requirements placed on it because it is not a part of the primary data path. 14

15 Clock and Reset Structures Good design practice dictates that any given module should have only one type of clock and one type of reset. If, as is the case in many designs, there are multiple clock domains and/or reset structures, it is important to partition the hierarchy so that they are separated by different modules. It is good design practice to use only one clock and only one type of reset in each module. Hazards can get involved with mixing clock and reset types in procedural descriptions, but if any given module has only one clock and reset, these problems are less likely to arise. 15

16 Multiple Instantiations If there are cases where certain logic operations occur more than once in a particular module (or across multiple modules), a natural partition to the design would be to group that block into a separate module and push it into the hierarchy for multiple instantiations. 16

17 Parameterization In the context of FPGA design, a parameter is a property of a module that can be changed either on a global sense or on an instance-by-instance basis while maintaining the root functionality of the module. Parameters and definitions are similar and in many cases can be used interchangeably. In Verilog, definitions are utilized with the define statement, and for compiler time controls with subsequent ifdef statements. 17

18 Examples Ifdef directives should be used for global definitions. 18

19 Parameters Unlike global definitions, parameters are typically localized to specific modules and can vary from instantiation to instantiation. A very common parameter is that of size or bus width as shown in the following example of a register. Parameters should be used for local definitions that will change from module to module. Parameterized code such as this is useful when different modules of similar functionality but slightly different characteristics are required. 19

20 Summary If/else structures should be used when the decision tree has a priority encoding. Use of the parallel_case directive is generally bad design practice. Use of the full_case directive is generally bad design practice. Parallel_case and full_case can cause mismatches between simulation and synthesis. It is good design practice to keep all register assignments inside one single control structure. Use blocking assignments to model combinatorial logic. Use nonblocking assignments to model sequential logic. Never mix blocking and nonblocking assignments in one always block. For-loops should not be used to implement software-like iterative algorithms. Data path and control blocks should be partitioned into different modules. It is good design practice to use only one clock and only one type of reset in each module. Ifdef directives should be used for global definitions. Parameters should be used for local definitions that will change from module to module. Named parameter passing is superior to positional parameter passing or the defparam statement. 20

21 Final issues Please fill out the student info sheet before leaving Come by my office hours (right after class) Any questions or concerns? 21