How to raise the RTL abstraction level and design conciseness with SystemVerilog - Part 2
Using advanced HDLs like SystemVerilog, current hardware modeling styles can be enhanced both in terms of abstraction levels and overall efficiency.
As discussed in
Part 1, this article proposes four steps to raise the abstraction level of current Verilog HDL designs and provide a phase wise approach to migrate to SystemVerilog.
- Enhance conciseness and expressiveness of designs.
- Add built-in checks to avoid design issues.
- Design efficient FSM and RAM/ROM memory models.
- Graduate to object oriented generic hardware designs.
In Part 1 we examined Steps1 and 2 – conciseness of expression and built-in code verification. Now, in Part 2, we will elaborate on Steps 3 and 4 and demonstrate how designers can improve code encapsulation, re-use, and consistency in model behavior – all without adversely affecting the quality of results.
Step 3: Design efficient FSMs and RAM/ROM memory models
#1 – Designing finite state machines
SystemVerilog enables modelling at higher levels of abstraction through the use of the following:
- Strongly typed enumerated types with state encoding.
- 2-state data types and user defined types.
- Specialized always_comb, always_latch, and always_ff blocks.
- Unique and priority case statements.
These enhancements enable accurate modelling that simulate and synthesize correctly with consistent behaviour across all tools.
The new SystemVerilog coding style is also easy to read and maintain compared to the Verilog method of modelling FSM's.
Example 1. FSM Modelling with SystemVerilog.
(Click this image to view a larger, more detailed version)
#2 – Designing RAM and ROM models
SystemVerilog also provides an enhanced method to model highly generic and complex memories with a very simple and readable representation. With the usage of powerful features like parameter types and user defined data types memory modelling gets very simplified.
Example shows how to effectively model RAM or ROM memories with SystemVerilog.
Example 2. Modeling RAM and ROM memories with SystemVerilog.
(Click this image to view a larger, more detailed version)
Step 4: Graduate to object oriented generic hardware designs
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.
The following three ways can be used to employ object oriented modelling techniques in hardware designs.
#1 – SystemVerilog interfaces for encapsulation
The Verilog language connects modules through module ports. For large designs, using module ports to connect blocks of a design together can result in duplication of port declarations and communication protocols, increasing the risk of mismatched declarations and reducing the flexibility to modify or scale up or scale down in the future.
a) Communication models
SystemVerilog interfaces offer an object oriented paradigm for abstraction in communication models by focusing the description in one location. This ability to localize the description of an interface, use it as abstract port type, and let the synthesis process appropriately spread the hardware through the design, provides a big advantage to the design process.
An interface can contain data type declarations, tasks, functions, continuous assign statements, and procedural blocks to specify communication protocols based on bus signals. This can be 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.
This provides an advantage in terms of scalability. For example, 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. Another example is 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.
SystemVerilog allows multiple views of the interface to be defined using modports. For example, each module connected to the interface can specify and share direction of the signal local to the interface port. Significant code size reduction is 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.
1. Interface connecting two modules (MY_INTER1, MY_INTER2).
(Click this image to view a larger, more detailed version)
b) Transaction level modelling
Verilog-2001 and VHDL-2000 do not provide the ability to define an interface method; hence transaction level modelling technique can only be used in system modelling and in the verification domain.
With SystemVerilog, interfaces can represent both pin level signals for structural communication with RTL blocks and TLM in the form of tasks, functions, and procedural blocks. This allows hardware designers to take advantage of the TLM concept and represent the design at a more abstract level. This will assist verification of SystemVerilog designs due to better integration with transaction level test benches, with the benefits of ease of design, code reuse, and simulation performance.
Example 3. TLM design methodology.
(Click this image to view a larger, more detailed version)
