US20010011212A1 - Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging - Google Patents

Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging Download PDF

Info

Publication number
US20010011212A1
US20010011212A1 US09/122,493 US12249398A US2001011212A1 US 20010011212 A1 US20010011212 A1 US 20010011212A1 US 12249398 A US12249398 A US 12249398A US 2001011212 A1 US2001011212 A1 US 2001011212A1
Authority
US
United States
Prior art keywords
source code
instrumentation
gate
level
statement
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.)
Granted
Application number
US09/122,493
Other versions
US6336087B2 (en
Inventor
Alain Raynaud
Luc M. Burgun
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.)
Mentor Graphics Corp
Mentor Graphics Holdings Ltd
Original Assignee
Mentor Graphics 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 Mentor Graphics Corp filed Critical Mentor Graphics Corp
Priority to US09/122,493 priority Critical patent/US6336087B2/en
Priority to US09/127,584 priority patent/US6240376B1/en
Assigned to MENTOR GRAPHICS CORPORATION reassignment MENTOR GRAPHICS CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BURGUN, LUC M., RAYNAUD, ALAIN
Publication of US20010011212A1 publication Critical patent/US20010011212A1/en
Application granted granted Critical
Publication of US6336087B2 publication Critical patent/US6336087B2/en
Assigned to MENTOR GRAPHICS (HOLDING) LTD., MENTOR GRAPHICS CORPORATION reassignment MENTOR GRAPHICS (HOLDING) LTD. RETROACTIVE ASSIGNMENT AND QUITCLAIM Assignors: BARBIER, JEAN, BEDOISEAU, FLORENT, BURGUN, LUC M., DAVIS, ROBERT W., DIEHL, PHILIPPE, DOUEZY, FRANCOIS, EMIRIAN, FREDERIC M., FILOCHE, OLIVIER, HOCHAPFEL, ERIC G.F., JOSSO, FREDERIC, LAURENT, GILLES, LEPAPE, OLIVIER, MAQUINON, FRANCK, MARANTZ, JOSHUA D., META SYSTEMS SARL, MONTAGNE, XAVIER, QUENNESSON, CYRIL, RAYNAUD, ALAIN, REBLEWSKI, FREDERIC, SAINT GENIEYS, DAVID FENECH, SCHMITT, PEER G., SELVIDGE, CHARLEY
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/327Logic synthesis; Behaviour synthesis, e.g. mapping logic, HDL to netlist, high-level language to RTL or netlist
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking
    • G06F30/3308Design verification, e.g. functional simulation or model checking using simulation

