REGISTER  |  SIGN IN
United States Patent7222315
Schubert , ; et al.May 22, 2007
Title
Hardware-based HDL code coverage and design analysis
Abstract
Techniques and systems for analysis, diagnosis and debugging fabricated hardware designs at a Hardware Description Language (HDL) level are described. Although the hardware designs (which were designed in HDL) have been fabricated in integrated circuit products with limited input/output pins, the techniques and systems enable the hardware designs within the integrated circuit products to be analyzed, diagnosed, and debugged at the HDL level at speed. The ability to debug hardware designs at the HDL level facilitates correction or adjustment of the HDL description of the hardware designs. Moreover, various embodiments related to HDL code coverage are described.
Inventors:Schubert; Nils Endric (Neu-Ulm, DE), Beardslee; John Mark  (Menlo Park, CA), Koch; Gernot Heinrich  (Waghaeusel, DE), Detjens; Ewald John  (San Francisco, CA)
Assignee:Synplicity, Inc. (Sunnyvale, CA)
Appl. No.:10/377,907
Filed:February 28, 2003
PCT Pub Date:May 22, 2007
Current U.S. Class:716/4 716/1 716/13 
Current International Class:G06F 17/50 (20060101)
Field of Search:716/4,1,13 703/13
U.S. Patent Documents
20020133794September 2002Kanapathhippillai et al.
20020138801September 2002Wang et al.
20020147939October 2002Wenzel et al.
20030106004June 2003Ricchetti et al.
20030115568June 2003Miller et al.
20030121011June 2003Carter
20030126565July 2003Aldebert et al.
20030131325July 2003Schubert et al.
20040025122February 2004Schubert et al.
20040111252June 2004Burgun et al.
20040181385September 2004Milne et al.
4306286December 1981Cocke et al.
4590581May 1986Widdoes, Jr.
4635218January 1987Widdoes, Jr.
4675646June 1987Lauer
4845712July 1989Sanner et al.
4901259February 1990Watkins
4937770June 1990Samuels et al.
4937827June 1990Beck et al.
5036473July 1991Butts et al.
5146460September 1992Ackerman et al.
5281864January 1994Hahn et al.
5321828June 1994Phillips et al.
5329470July 1994Sample et al.
5329471July 1994Swoboda et al.
5369593November 1994Papamarcos et al.
5412260May 1995Tsui et al.
5416919May 1995Ogino et al.
5425036June 1995Liu et al.
5537580July 1996Giomi et al.
5544311August 1996Harenberg et al.
5546562August 1996Patel
5560009September 1996Lenkov et al.
5568437October 1996Jamal
5572712November 1996Jamal
5574388November 1996Barbier et al.
5581742December 1996Lin et al.
5596587January 1997Douglas et al.
5604895February 1997Raimi
5640542June 1997Whitsel et al.
5644515July 1997Sample et al.
5661662August 1997Butts et al.
5663900September 1997Bhandari et al.
5717699February 1998Haag et al.
5748875May 1998Tzori
5751735May 1998Tobin et al.
5754827May 1998Barbier et al.
5757819May 1998Segars
5771240June 1998Tobin et al.
5777489July 1998Barbier et al.
5790832August 1998Barbier et al.
5801956September 1998Kawamura et al.
5805859September 1998Giramma et al.
5812414September 1998Butts et al.
5812562September 1998Baeg
5822564October 1998Chilton et al.
5831868November 1998Beausang et al.
5870308February 1999Dangelo et al.
5870410February 1999Norman et al.
5905883May 1999Kasuya
5907697May 1999Barbier et al.
5933356August 1999Rostoker et al.
5937190August 1999Gregory et al.
5943490August 1999Sample
5951696September 1999Naaseh et al.
5960191September 1999Sample et al.
5963735October 1999Sample et al.
5968188October 1999Rana
5991523November 1999Williams et al.
5999725December 1999Barbier et al.
6006022December 1999Rhim et al.
6009256December 1999Tseng et al.
6014334January 2000Patel et al.
6021447February 2000Szeto et al.
6026230February 2000Lin et al.
6038686March 2000Rana
6041176March 2000Shiell
6057706May 2000Barbier et al.
6107821August 2000Kelem et al.
6132109October 2000Gregory et al.
6157210December 2000Zaveri et al.
6175946January 2001Ly et al.
6182247January 2001Herrmann et al.
6182268January 2001McElvain
6188975February 2001Gay
6191683February 2001Nygaard
6199031March 2001Challier et al.
6202044March 2001Tzori
6202172March 2001Ponte
6212490April 2001Li et al.
6212650April 2001Guccione
6223148April 2001Stewart
6240376May 2001Raynaud et al.
6247147June 2001Beenstra et al.
6255836July 2001Schwarz et al.
6255845July 2001Wong et al.
6286114September 2001Veenstra et al.
6292765September 2001Ho et al.
6301688October 2001Roy
6311292October 2001Choquette et al.
6311317October 2001Khoche et al.
6314529November 2001Rana
6334207December 2001Joly et al.
6336087January 2002Burgun et al.
6363520March 2002Boubezari et al.
6374370April 2002Bockhaus et al.
6377911April 2002Sample et al.
6377912April 2002Sample et al.
6378093April 2002Whetsel
6389558May 2002Herrmann et al.
6389586May 2002McElvain
6421813July 2002Jeddeloh
6425101July 2002Garreau
6427224July 2002Devins et al.
6430727August 2002Warren
6434735August 2002Watkins
6438725August 2002Chen
6438735August 2002McElvain et al.
6449762September 2002McElvain
6456961September 2002Patil et al.
6460148October 2002Veenstra et al.
6460174October 2002Carey
6463392October 2002Nygaard
6467075October 2002Sato et al.
6470478October 2002Bargh et al.
6484134November 2002Hoskote
6493852December 2002Narain et al.
6499123December 2002McFarland et al.
6510534January 2003Nadeau-Dostie et al.
6513143January 2003Bloom et al.
6564347May 2003Mates
6567932May 2003Edwards et al.
6571375May 2003Narain et al.
6581191June 2003Schubert et al.
6587995July 2003Duboc et al.
6591402July 2003Chandra et al.
6594802July 2003Ricchetti et al.
6594804July 2003Hojati
6609229August 2003Ly et al.
6618839September 2003Beardslee et al.
6618854September 2003Mann
6633838October 2003Arimilli et al.
6690398February 2004Beck et al.
6697957February 2004Wang et al.
6704889March 2004Veenstra et al.
6751751June 2004Murray et al.
6754760June 2004Yee et al.
6754862June 2004Hoyer et al.
6779145August 2004Edwards et al.
6785854August 2004Jaramillo et al.
6789217September 2004Slaugh et al.
6791352September 2004Verdoorn et al.
6795963September 2004Andersen et al.
6799128September 2004Duff et al.
6822474November 2004Chaudhari
6823224November 2004Wood et al.
6826717November 2004Draper et al.
6839654January 2005Rollig et al.
6839874January 2005Fang
6859892February 2005Bolding et al.
6868376March 2005Swoboda
6894530May 2005Davidson et al.
6895365May 2005Voorhees et al.
6895372May 2005Knebel et al.
6904577June 2005Schubert et al.
Foreign Patent Documents
00/43884Jul., 2000WO
01/63434Aug., 2001WO
01/71876Sep., 2001WO
02/23344Mar., 2002WO
02/29568Apr., 2002WO
03/025595Mar., 2003WO
03/088040Oct., 2003WO
05/020280Mar., 2005WO
Other References
Dervisoglu, B., "Design for Testability: It is time to deliver it for Time-to-Market," Proceedings of the International Test Conference, 1999. cited by other .
Satish, K., "Tutorial on Design For Testability (DFT): An ASIC Design Philosophy for testability from Chips to Systems," Sixth Annual IEEE International ASIC Conference and Exhibit, 1993. cited by other .
Liband, J., "Techniques for Real-Time Debugging," Embedded Systems Programming, vol. 8, No. 4, Apr. 1995. cited by other .
Agarwal, Dr. V., "Embedded IC Test: A New Palateau for DFT," Evaluation Enginneerig, vol. 38, No. 9, Sep. 1999. cited by other .
O'Reilly, S., "Debugging Drivers with Emulators and Logic Analyzers," Embedded Systems Programming, vol. 11, No. 2, Feb. 1998. cited by other .
Ganssle, J., Debuggers for Modern Embedded Systems, Embedded Systems Programming, Nov. 1998. cited by other .
Miller, B., "Scan Conversion of ASICs," Circuit Design, vol. 7, No. 2, Feb. 1990. cited by other .
Bauer, J., et al., "A Reconfigurable Logic Machine for Fast Event-Driven Simulation," Design Automation Conference Proceedings (DAC), Jun. 1998, pp. 668-671. cited by other .
Synopsys, Inc., "BSD Compiler" datasheet, www.synopsys.com/products/test/bsd.sub.--ds.html. cited by other .
Synopsys, Inc., "DFT Compiler" Next Generation 1-Pass Test Synthesis Technology Backgrounder, Apr. 2000. cited by other .
Cousineau, C., et al., "Design of a JTAG Based Run Time Reconfigurable System," 7th IEEE Symposium on Field Programmable Custom Computing Machines, 1999. cited by other .
Andrews, J., "An Embedded JTAG, System Test Architecture," Proceedings of ELECTRO, 1994. cited by other .
Xubang, S, et al., "Design and Implementation of a JTAG Boundary-Scan Interface Controller," Proceedings of the 2nd IEEE Asian Test Symposium, 1993. cited by other .
"JTAG for system emulation," Electronic Engineering, vol. 65, No. 794, Feb. 1993. cited by other .
Van Riessen, R.P., et al., "Design and Implementation of a Hierarchical Testable Architecture using the Boundary Scan Standard," 1st European Test Conference, IEEE, 1989. cited by other .
Huang, I., et al., "ICEBERG: An Embedded In-circuit Emulator Synthesizer for Microcontrollers," proceedings of the 36th Design Automation Conference (DAC), 1999. cited by other .
Bannatyne, R., "Debugging Aids for Systems-on-a-Chip," Proceedings of North Con., 1998. cited by other .
Hasslen, R., et al., "A Validation Strategy for Embedded Core ASICS," Proceedings of the Third Annual IEEE ASIC Seminar and Exhibit, Sep. 1990. cited by other .
Baron, M., et al., "A Real-Time Performance Analyzer," VLSI Systems Design, May 4, 1987. cited by other .
Ghosh, I., "A BIST Scheme for RTL Circutis Based on Symbolic Testability Analysis," IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 19, No. 1, Jan. 2000. cited by other .
Ghosh, I., "A Design-for-Testability Technique for Register-Transfer Level Circuits Using Control/Data Flow Extraction," IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 17, No. 8, Aug. 1998. cited by other .
Tuck, B., "Test-bench tools ease tedious, time-consuming manual efforts," Computer Design, May 1996. cited by other .
Badzmirowski, K., et al., "Diagnosis of Digital/Analogue Measurement System with Application of Test Bus and Distributed Diagnostic subsystem," Proceedings of the IEEE Instrumentation and Measurement Technology Conference, 1998. cited by other .
Pateras, S., et al., "BIST: A Test & Diagnosis Methodology for Complex, High Reliability Electronics Systems," 1997 IEEE Autotestcon Proceedings. cited by other .
Sweeney, J., "A Method For Using JTAG Boundary scan for Diagnosing Module Level Functional Failures," proceedings of WesCon Conference, 1998. cited by other .
Fang, W., et al., "A Multi-Level FPGA Synthesis Method Supporting HDL Debugging for Emulation-Based Designs," Proceedings for the Asian and South Pacific Design Automation Conference, 1999. cited by other .
Gonzales, D., "Tool Reusable for DSP System emulation and Board Production Testing," IEEE Technical Applications Conference, Northcon, 1996. cited by other .
Weiss, R., "ICEs try to target higher clock rates, more processors," Computer Design, vol. 35, No. 2, Feb. 1996. cited by other .
Winters, M., "Using IEEE-1149.1 For In-Circuit Emulation," Proceedings of WesCon, 1994. cited by other .
Perez, C., "Tools for Embedded-Systems Debugging," Dr. Dobbs Journal, Mar. 1993. cited by other .
Aherns, K., "Test Standard Speeds On-Board Programming," Electronic Design, Nov. 7, 1994. cited by other .
Bringmann, O., et al., "Target Archtiecture Oriented High-Level Synthesis for Multi-FPGA Based Emulation," Proceedings fo the Design Automation and Test Conference, DATE, 2000. cited by other .
Wei.beta., K., et al., "Exploiting FPGA-Features during the Emulation of a Fast Reactive Embedded System," Proceedings of the 1999 ACM/SIGDA International Symposium on Field Programmable Gate Arrays, ACM, 1999. cited by other .
Koch, G., et al. "Breakpionts and Breakpoint Detection in Source Level Emulation," 9th International Symposium on System Synthesis, 1996. cited by other .
Koch, G., et al. "Co-Emulation and Debugging of HW/SW-Systems," 10th International Symposium on System Synthesis (ISSS), 1997. cited by other .
Koch, G., et al. "System protyping in the COBRA Project," International Journal Microprocessors and Microsystems, Elsevier Science, vol. 20., No. 30, 1996. cited by other .
Haug, G., et al., "Behavioral Emulation of Synthesized RT-level Descriptions Using VLIW Architectures," 9th International Workshop on Rapid System Prototyping, 1998. cited by other .
Koch, G., et al, "System Validation by Source Level Emulation of Behavioral VHDL Specifications," 6th Internationals Workshop of Rapid System Prototypin, 1995. cited by other .
Koch, G., "Interaktives Debugging algorithmmischer Hardware-Verhaltensbeschreibungen mit Emulation," Dissertation, 1998. cited by other .
Clarke, P, "DATE99: Temento to launch scan insertion too," EETimes.com, Mar. 4, 1999. cited by other .
Miczo, A., "Digital Logic Testing and Simulation," Harper & Row, Publishers, 1996. cited by other .
Xilinx, "ChipScope Software and ILA Cores User Manual," v1.1, Jun. 30, 2000. cited by other .
Koch, G., et al., "Breakpionts and Breakpoint Detection in source Level Emulation," ACM Transaction on Design Automation of Electronic Systems, vol. 3, No. 2, 1998. cited by other .
Mourad, S., et al., "123 Logic Analyzers", The Engineering Handbook, pp. 1325-1330, CRC Press, Inc., 1996. cited by other .
Haufe, M., et al., "Ein Debugger fuer ASIC-Prototypen", pp. 10, DASS Dresden Germany, 2000. cited by other .
Kirkovski, D., et al., "Improving the Observability and Controllability of Datapaths for Emulation-Based Debugging", IEEE Trans. on CAD, vol. 18, Nov. 1999, pp. 1529-1541. cited by other .
Joyce, D., "Code Coverage Analysis Works in Hardware Design", ISD Magazine, Jan. 1997, pp. 7 http://www.eedesign.com/editorial/1997/edafeature9701.html. cited by other .
Stuart, M., et al., "Verification Methodology Manual", Teamwork International, 2000, pp. 18, ISBN 0-9538482-0-5. cited by other .
Vermeulen, B., et al., "Silicon debug of a co-processor array for video applications", pp. 6, High-Level Design Validation and Test Workshop 2000, IEEE Proceedings. cited by other .
Van Rootselarr, G., et al., "Silicon debug: scan chains alone are not enough", pp. 11, ITC 1999. cited by other .
Van Rootselaar, G., et. al., "Silicon Debug Methodology", pp. 32, Embedded Tutorial, ICCAD, 1999. cited by other .
Ableidinger et al., "Multi-Core Embedded Debug for Structured ASIC Systems", DesignCon 2004, Feb. 2004, 23 pgs. cited by other .
Actel Corporation, "Actel Silicon Explorer II--User's Guide", Mar. 2004; cover page, p. ii and pp. 3-43. cited by other .
Altera Corporation, "Quartus II Handbook, vol. 3", Section IV-1, May 2005; pp. 9/1-9/14; pp. 10/1-10/46; pp. 11/1-11/46; pp. 12/1-12/10. cited by other .
Altera Corporation, "SignalTap II Features", http://www.altera.com/products/software/products/quartus2/verification/si- gnaltap2/sig-feature.sub.--descriptions.html, Jun. 2005, pp. 1-4. cited by other .
ASSET Intertech, Inc., "ScanWorks Diagnostic & Repair Station Bundle", Document 20019-H, Jun. 2005, pp. 1-6. cited by other .
Automotive DesignLine, "Lattice Semi in-system configuration engine goes into JTAG system", http://www.automotivedesignline.com, Feb. 14, 2005, pp. 1-3. cited by other .
Bennetts, R.G., "Boundary Scan Tutorial", ASSET Intertech Inc., Sep. 2002, pp. 1-58. cited by other .
First Silicon Solutions, Technical Data for Clam System for Actel FPGA Devices, http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Trace Instrumentation and Architectures for OCP Buses", Date Conference 2005, Mar. 2005, 16 pgs. cited by other .
First Silicon Solutions, Inc., "Getting Started--FS2 System Analyzer for QuickLogic Eclipse Devices", http://www.fs2.com, Jan. 2004, pp. 1-29. cited by other .
First Silicon Solutions, Inc., "Getting Started--System Analyzer for AMD Geode GX and Geode LX Processors", http://www.fs2.com, May 2005, pp. 1-45. cited by other .
First Silicon Solutions, Inc., "Technical Data for ISA-ACTEL51 In-Target System Analyzer for Actel Core8051 Microcontroller Cores", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for ISA-ARM System Analyzer for ARM Processors and Cores", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for ISA-CAST51 In-Target System Analyzer for CAST 8051 Synthesizable Microcontroller Cores", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for FS2 System Analyzer for QuickLogic Eclipse FPGA Devices", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for System Navigator OE for AMD Geode GX Processors", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for System Navigator OE for MIPS32 and MIPS64 Cores", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for In-Target System Analyzer for Altera Nios Embedded Processor Systems", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for FS2 System Analyzer for QuickLogic QuickMIPS ESP Devices", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for In-Target System Analyzer for LSI Logic ZSP500 DSP Core", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Getting Started--ISA-Jazz Debugger", http://www.fs2.com, Apr. 2004, pp. 1-22. cited by other .
First Silicon Solutions, Inc., "Technical Data for FS2 On-Chip Logic Navigator System for Actel FPGA Devices", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for Logic Navigator System for Atmel FPGA Devices", http://www.fs2.com, Jun. 2005, 3 pgs. cited by other .
First Silicon Solutions, Inc., "Preliminary Technical Data for FS2 MED System for SoC Multi-Core Embedded Debug", http://www.fs2.com, Feb. 2004, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for ISA-M8051EW In-Target System Analyzer for Mentor Grphics M8051EW Synthesizable Microcontroller Core", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Getting Started--System Navigator for MIPS Cores", http://www.fs2.com, Mar. 2005, pp. 1-49. cited by other .
First Silicon Solutions, Inc., "Preliminary Technical Data for AMBA Navigator AMBA On-Chip Bus Analyzer for AHB Bus Systems", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Preliminary Technical Data for OCP Navigator On-Chip Bus Socket Analyzer for OCP Bus Systems", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Preliminary Technical Data for SiliconBackplane Navigator On-Chip Bus Analyzer for Sonics SiliconBackplane uNetwork", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "NIOS II Hardware Reference--System Analyzer for the Nios II Processor Core", http://www.fs2.com, Nov. 2004, pp. 1-33. cited by other .
First Silicon Solutions, Inc., "NIOS II Software User Guide--System Analyzer for the Nios II Processor Core", http://www.fs2.com, Nov. 2004, pp. 1-34. cited by other .
First Silicon Solutions, Inc., "Getting Started--FS2 System Analyzer for QuickLogic QuickMIPS Devices", http://www.fs2.com, Feb. 2004, pp. 1-44. cited by other .
First Silicon Solutions, Inc., "Technical Data for System Navigator for AMD Geode GX Processor", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for System Navigator for MIPS32 and MIPS64 Cores", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Technical Data for System Navigator for Tensilica Xtensa Processors", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
First Silicon Solutions, Inc., "Getting Started--VAutomation System Analyzer, VSA-186", Version 1.8.0.2, http://www.fs2.com, Oct. 2002, pp. 1-19. cited by other .
First Silicon Solutions, Inc., "Technical Data for VSA-8X/18X System Analyzer for ARC International (formerly VAutomation) V186 and Turbo186 Synthesizable Cores", http://www.fs2.com, Jun. 2005, 2 pgs. cited by other .
Goel et al., "On-Chip Test Infrastructure Design for Optiomal Multi-Site Testing of System Chips", DATE Conference 2005, Mar. 2005, 6 pgs. cited by other .
Lauterbach, "BDM/JTAG Debuggers", http://www.lauterbach.com, Jan. 2005, pp. 1-51. cited by other .
Lauterbach, "ICD In-Circuit Debugger", http://www.lauterbach.com, Jan. 2005, pp. 1-23. cited by other .
Lauterbach, "Lauterbach--Basic Concept", http://www.lauterbach.com, Jan. 2005, pp. 1-15. cited by other .
Mayer et al., "Debug Support, Calibration and Emulation for Multiple Processor and Powertrain Control SoCs", Date Conference 2005, Mar. 2005, 5 pgs. cited by other .
S2C Inc., "IP Porter Introduction", http://www.s2cinc.com/aaipi3.asp, Jun. 2005, 9 pgs. cited by other .
Stollon et al., "Multi-Core Embedded Debug for Structured ASIC Systems", DesignCon 2004, Feb. 2004, pp. 1-23. cited by other .
Xilinx, Inc., "ChipScope Pro Software and Cores User Guide", UG029, Version v7.1, Feb. 2005, 122 pgs. cited by other .
Yang et al., "Extraction Error Modeling and Automated Model Debugging in High-Performance Low Power Custom Designs", Date Conference 2005, Mar. 2005, 6 pgs. cited by other.~
Primary Examiner: Chiang; Jack
Assistant Examiner: Bowers; Brandow W.
Attorney, Agent or Firm:Blakely, Sokoloff, Taylor & Zafman LLP
Parent Case Text


