Content area
In addition to standard system interfaces, most verification environments are likely to have customer specific or even proprietary requirements. Co-modelling is the ideal flexible, high-speed interface for quickly building these verification systems. Examples of general solutions include co-modelling products built on Vera, Co- Ware and the ARM instruction set simulator. For all solutions, Co- modelling provides a targetless high performance verification platform, a stable programming interface and an extendible modelling environment. The design of the application adapter and RTL transactor must be done prior to running co-verification. These models will vary in complexity and size depending on the design and type of the interface. Common applications such as data streaming are likely to yield adapters and trans-actors that can be built by modifying a standard template. With the initial release of TIP, IKOS delivers a simple data streaming co-modelling template. IKOS also plans to develop other co-modelling products for standard protocols like PCI and Ethernet, as well as a transaction compiler that can automate the generation of co-modelling interfaces.
A more detailed look of TAPI and the co-modelling macros depicts the interaction between the `C' functions on the host workstation and logic elements in the VStation. Figure 5 illustrates how co- modelling systems are architect by the user in `C' and Verilog. The logical data transfer between the `C' API and the co-modelling macros implement data transfer to and from the VStation. The RTL transactor manages the data transfer and interaction with the DUT. Once a communication channel has been opened with the TAPI_initInterface(_) function, the handle is passed to other TAPI functions to specify that channel. The input and output macros correspond directly to the TAPI_write () and TAPI_read() functions. Clocking in the DUT is controlled in the clock control co-modelling macro by gating the free running internally generate clock. In simple cycle-synchronous interfaces the clock control macro can be hooked directly to the data_done and new_data signals in the input and output macros so that each vector generates the clock. Alternatively, the user can create transactors that decode the data and generate arbitrary clock and data waveforms on the DUT. More advanced transactor design will utilize transaction density to achieve even higher performance.
The key to developing fast co-verification solutions is to find natural transaction boundaries between the platforms and use to the TIP interface to model those transactions. In determining optimal transaction boundaries, it is useful to understand the parameters that influence the performance of co-modelling solutions. A co- modelling solution consists of essentially three components, a system model or test bench connected to TAPI, an RTL transactor and the DUT. The verification speed is largely determined by four parameters, the amount of time spent per transaction in the system model, the maximum speed at which the DUT can run, the number of DUT cycles run per transaction, and the communication overhead between the work-station and hardware platform. Running more DUT cycles per transaction is usually the single best strategy to speed up co-modelling solutions. TIP performance is measured in transactions per second. More cycles per transactions multiplied by the same number of transactions per second gives more effective cycles per second. This is how a transaction based co-modelling interface can provide maxim performance. Optimising the system model or moving highly active parts of the system model into the emulator often results in performance wins. Since a co-verification solution can run no faster than its slowest part, IKOS has focused on creating the fastest workstation interface and transaction based co-modelling solutions.
By Mitch Dale, IKOS, Cupertino, CA
Today, the solution to the design complexity-verification problem, rests with a mixture of hardware and software platforms. Design verification has moved from interfaces that sychronise with events, to those that are clock cycle synchronous onto `transaction' co- modelling based solutions, where the interface communications are raised to a high level of abstraction. Here, a Transaction Portal is described against the background of the earlier, slower interface options.
As System-on-Chip (SoC) complexity increases, traditional methods of verification using HDL software simulators prove to be insufficient.They do not provide the verification power needed to check for correct system functionality, ensure high quality and gain confidence for first time working silicon. In addition, the verification of complex SOC devices now requires modelling the entire system and running enough real world situations to verify that the whole system works, as well as the chip.These factors present the need for a flexible modelling environment that can run at very high speeds, at least 1000 times faster than current software simulators, in order to process a meaningful number of system level options. A flexible, high-speed modelling environment allows the designer to develop real world test cases from high-level system models, captured live data, and interaction between system level interfaces. Built upon a unique interface technology, the IKOS Transaction Interface Portal to be discussed here provides a high-speed link between software at the abstract level and the detailed hardware implementation. This high speed, flexible interface along with the IKOS VStation, see Figure 1, enables the user to run mission software, verify system-level operation and quickly find and debug design problems.
Enabling co-modelling through TIP
Co-verification is the use of multiple interconnected platforms that form a unified verification environment. In the co-verification environment, parts of the design and testbench are partitioned onto each of the platforms and run in concert. Several specific types of co-verification exist today.
Co-simulation
Co-simulation is currently the most common form of co- verification. Co-simulation integrates an HDL software simulator with a high speed hardware platform for accelerated HDL simulation. The HDL software simulator runs on the host workstation, transferring data and synchronising with the hardware platform at each event exchange on the interface. Performance of Co-simulation solutions are limited by the HDL simulator and the event based inter-face. Typical Co-simulation performance is in the range of 100 to 3000c/s (clocks per second) for IKOS Voyager (VHDL) and Gemini (Verilog) products, integrated with the IKOS NSIM and ARES hardware accelerators respectively, provide two such examples of co-simulation.
Cycle-synchronous
Cycle-synchronous co-verification is a variation of co- simulation. Cycle-synchronous interfaces connect multiple platforms together with data and time synchronisation occurring only on clock edges. An example of a cycle-synchronous interface is shown in figure 2, which is an HDL software simulator connected to an instruction set simulator (ISS). In this example, the Behavioural Interface Model (BIM) maintains lock step, clock cycle relation with the RTL and gate- level models running in the accelerated hardware platform. At the same time the ISS model (i.e. C, Java, high level language) generates data transactions with the BIM.The BIM then combines the data with the timing information to create the cycle accurate timing to the DUT. The performance of Cycle-Synchronous solutions will be faster than Co-simulation because of reduced number of synchronisations. However, the HDL simulator and the lock step nature of the interface will limit performance to the 100 to 10000 C/s range. Both co- simulation and the cycle-synchronous interfaces are considered timed interfaces because both platforms are always in lock step with respect to the simulation time.
Co-modelling & transaction-based Interfaces
A further abstraction of the coverification boundary achieves higher performance through the creation of a co-modelling interface. Co-modelling involves modelling the platform boundary with transactions instead of cycles or events. This requires a separation of the communication functionality from the timing details. Synchronisation of untimed interfaces requires that a protocol be defined between the verification platforms. This protocol comes in the form of a transaction. A transaction combines the data structure and associated timing template together to define a multi-cycle communication sequence between the test environment in software and the device under test (DUT). Transactions across the interface are an abstraction of command, data and clocking information. The objective is to communicate the data in a way that preserves the speeds of both environments. Maximum performance can be achieved when each transaction communication executes multiple clock cycles (i.e. hundreds to thousands of cycles) in the hardware platform for each transaction generated in the software model.
With a transaction interface, it is possible to integrate co- verification applications that yield performance in the 100,000 to 1,000,000 C/s range.
One useful and common type of a transaction interface is Data Streaming. With Data Streaming, the data source contains implicit clocking information and is not reactive with DUT. Consequently, there is no need for an interface protocol and data is directly piped into the DUT. An example of data streaming co-verification is the use of MPEG video streams. In this case, the design processing the MPEG stream reads the data and generates clocks as fast as the verification platform can run and data can be supplied.
Abstract view of the Transaction Interface Portal
The Transaction Interface Portal provides a communication channel between the host workstation and the hardware emulator. Figure 3 illustrates how TIP fits into an abstract co-verification environment. TIP provides the physical transport layer between platforms, a set of RTL co-modelling macros in VLE and a `C' Transaction Application Programming Interface (TAPI) on the workstation. With TIP, it is possible to develop Co-modelling interfaces that control the verification environment, directly communicate abstract data and regulate the user clocks in the DUT.
TIP in an abstract co-modelling environment
TIP enables the development of reusable co-modelling solutions with `adapters' and `transactors' created for stan-dard interfaces such as MPEG and PCI. The adapter provides the linkage into the system model or user `C' application on the workstation. The transactor is a piece of RTL code that translates data transfers into the pins wiggles and clocking of the DUT.
In addition to standard system interfaces, most verification environments are likely to have customer specific or even proprietary requirements. Co-modelling is the ideal flexible, high-speed interface for quickly building these verification systems. Examples of general solutions include co-modelling products built on Vera, Co- Ware and the ARM instruction set simulator. For all solutions, Co- modelling provides a targetless high performance verification platform, a stable programming interface and an extendible modelling environment. The design of the application adapter and RTL transactor must be done prior to running co-verification. These models will vary in complexity and size depending on the design and type of the interface. Common applications such as data streaming are likely to yield adapters and trans-actors that can be built by modifying a standard template. With the initial release of TIP, IKOS delivers a simple data streaming co-modelling template. IKOS also plans to develop other co-modelling products for standard protocols like PCI and Ethernet, as well as a transaction compiler that can automate the generation of co-modelling interfaces.
Transaction interface capabilities
In addition to interfacing with abstract software models, the IKOS Transaction Interface Portal provides the user the capability to configure and control the VStation. Through this mechanism it is possible to create a targetless verification environment that can be completely controlled via a scripting language like TCL.
Figure 4 shows a high level diagram of a TIP set-up. After the system is defined and coded, the compile process is run on the user C program and design. The main program call functions that down-load, configure and run the VStation.
Transaction application programming interface
A more detailed look of TAPI and the co-modelling macros depicts the interaction between the `C' functions on the host workstation and logic elements in the VStation. Figure 5 illustrates how co- modelling systems are architect by the user in `C' and Verilog. The logical data transfer between the `C' API and the co-modelling macros implement data transfer to and from the VStation. The RTL transactor manages the data transfer and interaction with the DUT. Once a communication channel has been opened with the TAPI_initInterface(_) function, the handle is passed to other TAPI functions to specify that channel. The input and output macros correspond directly to the TAPI_write () and TAPI_read() functions. Clocking in the DUT is controlled in the clock control co-modelling macro by gating the free running internally generate clock. In simple cycle-synchronous interfaces the clock control macro can be hooked directly to the data_done and new_data signals in the input and output macros so that each vector generates the clock. Alternatively, the user can create transactors that decode the data and generate arbitrary clock and data waveforms on the DUT. More advanced transactor design will utilize transaction density to achieve even higher performance.
Determining the optimum speed
Understanding the size of the verification problem is the key to determining what speed is required in system verification. By counting the total number of cycles in a typical verification test the user can identify if a given verification solution will meet their need. For example, consider the verification of a MPEG video design with a video resolution of 1280 x 1024; each frame contains 1,310,720 pixels. If a nominal test requires generating 10 frames of data and the design can process a pixel on each clock cycle, 13.1M clocks must be executed for a nominal test. With an HDL software simulator running at 40CPS, this test would take over three days. Using the Transaction Interface Portal at 200kHz, the test completes in a little more than a minute! Each co-verification solution will run at a different speed depending on the type of application, speed of the system models, and specifics of the co-verification interface.
The key to developing fast co-verification solutions is to find natural transaction boundaries between the platforms and use to the TIP interface to model those transactions. In determining optimal transaction boundaries, it is useful to understand the parameters that influence the performance of co-modelling solutions. A co- modelling solution consists of essentially three components, a system model or test bench connected to TAPI, an RTL transactor and the DUT. The verification speed is largely determined by four parameters, the amount of time spent per transaction in the system model, the maximum speed at which the DUT can run, the number of DUT cycles run per transaction, and the communication overhead between the work-station and hardware platform. Running more DUT cycles per transaction is usually the single best strategy to speed up co-modelling solutions. TIP performance is measured in transactions per second. More cycles per transactions multiplied by the same number of transactions per second gives more effective cycles per second. This is how a transaction based co-modelling interface can provide maxim performance. Optimising the system model or moving highly active parts of the system model into the emulator often results in performance wins. Since a co-verification solution can run no faster than its slowest part, IKOS has focused on creating the fastest workstation interface and transaction based co-modelling solutions.
Conclusion
The IKOS Transaction Interface Portal provides the foundation technology for solutions in the Cycle-synchro-nous, Co-modelling and Data Streaming problem space as illustrated in Figure 6. TIP delivers a high speed, flexible interface for creating system level verification environments.
Tel: 001 408 255 4567
Credit: IKOS Transaction Interface Portal
Copyright Miller Freeman plc Jan 18, 2001