91³Ô¹ÏÍø

Debugging the complex serial protocols is the biggest challenge verification engineers face. It¡¯s one of the most time and effort consuming activity affecting the schedule of every project. Traditional debug methodologies use a combination of loosely connected waveforms, log files, messages, and documentation, which are insufficient for productive debugging. Debugging SoC and block level issues using log files is tedious and time consuming. Design problems that appear in the later phases of the development cycle can be extremely difficult to track down and debug, thus putting project schedules at risk.

Is there a way to simplify the debug process and performance? Wouldn¡¯t it be easier if one could look at packets and transactions instead of signals?  In this blog, we will discuss some the challenges users face to debug complex protocols; and highlight a GUI-based transaction debug solution that is both easy and fast. . We will take USB as an example, discussing the complex features, debug challenges and corresponding solution.

Let¡¯s look at the complexity of the USB 3.0 protocol and its corresponding debugging challenges. The USB 3.0 protocol specifies that the host controls the communication with devices by exchanging the following types of signaling, and packets:

Link Command Packets

Link commands are used for link level data integrity, flow control and link power management. These packets have fixed length of eight symbols, repeated to increase the error tolerance. It is very difficult to identify the patterns of these symbols using only serial signals in waveforms.

Protocol Command Packets

First the host initiates multiple transfers like Bulk, Interrupt, Isochronous and Interrupt. Each transfer has multiple transactions ¨C SETUP, STATUS, IN and OUT. Based on the type, each transaction has necessary packets mix of TP (Transaction Packet) and DP (Data Packets). Many types of TP are used, like ACK, NRDY, ERDY, STALL, PING, etc. Then the host initiates these packets for multiple device address and endpoint numbers. For debugging, checking the appropriate sequence of these packets is a difficult task in waveforms.

Low Frequency Periodic Signaling (LFPS)

LFPS is used for side band communication between two ports across a link in ¡®low power link state¡¯. It is also used when a link is under training, or when a downstream port issues a ¡®Warm Reset¡¯ to reset the link. LFPS function involves link speed negotiation, exit from low-power states, and link reset. It¡¯s challenging to identify the timing of transmitted signals in waveforms.

There are other challenges also, for example:

• USB also defines software level transfers that are composed of individual transactions.
• USB permits burst of packets, and acknowledgements are pipelined making it more difficult to find the response packet corresponding to any transaction.
• Different endpoints¡¯ traffic initiation and interleaved packets on the bus makes it difficult to find traffic corresponding to an endpoint.

Can waveforms provide a quick solution to these verification challenges? We need to know what¡¯s going on the bus to debug the issues. A waveform will show only serialized packets on the bus, and it is very complex to decode all the serial data manually to get the required packet/transaction/transfer details. Fortunately, Verdi Protocol Analyzer has proven to be an easy and efficient way of debugging, increasing productivity multi-fold.

Verdi Protocol Analyzer displays the layered transaction activity in the order occurred on the bus, as shown in the snapshot below. All the linked transactions and packets are highlighted when corresponding parent transfer is selected.