CLAIM OF PRIORITY

The present application is a continuation in part (CIP) of, claims priority to, and claims the benefit of: U.S. patent application Ser. No. 09/724,702 filed on Nov. 28, 2000 now U.S. Pat. No. 6,581,191.

The present application also claims priority to and claims the benefit of U.S. Provisional Patent Application 60/360,627 filed on Mar. 1, 2002.
Claims

What is claimed is:
1. A method for hardware-based HDL code coverage and design analysis, comprising: performing HDL code coverage analysis, at speed and within a target environment comprising a fabricated electronic system, for an HDL description of said fabricated electronic system, said HDL description having been previously instrumented for said HDL code coverage analysis in accordance with one or more directives that were specified by a user; and presenting debug information with respect to the HDL description of said fabricated electronic system.

2. The method of claim 1 wherein said one or more directives further comprise at least one selected break point.

3. The method of claim 2 wherein said HDL code coverage analysis further comprises control coverage analysis.

4. The method of claim 1 wherein said one or more directives further comprise at least one selected watch point.

5. The method of claim 4 wherein said HDL code coverage analysis further comprises data coverage analysis.

6. The method of claim 5 wherein said HDL code coverage analysis further comprises toggle coverage.

7. The method of claim 1 wherein said HDL description comprises a high level HDL description.

