With increasing complexity in today’s SoC designs, logic verification is one hurdle that all designers are eager to overcome. A majority of the verification effort is spent on debug. This is because typical SoCs consist of a variety of IPs and interfaces. In cases where data has to flow through multiple interfaces in order to reach its final destination, it becomes extremely hard for design engineers to debug failures. While tracking a data packet through different interfaces is time consuming and cumbersome, engineers will also need to have an in-depth knowledge of each of the interfaces’ protocols. This is undesirable as a design engineer, generally, if specialized in just one protocol and does not have a deep understanding of all protocols implemented in the SoC.
Design engineers, worry not! Arrow Devices’ revolutionary debug tool, the Protocol Debug Analyzer (PDA), is here to make debugging SoC level failures a walk in the park! In this blog, we’ll take a look at how the PDA tool simplifies the debug process.
A quick intro video to the PDA tool can be found here.
Example: SoC Design
Let us, first, take an example to understand typical SoC failures. Consider the system shown in the figure below.
Fig: A System on Chip
In this setup, the microprocessor that is running the system software is connected to a USB3.0 xHCI Controller via an HCI interface that runs on top of an APB bus. The USB3.0 DMA controller is connected to the main memory on an AXI3 bus. It receives commands from the microprocessor over the APB bus. The USB3.0 Host and a peripheral device communicate over a high speed PHY interface.
A SATA controller is connected to the microprocessor on the APB bus and to a flash drive via a SATA PHY interface. The SATA DMA controller is connected to the micro processor over the APB bus and to the main memory through the AXI3 bus.
In a test scenario, 10kB of data is to be transferred from the SATA flash drive to the USB peripheral device. Following is the expected sequence of events:
- The micro processor, through the SATA controller APB interface, issues a read command to the controller which contains information such as the source location, destination address and number of bytes (10*1024) to be read.
- The SATA controller uses this information to fetch data from the flash drive on the SATA PHY interface after which the DMA controller writes the fetched data into the system memory via the AXI interface. Once the data is stored in the system memory, the DMA controller sends a confirmation/response to the micro processor.
- The micro processor initiates a Memory read operation in the USB DMA controller through the APB bus and then programs an SCSI Write operation in the xHCI controller.
- The USB DMA controller uses the information passed on by the microprocessor such as the pointer to the memory and transfer length to fetch data from the system memory via the AXI interface and store it in the data buffers of the USB Host.
- The xHCI Controller issues the SCSI write command. The USB Host, upon receiving the SCSI write command, initiates a series of BULK transfers to transfer the SCSI write command and corresponding data of 10kB to the target USB peripheral device.
Upon running this test, the test setup indicated an error that the data received at the USB device was less than 10kB.
To debug this failure, in the conventional approach, the commands as well as data would have to be traced through the different interfaces with the help of just signal waveforms. Debug engineers would have to be well versed with all protocols (namely AXI3, APB, USB3, SATA and SCSI) involved in order to interpret the traffic correctly.
But with Arrow Devices’ Protocol Debug Analyzer (PDA), system failures can be debugged easily without the hassles of having to learn all of the protocols involved or involving multiple design engineers, specialized in different protocols, in the debug.
Debugging the Scenario with PDA
Let us find out how this failure can be analyzed with the help of the Protocol Debug Analyzer.
First, the USB transfers can be loaded in the PDA view. Here, it is seen that all transfers are complete but the BULK OUT data transfer length is 9kB and not 10kB. This is the reason why the test failed and indicated an error.
Figure: USB3 transfers view
Switching to the SCSI command view, it is observed that the transfer length specified in the command corresponding to the last USB write transfer was 9kB. So, the USB3 host was instructed to transmit just 9kB of data.
Figure: SCSI Commands View
To look at the command issued by the microprocessor to the USB DMA controller, the APB view can be used. Here, it is seen that the controller was programmed to read 9kB (value programmed in register 0x3f) starting from address 0x01ff (value programmed in register 0x10). Hence, the microprocessor programmed the memory controller incorrectly.
Figure: APB View for USB3 DMA, with the number of bytes command highlighted
To check if data was read from the hard disk correctly, the commands issued by the microprocessor to SATA Controller, through the APB interface, can be looked at. It is seen that, here, the microprocessor directed the controller to fetch 10kB(0x2800) from the hard disk and write them to the memory starting from address 0xff.
Figure: APB View for SATA Controller, with the number of bytes command highlighted
Therefore, we can conclude that the microprocessor correctly initiated a 10kB read at the SATA DMA controller but due to software bug issued a 9kB write command to the USB DMA controller.
This way, the PDA displays data pertaining to different interfaces in a uniform, protocol defined format, making it easy to analyze and track traffic through an SoC, and helps minimize the debug effort. It also offers numerous analysis tools that further simplify the debug process and help ensure a smooth debug experience for users.
To know more about the PDA and its features, visit our product page.