Definitions

  • This invention relates to the fields of simulation and prototyping when designing integrated circuits.
  • this invention is drawn to debugging synthesizable code at the register transfer level during gate-level simulation.
  • VHSIC Very High Speed Integrated Circuit
  • Verilog Verilog
  • Synthesis is the process of generating a gate-level netlist from the high-level description languages.
  • synthesis tools recognize a subset of the high-level description language source code referred to as Register Transfer Level (RTL) source code. Further information regarding RTL source code may be found in the IEEE 1076.6/D1.10 Draft Standard for VHDL Register Transfer Level Synthesis (1997).
  • the RTL source code can be synthesized into a gate-level netlist.
  • the gate-level netlist can be verified using gate-level simulation.
  • the gate-level simulation can be performed using a software gate-level simulator.
  • the gate-level simulation may be performed by converting the gate-level netlist into a format suitable for programming an emulator, a hardware accelerator, or a rapid-prototyping system so that the digital circuit description can take an actual operating hardware form.
  • Debugging environments for high-level hardware description languages frequently include a number of functionalities for analyzing and verifying the design when performing simulation. For example, a designer can typically navigate the design hierarchy, view the RTL source code, and set breakpoints on a statement of RTL source code to stop the simulation. Statements are usually identified by their line number in the RTL source code.
  • the debugging environment often supports viewing and tracing variables and signal values. The RTL simulation environment typically offers such RTL debugging functionalities.
  • RTL simulation is typically performed by using software RTL simulators which provide good flexibility.
  • software RTL simulators which provide good flexibility.
  • a very large number of test vectors may need to be applied in order to adequately verify the design.
  • This can take a considerable amount of time using software RTL simulation as contrasted with hardware acceleration or emulation starting from a gate-level netlist representation (i.e., “gate-level hardware acceleration,” or “gate-level emulation”).
  • gate-level hardware acceleration i.e., “gate-level emulation”
  • it may be useful to perform in-situ verification which consists of validating the design under test by connecting the emulator or hardware accelerator to the target system environment (where the design is to be inserted after the design is completed).
  • the designer typically cannot set a breakpoint from the source code during gate-level simulation. Although signals can be analyzed during gate-level simulation, mapping signal values to particular source code lines can be difficult, if not impossible. If the source code is translated into a combinatorial logic netlist, for example, the designer cannot “step” through the source code to trace variable values. Instead, the designer is limited to analyzing the input vector and resulting output vector values. Although the signals at the inputs and outputs of the various gates may be traced or modified, these values are determined concurrently in a combinatorial network and thus such analysis is not readily mappable to the RTL source code.
  • a typical design flow will include creating a design at the RTL level, then synthesizing it into a gate-level netlist. Although simulation of this netlist can be performed at greater speeds using emulators or hardware accelerators, the ability to debug the design at the gate level is severely limited in comparison with software RTL simulation.
  • RTL register transfer level
  • One method of facilitating gate-level simulation includes the step of generating cross-reference instrumentation data including instrumentation logic indicative of the execution status of at least one synthesizable statement within the RTL source code.
  • a gate-level netlist is synthesized from the RTL source code. Evaluation of the instrumentation logic during simulation of the gate-level netlist enables RTL debugging by indicating the execution status of the cross-referenced synthesizable statement in the RTL source code.
  • the gate-level netlist is modified to provide instrumentation signals implementing the instrumentation logic and corresponding to synthesizable statements within the RTL source code. In various embodiments, this may be accomplished by modifying the RTL source code or by generating the modified gate-level netlist during synthesis as if the source code had been modified.
  • the gate-level netlist is not modified but the instrumentation signals implementing the instrumentation logic are contained in a cross-reference instrumentation database. In either case, the instrumentation signals indicate the execution status of the corresponding cross-referenced synthesizable statement.
  • the instrumentation signals can be used to facilitate source code analysis, breakpoint debugging, and visual tracing of the source code execution path during gate-level simulation.
  • a breakpoint can be set at a selected statement of the source code.
  • a simulation breakpoint is set so that the simulation is halted at a simulation cycle where the value of the instrumentation signals indicate that the statement has become active .
  • the instrumentation logic is evaluated during gate-level simulation to determine a list of at least one active statement.
  • the active statement is displayed as a highlighted statement.
  • cross-reference instrumentation data including the instrumentation signals can be used to count the number of times a corresponding statement is executed in the source code. For example, an execution count of the cross-referenced synthesizable statement is incremented when evaluation of the corresponding instrumentation logic indicates that the cross-referenced synthesizable statement is active.
  • FIG. 1 illustrates the process of synthesizing RTL source code into a gate-level design.
  • FIG. 2 illustrates one embodiment of a modified process for generating a gate-level design.
  • FIG. 3 illustrates one embodiment of a method for instrumenting level-sensitive RTL source code.
  • FIG. 4 illustrates VHDL source code.
  • FIG. 5 illustrates the gate-level design synthesized from the RTL source code of FIG. 4.
  • FIG. 6 illustrates the VHDL source code of FIG. 4 modified in accordance with the method of FIG. 3.
  • FIG. 7 illustrates one embodiment of the gate-level logic synthesized from the modified RTL source code.
  • FIG. 8 illustrates sample Verilog source code before instrumentation.
  • FIG. 9 illustrates the Verilog source of FIG. 8 instrumented in accordance with the method of FIG. 3.
  • FIG. 10 illustrates the gate-level logic synthesized from the instrumented Verilog source code of FIG. 9.
  • FIG. 11 illustrates Verilog source code for a D flip-flop with asynchronous reset.
  • FIG. 12 illustrates one method of instrumenting event-sensitive RTL source code.
  • FIG. 13 illustrates the source code of FIG. 11 modified in accordance with the instrumentation process of FIG. 12.
  • FIG. 14 illustrates the gate-level logic synthesized for the instrumented source code of FIG. 13.
  • FIG. 15 illustrates Verilog source code for a D flip-flop with asynchronous reset.
  • FIG. 16 illustrates the Verilog source code of FIG. 15 after instrumentation in accordance with the method of FIG. 12.
  • FIG. 17 illustrates a method of instrumenting process activation.
  • FIG. 18 illustrates source code modified in accordance with the method of FIG. 17.
  • FIG. 19 illustrates an instrumented “case” statement.
  • FIG. 20 illustrates a process for decreasing the logic needed to instrument the source code.
  • FIG. 21 illustrates incorporating instrumentation within the synthesis process.
  • FIG. 22 illustrates a method of setting a breakpoint in RTL source code for use during gate-level simulation.
  • FIG. 1 illustrates a typical RTL source code synthesis process.
  • HDL code including synthesizable RTL source code ( 110 ) serves as input to a synthesis process 120 .
  • the RTL source code 110 is synthesized in step 140 to produce a gate-level design 150 .
  • the gate-level design can be used for gate-level simulation as illustrated in step 160 .
  • the gate-level design comprises a hierarchical or flattened gate-level netlist representing the circuit to be simulated.
  • the various signals in a design are referred to as nets.
  • a hierarchical netlist is made of a list of blocks, whereas a flattened netlist comprises only one block.
  • a block contains components and a description of their interconnection using nets. Components can be reduced to combinatorial or sequential logic gates, or they may be hierarchical blocks of lower level.
  • the component may be a primitive gate denoting a single combinatorial logic function (e.g., AND, NAND, NOR, OR, XOR, NXOR, etc.) or a single storage element such as a flip-flop or latch for sequential logic.
  • a primitive gate denoting a single combinatorial logic function (e.g., AND, NAND, NOR, OR, XOR, NXOR, etc.) or a single storage element such as a flip-flop or latch for sequential logic.
  • a set of primitive gates is found in the generic library GTECH available from Synopsys, Inc. of Mountain View, Calif.
  • the component may be an application specific integrated circuit (ASIC) library cell which can be represented by a set of primitive gates.
  • ASIC application specific integrated circuit
  • LCA300K ASIC library developed by LSI Logic, Inc., Milpitas, Calif.
  • a component may also be a programmable primitive that represents a set of logic functions and storage.
  • a programmable primitive is the configurable logic block (CLB) as described in The Programmable Gate Array Handbook, Xilinx Inc., San Jose, 1993.
  • a component is a macro block denoting a complex logic function such as memories, counters, shifters, adders, multipliers, etc. Each of these can be further reduced to primitive gates forming combinatorial or sequential logic.
  • RTL simulation typically permits the designer to set breakpoints in the source code, navigate the design hierarchy, view variables and signals and trace the value of these variables and signals.
  • Instrumentation is the process of preserving high-level information through the synthesis process. Instrumentation permits simulation of a gate-level netlist at the level of abstraction of RTL simulation by preserving some of the information available at the source code level through the synthesis process.
  • FIG. 2 illustrates one embodiment of the instrumentation process in which instrumentation is integrated with the synthesis process.
  • RTL source code 210 is provided to the synthesis process 220 .
  • the synthesis process 120 of FIG. 1 has been modified to include an instrumentation step 234 .
  • the instrumented code is then synthesized in step 240 as the original RTL source code was in step 140 of FIG. 1.
  • instrumentation results in generating a modified gate-level design to permit reconstitution of the flow of execution of the original RTL source code during gate-level simulation.
  • instrumentation logic is created for a synthesizable statement in the RTL source code either by modifying the RTL source code or by analyzing the RTL source code during the synthesis process.
  • the instrumentation logic provides an output signal indicative of whether the corresponding synthesizable statement is active.
  • a gate-level design including the instrumentation output signal is then synthesized.
  • the resulting gate-level design 250 contains additional logic to create the additional instrumentation output signals referenced in instrumentation data 238 .
  • the RTL source code is analyzed to generate a cross-reference database as instrumentation data 238 without modifying the gate-level design.
  • the cross-reference database indicates the combination of already existing signals in the form of instrumentation logic that can be evaluated during simulation to determine whether a particular line of the RTL source code is active.
  • the cross-reference database contains a cross-reference between these instrumentation logic output signals and the position of the corresponding statement in the source code.
  • the instrumentation data 238 is likely to contain considerably more complex logic to evaluate during simulation when the approach of not modifying the gate-level design (i.e., “pure” cross-reference database) is taken.
  • the two approaches have tradeoffs.
  • the gate-level design modification technique does not require special knowledge of the target simulation environment.
  • the gate-level design modification technique significantly reduces or eliminates the complexity of the logic to be evaluated during simulation to the extent that emulator or accelerator hardware triggering circuitry can be used to take an action when the corresponding statement is executed.
  • the hardware triggering circuitry may be used to halt the simulation at a particular statement or to count the number of times a particular statement is executed.
  • the resulting gate-level design used during simulation will not be the design actually used for production thus simulation may not verify accurately the behavior of the gate-level design used for production.
  • simulation of modified gate-level design may require more physical resources in hardware than the original design alone if gates have been added in order to implement the instrumentation logic.
  • the pure cross-reference database technique typically results in greater complexity of instrumentation logic to evaluate during simulation, but does not otherwise affect the original gate-level design.
  • the greater complexity may prevent the use of the hardware triggering circuitry to halt the simulation or to track source code coverage.
  • the pure cross-reference database technique may result in a significantly slower simulation time.
  • the evaluation since the evaluation may be performed by software, direct verification of the gate-level design in the target system through in-situ verification may not be possible.
  • the instrumentation data including the logic added for instrumentation purposes can be eliminated after testing, however, without disrupting the gate-level design.
  • the gate-level design modification technique greatly simplifies the analysis and the instrumentation logic required for cross-referencing by modifying the gate-level design to create unique signals and therefore simpler logic to evaluate (i.e., a single signal).
  • the resulting instrumentation logic cross-referenced in the instrumentation data 238 is easily evaluated during simulation.
  • Various embodiments of instrumentation may combine the gate-level design modification technique or the pure cross-referencing technique in order to trade off simulation speed, density, and verification accuracy.
  • the gate-level simulator, hardware accelerator, or emulator e.g., through the use of a logic analyzer which can be external to the emulator
  • the gate-level simulator, hardware accelerator, or emulator has the capacity to set breakpoints whenever certain signals reach a given value, then it is possible to implement breakpoints corresponding to RTL simulation breakpoints in the gate-level design.
  • the condition can be converted to a comparison with key signals in the gate-level design.
  • Instrumentation data 238 identifies the RTL source code statements each instrumentation output signal is associated with. Instrumentation data 238 is generated during the instrumentation process of step 234 . In one embodiment, the instrumentation data is implemented as gates that can then be simulated by the target-level simulator. By examining the state of each instrumentation output signal during gate-level simulation, the user can determine which portions of RTL source code are being simulated. This in turn permits the designer to determine RTL source code coverage. By tracking the instrumentation signal values for each cycle of execution, the designer can determine how many times each line of the RTL source code has been activated.
  • the instrumentation data 238 can be used during simulation to ensure every possible state transition has been tested.
  • a Finite State Machine analyzer can determine from the values of the instrumentation output signals whether every possible state transition has been tested.
  • the instrumentation data 238 can also be used to enhance the source code display.
  • the source code is repositioned on the display so as to indicate the execution paths that are active during a current cycle.
  • the active source code in a given cycle is highlighted to indicate that it is active. This permits the designer to visually see the process flow without having to determine the value of each signal.
  • the instrumentation data 238 is used to enhance the display of the original RTL source code rather than the source code resulting from instrumentation.
  • An integrated circuit design is typically built by assembling hierarchical blocks.
  • a block corresponds to an entity and architecture.
  • Verilog a block corresponds to a module.
  • a block typically includes a declarative portion and a statement portion. The declarative portion generally includes the list of the ports or connectors.
  • the statement portion describes the block's behavior and is typically where a designer needs help when debugging a design.
  • the statement portion includes concurrent signal assignment statements and sequential statements.
  • Concurrent signal assignment statements assign a logic expression to a signal.
  • the signal is typically available for viewing at all times and thus breakpoints can be set in accordance with when the signals reach a certain value.
  • Sequential statements assign values depending upon the execution flow of the sequence. Sequential statement analysis is typically where the designer needs the greatest aids in debugging the design.
  • Sequential statements are typically found in VHDL “processes” and in Verilog “always” blocks. Processes or always blocks can be built of an unlimited combination of sequential statements including loops, conditional statements, and alternatives. There are at least two classes of sequential statements: level-sensitive and event-sensitive. Level-sensitive sequential statements only depend on the value of the inputs and can be synthesized to logic networks of combinatorial gates and latches. Event-sensitive sequential statements additionally require sequential logic such as flip-flops.
  • level-sensitive RTL source code is instrumented by creating and associating one output signal with each list of synthesizable sequential statements.
  • a list can consist of one or more sequential statements.
  • each statement is a list.
  • each list corresponds to a branch of the RTL source code.
  • a list corresponding to a branch typically comprises a plurality of adjacent sequential statements, but may comprise a single sequential statement. Only one output signal is needed for each list of synthesizable sequential statements in a branch rather than for every sequential statement in the source code.
  • Examples of sequential statements that create branches in the RTL source code are conditional statements such as IF-THEN statements and SELECT-CASE statements.
  • FIG. 3 illustrates one method of modifying RTL source code for level-sensitive code.
  • a unique local variable is created for each list of adjacent sequential statements in step 310 .
  • the level sensitive code instrumentation includes the step of modifying the RTL source code to initialize each of these unique variables to zero at the beginning of the process being instrumented in step 320 .
  • One unique variable assignment statement is inserted into each list of adjacent sequential statements corresponding to an executable branch in step 330 .
  • the assignment statement sets the unique variable to one.
  • At the end of the process all the unique local variables are assigned to global signals in step 340 .
  • Steps 310 and 320 are more generically referred to as initialization.
  • Step 330 is referred to as flow instrumentation.
  • Step 340 is referred to as “gathering.”
  • FIG. 4 illustrates non-instrumented VHDL source code.
  • the VHDL source code 400 includes nine sequential statements within the process block. Eight of these nine statements are non-signal assignment sequential statements. These eight sequential statements form six statement lists or executable branches of the code.
  • IF-THEN statement 410 comprises one list.
  • Signal assignment statement 420 comprises a second list.
  • Statements 430 , 440 , 450 and 490 comprise a third list because they would be executed sequentially within the same execution path.
  • Statements 460 , 470 , and 480 form individual lists.
  • FIG. 5 illustrates one embodiment of the logic 500 resulting from the synthesis of the RTL source code of FIG. 4. This figure may be used for comparison with the gate level design generated from instrumented code described below.
  • FIG. 6 illustrates the source code of FIG. 4 after instrumentation as described in FIG. 3.
  • the added statements are italicized for emphasis.
  • line 612 has been added to the source code to create six unique local variables (TRACE 1 through TRACE 6 ), one for each of the six identified lists, in accordance with step 310 of FIG. 3.
  • variable assignment statement 630 has been added adjacent to the first list comprising statement 410 .
  • Variable assignment statement 632 has been added adjacent to the second list comprising statement 420 .
  • Variable assignment statement 634 has been added adjacent to the third list comprising statements 430 , 440 , 450 and 490 .
  • Variable assignment statement 636 has been added adjacent to the fourth list comprising statement 460 .
  • variable assignment statements 638 and 640 have been added adjacent to the fifth list comprising statement 470 and the sixth list comprising 480 , respectively.
  • Each of variable assignment statements 630 through 640 assigns a unique local variable the value of one.
  • Code portion 620 is added to initialize the unique local variables to zero at the beginning of the process in accordance with step 310 of FIG. 3.
  • Each of the local variables is assigned to a global output signal in accordance with step 340 of FIG. 3 by code portion 650 . If required by the HDL, the global signals are declared by code portion 610 . Similarly, the trace variables are declared by code portion 612 .
  • the unique local variables can actually be a single array where each “unique variable” or trace variable corresponds to a different position in the array.
  • the additional global signals are described by an array where each of the global signals is represented by a different index of the array.
  • Coding practices for VHDL generally require variables to be used within the process and a signal assignment at the end of the process to propagate the variable values at the end of the process.
  • markers such as variable assignment statements are used to track the execution paths. Markers such as variable assignment statements are not typically synthesized into logic indicating the variable values, thus the variable assignment statements are used in conjunction with signal assignment statements in order to produce signals indicating whether various portions of the synthesized code are being executed.
  • FIG. 7 illustrates one embodiment of the logic 700 generated through instrumentation.
  • FIG. 7 illustrates the additional gate-level logic added to generate signals SIG_TRACE 1 through SIG_TRACE 6 from synthesis of the modified source code.
  • FIG. 8 illustrates a Verilog “always” block 800 .
  • FIG. 9 illustrates the same code after instrumentation in accordance with the process of FIG. 3. Due to Verilog syntax requirements, “BEGIN-END” statements were used to properly group the instrumentation variable with the other statements in each executable path.
  • FIG. 10 illustrates one embodiment of gate-level logic 1100 generated by synthesis of the instrumented “always” block 900 of FIG. 9.
  • the instrumentation signals SIG_TRACE 1 , SIG_TRACE 2 , SIG_TRACE 3 , and SIG_TRACE 4 are the result of combinatorial logic only.
  • the instrumentation data 238 can be stored in a cross-reference file.
  • the cross-reference file contains a mapping between original source code line numbers and instrumentation signals. Each time an instrumentation variable (and its associated signal) is added to the source code, all the line numbers of the statements in the list associated with the instrumentation variable are added to the file.
  • This cross-reference file i.e., instrumentation data 238
  • a more sophisticated method than that illustrated in FIG. 3 is required to instrument RTL source code having references to signal events.
  • source code is used to describe edge-sensitive devices.
  • References to signal events typically imply flip-flops.
  • a signal event is a signal transition. Thus any signal computed from a signal transition references a signal event.
  • FIG. 11 illustrates sample VHDL code 1100 with references to a signal event.
  • VHDL code 1100 implements a D-type flip-flop with asynchronous reset.
  • the event in this example is a transition on the clock signal (CLK) as referenced by the term “CLK'EVENT.”
  • signals can have various attributes associated with them.
  • a function attribute executes a named function on the associated signal to return a value. For example, when the simulator executes a statement such as CLK'EVENT, a function call is performed to check this property of the signal CLK. In particular, CLK'EVENT returns a Boolean value signifying a change in value on the signal CLK.
  • Other classes of attributes include value attributes and range attributes.
  • the signal CLK has a function attribute named “event” associated with it.
  • the predicate CLK'EVENT is true if an event (i.e., signal transition) has occurred on the CLK signal. Assigning a value to a signal (i.e., a signal transaction) qualifies as an event only if the transaction results in a change in value or state for the signal. Thus the predicate CLK'EVENT is true whenever an event has occurred on the signal CLK in the most recent simulation cycle.
  • RISING_EDGE(CLK) might be used to accomplish the same result without the use of attributes.
  • the function RISING_EDGE(CLK) is still an event even though the term “event” does not appear in the function.
  • FIG. 12 illustrates a method of instrumenting source code having references to signal events.
  • every signal event is sampled using a fast clock.
  • every signal whose state transition serves as the basis for the determination of another signal is sampled.
  • An instrumentation signal event corresponding to the original signal event is generated in step 1220 . Any attributes of the original signal must similarly be reproduced based on the instrumentation signal if the source code uses attributes of the original signal event.
  • step 1230 every process that references a signal event is duplicated.
  • step 1240 each list of sequential statements within the duplicate version of the code is replaced by a unique local variable assignment statement.
  • step 1250 each time a signal event is referenced in the duplicated version of the code, it is replaced by the sampled signal event computed in step 1210 .
  • the modified RTL source code can then be synthesized in step 1260 to generate gate-level logic including the instrumentation output signals.
  • FIG. 13 illustrates application of the method of FIG. 12 to the source code of FIG. 11.
  • the signal events are sampled using a fast clock provided during gate-level simulation (i.e., FAST_CLK).
  • FAST_CLK has a higher frequency than the CLK signal and thus permits detecting transition edges before signals depending upon CLK (including CLK itself) can.
  • the only signal event referenced in FIG. 11 is a transition in the signal CLK indicated by the term CLK'EVENT.
  • CLK'EVENT an instrumentation version of CLK'EVENT is created by sampling the signal CLK using FAST_CLK.
  • the signal FAST_CLK has a higher frequency than the signal CLK.
  • Code portion 1310 samples the CLK signal on every rising edge of the signal FAST_CLK to generate a sampled version of the signal CLK named SAMPLED_CLK.
  • the instrumentation version of CLK'EVENT is CLK_EVENT which is generated in code portion 1310 based on SAMPLED_CLK.
  • the instrumentation signal CLK_EVENT (corresponding to CLK'EVENT) is determined by comparison of signals SAMPLED_CLK and CLK.
  • the signal CLK_EVENT is true only when the signal SAMPLED_CLK is not the same as CLK, thus indicating a transition has occurred in the signal CLK.
  • code portion 1310 also illustrates the generation of instrumentation clock signal attributes based on SAMPLED_CLK.
  • the signal CLK'STABLE is the complement of CLK'EVENT.
  • code portion 1310 indicates the instrumentation version of the attribute CLK'STABLE (i.e., CLK_STABLE) computed on the instrumentation clock signal (i.e., SAMPLED_CLK).
  • the signal CLK'LASTVALUE is a function signal attribute that returns the previous value of the signal CLK.
  • the instrumentation version (i.e., CLK_LASTVALUE) of the attribute CLK'LASTVALUE is similarly computed on the instrumentation clock signal, SAMPLED_CLK.
  • CLK_LASTVALUE is the same as the sampled clock signal, SAMPLED_CLK, code 1310 introduces the intermediate signal SAMPLED_CLK for purposes of illustrating sampling of the CLK signal.
  • the signal CLK_LASTVALUE can be defined in lieu of SAMPLED_CLK in order to eliminate the introduction of an unnecessary intermediate signal SAMPLED_CLK and the subsequent step of assigning CLK_LASTVALUE the value of SAMPLED_CLK.
  • code portion 1310 serves as an example of how to generate instrumentation versions of signal attributes typically used to describe edge-sensitive devices.
  • Code portion 1320 represents the instrumented duplicate of original code portion 1330 .
  • the process of code portion 1330 references the event CLK'EVENT in the IF-ELSIF statement.
  • code portion 1320 all sequential statements (except the statement referencing an event) have been replaced with unique local variable assignment statements. These statements assign a local variable (i.e., TRACE 1 , TRACE 2 ) the value “1.”
  • Code portion 1320 also includes statements to create and initialize these unique local variables.
  • every occurrence of a signal event is replaced with the sampled version of that event.
  • references to CLK'EVENT in code portion 1330 are replaced with references to CLK_EVENT in code portion 1320 .
  • the process parameter list is modified to include the generated signal CLK_EVENT.
  • FIG. 14 illustrates the gate-level logic 1400 resulting from synthesis of the code in FIG. 13.
  • FIG. 15 illustrates Verilog source code 1500 for a D flip-flop with asynchronous reset.
  • FIG. 16 illustrates the code 1600 resulting from modifying source code 1500 in accordance with the method of FIG. 12.
  • One advantage of the instrumentation approach of FIG. 12 is that the gates generated by the synthesis tool are the same ones that would be generated if the source code had not been instrumented.
  • the gates generated for the instrumentation logic are not intermingled with the gates generated from the non-instrumented source code. This permits design verification with gate-level logic that does not need to be re-verified after instrumentation verification. Thus the designer can verify the result of synthesis at the gate level while retaining RTL breakpoint feature.
  • the synthesis tool may not recognize that the same code appears twice. This may incur an additional relatively expensive phase of resource sharing in order to achieve the same performance results as the process illustrated in FIG. 3.
  • FIGS. 3 and 12 permit detecting any path that has been taken while a VHDL process or a Verilog “always” block is active. Tracking the activation of each process permits further analysis.
  • FIG. 17 illustrates a method of instrumenting the activation of the processes (or “always” blocks) themselves for subsequent determination of whether the process is active during gate-level simulation .
  • step 1710 the sensitivity list of a process is identified.
  • step 1720 logic is generated to compare the signals in the sensitivity list between consecutive simulation cycles. Subsequently, during gate-level simulation in step 1730 , a determination is made as to whether an event has occurred on any of the sensitivity list signals. Each simulation cycle that a signal indicates a difference (i.e., a signal event has occurred), the process is active as indicated by step 1740 . Otherwise, if no events have occurred on any of the sensitivity list signals, the process is inactive as indicated by step 1750 .
  • FIG. 18 illustrates the code added to determine if process P 1 is active.
  • the added code is italicized.
  • the sensitivity list of process P 1 includes signals a, b, and c.
  • code section 1810 creates sampled versions of a, b, and c using FAST_CLK as described above.
  • the sampled versions of a, b, and c are SAMPLED_A, SAMPLED_B, and SAMPLED_C, respectively.
  • Process instrumentation data can be added to the instrumentation data cross-reference file in order to enhance the source code display. For example, the active process in a given cycle can be highlighted to indicate it is active. This permits the designer to visually see the active processes without having to determine the value of each signal.
  • the instrumentation data is used to enhance the display of the original RTL source code rather than the source code resulting from instrumentation.
  • instrumentation techniques presented result in gate level designs providing explicit instrumentation signals to indicate that some specific portion of the source code is active.
  • the number of instrumentation signals tends to increase with the complexity of the system being modeled.
  • Some optimizations may be performed to decrease the number of instrumentation signals. At least one execution path will be active any time a process is activated. As a result, the TRACE 1 variable in the examples of FIGS. 6 and 9 tend to provide no additional information and thus SIG_TRACE 1 is somewhat trivial as can be seen from the synthesized logic of FIGS. 7 and 10. Thus at least one trace variable (and therefore one output signal trace) can typically be eliminated.
  • the execution status of each branch of the code can be determined even though every branch is not explicitly instrumented. To verify the execution status of every branch, the instrumentation process need only ensure that each branch is instrumented either explicitly or implicitly through the instrumentation of other branches.
  • the capacity of hardware triggers can be used to eliminate some of the instrumentation by combining several signals into one condition.
  • the number of gates simulated can be reduced by replacing logical AND conditions that appear in the equations of instrumentation signals by simulator-specific triggers.
  • FIG. 20 illustrates a method for optimizing the instrumentation process.
  • an instrumentation signal is selected in step 2010 .
  • step 2020 a determination is made to whether the equation of the current signal can be expressed as a logical AND between a signal and a simplified expression. If so, then the AND gate should be eliminated in step 2030 and the extracted signal can be added to the trigger conditions during simulation in step 2040 . If triggers can be activated on zeroes as well as ones, then step 2020 can also determine whether an equation can be simplified as a logical negation of a subexpression and the logical negation of the subexpression can be added to the trigger conditions during simulation in step 2040 where appropriate. Step 2020 would then be applied recursively until the equation cannot be further simplified. This process is then applied to all of the instrumentation signals.
  • signal TRACE 4 is the result of performing a logical AND between opcode( 0 ) and opcode( 1 ).
  • the AND gate could again be eliminated from the synthesized gate-level design and the trigger conditions could be updated accordingly as long as no other signals used “OPCODE( 0 )” as an input. If no other logic uses “OPCODE( 0 )” as an input, then the trigger conditions can be updated to refer to the signals used to generate OPCODE( 0 ) and the gate-level netlist AND gate can safely be eliminated. More generally, any optimization that consists of eliminating gates and other elements by transferring the implementation of the instrumentation logic to the logic analyzer of the target simulator can be performed.
  • the instrumentation required for detecting activation of a process may similarly be reduced.
  • greater efficiency may be possible by keeping a list of all the signals in the process sensitivity list and then testing whether events occurred on the signals in the sensitivity list.
  • Further optimization may be made possible by sharing the logic for signals that appear on the sensitivity list of more than one process.
  • the original signal can be sampled once initially. A comparison is made between the initial value and the current value of the signal to generate an event signal indicative of whether an event has occurred on that signal.
  • the event signal can then be used for instrumentation of processes with events and for tracking process activation.
  • FIGS. 3, 12, and 17 illustrate methods of modifying the original RTL source code for instrumenting processes and level-sensitive and edge-sensitive source code.
  • Trace variables i.e., instrumentation variables
  • Additional output signals are generated from instrumentation variables in order to detect the execution paths of the source code.
  • the instrumentation variables are reset at the beginning of a process and the signals are assigned at the end of the process in order to ensure that all the signals are assigned regardless of which execution path is taken inside the process.
  • the signals might be directly assigned in the execution path of the process.
  • this alternative embodiment would force the synthesis tool to generate complicated structures including latches due to the nature of HDLs and simulation rules.
  • FIGS. 3, 12, and 17 can be applied to the source code before the source code is synthesized.
  • the steps that modify the RTL source code can be performed before but entirely independently of the synthesis process itself.
  • FIG. 21 illustrates an embodiment in which the instrumentation data is generated entirely within the synthesis process.
  • the process of creating output signals associated with synthesizable statements in the source code and then synthesizing the source code into a gate-level design including the output signal can be incorporated into the synthesis tool itself so that modification of the RTL source code is not required.
  • one of the steps performed by a synthesis tool for generation of the gate-level design is parsing the RTL source code. Parsing the RTL source code results in a parser data structure that is subsequently used to generate the gate-level design. Instead of modifying the source code, the synthesis tool can simply set markers inside the parser data structure.
  • FIG. 22 illustrates one application of using the instrumentation signals for tracing execution flow using breakpoints.
  • the user sets a breakpoint at a specified line number of the source code.
  • the specified line number is then associated with one of the instrumented lists of statements in step 2220 .
  • the instrumentation signal for the associated list is identified as the breakpoint output signal.
  • the active lists (identified by transitions in their corresponding instrumentation signals) may be highlighted and displayed for the user as indicated in step 2240 .
  • the active lists may be portrayed in a different color than the inactive lists.
  • the active lists may be displayed using blinking characters, for example.
  • the instrumentation data file can be used to associate an instrumentation signal with a list of source code line numbers to be highlighted.
  • the simulation can be stopped as indicated in step 2250 .
  • the designer has the ability to effectively set breakpoints in the RTL source code which can be acted upon during RTL simulation.
  • the methods of instrumentation may be implemented by a processor responding to a series of instructions.
  • these instructions may be stored in a computer system's memory such as random access memory or read only memory.
  • the instructions may be distributed on a nonvolatile storage medium for subsequent access and execution by the processor. Typically the instructions are stored in the storage medium for distribution to a user. The instructions may exist in an application program form or as a file stored in the storage medium. The instructions are transferred from the nonvolatile storage medium to a computer system for execution by the processor.
  • the program or file is installed from the storage medium to the computer system such that the copy of the instructions in the nonvolatile storage medium is not necessary for performing instrumentation.
  • the program or file is configured such that the original nonvolatile storage medium is required whenever the instructions are executed.
  • Nonvolatile storage mediums based on magnetic, optical, or semiconductor memory storage principles are readily available.
  • Nonvolatile magnetic storage mediums include floppy disks and magnetic tape, for example.
  • Nonvolatile optical storage mediums include compact discs, digital video disks, etc.
  • Semiconductor-based nonvolatile memories include rewritable flash memory.
  • Instrumentation allows the designer to perform gate-level simulation of synthesized RTL designs with source-level debugging. In addition, the instrumentation process allows the designer to examine source code coverage during simulation.

Abstract

Methods of instrumenting synthesizable source code to enable debugging support akin to high-level language programming environments for gate-level simulation are provided. One method of facilitating gate-level simulation includes generating cross-reference instrumentation data including instrumentation logic indicative of an execution status of at least one synthesizable register transfer level (RTL) source code statement. A gate-level netlist is synthesized from the source code. Evaluation of the instrumentation logic during simulation of the gate-level netlist facilitates simulation by indicating the execution status of a corresponding source code statement. One method results in a modified gate-level netlist to generate instrumentation signals corresponding to synthesizable statements within the source code. This may be accomplished by modifying the source code or by generating the modified gate-level netlist as if the source code was modified during synthesis. Alternatively, cross-reference instrumentation data including instrumentation logic can be generated without modifying the gate-level design. The instrumentation logic indicates the execution status of a corresponding cross-referenced synthesizable statement. An execution count of a cross-referenced synthesizable statement can be incremented when the corresponding instrumentation signals indicates the statement is active to determine source code coverage. Source code statements can be highlighted when active for visually tracing execution paths. For breakpoint simulation, a breakpoint can be set at a selected source code statement. The corresponding instrumentation logic from the cross-reference instrumentation data is implemented as a simulation breakpoint. The simulation is halted at a simulation cycle where the values of the instrumentation signals indicate that the source code statement is active.

Description

    FIELD OF THE INVENTION
  • This invention relates to the fields of simulation and prototyping when designing integrated circuits. In particular, this invention is drawn to debugging synthesizable code at the register transfer level during gate-level simulation. [0001]
  • BACKGROUND OF THE INVENTION
  • Integrated circuit designers have adopted the use of high-level hardware description languages due in part to the size and complexity of modern integrated circuits. One such description language is Very High Speed Integrated Circuit (VHSIC) Description Language, or VHDL. Further information regarding VHDL may be found in the IEEE Standard VHDL Language Reference Manual (IEEE 1076-1987, IEEE 1076-1993). Another such description language is Verilog. These high level description languages are typically generically referred to as hardware description languages (HDLs). [0002]
  • Synthesis is the process of generating a gate-level netlist from the high-level description languages. Presently, synthesis tools recognize a subset of the high-level description language source code referred to as Register Transfer Level (RTL) source code. Further information regarding RTL source code may be found in the IEEE 1076.6/D1.10 Draft Standard for VHDL Register Transfer Level Synthesis (1997). [0003]
  • The RTL source code can be synthesized into a gate-level netlist. The gate-level netlist can be verified using gate-level simulation. The gate-level simulation can be performed using a software gate-level simulator. Alternatively, the gate-level simulation may be performed by converting the gate-level netlist into a format suitable for programming an emulator, a hardware accelerator, or a rapid-prototyping system so that the digital circuit description can take an actual operating hardware form. [0004]
  • Debugging environments for high-level hardware description languages frequently include a number of functionalities for analyzing and verifying the design when performing simulation. For example, a designer can typically navigate the design hierarchy, view the RTL source code, and set breakpoints on a statement of RTL source code to stop the simulation. Statements are usually identified by their line number in the RTL source code. In addition, the debugging environment often supports viewing and tracing variables and signal values. The RTL simulation environment typically offers such RTL debugging functionalities. [0005]
  • RTL simulation is typically performed by using software RTL simulators which provide good flexibility. However, for complex designs, a very large number of test vectors may need to be applied in order to adequately verify the design. This can take a considerable amount of time using software RTL simulation as contrasted with hardware acceleration or emulation starting from a gate-level netlist representation (i.e., “gate-level hardware acceleration,” or “gate-level emulation”). Furthermore, it may be useful to perform in-situ verification, which consists of validating the design under test by connecting the emulator or hardware accelerator to the target system environment (where the design is to be inserted after the design is completed). [0006]
  • One disadvantage with gate-level simulation, however, is that most of the high-level information from the RTL source code is lost. Without the high-level information, many of the debugging functionalities are unavailable. [0007]
  • For example, the designer typically cannot set a breakpoint from the source code during gate-level simulation. Although signals can be analyzed during gate-level simulation, mapping signal values to particular source code lines can be difficult, if not impossible. If the source code is translated into a combinatorial logic netlist, for example, the designer cannot “step” through the source code to trace variable values. Instead, the designer is limited to analyzing the input vector and resulting output vector values. Although the signals at the inputs and outputs of the various gates may be traced or modified, these values are determined concurrently in a combinatorial network and thus such analysis is not readily mappable to the RTL source code. [0008]
  • A typical design flow will include creating a design at the RTL level, then synthesizing it into a gate-level netlist. Although simulation of this netlist can be performed at greater speeds using emulators or hardware accelerators, the ability to debug the design at the gate level is severely limited in comparison with software RTL simulation. [0009]
  • SUMMARY OF THE INVENTION
  • Methods of instrumenting synthesizable register transfer level (RTL) source code to enable debugging support akin to high-level language programming environments for gate-level simulation are provided. [0010]
  • One method of facilitating gate-level simulation includes the step of generating cross-reference instrumentation data including instrumentation logic indicative of the execution status of at least one synthesizable statement within the RTL source code. A gate-level netlist is synthesized from the RTL source code. Evaluation of the instrumentation logic during simulation of the gate-level netlist enables RTL debugging by indicating the execution status of the cross-referenced synthesizable statement in the RTL source code. [0011]
  • In one embodiment, the gate-level netlist is modified to provide instrumentation signals implementing the instrumentation logic and corresponding to synthesizable statements within the RTL source code. In various embodiments, this may be accomplished by modifying the RTL source code or by generating the modified gate-level netlist during synthesis as if the source code had been modified. [0012]
  • Alternatively, the gate-level netlist is not modified but the instrumentation signals implementing the instrumentation logic are contained in a cross-reference instrumentation database. In either case, the instrumentation signals indicate the execution status of the corresponding cross-referenced synthesizable statement. The instrumentation signals can be used to facilitate source code analysis, breakpoint debugging, and visual tracing of the source code execution path during gate-level simulation. [0013]
  • For example, a breakpoint can be set at a selected statement of the source code. A simulation breakpoint is set so that the simulation is halted at a simulation cycle where the value of the instrumentation signals indicate that the statement has become active . [0014]
  • With respect to visually tracing the source code during execution, the instrumentation logic is evaluated during gate-level simulation to determine a list of at least one active statement. The active statement is displayed as a highlighted statement. [0015]
  • With respect to source code analysis, cross-reference instrumentation data including the instrumentation signals can be used to count the number of times a corresponding statement is executed in the source code. For example, an execution count of the cross-referenced synthesizable statement is incremented when evaluation of the corresponding instrumentation logic indicates that the cross-referenced synthesizable statement is active. [0016]
  • Other features and advantages of the present invention will be apparent from the accompanying drawings and from the detailed description that follows below. [0017]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: [0018]
  • FIG. 1 illustrates the process of synthesizing RTL source code into a gate-level design. [0019]
  • FIG. 2 illustrates one embodiment of a modified process for generating a gate-level design. [0020]
  • FIG. 3 illustrates one embodiment of a method for instrumenting level-sensitive RTL source code. [0021]
  • FIG. 4 illustrates VHDL source code. [0022]
  • FIG. 5 illustrates the gate-level design synthesized from the RTL source code of FIG. 4. [0023]
  • FIG. 6 illustrates the VHDL source code of FIG. 4 modified in accordance with the method of FIG. 3. [0024]
  • FIG. 7 illustrates one embodiment of the gate-level logic synthesized from the modified RTL source code. [0025]
  • FIG. 8 illustrates sample Verilog source code before instrumentation. [0026]
  • FIG. 9 illustrates the Verilog source of FIG. 8 instrumented in accordance with the method of FIG. 3. [0027]
  • FIG. 10 illustrates the gate-level logic synthesized from the instrumented Verilog source code of FIG. 9. [0028]
  • FIG. 11 illustrates Verilog source code for a D flip-flop with asynchronous reset. [0029]
  • FIG. 12 illustrates one method of instrumenting event-sensitive RTL source code. [0030]
  • FIG. 13 illustrates the source code of FIG. 11 modified in accordance with the instrumentation process of FIG. 12. [0031]
  • FIG. 14 illustrates the gate-level logic synthesized for the instrumented source code of FIG. 13. [0032]
  • FIG. 15 illustrates Verilog source code for a D flip-flop with asynchronous reset. [0033]
  • FIG. 16 illustrates the Verilog source code of FIG. 15 after instrumentation in accordance with the method of FIG. 12. [0034]
  • FIG. 17 illustrates a method of instrumenting process activation. [0035]
  • FIG. 18 illustrates source code modified in accordance with the method of FIG. 17. [0036]
  • FIG. 19 illustrates an instrumented “case” statement. [0037]
  • FIG. 20 illustrates a process for decreasing the logic needed to instrument the source code. [0038]
  • FIG. 21 illustrates incorporating instrumentation within the synthesis process. [0039]
  • FIG. 22 illustrates a method of setting a breakpoint in RTL source code for use during gate-level simulation. [0040]
  • DETAILED DESCRIPTION
  • FIG. 1 illustrates a typical RTL source code synthesis process. HDL code including synthesizable RTL source code ([0041] 110) serves as input to a synthesis process 120. In one embodiment, the RTL source code 110 is synthesized in step 140 to produce a gate-level design 150. The gate-level design can be used for gate-level simulation as illustrated in step 160.
  • Typically the gate-level design comprises a hierarchical or flattened gate-level netlist representing the circuit to be simulated. The various signals in a design are referred to as nets. A hierarchical netlist is made of a list of blocks, whereas a flattened netlist comprises only one block. A block contains components and a description of their interconnection using nets. Components can be reduced to combinatorial or sequential logic gates, or they may be hierarchical blocks of lower level. [0042]
  • For example, the component may be a primitive gate denoting a single combinatorial logic function (e.g., AND, NAND, NOR, OR, XOR, NXOR, etc.) or a single storage element such as a flip-flop or latch for sequential logic. One example of a set of primitive gates is found in the generic library GTECH available from Synopsys, Inc. of Mountain View, Calif. [0043]
  • Alternatively the component may be an application specific integrated circuit (ASIC) library cell which can be represented by a set of primitive gates. One example of an ASIC library is the LCA300K ASIC library developed by LSI Logic, Inc., Milpitas, Calif. [0044]
  • A component may also be a programmable primitive that represents a set of logic functions and storage. One example of a programmable primitive is the configurable logic block (CLB) as described in The Programmable Gate Array Handbook, Xilinx Inc., San Jose, 1993. [0045]
  • Another example of a component is a macro block denoting a complex logic function such as memories, counters, shifters, adders, multipliers, etc. Each of these can be further reduced to primitive gates forming combinatorial or sequential logic. [0046]
  • Three major categories of tools are available to the designer to simulate and test the design. Software RTL simulators (such as ModelSim™ from Model Technology, Inc.) typically offer a high-level of abstraction for their debugging environment, but have limited performance in terms of speed and no in-situ capacity. Software gate-level simulators (such as QuickSim™ from Mentor Graphics Corporation) typically offer limited level of abstraction and speed as well as no in-situ capacity. Hardware gate-level simulators (such as Cobalt™ and System Realizer™ from Quickturn Inc., Avatar™ from Ikos, and fast-prototyping systems usually built from FPGAs) typically offer very good performance in terms of speed and in-situ capacity, but a limited debugging environment. [0047]
  • When testing the design described by the HDL source code a designer may choose to simulate and validate the design at the RTL source code level (i.e., RTL simulation). RTL simulation typically permits the designer to set breakpoints in the source code, navigate the design hierarchy, view variables and signals and trace the value of these variables and signals. [0048]
  • When testing complex designs, millions or billions of test vectors may need to be applied in order to adequately test the design. Hardware accelerators or emulators can be used with the gate-level design to test the design at a much greater speed than what is typically possible through software simulation (i.e. either software RTL simulation or software gate-level simulation). Unfortunately, the gate-level design generated in [0049] step 150 typically includes none of the high-level information available in the RTL source code 110. As a result, features available during RTL simulation such as setting breakpoints or analyzing the source code coverage are not available during gate-level simulation.
  • Instrumentation is the process of preserving high-level information through the synthesis process. Instrumentation permits simulation of a gate-level netlist at the level of abstraction of RTL simulation by preserving some of the information available at the source code level through the synthesis process. [0050]
  • FIG. 2 illustrates one embodiment of the instrumentation process in which instrumentation is integrated with the synthesis process. [0051] RTL source code 210 is provided to the synthesis process 220. The synthesis process 120 of FIG. 1 has been modified to include an instrumentation step 234. After instrumentation the instrumented code is then synthesized in step 240 as the original RTL source code was in step 140 of FIG. 1.
  • In one embodiment, instrumentation results in generating a modified gate-level design to permit reconstitution of the flow of execution of the original RTL source code during gate-level simulation. Generally instrumentation logic is created for a synthesizable statement in the RTL source code either by modifying the RTL source code or by analyzing the RTL source code during the synthesis process. The instrumentation logic provides an output signal indicative of whether the corresponding synthesizable statement is active. A gate-level design including the instrumentation output signal is then synthesized. Referring to FIG. 2, the resulting gate-[0052] level design 250 contains additional logic to create the additional instrumentation output signals referenced in instrumentation data 238.
  • In an alternative embodiment, the RTL source code is analyzed to generate a cross-reference database as [0053] instrumentation data 238 without modifying the gate-level design. The cross-reference database indicates the combination of already existing signals in the form of instrumentation logic that can be evaluated during simulation to determine whether a particular line of the RTL source code is active. The cross-reference database contains a cross-reference between these instrumentation logic output signals and the position of the corresponding statement in the source code. The instrumentation data 238 is likely to contain considerably more complex logic to evaluate during simulation when the approach of not modifying the gate-level design (i.e., “pure” cross-reference database) is taken.
  • The two approaches have tradeoffs. The gate-level design modification technique does not require special knowledge of the target simulation environment. Moreover, the gate-level design modification technique significantly reduces or eliminates the complexity of the logic to be evaluated during simulation to the extent that emulator or accelerator hardware triggering circuitry can be used to take an action when the corresponding statement is executed. [0054]
  • For example, the hardware triggering circuitry may be used to halt the simulation at a particular statement or to count the number of times a particular statement is executed. The resulting gate-level design used during simulation, however, will not be the design actually used for production thus simulation may not verify accurately the behavior of the gate-level design used for production. Furthermore, simulation of modified gate-level design may require more physical resources in hardware than the original design alone if gates have been added in order to implement the instrumentation logic. [0055]
  • Alternatively, the pure cross-reference database technique typically results in greater complexity of instrumentation logic to evaluate during simulation, but does not otherwise affect the original gate-level design. The greater complexity, however, may prevent the use of the hardware triggering circuitry to halt the simulation or to track source code coverage. Thus the pure cross-reference database technique may result in a significantly slower simulation time. Furthermore, since the evaluation may be performed by software, direct verification of the gate-level design in the target system through in-situ verification may not be possible. The instrumentation data including the logic added for instrumentation purposes can be eliminated after testing, however, without disrupting the gate-level design. [0056]
  • In essence the gate-level design modification technique greatly simplifies the analysis and the instrumentation logic required for cross-referencing by modifying the gate-level design to create unique signals and therefore simpler logic to evaluate (i.e., a single signal). The resulting instrumentation logic cross-referenced in the [0057] instrumentation data 238 is easily evaluated during simulation. Various embodiments of instrumentation may combine the gate-level design modification technique or the pure cross-referencing technique in order to trade off simulation speed, density, and verification accuracy.
  • If the gate-level simulator, hardware accelerator, or emulator (e.g., through the use of a logic analyzer which can be external to the emulator) has the capacity to set breakpoints whenever certain signals reach a given value, then it is possible to implement breakpoints corresponding to RTL simulation breakpoints in the gate-level design. Whenever the user specifies a breakpoint in the RTL source code, the condition can be converted to a comparison with key signals in the gate-level design. [0058]
  • [0059] Instrumentation data 238 identifies the RTL source code statements each instrumentation output signal is associated with. Instrumentation data 238 is generated during the instrumentation process of step 234. In one embodiment, the instrumentation data is implemented as gates that can then be simulated by the target-level simulator. By examining the state of each instrumentation output signal during gate-level simulation, the user can determine which portions of RTL source code are being simulated. This in turn permits the designer to determine RTL source code coverage. By tracking the instrumentation signal values for each cycle of execution, the designer can determine how many times each line of the RTL source code has been activated.
  • The [0060] instrumentation data 238 can be used during simulation to ensure every possible state transition has been tested. For example, a Finite State Machine analyzer can determine from the values of the instrumentation output signals whether every possible state transition has been tested.
  • The [0061] instrumentation data 238 can also be used to enhance the source code display. In one embodiment, the source code is repositioned on the display so as to indicate the execution paths that are active during a current cycle. In another embodiment, the active source code in a given cycle is highlighted to indicate that it is active. This permits the designer to visually see the process flow without having to determine the value of each signal. In one embodiment, the instrumentation data 238 is used to enhance the display of the original RTL source code rather than the source code resulting from instrumentation.
  • An integrated circuit design is typically built by assembling hierarchical blocks. In VHDL, a block corresponds to an entity and architecture. In Verilog, a block corresponds to a module. In both HDLs, a block typically includes a declarative portion and a statement portion. The declarative portion generally includes the list of the ports or connectors. [0062]
  • The statement portion describes the block's behavior and is typically where a designer needs help when debugging a design. The statement portion includes concurrent signal assignment statements and sequential statements. [0063]
  • Concurrent signal assignment statements assign a logic expression to a signal. The signal is typically available for viewing at all times and thus breakpoints can be set in accordance with when the signals reach a certain value. [0064]
  • Sequential statements assign values depending upon the execution flow of the sequence. Sequential statement analysis is typically where the designer needs the greatest aids in debugging the design. [0065]
  • Sequential statements are typically found in VHDL “processes” and in Verilog “always” blocks. Processes or always blocks can be built of an unlimited combination of sequential statements including loops, conditional statements, and alternatives. There are at least two classes of sequential statements: level-sensitive and event-sensitive. Level-sensitive sequential statements only depend on the value of the inputs and can be synthesized to logic networks of combinatorial gates and latches. Event-sensitive sequential statements additionally require sequential logic such as flip-flops. [0066]
  • In one embodiment, level-sensitive RTL source code is instrumented by creating and associating one output signal with each list of synthesizable sequential statements. A list can consist of one or more sequential statements. [0067]
  • In one embodiment, each statement is a list. In an alternative embodiment, each list corresponds to a branch of the RTL source code. A list corresponding to a branch typically comprises a plurality of adjacent sequential statements, but may comprise a single sequential statement. Only one output signal is needed for each list of synthesizable sequential statements in a branch rather than for every sequential statement in the source code. Examples of sequential statements that create branches in the RTL source code are conditional statements such as IF-THEN statements and SELECT-CASE statements. [0068]
  • FIG. 3 illustrates one method of modifying RTL source code for level-sensitive code. Generally, a unique local variable is created for each list of adjacent sequential statements in [0069] step 310. The level sensitive code instrumentation includes the step of modifying the RTL source code to initialize each of these unique variables to zero at the beginning of the process being instrumented in step 320. One unique variable assignment statement is inserted into each list of adjacent sequential statements corresponding to an executable branch in step 330. The assignment statement sets the unique variable to one. At the end of the process all the unique local variables are assigned to global signals in step 340. Steps 310 and 320 are more generically referred to as initialization. Step 330 is referred to as flow instrumentation. Step 340 is referred to as “gathering.”
  • FIG. 4 illustrates non-instrumented VHDL source code. The [0070] VHDL source code 400 includes nine sequential statements within the process block. Eight of these nine statements are non-signal assignment sequential statements. These eight sequential statements form six statement lists or executable branches of the code. IF-THEN statement 410 comprises one list. Signal assignment statement 420 comprises a second list. Statements 430, 440, 450 and 490 comprise a third list because they would be executed sequentially within the same execution path. Statements 460, 470, and 480 form individual lists.
  • FIG. 5 illustrates one embodiment of the [0071] logic 500 resulting from the synthesis of the RTL source code of FIG. 4. This figure may be used for comparison with the gate level design generated from instrumented code described below.
  • FIG. 6 illustrates the source code of FIG. 4 after instrumentation as described in FIG. 3. The added statements are italicized for emphasis. For example, [0072] line 612 has been added to the source code to create six unique local variables (TRACE1 through TRACE6), one for each of the six identified lists, in accordance with step 310 of FIG. 3.
  • In accordance with [0073] step 330 of FIG. 3, a trace variable assignment statement has been added adjacent to each of the lists. Referring to FIGS. 4 and 6, variable assignment statement 630 has been added adjacent to the first list comprising statement 410. Variable assignment statement 632 has been added adjacent to the second list comprising statement 420. Variable assignment statement 634 has been added adjacent to the third list comprising statements 430, 440, 450 and 490. Variable assignment statement 636 has been added adjacent to the fourth list comprising statement 460. Similarly, variable assignment statements 638 and 640 have been added adjacent to the fifth list comprising statement 470 and the sixth list comprising 480, respectively. Each of variable assignment statements 630 through 640 assigns a unique local variable the value of one.
  • [0074] Code portion 620 is added to initialize the unique local variables to zero at the beginning of the process in accordance with step 310 of FIG. 3.
  • Each of the local variables is assigned to a global output signal in accordance with [0075] step 340 of FIG. 3 by code portion 650. If required by the HDL, the global signals are declared by code portion 610. Similarly, the trace variables are declared by code portion 612.
  • In one embodiment, the unique local variables can actually be a single array where each “unique variable” or trace variable corresponds to a different position in the array. Similarly, in one embodiment, the additional global signals are described by an array where each of the global signals is represented by a different index of the array. [0076]
  • Coding practices for VHDL generally require variables to be used within the process and a signal assignment at the end of the process to propagate the variable values at the end of the process. In one embodiment, markers such as variable assignment statements are used to track the execution paths. Markers such as variable assignment statements are not typically synthesized into logic indicating the variable values, thus the variable assignment statements are used in conjunction with signal assignment statements in order to produce signals indicating whether various portions of the synthesized code are being executed. [0077]
  • If permitted by the HDL, however, global signal assignments can be used in lieu of local variable assignment statements. This would simplify the process of FIG. 3 in that there would be no need to create or initialize local variables. In addition the step of assigning the local variables to global signals could be eliminated because values are assigned directly. The key is ensuring that there is a unique output signal created and associated with each list of sequential statements regardless of the coding practice used to achieve this goal. [0078]
  • FIG. 7 illustrates one embodiment of the [0079] logic 700 generated through instrumentation. In particular, FIG. 7 illustrates the additional gate-level logic added to generate signals SIG_TRACE1 through SIG_TRACE6 from synthesis of the modified source code.
  • FIG. 8 illustrates a Verilog “always” [0080] block 800. FIG. 9 illustrates the same code after instrumentation in accordance with the process of FIG. 3. Due to Verilog syntax requirements, “BEGIN-END” statements were used to properly group the instrumentation variable with the other statements in each executable path.
  • Although the code of FIG. 8 results in a latch, application of the technique of FIG. 3 to the source code of FIG. 8 ensures that the instrumentation output signals are the result of combinatorial logic only. Thus the logic for determining which lines of code are active can be purely combinatorial even when the RTL source code is synthesized into latches. [0081]
  • FIG. 10 illustrates one embodiment of gate-[0082] level logic 1100 generated by synthesis of the instrumented “always” block 900 of FIG. 9. The instrumentation signals SIG_TRACE1, SIG_TRACE2, SIG_TRACE3, and SIG_TRACE4 are the result of combinatorial logic only.
  • Referring to FIG. 2, the [0083] instrumentation data 238 can be stored in a cross-reference file. In one embodiment, the cross-reference file contains a mapping between original source code line numbers and instrumentation signals. Each time an instrumentation variable (and its associated signal) is added to the source code, all the line numbers of the statements in the list associated with the instrumentation variable are added to the file. This cross-reference file (i.e., instrumentation data 238) can be used by the gate-level simulation environment to convert the designer's breakpoints into actual conditions on instrumentation signals.
  • A more sophisticated method than that illustrated in FIG. 3 is required to instrument RTL source code having references to signal events. Typically such source code is used to describe edge-sensitive devices. References to signal events typically imply flip-flops. A signal event is a signal transition. Thus any signal computed from a signal transition references a signal event. [0084]
  • FIG. 11 illustrates [0085] sample VHDL code 1100 with references to a signal event. VHDL code 1100 implements a D-type flip-flop with asynchronous reset. The event in this example is a transition on the clock signal (CLK) as referenced by the term “CLK'EVENT.”
  • In accordance with VHDL specifications signals can have various attributes associated with them. A function attribute executes a named function on the associated signal to return a value. For example, when the simulator executes a statement such as CLK'EVENT, a function call is performed to check this property of the signal CLK. In particular, CLK'EVENT returns a Boolean value signifying a change in value on the signal CLK. Other classes of attributes include value attributes and range attributes. [0086]
  • In [0087] VHDL code 1100, the signal CLK has a function attribute named “event” associated with it. The predicate CLK'EVENT is true if an event (i.e., signal transition) has occurred on the CLK signal. Assigning a value to a signal (i.e., a signal transaction) qualifies as an event only if the transaction results in a change in value or state for the signal. Thus the predicate CLK'EVENT is true whenever an event has occurred on the signal CLK in the most recent simulation cycle. The predicate “IF (CLK'EVENT and CLK=‘1’)” is true on the rising edge of the signal CLK.
  • Depending upon the specifics of the HDL, another function such as RISING_EDGE(CLK) might be used to accomplish the same result without the use of attributes. The function RISING_EDGE(CLK) is still an event even though the term “event” does not appear in the function. [0088]
  • FIG. 12 illustrates a method of instrumenting source code having references to signal events. In [0089] step 1210, every signal event is sampled using a fast clock. In other words, every signal whose state transition serves as the basis for the determination of another signal is sampled. An instrumentation signal event corresponding to the original signal event is generated in step 1220. Any attributes of the original signal must similarly be reproduced based on the instrumentation signal if the source code uses attributes of the original signal event.
  • In [0090] step 1230, every process that references a signal event is duplicated. In step 1240, each list of sequential statements within the duplicate version of the code is replaced by a unique local variable assignment statement. In step 1250, each time a signal event is referenced in the duplicated version of the code, it is replaced by the sampled signal event computed in step 1210. The modified RTL source code can then be synthesized in step 1260 to generate gate-level logic including the instrumentation output signals.
  • FIG. 13 illustrates application of the method of FIG. 12 to the source code of FIG. 11. In order to detect signal events properly for instrumentation, the signal events are sampled using a fast clock provided during gate-level simulation (i.e., FAST_CLK). FAST_CLK has a higher frequency than the CLK signal and thus permits detecting transition edges before signals depending upon CLK (including CLK itself) can. [0091]
  • The only signal event referenced in FIG. 11 is a transition in the signal CLK indicated by the term CLK'EVENT. Thus an instrumentation version of CLK'EVENT is created by sampling the signal CLK using FAST_CLK. The signal FAST_CLK has a higher frequency than the signal CLK. [0092]
  • [0093] Code portion 1310 samples the CLK signal on every rising edge of the signal FAST_CLK to generate a sampled version of the signal CLK named SAMPLED_CLK. The instrumentation version of CLK'EVENT is CLK_EVENT which is generated in code portion 1310 based on SAMPLED_CLK. The instrumentation signal CLK_EVENT (corresponding to CLK'EVENT) is determined by comparison of signals SAMPLED_CLK and CLK. The signal CLK_EVENT is true only when the signal SAMPLED_CLK is not the same as CLK, thus indicating a transition has occurred in the signal CLK.
  • Although not required for this example, [0094] code portion 1310 also illustrates the generation of instrumentation clock signal attributes based on SAMPLED_CLK. For example, the signal CLK'STABLE is the complement of CLK'EVENT. Thus code portion 1310 indicates the instrumentation version of the attribute CLK'STABLE (i.e., CLK_STABLE) computed on the instrumentation clock signal (i.e., SAMPLED_CLK). The signal CLK'LASTVALUE is a function signal attribute that returns the previous value of the signal CLK. The instrumentation version (i.e., CLK_LASTVALUE) of the attribute CLK'LASTVALUE is similarly computed on the instrumentation clock signal, SAMPLED_CLK.
  • Although CLK_LASTVALUE is the same as the sampled clock signal, SAMPLED_CLK, [0095] code 1310 introduces the intermediate signal SAMPLED_CLK for purposes of illustrating sampling of the CLK signal. The signal CLK_LASTVALUE can be defined in lieu of SAMPLED_CLK in order to eliminate the introduction of an unnecessary intermediate signal SAMPLED_CLK and the subsequent step of assigning CLK_LASTVALUE the value of SAMPLED_CLK.
  • Neither CLK_LASTVALUE nor CLK_STABLE are needed in this example for [0096] code portion 1320, however, code portion 1310 serves as an example of how to generate instrumentation versions of signal attributes typically used to describe edge-sensitive devices.
  • [0097] Code portion 1320 represents the instrumented duplicate of original code portion 1330. The process of code portion 1330 references the event CLK'EVENT in the IF-ELSIF statement. In code portion 1320, all sequential statements (except the statement referencing an event) have been replaced with unique local variable assignment statements. These statements assign a local variable (i.e., TRACE1, TRACE2) the value “1.” Code portion 1320 also includes statements to create and initialize these unique local variables.
  • In accordance with [0098] step 1240, every occurrence of a signal event is replaced with the sampled version of that event. Thus, for example, references to CLK'EVENT in code portion 1330 are replaced with references to CLK_EVENT in code portion 1320. Moreover, the process parameter list is modified to include the generated signal CLK_EVENT. FIG. 14 illustrates the gate-level logic 1400 resulting from synthesis of the code in FIG. 13.
  • FIG. 15 illustrates [0099] Verilog source code 1500 for a D flip-flop with asynchronous reset. FIG. 16 illustrates the code 1600 resulting from modifying source code 1500 in accordance with the method of FIG. 12.
  • One advantage of the instrumentation approach of FIG. 12 is that the gates generated by the synthesis tool are the same ones that would be generated if the source code had not been instrumented. The gates generated for the instrumentation logic are not intermingled with the gates generated from the non-instrumented source code. This permits design verification with gate-level logic that does not need to be re-verified after instrumentation verification. Thus the designer can verify the result of synthesis at the gate level while retaining RTL breakpoint feature. In some cases, however, the synthesis tool may not recognize that the same code appears twice. This may incur an additional relatively expensive phase of resource sharing in order to achieve the same performance results as the process illustrated in FIG. 3. [0100]
  • One advantage of the instrumentation process of FIG. 3 over that of FIG. 12, however, is that a synthesis tool can typically analyze the source code to detect obvious resource sharing. [0101]
  • The instrumentation methods of FIGS. 3 and 12 permit detecting any path that has been taken while a VHDL process or a Verilog “always” block is active. Tracking the activation of each process permits further analysis. [0102]
  • FIG. 17 illustrates a method of instrumenting the activation of the processes (or “always” blocks) themselves for subsequent determination of whether the process is active during gate-level simulation . [0103]
  • In [0104] step 1710, the sensitivity list of a process is identified. In step 1720, logic is generated to compare the signals in the sensitivity list between consecutive simulation cycles. Subsequently, during gate-level simulation in step 1730, a determination is made as to whether an event has occurred on any of the sensitivity list signals. Each simulation cycle that a signal indicates a difference (i.e., a signal event has occurred), the process is active as indicated by step 1740. Otherwise, if no events have occurred on any of the sensitivity list signals, the process is inactive as indicated by step 1750.
  • FIG. 18 illustrates the code added to determine if process P[0105] 1 is active. The added code is italicized. The sensitivity list of process P1 includes signals a, b, and c. In accordance with step 1720 of FIG. 17, code section 1810 creates sampled versions of a, b, and c using FAST_CLK as described above. The sampled versions of a, b, and c are SAMPLED_A, SAMPLED_B, and SAMPLED_C, respectively.
  • [0106] Code section 1820 determines if an event has occurred on each of the sensitivity list signals. The test “(SAMPLED_A /=A)” is true if an event occurs with respect to signal A. Similarly “(SAMPLED_B /=B)” and “(SAMPLED_C/=C)” indicate whether an event has occurred with respect to signals B and C. Process P1 is active if any one of these tests is true. Thus the variable P1_ACTIVE is generated by combining each of these signal events using the logical OR function in code section 1820. Thus signal P1_ACTIVE indicates whether process P1 is active.
  • Process instrumentation data can be added to the instrumentation data cross-reference file in order to enhance the source code display. For example, the active process in a given cycle can be highlighted to indicate it is active. This permits the designer to visually see the active processes without having to determine the value of each signal. In one embodiment, the instrumentation data is used to enhance the display of the original RTL source code rather than the source code resulting from instrumentation. [0107]
  • The instrumentation techniques presented result in gate level designs providing explicit instrumentation signals to indicate that some specific portion of the source code is active. The number of instrumentation signals tends to increase with the complexity of the system being modeled. [0108]
  • Some optimizations may be performed to decrease the number of instrumentation signals. At least one execution path will be active any time a process is activated. As a result, the TRACE[0109] 1 variable in the examples of FIGS. 6 and 9 tend to provide no additional information and thus SIG_TRACE1 is somewhat trivial as can be seen from the synthesized logic of FIGS. 7 and 10. Thus at least one trace variable (and therefore one output signal trace) can typically be eliminated.
  • In some cases the execution status of each branch of the code can be determined even though every branch is not explicitly instrumented. To verify the execution status of every branch, the instrumentation process need only ensure that each branch is instrumented either explicitly or implicitly through the instrumentation of other branches. [0110]
  • In some instances, the capacity of hardware triggers can be used to eliminate some of the instrumentation by combining several signals into one condition. The number of gates simulated can be reduced by replacing logical AND conditions that appear in the equations of instrumentation signals by simulator-specific triggers. [0111]
  • For example, consider the instrumented CASE [0112] statement code fragment 1910 illustrated in FIG. 19. For purposes of example, only the trace variable assignment statements are shown for the four possible cases. A synthesis tool will generate four comparisons with the vector “opcode.” Each trace variable is associated with one of the possible values of opcode. Clearly, however, the additional logic is unnecessary because setting a breakpoint on any one of the case conditions corresponds to setting a trigger on the vector for the corresponding value of “opcode.”
  • FIG. 20 illustrates a method for optimizing the instrumentation process. In particular, an instrumentation signal is selected in [0113] step 2010. In step 2020, a determination is made to whether the equation of the current signal can be expressed as a logical AND between a signal and a simplified expression. If so, then the AND gate should be eliminated in step 2030 and the extracted signal can be added to the trigger conditions during simulation in step 2040. If triggers can be activated on zeroes as well as ones, then step 2020 can also determine whether an equation can be simplified as a logical negation of a subexpression and the logical negation of the subexpression can be added to the trigger conditions during simulation in step 2040 where appropriate. Step 2020 would then be applied recursively until the equation cannot be further simplified. This process is then applied to all of the instrumentation signals.
  • For example, signal TRACE[0114] 4 is the result of performing a logical AND between opcode(0) and opcode(1). Thus TRACE4 is active only when opcode=“11”. In accordance with FIG. 20, the AND gate can be removed and the simulator trigger conditions would be changed from TRACE4=1 to “OPCODE(0)=1 AND OPCODE(1)=1.” This process would then be applied recursively to all signals remaining in the trigger condition. Thus if OPCODE(0) happened to be the result of an AND between two other signals, the AND gate could again be eliminated from the synthesized gate-level design and the trigger conditions could be updated accordingly as long as no other signals used “OPCODE(0)” as an input. If no other logic uses “OPCODE(0)” as an input, then the trigger conditions can be updated to refer to the signals used to generate OPCODE(0) and the gate-level netlist AND gate can safely be eliminated. More generally, any optimization that consists of eliminating gates and other elements by transferring the implementation of the instrumentation logic to the logic analyzer of the target simulator can be performed.
  • Where permitted by the gate-level simulator, the instrumentation required for detecting activation of a process may similarly be reduced. In particular, greater efficiency may be possible by keeping a list of all the signals in the process sensitivity list and then testing whether events occurred on the signals in the sensitivity list. Further optimization may be made possible by sharing the logic for signals that appear on the sensitivity list of more than one process. The original signal can be sampled once initially. A comparison is made between the initial value and the current value of the signal to generate an event signal indicative of whether an event has occurred on that signal. The event signal can then be used for instrumentation of processes with events and for tracking process activation. [0115]
  • FIGS. 3, 12, and [0116] 17 illustrate methods of modifying the original RTL source code for instrumenting processes and level-sensitive and edge-sensitive source code. Trace variables (i.e., instrumentation variables) can be used to track the execution of any path within the source code. Additional output signals are generated from instrumentation variables in order to detect the execution paths of the source code. In the illustrated embodiments, the instrumentation variables are reset at the beginning of a process and the signals are assigned at the end of the process in order to ensure that all the signals are assigned regardless of which execution path is taken inside the process.
  • In an alternative embodiment, the signals might be directly assigned in the execution path of the process. Typically, this alternative embodiment would force the synthesis tool to generate complicated structures including latches due to the nature of HDLs and simulation rules. [0117]
  • The methods of FIGS. 3, 12, and [0118] 17 can be applied to the source code before the source code is synthesized. Thus in one embodiment the steps that modify the RTL source code can be performed before but entirely independently of the synthesis process itself.
  • FIG. 21 illustrates an embodiment in which the instrumentation data is generated entirely within the synthesis process. The process of creating output signals associated with synthesizable statements in the source code and then synthesizing the source code into a gate-level design including the output signal can be incorporated into the synthesis tool itself so that modification of the RTL source code is not required. [0119]
  • For example, one of the steps performed by a synthesis tool for generation of the gate-level design is parsing the RTL source code. Parsing the RTL source code results in a parser data structure that is subsequently used to generate the gate-level design. Instead of modifying the source code, the synthesis tool can simply set markers inside the parser data structure. [0120]
  • FIG. 22 illustrates one application of using the instrumentation signals for tracing execution flow using breakpoints. In [0121] step 2210, the user sets a breakpoint at a specified line number of the source code. The specified line number is then associated with one of the instrumented lists of statements in step 2220. In step 2230, the instrumentation signal for the associated list is identified as the breakpoint output signal.
  • During the gate-level simulation run, the active lists (identified by transitions in their corresponding instrumentation signals) may be highlighted and displayed for the user as indicated in [0122] step 2240. For example, the active lists may be portrayed in a different color than the inactive lists. Alternatively, the active lists may be displayed using blinking characters, for example. The instrumentation data file can be used to associate an instrumentation signal with a list of source code line numbers to be highlighted.
  • In response to a 0 to 1 transition in the breakpoint output signal, the simulation can be stopped as indicated in [0123] step 2250. Thus through instrumentation the designer has the ability to effectively set breakpoints in the RTL source code which can be acted upon during RTL simulation.
  • The methods of instrumentation may be implemented by a processor responding to a series of instructions. In various embodiments, these instructions may be stored in a computer system's memory such as random access memory or read only memory. [0124]
  • The instructions may be distributed on a nonvolatile storage medium for subsequent access and execution by the processor. Typically the instructions are stored in the storage medium for distribution to a user. The instructions may exist in an application program form or as a file stored in the storage medium. The instructions are transferred from the nonvolatile storage medium to a computer system for execution by the processor. [0125]
  • In one embodiment, the program or file is installed from the storage medium to the computer system such that the copy of the instructions in the nonvolatile storage medium is not necessary for performing instrumentation. In another embodiment, the program or file is configured such that the original nonvolatile storage medium is required whenever the instructions are executed. [0126]
  • Nonvolatile storage mediums based on magnetic, optical, or semiconductor memory storage principles are readily available. Nonvolatile magnetic storage mediums include floppy disks and magnetic tape, for example. Nonvolatile optical storage mediums include compact discs, digital video disks, etc. Semiconductor-based nonvolatile memories include rewritable flash memory. [0127]
  • Instrumentation allows the designer to perform gate-level simulation of synthesized RTL designs with source-level debugging. In addition, the instrumentation process allows the designer to examine source code coverage during simulation. [0128]
  • In the preceding detailed description, the invention is described with reference to specific exemplary embodiments thereof. Various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. [0129]

Claims (17)

What is claimed is:
1. A method of simulation comprising the steps of:
a) synthesizing an original synthesizable register transfer level (RTL) source code to generate a gate-level netlist and cross-reference instrumentation data including instrumentation logic for at least one synthesizable statement; and
b) facilitating simulation of the gate-level netlist, wherein evaluation of the instrumentation logic indicates the execution status of the synthesizable statement identified by the cross-reference instrumentation data.
2. The method of
claim 1
wherein the cross-reference instrumentation data is generated for each list of synthesizable statements in the original source code.
3. The method of
claim 1
wherein the cross-reference data includes a reference to the position of the cross-referenced synthesizable statement in the source code.
4. The method of
claim 1
wherein step a) is performed during the synthesis process.
5. The method of
claim 1
wherein the gate-level netlist contains at least one gate implementing part of an instrumentation logic.
6. The method of
claim 1
wherein the original source code is not modified to synthesize the gate-level design.
7. The method of
claim 4
wherein for a selected synthesizable statement the corresponding logic in the cross-reference instrumentation data consists of a single signal reference.
8. The method of
claim 1
wherein the original source code is modified in step a) to produce at least one gate implementing part of the instrumentation logic.
9. The method of
claim 6
wherein for a selected synthesizable statement the corresponding cross-reference instrumentation data references a single signal.
10. The method of
claim 1
wherein the original source code includes edge-sensitive statements.
11. The method of
claim 1
wherein the original source code includes level-sensitive statements.
12. The method of
claim 1
further comprising the step of:
d) displaying the cross-referenced statement as a highlighted statement during simulation in accordance with the execution status.
13. The method of
claim 1
further comprising the step of:
d) incrementing an execution count of the cross-referenced synthesizable statement when the corresponding instrumentation logic indicates the synthesizable statement is active.
14. A storage medium having stored therein processor executable instructions for simulating a gate level design from a synthesizable source code, wherein when executed the instructions enable the processor to perform the steps of:
a) synthesizing register transfer level (RTL) source code into a gate-level netlist and cross-reference instrumentation data that includes instrumentation logic indicative of the execution status of at least one synthesizable statement within the RTL source code;
b) facilitating simulation of the gate-level netlist, wherein evaluation of the instrumentation logic in accordance with the cross-reference instrumentation data indicates the execution status of a cross-referenced synthesizable statement in the RTL source code.
15. A method of gate-level simulation comprising the steps of:
a) generating instrumentation logic indicative of an execution status of each branch of register transfer level (RTL) source code having a list of at least one synthesizable sequential statement as cross-reference instrumentation data;
b) synthesizing the source code into a gate-level netlist;
c) setting a breakpoint at a selected statement of the source code;
d) identifying the instrumentation logic output signal corresponding to the list associated with the selected statement from the cross-reference instrumentation data as a simulation breakpoint; and
e) simulating the gate-level design, wherein simulation is halted at a simulation cycle that results in the simulation breakpoint being active.
16. The method of
claim 15
wherein step e) further comprises the steps of:
i) evaluating the cross-reference data to determine an active statement; and
ii) displaying the active statement as a highlighted statement.
17. The method of
claim 16
wherein step e)(ii) further comprises the step of highlighting the list associated with the active statement.
US09/122,493 1998-07-24 1998-07-24 Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging Expired - Lifetime US6336087B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US09/122,493 US6336087B2 (en) 1998-07-24 1998-07-24 Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging
US09/127,584 US6240376B1 (en) 1998-07-24 1998-07-31 Method and apparatus for gate-level simulation of synthesized register transfer level designs with source-level debugging

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/122,493 US6336087B2 (en) 1998-07-24 1998-07-24 Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US09/127,584 Continuation-In-Part US6240376B1 (en) 1998-07-24 1998-07-31 Method and apparatus for gate-level simulation of synthesized register transfer level designs with source-level debugging