8. The method of claim 1 wherein said HDL description comprises a gate level HDL description.

9. The method of claim 1 wherein said HDL description contains a hierarchical structure of HDL building blocks.

10. The method of claim 1 wherein said HDL description comprises a description written in VHDL.

11. The method of claim 1 wherein said HDL description comprises a description written in Verilog.

12. The method of claim 1 wherein said HDL description comprises a description written in Superlog.

13. The method of claim 1 wherein said HDL description comprises a description written in C.

14. The method of claim 1 wherein said HDL description comprises a description written in C++.

15. The method of claim 1 wherein said HDL description comprises a description written in SystemC.

16. The method of claim 1 further comprising performing an analysis of the design for said fabricated electronic system based upon said HDL code coverage analysis.

17. The method of claim 16 wherein said design analysis further comprises analyzing the performance of said fabricated electronic system.

18. The method of claim 16 wherein said design analysis further comprises checking properties in the HDL description.

19. The method of claim 16 wherein said design analysis further comprises checking assertions in the HDL description.

20. The method of claim 19 wherein at least one of said assertions is described in VHDL.

21. The method of claim 19 wherein at least one of said assertions is described in an assertion language.

22. The method of claim 21 wherein said assertion language is SUGAR.

23. The method of claim 16 wherein said design analysis further comprises analyzing overflows/underflows of at least one signal and/or variable in said HDL description.

24. The method of claim 16 wherein said design analysis further comprises analyzing collisions on at least one bus within said HDL description.

25. The method of claim 16 wherein said design analysis further comprises analyzing contentions for at least one bus within in said HDL description.

26. The method of claim 1 wherein said fabricated electronic system further comprises at least one programmable integrated circuit device.

27. A method for hardware-based HDL code coverage and design analysis, comprising: a) instrumenting an HDL description of an electronic system in accordance with one or more directives that are specified by a user; b) determining design instrumentation circuitry (DIC) based on said directives; c) fabricating said electronic system incorporated with said DIC; d) performing HDL code coverage analysis of said HDL description at speed in said fabricated electronic system; and e) presenting debug information with respect to the HDL description of said fabricated electronic system.

28. The method of claim 27 further comprising initiating an HDL-based hardware debugger on a host computer after said fabricating but prior to said performing.

29. The method of claim 27 wherein said one or more directives further comprise at least one selected break point.

30. The method of claim 29 wherein said HDL code coverage analysis further comprises control coverage analysis.

31. The method of claim 27 wherein said one or more directives further comprise at least one selected watch point.

32. The method of claim 31 wherein said HDL code coverage analysis further comprises data coverage analysis.

33. The method of claim 32 wherein said HDL code coverage analysis further comprises toggle coverage.

34. The method of claim 27 wherein said HDL description comprises a high level HDL description.

35. The method of claim 27 wherein said HDL description comprises a gate level HDL description.

36. The method of claim 27 wherein said HDL description contains a hierarchical structure of HDL building blocks.

37. The method of claim 27 wherein said HDL description comprises a description written in VHDL.

38. The method of claim 27 wherein said HDL description comprises a description written in Verilog.

39. The method of claim 27 wherein said HDL description comprises a description written in Superlog.

40. The method of claim 27 wherein said HDL description comprises a description written in C.

41. The method of claim 27 wherein said HDL description comprises a description written in C++.

42. The method of claim 27 wherein said HDL description comprises a description written in SystemC.

43. The method of claim 27 further comprising performing an analysis of the design for said fabricated electronic system based upon said HDL code coverage analysis.

44. The method of claim 43 wherein said design analysis further comprises analyzing the performance of said fabricated electronic system.

45. The method of claim 43 wherein said design analysis further comprises checking properties in the HDL description.

46. The method of claim 43 wherein said design analysis further comprises checking assertions in the HDL description.

47. The method of claim 46 wherein at least one of said assertions is described in VHDL.

48. The method of claim 46 wherein at least one of said assertions is described in an assertion language.

49. The method of claim 48 wherein said assertion language is SUGAR.

50. The method of claim 43 wherein said design analysis further comprises analyzing overflows/underflows of at least one signal and/or variable in said HDL description.

51. The method of claim 43 wherein said design analysis further comprises analyzing collisions on at least one bus within said HDL description.

52. The method of claim 43 wherein said design analysis further comprises analyzing contentions for at least one bus within in said HDL description.

53. The method of claim 27 wherein said fabricated electronic system further comprises a programmable integrated circuit.

