| Author: Rich Edelman - Mentor, A Siemens Business Introduction: Transaction recording seems at times to have a life of its own. It has existed since before simulation. Writing down the communication between two people – that’s transaction recording. In verification it isn’t quite as easy as that. Transaction recording has been implemented by vendors and a UVM interface exists, but it is poorly implemented and hard to use. Many VIP providers use transaction recording to create better debug. Any user can use transaction recording to create better debug. The simple API below is very small, and very easy to use. The UVM API is a general API, but is poorly thought out. It is usable, but a better recommendation is to use a stand-alone kind of interface, as described in this paper. One upside of the UVM transaction recording is that it comes for free just by using sequences and sequence items. The free is limited to those areas. (Drivers and monitors are not instrumented automatically). Transaction Recording - The Concepts: The concepts behind transaction recording are simple. A transaction has a beginning and an end. It can have attributes (properties). It can have relationships with other transaction (transaction A is a child of transaction B). A transaction lives on a “stream”. A stream is a construct that enables transactions to be organized (my stream of AXI transactions), but also allows for easy reasoning and display. A stream is simply a horizontal line on the waveform display. On that horizontal line, transactions may be drawn. Transaction Start and End A transaction has a start time and an end time. They represent the time during which this transaction was active. A transaction start and end times can be the same time – a zero delay transaction. Start and End times can be in the future or in the past. In the diagram above, the RED triangles designate the start and end times for the READ transaction. The diagram lays out transactions as they might be seen in the wave window. Time increases from left to right. Each “row” or horizontal display area is a stream. Transaction Attributes A transaction has attributes. Attributes are (NAME, VALUE) property pairs. For example a transaction could have the attributes “ADDR” and “DATA”. Attributes have no special meaning to the transaction recording system or the simulation – they are useful to the verification or design engineer. They may be primary attributes like data and address, or a secondary (derived) attributes like “bytes per second”. Attributes are very useful for debug and analysis. In the diagram above, the transactions have attributes of ‘rw’, ‘addr’ and ‘data’. View & Download: Read the entire Transaction Recording Anywhere Anytime technical paper. | |