Verification interfaces

To enable the use scenarios outlined above, we need to interface the various parts of  a hybrid verification solution and bring together simulators, physical hardware and  virtual models. We shall now explore some of those interfaces.

Interfaces for co-simulation

To enable co-simulation, we need to provide a cycle-accurate bi-directional link  between a high-performance RTL simulator and an FPGA-based prototyping system  

Ideally, we want the link between the technologies to be easy to set up and require  no changes to the design itself. Performance of the interface is important, and  ideally the link will offer good debug features. 

To avoid confusion, it is worth comparing the use of FPGA hardware linked to  simulators and a similar technology, known as “hardware in the loop” or HIL. HIL  replaces a block in a simulation model with a faster piece of hardware, usually  implemented in an FPGA. The aim is to use the FPGA to speed up simulation of the  algorithmic model. The FPGA is programmed with some automatically generated  code, which is often only functionally equivalent to the simulation model that it  replaces and will not be cycle-accurate. The initial design in an HIL approach is  often an algorithm modeled in a simulation tool, such as Matlab® or Simulink® and  there is no reference to the RTL that will be used in the SoC implementation. 

In contrast to HIL, the aim of linking FPGA-based prototyping to simulation is to  use the same RTL as the SoC implementation in order to check the validity of the  FPGA implementation, possibly with some speed-up of runtime, or to allow systemwide prototyping before the whole RTL is available.

Example: HDL Bridge

It is useful to look at an actual co-simulation interface by way of example. HDL  Bridge is Synopsys’ proprietary co-simulation link. It provides a bi-directional  interface between Synopsys’ RTL simulator (VCS®), and the FPGA-based  prototyping system (Synopsys CHIPit® or HAPS® prototyping system). The CHIPit  tool can automatically prepare the infrastructure to communicate between the  simulator and hardware based on the RTL provided by the user. CHIPit creates  wrappers without disturbing the original design – a synthesizable wrapper for the  hardware (either Verilog or VHDL) and a separate wrapper for the software  simulator.  

This environment is easy to set up and allows seamless integration with VCS simulation. Once constrained, generating the wrappers is very fast as we need only  provide the top-level design description, define the clock and reset polarity. 

The interface enables comprehensive debug by allowing the simulator to monitor all  internal registers of the design under test (DUT) in the FPGA.  

Figure 150 shows how the HDL Bridge is partitioned so that the non-synthesizable  part of the interface remains in the simulator, while the synthesizable code is implemented in hardware. The wrappers get data from the hardware and software  and give it to the simulator’s PLI interface as it makes PLI calls. The simulator  testbench controls the design.

Figure 151 shows the overall design flow for the Synopsys environment and  highlights the user-defined inputs and the automatically generated code. 

Co-simulation suffers from a fundamental limitation: because the simulator is only  capable of running at a speed of a few kilohertz, and the hardware runs in lock-step,  it is not possible to use real-time interfaces or components that have a minimum  frequency such as technology-dependent primitives including PLLs, DCMs and IP  PHYs. We have covered the issue of addressing FPGA minimum frequency in  chapters 7 and 9, which readers should consult for recommended design strategies.

Recommendation: design teams can save themselves time by thinking ahead and  anticipating issues. Planning the clock structure to support a low-frequency clock  will make the task of setting up for co-simulation easier 

Another issue that designers must watch out for is the trade-off between debug and  performance. HDL Bridge allows designers to monitor the internal registers in the  FPGA, as they increase the number of signals to monitor, the performance of the  interface decreases. 

In summary, co-simulation can take advantage of any simulator’s API in order to  push stimulus to the hardware and receive its responses. It is easy to set up and no  design changes are necessary. The tool takes care of preparing the infrastructure to  communicate between the simulator and hardware once we have created a top-level  description and defined the clock and reset signals.

Interfaces for transaction-based verification

In co-simulation, the simulator is controlling the design in hardware, while in  transaction-based verification, the DUT (in hardware) and simulator (or software  application running on a host machine) communicate by passing messages or  transactions. This requires an abstracted bi-directional link between virtual models  and the FPGA-based prototyping system.

Communicating through transactions and the use of transaction-level models enable  faster simulation and easier debugging than co-simulation. Using transactions,  design teams can focus on the function and behavior of their systems and get that  right before they concern themselves with implementation. They can also define the  verification scenarios that they want to cover more quickly and easily, because they  are using software running on the processor.