54. A computer readable medium having instructions which, when executed by a computer, cause said computer to perform a method for hardware-based HDL code coverage and design analysis, said method comprising: performing HDL code coverage analysis, at speed and within a target environment comprising a fabricated electronic system, for an HDL description of said fabricated electronic system, said HDL description having been previously instrumented for said HDL code coverage analysis in accordance with one or more directives that were specified by a user; and presenting debug information with respect to the HDL description of said fabricated electronic system.

55. The computer readable medium of claim 54 wherein said one or more directives further comprise at least one selected break point.

56. The computer readable medium of claim 55 wherein said HDL code coverage analysis further comprises control coverage analysis.

57. The computer readable medium of claim 54 wherein said one or more directives further comprise at least one selected watch point.

58. The computer readable medium of claim 57 wherein said HDL code coverage analysis further comprises data coverage analysis.

59. The computer readable medium of claim 58 wherein said HDL code coverage analysis further comprises toggle coverage.

60. The computer readable medium of claim 54 wherein said HDL description comprises a high level HDL description.

61. The computer readable medium of claim 54 wherein said HDL description comprises a gate level HDL description.

62. The computer readable medium of claim 54 wherein said HDL description contains a hierarchical structure of HDL building blocks.

63. The computer readable medium of claim 54 wherein said HDL description comprises a description written in VHDL.

64. The computer readable medium of claim 54 wherein said HDL description comprises a description written in Verilog.

65. The computer readable medium of claim 54 wherein said HDL description comprises a description written in Superlog.

66. The computer readable medium of claim 54 wherein said HDL description comprises a description written in C.

67. The computer readable medium of claim 54 wherein said HDL description comprises a description written in C++.

68. The computer readable medium of claim 54 wherein said HDL description comprises a description written in SystemC.

69. The computer readable medium of claim 54 wherein said method further comprises performing an analysis of the design for said fabricated electronic system based upon said HDL code coverage analysis.

70. The computer readable medium of claim 69 wherein said design analysis further comprises analyzing the performance of said fabricated electronic system.

71. The computer readable medium of claim 69 wherein said design analysis further comprises checking properties in the HDL description.

72. The method of claim 69 wherein said design analysis further comprises checking assertions in the HDL description.

73. The method of claim 72 wherein at least one of said assertions is described in VHDL.

74. The method of claim 72 wherein at least one of said assertions is described in an assertion language.

75. The method of claim 74 wherein said assertion language is SUGAR.

76. The method of claim 69 wherein said design analysis further comprises analyzing overflows/underflows of at least one signal and/or variable in said HDL description.

77. The method of claim 69 wherein said design analysis further comprises analyzing collisions on at least one bus within said HDL description.

78. The method of claim 69 wherein said design analysis further comprises analyzing contentions for at least one bus within in said HDL description.

79. The method of claim 54 wherein said fabricated electronic system further comprises at least one programmable integrated circuit device.

80. A hardware-based HDL code coverage analysis system to analyze the code coverage of tests applied to a fabricated electronic system, comprising: a) an instrumentor configured to receive a high level HDL description of the electronic circuit design, to determine aspects of the electronic circuit design to be examined or modified during debugging, to determine additional circuitry to be incorporated into the electronic circuit design to facilitate debugging, and to produce a modified high level HDL description of the electronic circuit design by incorporating an HDL description of the additional circuitry into the high level HDL description of the electronic circuit design; b) a design instrumentation database configured to store information about the additional circuitry including relationships between signals of the electronic circuit design and portions of the modified high level HDL description or the high level HDL description; and, c) a HDL-based hardware debugger configured to debug the fabricated integrated circuit fabricated in accordance with the modified high level HDL description by interacting with the electronic circuit design using the additional circuitry and by operating to present debug information with respect to the modified high level HDL description or the high level HDL description.
Description
BACKGROUND OF THE INVENTION

1. Field of the Invention

The field of invention relates to electronic systems and, more particularly, to debugging of electronic systems.

2. Description of the Related Art

Electronic systems are designed by designers to operate in specific ways. Electronic systems are systems that contain digital and/or analog electronic components connected together to perform specific operations or functions. Besides the electronic components, electronic systems may also include software. Once designed, the electronic systems may need to be debugged. Debugging electronic systems is a process which involves detection, diagnosis, and correction of functional failures. In the detection step, the designer of the electronic system observes a functional failure. When the designer is able to gather enough information about the incorrect behavior of the electronic system, the designer of the electronic system can draw the necessary conclusions to diagnose the functional failure. For correction of the functional failure, a fix is applied and subsequently tested. When the design is provided in a Hardware Description Language (HDL), such a fix may be a textual change to the HDL description of the electronic system.

In general, debugging has conventionally been performed by various different approaches. In particular, debugging has been performed by computer software debugging, hardware description language functional verification, hardware logic level analysis, or hardware behavioral source level emulation. These different approaches are discussed below.

Computer software debugging is conventionally performed using a computer software debugger. A computer software debugger is a software tool that allows a software developer to control the execution of a running computer software program by setting break-points, sequentially single-stepping through the execution of the computer software program, and looking at the program's state by examining and displaying variables and expressions. One example of such a software debugging tool is the GNU Debugger (GDB), which can be obtained from Red Hat, Inc. in Sunnyvale, Calif.

Software debuggers usually offer interactive debugging of software programs which are sequentially executed on computers. However, some software debuggers also support limited concurrency such as threaded program execution. Some software debuggers support debugging programs written at different levels of abstraction from high-level computer languages such as C++ down to assembler code and/or machine code. To assist with debugging of programs written in high-level computer languages, the software debugging system can add extra debug information (e.g., symbolic names and references to source code) to the compiled code during compilation of the computer software program. In combination with in-circuit emulators, software debuggers may provide a limited capability to analyze the underlying Central Processing Unit (CPU) of the computer executing the computer software program. A major disadvantage of software debuggers is, however, that they cannot be used for efficiently debugging general hardware of electronic systems.

Hardware description language functional verification is used to verify that the parts of an electronic system which are described using HDL match their functional specification. Such functional verification can be achieved through functional simulation or formal verification.

Functional simulation is performed by a functional simulator. A functional simulator is a software program that runs on a host computer and simulates the operation of an electronic system using its HDL description. Examples of functional simulators include VCS and VSS from Synopsys, Inc. in Mountain View, Calif., and ModelSim from Mentor Graphics Corp. in Wilsonville, Oreg. To increase simulation performance some functional simulators additionally make use of special purpose hardware which acts as a co-processor and accelerates the simulation. An example of a hardware-accelerated functional simulator is the Hammer system from Tharas Systems, Inc. in Santa Clara, Calif. Unfortunately, one major disadvantage of functional simulation is the need for simulation models. In order to be able to simulate, there must exist a simulation model with the proper functional behavior for each component of the HDL design for the electronic system. For some components such simulation models may not be readily available and must be generated. Additionally, the HDL design must be stimulated by a testbench. Since the ideal testbench must correctly and exhaustively match the behavior of the target environment, creation of a testbench can be very difficult and time consuming. On the other hand, a testbench that is too simple will not provide the necessary coverage to find all the design errors. Although functional simulation is useful, using functional simulation to debug design errors is too burdensome. Not only are the testbenches difficult to create, but also the more complex the HDL design is, the lower the performance of functional simulation. For state-of-the-art HDL designs simulation is now a million times slower than the fabricated hardware. Hardware-acceleration can typically speedup functional simulation by a factor on the order of one-hundred. Accordingly, its low performance makes it impractical to use functional simulation either to debug real-time applications or to concurrently debug hardware and software of complex electronic systems.

Formal verification is performed by a formal verification tool. Formal verification can help with the problem of incomplete coverage in functional simulation due to testbench limitations. One approach checks the HDL description for properties. Such properties may be explicitly provided by the designer of the electronic system or implicitly extracted from the HDL description by the formal verification tool. An example of such a formal verification tool is Solidify from Averant, Inc. in Sunnyvale, Calif. One disadvantage of formal verification is that it is impractical to use to re-produce functional failures observed in a running electronic system.

Both techniques, functional simulation and formal verification, have the major disadvantage that they do not operate on fabricated hardware. Instead, both techniques operate on a model of the electronic system and a model of the environment in which the electronic system runs, i.e., a testbench. Thus, their use is limited to debugging design errors. As such, neither technique is applicable for debugging manufacturing faults, environment errors, timing errors and/or tool errors. Also, inadequacies in the testbench have the potential to hide or introduce design errors in the HDL design during functional simulation which can later, when the HDL design is fabricated, show up as functional failures of the running electronic system.

Hardware logic level analysis is a technique that works at the logic level of a fabricated electronic system. The logic level of abstraction is also referred to as gate-level. Since electronic systems have been designed at the logic level for many years (for example using schematic entry of logic gates and flip-flops), there exists a wide variety of different techniques for debugging at logic level, including: digital logic analyzers, in-circuit emulators, Design-For-Test (DFT) techniques, and hardware emulation, each of these different techniques are discussed below.

Digital logic analyzers operate to probe a limited number of digital signals and record their logic values. Probing is accomplished by physically connecting probes of the digital logic analyzer to exposed pins and/or circuitry on the fabricated design. Recording is controlled by trigger conditions, which are conditional expressions built upon the values of the recorded signals provided by the probes. The values for the recorded signals are stored in dedicated memory inside the digital logic analyzer so as to be available for subsequent display. Digital logic analyzers can be external devices or blocks embedded inside the digital circuits of an electronic system. An example of an external digital logic analyzer is the Agilent 16715A from Agilent Technologies, Inc. in Palo Alto, Calif. Examples of embedded logic analyzers are SignalTap from Altera Corporation in San Jose, Calif., or ChipScope from Xilinx, Inc. in San Jose, Calif. Another example of an embedded logic analyzer was presented at the 1999 IEEE International Test Conference by Bulent Dervisoglu in "Design for Testability: It is time to deliver it for Time-to-Market". Since embedded logic analyzers are added to the circuitry of the design, they can probe internal signals. Thus, embedded digital logic analyzers overcome the limited access to internal signals problem of external logic analyzers because access to the internal signals is not restricted by the pins of the fabricated circuits.