Publications (2)

Publication Number Publication Date
US20010011212A1 true US20010011212A1 (en) 2001-08-02
US6336087B2 US6336087B2 (en) 2002-01-01

Family

ID=22403022

Family Applications (1)

Application Number Title Priority Date Filing Date
US09/122,493 Expired - Lifetime US6336087B2 (en) 1998-07-24 1998-07-24 Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging

Country Status (1)

Country Link
US (1) US6336087B2 (en)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030101041A1 (en) * 2001-10-30 2003-05-29 International Business Machines Corporation Annealing harvest event testcase collection within a batch simulation farm
US20030101038A1 (en) * 2001-11-30 2003-05-29 International Business Machines Corporation Centralized disablement of instrumentation events within a batch simulation farm network
US20030101039A1 (en) * 2001-10-30 2003-05-29 International Business Machines Corporation Maintaining data integrity within a distributed simulation environment
US20030101035A1 (en) * 2001-11-30 2003-05-29 International Business Machines Corporation Non-redundant collection of harvest events within a batch simulation farm network
US20030121009A1 (en) * 2001-12-24 2003-06-26 Jong-Hong Bae Method for generating register transfer level code
US20030125915A1 (en) * 2001-11-30 2003-07-03 International Business Machines Corporation Count data access in a distributed simulation environment
US20030135354A1 (en) * 2001-11-30 2003-07-17 International Business Machines Corporation Tracking converage results in a batch simulation farm network
US20050149313A1 (en) * 2003-12-31 2005-07-07 International Business Machines Corp. Method and system for selective compilation of instrumentation entities into a simulation model of a digital design
US20050240824A1 (en) * 2004-04-08 2005-10-27 International Business Machines Corporation Method and apparatus for breakpoint analysis of computer programming code using unexpected code path conditions
US20060277518A1 (en) * 2005-06-06 2006-12-07 Matsushita Electric Industrial Co., Ltd. High order synthesizing method and high order synthesizing apparatus
US7292970B1 (en) * 2002-04-30 2007-11-06 Unisys Corporation Finding unexercised logic for use in code coverage testing
US7305466B1 (en) * 1999-05-28 2007-12-04 Teradyne, Inc. Network fault isolation
US20080307391A1 (en) * 2007-06-11 2008-12-11 Microsoft Corporation Acquiring coverage data from a script
US7502728B1 (en) * 2002-04-30 2009-03-10 Unisys Corporation Code coverage testing in hardware emulation
WO2012118859A1 (en) * 2011-03-03 2012-09-07 Synopsys, Inc. Technique for honoring multi-cycle path semantics in rtl simulation
US20120233578A1 (en) * 2011-03-08 2012-09-13 Oracle International Corporation Performance counters for integrated circuits
US20130111423A1 (en) * 2011-10-27 2013-05-02 Liang Xia Tool suite for rtl-level reconfiguration and repartitioning
US20140019780A1 (en) * 2012-07-16 2014-01-16 International Business Machines Corporation Active power dissipation detection based on erronous clock gating equations
US20160328505A1 (en) * 2014-05-09 2016-11-10 Zipalog, Inc. Computer implemented system and method of identification of useful untested states of an electronic design
US20230070516A1 (en) * 2021-09-07 2023-03-09 International Business Machines Corporation Logical clock connection in an integrated circuit design
US11704448B2 (en) 2014-05-09 2023-07-18 Zipalog, Inc. Computer implemented system and method of translation of verification commands of an electronic design
CN116522830A (en) * 2023-06-30 2023-08-01 奇捷科技(深圳)有限公司 Logic function correcting method and device for testing design and layout wiring stage
US11907634B2 (en) 2021-09-01 2024-02-20 International Business Machines Corporation Automating addition of power supply rails, fences, and level translators to a modular circuit design

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6138266A (en) 1997-06-16 2000-10-24 Tharas Systems Inc. Functional verification of integrated circuit designs
US6931572B1 (en) 1999-11-30 2005-08-16 Synplicity, Inc. Design instrumentation circuitry
US6823497B2 (en) 1999-11-30 2004-11-23 Synplicity, Inc. Method and user interface for debugging an electronic system
US6581191B1 (en) 1999-11-30 2003-06-17 Synplicity, Inc. Hardware debugging in a hardware description language
US7065481B2 (en) * 1999-11-30 2006-06-20 Synplicity, Inc. Method and system for debugging an electronic system using instrumentation circuitry and a logic analyzer
US7072818B1 (en) * 1999-11-30 2006-07-04 Synplicity, Inc. Method and system for debugging an electronic system
US7356786B2 (en) * 1999-11-30 2008-04-08 Synplicity, Inc. Method and user interface for debugging an electronic system
US7240303B1 (en) 1999-11-30 2007-07-03 Synplicity, Inc. Hardware/software co-debugging in a hardware description language
US7168074B1 (en) * 2000-09-29 2007-01-23 Intel Corporation Runtime prediction framework for CPU intensive applications
US7222315B2 (en) * 2000-11-28 2007-05-22 Synplicity, Inc. Hardware-based HDL code coverage and design analysis
US6625786B2 (en) 2000-12-14 2003-09-23 Tharas Systems, Inc. Run-time controller in a functional verification system
US6470480B2 (en) * 2000-12-14 2002-10-22 Tharas Systems, Inc. Tracing different states reached by a signal in a functional verification system
US6629297B2 (en) * 2000-12-14 2003-09-30 Tharas Systems Inc. Tracing the change of state of a signal in a functional verification system
US6691287B2 (en) 2000-12-14 2004-02-10 Tharas Systems Inc. Functional verification system
US6691288B1 (en) * 2001-12-27 2004-02-10 Lsi Logic Corporation Method to debug IKOS method
US6810507B2 (en) * 2002-01-17 2004-10-26 Sun Microsystems, Inc. Method and apparatus for isolating the root of indeterminate logic values in an HDL simulation
US7117458B1 (en) * 2002-04-30 2006-10-03 Unisys Corporation Identifying specific netlist gates for use in code coverage testing
US7827510B1 (en) 2002-06-07 2010-11-02 Synopsys, Inc. Enhanced hardware debugging with embedded FPGAS in a hardware description language
US7051322B2 (en) * 2002-12-06 2006-05-23 @Stake, Inc. Software analysis framework
US7162403B2 (en) * 2003-02-14 2007-01-09 Sun Microsystems, Inc. System and method for efficiently tracing simulation data in hardware acceleration simulation systems
US6978216B2 (en) * 2003-03-26 2005-12-20 Broadcom Corporation Testing of integrated circuits from design documentation
US8205186B1 (en) 2005-04-11 2012-06-19 Synopsys, Inc. Incremental modification of instrumentation logic
US7483825B2 (en) * 2005-09-12 2009-01-27 International Business Machines Corporation Method for the creation of a hybrid cycle simulation model
GB0601135D0 (en) 2006-01-20 2006-03-01 Spiratech Ltd Modelling and simulation method
US8613080B2 (en) 2007-02-16 2013-12-17 Veracode, Inc. Assessment and analysis of software security flaws in virtual machines
US7783865B2 (en) * 2007-08-01 2010-08-24 International Business Machines Corporation Conditional data watchpoint management
US8484589B2 (en) 2011-10-28 2013-07-09 Apple Inc. Logical repartitioning in design compiler
US8555228B2 (en) * 2011-12-29 2013-10-08 Intel Corporation Tool for glitch removal
US9286063B2 (en) 2012-02-22 2016-03-15 Veracode, Inc. Methods and systems for providing feedback and suggested programming methods
US8726205B1 (en) 2013-04-15 2014-05-13 Nvidia Corporation Optimized simulation technique for design verification of an electronic circuit
US9798842B1 (en) 2015-01-30 2017-10-24 Altera Corporation Circuit design instrumentation for state visualization
US9588176B1 (en) 2015-01-30 2017-03-07 Altera Corporation Techniques for using scan storage circuits
US9684743B2 (en) 2015-06-19 2017-06-20 Synopsys, Inc. Isolated debugging in an FPGA based emulation environment
US9697318B2 (en) 2015-10-08 2017-07-04 Altera Corporation State visibility and manipulation in integrated circuits
US11361133B2 (en) 2017-09-26 2022-06-14 Intel Corporation Method of reporting circuit performance for high-level synthesis

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5553002A (en) * 1990-04-06 1996-09-03 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, using milestone matrix incorporated into user-interface
US5598344A (en) * 1990-04-06 1997-01-28 Lsi Logic Corporation Method and system for creating, validating, and scaling structural description of electronic device
US5623418A (en) * 1990-04-06 1997-04-22 Lsi Logic Corporation System and method for creating and validating structural description of electronic system
US5870308A (en) * 1990-04-06 1999-02-09 Lsi Logic Corporation Method and system for creating and validating low-level description of electronic design
US5544067A (en) * 1990-04-06 1996-08-06 Lsi Logic Corporation Method and system for creating, deriving and validating structural description of electronic system from higher level, behavior-oriented description, including interactive schematic design and simulation
US5220512A (en) * 1990-04-19 1993-06-15 Lsi Logic Corporation System for simultaneous, interactive presentation of electronic circuit diagrams and simulation data
US5222030A (en) 1990-04-06 1993-06-22 Lsi Logic Corporation Methodology for deriving executable low-level structural descriptions and valid physical implementations of circuits and systems from high-level semantic specifications and descriptions thereof
US5541849A (en) * 1990-04-06 1996-07-30 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including estimation and comparison of timing parameters
US5555201A (en) * 1990-04-06 1996-09-10 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including interactive system for hierarchical display of control and dataflow information
US5572436A (en) * 1990-04-06 1996-11-05 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design
US5423023A (en) * 1990-06-25 1995-06-06 Prime Computer, Inc. Method and apparatus for providing a user configurable system which integrates and manages a plurality of different task and software tools
US5253255A (en) 1990-11-02 1993-10-12 Intel Corporation Scan mechanism for monitoring the state of internal signals of a VLSI microprocessor chip
US5325309A (en) * 1991-04-30 1994-06-28 Lsi Logic Corporation Method and apparatus for integrated circuit diagnosis
US5615356A (en) * 1992-04-21 1997-03-25 Cpu Technology, Inc. Method and apparatus for interactively displaying signal information during computer simulation of an electrical circuit
US5491640A (en) * 1992-05-01 1996-02-13 Vlsi Technology, Inc. Method and apparatus for synthesizing datapaths for integrated circuit design and fabrication
US5461576A (en) * 1993-09-01 1995-10-24 Arcsys, Inc. Electronic design automation tool for the design of a semiconductor integrated circuit chip
US5568396A (en) * 1994-01-21 1996-10-22 Cadence Design Systems, Inc. Identifying overconstraints using port abstraction graphs
US5632032A (en) 1994-02-07 1997-05-20 International Business Machines Corporation Cross address space thread control in a multithreaded environment
US6044211A (en) * 1994-03-14 2000-03-28 C.A.E. Plus, Inc. Method for graphically representing a digital device as a behavioral description with data and control flow elements, and for converting the behavioral description to a structural description
TW421761B (en) * 1994-04-12 2001-02-11 Yokogawa Electric Corp Verification support system
US5937190A (en) * 1994-04-12 1999-08-10 Synopsys, Inc. Architecture and methods for a hardware description language source level analysis and debugging system
US5513123A (en) 1994-06-30 1996-04-30 Nec Usa, Inc. Non-scan design-for-testability of RT-level data paths
US5920711A (en) * 1995-06-02 1999-07-06 Synopsys, Inc. System for frame-based protocol, graphical capture, synthesis, analysis, and simulation
US5727187A (en) * 1995-08-31 1998-03-10 Unisys Corporation Method of using logical names in post-synthesis electronic design automation systems
US5841663A (en) * 1995-09-14 1998-11-24 Vlsi Technology, Inc. Apparatus and method for synthesizing integrated circuits using parameterized HDL modules
US5870585A (en) 1995-10-10 1999-02-09 Advanced Micro Devices, Inc. Design for a simulation module using an object-oriented programming language
US5835380A (en) * 1996-06-11 1998-11-10 Lsi Logic Corporation Simulation based extractor of expected waveforms for gate-level power analysis tool
US5768145A (en) * 1996-06-11 1998-06-16 Lsi Logic Corporation Parametrized waveform processor for gate-level power analysis tool
US6006022A (en) * 1996-11-15 1999-12-21 Microsystem Synthesis, Inc. Cross-linked development and deployment apparatus and method
US6134516A (en) * 1997-05-02 2000-10-17 Axis Systems, Inc. Simulation server system and method
US6009256A (en) * 1997-05-02 1999-12-28 Axis Systems, Inc. Simulation/emulation system and method
US5960191A (en) * 1997-05-30 1999-09-28 Quickturn Design Systems, Inc. Emulation system with time-multiplexed interconnect
US6083269A (en) * 1997-08-19 2000-07-04 Lsi Logic Corporation Digital integrated circuit design system and methodology with hardware