TLMs and transactors

The SystemC transaction-level modeling standard (TLM-2.0) defines two coding  styles: loosely timed (LT) and approximately timed (AT). TLM-2.0 models, which  themselves include transactors, enable efficient message-based communication for  exploring the system at a high level of abstraction when written in an LT coding  style. A model that includes an LT transactor is relatively fast to develop because  the transactor simply deals with reads and writes to memory locations. 

However, in the hardware world we cannot ignore timing forever. That is why  TLM-2.0 allows designers to create transactors with timing annotations by writing  models using AT coding styles. Using these, design teams can perform tasks such as  estimating software performance and analyzing different architectures. Developers  can create AT models relatively quickly. 

As designers refine their systems down to real hardware, they need to add even  more timing detail. To enable this we need transactors that can convert from the  function level to and from the signal level. For example, taking TLM-2.0  transactions to, for instance, AMBA® AHB/APB/AXI™ interconnect signals, and  also handling side-band signals such as reset inputs and interrupt request outputs.  These transactors have a cycle-accurate interface to RTL on one side, and a  transaction-level interface on the other side.

Design teams can achieve high-speed transaction-based verification by processing  the compute-intensive part of the transactor in hardware, rather than using software  on the host workstation. This is possible if the transactor is coded as a synthesizable  state machine, or bus functional model (BFM), which receives messages and  converts them into signals that are connected to the design ports or internal buses.  Developing transactors for complex interfaces such as AXI can be time-consuming,  so reuse is extremely desirable.  

The transaction-level interface between the synthesized and simulated parts of the  design is made up of fixed-width unidirectional input and output ports. An input  port sends messages carrying transaction-level information from the simulated  testbench layers to the hardware-assisted layer. An output port sends messages from  the hardware-assisted layer to the simulated layers. There can be any number of  input and output ports. However, the hardware platform may place some restrictions  on their number, width or total width.

SCE-MI

The Accellera standards organization approved version 2.0 of the Standard Co Emulation Modeling Interface (SCE-MI) in 2007. SCE-MI provides a multi-channel  message-passing environment for transaction-based verification. The standard  defines how messages can be sent between software and hardware.

SCE-MI enables design teams to link transaction-level models to hardware  accelerators, emulators and rapid prototyping platforms by interconnecting untimed  software models to structural hardware transactor and DUT models (Figure 152). It  provides a transport infrastructure between the emulator and host workstation sides  of each channel, which interconnects transactor models in an emulator to  C/C++/SystemC (untimed or RTL) models on a workstation.

In SCE-MI version 1.1, the transport infrastructure provides interconnections in the  form of message channels that run between the software side and the hardware side  of the SCE-MI infrastructure. Each message channel has two ends. The end on the  software side is called a message port proxy, which is a C++ object that gives API  access to the channel. The end on the hardware side is a message port macro, which  is instantiated inside a transactor and connected to other components in the  transactor.

A message channel is unidirectional – either an input or an output channel with  respect to the hardware side. However, a message channel is not a unidirectional or  bidirectional bus in the sense of hardware signals, but resembles a network socket  that uses a message-passing protocol. The transactors are responsible for translating  the message-passing protocol into a cycle-based protocol at the DUT interface.  They decompose messages arriving on input channels from the software side into  sequences of cycle-accurate events which can be clocked into the DUT. In the  opposite direction of information flflow, transactors recompose sequences of events coming from the DUT back into messages to be sent via output channels to the  software side. 

Furthermore, the SCE-MI 1.1 infrastructure provides clock (and reset) generation  and shared-clock control using handshake signals with the transactors. This way the  transactors can freeze controlled time (by suspending the clocks) while performing  message composition and decomposition operations.  

SCE-MI 2.0 adopts SystemVerilog’s direct programming interface (DPI) function call model and adds additional features to enable transfer of bi-directional variablelength data between the DUT and the software testbench using just four functions  and pipes.

In case of SCE-MI 2.0, the clock delivered to the SCE-MI transactors is controlled  by the infrastructure and therefore user intervention is not required to stop and start  these clock  signals.