An in-circuit emulator is a specialized piece of hardware that connects to a CPU for debugging the CPU and the software that runs on the CPU. An example of an in-circuit emulator is visionICE from Windriver in Alameda, Calif. However, since in-circuit emulators only work for the specific target CPU for which they were built, in-circuit emulators are inappropriate for debugging general digital circuits.

DFT techniques, such as boundary scan and built-in self test, provide access to the internal registers of a running fabricated digital circuit. An example of such technique is described in the IEEE 1149.1 JTAG standard available from the Institute of Electrical and Electronic Engineers in Piscataway, N.J. DFT techniques are also described in "Digital Logic Testing and Simulation" by Alexander Miczo, published by Wiley, John and Sons Inc., 1985. DFT techniques were originally developed for and applied to testing of manufacturing faults and have the major disadvantage that they do not relate back to the HDL description.

Hardware emulation systems map a synthesized HDL design onto special emulation hardware. Such emulation hardware comprises many re-programmable FPGA devices and/or special purpose processors. The emulation hardware then executes a model of the HDL design. Thus hardware emulation has the same disadvantage as functional simulation, namely, that it works on a model of the electronic system and not on the fabricated hardware. As a result, hardware emulation systems are limited to design error debugging, and cannot be used for diagnosing manufacturing faults, tool errors, timing errors, etc. An example of such a hardware emulation system is System Realizer from Quickturn Systems, in San Jose, Calif. Specially built prototyping systems comprising FPGAs/PLDs can also be seen as hardware emulation systems. Since hardware emulation is usually much faster than functional simulation, hardware emulation systems may enable use of the software that is supposed to run on the HDL design to be used as a testbench. Even so, hardware emulation typically runs at speeds below one MegaHertz (MHz) while the HDL design is supposed to run at many hundred MegaHertz. In some cases the emulator speed may allow the user to connect the HDL design to the target environment which makes the design of testbenches unnecessary. Even so, with the high speeds of state-of-the-art HDL designs, hardware emulation is not capable of debugging the majority of real-time applications. Another disadvantage is that the special synthesis, mapping, and multi-chip partitioning steps required to bring an HDL design into a hardware emulation system are very complicated and time consuming.

A major drawback of all logic level debugging techniques is that they work at the logic level of abstraction. Since the HDL-based design methodology of electronic systems is much more efficient for todays complex designs, HDL designs have largely replaced logic level designs. Application of logic level debugging techniques to HDL design methodology is highly inefficient. Since logic level debugging does not relate back to the HDL description, it normally would not provide the designer of the electronic system with sufficient information to correctly diagnose a functional failure.

Hardware behavioral source level emulation provides hardware emulation of source level designs. One technique for debugging HDL designs described at the behavioral level HDL using hardware emulation is described in "Interaktives Debugging algorithmischer Hardware-Verhaltens-beschreibungen mit Emulation" by Gernot H. Koch, Shaker Verlag, Germany, 1998. Some of which is also described in Koch et al., "Breakpoints and Breakpoint Detection in Source Level Emulation," ACM Transactions on Design Automation of Electronic Systems, Vol. 3, No. 2, 1998. The therein described technique is referred to as Source Level Emulation (SLE) and offers an approach for emulating HDL designs, however only if such designs are described in behavioral VHDL. During behavioral synthesis a behavioral HDL design is enhanced for debugging by generating and adding additional circuitry for break-point detection. The behavioral synthesis tool writes out synthesized VHDL which contains a register transfer level description of the enhanced HDL design. The register transfer level description is then synthesized, mapped, and multi-chip partitioned into the emulation hardware. During hardware emulation with a hardware model of the HDL design, the user is able to examine particular variables in the behavioral HDL description.

Control is provided via break-points which are detected using the additional circuitry inside the running hardware model. Break-points in SLE have a very specific meaning. In particular, such break-points are closely tied to behavioral operations in the data-flow of the behavioral HDL description, and are associated with particular states of a controller which is generated by the behavioral synthesis. Additionally, break-points can be made conditioned upon particular values of data-path registers. When a break-point is detected, the execution of the hardware model is stopped. This is done by halting some or all of the system clocks and prevents the registers from changing their current values. Once halted, internal registers can be read. These registers form a scan-chain such that their values can be read by an emulation debugging tool.

Examination of variables in the behavioral HDL description is done in two ways. For variables which are mapped by the behavioral synthesis into registers in the hardware model, their values can be read and related back to HDL identifiers. This is done using map files which keep track of the transformations in behavioral synthesis, register transfer level synthesis, mapping, and multi-chip partitioning. For variables which have not been mapped to registers in the hardware model, their values are computed using a functional model of the behavioral HDL design. This functional model is created during behavioral synthesis and requires the existence of functional models of its components. The values, either read or computed, are then displayed in the behavioral HDL description. Optionally, by overwriting some or all of the registers of the hardware model while the hardware model is halted, the behavior of the HDL design can be modified once the execution of the hardware model is resumed.

Although source level emulation provides a debugging method which works at the level of the HDL description (in this case behavioral VHDL), it has various drawbacks which limits its use in practice. Several of the drawbacks are as follows. First, enhancements for source level emulation must be done inside a behavioral synthesis tool, since it needs special information about the behavioral HDL design which is only available during the behavioral synthesis process. Second, source level emulation does not allow the designer to perform customization. For example, a designer is not able to select trade-offs between hardware overhead and debugging support. Third, source level emulation cannot handle HDL descriptions on levels of abstraction other than the one provided by behavioral VHDL. Explicitly, source level emulation is not applicable for the most commonly used levels of abstraction of RTL HDL and gate-level HDL. Fourth, source level emulation supports neither hierarchy nor re-use of pre-designed blocks. Fifth, there are various limitations and difficulties in relating registers back to behavioral HDL source code. Sixth, in order to examine the state of the hardware model, it is required that some or all of the system clocks be halted and the hardware stopped, which makes source level emulation inapplicable for debugging the majority of today's electronic systems which are not to be stopped.

Thus, there is a need for efficient and effective approaches for debugging HDL-based electronic system designs.

SUMMARY

Techniques and systems for analysis, diagnosis and debugging fabricated hardware designs at a Hardware Description Language (HDL) level are described. Although the hardware designs (which were designed in HDL) have been fabricated in integrated circuit products with limited input/output pins, the hardware designs within the integrated circuit products can be analyzed, diagnosed, and debugged at the HDL level at speed. The ability to debug hardware designs at the HDL level facilitates correction or adjustment of the HDL description of the hardware designs.

Some exemplary embodiments are described immediately below.

A method that comprises performing code coverage analysis, at speed and within a target environment, for an HDL description of an electronic system; where, the HDL description was previously instrumented for code coverage analysis in accordance with one or more directives that were specified by a user.

A method that comprises instrumenting an HDL description of an electronic system in accordance with one or more directives that are specified by a user; determining design instrumentation circuitry (DIC) based on the directives; fabricating the electronic system incorporated with the DIC; and, performing code coverage analysis of the HDL description at speed.

A hardware-based HDL code coverage analysis system to analyze the code coverage of tests applied to a fabricated electronic system, comprising: an instrumentor configured to receive a high level HDL description of the electronic circuit design, to determine aspects of the electronic circuit design to be examined or modified during debugging, to determine additional circuitry to be incorporated into the electronic circuit design to facilitate debugging, and to produce a modified high level HDL description of the electronic circuit design by incorporating an HDL description of the additional circuitry into the high level HDL description of the electronic circuit design; a design instrumentation database configured to store information about the additional circuitry including relationships between signals of the electronic circuit design and portions of the modified high level HDL description or the high level HDL description; and a HDL-based hardware debugger configured to debug the fabricated integrated circuit fabricated in accordance with the modified high level HDL description by interacting with the electronic circuit design using the additional circuitry and by operating to present debug information with respect to the modified high level HDL description or the high level HDL description.

Other aspects and perspectives will become apparent from the following detailed description taken in conjunction with the accompanying drawings which illustrate, by way of example, relevant principles.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:

FIG. 1A is a block diagram of a hardware debugging system according to one embodiment of the invention;

FIG. 1B is a block diagram of a hardware debugging system according to another embodiment of the invention;

FIG. 2 is a flow diagram of basic instrumentation processing according to one embodiment of the invention;

FIG. 3 is a block diagram of an instrumentation system according to one embodiment of the invention;

FIGS. 4A and 4B are flow diagrams of detailed design instrumentation processing according to one embodiment of the invention;

FIG. 5A is a flow diagram of selection processing according to one embodiment of the invention;

FIG. 5B is a flow diagram of break-point processing according to one embodiment of the invention;

FIG. 5C is a flow diagram of explicit trigger condition selection processing according to one embodiment of the invention;

FIG. 5D is a flow diagram of sampling signal selection processing according to one embodiment of the invention;

FIG. 6 is a diagram of a design instrumentation database according to one embodiment of the invention;

