Transaction Analysis and Debug across Language Boundaries and between Abstraction Levels

Rich Edelman, Mentor Graphics Corporation
San Jose, CA, USA

Abstract :

Transaction analysis and debug between multiple abstraction levels is now possible with current technology. This paper will present an API and implementation for recording transactions from SystemC, C or C++, SystemVerilog, VHDL and Verilog. Additionally, we'll discuss how to record transactions from existing RTL or gate level designs.

INTRODUCTION

Transaction analysis and debug is enabled by recording transactions as they occur, either for immediate analysis and debug or for later analysis and debug. Some of the transaction analysis can be performed immediately – like calculating the current transactions "throughput" on a bus. Other kinds of analysis – like understanding bottlenecks and delays might need to be performed at the end of simulation or as a post-processing step.

In addition to the traditional database of transactions, it is convenient to have the transactions available "live" during simulation, in a simulation modeling database. We will discuss how the proposed recording API can be used in both ways – as a way to record transactions into a database, but also as a way to have "live" transaction information available for other kinds of analysis.

API AND DATA MODEL

The API (Figure 1) consists of SystemVerilog function calls which are callable from C using DPI, and a collection of macros to simplify certain repetitive tasks. The SystemVerilog function calls provide a data model and function-call interface. That interface is extended with lower level PLI calls that record into vendor specific databases. The SystemVerilog data model provides additional functionality, not available in common recording interfaces, including tagging transactions, and posted locations where transactions can be placed for later retrieval and further analysis.

Figure 1 - Layered Recording API – with DPI

The RTL and gate level interfaces discussed are a collection of monitors enabled by binding a monitor into existing implementations. Those bound monitors cause transactions to be generated for the data model to record.

Transaction Recording Background

Transaction recording has been available with SystemVerilog [1], OVM [2] and SystemC [3][4]. These systems have unique modeling assumptions and certain incompatible data models.

Unifying these languages with respect to transaction recording will allow the transactions and the transaction analysis to be more complete and more self-consistent.

In addition, internal signals and busses in RTL and gate descriptions previously relegated to signal level analysis can be combined to create transactions. These transactions are actual on-chip communications and can be very valuable for debug and analysis. The internal signals and busses can easily be observed, and transactions captured at interesting times.

Existing APIs

Programming interfaces exist today to record transactions (See Figure 2).

Figure 2 - Layered Recording API

A transaction recording database may be supported with a C API. The C API may be proprietary or have a complex use model. Integrations between existing Verilog designs and the C API have been created using the PLI [1].

SystemVerilog APIs have been implemented on top of the PLI API, and offer a more generic use model. Class libraries like the OVM [4] have further extracted the SystemVerilog use model into a higher level abstraction.

These transaction recording APIs provide useful functionality, but can be difficult to use. C APIs can be complex to use, and hard to extend by the user. A PLI API is complex, hard to change, and has difficult usage.

A SystemVerilog API provides a much simpler use model, and can be extended easily by users. A class library API (like the OVM) has the potential to be even simpler, but often ends up with less flexibility, more complexity and difficulty changing and integrating.

The OVM transaction recording API is hard to integrate with if you are not using the class library in the proscribed way. Additionally, adding other components – like drivers, VHDL modules, C/C++ and SystemC are extremely difficult with the current implementation.

Furthermore, due to SystemVerilog limitations and certain historical implementation limitations, values are only recorded as 1024 bit vectors. This historical restriction can be removed immediately and has no technical basis to exist. The proposed API has no such limitation.

The existing SystemVerilog transaction recording API can be leveraged and extended to C/C++, SystemC and RTL interfaces. This extended API is extended from the SystemVerilog API, with additional implementation for tying in other languages.

SystemVerilog API with DPI

Figure 1 shows the new API stack – with support for DPI-C exports, and a few functionality extensions to support additional debug and analysis. The basic API is the same; the usage and structure is the same, but new capabilities to access and coordinate from other languages and abstractions levels has been enabled.

