HDL Coding

HDL code can be behavioral or RTL. In the synthesis domain, the latter is usually considered to be the synthesizable form of HDL code. Since the focus of this book is on logic synthesis, all examples discussed are in synthesizable RTL code. As a preliminary introduction to HDL coding and synthesis let us consider the following simple examples. Four examples of HDL code which infer on synthesis a D-flip flop, a latch, an AND gate, and a multiplexer (referred to as mux throughout this book) respectively are discussed. 

Example 1.2 shows the Verilog and VHDL code which when synthesized infers a latch. Notice that the if statement does not have an else clause specified. The synthesis tool interprets the absence of an else clause to mean, when if condition not satisfied, maintain previous value . Hence a latch is inferred in this example. 

Example 1.3 Initialized Signal to Prevent Latch Inference 

Chapter 2 discusses HDL coding in greater detail with several examples. The issues discussed above have all been covered in greater depth. 

In this model of a technology library, all combinational cells have a rise/fall delay of Ins, while all sequential cells have a rise/fall delay of 2 ns. 

---

There is no correlation between the gates produced and the number of lines of Verilog HDL code. A 2500-gate circuit could have been synthesized from a 10-line Verilog HDL code (may have a for-loop and/or vectors) or from 10,000 lines of Verilog HDL code (maybe from a large case statement with simple assignments). 

When writing Verilog HDL code, the designer must be aware of the logic structure being generated. One such important point is the use of parentheses. Here is an example. 

Having synthesized a Verilog HDL model into a netlist, it is important to verify the functionality of the synthesized netlist to ensure that it still matches the intended functionality. This step is important since a synthesis system may make certain assumptions or interpretations of the Verilog HDL code that may not match those intended by the model writer. 

Open the top-level file mac.v in I xilinx tutoriaKmac and try to understand the structure of the multiply-accumulator. You must be able to draw a simple diagram with some useful details descrihed by this HDL code and show it to the instructor. 

The user templates can be customized to keep any HDL code as on-line references. 

In addition, passing the FPGA Express syntax checker does always NOT mean that the HDL code can be synthesized correctly since problems can arise later in the synthesis process. Also, synthesis may work, but not produce useful results. For example, you have to search the output schematic carefully to see whether latches are inferred by your incomplete if or case statements. 

The most commonly used HDLs today are VHDL and Verilog. The desired fimctionality of a design is first captured in HDL code, usually Verilog or VHDL. This step is complex, particularly for 1C designers who are accustomed to schematic capture tools. This is further compounded by the fact that this code then must be synthesized into an optimal design which meets the functional requirements of the initial specification. 

There are two possible ways of simulating a design using a testbench as shown in Figure 1.6. One can write a testbench where all the stimuli for the different signals are provided in the HDL code. Then one would use a graphical front end of a simulation tool to view the waveforms. It is also possible to provide the stimuli for the different signals and pipe the outputs to a file. If one has another file of expected results, one can quite easily compare the two files to ensure that the two match. Both these techniques have been discussed in chapter 3 with examples. 

In this section, we discuss some basic issues related to HDL coding for synthesis such as VHDL types, unwanted latches, variables and signals, and priority encoding. For a certain desired functionality, it is often possible to code HDL in a number of different ways. However, there are several guidelines that one can follow to develop a consistent coding style for synthesis. 

This section shows several simple HDL coding examples of commonly used building blocks such as RAMs, ROMs, barrel shifters and incrementors. Examples are provided in both VHDL and Verilog. 

This section discusses classic coding scenarios for DC. Unlike the classic scenarios discussed in chapter 1, these are useful to all designers writing HDL code for synthesis using DC. 

HDL Coding Styles Sequential Devices Application Note... 

Use the report resources command to check implementations of resources in the designs and also on how many resources are inferred. There might be scope for sharing of resources by modifying the HDL code. 

Last but not the least, it is always advisable to perform a preliminaiy synthesis and place and route so as to identify any serious issues which may require re-writing the HDL code. 

A design has a delay cell (instance name u1) instantiated in HDL code as shown in Figure 4.8. This delay cell is between a flip-flop and mux, and you wish to make sure DC does not remove it from this location during synthesis. The flip-flop and mux are... 

Xilinx XC4000 devices can efficiently implement RAMs and ROMs using CLB function generators. XC4000 libraries include 16x1 and 32x1 RAM and ROM primitives that you can instantiate in your code. These primitives must be instantiated in your HDL code to efficiently implement memory in the XC4000 family. In the... 

Read in your HDL code using the read command with the appropriate options. The read command performs syntax checking and basic code optimization such as, constant propagation and dead-code elimination before creating a network of logic equations and registers. 

This above line in the XNF file binds the sequential element BITS SEEN reg<1 > inferred from the HDL code to a CLB with instance name U125"... 

Read in the HDL code of the entire design into DC. In the example dc shell command shown below, VHDL FILES is a variable which is assigned to a number of VHDL files. 

In the testmode, it is important that all clocks and asynchronous reset signals be controllable from the primary inputs. For internally generated clocks in the design (clock dividers, for instance), one approach is to synthesize a mux in the HDL code such that, in the testmode, die test clock from the primary input is selected. The same approach can be followed for the reset line. 

Example 8.2 HDL Code for a design with bi-directional ports... 

---