FIG. 7A is a block diagram of an instrumentation system according to one embodiment of the invention;

FIG. 7B is a diagram of a hard block resolution system according to one embodiment of the invention;

FIG. 8 is a block diagram of a representative Design Instrumentation Circuit (DIC) according to one embodiment of the invention;

FIG. 9 describes a representative generic configurable circuitry which can implement design sampling and design patching according to one embodiment of the invention;

FIG. 10 illustrates a representative generic configurable trigger detection circuit according to one embodiment of the invention;

FIG. 11 illustrates a representative state based Finite State Machine design control circuit according to one embodiment of the invention;

FIG. 12 illustrates a representative transition based Finite State Machine design control circuit according to one embodiment of the invention;

FIG. 13 illustrates a representative data-path register design control circuit according to one embodiment of the invention;

FIG. 14 illustrates a representative part of the design control circuit according to one embodiment of the invention;

FIG. 15 is a block diagram of a portion of an instrumentation system which includes a cross-reference analysis module and a cross-reference database according to one embodiment of the invention;

FIG. 16 is a block diagram of a portion of an instrumentation system which includes a DFT analysis module according to one embodiment of the invention;

FIG. 17 is a data flow diagram illustrating DIC creation processing according to one embodiment of the invention;

FIG. 18 is a flow diagram of HDL-based hardware debugging processing according to one embodiment of the invention;

FIG. 19 is a data flow diagram of a debugging process performed by a HDL-based hardware debugger according to one embodiment of the invention;

FIG. 20 is a block diagram of a hardware/software co-debugging system according to one embodiment of the invention; and

FIG. 21 is a block diagram of a hardware/software co-debugging system according to one embodiment of the invention.

FIG. 22 is a first flow diagram of hardware-based HDL code coverage and design analysis.

FIG. 23 is another flow diagram of hardware-based HDL code coverage and design analysis.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to techniques and systems for analysis, diagnosis and debugging fabricated hardware designs at a Hardware Description Language (HDL) level. Although the hardware designs (which were designed in HDL) have been fabricated in integrated circuit products with limited input/output pins, the invention enables the hardware designs within the integrated circuit products to be comprehensively analyzed, diagnosed, and debugged at the HDL level at speed. The ability to debug hardware designs at the HDL level facilitates correction or adjustment to the HDL of the hardware designs.

The following discussions will be made clearer by a brief review of the relevant terminology as it is typically (but not exclusively) used. Accordingly, to assist readers in understanding the terminology used herein, the following definitions are provided. "Software" is defined as but not limited to programming language content written using a programming language. Examples of programming languages include C, C++, Basic, assembly, and Java.

"HDL" is a Hardware Description Language. A hardware description language is defined as any programming language that can describe the hardware portion of an electronic system. Examples of HDLs include VHDL which is described in the IEEE Standard VHDL Language Reference Manual available from the Institute of Electrical and Electronic Engineers in Piscataway, N.J., which is hereby incorporated by reference; Verilog HDL which is described in Hardware Modeling with Verilog HDL by Eliezer Sternheim, Rajvir Singh, and Yatin Trivedi, published by Automata Publishing Company, Palo Alto, Calif., 1990, which is hereby incorporated by reference; and SystemC which stems from the Open SystemC Initiative (OSCI) originally started by Synopsys, Inc. of Mountain View, Calif. General purpose programming languages such as C++, C, and assembly languages may also be used as a HDL.

A "high level HDL description" is a HDL description in which at least a portion of the description is at register transfer level (RTL) or higher. For VHDL this synthesizable, register transfer level subset is described in the IEEE 1076.6-1999
Standard for VHDL Register Transfer Level (RTL) Synthesis, available from the Institute of Electrical and Electronic Engineers in Piscataway, N.J., which is hereby incorporated by reference. The synthesizable register transfer level subset of the Verilog HDL is described in "Verilog HDL: A Guide to Digital Design and Synthesis" by Samir Palnitkar, SunSoft Press, 1996.

A "RAM" is a Random Access Memory--defined as an electronic component capable of storing data.

"ASIC" is an Application Specific Integrated Circuit. An ASIC device is an electronic component of a system. ASICs are custom devices created for a specific purpose within the electronic system. ASIC devices are easier and faster to create with respect to a full custom semiconductor device. An ASIC may be described using HDL and implemented using synthesis.

An "FPGA" is a Field Programmable Gate Array. FPGAs are electronic components that have a configurable function. These devices are able to change their functionality via an information stream transferred to the device. These electronic components are available from a number of different suppliers in a wide range of sizes and speeds. One example of these devices are the Virtex FPGA devices from Xilinx, Inc. located in San Jose, Calif. An FPGA design may be described using HDL and implemented using synthesis.

A "Central Processing Unit" or "CPU" is circuitry controlling the interpretation and execution of software programmed instructions, performs arithmetic and logical operations on data, and controls input/output functions. For the following descriptions the term CPU will be used to also denote other processing elements such as microprocessors, digital signal processors, microcontrollers, etc.

A "register" is an element in digital circuitry which can store one or more bits. Examples for registers are the various types of flip-flops and latches.

A "PLD" is an Programmable Logic Device. PLDs are electronic components that have a configurable function. These devices are able to change their functionality via an information stream transferred to the device. These electronic components are available from a number of different suppliers in a wide range of sizes and speeds. One example of these devices are the Apex PLD devices from Altera Corporation in San Jose, Calif. A PLD design may be described using HDL and implemented using synthesis.

"Electronic Components" are defined as but not limited to, transistors, logic gates, integrated circuits, semi-custom integrated circuits, full custom integrated circuits, application specific integrated circuits (ASICs), gate arrays, programmable logic devices (PLDs), field programmable gate arrays (FPGAs), CPUs, Random Access Memory (RAM), mixed signal integrated circuits, systems on a chip (SOC), and systems on a printed circuit board.

An "Electronic System" is defined as a system that contains one or more digital and/or analog Electronic Components connected together to perform specific operations or functions. An Electronic System can be implemented entirely of hardware (Electronic Components) or consist of a mix of hardware and software (programming language content). "Mixed-signal designs" are defined as Electronic System designs which incorporate both digital and analog signals.

The "HDL Design" is referred to as the portion of the electronic system which is described in HDL and implemented in hardware. It is also referred to as the "Design under Test" (DUT).

An "SOC" is a System On Chip. A SOC is defined as a device large enough to contain an entire electronic system implementation. SOC devices can integrate a number of electronic devices into one device.

An "HDL description" is the textual description of an HDL Design. "HDL source code" is referring to the text files which contain the HDL description.

An "HDL identifier" is an object in an HDL description which represents a signal, a set of signals, a storage element, or a set of storage elements and which can take a value from a set of possible values. Each HDL identifier is associated with a particular scope defined by the syntax of the underlying hardware description language.

A "Technology Mapping Process" is defined as the process of transforming a particular representation of an electronic design into a design consisting entirely of primitive electronic elements from a design library for a target technology. The representation of said electronic design from which the Technology Mapping Process begins is dependent on the particular Technology Mapping Process being employed. However, said representation usually consists of simple boolean elements. For example, said representation may consist entirely of an interconnected set of 2-input/1-output logic elements with each said element performing the NAND function. An example of a tool that performs the Technology Mapping Process is Design Compiler from Synopsys in Mountain View, Calif.

"Synthesis" is defined as the process of creating an electronic implementation from the functional description of a system. An example of a tool that performs this operation is Design Compiler from Synopsys in Mountain View, Calif. which reads electronic system descriptions written in a synthesizable subset of VHDL and Verilog and produces a technology mapped design as an output.

"Behavioral HDL" is an HDL description at an algorithmic level of abstraction in which neither the timing behavior nor the structure of the HDL Design is explicitly described.

"Behavioral synthesis" transforms a behavioral HDL description into a register transfer level (RTL) description where the timing behavior and the structure of the HDL Design is fixed. This RTL description is then processed in synthesis and technology mapping. An example of a tool that performs behavioral synthesis is Behavioral Compiler from Synopsys, Inc. of Mountain View, Calif.

A "System Clock" is defined as a main timekeeping signal in a design. All operations that are relative to the System Clock will proceed when the System Clock becomes active. "Constraints" are defined as limits placed on parameters for the implementation of an electronic system. Parameters of an electronic system can include but are not limited to register to register propagation delay, system clock frequency, primitive element count, and power consumption. These constraints can be used by synthesis tools to guide the implementation of the electronic design.

"Fabrication" is the process of transforming a synthesized and technology mapped design into one or more devices of the target technology. For example, the fabrication of ASICs involves manufacturing and the fabrication of FPGAs and PLDs involves device configuration.

"DFT" is Design-for-test. DFT is defined as a process in which an electronic system designer will include structures in the electronic system that facilitates manufacturing testing.

"Design Rule Check" (DRC) are checks performed before integrated circuit manufacturing to ensure that in the placed and routed technology mapped design none of the rules of the target technology process is violated. Examples for such DRC are checks for shorts, spacing violations, or other design-rule problems between logic cells. An example for a tool that does DRC is Dracula from Cadence Design Systems, Inc. in San Jose, Calif.

A "Functional Specification" is defined as the documentation that describes the necessary features and operations of a system.

A "functional failure" is a behavior of a design which does not meet the functional specification which was used in the creation of the design. Every step in the design process can potentially cause a functional failure. Functional failures can be classified depending on which step of the design process caused the functional failure.

A "fault" is a specific type of functional failure. This type of failure is due to one or more manufacturing defects causing a functional failure in the fabricated design.

