Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded
?
?
Embedded

DFD bridges gap between system validation engineer, designer

Posted: 23 Apr 2007 ?? ?Print Version ?Bookmark and Share

Keywords:Design-for-debug system? debug DFD system? silicon debug DFD?

By Kevin Tsai
Novas Software

Debugging the functionality of a design is a continuum: It starts at the architectural phase, continues through its logical and physical implementation, and does not stop after tapeout. Once the silicon prototype is manufactured and mounted in the target board, the system validation engineer must run a battery of system-level tests and size up any detected errors.

The key to understanding the cause of these errors lies in the visibility of internal signal values. While many engineers overlook this post-silicon requirement during the design phase, recent data shows that as the time from the arrival of the silicon prototype to volume production grows, so does the need to improve system-level silicon debug.

An improvement in design verification cannot completely reduce system-level debug time. Verification tools are bound by capacity and performance, so engineers must often balance accuracy and thoroughness against the availability of time and resources as they complete verification for tapeout. Furthermore, the software may not be bug-free until well after silicon arrives. Finally, physical defects can be introduced during manufacturing.

Design-for-debug (DFD) is a methodology that offers insight into internal silicon device behavior during system-level validation. An important aspect of most DFD implementations is the reuse of existing design-for-test logic such as scan chains and boundary scan controllers (IEEE 1149.1). These structures provide access to silicon signal data via a debug port connected to a PC.

The analysis tools process the acquired data for enhanced graphical presentation. The DFD system bridges the gap between the system validation engineer and designer. It provides excellent visibility into silicon signal data, improves silicon debug productivity and minimizes system validation time. Here are a few do's and don'ts for DFD.

Do

  • Consider if debug must be done in real-time or with time-intrusive techniques. Real-time provides a detailed view of signal information at high bandwidth, making it suitable for systems with a lot of embedded software interaction. Time-intrusive methods are easier to implement and provide more data, but at a lower bandwidth.

  • Reuse DFT. Most designs contain scan chains and JTAG controllers that can serve as the foundation for DFD. Entering debug mode and shifting out captured values through the JTAG while the device is operating requires additional control logic for the resets and clocks. The TAP controller must be extended with instructions for in situ debug operation, loaded from a control program on a PC.

  • Use nondestructive scan, if possible, to enable a "stop-observe-go" debug method. Register values are corrupted during scan shifting unless the hardware prevents corruption or the DFD control software transparently reloads the correct values.

  • Plan the entire DFD. Placing DFD logic on-chip is just one step. The board must contain routing between the chip's debug port and a socket connector. Ensure cable compatibility between the board connector and the PC. The control program is developed from software libraries for JTAG-based testing. A control program must format acquired data for further analysis with debug tools.

Don't

  • Determine a debug strategy after silicon arrives, when it's too late to improve internal signal visibility. Incorporate DFD in the device specification before coding begins.

  • Assume that the software development environment will provide sufficient hardware debug capabilities. Internal signal data can sometimes be accessed by the SDE, but it is usually limited to architectural registers such as data and address. Efficient hardware debug requires the visibility of state machine registers and other critical signals.

  • Ignore clock handling and data interaction. Make sure control logic does not inadvertently inject glitches onto the clock lines. Also, monitor data that crosses clock domains to determine if it is valid after a system stop.

  • Neglect to validate the DFD logic prior to tapeout. DFD is a functional feature of the device that must be specified and verified.

  • Forget to consider what to do after acquiring the signal data. Viewing textual values is sufficient for data and address registers, but other register data is best analyzed using waveform, source, schematic and transaction views provided by HDL-oriented debug systems. Ensure that this connection exists by including an ability to dump out signal values into standard formats such as value change dump or fast signal database.

About the author
Kevin Tsai
is technical director at Novas Software. His 17 years of experience in synthesis, optimization and verification includes stints at Avanti and S-MOS Systems. He has a PhD from National Tsing Hua University. Comments may be sent to ktsai@novas.com.




Article Comments - DFD bridges gap between system valid...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
?
?
Back to Top