Verilog HDL

A Verilog HDL Primer, Star Galaxy Press, Allentown, PA, 1997,... 

All these values are defined explicitly in Verilog HDL except for the don t-care value. A synthesis system treats the value x, when it is assigned to a variable, as a don t-care value. Here is the mapping between the Verilog HDL values and the hardware modeling values ... 

There are three kinds of constants in Verilog HDL integer, real and string. Real and string constants are not supported for synthesis. 

A variable in Verilog HDL can either be of the net data type or the register data type. For synthesis, a variable of net type maps to a wire in hardware and a variable of the register type maps either to a wire or a storage element (flip-flop or latch) depending on the context under which the variable is assigned a value. Let us look at a variable of register type in more detail. 

In Verilog HDL, a register variable retains its value through the entire simulation run, thus inferring memory. However, this is too general for synthesis. Here is an example of a variable that is used as a temporary and therefore need not be a candidate for a storage element. 

As per Verilog HDL rales, when performing the left shift operation in module ConstantShift, the shifted bits from DataMux are not discarded but simply move into the higher order bits of Address. If Address were the same size as DataMux, then the high-order bits get shifted out and discarded. 

ZCat[2 0] and C[3 2] are examples of part-selects. Non-constant part-selects are not supported in Verilog HDL. 

Arithmetic operations as conditional expressions, as in the previous example, should be avoided when inferring latches since there is a very high probability of race condition between the conditionals in the synthesized netlist this might cause the latched value in the synthesized netlist to differ from that in the Verilog HDL model. 

Verilog HDL semantics of a case statement specifies a priority order in which a case branch is selected. The case expression is checked with the first case item, if it is not the same, the next case item is checked, if not the same, the next case item is checked, and so on. A priority order of case item checking is implied by the case statement. Additionally, in Verilog HDL, it is possible for two or more case item values to be the same or there may be overlapping case item values such as in casex and casez statements however, because of the priority order, only the first one in the listed sequence of case items is selected. 

The information that all case item values are mutually exclusive needs to be passed to the synthesis tool. This is done by using a synthesis directive called parallel case. When such a directive is attached to a case statement, a synthesis tool interprets the case statement as if all case items are mutually exclusive. Since the synthesis directive appears as a comment in the Verilog HDL model, it has no effect on the language semantics of the model. This implies that no priority logic is synthesized for the case statement control instead decoding logic is used. Here is the case statement with the parallel case directive. 

In Verilog HDL, it is possible to have a non-constant expression as a case item. This is shown in the following example of a priority encoder. 

There are four kinds of loop statements in Verilog HDL. 

Variables (reg and integer types) declared locally within an always statement do not infer flip-flops. This may potentially lead to a functional mismatch between the Verilog HDL model and the synthesized netlist. Here is an example of a locally declared variable Temp that does not get inferred as a flip-flop. 

Having an asynchronous data input such as PresetData can cause a problem. Consider when Preset is 1 and then PresetData changes. The change of PresetData does not reflect in the Verilog HDL model while the change propagates to Counter in the synthesized netlist. Avoid or be careful when using asynchronous data inputs. 

A function call represents combinational logic since a function call is part of an expression in Verilog HDL. A function call is synthesized by expanding the function call into in-line code. Any local variable declared within the function is treated as a pure temporary such a variable gets synthesized as a wire. 

Verilog HDL has two non-logical values x (unknown) and z (high-impedance). In this section, we specify the domain under which these values can be used for synthesis. Use caution when using these values in a synthesis model as they can potentially cause a functional mismatch between the design model and the synthesized netlist. 

Parameters in Verilog HDL provide a powerful mechanism to model parameterized designs. Here is a simple example of an TV-bit register. 

Chapter 3 shows many more modeling examples that show the collective usage of many Verilog HDL constructs. 

In Chapter 2, we looked at the synthesis of Verilog HDL statements into gates. In this chapter we look at an orthogonal view, that is the task of modeling hardware elements for synthesis and how Verilog HDL can be used to achieve this. As before, we show both the Verilog HDL model and the schematic for the synthesized output. 

This chapter also provides a number of more complicated Verilog HDL synthesis examples. These models illustrate the usage of Verilog HDL constructs collectively to model a design that can be synthesized. 

Sequential logic and combinational logic can be synthesized from a Verilog HDL description. There are two main styles for describing combinational logic ... 

A register file can be modeled as a two-dimensional reg variable (a two-dimensional reg variable is referred to as memory in Verilog HDL), which can then be synthesized. Here is an example of a register file. 

For example, a binary count of 4 bll00 corresponds to a Gray count of 4 bl010. Here is a Verilog HDL model for a parameterized N-bit Gray up-counter with synchronous preclear. 

This chapter explores some of these optimizations that may be performed by a designer by rewriting appropriate code in the Verilog HDL synthesis model. These optimizations provide a way to reduce the number of arithmetic and relational operators in the design yielding better quality designs. Synthesis run-times may also be reduced. 

A variable that does not have a value assigned in all branches of a case statement or an if statement can lead to a latch being built. This is because in Verilog HDL, a reg variable (assigned within an always statement) infers memory, and thus if the variable is not assigned a value in all branches of a conditional statement, the value needs to be saved in memory. Here is an example. 

Experimental studies have shown that logic circuits of size between 2000 to 5000 gates are best handled by a logic optimizer. This implies that in a Verilog HDL model, always statements must not be inordinately long. A design should be structured into multiple always statements or multiple modules. 

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

It is useful to retain the hierarchy of a Verilog HDL model in terms of always statements. This enables a hierarchy of sub-circuits to be produced by the synthesis tool that a logic optimizer can effectively handle. 

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. 

A synthesis tool when synthesizing the right-hand-side expression follows the Verilog HDL rules for expression evaluation, that is, left to right, and builds a circuit as shown in Figure 4-4. The logic structure generated may... 

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. 

In this chapter, we assume that the synthesis process produces a synthesized netlist in Verilog HDL as shown in Figure 5-1. A Verilog HDL netlist is a collection of module instances interconnected by nets. 

Another approach is to write a test bench a test bench is a model written in Verilog HDL that applies stimulus, compares the output responses, and reports any functional mismatches. Figure 5-3 shows such a scenario. A test bench for a full-adder is shown next. The stimulus is read from a vector file Inputs.vec its contents are of the form ... 

In the following sections, we see examples of how mismatches may occur that may be caused due to different interpretations by synthesis (as compared to Verilog HDL language semantics). 

To give an idea of what Verilog HDL constructs are synthesizable, this appendix provides a listing of the synthesizable Verilog HDL constructs that are recognized by the ArchSyn synthesis system, vl4.0. This subset may not be the same for all synthesis tools. 

In the following tables, the first column specifies the Verilog HDL feature, the second column indicates whether the feature is supported or not, and the third column is for comments and exceptions. 

---