A "design error" is a specific type of functional failure where the HDL description's behavior did not match the functional specification.

A "tool error" is a specific type of functional failure which was introduced by design tools because the HDL description was not properly processed such that the functional specification is not met by the implementation.

An "environment error" is a specific type of functional failure caused by a particular combination of environmental parameters such as temperature, humidity, pressure, etc.

A "Functional Simulator" is a tool that mimics the functional behavior of a model of an electronic system which is described using HDL.

A "Testbench" is defined as an electronic system description that presents stimulus to and/or gathers information from the target electronic system design to be verified. In some cases the testbench ignores the response from the target electronic system design. A testbench is used to mimic the behavior of the target environment in which the electronic system being developed will operate. A testbench may comprise both hardware and software.

A "Target Environment" is the system the electronic system is specified to interact with and/or to run in. A target environment may comprise both hardware and software.

The "Target Speed" of an electronic system is the speed and/or the speed range the electronic system is specified to run at. Examples for measures for the target speed and the speed range are clock frequency, response time, time to propagate, and cycle time.

"Debugging" is the process of comparing the behavior of an implementation of the electronic system to the electronic system functional specification. The purpose of debugging is to find causes and remedies for functional failures.

"Co-Debugging" or "hardware/software co-debugging" is defined as the process of debugging the software and hardware of an electronic system concurrently.

A "FSM" is Finite State Machine--defined as an electronic system control structure. The design and implementation of FSM is described in great detail in Synthesis and Optimization of Digital Circuits, by Giovanni DeMicheli, McGraw Hill, 1994.

A "HDL Building Block" is a functional unit of an HDL Design from which the HDL Design is constructed. A HDL Building Block (BB) performs calculations on the signals to which it is connected and communicates with other BBs in the design. The communication is through connecting internal signals of a BB to communication ports of the BB and/or connecting internal signals of the BB to communication ports of other BBs in the HDL Design. Examples of BBs are Entities in the VHDL language and Modules in the Verilog language.

A "Hard Block" is an electronic system which has a pre-defined functionality and which can be incorporated into another electronic system. Commonly, the form of the Hard Block is such that the functionality of the Hard Block can not be altered. An example of a hard block is an HDL Design which implements a industry standard bus controller.

A "Design State" is defined as the logical values taken by the storage elements of the design at a particular time, combined with the logical values taken by the inputs of the design taken at the same particular time. The "System State" or "State of the System" is a synonym for "Design State."

"Real-time" means a task, process or response occurs substantially immediately. The term is used to describe a number of different computer features. For example, real-time operating systems are systems that respond to input immediately. Real-time is also used for describing tasks in which the computer must react to a steady flow of new information without interruption. Real-time can also refer to events simulated by a computer at the same speed that they would occur in real life.

Embodiments of this aspect of the invention are discussed below with reference to FIGS. 1 21. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments.

FIG. 1A is a block diagram of a hardware debugging system 100 according to one embodiment of the invention. The hardware debugging system 100 operates to debug a hardware product referred to herein as a Device Under Test (DUT) 102. The DUT 102
is typically part of a larger hardware product referred to as an electronic system 104. The DUT 102 can pertain to a single integrated circuit chip, multiple integrated circuit chips, a system on a chip, or a system on a printed circuit board.

According to the invention, the DUT 102 includes Design Instrumentation Circuitry (DIC) 106. The DIC 106 is provided within the DUT 102 in order to facilitate debugging of the DUT 102. The DIC 106 can be provided within the DUT 106 in either a centralized or distributed manner.

The hardware debugging system 100 operates to determine the DIC 106 that is provided within the DUT 102. In this regard, an original HDL description 108 of the electronic system 104 is received at an instrumentor 110. The instrumentor 110
modifies or alters the original HDL description 108 to produce an instrumented HDL description 112. The instrumented HDL description 112 represents not only the electronic system 104 with the DUT 102 provided therein, but also the DIC 106 that is provided within the DUT 102. The instrumentor 110 also stores DIC information to a design instrumentation database 114. By storing the DIC information in the design instrumentation database 114, the hardware-based debugging of the DUT 102 is facilitated.

The hardware debugging system 100 also includes synthesis and place & route systems 116. The synthesis and place & route systems 116 receives the instrumented HDL description 112 and performs conventional synthesis as well as place & route operations in order to produce an instrumented design 118. Although not shown in FIG. 1A, other additional tools can be utilized to produce or enhance the instrumented design 118. Examples of additional tools include a Design-For-Test (DFT) tool or a Design Rule Check (DRC) tool. The instrumented design 118 represents a description (e.g., design files) of the electronic system 104 that would be thereafter fabricated. Hence, once the instrumented design 118 is available, fabrication 120 can be performed. The fabrication 120 produces the electronic system 104 having the DUT 102 with the DIC 106 provided therein. Fabrication is the process of transforming a synthesized and technology mapped design (e.g., the instrumented design 118) into one or more devices of the target technology. For example, if the target technology is Application Specific Integrated Circuits (ASICs) then the fabrication involves manufacturing, and if the target technology is Field Programmable Gate Arrays (FPGAs) or Programmable Logic Devices (PLDs) the fabrication involves device configuration.

At this point, the electronic system 104 is a hardware product that has been produced. This hardware product can then be debugged using a HDL-based hardware debugger 122. More particularly, the HDL-based hardware debugger 122 couples to the DIC
106 so that it is able to communicate with the DIC 106 when debugging the DUT 102. The HDL-based hardware debugger 122 also couples to the design instrumentation database 114 so that access to the DIC information is available. As a result, the HDL-based hardware debugger 122 enables a user to debug the DUT 102 and/or hardware and/or software interacting with the DUT 102 in close relation to the original HDL description 108. Further, in one embodiment, debugging can be performed while the electronic system 104 and the DUT 102 operate in the target environment, at target speed.

FIG. 1B is a block diagram of a hardware debugging system 150 according to another embodiment of the invention. The hardware debugging system 150 is similar to the hardware debugging system 100 and includes many of the same components. Hence, the hardware debugging system 150 enables a user of the HDL-based hardware debugger 122 to debug the DUT 102 of the electronic system 104 and/or hardware and/or software interacting with the DUT 102, as noted above. However, the hardware debugging system 150 includes a synthesis and place & route system 152 that includes an instrumentor 154. Hence, the original HDL description 108 is supplied to the synthesis and place & route system 152. The synthesis and place & route system 152 can then produce the instrumented design 118 while using not only synthesis and place & route tools but also the instrumentor 154. In this embodiment, the instrumentor 154 is able to be embedded within synthesis and place & route system 152. Here, the instrumentor 154 assists with producing the instrumented design 118 which represents the electronic system 104 having the DIC 106 provided within the DUT 102. However, with the hardware debugging system 150, the original HDL description 108 need not be modified to produce an instrumented HDL description.

FIG. 2 is a flow diagram of basic instrumentation processing 200 according to one embodiment of the invention. The basic instrumentation processing 200 is, for example, performed by the instrumentor 110 illustrated in FIG. 1A or the instrumentor
154 illustrated in FIG. 1B.

The basic instrumentation processing 200 initially receives 202 a HDL description for an electronic system. The HDL description is then analyzed 203 to understand the characteristics of the electronic system. Next, parts (or portions) of the electronic system that are to be examined and/or modified are determined 204. Typically, the parts of the electronic system to be examined and/or modified (e.g., instrumented) are within a DUT such as the DUT 102 illustrated in FIGS. 1A and 1B. Hence, the parts of the electronic system to be examined and/or modified represent various signals and/or components within the DUT. After the parts of the electronic system to be examined and/or modified have been determined 204, design instrumentation circuitry (DIC) is generated 206. Preferably, the DIC is determined 204 based on the parts of the electronic system to be examined and/or modified. In this regard, the DIC can be at least partially customized to the application such as the amount or degree of testing or debugging desired. Thereafter, the DIC is incorporated 208 into the electronic system. The DIC can be incorporated 208 into the electronic system (namely, the DUT) in various ways. In one embodiment, the DIC can be incorporated by adding HDL to the original HDL for the electronic system. In another embodiment, the DIC can be incorporated by modifying a netlist description for the electronic system. Following the operation 208, the basic instrumentation processing 200 is complete and ends.

Design instrumentation (DI) is a process by which a HDL description of an electronic system is analyzed, and then a DIC computed. The DIC is thereafter incorporated (e.g., added) into the electronic system to facilitate debugging. The DIC can be added to the electronic system in a variety of ways. In one embodiment, DIC can be added to the electronic system by adding an HDL description of the DIC to the HDL description of the electronic system. In another embodiment, the DIC can be added to the electronic system during synthesis. The DIC provides mechanisms to control the examination and/or modification of a running electronic system. Thus, the DIC allows to analyze, diagnose, and/or debug the DUT by giving detailed and accurate information about its current state of operation, as well as the state history.

FIG. 3 is a block diagram of an instrumentation system 300 according to one embodiment of the invention. The instrumentation system 300 operates to perform design instrumentation operations to produce an appropriate DIC.

The instrumentation system 300 includes an instrumentor 302. The instrumentor 302 operates to determine the appropriate DIC for the electronic system (namely, the DUT) that is to be eventually hardware debugged. The instrumentor 302 receives an original HDL description 304 as well as instrumentation directives 306. The instrumentation directives 306 are instructions to the instrumentor 302 that inform the instrumentor 302 of the portions, parts or areas of the original HDL description 304 that are to be examined and/or modified. The instrumentation directives 306 can be predetermined or interactively provided by a user through a user interface. Additionally, the instrumentor 302 can further receive design constraints 308, Design For Test (DFT) information 310, instrumented pre-designed blocks 312 and DIC template(s) 314.