A good question is “why use SystemVerilog as the vehicle for the recording interface”? Why not use C or C++? C and C++ are efficient, fast ways to build application programming interfaces, but since we want to allow user customization, SystemVerilog is a better choice, since users are already writing SystemVerilog, and SystemVerilog has a rich set of programming features.

Using SystemVerilog allows interoperability with existing PLI implementations, and enables languages supporting C callable functions to be used – for example C, C++ and SystemC.

Another good question is “what’s wrong with the existing SystemVerilog transaction recording API?” The existing API is very close to the proposed new API, with a few changes. In the existing API, the concept of fiber is exposed to the user. Fibers really are an artifact of underlying implementations, and should be abstracted to ‘stream’. The new API allows the user to create streams, and will create sub-streams automatically where necessary.

Limitations

SystemVerilog allows for default arguments. Exporting these interfaces with default arguments to C requires additional support and functions, since C doesn’t have the concept of default arguments.

The inter-language interface is limited by any limitations imposed by the DPI-C standard. Currently the limitations most relevant are the inability to pass classes or class handles across the interfaces. In addition, certain dynamic types are not allowed to be passed – or are allowed under certain use models.

Transaction Lifetime

Transaction recording records the events around a transaction, like beginning, ending and attributes attached to it. Simple API calls can be imagined as ‘begin_tr’, ‘end_tr’ and ‘add_attribute’. Transactions pass through distinct phases in their lifecycle, including create, accept, begin, end, dispose. With a centralized transaction mechanism, these transaction states can be related to each other easily.

Implementation in SystemVerilog imposes certain restrictions on the API, for example recording an attribute of int or double needs to have two functions – one for each type, since SystemVerilog does not allow function overloading:

   add_attribute(tr, <int>)

  add_attribute(tr, <double>)

becomes

    add_attribute_int(tr, <int>)

    add_attribute_double(tr, <int>)

In SystemVerilog a PLI call has the ability to investigate the type of the arguments. The PLI implementation is part of the simulator, and types of arguments are well-known.

     $add_attribute(tr, <int>)

     $add_attribtue(tr, <double>)

In this case, no function overloading is needed, and no special functions must be built. In the new extended recording API, a macro can be used to allow recording of the SystemVerilog types without the need for a special recording function.

For integration with other languages, for example C, DPI-C is used to call from C into the SystemVerilog transaction recording implementation. The SystemVerilog API is “exported”, and available for C/C++ and SystemC to call.

This means that the SystemVerilog API must be functions and tasks with DPI-C types. For our attribute recording, we must create a type specific function, so that proper type recording can be performed. These requirements or restrictions can be automated with a collection of simple macros.

Figure 3 - C and SV Generated Transactions

Extensions to existing API

The new API can record file and line numbers for each call. This extra information can help debug, by telling the user where the transaction began and ended, for example. Each function definition takes FILE and LINE arguments, which can be automatically filled in using the macro version of the function or task.

SystemVerilog macros are provided along with C macros. The C macros provide an easy way to add FILE and LINE number information.

USEFUL NEW WAYS TO DEBUG /ANALYZE

Tags [6] can be used to group transactions across streams or other data models. For example, a collection of transactions executing (Figure 4) or flowing (Figure 6) across the hardware under test are tagged together, and can be identified as a single communication [7][8][9].

Since we now have a common SystemVerilog database containing all the transactions, there are many kinds of queries and analysis we can perform. For example, we can track every transaction as it starts. Each time a transaction starts, a callback or other notification can be given. Those callbacks are customized for each verification environment.

Certain kinds of analysis can be performed live – like “show me all the transactions that ended within the previous 10 clocks”. “Show me all active transactions on stream S”. “Did any active transaction on the list of streams have a retry?”

Common performance measures are also easy to calculate, including throughput - bytes per second or packets per second; latency - time spent waiting before execution; error tracking – packets dropped per packets sent.

