Tracing TLM 2.0 Activity in an ESL Design – Part 3

Last time I discussed how to use –sctlmrecord to produce an SST2 database of TLM 2.0 transaction data (http://www.systemc.org). In this post, we’ll explore the data in the Simvision Waveform Viewer, the Transaction Explorer, and with TxE. This is the first step towards tying TLM 2.0 trace data to TLM 2.0 debug, a topic I’ll explore in greater detail in future entries.

The example can be found in an IUS 8.2 install at `ncroot`/tools/systemc/examples/tlm2/tutorial. If you want to follow along type:

+txscmain \
simple_dma.cpp \
simple_rxtx.cpp \
sc_main.cpp \
simple_host.cpp \
simple_memory.cpp \
-nocopyright \
-DNCSC_INCLUDE_TASK_CALLS \
-scupdate \
-sctlmrecord \
-tlm2 \
-sctlmdbname tlm.shm \
-debug

And then launch Simvision to view the results:

%simvision tlm.shm/tlm.trn1

Previously, we produced a transaction stream and zeroed in on an area of interest: activity clustered around time 5400 ns for transaction stream isocket_1_0_SCTLMX.. In Simvision, you can drill down to time range 5400ns : 5500ns by typing in the time range box to the left of the magnifying glass. You will see a rectangle representing a transaction that begins at time 5400 ns (the rectangle is left-aligned with 5400 ns). Select that transaction by pressing the shift key and selecting with the left mouse button. If you are using the default color scheme in Simvision, the transaction outline will turn yellow. Next display a quick-view of the attributes by selecting the red resizing icon at the bottom left of the transaction and pulling it down until the entire transaction is visible (Figure 1).

 

Figure 1

 

Some of the attribute values are visible in the Waveform viewer. A powerful feature of Simvision is the ability to expand a stream by attribute value. Here, it would be interesting to separate transactions into rows of READS and WRITES. To do this, hover over the "Command" attribute of the selected transaction in the right window and right-click select the option "Expand Stream By Command" (see Figure 2):

 

Figure 2

 

To see the resulting rows expand the time range 0 ns – 20,000 ns. You will see two new rows below the original row (Figure 3).

 

Figure 3

 

It is easy to see that the dma is performing a block of READS (the topmost of the two new rows) followed by a series of WRITES followed later by another block of READS. You can move the WRITE row above the READ row by grabbing the [Command == "WRITE"] row heading in the name column on the left and dragging it by pressing the middle mouse button up above the [Command == "READ"] row. These expansions can be done by any attribute value (and the resulting rows can be rearranged or deleted as necessary).

Now change the time range back to 5400ns : 5500ns. Sometimes multiple transactions are recorded at the same time. In the default view only one of those transactions will be visible. Note that the original transaction at time 5400ns is still selected. To see if any other transactions are recorded in this time range right-click on the selected transaction and choose "Expand Stream." The resulting view (Figure 4) shows that one transaction begins at time 5400ns and three transactions begin at time 5410 ns. Selecting the transaction at time 5400 ns shows the three transactions aligned at 5400 ns all colored yellow: they are different views of the same transaction – one in the default stream, one broken out by time, the other broken out by command READ

.

Figure 4

 

Next, select the transaction that begins at time 5400 ns in the Waveform viewer. The best way to examine the value of its attributes is to display them in the Transaction Explorer. On the Transaction Explorer toolbar (which you can bring up by clicking the TxE button on the topmost tool bar) immediately to the right of the TxE button is a button that displays the detailed attributes of the transaction. Clicking the button brings up the Transaction Explorer Window (Figure 5):

 

Figure 5

 

This transaction corresponds to the first “hop” in an attempt to read 8 bytes from address 0x6000 with the blocking transport protocol (b_transport). ID 34 indicates this is the 34^th TLM 2.0 read or write operation attempted during this simulation. All of the remaining hops in the transaction sequence will share this ID because the same generic payload object is being passed across each transport boundary. This transaction is the initial transaction that connections simple_dma to memory_1. Since the operation is blocking, the start and end times represent the total time needed to complete the operation. However, there are three more hops remaining:

1. TOP_TB.TOP.dma_0.isocket_1_0 to TOP_TB.TOP.arbiter_0.tsocket_1_0
2. TOP_TB.TOP.arbiter_0.isocket_0 to TOP_TB.TOP.router_0.tsocket_0
3. TOP_TB.TOP.router_0.isocket_2_0 to TOP_TB.TOP.arbiter_1.tsocket_0_0
4. TOP_TB.TOP.arbiter_1.isocket_0 to TOP_TB.TOP.mem_1.tsocket_0

Simvision can build a graph representing this path based on the information recorded by TLM 2.0 tracing. To see the relations, open the View menu and select family_tree (Figure 6).

 

Figure 6

 

The yellow node corresponds to the Initiator transaction.  The arrows show the order of transaction initiation which also corresponds to the connections in Figure 7.

 

Figure 7

 

Selecting any of the other graph nodes will update the attribute values in the Attribute window to the left. If you click the “See” button the Waveform window will be brought into focus with the transaction highlighted. The Waveform Viewer also reflects the information in the family tree (Figure 8).

 

Figure 8

 

The last four rows on the right show the Initiator transaction in yellow followed by the three succeeding transactions in green (the top row is the unexpanded view). The database generated by TLM 2.0 represents a complete history of the life spans of generic payload objects in a TLM 2.0 simulation. Within this data is a wealth of information about the functioning and performance of the design. Future versions of Cadence IUS will include a rich set of TLM data anlysis capabilities. One way to unlock this information in IUS 8.2 is through the use of TxE scripts. Here I present one script you can use as a starting point if you are interested in mining TLM 2.0 data. The script is simple, but you can expand it to include more of the generic payload fields or computed fields such as latency. The script prints basic information about each transaction to a file named “dump.log”. The attributes printed are start_time, end_time, Initiator, Target, and ID. To customize you can choose any attribute generate by TLM 2.0 tracing and add a “col” entry in the table section.

 

 

My three posts on TLM 2.0 tracing in Incisive provide a small peek at the capabilities built into Incisive for working natively with TLM 2.0 data. This is just the beginning though, look for a richer set of TLM 2.0 tool features coming in IUS 9.2.

 

George Frazier