| Partner Solution|
From Transaction Level to RTL
Jonathan Bromley, Consultant, Doulos, explains an approach to modeling using SystemVerilog that allows seamless refinement of a chip design from transaction level models to RTL.
A common requirement when verifying a design is the comparison of a high-level or abstract reference model against an RTL implementation. Often, designers create these two types of model in different programming languages and using completely different modeling styles. Designers prefer to write high-level models using a transaction-level modeling (TLM) style. TL models operate in a very different way to RTL; they are often written in C++, taking advantage of SystemC modeling. Consequently, although designers can simulate the two models in isolation, it is less easy to simulate and compare them together in a common environment.
It is possible to write high-level behavioral models in Verilog or VHDL, and we can simulate them in a common environment alongside RTL models. However, such HDLs have limitations when attempting to create flexible, transaction-level communication between modules. VHDL does not support procedural entry points to a module (i.e., cross-module subprogram call). Verilog does provide cross-module subprogram call, but has an insufficiently expressive data type system for serious TL modeling, and has no support for any kind of dynamically-allocated or dynamically-sized data objects. Neither language supports the object-oriented programming (OOP) features that software engineers expect. These limitations make VHDL and Verilog ill-suited for serious TL models.
The disparity in modeling style between typical RTL and TL models means that direct
equivalence checking using formal techniques is unlikely to be possible.
A handful of "C-to-gates" tools intended to take abstract or behavioral descriptions and synthesize them to RTL or gate-level are commercially available today and all of them find useful application in some areas, but today's mainstream digital design applications remain largely unaffected by this technology.
Digital simulation tools from several major vendors already offer the ability to integrate models in various languages, usually including at least Verilog, VHDL and C++/SystemC, into a common simulation. It is clear that this is a very powerful approach and tool vendors have made impressive progress in making such mixed-language simulation as straightforward as possible for the end user.
An alternative approach, which offers an attractive compromise between ease of use and expressiveness, uses SystemVerilog throughout.
Using SystemVerilog Interfaces
Typical TLM function-call interfaces might represent the execution of a complete data transfer cycle on a microprocessor bus, or the movement of a data packet over a communications channel. We can realize more performance benefits of TLM if each function call performs a large amount of activity. Each such function call typically represents a block of activity that would span many clock cycles in an RTL simulation, and the TLM simulation therefore provides less accurate modeling of timing. At one extreme it is possible to write a model of the functionality of a system that takes no account of simulated time – an untimed functional model – whilst preserving the correct sequential ordering of different activities in the various components of the model.
Components in a transaction-level model communicate by function call; the initiator calls a function in the target. However, to support modular design and component reuse, this call should be done indirectly. It is inappropriate for an initiator component to be hard-coded for details of the target. Instead, some kind of indirection is used. A typical mechanism uses the notion of ports and exports.
An initiator is equipped with an instance of a suitable port object, and calls the appropriate method (function) in that port object. The target has an instance of a corresponding export object, and provides an implementation of the method specified in the export. We code the initiator as if it calls a function in the port, and the target as if the export calls its function. However, a connection mechanism allows us to bind ports and exports together so that we can redirect the initiator's function call into its port to the target's export, which in its turn redirects the function call to the real implementation in the target. Given appropriate support from the chosen programming language, we can achieve this redirection with negligible run-time overhead. We implement the redirection in SystemVerilog by putting the exported method in a class and instantiating that class within the provider module. Port-to-export binding then arranges that the client (caller) has a reference to the instance containing the method. The client can then easily call the method through this reference. Similar but more elaborate arrangements are used in SystemC, exploiting the C++ language's multiple-inheritance feature.
In the world of transaction-level modeling, this port binding is done dynamically, but SystemVerilog also offers a static mechanism in which initiator-to-target binding is specified as part of the module instance hierarchy. Although this static mechanism is less flexible than dynamic port binding, it fits better into a refinement flow that incorporates both RTL and TL models, since RTL models are invariably instantiated and connected as part of the static (time-zero) elaboration of the module instance hierarchy. The mechanism in question is the subprogram import and export via modports on SystemVerilog interfaces.
TL Model in SystemVerilog
We have coded an example system (Figure 1) in a TL modeling style, using SystemVerilog modules and interfaces. We modeled it without the use of SystemVerilog classes, instead using a completely static hierarchy of module and interface instances. Using an entirely static connection mechanism for TLM makes it possible to refine components to RTL with minimal disruption to other parts of the model. By contrast, had we coded TLM in the traditional manner using OOP techniques then the connection mechanism between TL models is so very different from the connections between RTL models that it is very disruptive to change any one component from one modeling style to the other.
Figure 1. Example system includes a variety of functional blocks and interesting behaviors
An alternative approach uses a "gasket" module as a bridge between interfaces at different abstraction levels. This technique provides more portability across simulators since it does not rely on having support for generic interface ports. This approach, illustrated in block diagram form in Figure 2, meets our original objectives (that the remainder of the system model should be undisturbed by the refinement step) at the cost of a somewhat more clumsy interconnection between TL and RTL models. The RTL memory model now connects to the same RTL-style interface that will be used in a pure-RTL system. The TL fabric model connects to the same TL-style interface that was used in the pure-TLM system. A new gasket module provides the bridge between the two interfaces. From the point of view of the TL interface it mimics the TL memory model; from the point of view of the RTL interface it mimics an RTL implementation of the fabric module.
Figure 2: Use of a gasket module to adapt from one modeling style to another
Refining the Model to RTL
We can run the TL system model in simulation, with the CPU executing simulated instructions stored in the ROM model. Although there is no timing in this model, we have faithfully preserved the relative ordering of memory accesses from CPU and DMA components and we can observe and debug the overall flow of activity in the system. We captured the individual component models in an abstract style, with no concern for timing or signal-level detail, and therefore are concise and easy to create. Designers can write models of this kind much more quickly and reliably than RTL designs, facilitating early testing of the overall system in simulation.
As the design progresses, RTL implementations of individual modules become available. Thanks to the flexibility of SystemVerilog interfaces, it is relatively straightforward to integrate these RTL models into the otherwise TL system model.
Completing the Migration to RTL
Given the gasket-module arrangements, it becomes very easy to migrate the model incrementally from TL to RTL modeling style. Use of SystemVerilog gasket modules means that each block in the design can connect to whatever sort of interface it expects to use. If a block at the other end of the interface is to be modeled in a different style, a gasket module and a second interface provides the necessary link; if that other block uses the same modeling style, no gasket and no second interface is needed. We have achieved our original aim of progressive module-by-module refinement of a model, with no disturbance to other parts of the model at each refinement step.
We have also implemented the entire system in a conventional RTL style. Even for this rather small system (fewer than 20,000 ASIC-equivalent gates) the simulation speed improvement of TLM over RTL was about a factor of 30 in our experiments using Synopsys' VCS® simulator. To make these speed measurements we created test programs for the modeled CPU that ran several million modeled CPU instructions, consuming many seconds of workstation CPU time. For simulations this long, we were able to observe simulation runtime increasing linearly with number of simulated instructions, to a repeatability of better than 5%. We therefore concluded that our simulations were long enough that the one-off time costs of loading the simulation, initialization and so forth were negligible and therefore our measurements were acceptably reliable. We made the measurements on a desktop Linux workstation with negligible CPU load other than the simulation being measured. Sample measurements are given in Figure 3.
Figure 3. Sample simulation results
For larger designs containing many more signals, we would expect to see even greater simulation performance benefits of TL modeling over a register-transfer style.
For our first performance tests we compared two versions of the system in which only the readwrite memory module was changed from TL to RTL style, and the remainder of the system was all TLM. We were initially surprised to see only a factor of 2 slowdown in the RTL simulation, until we noted that our mix of instructions executed by the CPU performs a read/write memory access only about once for every 50 clock cycles. We then also migrated the ROM implementation from TL to RTL, and observed a much larger slowdown (the CPU performs many more accesses to ROM than to read/write memory). We conjecture that the total simulation time for such a model is dominated by, and is closely linear with, the amount of RTL activity. The transaction-level parts of the model represent only a very small part of the total simulation time when even a small part of the system is re-implemented as RTL. This observation leads us to believe that a hybrid TL/RTL system model of a system provides a useful and efficient vehicle for the testing of individual RTL models in an environment otherwise largely implemented using TL components.
Integration of C-based TL Models
SystemVerilog's Direct Programming Interface (DPI) features make it very straightforward to call C or C++ routines from a SystemVerilog model. Consequently, we can easily call C models that have a TL-style interface either from within a SystemVerilog interface or from a stub module that has an interface-type port. In both cases the C functions are then available, in the guise of SystemVerilog functions or tasks, for import from the SystemVerilog interface into a connected client module.
Using SystemVerilog interfaces to implement TL-style communication and connection makes it possible to refine TL models to RTL and integrate them with a TL system model without disrupting other parts of the model. A SystemVerilog interface can be modified to provide appropriate adapter functionality between modeling styles; alternatively, a gasket module can easily be introduced between different styles of interface, to meet the same need if tool support for generic interface ports is not available. Consequently, each TL-to-RTL refinement step can be verified by execution in a common simulation environment, with minimal disruption to other components of the system model. Although the introduction of any RTL code into an otherwise TL system model is sure to impose a significant performance penalty, this penalty is no larger than would be expected with other techniques. Combined with the use of SV-DPI to link to external C/C++ models, this approach makes SystemVerilog interfaces attractive as "glue" for integrating heterogeneous modeling styles, permitting the same verification environment to be re-used whilst components of a system are progressively refined from behavioral to RTL modeling styles.
Jonathan Bromley graduated in Physics from Oxford University, England, and began his electronics career 25 years ago developing real-time machine vision hardware for academic groups and start-up companies.
Subsequently he taught electronics on the faculty of Oxford Brookes University, England and continued to work in robotics and vision system development.
In 2001 Jonathan joined the global language and methodology training company Doulos, where he has continued his involvement in ASIC and FPGA design through consultancy work but has specialized in developing and delivering training classes on all things HDL-related, with particular focus on SystemVerilog and testbench automation. He has authored award-winning technical conference papers and is an active participant in SystemVerilog language standardization.
Doulos develops and delivers global training solutions for SoC, FPGA and ASIC design and verification. Established in 1990 and fully independent their unparalleled in-house expertise supports methodology training for SystemVerilog, SystemC, e, PSL, Verilog, and VHDL. Doulos know-how has contributed to the success of more than 700 companies across 35 countries through in-house training, and a regular schedule of classes in the US and Europe.
©2010 Synopsys, Inc. Synopsys and the Synopsys logo are registered trademarks of Synopsys, Inc. All other company and product names mentioned herein may be trademarks or registered trademarks of their respective owners and should be treated as such.