Transaction-based Debug of PCI Express Embedded SoC Platforms

Bindesh Patel, Novas Software
Sean Smith, Denali Software
San Jose, USA

Abstract

Embedded system platforms typically contain at least one processing element such as a microprocessor or digital signal processor along with peripherals, random logic, and memory and interface modules. They also employ a bus-based protocol architecture. Bugs that interact both inside blocks and at the bus communication level can be particularly problematic during verification. Multi-bus protocols within the system on chip itself further increase the complexity of this problem. By analyzing bus behavior at the transaction level, design behavior can be much easier to understand and debug.

This requires an extensible architecture that enables transaction-level debugging and an open API approach to verification IP, which includes bus protocol checkers, bus transactors, and traffic generation mechanisms. In particular, the verification IP and debug environment must be able to recognize and record transactions (extraction), perform protocol verification as well as output rules and results, and also calculate bus statistics to ensure functional coverage and utilization. These built-in bus protocol checkers and analysis engines, along with new visualization and animation capabilities, must address the unique requirements of debugging complex serial interconnect standards such as PCI Express.

This paper will look at a typical application of transactions for embedded processor platform modeling and debug across a PCI Express based system. It will examine how transactions are leveraged to improve the performance, verification, and simulation efficiency of embedded designs, and illustrate specific debug issues and methodologies associated with them.

Introduction

Semiconductor advances have enabled designers to take advantage of the increased silicon real estate to put entire systems on a single chip.  Such system-on-chip (SoC) designs are made up of several complex functional units (blocks) built around a standard or custom bus with a well-defined protocol.   Functional verification of large SoC designs presents new and interesting challenges to chip development teams. In particular, simulating at the register transfer level (RTL) now generates tremendous amounts of signal-level data that must be tracked and analyzed, greatly increasing the complexity of the verification and debug process. Design and verification engineers can realize significant productivity gains by viewing and analyzing this data at a higher level of abstraction.

The functional units of SoCs often communicate through numerous buses which are based on standard or custom protocols such as PCI Express, a highly optimized serial protocol. While analyzing the communication across existing parallel bus architectures is complex, serial protocols pose an even greater challenge for verification and debug.  Serial protocols encode the control and data signals into a stream of bits that are then transported across a much narrower interconnect. In the case of modern interface protocols like PCI Express, the data is placed into packets, scrambled for EMI reduction, encoded (8b/10b) for DC balancing, and then finally serialized for transmission across the wires.

In addition, many serial interface protocols utilize split transactions. Again using PCI Express as an example, commands are split into multiple parts and then pipelined to improve the performance and efficiency of the bus. This is achieved by separating the request and the request acknowledgement phase of the transaction, enabling the processing of commands before previous commands are completed. For example, one requester might issue a read command, and while waiting on the response to the read, the requester may issue other reads and writes, thus increasing the efficiency of the system.  It is obvious that analyzing this data, which has been serialized, encoded, and packetized, is impractical at the pin-level with standard debug tools.

The Motivation for Transaction-Level Debug

The grouping together of event sequences into abstract “transactions” provides a new way of describing operations that occur within and between the modules of a SoC, in order to accelerate functional verification and simplify design implementation. This transaction-level approach, in which communication packets are represented as single entities rather than multiple signals over a length of time, is becoming a key component of advanced system design methodologies.

Abstraction of Signal Data

Transactions provide an abstraction of pin-level activity that is easier to comprehend, analyze, and debug. In the case of a top-down design flow, engineers would define the system in terms of transactions between components (or blocks).  At this stage, the blocks might be designed using a system language such as SystemC or SystemVerilog and are generally called Transaction Level Models (TLMs). In the case of the standard chip interfaces, like PCI Express, the TLM functionality of these blocks could be part of a commercial verification IP (VIP) solution. At this system-level stage, the TLMs interact with the verification environment and other TLMs via transaction-level interfaces. Then, as the design blocks are subsequently refined and implemented in RTL, engineers can retain the transaction-level analysis capabilities and avoid the complexity of the pin-level views. This allows for a smooth flow between the different stages as the design progresses to implementation.