Debug is also enhanced with a live database. When a certain transaction executes (or begins), a breakpoint can be set, or other functions can execute. Dumping can be turned on, so that after a certain state is reached, all new packets are dumped live to the output. A packet which has become “stuck” (never executed) can be found easily.

As each packet is created and runs, it can be saved to a replay text file. That replay text file can be read in later as simple way to replay the transaction activity.

Constrained random transaction generation can be performed more easily, since the history of all previous transactions can be recorded or the current state of the system can be sampled. This allows the generation of the next transaction to be a derivation of the previous transaction stream and the current hardware state.

TRANSACTIONS FROM HARDWARE

Transactions are not just external bus events or abstract testbench occurrences. Transactions occur in many places on the hardware. Each piece of information transferred from point A to point B inside the hardware, is a transaction.

SystemVerilog provides an easy solution to monitoring internal nodes – bind. Using bind [10] [11], an “observer” or monitor can be located inside a bound instance. When activity in the bound instance occurs it can trigger a function call or transaction creation. Once the function call occurs, the transaction from with the hardware description gets transferred to the centralized database, and coordinated with the testbench and other transaction generators.

TRANSACTION BEHAVIOR

Transactions can be modeled many ways. Each verification team has different ideas about how to present their information and communication models. Two simple examples are show below. One example shows a bus oriented system (Figure 4), which models streams as collections of transactions on interfaces. The master and RAM streams are shown (Figure 5).

Figure 4 - A Transaction "Executing"

Figure 5 – Transaction execution streams

The second example shows a network of communicating devices (Figure 6), which models streams as collections of transactions that are executing on the given device. Each device has its own stream (Figure 7).

Figure 6 - A Transaction "Flowing"

Figure 7 – Transaction flow streams

CONCLUSION

Transaction recording and analysis are being used everyday in verification projects today, but techniques to allow inter-language transaction recording and analysis can be improved. The proposed changes to existing transaction recording facilities would allow easy adoption by any language supporting the DPI-C calling conventions.

The transaction recording API is a small programming interface, and can be changed and customized easily to suit the needs of each individual team.

Transaction generation, transaction recording and transaction analysis continues to improve. Creating easier ways to annotate and designate transactions is the next step towards simplifying transaction based debug and analysis.

REFERENCES

[1] Draft Standard for Verilog Transaction Recording, www.boyd.com/1364_btf/report/full_pr/attach/435_IEEE_TR_Proposal_04.pdf  

[2] Rich Edelman, IP08, Transactions in an OVM SystemVerilog Verification Environment.

[3] OSCI TLM Standard, www.systemc.org  

[4] Frank Ghenassia (editor), Transaction-level Modeling with SystemC: TLM Concepts and Applications for Embedded Systems, Springer, 2005.

[5] The SystemVerilog OVM, www.ovmworld.org  

[6] Rich Edelman, Mark Glasser, Bill Cox, IPSOC2004, Debugging SOC Designs with Transactions

[7] Sudeep Pasricha, Nikil Dutt, Mohamed Ben-Romdhane, Extending the Transaction Level Modeling Approach for Fast Communication Architecture Exploration. DAC 2004.

[8] Alain Clouard, Kshitz Jain, et. al., Using transactional level models in a SoC design flow, SystemC:methodologies and applications, pp. 29-63, Kluwer 2003, ISBN: 1-4020-7479-4

[9] Lukai Cai and Daniel Gajski, Transaction Level Modeling: An Overview, CODES+ ISSS’03, October 1–3, 2003

[10] David Rich, Jonathan Bromley, Abstract BFMs Outshine Virtual Interfaces for Advanced SystemVerilog Testbenches, DVCON 2008

[11] Virginie Mallez, Mark Peryer, et. al, Are You in a bind with Advanced Verification?, Verification Horizons, February 2009, Vol 5, Issue 1.

Appendix 1 C Macros

Appendix 2 SV Macros

Appendix 3 SV Exported API