Novas Design-for-Debug (DFD) Methodology Brief
System Validation Today
No standard methodology exists today for in situ silicon validation. To perform system validation, the validation team must typically:
- Plug the silicon device into the target system and turn on the power;
- Run system-level applications to ensure it operates according to specification;
- Reproduce scenarios using emulation or software simulation when unexpected silicon behavior arises; and
- Trace its origin once the bug has been reproduced.
Unfortunately, limited access to and visibility of internal signal data means that directly observing a design’s behavior for any errors that escaped the pre-silicon verification process is nearly impossible. This limitation also makes determining whether silicon errors are undetected functional design bugs or physical manufacturing defects increasingly difficult. With no internal signal observability, debugging erroneous silicon behavior is an extremely costly, time-consuming and unpredictable task.
To effectively debug silicon, a means of observing internal signal values to garner insight into the status of a device’s internal state machines, data and status registers is required.
DFD Minimizes Errors And Time
Design-for-Debug (DFD) is an emerging methodology that provides validation teams with insight into internal silicon device behavior during in-situ validation. It requires the use of upfront planning and involves the placement of structures on the silicon to help with its debug. Bridging the communication gap between the system validation engineer and designer, it provides excellent observability of silicon signal data, improves silicon debug productivity and minimizes system validation time. Validation teams can now efficiently validate silicon prototypes prior to volume production.
How It Works
The DFD methodology is consistent with what engineers currently perform today as part of an ad-hoc silicon debug flow. Where it differs is in how it enables the engineer to perform an examination of internal signal data. Use of the DFD methodology requires:
- The implementation of on-chip logic used to retrieve crucial signal data.
- Associated software and hardware to facilitate the transport of signal data off-chip.
- The extrapolation of the limited retrievable data using standard process automation and analysis techniques for system-level silicon validation.
To trace errors in silicon using the DFD methodology, first place DFD logic in the design and manufacture the silicon. After obtaining the first silicon prototypes:
- Run system-level applications while the device is in situ to ensure it operates according to specification.
- When an unexpected behavior arises, stop the device at the point of interest.
- Access the system-mode operation signal data, via the DFD logic.
- Next, transport the raw signal data off chip and translate it to correspond with the Hardware Description Language (HDL) design so that it can be exported to existing HDL-centric verification tools.
- Use familiar HDL-centric debug environments and techniques, such as Novas Verdi Debug System, to locate and fix the problem.
While there are a variety of different DFD options, like adding internal debug busses to the silicon, the most straightforward DFD methodology reuses existing Design-for-Test (DFT), such as scan chains, in conjunction with the IEEE 1149.1 test modules (also known as JTAG). Additionally, monitors can be inserted to observe internal behavior and note when illegal, unexpected or pre-programmed conditions occur (see Figure 1).
Figure 1. Example DFD architecture which reuses DFT and adds debug instruction registers, control and optional monitors.
In this scenario, the IEEE 1149.1 controller is extended to operate the DFD logic. Doing so enables it to halt system operation and shift the signal data out of the scan chains. An 1149.1 cable connects the system board to a personal computer (PC) and allows for the transport of debug instructions and data. Once on the PC, the data can be formatted for export to an appropriate debug environment (see Figure 2).
Figure 2. The silicon device (noted in the orange circle) is placed into the target board for system level validation. Under control of debug software application, scan register data travels out of the silicon, across a pod interface, to a PC where it is dumped into a usable form.
Faster, More Efficient Debug
DFD makes system validation of increasingly complex silicon viable. It significantly improves the efficiency of silicon debug, lowers development cost and accelerates time-to-volume production for integrated device manufacturers. Through adoption of a DFD methodology users can:
- Debug both functional bugs and physical defects.
- Use standard design tools and associated environments to extract and process data from the silicon.
- Use standard debug systems and apply pre-silicon techniques, while operating in the designer’s environment, to isolate the root cause of any problem.
Improved Silicon Validation
The Design-for-Debug methodology enables validation teams to efficiently validate silicon prototypes prior to volume production by re-using test structures, such as the IEEE 1149.1 test controller and scan chains, on the silicon to help with its debug. The re-use of existing DFT structures significantly minimizes the impact of this methodology on silicon area. Furthermore, this methodology makes use of DFT resources that would otherwise sit idle during system-level testing.
With DFD, validation teams can now easily extract and process data from the silicon for further exploration and analysis by standard debug systems and associated verification environments. Increased observability significantly improves the ability of validation teams to better understand internal silicon device behavior. In turn, this understanding enables quick resolution of erroneous silicon behavior. Because it directly cuts the time from receipt of silicon prototypes to volume product, the DFD methodology is continuing to gain interest.