Verification Environment Abstraction

For today’s SoCs, developing test cases or simulation stimulus at the signal level would take an exorbitant amount of time.  Like the case for higher-level design, the investment in a transaction-level test environment enables the engineer to quickly and more effectively describe complex stimulus because of the increased level of abstraction. In addition to creating stimulus at the transaction level, engineers would naturally be most effective viewing and analyzing the stimulus at this same level of abstraction. In order to support this transaction-level analysis, the verification team must utilize a model, such as a bus functional model (BFM), which converts between transactions and signal-level stimulus. Modern VIP solutions generally encompass BFMs, TLMs, stimulus generation, and monitors with temporal checking.  Advanced VIP provides interfaces for all these components at both the signal level and the transaction and possibly even higher levels of abstraction.  Moreover, VIP models may also have built-in capabilities to check for compliance of a standard interface protocol.

Analysis and Visualization Techniques for Transaction-Level Debug

Trace data

To enable transaction-level visualization and analysis, verification environments must be able to produce the data during simulation. The capability to dump signal activity is supported by most simulators. However, processing transactions requires much more intelligence. In particular, it requires a detailed understanding of the interface protocols, and more automated methods of exporting and visualizing transactions in a meaningful format.

There are various ways for a tool to be transaction-aware:

• Monitor signal activity (on a bus for example) and extract (or decipher) detailed signal activity into transaction-level activity that can be subsequently dumped.
• A component of the system being simulated can be modeled using a system language such as SystemC. Because the notion of transactions is inherent to the language, users can define and produce data as abstract transaction types.
• System-level IP models, whether design-oriented or verification-oriented, generally have a built-in concept of transactions.

In addition to dumping abstract transactions-level objects, other interesting associated data can be dumped and stored as attributes of the transaction.  An obvious example of such a transaction attribute is the underlying signal data abstracted by the transaction. Attributes can also include other elements such as messages, flag, or register settings.

Transaction analysis and visualization

Once data is dumped and stored as abstract transactions from a simulation, debug tools must provide meaningful ways to present the data to the user to aid comprehension and analysis.

Waveforms

As with most simulation event data, transactions happen over time. The first order requirement is to enhance the ever-familiar waveform tools for display of transactions and provide utilities for performing relevant actions on the displayed transactions.

Figure 1 shows the top of the debug window revealing the PCI Express transactions produced by TX, TX_, RX, and RX_ signals.  The bottom of the window shows the actual serial traffic from signals TX, TX_, RX, RX_. As you can see the long series of TX pin toggles, after deserialization, decoding, unscrambling, and unpacking, may reveal a 32-bit Memory Read operation, with certain packet information, like byte count, sequence number, or traffic class.  Manually deciphering the serial data is both very tedious and very error prone.

 

Figure 1.

The availability of transaction data also facilitates more advanced debugging activities:

• Searching.  Engineers often search for a particular signal value or transition during debug and analysis.  For transactions, they typically want to search for some Boolean combination of attributes to quickly go to an interesting point.
• Expose overlapped transactions.  Unlike signal waveforms, transactions are often overlapped.  Waveform tools have to provide a mechanism to bring “hidden” transactions to the front.

View Detailed “Attributes” of a Transaction

Generally, it is much more convenient to debug and analyze at the higher transaction level. However, when debugging a detailed model (at RTL for example), the detailed signal-level activity may need to be analyzed in order to locate the causes of bugs in the RTL code.  The abstraction of detailed signal activity to the transaction level should, therefore, also keep the associated signal level activity intact and readily accessible, either as attributes of the transaction or tagged to the transaction in some other way. Tagged signals could, for example, be displayed when the user double-clicks on a transaction.  (See Figure 2).

 
Figure 2.