Recommendation: if there is a huge amount of data to be sent, then it is  necessary to use pipes. We can use data transfer functions if there are only  control signals or small amounts of data to be sent. If data transfer functions are used for large amounts of data the handshake overhead can exceed the size of  the packet sent.

SCE-MI 2.0 implementation example

In this example, illustrated in Figure 153, the transactor and infrastructure  communicates with hardware through the UMRBus®. Synopsys’ CHIPit tool uses  the user-defined transactor description to create the hardware infrastructure for the  DUT, and also writes out C/C++ files for the software environments. The  communication between software and hardware uses its own clock domain (SCEMI clock), which is independent of the DUT’s clock domain. During data transfer  between the host software application and hardware via SCE-MI, the SCE-MI  controlled clocks are stopped on the hardware. SCE-MI infrastructure releases the  controlled clocks once the data transfer is complete. Users do not need to take any special steps to manage this – the control clock handling procedure is part of the  SCE-MI 2.0 infrastructure.

Another way to use SCE-MI is to communicate with a simulator incorporating  SystemVerilog testbenches. The SCE-MI 2.0 standard defines a way to  communicate between software and hardware. If users need to communicate with a  simulator within a SCE-MI 2.0 environment, Figure 154 shows how the simulator’s  SystemVerilog testbench can talk via SystemVerilog’s DPI calls to a Cenvironment, and the very same C software can talk to the connected hardware via  DPI-like SCE-MI 2.0 function calls.

VMM HAL

The Verification Methodology Manual (VMM) defines a methodology for  verification that has become widely adopted by design teams. The VMM HAL is a  VMM application that includes a class library to support transaction-level coemulation between a hardware-accelerated design and a VMM-compliant testbench  running on a SystemVerilog simulator, such as Synopsys’ VCS functional  verification simulator.

The hardware abstraction layer enables designers to use different hardware  acceleration platforms with the same constrained-random testbench that is used in  simulation-only environments. Testcases and DUT can target different hardware  platforms without any modifications. Figure 155 gives a very brief overview of the  VMM approach and we see that there is a verification loop driven by high-level,  often object-oriented code which hardly resembles a testbench in the traditional  374 Chapter 13: Prototyping + Verification = The best of both worlds sense. The loop would normally continue via transaction-level drivers into the DUT  and out through transaction-level monitors to complete the loop with some  comparisons and a scoreboard of results passed.

With the HAL, the transaction-level drivers and monitors are replaced with SCEMI2.0 transactors and the DUT is the FPGA-based prototype containing a version  of the SoC design. The VMM HAL application also contains a purely simulated implementation of the  hardware abstraction layer that allows the testbench and testcases to be developed  and debugged with the DUT entirely within the same simulation, without  modifications, and without access to the hardware emulator.

The VMM HAL environment can target hardware or simulation at runtime by using  a simple simulator command-line switch. The environment includes drivers and  monitors, which are software-software transactors in a normal VMM environment.  VMM HAL transactors for hardware must be synthesizable. 

Some companies are starting to build up VMM HAL transactor libraries. A key  benefit of the VMM HAL is that it maximizes reuse of testbench code. A designer  does not need to modify the top layers of the verification environment (such as tests,  generators and transactors), only the lower-layer monitors and drivers need to be  made HAL-compliant.

Physical interfaces for co-verification

Physical interfaces for co-verification are those implemented in the prototyping  environment to support communication between a host system and hardware. The  physical layer can use any transport mechanism, and design teams can opt to use a  standard PC interface like PCIe. Whatever physical interface they settle on, ideally  it should offer ease of use for faster validation of the hardware prototype, better  design debugging and easy prototype configuration. Support for advanced use  modes will also be beneficial, especially support of: standard APIs; RTL-based cosimulation and debugging; accelerated transaction-based verification; and  connecting to and co-simulating with virtual prototypes. Interfaces that enable rapid  initialization of the system and remote access and management of the FPGA-based  prototype allow design teams to get the most use from their prototypes. 

Synopsys has designed the UMRBus physical interface specifically to provide high performance, low-latency communications between a host and Synopsys’ FPGA based prototype platforms. We previously introduced UMRBus in chapter 11 in the  context of debugging. To recap, UMRBus is a high-speed connection between the  host workstation and the prototype that provides parallel access to all FPGAs,  board-level control infrastructure and memories (internal and external) on the  Synopsys FPGA-based prototyping platforms.