Collecting objects and their functionality together in the form of object-oriented programming has been one of the biggest recent advancements in software design. It allows one individual to be responsible for the description and maintenance of an object, rather than spreading that knowledge diffusely throughout a design, creating a risk that integration will expose differences in understanding. With the advent of SystemVerilog, this unification is now available for hardware design.

Conciseness of expression is achieved through the addition of coding shortcuts from C, the simplification of port expressions, and the collection of related data together. Several studies have shown that the number of bugs in a piece of software directly correlates with the number of lines of code. Using constructs that reduce the number of lines necessary to describe functionality is an important tool to reduce the pre and post-tapeout issues found in a design.

One significant design issue exposed during the verification phase is "simulation synthesis mismatch." Having gate-level simulation discover that someone put in a parallel case or full case pragma when the pragma was not true can wreck havoc with a schedule. The addition of unique and priority keywords, such as always_comb, always_latch, always_ff, and assertions allows tools to verify that the designer's assumptions and intent are in alignment with his synthesized design, reducing the likelihood that the schedule will have to slip at the last moment.

Structured approach

Let's examine several of the features of SystemVerilog and see how they achieve these benefits. The first feature we examine is structures. Derived from the C language, structures provide a way to collect related variable declarations together into a single object.

Consider the example in Figure 1. In this example of a small FIFO, the Verilog 2001 version lists each of the fields of a packet (src, dst, and data) as individual ports on the design. They are listed twice, once for the incoming direction, once for the outgoing direction.

In the SystemVerilog version, these fields have been collected together into a structure called packet_t. This collection has reduced the number of ports from six to two. In addition, when it becomes necessary to add new fields to a packet, rather than adding them multiple times in the port list, as for the Verilog 2001 example, the ports can be added once to the structure packet_t.

This localization of data description into one object — the structure declaration — improves the specification of the design. The grouped items no longer need to be listed repeatedly, but can instead be treated as a single object, reducing code size, and enhancing readability. Expanding the group to include new members requires modification of the description in a single location rather than spreading the changes throughout the design, reducing support costs.

Figure 1 — A FIFO example in Verilog 2001 and SystemVerilog

Interface specifications

Another feature of SystemVerilog that improves design specification is interfaces. Interfaces are designed to model communication between modules, focusing the description in one location. Consider the processor example in Figure 2. In this design, the processor, module TOP, has a bus, chip_bus, for connecting between the CPU and the RAM modules.

Figure 2 — Interface description and synthesis

The description of the signals on the bus is localized into the description of the chip_bus interface. The interface is instantiated in the module TOP, creating the signals within that module. The interface has a port, clk, that allows it to incorporate signals from the module top into the bus. Port directions for the interface are specified using modports.

Both the modules CPU and RAM call functions associated with the interface to perform actions supported by the interface. The interface also instantiates some hardware in module TOP through the use of the always block embedded within it. The synthesis of this interface description is achieved by spreading the hardware described in the interface appropriately throughout the design.

The ability to localize the description of an interface, and let the synthesis process appropriately spread the hardware through the design, provides a big advantage to the design process. Many design teams have written a specification for a bus, only to find out in integration testing that the specification was not quite clear enough, and that there were two or more interpretations of it, requiring pieces of the design to be reworked.

When interfaces are used, one engineer can own the interface and provide an API that other engineers can use to connect to the bus, hiding the details of the data transfer onto and off of the bus. Another advantage to design of interfaces arises because the description is in a single location. If another signal needs to be added to the interface, this can be done without requiring every module that passes the bus through it to be modified to add the signal.

A third advantage of interfaces is that they are easily exchangeable with other interfaces supporting the same API. For example, if a design was originally developed with a serial bus, and it is discovered that a parallel bus is needed, the interface can be exchanged, leaving the rest of the design unchanged — a very fast method to retarget a design. Significant code size reduction is also possible when multiple modules refer to the same interface; rather than listing all of the ports on each module, the single port reflecting the interface is sufficient.

Always blocks

In addition to features to support focused design, like structures and interfaces, SystemVerilog also adds new forms of always blocks to allow engineers to specify their design intent in a way that tools can verify. Always_comb is for the specification of combinational logic. Synthesis tools can check that the hardware synthesized from the block does not contain any sequential elements. Additionally, the activation expression for an always_comb block is calculated by tools rather than by the user, ensuring that simulation will behave closely with the synthesized result.

Always_latch is another form of always block designed to express latch logic. Tools can verify that a latch is required by the description or inform users that there is a problem with the design. As for always_comb blocks, the activation expression for an always_latch is also inferred by tools, ensuring that simulation and the synthesized result behave similarly.

The always_ff block was added to ensure that the hardware being described contains a flip-flop. These blocks also limit the block to a single activation expression, so that an implicit state machine will not be inferred.

To reduce one form of "simulation synthesis mismatch," the unique and priority designations were added to SystemVerilog. Designating a case statement as unique is equivalent to adding a parallel case and full case pragma to the statement.

The additional benefit of having it in the language is that the simulators and formal verification tools can check that there is always exactly one arm of the specified case statement active. Priority case statements tell synthesis tools to treat the case statement as a full case, and simulators to generate an error if there is ever a condition where one of the case labels is not true.

The new always forms and the unique and priority keywords are important new additions to design because they allow simulation and synthesis to have a more unified view of the hardware description. This unification reduces the likelihood of encountering a simulation error in the gate-level netlist by allowing issues to be caught in the RTL simulation phase.

All of these features can make important contributions to the design process, improving the descriptiveness of design, the conciseness of a design, and the correlation of the gate-level netlist with the RTL. The next question that arises is whether there is an impact to the quality of the synthesized result using these features. To investigate this issue, we compared a number of Verilog designs and their SystemVerilog equivalents implemented using using structures, interfaces, modports, always_comb, always_ff, and unique and priority keywords. After synthesis, we observed no change in the timing or area of the designs.

Karen Pieper is the R&D Manager for HDL Compiler, the RTL to unmapped gates synthesis engine in DesignCompiler. She serves as the Chair of the IEEE 1364 Verilog Errata Task Force, and as the Co-Chair of the Accellera SystemVerilog Design Committee. During her tenure at Synopsys, she has contributed to the development of DesignCompiler, Formality, an early Verilog simulation tool, and Internet Enabled Design.