We have all debugged SOC and IP level issues using signal level waveforms. Its a tedious and laborious process. Are there any ways that can make design debug easier? Wouldn’t it be great if I could look at fully decoded transactions instead of signal toggles? In this series of posts, we will try to come up with the best way to look at some typical interfaces in order to reduce debug effort and increase productivity.
DDRn (more precisely Double data rate synchronous dynamic access memory) interfaces provide high bandwidth interfaces to SDRAM memory. Pretty much every system based on an SOC or ASIC has external SDRAM that provides a high capacity dynamic memory. The DDRn interfaces have separate command, address and data buses. These buses are pipelined such that multiple memory reads and writes can be outstanding at any given time. It is the job of the Memory Controller (MAC) to optimize memory accesses is a fashion that maximizes the data bandwidth. The memory controller can choose to issue reads and writes “out-of-order” compared to the order in which the controller received these requests from the rest of the system (based on certain ordering constraints).
Since memory is such an integral part of any system, during debug engineers need to trace system activity to and from the memory. As the DDRn bus is pipelined and supports re-ordering of the memory accesses, debugging memory accesses can become tricky and complicated.
To trace a transaction through a DDRn interface using a waveform viewer, engineers have to manually decode command, address and data phases on the bus and then keep track of which command and address phase corresponds to any given data phase. This is complicated by the fact that some commands do not have a data phase at all!
The above waveform screenshot shows a Write (with burst length = 4) on a DDR2 interface. Were you able to decode this by looking at the waveform in less than a minute?
In contrast, the below screenshot is of our PDA tool that was loaded with the same signal dump file. How long did it take you to figure out the parameters of the highlighted transaction?
As you can see, the PDA tool provides you with a precise summary of information extracted from your signal dump file. You do not have to struggle with remembering the bus encoding patterns (Eg: What is the RAS, CAS pattern and encoding for a READ command?). The tool does all that for you. It even takes care of the pipelined nature of the bus and reports the CMD, Address and Data information in a one-line summary! How easy is that!
This is especially useful for engineers debugging at system level and who might not be well aware of the intricacies of the DDRn protocol. Using the PDA tool, even inexperienced engineers can debug transactions through memory and thus improve their debug productivity.
When used along with a traditional waveform viewer, the PDA tool provides excellent debug visibility and traceability; from signal level to transaction level.
[update] PDA is better than a VIP monitor because:
1. It analyzes signal dumps, so the data presented is more accurate and correlatable with waveforms. No changes are required in the verification environment to get this debug information
2. It can report transaction level activity on internal interfaces which are not driven by a VIP (RTL to RTL interfaces)
3. The GUI allows capability to filter, search and even perform DIFF. All these analysis features are protocol aware
4. The tool provides data in a form that allows engineers to automate analysis and debug tasks using simple Python scripts. This is difficult with text log files dumped by monitors
5. Since this tool analyzes signal activity, it works equally well for Emulation. For example, it can analyze DDR signals from an emulation run to extract DDR transactions
6. The tool provides a “memory view” that allows you to examine the data stored in the DDR memory at any given timestamp
If you want to make design debug easy, contact us using the button below!
Author: Aditya Mittal