View “Related” Transactions

Transactions by their nature have relationships with other transactions that are generally defined within a model.  A debug tool has to provide intuitive clear indication of these relationships.  In the waveform for example, different colorization of transaction objects can be used to indicate that they are related.  Examples of relationships:

• Master-Slave:  requests may be made from one device to another device where the first device acts as a master and initiates a transaction.  It is often useful to be able to correlate a request with a request completion. In the PCI Express protocol, each request is implemented as split transactions, and some of the request packets require a response packet. The transaction layer also receives response packets from the link layer and matches these with the original requests. Each packet has a unique identifier that enables response packets to be directed to the correct originator.

• Parent-Child: transactions can be built hierarchically in terms of abstraction layers.  Just as a signal-level data can be abstracted into transactions, multiple transactions at a lower level can be abstracted into a higher-level transaction.  And just as it is sometimes necessary to delve into the signal level details of a transaction, it is useful during analysis and debug to look at all the underlying lower-level (child) transactions of a higher-level (parent) transaction.  Numerous examples of Parent-Child relationships can be found in PCI Express designs where a Transaction Layer packet can be inspected at each layer of the PCI Express stack (Transaction Layer(TL), Data Link (DLL) Layer, or Physical Layer  (PL)).  (See Figure 4).

• Predecessor-Successor: A model may dump predecessor-successor relationships between transactions to analyze cause and effect. 

Advanced Analysis Techniques

Beyond the display of transactions as waveforms, it is desirable to visualize and analyze transaction data in a tabular format with filtering, sorting, and other spreadsheet-like capabilities.  For example, one may want to only look at transactions that originated from a particular block. This type of data sort can be easily accomplished in a spreadsheet view as shown in Figure 5.
 

Figure 4.

Advanced techniques for relationships

For relationships, waveforms can use colorization and other techniques to show relationships.  However, for complex protocols, these relationships can build up to a level that requires advanced visualization techniques.   As depicted in Figure 6, such an advanced relationship view can show all the relationships in a tree view that allows the user to expand the different levels of relationships.

 

Figure 5.


Future Ideas and Requirements

There are several areas for additional innovation in the area of debug and analysis of transaction-level data.  One potential capability is to show transactions in a temporal flow view that shows activity over time. Such views and underlying behavior analysis engines already exist for signal-level data and provide far more automation in debugging and understanding cause-and-effect relationships (e.g., such as a wrong value).  The behavior analysis engine can automatically trace the cause of a signal transition over many cycles and display the results in the temporal flow view.

A temporal flow view is also well suited to the task of displaying transaction relationships in a meaningful way. This view aids debug of cause-and-effect over time for a particular transaction.  With this approach, engineers have the option to continue debugging at the transaction level or switch to debugging detailed signal activity at some relevant point.

Conclusion
 
Transaction-level analysis is a practical way to improve the quality and productivity of verification and debug by raising the level of abstraction. Overall verification productivity advantages can be characterized into two categories. First, the use of commercial verification IP reduces the time and risk associated with implementing high-quality TLM’s and generating complex stimulus. Second, transaction-level debug greatly improves productivity for tracing and analyzing cause-and-effect relationships of design errors found in complex SoC’s.   Both of these facets contribute to higher quality results, and faster time-to-market.  The value of this methodology is multiplied when applied to modern serial interconnect standards such as PCI Express, where the inherently complex protocol inhibits meaningful analysis of pin-level activity.

Transaction-based solutions are necessary for designers to meet the challenge of analyzing and verifying complex SoC designs. Leading EDA vendors are addressing this need for transaction-level verification and debug. Commercial tools such as Denali’s PureSpec™ verification IP and Novas’ Verdi™ debug systems now support both pin-level and transaction-level verification and debug for complex interfaces such as PCI Express. These solutions provide an intuitive and efficient means for understanding and analyzing complex design operations, while increasing verification quality and reducing time-to-market.