[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

US7096440B2 - Methods and systems for automatic verification of specification document to hardware design - Google Patents

Methods and systems for automatic verification of specification document to hardware design Download PDF

Info

Publication number
US7096440B2
US7096440B2 US10/624,347 US62434703A US7096440B2 US 7096440 B2 US7096440 B2 US 7096440B2 US 62434703 A US62434703 A US 62434703A US 7096440 B2 US7096440 B2 US 7096440B2
Authority
US
United States
Prior art keywords
hardware
document
database
hardware device
predefined elements
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime, expires
Application number
US10/624,347
Other versions
US20050022058A1 (en
Inventor
David A. Fechser
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bell Semiconductor LLC
Original Assignee
LSI Logic Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LSI Logic Corp filed Critical LSI Logic Corp
Priority to US10/624,347 priority Critical patent/US7096440B2/en
Assigned to LSI LOGIC CORPORATION reassignment LSI LOGIC CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FECHSER, DAVID A.
Publication of US20050022058A1 publication Critical patent/US20050022058A1/en
Application granted granted Critical
Publication of US7096440B2 publication Critical patent/US7096440B2/en
Assigned to DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT reassignment DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT PATENT SECURITY AGREEMENT Assignors: AGERE SYSTEMS LLC, LSI CORPORATION
Assigned to LSI CORPORATION reassignment LSI CORPORATION CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: LSI LOGIC CORPORATION
Assigned to AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. reassignment AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LSI CORPORATION
Assigned to LSI CORPORATION, AGERE SYSTEMS LLC reassignment LSI CORPORATION TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031) Assignors: DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT
Assigned to BANK OF AMERICA, N.A., AS COLLATERAL AGENT reassignment BANK OF AMERICA, N.A., AS COLLATERAL AGENT PATENT SECURITY AGREEMENT Assignors: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.
Assigned to AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. reassignment AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS Assignors: BANK OF AMERICA, N.A., AS COLLATERAL AGENT
Assigned to BELL SEMICONDUCTOR, LLC reassignment BELL SEMICONDUCTOR, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD., BROADCOM CORPORATION
Assigned to CORTLAND CAPITAL MARKET SERVICES LLC, AS COLLATERAL AGENT reassignment CORTLAND CAPITAL MARKET SERVICES LLC, AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BELL NORTHERN RESEARCH, LLC, BELL SEMICONDUCTOR, LLC, HILCO PATENT ACQUISITION 56, LLC
Assigned to BELL SEMICONDUCTOR, LLC, BELL NORTHERN RESEARCH, LLC, HILCO PATENT ACQUISITION 56, LLC reassignment BELL SEMICONDUCTOR, LLC RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: CORTLAND CAPITAL MARKET SERVICES LLC
Adjusted expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2284Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing by power-on test, e.g. power-on self test [POST]
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01RMEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317Testing of digital circuits
    • G01R31/3181Functional testing
    • G01R31/3183Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318342Generation of test inputs, e.g. test vectors, patterns or sequences by preliminary fault modelling, e.g. analysis, simulation
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01RMEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317Testing of digital circuits
    • G01R31/3181Functional testing
    • G01R31/3183Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318342Generation of test inputs, e.g. test vectors, patterns or sequences by preliminary fault modelling, e.g. analysis, simulation
    • G01R31/318357Simulation
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01RMEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317Testing of digital circuits
    • G01R31/3181Functional testing
    • G01R31/3183Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318364Generation of test inputs, e.g. test vectors, patterns or sequences as a result of hardware simulation, e.g. in an HDL environment

Definitions

  • Embodiments generally relate to hardware design verification methods and systems. Embodiments also relate to methods and systems for verifying integrated circuit designs. Embodiments additionally relate to Power On Self Test (POST) techniques and devices.
  • POST Power On Self Test
  • design verification In many instances it can be necessary to implement hardware design verification methods and systems.
  • the objective of design verification is to ensure that errors are absent from a design.
  • Modern integrated circuit (IC) manufacturing technology is enabling IC designers to place millions of transistors on a single IC.
  • Design complexity is doubling every 12–18 months, which causes design verification complexity to increase at an exponential rate.
  • competitive pressures are putting increased demands on reducing time to market.
  • Today's design flow begins with a hardware specification document for the design.
  • the engineer then implements the design in a language model, typically a Hardware Description Language (HDL).
  • HDL Hardware Description Language
  • Such a model can be utilized to discover incorrect input/output (I/O) behavior through a stimulus in expected “results out” paradigm at the top level of the design.
  • simulation-based functional verification By far the most popular method of functional verification today is simulation-based functional verification, which is widely utilized within the digital design industry as a technique for detecting defects within hardware designs.
  • a very wide variety of products are available in the market to support simulation-based verification methodologies.
  • a fundamental problem with conventional simulation-based verification approaches is that they are vector and test bench limited.
  • Simulation-based verification is driven by a test bench that explicitly generates the vectors to achieve stimulus coverage and also implements the checking mechanism.
  • Test benches create a fundamental bottleneck in simulation-based functional verification. In order to verify a design hierarchy level, a test bench must be generated for it. This creates verification overhead for coding and debugging the test bench. Hence, a significant amount of expensive design and verification engineering resources are needed to produce results in a cumbersome and slow process.
  • Formal verification is another class of tools that has entered the functional verification arena. These tools rely on mathematical analysis rather than simulation of the design. The strong selling point of formal verification is the fact that the results hold true for all possible input combinations to the design. However, in practice this high level of stimulus coverage has come at the cost of both error coverage and particularly usability. While some formal techniques are available, they are not widely used because they typically require the designer to know the details of how the tool works in order to operate it. Formal verification tools generally fall into two classes: (1) equivalence checking, and (2) model checking.
  • Equivalence checking is a form of formal verification that provides designers with the ability to perform RTL-to-gate and gate-to-gate comparisons of a design to determine if they are functionally equivalent. Importantly, however, equivalence checking is not a method of functional verification. Rather, equivalence checking merely provides an alternate solution for comparing a design representation to an original golden reference. It does not verify the functionality of the original golden reference for the design. Consequently, the original golden reference must be functionally verified using other methods.
  • Model checking is a functional verification technology that requires designers to formulate properties about the design's expected behavior. Each property is then checked against an exhaustive set of functional behaviors in the design. The limitation of this approach is that the designer is responsible for exactly specifying the set of properties to be verified. The property specification languages are new and obscure. Usually the technology runs into capacity problems and the designer has to engage with the tools to solve the problems.
  • IC integrated circuit
  • a plurality of predefined elements can be designed within a hardware specification document, wherein the hardware specification document provides a hardware design for a hardware device.
  • the plurality of predefined elements can be stored within a database of hardware components, wherein each predefined element of the plurality of predefined elements is associated with a hardware component of the hardware device.
  • Physical components of the hardware device can be compared with the predefined elements maintained within the database of hardware components upon an initial power-up of the hardware device in order to verify that the hardware device functions according to the hardware specification document.
  • FIG. 1 illustrates a block diagram of a data processing system in which an embodiment of the present invention may be implemented
  • FIG. 2 illustrates a high-level flowchart depicting logical operational steps, which may be followed to implement an embodiment of the present invention
  • FIG. 3 illustrates a high-level flowchart depicting continuing logical operational steps of the flowchart depicted in FIG. 2 , in accordance with an embodiment of the present invention
  • FIG. 4 illustrates a block diagram of a hardware interrupt system, which can be implemented in accordance with an embodiment of the present invention
  • FIG. 1 a block diagram of a data processing system 100 in which the present invention may be implemented is illustrated.
  • the depicted example is not meant to imply architectural limitations with respect to embodiments of the present invention, but is presented for general illustrative and edification purposes only.
  • Data processing system 100 can employ a peripheral component interconnect (PCI) local bus architecture.
  • PCI peripheral component interconnect
  • a Processor 102 and a main memory 104 can be connected to PCI local bus 106 through PCI bridge 108 .
  • PCI bridge 108 also may include an integrated memory controller and cache memory for processor 102 .
  • a controller 103 can communicate with PCI local bus 106 to provide additional architectural support. Controller 103 may be utilized in place of to complement an integrated memory controller and cache memory for processor 102 .
  • PCI local bus 106 may be made through direct component interconnection or through add-in boards.
  • local area network (LAN) adapter 110 host bus adapter 112 , and expansion bus interface 114 are connected to PCI local bus 106 by direct component connection.
  • audio adapter 116 graphics adapter 118 , and audio/video adapter (A/V) 119 are connected to PCI local bus 106 by add-in boards inserted into expansion slots.
  • Expansion bus interface 114 provides a connection for a keyboard and mouse adapter 120 , modem 122 , and additional memory 124 .
  • Host bus adapter 112 provides a connection for hard disk drive 126 , tape drive 128 , and CD-ROM 130 in the depicted example.
  • Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.
  • the depicted example includes four loads on the mother board and three expansion slots.
  • FIG. 1 may vary.
  • other peripheral devices such as optical disc drives and the like may be used in addition to or in place of the hardware depicted in FIG. 1 .
  • FIG. 2 a high-level flowchart 200 depicting logical operational steps is illustrated, which may be followed to implement an embodiment of the present invention.
  • FIG. 3 illustrates a high-level flowchart 300 depicting continuing logical operational steps of the flowchart 200 depicted in FIG. 2 , in accordance with an embodiment of the present invention.
  • like parts or elements are indicated by identical reference numerals, such that flowcharts 200 and 300 represent a single continuous flowchart of logical operation steps.
  • FIGS. 2 and 3 together generally illustrate a methodology that includes document parsing software utility, routines, and/or subroutines which search for predefined flags and formatting in a hardware specification document and extracts the hardware information from the hardware specification document.
  • the document parsing software utility generates a database can be utilized by other utilities.
  • the methodology of FIGS. 2 and 3 can also be utilized to implement an RTL code auto-generation utility that reads the database and creates valid RTL hardware description code that defines the storage elements in the hardware.
  • a software code auto-generation utility can be utilized to read the database and create valid software code that defines accesses to the storage elements in the hardware, and which also can generate hardware specification tables, which can be utilized by a Power On Self Test (POST) function, which is described in further detail herein.
  • POST Power On Self Test
  • the process is initiated.
  • a document writer can follow a specified procedure to created detailed descriptions of the hardware to be designed according to the hardware specification document.
  • Such specified procedure includes the use of specified formats for register map tables, address map tables and register description sections of the hardware specification document.
  • invisible flags are embedded in the document to be utilized by the document reader script, which will be described in more detail herein.
  • the document can be saved and used by internal and external engineers as formatted.
  • the document can be saved as a text-only document for use by the document reader script.
  • a document parsing software utility reads the document(s), and creates, as depicted at block 214 , a database of all storage elements in the document that are visible to a microcontroller, such as, for example, controller 103 of data processing system 100 illustrated in FIG. 1 .
  • a microcontroller such as, for example, controller 103 of data processing system 100 illustrated in FIG. 1 .
  • an RTL code auto-generator can be utilized to create HDL code file(s).
  • HDL generally refers to “Hardware Description Language”.
  • the software code auto-generator can create software file(s) that contain definitions and declarations for every storage element and for every bit field within registers, strictly as defined in the hardware document specification.
  • the software code auto-generator can create tables utilized by Power-On Self Test Code to check the hardware upon power-up. The use of the auto-generated software code ensures that the RTL hardware description complies with the hardware specification document.
  • two code auto-generators can be implemented, including the hardware RTL code generator and the software code generator.
  • Block 216 refers to hardware code.
  • Blocks 220 – 222 refer to software code which is not RTL code.
  • such code may be C or C++ code. It can of course be appreciated by those skilled in the art that C or C++ code is not considered a limiting feature of the present invention, because other types of programming code can also be utilized to implement embodiments.
  • the use of the auto-generated software code for storage elements and the Power-On Self Test tables causes the software to fail if the hardware does not comply with the specification document.
  • a test can be performed to determine if the hardware complies with the specification document. If so, then the hardware design is verified, as indicated at block 228 . If not, then the hardware design fails, as indicated at block 226 . The process then terminates, as depicted at block 230 .
  • files can be organized according to a layered structured.
  • a layered structure can be implemented as firmware and may include hardware drivers, which are based on code that actually manipulates hardware register bits or memory. These drivers can be contained in the context of one or more files that hold only code that affects the specific hardware in question.
  • a hardware driver generally is composed of both initialization code, and the actual driver code.
  • the layered structure can also include configuration code that loads data and then acts as a ROM (read only memory) for the remainder of the firmware operations.
  • such a layer structure can include definitions that are specific to an external standard, such as, for example, the SAS or SCSI bus standards. These definitions can be contained in header files that hold definitions specific to that standard.
  • the layered structure can also include operating system header and code files that exist to contain definitions and declarations utilized by a kernel to control the general flow of the software. These include all general code files that contain common definitions and declarations.
  • the layer structure can include development code files are files that contain code utilized for debugging. Code that facilitates retargettable Output for tracing or any other functions that are not part of the actual firmware can be contained within such code files.
  • the interface for each separately specified block of hardware can be contained within its own code file set.
  • the intent of this action is to provide a hardware abstraction layer so that if any part of the hardware is upgraded or redesigned in a later generation of the chip, code changes are limited to only the files owning that hardware interface.
  • the files can contain the following: ⁇ HW Block Name>.h.
  • This file contains the interface between the hardware and the rest of the firmware.
  • Such a file can include prototypes for any functions that are owned by the hardware interface and that are visible to other parts of the firmware (e.g., a driver API). This also includes ‘extern’ declarations for any constants that are owned by this hardware interface but that must be visible elsewhere.
  • the files can also contain ⁇ HW Block Name>.c.
  • This file contains the code that directly manipulates the hardware. This includes declarations for all private functions, variables, block-owned registers, and constants. This also includes definitions for all public functions and for constants declared ‘extern’ in the .h file.
  • code architecture can be implemented to include an infinite loop, event handlers, and interrupt handlers.
  • the kernel code which implements the architecture can be contained in the main.c and global.c/h files. This includes event handling code and various other general utilities that are used by other code but are not hardware-specific.
  • a Power On Self Test can be implemented in accordance with embodiments of the present invention and may possess special capabilities due to a UNIX executable aspect of the compiled code that would not be available if this were truly loadable firmware.
  • a number of data structures can be used in the POST, including a Register Block Space Table, which comprises an Array storing the size of the address space for each register block. Such a table can be utilized to test the reserved spaces for unspecified storage elements. Registered addresses can be also utilized in the POST as a list of number defined literals utilized in other tables.
  • a “Go Mask Table” can also be utilized with the post, which comprises an array that contains an entry for every register that contains a GO bit.
  • Each entry will contain the address of the register and a mask with zeroed bits where GO bits exist. Go bits are specified in the hardware specifications by the letters “Go” at the end of the bit name. Additional data structures include a Power-On Reset Value Table (POR VTable) and a “Write Bits table.”
  • POR VTable can be implemented as an array organized by register within register block. Each entry contains the register's address, the POR specification for the register, and a mask value that contains zeroed bits wherever the hardware specification indicates that the POR value is unknown.
  • a “Write Bits Table” can be configured as an array organized by register within register block. Each entry can contain the register's address and a mask value that contains zeroed bits wherever the hardware specification indicates that a non-writeable bit exists. A writeable bit can be defined as a bit that reads back what was written.
  • An “On Chip RAM Information Table” can also be utilized with the POST in the form of an array for storing a word size (in 32-bit unsigned long values), number of words, and a mask for each entry in each on-chip RAM.
  • the mask can include two unsigned long values with zeroed bits where no storage exists.
  • Such a format can be utilized to determine the actual width of an entry in the RAM when the RAM has a non-DWORD word width.
  • An internal buffer for example, can be 34 bits wide, and is therefore listed as possessing 2 32-bit entries per word.
  • the MS mask can be set, however, to 0x00000003 to indicate that only two bits in the MS 32-bit entry are real.
  • the top level POST program simply calls the CPU initialization program and then calls for a POST.
  • the POST can verify the functionality of the hardware in the following order: 1. Test Power-On Reset (POR) values of registers; 2. Test Write/Read capabilities of registers; 3. Test Interrupts; 4. Test On Chip Memory; 5. Test Off-Chip Memory; and 6. Run any automated tests existing in the hardware design (i.e., referred to here as an RTEST).
  • POR Test Power-On Reset
  • the “GoBitTable” can be utilized.
  • the POST will also test reserved register locations. Ideally these would read back zero and would not return what is written. For each address location in each register block, the following algorithm can be followed:
  • An interrupt verification function can be implemented in accordance with an embodiment, which masks and clears all interrupts and sets the interrupt polarity to high.
  • the interrupt verification function can then register an interrupt handler (IntISR( )) function with the compiler, call a function (PostTriggerlnt( )) to force each interrupt, and then reregister the “real” ISRs for actual firmware operation.
  • the PostTriggerlnt( ) function may cause an interrupt by setting up a “watch dog” timer interrupt to trigger an interrupt signal.
  • the IntISR( ) function sets a flag to show which interrupt occurred and then masks and clears the processor's interrupt logic.
  • An On-Chip Memory Verification can be implemented as a function that can test the on-chip memories specified in the hardware specification.
  • the On-Chip Memory Verification function can cycle through each on-chip memory and performs the following several tests, including writing incrementing or decrementing byte values to every location, then read back and verify. Other tests include, for example, writing 0xAAAAAAAA to every location, and then reading back and verifying. Another test can include writing 0x55555555 to every location, then read back and verify. In the first three tests the memory location directly below and above the indicated memory block space is also written and read to verify that it does NOT contain valid memory.
  • An on-chip memory verification function can be utilized to write or read a single on-chip memory location. Such a function when reading compares the value with the expected value (i.e., a parameter). This returns a FAIL message or command if the address is valid. The read value does not compare, however, if the address is invalid. The case, the data is compared.
  • the expected value i.e., a parameter
  • the Off-Chip Memory Verification function can perform a particular number of operations. First Off-Chip Memory locations in the window can be written, as specified by auto-generated write test table entries. Second, the Off-Chip Memory values can be read and compared using the configurations designed according to step one above. Crosstalk in the off-chip data lines can be checked with an operation that performs a write of traveling 1's to the off-chip memory starting at location zero. Finally, the off-chip memory values can be read and compared to the off-chip memory values written via step 3 listed above.
  • Hardware auto-test (RTEST) logic can be implemented as hardware designed specifically to test a hardware block automatically.
  • the RTEST portion of the POST simply sets up the RTEST logic and then starts the hardware test.
  • the POST code handles any interrupts generated by the RTEST logic. Any of the aforementioned tests may generate POST warnings or failures. Warnings will not stop the POST, but can cause the POST to return a nonzero value. Errors can halt the POST function and cause the firmware to trap.
  • embodiments of the present invention are directed toward methods and systems for verifying a hardware specification of integrated circuit (IC) designs.
  • Embodiments also include methods and systems for automatically verifying a hardware design based on a hardware specification document.
  • a plurality of predefined elements can be designed within a hardware specification document, such that the hardware specification document provides a hardware design for a hardware device.
  • the predefined elements can be stored within a database of hardware components, wherein each predefined element of the predefined elements is associated with a hardware component of the hardware device. Physical components of the hardware device can be compared with the predefined elements maintained within the database of hardware components upon an initial power-up of the hardware device in order to verify that the hardware device functions according to the hardware specification document.
  • An RTL auto-generation utility or module generally auto-generates define statements utilized by the RTL code to decode and configure the hardware memories and registers.
  • the software auto-generation utility or module auto-generates the same define statements utilized by the software code.
  • the POST software auto-generation utility or module as indicated earlier, can then auto-generate table-based tests that can verify the accessibility and correctness of the on-chip memories, off-chip memories, and registers as specified in the IC specification document.
  • modules can be typically implemented as a collection of routines and data structures that performs particular tasks or implements a particular abstract data type. Modules can be composed of two parts. First, a software module may list the constants, data types, variable, routines and the like that can be accessed by other modules or routines. Second, a software module can be configured as an implementation, which can be private (i.e., accessible perhaps only to the module), and that contains the source code that actually implements the routines or subroutines upon which the module is based. Thus, for example, the term module, as utilized herein can refer to a software module(s) or implementations thereof. Such modules can be utilized separately or together to form a program product that can be implemented through signal-bearing media, including transmission media and recordable media.
  • Suitable modules which can be implemented in accordance with embodiments of the present invention include a comparing module, a testing module, an RTL auto-generation module, a software auto-generation module, and the like.
  • the comparing module can automatically compare physical components of the hardware device with the predefined elements maintained within the database of hardware components upon an initial power-up of the hardware device, in order to verify that the hardware device functions according to the hardware specification document.
  • the testing module can automatically force the hardware device to fail if the hardware device does not comply with the hardware specification document, in response to automatically comparing physical components of the hardware device with the predefined elements maintained within the database of the hardware components upon an initial power-up of the hardware device.
  • the RTL auto-generation module can generate define statements utilized by an RTL code to decode and configure at least one hardware memory and at least one register thereof.
  • the software auto-generation module can auto-generate the same set of define statements utilized by the software code thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Methods and systems for automatically verifying a hardware design based on a hardware specification document. Hardware descriptions to be designed according to a hardware specification document are created. A document writer can follow a specified procedure including the use of register mao tables, address map tables and register descriptions to create the hardware descriptions. Flags are embedded in the document which document is then saved for use by internal/external engineers. The used document, which has been saved as a text-only file, is read by a document parsing utility which creates a database of hardware components. Physical components of the hardware device can then be compared with elements maintained within the database upon an initial power-up of the hardware device. RTL auto-generation and software auto-generation modules can be used to ensure that the RTL hardware description complies with the hardware specification.

Description

TECHNICAL FIELD
Embodiments generally relate to hardware design verification methods and systems. Embodiments also relate to methods and systems for verifying integrated circuit designs. Embodiments additionally relate to Power On Self Test (POST) techniques and devices.
BACKGROUND OF THE INVENTION
In many instances it can be necessary to implement hardware design verification methods and systems. The objective of design verification is to ensure that errors are absent from a design. Modern integrated circuit (IC) manufacturing technology is enabling IC designers to place millions of transistors on a single IC. Design complexity is doubling every 12–18 months, which causes design verification complexity to increase at an exponential rate. In addition, competitive pressures are putting increased demands on reducing time to market.
Today's design flow begins with a hardware specification document for the design. The engineer then implements the design in a language model, typically a Hardware Description Language (HDL). Such a model can be utilized to discover incorrect input/output (I/O) behavior through a stimulus in expected “results out” paradigm at the top level of the design.
By far the most popular method of functional verification today is simulation-based functional verification, which is widely utilized within the digital design industry as a technique for detecting defects within hardware designs. A very wide variety of products are available in the market to support simulation-based verification methodologies. However, a fundamental problem with conventional simulation-based verification approaches is that they are vector and test bench limited.
Simulation-based verification is driven by a test bench that explicitly generates the vectors to achieve stimulus coverage and also implements the checking mechanism. Test benches create a fundamental bottleneck in simulation-based functional verification. In order to verify a design hierarchy level, a test bench must be generated for it. This creates verification overhead for coding and debugging the test bench. Hence, a significant amount of expensive design and verification engineering resources are needed to produce results in a cumbersome and slow process.
Several methods have been attempted by Electronic Design Automation (EDA) companies today in order to address the shortcomings of simulation. However, none of these attempts address this fundamental limitation of the process. For example, simulation vendors have tried to meet the simulation throughput challenge by increasing the performance of hardware and software simulators thereby allowing designers to process a greater number of vectors in the same amount of simulation time. While this does increase stimulus coverage, the results are incremental. The technology is not keeping pace with the required growth rate and the verification processes are lagging in achieving the required stimulus coverage.
Formal verification is another class of tools that has entered the functional verification arena. These tools rely on mathematical analysis rather than simulation of the design. The strong selling point of formal verification is the fact that the results hold true for all possible input combinations to the design. However, in practice this high level of stimulus coverage has come at the cost of both error coverage and particularly usability. While some formal techniques are available, they are not widely used because they typically require the designer to know the details of how the tool works in order to operate it. Formal verification tools generally fall into two classes: (1) equivalence checking, and (2) model checking.
Equivalence checking is a form of formal verification that provides designers with the ability to perform RTL-to-gate and gate-to-gate comparisons of a design to determine if they are functionally equivalent. Importantly, however, equivalence checking is not a method of functional verification. Rather, equivalence checking merely provides an alternate solution for comparing a design representation to an original golden reference. It does not verify the functionality of the original golden reference for the design. Consequently, the original golden reference must be functionally verified using other methods.
Model checking is a functional verification technology that requires designers to formulate properties about the design's expected behavior. Each property is then checked against an exhaustive set of functional behaviors in the design. The limitation of this approach is that the designer is responsible for exactly specifying the set of properties to be verified. The property specification languages are new and obscure. Usually the technology runs into capacity problems and the designer has to engage with the tools to solve the problems.
There are severe limits on the size of the design and the scope of problems that can be analyzed. For example, the designer does not know which properties are necessary for complete analysis of the design. Further, specifying a large number of properties does not correlate well with better error coverage. Consequently, model checking has proven to be very difficult to use and has not provided much value in the verification process.
In view of the foregoing it would be desirable to create a verification methodology to create high quality designs and to increase the productiveness of design engineers by minimizing the tool setup effort and report processing effort. It is particular desirable to implement a method and system for hardware design verification, which is automatic in nature, and is tied directly to the original hardware design specification at the time of an actual hardware Power On Self Test (POST).
BRIEF SUMMARY OF THE INVENTION
The following summary of the invention is provided to facilitate an understanding of some of the innovative features unique to the present invention and is not intended to be a full description. A full appreciation of the various aspects of the invention can be gained by taking the entire specification, claims, drawings, and abstract as a whole.
It is, therefore, one aspect of the present invention to provide improved hardware design verification methods and systems.
It is another aspect of the present invention to provide improved methods and systems for verifying electrical integrated circuit (IC) designs.
It is yet another aspect of the present invention to provide accurate methods and systems for verifying a hardware specification of integrated circuit (IC) designs.
The aforementioned aspects of the invention and other objectives and advantages can now be achieved as described herein. Methods and systems for automatically verifying a hardware design based on a hardware specification document are disclosed herein. A plurality of predefined elements can be designed within a hardware specification document, wherein the hardware specification document provides a hardware design for a hardware device. The plurality of predefined elements can be stored within a database of hardware components, wherein each predefined element of the plurality of predefined elements is associated with a hardware component of the hardware device. Physical components of the hardware device can be compared with the predefined elements maintained within the database of hardware components upon an initial power-up of the hardware device in order to verify that the hardware device functions according to the hardware specification document.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying figures, in which like reference numerals refer to identical or functionally-similar elements throughout the separate views and which are incorporated in and form part of the specification, further illustrate embodiments of the present invention.
FIG. 1 illustrates a block diagram of a data processing system in which an embodiment of the present invention may be implemented;
FIG. 2 illustrates a high-level flowchart depicting logical operational steps, which may be followed to implement an embodiment of the present invention;
FIG. 3 illustrates a high-level flowchart depicting continuing logical operational steps of the flowchart depicted in FIG. 2, in accordance with an embodiment of the present invention;
FIG. 4 illustrates a block diagram of a hardware interrupt system, which can be implemented in accordance with an embodiment of the present invention;
DETAILED DESCRIPTION OF THE INVENTION
The particular values and configurations discussed in these non-limiting examples can be varied and are cited merely to illustrate an embodiment of the present invention and are not intended to limit the scope of the invention.
With reference now to the figures, and in particular with reference to FIG. 1, a block diagram of a data processing system 100 in which the present invention may be implemented is illustrated. The depicted example is not meant to imply architectural limitations with respect to embodiments of the present invention, but is presented for general illustrative and edification purposes only.
Data processing system 100 can employ a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Micro Channel and ISA may be used. A Processor 102 and a main memory 104 can be connected to PCI local bus 106 through PCI bridge 108. PCI bridge 108 also may include an integrated memory controller and cache memory for processor 102. Alternatively, a controller 103 can communicate with PCI local bus 106 to provide additional architectural support. Controller 103 may be utilized in place of to complement an integrated memory controller and cache memory for processor 102.
Additional connections to PCI local bus 106 may be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter 110, host bus adapter 112, and expansion bus interface 114 are connected to PCI local bus 106 by direct component connection. In contrast, audio adapter 116, graphics adapter 118, and audio/video adapter (A/V) 119 are connected to PCI local bus 106 by add-in boards inserted into expansion slots. Expansion bus interface 114 provides a connection for a keyboard and mouse adapter 120, modem 122, and additional memory 124. Host bus adapter 112 provides a connection for hard disk drive 126, tape drive 128, and CD-ROM 130 in the depicted example.
Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors. The depicted example includes four loads on the mother board and three expansion slots. Those of ordinary skill in the art will appreciate that the hardware in FIG. 1 may vary. For example, other peripheral devices, such as optical disc drives and the like may be used in addition to or in place of the hardware depicted in FIG. 1.
Turning now to FIG. 2, a high-level flowchart 200 depicting logical operational steps is illustrated, which may be followed to implement an embodiment of the present invention. FIG. 3 illustrates a high-level flowchart 300 depicting continuing logical operational steps of the flowchart 200 depicted in FIG. 2, in accordance with an embodiment of the present invention. In FIGS. 2 and 3, like parts or elements are indicated by identical reference numerals, such that flowcharts 200 and 300 represent a single continuous flowchart of logical operation steps. FIGS. 2 and 3 together generally illustrate a methodology that includes document parsing software utility, routines, and/or subroutines which search for predefined flags and formatting in a hardware specification document and extracts the hardware information from the hardware specification document.
The document parsing software utility generates a database can be utilized by other utilities. The methodology of FIGS. 2 and 3 can also be utilized to implement an RTL code auto-generation utility that reads the database and creates valid RTL hardware description code that defines the storage elements in the hardware. Additionally, a software code auto-generation utility can be utilized to read the database and create valid software code that defines accesses to the storage elements in the hardware, and which also can generate hardware specification tables, which can be utilized by a Power On Self Test (POST) function, which is described in further detail herein.
Thus, as depicted at block 202, the process is initiated. Thereafter, as illustrated at block 204, a document writer can follow a specified procedure to created detailed descriptions of the hardware to be designed according to the hardware specification document. Such specified procedure includes the use of specified formats for register map tables, address map tables and register description sections of the hardware specification document. Next, as described at block 206, invisible flags are embedded in the document to be utilized by the document reader script, which will be described in more detail herein. Thereafter, as depicted at block 208, the document can be saved and used by internal and external engineers as formatted. Next, as illustrated at block 210, the document can be saved as a text-only document for use by the document reader script.
Thereafter, as illustrated at block 212, a document parsing software utility reads the document(s), and creates, as depicted at block 214, a database of all storage elements in the document that are visible to a microcontroller, such as, for example, controller 103 of data processing system 100 illustrated in FIG. 1. Next, as depicted at block 216, an RTL code auto-generator can be utilized to create HDL code file(s). The acronym “HDL” generally refers to “Hardware Description Language”. The process continues, as indicated at continuation block 218 in FIGS. 2 and 3.
As illustrated thereafter at block 220 of FIG. 3, the software code auto-generator can create software file(s) that contain definitions and declarations for every storage element and for every bit field within registers, strictly as defined in the hardware document specification. Next, as indicated at block 222, the software code auto-generator can create tables utilized by Power-On Self Test Code to check the hardware upon power-up. The use of the auto-generated software code ensures that the RTL hardware description complies with the hardware specification document.
In accordance with one embodiment of the present invention, two code auto-generators can be implemented, including the hardware RTL code generator and the software code generator. Block 216, for example, refers to hardware code. Blocks 220222, on the other hand, refer to software code which is not RTL code. In accordance with one possible embodiment of the present invention, such code may be C or C++ code. It can of course be appreciated by those skilled in the art that C or C++ code is not considered a limiting feature of the present invention, because other types of programming code can also be utilized to implement embodiments.
The use of the auto-generated software code for storage elements and the Power-On Self Test tables causes the software to fail if the hardware does not comply with the specification document. Thus, as depicted at block 224, a test can be performed to determine if the hardware complies with the specification document. If so, then the hardware design is verified, as indicated at block 228. If not, then the hardware design fails, as indicated at block 226. The process then terminates, as depicted at block 230.
When implementing a method and/or system for verifying hardware designs against a hardware specification document, files can be organized according to a layered structured. Such a layered structure can be implemented as firmware and may include hardware drivers, which are based on code that actually manipulates hardware register bits or memory. These drivers can be contained in the context of one or more files that hold only code that affects the specific hardware in question. A hardware driver generally is composed of both initialization code, and the actual driver code. The layered structure can also include configuration code that loads data and then acts as a ROM (read only memory) for the remainder of the firmware operations.
Additionally, such a layer structure can include definitions that are specific to an external standard, such as, for example, the SAS or SCSI bus standards. These definitions can be contained in header files that hold definitions specific to that standard. The layered structure can also include operating system header and code files that exist to contain definitions and declarations utilized by a kernel to control the general flow of the software. These include all general code files that contain common definitions and declarations. Additionally, the layer structure can include development code files are files that contain code utilized for debugging. Code that facilitates retargettable Output for tracing or any other functions that are not part of the actual firmware can be contained within such code files.
In accordance with an embodiment of the present invention, the interface for each separately specified block of hardware can be contained within its own code file set. The intent of this action is to provide a hardware abstraction layer so that if any part of the hardware is upgraded or redesigned in a later generation of the chip, code changes are limited to only the files owning that hardware interface.
The files can contain the following: <HW Block Name>.h. This file contains the interface between the hardware and the rest of the firmware. Such a file can include prototypes for any functions that are owned by the hardware interface and that are visible to other parts of the firmware (e.g., a driver API). This also includes ‘extern’ declarations for any constants that are owned by this hardware interface but that must be visible elsewhere.
The files can also contain <HW Block Name>.c. This file contains the code that directly manipulates the hardware. This includes declarations for all private functions, variables, block-owned registers, and constants. This also includes definitions for all public functions and for constants declared ‘extern’ in the .h file.
TABLE 1
Hardware Driver Files
Hardware Block Code File Header File
Ouray Register Definitions <none> OurayNN_reg.h
Saspen Protocol Engine Register <none> Saspen_NN_reg.h
Definitions
Buffer Controller bc.c bc.h
Microprocessor Interface mpu.c mpu.h
RAM Test rtest.c rtest.h
Saspen Sub-Blocks
Saspen Command Buffer cbuf.c cbuf.h
Saspen Data Buffer dbuf.c dbuf.h
Saspen Frame Buffer fbuf.c fbuf.h
Saspen Global saspen.c saspen.h
Saspen Header Buffer hbuf.c hbuf.h
Saspen Receive Data Path dpt.c dpt.h
Saspen RX WCS rxwcs.c rxwcs.h
Saspen Transmit Buffer txb.c txb.h
Saspen Transmit Data Path txdp.c txdp.h
Saspen Transmit Request txreq.c txreq.h
Saspen TX WCS txwcs.c txwcs.h
Host Sub-Blocks
Command Automation Processor cap.c cap.h
Command FIFO cfifo.c cfifo.h
Context Cache cc.c cc.h
Disk Thread Retrieval Channel dtrc.c dtrc.h
Free Pointer Manager fpm.c fpm.h
Host Global host.c host.h
Host Thread Retrieval Channels htrc.c htrc.h
Pending Write Table pwt.c pwt.h
Prefetch Engine peng.c peng.h
Read Context Manager rcm.c rcm.h
Read DMA rdma.c rdma.h
Receive Frame Router rxfr.c rxfr.h
Status Context Manager scm.c scm.h
Status Thread Retrieval Channel strc.c strc.h
Tag Manager tag.c tag.h
Transfer Control FIFO tcfifo.c tcfifo.h
Write Context Manager wcm.c wcm.h
Write DMA wdma.c wdma.h
Disk Formatter Sub-Blocks
Data Channel dchan.c dchan.h
Data Path dp.c dp.h
Disk Formatter Global df.c df.h
Disk Formatter Writeable Control Store wcs.c wcs.h
Error Correction Engine ecc.c ecc.h
Release Control rel.c rel.h
RG/WG Sequencer rgwg.c rgwg.h
Sector Generation sec.c sec.h
Servo Positioning Table spt.c spt.h
Skip Mask Table smt.c smt.h
Start Of Sector sos.c sos.h
Transfer Control Table tct.c tct.h
In accordance with an embodiment, code architecture can be implemented to include an infinite loop, event handlers, and interrupt handlers. The kernel code which implements the architecture can be contained in the main.c and global.c/h files. This includes event handling code and various other general utilities that are used by other code but are not hardware-specific.
A Power On Self Test (POST) can be implemented in accordance with embodiments of the present invention and may possess special capabilities due to a UNIX executable aspect of the compiled code that would not be available if this were truly loadable firmware. A number of data structures can be used in the POST, including a Register Block Space Table, which comprises an Array storing the size of the address space for each register block. Such a table can be utilized to test the reserved spaces for unspecified storage elements. Registered addresses can be also utilized in the POST as a list of number defined literals utilized in other tables. A “Go Mask Table” can also be utilized with the post, which comprises an array that contains an entry for every register that contains a GO bit.
Each entry will contain the address of the register and a mask with zeroed bits where GO bits exist. Go bits are specified in the hardware specifications by the letters “Go” at the end of the bit name. Additional data structures include a Power-On Reset Value Table (POR VTable) and a “Write Bits table.” A POR VTable can be implemented as an array organized by register within register block. Each entry contains the register's address, the POR specification for the register, and a mask value that contains zeroed bits wherever the hardware specification indicates that the POR value is unknown. A “Write Bits Table” can be configured as an array organized by register within register block. Each entry can contain the register's address and a mask value that contains zeroed bits wherever the hardware specification indicates that a non-writeable bit exists. A writeable bit can be defined as a bit that reads back what was written.
An “On Chip RAM Information Table” can also be utilized with the POST in the form of an array for storing a word size (in 32-bit unsigned long values), number of words, and a mask for each entry in each on-chip RAM. The mask can include two unsigned long values with zeroed bits where no storage exists. Such a format can be utilized to determine the actual width of an entry in the RAM when the RAM has a non-DWORD word width. An internal buffer, for example, can be 34 bits wide, and is therefore listed as possessing 2 32-bit entries per word. The MS mask can be set, however, to 0x00000003 to indicate that only two bits in the MS 32-bit entry are real.
In general, the top level POST program simply calls the CPU initialization program and then calls for a POST. The POST can verify the functionality of the hardware in the following order: 1. Test Power-On Reset (POR) values of registers; 2. Test Write/Read capabilities of registers; 3. Test Interrupts; 4. Test On Chip Memory; 5. Test Off-Chip Memory; and 6. Run any automated tests existing in the hardware design (i.e., referred to here as an RTEST).
In order to handle exceptions to the standard write-then-read verification test, and in order to allow the skipping of this test on bits where toggling would be a critical error, such as “Go” bits, the “GoBitTable” can be utilized. The POST will also test reserved register locations. Ideally these would read back zero and would not return what is written. For each address location in each register block, the following algorithm can be followed:
    • 1. If the location exists in the Avoid table then skip it and continue to the next location.
    • 2. Set the Go mask to 0xFFFFFFFF.
    • 3. If the location contains a register then get the WriteBits mask from the Write Bits Table.
    • 4. Else set the Write Bits mask to 0xFFFFFFFF.
    • 5. If the location is in the Go Mask table then get the Go mask value.
    • 6. If the Write Bits mask is zero then continue to the next location.
    • 7. Read the register's current value.
    • 8. XOR the read value with the Write Bits mask; AND the results with the Go mask.
    • 9. Write to the register.
    • 10. Read the register, AND this value with the Write Bits and Go mask.
    • 11. Check the masked read value with the masked write value.
    • 12. If the values do not match then FAIL to log file.
    • 13. If the read value is non-zero and no register exists then FAIL to log file.
An interrupt verification function can be implemented in accordance with an embodiment, which masks and clears all interrupts and sets the interrupt polarity to high. The interrupt verification function can then register an interrupt handler (IntISR( )) function with the compiler, call a function (PostTriggerlnt( )) to force each interrupt, and then reregister the “real” ISRs for actual firmware operation. The PostTriggerlnt( ) function may cause an interrupt by setting up a “watch dog” timer interrupt to trigger an interrupt signal. The IntISR( ) function sets a flag to show which interrupt occurred and then masks and clears the processor's interrupt logic.
An On-Chip Memory Verification can be implemented as a function that can test the on-chip memories specified in the hardware specification. The On-Chip Memory Verification function can cycle through each on-chip memory and performs the following several tests, including writing incrementing or decrementing byte values to every location, then read back and verify. Other tests include, for example, writing 0xAAAAAAAA to every location, and then reading back and verifying. Another test can include writing 0x55555555 to every location, then read back and verify. In the first three tests the memory location directly below and above the indicated memory block space is also written and read to verify that it does NOT contain valid memory.
An on-chip memory verification function can be utilized to write or read a single on-chip memory location. Such a function when reading compares the value with the expected value (i.e., a parameter). This returns a FAIL message or command if the address is valid. The read value does not compare, however, if the address is invalid. The case, the data is compared.
The Off-Chip Memory Verification function can perform a particular number of operations. First Off-Chip Memory locations in the window can be written, as specified by auto-generated write test table entries. Second, the Off-Chip Memory values can be read and compared using the configurations designed according to step one above. Crosstalk in the off-chip data lines can be checked with an operation that performs a write of traveling 1's to the off-chip memory starting at location zero. Finally, the off-chip memory values can be read and compared to the off-chip memory values written via step 3 listed above.
Hardware auto-test (RTEST) logic can be implemented as hardware designed specifically to test a hardware block automatically. The RTEST portion of the POST simply sets up the RTEST logic and then starts the hardware test. The POST code handles any interrupts generated by the RTEST logic. Any of the aforementioned tests may generate POST warnings or failures. Warnings will not stop the POST, but can cause the POST to return a nonzero value. Errors can halt the POST function and cause the firmware to trap.
Based on the foregoing, it can be appreciated that embodiments of the present invention, as disclosed herein, are directed toward methods and systems for verifying a hardware specification of integrated circuit (IC) designs. Embodiments also include methods and systems for automatically verifying a hardware design based on a hardware specification document. As indicated herein, a plurality of predefined elements can be designed within a hardware specification document, such that the hardware specification document provides a hardware design for a hardware device.
The predefined elements can be stored within a database of hardware components, wherein each predefined element of the predefined elements is associated with a hardware component of the hardware device. Physical components of the hardware device can be compared with the predefined elements maintained within the database of hardware components upon an initial power-up of the hardware device in order to verify that the hardware device functions according to the hardware specification document.
An RTL auto-generation utility or module generally auto-generates define statements utilized by the RTL code to decode and configure the hardware memories and registers. The software auto-generation utility or module auto-generates the same define statements utilized by the software code. The POST software auto-generation utility or module, as indicated earlier, can then auto-generate table-based tests that can verify the accessibility and correctness of the on-chip memories, off-chip memories, and registers as specified in the IC specification document.
Note that embodiments of the present invention can be implemented in the context of a “module” or “modules”. In the computer programming arts, for example, a module can be typically implemented as a collection of routines and data structures that performs particular tasks or implements a particular abstract data type. Modules can be composed of two parts. First, a software module may list the constants, data types, variable, routines and the like that can be accessed by other modules or routines. Second, a software module can be configured as an implementation, which can be private (i.e., accessible perhaps only to the module), and that contains the source code that actually implements the routines or subroutines upon which the module is based. Thus, for example, the term module, as utilized herein can refer to a software module(s) or implementations thereof. Such modules can be utilized separately or together to form a program product that can be implemented through signal-bearing media, including transmission media and recordable media.
Examples of suitable modules which can be implemented in accordance with embodiments of the present invention include a comparing module, a testing module, an RTL auto-generation module, a software auto-generation module, and the like. The comparing module, for example, can automatically compare physical components of the hardware device with the predefined elements maintained within the database of hardware components upon an initial power-up of the hardware device, in order to verify that the hardware device functions according to the hardware specification document.
The testing module, for example, can automatically force the hardware device to fail if the hardware device does not comply with the hardware specification document, in response to automatically comparing physical components of the hardware device with the predefined elements maintained within the database of the hardware components upon an initial power-up of the hardware device. The RTL auto-generation module can generate define statements utilized by an RTL code to decode and configure at least one hardware memory and at least one register thereof. The software auto-generation module can auto-generate the same set of define statements utilized by the software code thereof.
The embodiments and examples set forth herein are presented to best explain the present invention and its practical application and to thereby enable those skilled in the art to make and utilize the invention. Those skilled in the art, however, will recognize that the foregoing description and examples have been presented for the purpose of illustration and example only. Other variations and modifications of the present invention will be apparent to those of skill in the art, and it is the intent of the appended claims that such variations and modifications be covered.
The description as set forth is not intended to be exhaustive or to limit the scope of the invention. Many modifications and variations are possible in light of the above teaching without departing from the scope of the following claims. It is contemplated that the use of the present invention can involve components having different characteristics. It is intended that the scope of the present invention be defined by the claims appended hereto, giving full cognizance to equivalents in all respects.

Claims (20)

1. A method for automatically verifying a hardware design based on a hardware specification document, said method comprising the steps of:
designating a plurality of predefined elements within a hardware specification document, wherein said hardware specification document provides a hardware design for a hardware device;
storing said plurality of predefined elements within a database of hardware components, wherein each predefined element of said plurality of predefined elements is associated with a hardware component of said hardware device;
embedding said plurality of predefined elements within said hardware specification document preparatory to storing said predefined elements in said database, wherein said plurality of predefined element comprise flags which can be utilized by a document reader script;
creating at least one RTL Hardware Description code file from said database, said RTL Hardware description code file(s) defining said predefined elements stored in said database; and
automatically comparing physical components of said hardware device with said predefined elements maintained within said database of said hardware components upon an initial power-up of said hardware device, in order to verify that said hardware device functions according to said hardware specification document.
2. The method of claim 1 further comprising the step of:
configuring said hardware specification document to include a specified format which is readable by a document parsing utility for storing said plurality of predefined elements in said database, wherein said specified format includes at least one of the following sections: register map tables, address map tables, and register descriptions.
3. The method of claim 1 further comprising the step of:
saving said document including said embedded plurality of predefined elements for use by Internal/external engineers as formatted preparatory to storing said plurality of predefined elements in said database.
4. The method of claim 3 further comprising the method steps of:
using said saved document as formatted; and
saving said used document to a text-only document which can be utilized said document reader script.
5. The method of claim 4 wherein storing said plurality of predefined elements in said database of hardware components comprises reading said saved document using a document parsing utility.
6. The method of claim 1 further comprising the step of:
dynamically creating a plurality of tables for utilization by a POST to verifying said hardware device upon a power up of said hardware device.
7. The method of claim 1 further comprising the step of:
automatically forcing said hardware device to fail if said hardware device does not comply with said hardware specification document, in response to automatically comparing physical components of said hardware device with said predefined elements maintained within said database of said hardware components upon an initial power-up of said hardware device.
8. A system for automatically verifying a hardware design based on a hardware specification document, said system comprising:
a plurality of predefined elements designated within a hardware specification document, wherein said hardware specification document provides a hardware design for a hardware device;
a database of hardware components for storing said plurality of predefined elements, wherein each predefined element of said plurality of predefined elements is associated with a hardware component of said hardware device;
wherein said plurality of predefined elements are embedded within said hardware specification document preparatory to storing said predefined elements in said database, wherein said plurality of predefined elements comprise flags which can be utilized by a document readerscript;
an RTL auto-generation module for creating at least one RTL Hardware description code from said database, said RTL Hardware description code file(s) defining said predefined elements stored in said database; and
a comparing module for automatically comparing physical components of said hardware device with said predefined elements maintained within said database of said hardware components upon an initial power-up of said hardware device, in order to verify that said hardware device functions according to said hardware specification document.
9. The system of claim 8 further comprising a document parsing utility for storing said plurality of predefined elements in said database.
10. The system of claim 9 wherein said hardware specification document comprises a specified format which is readable by said document parsing utility, wherein said specified format includes at least one of the following sections: register map tables, address map tables, and register descriptions.
11. The system of claim 8 wherein said document including said embedded plurality of predefined elements comprises a saved document for use by internal/external engineers as formatted preparatory to storing said predefined elements in said database.
12. The system of claim 11 wherein said used document is saved as a text-only document which can be utilized by said document reader script.
13. The system of claim 12 wherein said database of hardware components comprises a database of storage elements visible to a microcontroller and further comprising a plurality of files automatically generated, which contain definitions and declarations for said storage elements and for every bit field within registers thereof.
14. The system of claim 8 further comprising a plurality of tables dynamically created for utilization by a POST to verifying said hardware device upon a power up of said hardware device.
15. The system of claim 8 further comprising a testing module for automatically forcing said hardware device to fail if said hardware device does not comply with said hardware specification document, in response to automatically comparing physical components of said hardware device with said predefined elements maintained within said database of said hardware components upon an initial power-up of said hardware device.
16. The system of claim 8 wherein said RTL auto-generation module comprises an RTL auto-generation utility for generating define statements utilized by an RTL code to decode and configure at least one hardware memory and at least one register thereof.
17. The system of claim 8 further comprising a software auto-generation utility that auto-generates a same set of define statements utilized by a software code thereof.
18. A system for automatically verifying a hardware design based on a hardware specification document, said system comprising:
a plurality of predefined elements designated within a hardware specification document, wherein said hardware specification document provides a hardware design for a hardware device;
a database of hardware components for storing said plurality of predefined elements, wherein each predefined element of said plurality of predefined elements is associated with a hardware component of said hardware device;
a document parsing utility storing said plurality of predefined elements in said database, wherein said hardware specification document comprises a specified format which is readable by said document parsing utility, wherein said specified format includes at least one of the following sections: register map tables, address map tables, and register descriptions;
an RTL auto-generation module for creating at least one RTL Hardware description code from said database, said RTL Hardware description code file(s) defining said predefined elements stored in said database;
a comparing module for automatically comparing physical components of said hardware device with said predefined elements maintained within said database of said hardware components upon an initial power-up of said hardware device, in order to verify that said hardware device functions according to said hardware specification document; and
wherein said plurality of predefined elements are embedded within said hardware specification document preparatory to storing said plurality of predefined elements in said database, such that said plurality of predefined elements comprise invisible flags which can be utilized by a document reader script.
19. The system of claim 18 further comprising:
a plurality of tables dynamically created for utilization by a POST to verifying said hardware device upon a power up of said hardware device; and
a testing module for automatically forcing said hardware device to fail if said hardware device does not comply with said hardware specification document, in response to automatically comparing physical components of said hardware device with said predefined elements maintained within said database of said hardware components upon an initial power-up of said hardware device.
20. The system of claim 18 wherein said RTL auto-generation module is arranged for generating define statements utilized by an RTL code to decode and configure at least one hardware memory and at least one register thereof; and
further comprising a software auto-generation module that auto-generates a same set of define statements utilized by a software code thereof.
US10/624,347 2003-07-22 2003-07-22 Methods and systems for automatic verification of specification document to hardware design Expired - Lifetime US7096440B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/624,347 US7096440B2 (en) 2003-07-22 2003-07-22 Methods and systems for automatic verification of specification document to hardware design

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/624,347 US7096440B2 (en) 2003-07-22 2003-07-22 Methods and systems for automatic verification of specification document to hardware design

Publications (2)

Publication Number Publication Date
US20050022058A1 US20050022058A1 (en) 2005-01-27
US7096440B2 true US7096440B2 (en) 2006-08-22

Family

ID=34079988

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/624,347 Expired - Lifetime US7096440B2 (en) 2003-07-22 2003-07-22 Methods and systems for automatic verification of specification document to hardware design

Country Status (1)

Country Link
US (1) US7096440B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080109772A1 (en) * 2006-10-24 2008-05-08 Pokorny William F Method and system of introducing hierarchy into design rule checking test cases and rotation of test case data
US8522176B2 (en) * 2010-05-11 2013-08-27 Synopsys, Inc. Method of recording and replaying call frames for the testbench
US8589841B2 (en) 2012-04-05 2013-11-19 International Business Machines Corporation Automatic parity checking identification
US20170017506A1 (en) * 2008-09-04 2017-01-19 Synopsys, Inc. Software and Hardware Emulation System
US9569582B2 (en) 2014-01-03 2017-02-14 International Business Machines Corporation Template matching for resilience and security characteristics of sub-component chip designs

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4251964B2 (en) * 2003-11-10 2009-04-08 富士通マイクロエレクトロニクス株式会社 Verification device, verification method, and program
US8230263B2 (en) * 2007-09-19 2012-07-24 Lsi Corporation Automated specification based functional test generation infrastructure
JP5163308B2 (en) * 2008-06-23 2013-03-13 富士通セミコンダクター株式会社 IP model generation device, IP model generation method, and IP model generation program
US9330419B2 (en) 2012-05-01 2016-05-03 Oracle International Corporation Social network system with social objects
CN116382992B (en) * 2023-05-16 2023-09-19 上海孤波科技有限公司 Hardware testing method and device, electronic equipment and storage medium
CN117150998B (en) * 2023-10-31 2024-01-19 上海合见工业软件集团有限公司 Hardware module equivalence verification system

Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5452227A (en) * 1991-11-13 1995-09-19 Westinghouse Elec. Corp. Method and apparatus for converting a programmable logic device designed into a selectable target gate array design
US5600579A (en) 1994-07-08 1997-02-04 Apple Computer, Inc. Hardware simulation and design verification system and method
US5995736A (en) * 1997-07-24 1999-11-30 Ati Technologies, Inc. Method and system for automatically modelling registers for integrated circuit design
US6052524A (en) * 1998-05-14 2000-04-18 Software Development Systems, Inc. System and method for simulation of integrated hardware and software components
US6249899B1 (en) * 1999-03-23 2001-06-19 Hewlett Packard Company System and method for detecting pass FETs
US6321365B1 (en) * 1999-01-26 2001-11-20 Hewlett-Packard Company System and method for detecting storage nodes that are susceptible to charge sharing
US6360308B1 (en) 1998-09-30 2002-03-19 Lsi Logic Corporation Buffer controller
US6405347B1 (en) * 1999-06-30 2002-06-11 Hewlett-Packard Company Method and apparatus for determining the maximum permitted and minimum required width of a feedback FET on a precharge node
US6430652B1 (en) 1997-12-30 2002-08-06 Lsi Logic Corporation Method and apparatus for streaming data in a data processing system
US6539523B1 (en) * 2000-05-08 2003-03-25 Real Intent, Inc. Automatic formulation of design verification checks based upon a language representation of a hardware design to verify the intended behavior of the hardware design
US6571375B1 (en) 2000-05-08 2003-05-27 Real Intent, Inc. Determining dependency relationships among design verification checks
US20040030876A1 (en) * 2002-08-07 2004-02-12 Qureshi Shiraz A. System and method for using a firmware interface table to dynamically load an ACPI SSDT
US6718522B1 (en) * 2000-08-15 2004-04-06 Hewlett-Packard Development Company, L.P. Electrical rules checker system and method using tri-state logic for electrical rule checks
US20040216077A1 (en) * 2003-04-28 2004-10-28 International Business Machines Corp. Method, system and program product for specifying and using a dial having a default value to configure a digital system described by a hardware description language (HDL) model
US6990643B1 (en) * 1999-05-13 2006-01-24 Hewlett-Packard Development Company, L.P. Method and apparatus for determining whether an element in an integrated circuit is a feedback element

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2565005B2 (en) * 1991-03-08 1996-12-18 富士通株式会社 Heterogeneous crystal synthesizer

Patent Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5452227A (en) * 1991-11-13 1995-09-19 Westinghouse Elec. Corp. Method and apparatus for converting a programmable logic device designed into a selectable target gate array design
US5600579A (en) 1994-07-08 1997-02-04 Apple Computer, Inc. Hardware simulation and design verification system and method
US5995736A (en) * 1997-07-24 1999-11-30 Ati Technologies, Inc. Method and system for automatically modelling registers for integrated circuit design
US6430652B1 (en) 1997-12-30 2002-08-06 Lsi Logic Corporation Method and apparatus for streaming data in a data processing system
US6052524A (en) * 1998-05-14 2000-04-18 Software Development Systems, Inc. System and method for simulation of integrated hardware and software components
US6360308B1 (en) 1998-09-30 2002-03-19 Lsi Logic Corporation Buffer controller
US6321365B1 (en) * 1999-01-26 2001-11-20 Hewlett-Packard Company System and method for detecting storage nodes that are susceptible to charge sharing
US6249899B1 (en) * 1999-03-23 2001-06-19 Hewlett Packard Company System and method for detecting pass FETs
US6990643B1 (en) * 1999-05-13 2006-01-24 Hewlett-Packard Development Company, L.P. Method and apparatus for determining whether an element in an integrated circuit is a feedback element
US6405347B1 (en) * 1999-06-30 2002-06-11 Hewlett-Packard Company Method and apparatus for determining the maximum permitted and minimum required width of a feedback FET on a precharge node
US6539523B1 (en) * 2000-05-08 2003-03-25 Real Intent, Inc. Automatic formulation of design verification checks based upon a language representation of a hardware design to verify the intended behavior of the hardware design
US6571375B1 (en) 2000-05-08 2003-05-27 Real Intent, Inc. Determining dependency relationships among design verification checks
US6718522B1 (en) * 2000-08-15 2004-04-06 Hewlett-Packard Development Company, L.P. Electrical rules checker system and method using tri-state logic for electrical rule checks
US20040030876A1 (en) * 2002-08-07 2004-02-12 Qureshi Shiraz A. System and method for using a firmware interface table to dynamically load an ACPI SSDT
US20040216077A1 (en) * 2003-04-28 2004-10-28 International Business Machines Corp. Method, system and program product for specifying and using a dial having a default value to configure a digital system described by a hardware description language (HDL) model

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080109772A1 (en) * 2006-10-24 2008-05-08 Pokorny William F Method and system of introducing hierarchy into design rule checking test cases and rotation of test case data
US7823103B2 (en) * 2006-10-24 2010-10-26 International Business Machines Corporation Method and system of introducing hierarchy into design rule checking test cases and rotation of test case data
US20170017506A1 (en) * 2008-09-04 2017-01-19 Synopsys, Inc. Software and Hardware Emulation System
US10713069B2 (en) * 2008-09-04 2020-07-14 Synopsys, Inc. Software and hardware emulation system
US8522176B2 (en) * 2010-05-11 2013-08-27 Synopsys, Inc. Method of recording and replaying call frames for the testbench
US8924912B2 (en) 2010-05-11 2014-12-30 Synopsys, Inc. Method of recording and replaying call frames for a test bench
US8589841B2 (en) 2012-04-05 2013-11-19 International Business Machines Corporation Automatic parity checking identification
US9569582B2 (en) 2014-01-03 2017-02-14 International Business Machines Corporation Template matching for resilience and security characteristics of sub-component chip designs

Also Published As

Publication number Publication date
US20050022058A1 (en) 2005-01-27

Similar Documents

Publication Publication Date Title
CN110603528B (en) Debugging system and method
US6678625B1 (en) Method and apparatus for a multipurpose configurable bus independent simulation bus functional model
US7962869B2 (en) Method and system for debug and test using replicated logic
KR100434240B1 (en) Apparatus and method for in-circuit emulation using high-level programming language
US10255400B1 (en) Debugging system and method
US20170115969A1 (en) System and method for automatically generating device drivers for run time environments
US7096440B2 (en) Methods and systems for automatic verification of specification document to hardware design
CN112417798B (en) Time sequence testing method and device, electronic equipment and storage medium
US6917998B1 (en) Reusable complex multi-bus system hardware prototype system
EP1913410B1 (en) Method and system for debug and test using replicated logic
US7827517B1 (en) Automated register definition, builder and integration framework
JP2002358340A (en) Circuit for logical emulation, logical board with the circuit, logical emulator, and communication method in logical emulation
US20020108094A1 (en) System and method for designing integrated circuits
CN100442293C (en) Method for combination of original files of hardware design language and checking data files
CN117195783A (en) Method for verifying chip design
US7584456B1 (en) Method and apparatus for debugging embedded systems having read only memory
US6842883B2 (en) Application of co-verification tools to the testing of IC designs
CN115017845A (en) Bus driving type chip simulation excitation model for IP unit level verification
US20030237023A1 (en) Associated apparatus and method for supporting development of semiconductor device
US12055588B2 (en) Testbenches for electronic systems with automatic insertion of verification features
US7130784B2 (en) Logic simulation
Bombieri et al. Correct-by-construction generation of device drivers based on RTL testbenches
CN111338761A (en) 51 single-chip microcomputer virtual interrupt controller and implementation method
CN110162438B (en) Simulation debugging device and simulation debugging method
US11403449B1 (en) Systems and methods for configurable switches for verification IP

Legal Events

Date Code Title Description
AS Assignment

Owner name: LSI LOGIC CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FECHSER, DAVID A.;REEL/FRAME:014320/0312

Effective date: 20030715

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AG

Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:LSI CORPORATION;AGERE SYSTEMS LLC;REEL/FRAME:032856/0031

Effective date: 20140506

AS Assignment

Owner name: LSI CORPORATION, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:LSI LOGIC CORPORATION;REEL/FRAME:033102/0270

Effective date: 20070406

AS Assignment

Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LSI CORPORATION;REEL/FRAME:035390/0388

Effective date: 20140814

AS Assignment

Owner name: AGERE SYSTEMS LLC, PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039

Effective date: 20160201

Owner name: LSI CORPORATION, CALIFORNIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039

Effective date: 20160201

AS Assignment

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA

Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001

Effective date: 20160201

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH

Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001

Effective date: 20160201

AS Assignment

Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD., SINGAPORE

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041710/0001

Effective date: 20170119

Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041710/0001

Effective date: 20170119

AS Assignment

Owner name: BELL SEMICONDUCTOR, LLC, ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;BROADCOM CORPORATION;REEL/FRAME:044887/0109

Effective date: 20171208

AS Assignment

Owner name: CORTLAND CAPITAL MARKET SERVICES LLC, AS COLLATERA

Free format text: SECURITY INTEREST;ASSIGNORS:HILCO PATENT ACQUISITION 56, LLC;BELL SEMICONDUCTOR, LLC;BELL NORTHERN RESEARCH, LLC;REEL/FRAME:045216/0020

Effective date: 20180124

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553)

Year of fee payment: 12

AS Assignment

Owner name: BELL NORTHERN RESEARCH, LLC, ILLINOIS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CORTLAND CAPITAL MARKET SERVICES LLC;REEL/FRAME:059720/0223

Effective date: 20220401

Owner name: BELL SEMICONDUCTOR, LLC, ILLINOIS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CORTLAND CAPITAL MARKET SERVICES LLC;REEL/FRAME:059720/0223

Effective date: 20220401

Owner name: HILCO PATENT ACQUISITION 56, LLC, ILLINOIS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CORTLAND CAPITAL MARKET SERVICES LLC;REEL/FRAME:059720/0223

Effective date: 20220401