The design constraints 308 are constraints on the particular design associated with the original HDL description 304. More particularly, design constraints are limits placed on parameters for an implementation of an electronic system. Some examples of the parameters that can be limited by design constraints include register-to-register propagation delay, system clock frequency, primitive element count, and power consumption. The constraints on the parameters are used by synthesis and place & route tools to guide the implementation of the electronic design.

The DFT information 310 is information about features (e.g., structures) of the original HDL description 304 that pertain to testing. The DFT information is used to facilitate manufacturing testing. For example, the DFT information 310 can provide a description of a scan-chain provided within the original HDL description 304. The instrumentor 302 can utilize portions of the DFT information 310 to reduce the circuitry required for the DIC.

The DIC can make use of previously instrumented pre-designed blocks 312. In case the electronic system contains pre-designed blocks which have been instrumented, the DIC can communicate with the previously instrumented pre-designed blocks 312 to facilitate their debugging. The DIC template(s) 314 provide one or more templates for the instrumentor 302 to utilize when producing the DIC.

The instrumentor 302 outputs an instrumented description 316. In one embodiment, the instrumented description 316 can be represented as an instrumented HDL description in which the original HDL description 304 has been enhanced to include a HDL description of the DIC (see FIG. 1A). In another embodiment, the instrumented description 316 can represent an instrumented netlist (see FIG. 1B). The instrumentor 302 also produces an optional DIC HDL description 318. The DIC HDL description 318 can be utilized by a functional simulator or synthesis and place & route tools. The instrumentor 302 can also produce an optional DIC simulation model 322 that permits functional simulation of the instrumented description 316. Still further, the instrumentor 302 can output synthesis and place & route constraints 324 and modified DFT information 326. The synthesis and place & route constraints 324 can be utilized by the synthesis and place & route tools. The modified DFT information 326 can also be used by the synthesis and place & route tools, so that the resulting electronic system is able to be tested as originally designed.

The instrumentation system 300 also includes a design instrumentation database 320 that stores instrumentation information. The instrumentation information includes information on the types of instrumentations that have been done, the DIC and other information as explained in greater detail below. As noted above, an HDL-based hardware debugger (e.g., debugger 122) eventually utilizes the DIC information stored in the design instrumentation database 320 when performing hardware debugging of the electronic system. Additional details on the design instrumentation database 320 are provided in FIG. 6 below.

FIGS. 4A and 4B are flow diagrams of detailed design instrumentation processing 400 according to one embodiment of the invention. The detailed design instrumentation processing 400 is, for example, performed by the instrumentor 110 illustrated in FIG. 1A, the instrumentor 154 illustrated in FIG. 1B, or the instrumentor 302 illustrated in FIG. 3.

The detailed design instrumentation processing 400 initially receives 402 a HDL description of an electronic system. The HDL description is then parsed and analyzed 404. The analysis 404 of the HDL description can identify portions that cannot be instrumented or that can only be instrumented in certain ways. The result of the analysis 404 can be used to determine whether particular instrumentation directives are valid, and thus can be followed by the instrumentor.

Additionally, one or more of design constraints, DFT information, predetermined instrumentation directives, or pre-designed blocks may also optionally be received 406. Then, instrumentation directives are determined 408. Here, instrumentation directives can be predetermined and thus provided or can be determined through user interaction. FIGS. 5A 5D, discussed below, pertain to user interaction to produce instrumentation directives.

After the instrumentation directives are determined 408, a customized DIC is produced 410 based on the HDL description and the instrumentation directives. Hence, the customized DIC is tailored to the particular HDL description and the particular instrumentation directives. By tailoring the DIC to the particular HDL description and the particular instrumentation directives, the customized DIC makes efficient use of its circuitry. Since the DIC consumes area (e.g., die space) on the hardware product (e.g., semiconductor chip), making the customized DIC efficient and compact is advantageous. In producing the customized DIC, the detailed design instrumentation processing 400 is able to reuse pre-designed blocks that have already been instrumented. In other words, the customized DIC can communicate with existing DICs of pre-designed blocks that represent other portions of the electronic system (or even external systems).

Additionally, the DIC can be optimized 412 to reduce hardware overhead and/or maximize coverage. Here, the optimization 412 to the DIC enables the hardware overhead associated with the DIC to be reduced which is advantageous in producing or using integrated circuit products. For example, cost analysis can be performed during the optimization to explore the different structures in the context of a given implementation technology and given design constraints. Variations of the DIC can thus be explored in order to minimize the overhead of the DIC on the hardware in terms of area, delay, power consumption, routability, and/or testability. Variations of the DIC can be described via DIC templates. The optimization 412 can also try to increase the effects of the instrumentation with regards to the hardware overhead. For example, if some certain signals can be examined, some other signals may also be able to be examined without any or minimal hardware overhead.

Next, a decision 414 determines whether design constraints have been provided. Typically, the design constraints are provided in a file which contains specifications for area, delay, power consumption, routability and testability. When the decision 414 determines that design constraints have been provided, then the DIC may be modified 416 in view of the design constraints. Also, modifications to the design constraints may be performed so that the overall design of the electronic system (including the DIC) complies with the intent of the original design constraints. For example, timing constraints may be changed to reflect the insertion of the DIC. In addition, additional design constraints might be generated, which, for example, may be used to guide synthesis and place & route tools in optimizing the DIC.

Following operation 416, as well as following the decision 414 when design constraints are not provided, a decision 418 determines whether DFT information has been provided. When the decision 418 determines that DFT information has been provided, then the DFT information is complied with or reused 420. When complied with, the detailed design instrumentation processing 400 renders the customized DIC compatible or compliant with the DFT information (e.g., existing DFT structures in the design). For example, scan-chains or boundary-scans can be provided or modified to take into account the DIC. Alternatively, when the DFT information is reused, the customized DIC can make use of portions of the circuitry made available through the DFT information and thereby make use of existing circuitry. The modifications to the DFT information can reflect the ability of the DIC to utilize portions of the circuitry within the electronic system associated with the DFT information as well as with the ability to modify the DFT information to preserve the intent of the designer after the DIC is included within the electronic system.

Following the operation 420, as well as following the decision 418 when the DFT information is not provided, a decision 422 determines whether instrumented, pre-designed blocks have been provided. When the decision 422 determines that instrumented, pre-determined blocks have been provided, then the DIC of each instrumented, pre-designed block is connected 424 to the current DIC. This facilitates debugging of the electronic system which contains pre-designed blocks.

Following operation 424, as well as following the decision 422 when instrumented, pre-designed blocks are not provided, DIC information is stored 426 to a design instrumentation database. The DIC information includes a description of the DIC, the instrumentation directives, and DIC connectivity information. The DIC information can also include cross-reference data that relates elements in the design of the electronic system (i.e., hardware implementation) to and from the HDL description. Then, the customized DIC can then be added 428 to the electronic system. The customized DIC can be added 428 to the electronic system in a variety of different ways. For example, with respect to an embodiment such as illustrated in FIG. 1A, the customized DIC can be added 428 to the electronic system by producing the instrumented HDL description which describes the electronic system with the DIC included therein. Alternatively, with respect to an embodiment such as illustrated in FIG. 1B, the customized DIC can be added to the electronic system by modifying a netlist that defines the electronic system.

Following operation 428 the detailed design instrumentation processing 400 operates to produce and output 430 the instrumented description, an optional DIC simulation model and an optional DIC HDL description. The DIC simulation model can be used by a simulator when functionally simulating the operation of the DUT. The DIC HDL description may for example also be used for simulation. Following the operation 430, the detailed design instrumentation processing 400 is complete and ends.

As noted above, the instrumentation directives can be predetermined and thus provided or can be determined through user interaction. When the instrumentation directives are predetermined, they can be obtained from a design instrumentation file. In one embodiment, the instrumentation directives specify design visibility, design patching and design control criteria for particular portions of the design for the electronic system. Design Visibility (DV) is monitoring the entire or partial state of the DUT at, and relative to, predetermined events. An important aspect of DV is relating the states of operation back to identifiers in the original HDL description for examination during HDL-based hardware debugging. In one embodiment, DV is done by sampling the values of one or more signals of the DUT for a particular time interval determined by one or more predetermined events. The events are determined by Design Control which is described below. Design Visibility serves to monitor the state of operation of the DUT, but does not alter the DUT's behavior in any way. However, in some situations, it is advantageous to have a method to alter the behavior of the DUT after the hardware has been fabricated. Design Patching (DP) is to alter the behavior of the DUT to a predetermined particular desired state at predetermined events. The events are determined by Design Control which is described below. A particular desired state of a DUT is a particular setting of the values of all or a subset of all storage components in the DUT.

Design Control (DC) provides the designer with a method to specify the events that control DV and DP. DC can be accomplished by one or more trigger conditions. A trigger condition is a conditional expression comprising HDL identifiers where the conditional expression denotes a combination comprising a particular state and/or state transition, and/or history of states and/or history of state transitions, the DUT, or a portion of it, can be in. Each time a particular trigger condition is met an associated trigger event is produced. One or more trigger events can be combined to issue a particular predetermined trigger action which may control the DV and DP and may control other functions re