Cited By (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7305466B1 (en) * 1999-05-28 2007-12-04 Teradyne, Inc. Network fault isolation
US7092868B2 (en) 2001-10-30 2006-08-15 International Business Machines Corporation Annealing harvest event testcase collection within a batch simulation farm
US20030101041A1 (en) * 2001-10-30 2003-05-29 International Business Machines Corporation Annealing harvest event testcase collection within a batch simulation farm
US20030101039A1 (en) * 2001-10-30 2003-05-29 International Business Machines Corporation Maintaining data integrity within a distributed simulation environment
US7143019B2 (en) 2001-10-30 2006-11-28 International Business Machines Corporation Maintaining data integrity within a distributed simulation environment
US20030125915A1 (en) * 2001-11-30 2003-07-03 International Business Machines Corporation Count data access in a distributed simulation environment
US20030135354A1 (en) * 2001-11-30 2003-07-17 International Business Machines Corporation Tracking converage results in a batch simulation farm network
US20030101038A1 (en) * 2001-11-30 2003-05-29 International Business Machines Corporation Centralized disablement of instrumentation events within a batch simulation farm network
US7359847B2 (en) 2001-11-30 2008-04-15 International Business Machines Corporation Tracking converage results in a batch simulation farm network
US20030101035A1 (en) * 2001-11-30 2003-05-29 International Business Machines Corporation Non-redundant collection of harvest events within a batch simulation farm network
US7085703B2 (en) 2001-11-30 2006-08-01 International Business Machines Corporation Count data access in a distributed simulation environment
US7027971B2 (en) * 2001-11-30 2006-04-11 International Business Machines Corporation Centralized disablement of instrumentation events within a batch simulation farm network
US7143018B2 (en) 2001-11-30 2006-11-28 International Business Machines Corporation Non-redundant collection of harvest events within a batch simulation farm network
US6698001B2 (en) * 2001-12-24 2004-02-24 Hynix Semiconductor Inc. Method for generating register transfer level code
US20030121009A1 (en) * 2001-12-24 2003-06-26 Jong-Hong Bae Method for generating register transfer level code
US7502728B1 (en) * 2002-04-30 2009-03-10 Unisys Corporation Code coverage testing in hardware emulation
US7292970B1 (en) * 2002-04-30 2007-11-06 Unisys Corporation Finding unexercised logic for use in code coverage testing
US7236918B2 (en) * 2003-12-31 2007-06-26 International Business Machines Corporation Method and system for selective compilation of instrumentation entities into a simulation model of a digital design
US20050149313A1 (en) * 2003-12-31 2005-07-07 International Business Machines Corp. Method and system for selective compilation of instrumentation entities into a simulation model of a digital design
US20080052683A1 (en) * 2004-04-08 2008-02-28 International Business Machines Corporation Method and Apparatus for Breakpoint Analysis of Computer Programming Code Using Unexpected Code Path Conditions
US7353427B2 (en) * 2004-04-08 2008-04-01 International Business Machines Corporation Method and apparatus for breakpoint analysis of computer programming code using unexpected code path conditions
US20050240824A1 (en) * 2004-04-08 2005-10-27 International Business Machines Corporation Method and apparatus for breakpoint analysis of computer programming code using unexpected code path conditions
US8091075B2 (en) 2004-04-08 2012-01-03 International Business Machines Corporation Method and apparatus for breakpoint analysis of computer programming code using unexpected code path conditions
US20060277518A1 (en) * 2005-06-06 2006-12-07 Matsushita Electric Industrial Co., Ltd. High order synthesizing method and high order synthesizing apparatus
US20080307391A1 (en) * 2007-06-11 2008-12-11 Microsoft Corporation Acquiring coverage data from a script
US8479128B2 (en) 2011-03-03 2013-07-02 Synopsys, Inc. Technique for honoring multi-cycle path semantics in RTL simulation
CN103548026A (en) * 2011-03-03 2014-01-29 辛奥普希斯股份有限公司 Technique for honoring multi-cycle path semantics in RTL simulation
WO2012118859A1 (en) * 2011-03-03 2012-09-07 Synopsys, Inc. Technique for honoring multi-cycle path semantics in rtl simulation
US20120233578A1 (en) * 2011-03-08 2012-09-13 Oracle International Corporation Performance counters for integrated circuits
US8418099B2 (en) * 2011-03-08 2013-04-09 Oracle International Corporation Performance counters for integrated circuits
US20130111423A1 (en) * 2011-10-27 2013-05-02 Liang Xia Tool suite for rtl-level reconfiguration and repartitioning
US8584062B2 (en) * 2011-10-27 2013-11-12 Apple Inc. Tool suite for RTL-level reconfiguration and repartitioning
US9495490B2 (en) * 2012-07-16 2016-11-15 International Business Machines Corporation Active power dissipation detection based on erroneus clock gating equations
US20140019780A1 (en) * 2012-07-16 2014-01-16 International Business Machines Corporation Active power dissipation detection based on erronous clock gating equations
US9875325B2 (en) * 2014-05-09 2018-01-23 Zipalog, Inc. Computer implemented system and method of identification of useful untested states of an electronic design
US20160328505A1 (en) * 2014-05-09 2016-11-10 Zipalog, Inc. Computer implemented system and method of identification of useful untested states of an electronic design
US20180150580A1 (en) * 2014-05-09 2018-05-31 Zipalog, Inc. Computer implemented system and method of identification of useful untested states of an electronic design
US10262093B2 (en) * 2014-05-09 2019-04-16 Zipalog, Inc. Computer implemented system and method of identification of useful untested states of an electronic design
US10691857B2 (en) 2014-05-09 2020-06-23 Zipalog, Inc. Computer implemented system and method of identification of useful untested states of an electronic design
US11003824B2 (en) 2014-05-09 2021-05-11 Zipalog, Inc. Computer implemented system and method of identification of useful untested states of an electronic design
US11657201B2 (en) 2014-05-09 2023-05-23 Zipalog, Inc. Computer implemented system and method of identification of useful untested states of an electronic design
US11704448B2 (en) 2014-05-09 2023-07-18 Zipalog, Inc. Computer implemented system and method of translation of verification commands of an electronic design
US11907634B2 (en) 2021-09-01 2024-02-20 International Business Machines Corporation Automating addition of power supply rails, fences, and level translators to a modular circuit design
US20230070516A1 (en) * 2021-09-07 2023-03-09 International Business Machines Corporation Logical clock connection in an integrated circuit design
CN116522830A (en) * 2023-06-30 2023-08-01 奇捷科技(深圳)有限公司 Logic function correcting method and device for testing design and layout wiring stage

Also Published As

Publication number Publication date
US6336087B2 (en) 2002-01-01

Similar Documents

Publication Publication Date Title
US6336087B2 (en) Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging
US6240376B1 (en) Method and apparatus for gate-level simulation of synthesized register transfer level designs with source-level debugging
US6470478B1 (en) Method and system for counting events within a simulation model
US5880971A (en) Methodology for deriving executable low-level structural descriptions and valid physical implementations of circuits and systems from semantic specifications and descriptions thereof
US7356786B2 (en) Method and user interface for debugging an electronic system
US8751984B2 (en) Method, system and computer program for hardware design debugging
US6195627B1 (en) Method and system for instrumenting simulation models
US6195629B1 (en) Method and system for selectively disabling simulation model instrumentation
US6223142B1 (en) Method and system for incrementally compiling instrumentation into a simulation model
Zarandi et al. Dependability analysis using a fault injection tool based on synthesizability of HDL models
US20040025122A1 (en) Hardware-based HDL code coverage and design analysis
US6202042B1 (en) Hardware simulator instrumentation
US20080288234A1 (en) Method, system and program product supporting user tracing in a simulator
US6212491B1 (en) Automatic adjustment for counting instrumentation
US20020128809A1 (en) Randomized simulation model instrumentation
Große et al. Quality-driven SystemC design
US6978231B2 (en) Embedded hardware description language instrumentation
US6131080A (en) Method of monitoring a computer simulation of an electrical circuit
US7536288B2 (en) Method, system and program product supporting user tracing in a simulator
US6941257B2 (en) Hierarchical processing of simulation model events
US6725187B1 (en) Latch inference using dataflow analysis
US7502728B1 (en) Code coverage testing in hardware emulation
US7552043B2 (en) Method, system and program product for selectively removing instrumentation logic from a simulation model
US7092864B2 (en) Signal override for simulation models
Ubar et al. Diagnostic modeling of digital systems with multi-level decision diagrams

Legal Events

Date Code Title Description
AS Assignment

Owner name: MENTOR GRAPHICS CORPORATION, OREGON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RAYNAUD, ALAIN;BURGUN, LUC M.;REEL/FRAME:009466/0742;SIGNING DATES FROM 19980908 TO 19980909

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: MENTOR GRAPHICS CORPORATION,OREGON

Free format text: RETROACTIVE ASSIGNMENT AND QUITCLAIM;ASSIGNORS:META SYSTEMS SARL;BARBIER, JEAN;LEPAPE, OLIVIER;AND OTHERS;REEL/FRAME:016547/0979

Effective date: 20050826

Owner name: MENTOR GRAPHICS (HOLDING) LTD.,OREGON

Free format text: RETROACTIVE ASSIGNMENT AND QUITCLAIM;ASSIGNORS:META SYSTEMS SARL;BARBIER, JEAN;LEPAPE, OLIVIER;AND OTHERS;REEL/FRAME:016547/0979

Effective date: 20050826

Owner name: MENTOR GRAPHICS (HOLDING) LTD., OREGON

Free format text: RETROACTIVE ASSIGNMENT AND QUITCLAIM;ASSIGNORS:META SYSTEMS SARL;BARBIER, JEAN;LEPAPE, OLIVIER;AND OTHERS;REEL/FRAME:016547/0979

Effective date: 20050826

Owner name: MENTOR GRAPHICS CORPORATION, OREGON

Free format text: RETROACTIVE ASSIGNMENT AND QUITCLAIM;ASSIGNORS:META SYSTEMS SARL;BARBIER, JEAN;LEPAPE, OLIVIER;AND OTHERS;REEL/FRAME:016547/0979

Effective date: 20050826

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: 8

FPAY Fee payment

Year of fee payment: 12

FEPP Fee payment procedure

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

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY