US20130332137A1 - Identification of mistimed forcing of values in design simulation - Google Patents
Identification of mistimed forcing of values in design simulation Download PDFInfo
- Publication number
- US20130332137A1 US20130332137A1 US13/492,399 US201213492399A US2013332137A1 US 20130332137 A1 US20130332137 A1 US 20130332137A1 US 201213492399 A US201213492399 A US 201213492399A US 2013332137 A1 US2013332137 A1 US 2013332137A1
- Authority
- US
- United States
- Prior art keywords
- value
- storage element
- simulation
- clock signal
- mistimed
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
- G06F30/3308—Design verification, e.g. functional simulation or model checking using simulation
- G06F30/3312—Timing analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2119/00—Details relating to the type or aim of the analysis or the optimisation
- G06F2119/12—Timing analysis or timing optimisation
Definitions
- the present invention relates to data processing, and more specifically, to identification of mistimed forcing of values in the simulation of a design.
- Designers typically employ a high level language, such as a hardware description language (HDL), to define the structure and function of a design, such as a design of an integrated circuit.
- HDL hardware description language
- the design files specified in the high level language are then compiled to obtain a simulation model of the design, which is stimulated by a simulation engine with one or more testcases (i.e., a sequence of inputs and associated expected signal values in the design) in order to verify aspects of the design.
- testcases i.e., a sequence of inputs and associated expected signal values in the design
- Logic or functional simulation which is often the first type of simulation performed, verifies the logical correctness of the design without regard to timing constraints.
- Event simulation which tracks signal changes in the design as events, additionally supports verification in the presence of simple timing information such as signal delays.
- Cycle simulation which employs a cycle-accurate model of the design, does not support specification of delays, but instead evaluates every gate in the design every simulation cycle and enables significant performance improvement over event simulation in cases in which, on the whole, signal levels change relatively infrequently.
- forcing a signal in the design to a particular value is commonly utilized to verify the logical correctness of the design or to determine the response of the design to various combinations of signal values. Because functional simulation is not bound by timing constraints, the practice of forcing signal values does not create any issues as long as the signal value (or combination of signal values) forced on the design is legal. In event simulation and cycle simulation, however, forcing a signal in the design to a particular value can induce an error in the simulation results if the forced signal value is applied at the wrong time relative to other signals in the design, such as clock signals.
- the output values change at a rising or falling clock edge in event simulators and one simulation cycle after the clock transition in cycle simulators. If the signal value is forced at any other time, the forced change in signal value may cause an unrealistic and therefore erroneous response in the simulation model. Such errors in the simulation results can be difficult to detect.
- a computer identifies a storage element in a simulation model of an integrated circuit design that, during simulation of the integrated circuit design using the simulation model, is subject to having its value forced.
- an indication of the storage element and the associated clock signal are stored in a database.
- a determination is made by reference to the database whether or not forcing of the value is mistimed with reference to the associated clock signal.
- an indication that forcing of the value is mistimed is output.
- FIG. 1 is a high level block diagram of a data processing system in accordance with one embodiment
- FIG. 2 is a high level logical flowchart of an exemplary embodiment of a process for identifying mistimed forcing of a signal value in simulation of a design
- FIG. 3 is a data flow diagram illustrating an exemplary embodiment of a process for building a forced signal database
- FIG. 4 depicts an exemplary embodiment of an entry in the forced signal database
- FIG. 5 is a first exemplary embodiment of a presentation of simulation results generated by a simulator.
- FIG. 6 is a second exemplary embodiment of a presentation of simulation results generated by a simulator.
- data processing system 100 includes one or more processors 102 that process data and program code, for example, to simulate a design, such as an integrated circuit design.
- Data processing system 100 additionally includes one or more network interfaces 104 through which data processing system 100 can communicate with one or more other computing resources (e.g., other processing, storage or communication resources) via cabling and/or one or more wired or wireless, public or private, local or wide area networks (including the Internet).
- Data processing system 100 also includes input/output (I/O) devices 106 , such as ports, display devices, and attached devices, etc., which receive inputs and provide outputs of the processing performed by data processing system 100 and/or other computing resource(s) coupled to data processing system 100 .
- data processing system 100 includes data storage 108 , which may include one or more volatile or non-volatile storage devices, including memories, solid state drives, optical or magnetic disk drives, tape drives, portable storage media, etc.
- data storage 108 stores, in addition to unillustrated operating system software (e.g., Windows, Unix, AIX, LINUX, etc.), various program code and data processed by processors 102 to simulate a design.
- data storage 108 includes a simulation model 110 , which is a logical representation of the design to be simulated, such as an integrated circuit design.
- Simulation model 110 include constructs modeling a plurality of unillustrated combinatorial logic elements, a plurality of storage elements 116 , 118 (e.g., latches and/or registers), and a plurality of signals 120 , 122 and 124 in the design.
- Signals 120 and 122 are output by storage elements 116 and 118 , respectively, and signal 124 is a clock signal that synchronizes operation of the combinatorial logic elements and/or one or more of storage elements 116 , 118 .
- Data storage 108 additionally stores software including a simulator 112 and, optionally, a separate RTX (Run Time eXecutive) 114 .
- Simulator 112 which can be, for example, a cycle simulator or event simulator, loads one or more simulation models, such as simulation model 110 , into data storage 108 .
- Simulator 112 additionally simulates the design by stimulating simulation model 110 with one or more testcases from testbench 160 , where the application of a testcase to simulation model 110 is commonly referred to as a “simulation run.”
- simulator 112 resets simulation model 110 to various initial states based on reset information contained in reset file 164 and clocks and evaluates simulation model 110 via various APIs (Application Programming Interfaces) 130 - 134 .
- simulator 112 reads values from simulation model 110 utilizing GETFAC API 132 and writes values to simulation model 110 utilizing PUTFAC API 134 based on information contained in model access (or FAC) file 162 .
- the values simulator 112 reads from and writes to simulation model 110 are commonly specified in a model access file 162 in terms of specific signals (e.g., the values of signals 120 , 122 ), but can alternatively or additionally be expressed in terms of the storage elements (e.g., storage elements 116 , 118 ) that output the signals.
- the values of the signals and/or storage elements in simulation model 110 at various cycles (for a cycle simulator) or at occurrence of various events (for an event simulator) during a simulation run are stored for subsequent viewing and analysis as simulation log files 150 .
- simulator 112 is depicted in FIG. 1 as implemented in software, it should be appreciated that in alternative embodiments simulator 112 is implemented at least partially in hardware.
- RTX 114 is an optional control program that, if implemented, controls simulation of simulation models, such as simulation model 110 , by simulator 112 .
- RTX 114 can specify to simulator 112 which testcases from testbench 160 are to be applied to simulation model 110 .
- RTX 114 can be utilized to deliver API calls to the APIs 130 - 134 provided by simulator 112 to initialize, configure, and exercise simulation model 110 , for example, by applying values to simulation model 110 or by advancing to the next cycle (in a cycle simulator).
- FIG. 2 there is depicted a high level logical flowchart of an exemplary embodiment of a process for identifying mistimed forcing of a value in a simulation model.
- the process begins at block 200 and then proceeds to block 202 , which illustrates simulator 112 building a forced signal database 140 (see, FIG. 1 ) that specifies the signals (e.g., signals 120 , 122 ) and/or storage elements (e.g., storage elements 116 , 118 ) that have their values forced during a simulation run and preferably additionally indicates the associated clock signal(s) (e.g., clock signal 124 ) utilize to drive those storage elements.
- signals e.g., signals 120 , 122
- storage elements e.g., storage elements 116 , 118
- clock signal(s) e.g., clock signal 124
- FIG. 3 illustrates one exemplary embodiment of a process for building forced signal database 140 .
- simulator 112 receives as inputs one or more model access files 162 , one or more reset files 164 and a simulation model 110 to be utilized in the simulation run.
- Simulator 112 first identifies which signals are to be forced during simulation by calls to PUTFAC API 124 (and/or other APIs 130 ) in accordance with the contents of model access file(s) 162 and reset file(s) 163 .
- simulator 112 performs signal traceback to identify the storage elements (e.g., storage elements 116 , 118 ) that output the identified signal values.
- simulator 112 determines the clock signal(s) utilized to drive the identified storage elements, for example, by reference to clock signals explicitly specified in model access file 162 or by analysis of simulation model 110 . Simulator 112 records the forced signals, the storage elements that output the forced signals, and the associated clock signals determined by the process of FIG. 3 in forced signal database 140 .
- FIG. 4 depicts an exemplary embodiment of an entry 400 in the forced signal database 140 generated according to the process given in FIG. 3 .
- Entry 400 includes a testcase field 402 that specifies the testcase within testbench 160 with which entry 400 is associated.
- entry 400 includes a signal name field 404 that specifies a signal name of a signal forced during the testcase, a latch name field 406 that specifies the latch name of the storage element that outputs the forced signal, a clock name field 408 that specifies the clock name of the clock signal that drives the specified storage element, and a clock data field 410 .
- Clock data field 410 is dynamically updated during simulation with information regarding the specified clock signal, as described further below.
- simulator 112 begins a cycle-based or event-based simulation run by stimulating simulation model 110 with the particular testcase.
- simulator 112 can either direct the simulation run itself or can alternatively be controlled through RTX 114 .
- simulator 112 updates clock data fields 410 of the relevant entries 400 in forced signal database 140 with the information about the edges of the clock signals and the periods of the clock signals (block 206 ). If a clock signal is subject to jitter or if the clock signal is non-periodic, simulator 112 additionally monitors the clock signal to determine the pattern of the jitter during initial cycles (assuming the jitter is periodic) and updates the relevant clock data field 410 with the jitter information. If the jitter has no identifiable pattern (the jitter is random), simulator 112 determines the edge of the clock for each simulation cycle.
- simulator 112 monitors for receipt of an input indicating that a signal value in simulation model 110 is to be forced to a specified value.
- the input can be, for example, a call to PUTFAC API 134 . If simulator 112 does not detect receipt of an input indicating that a signal value in simulation model 110 is to be forced, simulator 112 additionally determines at block 224 whether or not the simulation run is complete. If so, the process shown in FIG. 2 terminates at block 230 . If, however, the simulation run is not complete, simulator 112 continues simulating the design, and the process given in FIG. 2 returns to block 210 , which has been described.
- simulator 112 determines by reference to forced signal database 140 whether or not forcing of the signal value is mistimed with respect to the associated clock signal (block 212 ). For example, simulator 112 performs a lookup in forced signal database 130 and accesses the appropriate entry 400 by performing a match on the contents of testcase field 402 and signal name field 404 or latch name field 406 . Simulator 112 can then determine the next active edge of the associated clock signal by reference to clock data field 410 and consequently determine whether the requested alteration of the signal value (i.e., the value in the associated storage element) is mistimed.
- simulator 112 forces (“sticks”) the signal to the specified value at the requested time in the simulation (block 214 ), for example, by forcing the associated storage element to the specified value via PUTFAC API 134 . Thereafter, simulator 112 continues the simulation run, and the process returns to block 210 , which has been described. In response to a determination at block 212 that the requested forcing of the signal value is mistimed with respect to an associated clock signal, the process proceeds from block 212 to block 220 .
- Block 220 illustrates simulator 112 outputting an indication that the requested forcing of the signal value is mistimed with respect to an associated clock signal.
- the indication output by simulator 112 can be output in a variety or combination of forms, including in a dialog box requesting user confirmation of when to apply the “stick” (e.g., mistimed as requested or correctly timed), in a notification message that a mistimed “stick” was automatically detected and corrected, in an error message in a dynamic presentation of simulation results on a display, in a notation on a signal value trace in one of simulation log files 150 indicating the correct timing for forcing the signal value, etc.
- Simulator 112 additionally forces the signal to the specified signal value using a selected timing (block 222 ).
- simulator 112 automatically applies the correct timing to the signal “stick” and merely notifies the user of the alteration in timing. Simulator 112 can determine when to alter the latch value, for example, based on the delay from clock to data output of the latch specified in a Standard Delay Format (SDF) file.
- SDF Standard Delay Format
- simulator 112 has a default configuration setting that, if employed, causes simulator 112 to force the signal to the specified signal value using appropriate timing with respect to the associated clock signal, but explicitly provides the user with opportunity to override the default configuration by confirming application of a mistimed signal “stick.” In other embodiments, simulator 112 forces the signal to the specified signal value in a mistimed manner as requested and merely provides notification of the mistiming via the presentation of the simulation results and/or simulation log files 150 . Other variations or combinations of options are additionally contemplated.
- simulator 112 determines at block 224 whether or not the simulation run is complete. If so, the process given in FIG. 2 terminates at block 230 . If, however, the simulation run is not complete, the process given in FIG. 2 returns from block 224 to block 210 , which has been described.
- FIG. 5 there is illustrated is a first exemplary embodiment of a presentation 500 of simulation results generated by simulator 112 .
- Presentation 500 may be presented by simulator 112 , for example, via a display device among I/O devices 106 or coupled to data processing system 100 by one of I/O devices 106 .
- simulator 112 is a cycle simulator configured to present simulation results of a simulation run in substantially real time during the simulation run and/or after the simulation run completes (e.g., from simulation log files 150 ).
- simulator 112 is further configured, either by default or by user configuration, to provide notification of mistimed sticks without altering the timing of the sticks.
- Presentation 500 includes three components (which can optionally be implemented in separate windows or panes of a graphical user interface), including a signal tree 502 , a signal waveform graph 504 , and a signal value summary 506 .
- Signal tree 502 illustrates that in the depicted example simulation model 110 includes at least four signals, respectively identified by the signal names CLOCK, EN (enable), EN_DEL (delayed enable), and RDWR_REQ (read/write request).
- Signal waveform graph 504 which presents the values of the signals in signal tree 502 with reference to a timeline 508 of simulation cycles, indicates that CLOCK is a fifty percent duty cycle clock signal having a period of eight simulation cycles, and that EN_DEL is a delayed version of EN that is generated by simulation model 110 one simulation cycle after the next rising edge of CLOCK at or after a rising edge of EN.
- the values of the signals at a user-selectable time index 510 are summarized in signal value summary 506 .
- simulator 110 forces EN to the value b“1” coincident with the rising edge of CLOCK at simulation cycle 973 , for example, in response to a call to PUTFAC API 134 specified in model access file 162 .
- simulated circuitry within simulation model 110 generates EN_DEL one simulation cycle later at simulation cycle 974 .
- the pulse generated by simulation model 110 on RDWR_REQ is a glitch lasting for only a single simulation cycle.
- simulator 110 presents a notification 512 in conjunction with signal waveform graph 504 to inform the user that simulator 112 has detected, but not corrected, a mistimed forcing of EN at simulation cycle 973 , as described above with reference to block 220 of FIG. 2 .
- FIG. 6 there is a depicted a second exemplary embodiment of a presentation 500 ′ of simulation results generated by simulator 112 .
- Presentation 500 ′ may be presented by simulator 112 via a display device during the simulation run (i.e., using substantially real time simulation results) and/or after the simulation run completes (e.g., from simulation results recorded in simulation log files 150 ).
- simulator 112 is further configured, either by default or by user configuration, to provide notification of mistimed sticks and, if possible, to alter the timing of the sticks to better reflect the operation of the design as realized in integrated circuitry.
- simulator 110 receives an input (e.g., a call to PUTFAC API 134 ) requesting EN to be forced to the value b“1” coincident with the rising edge of CLOCK at simulation cycle 541 .
- an input e.g., a call to PUTFAC API 134
- simulator 110 determines that the forcing of the value of EN is mistimed with respect to CLOCK, and accordingly applies the “stick” (automatically or in response to user confirmation) one cycle later at simulation cycle 542 .
- simulation model 110 generates EN_DEL eight simulation cycles (i.e., a full CLOCK cycle) later at simulation cycle 550 .
- the pulse generated by simulation model 110 on RDWR_REQ has the proper length (e.g., a full CLOCK cycle) corresponding to expected hardware behavior.
- Simulator 110 further presents a notification 520 in conjunction with signal waveform graph 504 to inform the user that simulator 112 has detected a mistimed forcing of EN at simulation cycle 541 and corrected the timing at which EN is forced at simulation cycle 542 .
- a computer identifies a storage element in a simulation model of an integrated circuit design that, during simulation of the integrated circuit design using the simulation model, is subject to having its value forced.
- an indication of the storage element and the associated clock signal are stored in a database.
- a determination is made by reference to the database whether or not forcing of the value is mistimed with reference to the associated clock signal.
- an indication that forcing of the value is mistimed is output. The user is thus notified about unrealistic alteration of values in the simulation model.
- the simulator automatically modifies timing of application of the particular value to the storage element so that forcing of the value is not mistimed.
- present invention has been particularly shown as described with reference to one or more preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
- present invention may alternatively or additionally be implemented as a program product including a computer-readable storage medium or device storing program code that can be processed by a data processing system.
- computer-readable storage medium and “computer-readable storage device” are defined to exclude signals per se and to include only those embodiments of machines, manufactures, and improvements thereof that are statutory under 35 U.S.C. ⁇ 101.
- a computer-readable storage medium or device can include, without limitation, a volatile or non-volatile memory, a magnetic or optical storage device, a CD-ROM.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
- The present invention relates to data processing, and more specifically, to identification of mistimed forcing of values in the simulation of a design.
- Designers typically employ a high level language, such as a hardware description language (HDL), to define the structure and function of a design, such as a design of an integrated circuit. The design files specified in the high level language are then compiled to obtain a simulation model of the design, which is stimulated by a simulation engine with one or more testcases (i.e., a sequence of inputs and associated expected signal values in the design) in order to verify aspects of the design.
- Various types of simulation can be utilized to verify designs. Logic or functional simulation, which is often the first type of simulation performed, verifies the logical correctness of the design without regard to timing constraints. Event simulation, which tracks signal changes in the design as events, additionally supports verification in the presence of simple timing information such as signal delays. Cycle simulation, which employs a cycle-accurate model of the design, does not support specification of delays, but instead evaluates every gate in the design every simulation cycle and enables significant performance improvement over event simulation in cases in which, on the whole, signal levels change relatively infrequently.
- In functional simulation, forcing a signal in the design to a particular value (commonly referred to “sticking” a signal) is commonly utilized to verify the logical correctness of the design or to determine the response of the design to various combinations of signal values. Because functional simulation is not bound by timing constraints, the practice of forcing signal values does not create any issues as long as the signal value (or combination of signal values) forced on the design is legal. In event simulation and cycle simulation, however, forcing a signal in the design to a particular value can induce an error in the simulation results if the forced signal value is applied at the wrong time relative to other signals in the design, such as clock signals. For example, in the case of flip flops, the output values change at a rising or falling clock edge in event simulators and one simulation cycle after the clock transition in cycle simulators. If the signal value is forced at any other time, the forced change in signal value may cause an unrealistic and therefore erroneous response in the simulation model. Such errors in the simulation results can be difficult to detect.
- In some embodiments, a computer identifies a storage element in a simulation model of an integrated circuit design that, during simulation of the integrated circuit design using the simulation model, is subject to having its value forced. In response to identifying the storage element, an indication of the storage element and the associated clock signal are stored in a database. In response to receiving an input indicating the value of the storage element is to be forced during simulation, a determination is made by reference to the database whether or not forcing of the value is mistimed with reference to the associated clock signal. In response to a determination that the forcing of the value as indicated by the input is mistimed with reference to the associated clock signal, an indication that forcing of the value is mistimed is output.
-
FIG. 1 is a high level block diagram of a data processing system in accordance with one embodiment; -
FIG. 2 is a high level logical flowchart of an exemplary embodiment of a process for identifying mistimed forcing of a signal value in simulation of a design; -
FIG. 3 is a data flow diagram illustrating an exemplary embodiment of a process for building a forced signal database; -
FIG. 4 depicts an exemplary embodiment of an entry in the forced signal database; -
FIG. 5 is a first exemplary embodiment of a presentation of simulation results generated by a simulator; and -
FIG. 6 is a second exemplary embodiment of a presentation of simulation results generated by a simulator. - With reference now to the figures and with particular reference to
FIG. 1 , there is illustrated a high level block diagram of an exemplary embodiment of adata processing system 100. In the illustrated exemplary embodiment,data processing system 100 includes one ormore processors 102 that process data and program code, for example, to simulate a design, such as an integrated circuit design.Data processing system 100 additionally includes one ormore network interfaces 104 through whichdata processing system 100 can communicate with one or more other computing resources (e.g., other processing, storage or communication resources) via cabling and/or one or more wired or wireless, public or private, local or wide area networks (including the Internet).Data processing system 100 also includes input/output (I/O)devices 106, such as ports, display devices, and attached devices, etc., which receive inputs and provide outputs of the processing performed bydata processing system 100 and/or other computing resource(s) coupled todata processing system 100. Finally,data processing system 100 includesdata storage 108, which may include one or more volatile or non-volatile storage devices, including memories, solid state drives, optical or magnetic disk drives, tape drives, portable storage media, etc. - In the illustrated embodiment,
data storage 108 stores, in addition to unillustrated operating system software (e.g., Windows, Unix, AIX, LINUX, etc.), various program code and data processed byprocessors 102 to simulate a design. As shown,data storage 108 includes asimulation model 110, which is a logical representation of the design to be simulated, such as an integrated circuit design.Simulation model 110 include constructs modeling a plurality of unillustrated combinatorial logic elements, a plurality ofstorage elements 116, 118 (e.g., latches and/or registers), and a plurality ofsignals Signals storage elements signal 124 is a clock signal that synchronizes operation of the combinatorial logic elements and/or one or more ofstorage elements -
Data storage 108 additionally stores software including asimulator 112 and, optionally, a separate RTX (Run Time eXecutive) 114.Simulator 112, which can be, for example, a cycle simulator or event simulator, loads one or more simulation models, such assimulation model 110, intodata storage 108. Simulator 112 additionally simulates the design bystimulating simulation model 110 with one or more testcases fromtestbench 160, where the application of a testcase tosimulation model 110 is commonly referred to as a “simulation run.” During one or more simulation runs,simulator 112resets simulation model 110 to various initial states based on reset information contained inreset file 164 and clocks and evaluatessimulation model 110 via various APIs (Application Programming Interfaces) 130-134. For example,simulator 112 reads values fromsimulation model 110 utilizing GETFACAPI 132 and writes values tosimulation model 110 utilizing PUTFAC API 134 based on information contained in model access (or FAC)file 162. As illustrated inFIG. 1 , thevalues simulator 112 reads from and writes tosimulation model 110 are commonly specified in amodel access file 162 in terms of specific signals (e.g., the values ofsignals 120, 122), but can alternatively or additionally be expressed in terms of the storage elements (e.g.,storage elements 116, 118) that output the signals. The values of the signals and/or storage elements insimulation model 110 at various cycles (for a cycle simulator) or at occurrence of various events (for an event simulator) during a simulation run are stored for subsequent viewing and analysis assimulation log files 150. Althoughsimulator 112 is depicted inFIG. 1 as implemented in software, it should be appreciated that inalternative embodiments simulator 112 is implemented at least partially in hardware. - RTX 114 is an optional control program that, if implemented, controls simulation of simulation models, such as
simulation model 110, bysimulator 112. For example, RTX 114 can specify tosimulator 112 which testcases fromtestbench 160 are to be applied tosimulation model 110. In addition, RTX 114 can be utilized to deliver API calls to the APIs 130-134 provided bysimulator 112 to initialize, configure, andexercise simulation model 110, for example, by applying values tosimulation model 110 or by advancing to the next cycle (in a cycle simulator). - Referring now to
FIG. 2 , there is depicted a high level logical flowchart of an exemplary embodiment of a process for identifying mistimed forcing of a value in a simulation model. The process begins atblock 200 and then proceeds toblock 202, which illustratessimulator 112 building a forced signal database 140 (see,FIG. 1 ) that specifies the signals (e.g.,signals 120, 122) and/or storage elements (e.g.,storage elements 116, 118) that have their values forced during a simulation run and preferably additionally indicates the associated clock signal(s) (e.g., clock signal 124) utilize to drive those storage elements. -
FIG. 3 illustrates one exemplary embodiment of a process for building forcedsignal database 140. As illustrated inFIG. 3 , prior to a simulation run,simulator 112 receives as inputs one or moremodel access files 162, one ormore reset files 164 and asimulation model 110 to be utilized in the simulation run.Simulator 112 first identifies which signals are to be forced during simulation by calls to PUTFAC API 124 (and/or other APIs 130) in accordance with the contents of model access file(s) 162 and reset file(s) 163. By reference tosimulation model 110,simulator 112 performs signal traceback to identify the storage elements (e.g.,storage elements 116, 118) that output the identified signal values. In addition,simulator 112 determines the clock signal(s) utilized to drive the identified storage elements, for example, by reference to clock signals explicitly specified inmodel access file 162 or by analysis ofsimulation model 110.Simulator 112 records the forced signals, the storage elements that output the forced signals, and the associated clock signals determined by the process ofFIG. 3 in forcedsignal database 140. -
FIG. 4 depicts an exemplary embodiment of anentry 400 in the forcedsignal database 140 generated according to the process given inFIG. 3 .Entry 400 includes atestcase field 402 that specifies the testcase withintestbench 160 with whichentry 400 is associated. In addition,entry 400 includes asignal name field 404 that specifies a signal name of a signal forced during the testcase, alatch name field 406 that specifies the latch name of the storage element that outputs the forced signal, aclock name field 408 that specifies the clock name of the clock signal that drives the specified storage element, and aclock data field 410.Clock data field 410 is dynamically updated during simulation with information regarding the specified clock signal, as described further below. - Returning to
block 204 ofFIG. 2 , after theentries 400 in forcedsignal database 140 relevant to a particular testcase intestbench 160 are generated,simulator 112 begins a cycle-based or event-based simulation run by stimulatingsimulation model 110 with the particular testcase. As noted above,simulator 112 can either direct the simulation run itself or can alternatively be controlled through RTX 114. - After the clock signals in simulation model 110 (e.g., clock signal 124) are stable,
simulator 112 updatesclock data fields 410 of therelevant entries 400 in forcedsignal database 140 with the information about the edges of the clock signals and the periods of the clock signals (block 206). If a clock signal is subject to jitter or if the clock signal is non-periodic,simulator 112 additionally monitors the clock signal to determine the pattern of the jitter during initial cycles (assuming the jitter is periodic) and updates the relevantclock data field 410 with the jitter information. If the jitter has no identifiable pattern (the jitter is random),simulator 112 determines the edge of the clock for each simulation cycle. - At
block 210,simulator 112 monitors for receipt of an input indicating that a signal value insimulation model 110 is to be forced to a specified value. The input can be, for example, a call toPUTFAC API 134. Ifsimulator 112 does not detect receipt of an input indicating that a signal value insimulation model 110 is to be forced,simulator 112 additionally determines atblock 224 whether or not the simulation run is complete. If so, the process shown inFIG. 2 terminates atblock 230. If, however, the simulation run is not complete,simulator 112 continues simulating the design, and the process given inFIG. 2 returns to block 210, which has been described. - In response to
simulator 112 detecting atblock 210 an input indicating that signal value insimulation model 110 is to be forced,simulator 112 determines by reference to forcedsignal database 140 whether or not forcing of the signal value is mistimed with respect to the associated clock signal (block 212). For example,simulator 112 performs a lookup in forcedsignal database 130 and accesses theappropriate entry 400 by performing a match on the contents oftestcase field 402 and signalname field 404 or latchname field 406.Simulator 112 can then determine the next active edge of the associated clock signal by reference toclock data field 410 and consequently determine whether the requested alteration of the signal value (i.e., the value in the associated storage element) is mistimed. - In response to a negative determination at
block 212,simulator 112 forces (“sticks”) the signal to the specified value at the requested time in the simulation (block 214), for example, by forcing the associated storage element to the specified value viaPUTFAC API 134. Thereafter,simulator 112 continues the simulation run, and the process returns to block 210, which has been described. In response to a determination atblock 212 that the requested forcing of the signal value is mistimed with respect to an associated clock signal, the process proceeds fromblock 212 to block 220. -
Block 220 illustratessimulator 112 outputting an indication that the requested forcing of the signal value is mistimed with respect to an associated clock signal. In various embodiments, the indication output bysimulator 112 can be output in a variety or combination of forms, including in a dialog box requesting user confirmation of when to apply the “stick” (e.g., mistimed as requested or correctly timed), in a notification message that a mistimed “stick” was automatically detected and corrected, in an error message in a dynamic presentation of simulation results on a display, in a notation on a signal value trace in one of simulation log files 150 indicating the correct timing for forcing the signal value, etc.Simulator 112 additionally forces the signal to the specified signal value using a selected timing (block 222). In some embodiments,simulator 112 automatically applies the correct timing to the signal “stick” and merely notifies the user of the alteration in timing.Simulator 112 can determine when to alter the latch value, for example, based on the delay from clock to data output of the latch specified in a Standard Delay Format (SDF) file. In other embodiments,simulator 112 has a default configuration setting that, if employed, causessimulator 112 to force the signal to the specified signal value using appropriate timing with respect to the associated clock signal, but explicitly provides the user with opportunity to override the default configuration by confirming application of a mistimed signal “stick.” In other embodiments,simulator 112 forces the signal to the specified signal value in a mistimed manner as requested and merely provides notification of the mistiming via the presentation of the simulation results and/or simulation log files 150. Other variations or combinations of options are additionally contemplated. - Following
block 222,simulator 112 determines atblock 224 whether or not the simulation run is complete. If so, the process given inFIG. 2 terminates atblock 230. If, however, the simulation run is not complete, the process given inFIG. 2 returns fromblock 224 to block 210, which has been described. - With reference now to
FIG. 5 , there is illustrated is a first exemplary embodiment of apresentation 500 of simulation results generated bysimulator 112.Presentation 500 may be presented bysimulator 112, for example, via a display device among I/O devices 106 or coupled todata processing system 100 by one of I/O devices 106. In the embodiment depicted inFIG. 5 ,simulator 112 is a cycle simulator configured to present simulation results of a simulation run in substantially real time during the simulation run and/or after the simulation run completes (e.g., from simulation log files 150). In the illustrated embodiment,simulator 112 is further configured, either by default or by user configuration, to provide notification of mistimed sticks without altering the timing of the sticks. -
Presentation 500 includes three components (which can optionally be implemented in separate windows or panes of a graphical user interface), including asignal tree 502, asignal waveform graph 504, and asignal value summary 506.Signal tree 502 illustrates that in the depictedexample simulation model 110 includes at least four signals, respectively identified by the signal names CLOCK, EN (enable), EN_DEL (delayed enable), and RDWR_REQ (read/write request).Signal waveform graph 504, which presents the values of the signals insignal tree 502 with reference to atimeline 508 of simulation cycles, indicates that CLOCK is a fifty percent duty cycle clock signal having a period of eight simulation cycles, and that EN_DEL is a delayed version of EN that is generated bysimulation model 110 one simulation cycle after the next rising edge of CLOCK at or after a rising edge of EN. The values of the signals at a user-selectable time index 510 are summarized insignal value summary 506. - As further indicated in
FIG. 5 , during simulation,simulator 110 forces EN to the value b“1” coincident with the rising edge of CLOCK at simulation cycle 973, for example, in response to a call toPUTFAC API 134 specified inmodel access file 162. In response to the change in value of EN, simulated circuitry withinsimulation model 110 generates EN_DEL one simulation cycle later at simulation cycle 974. As a result, the pulse generated bysimulation model 110 on RDWR_REQ is a glitch lasting for only a single simulation cycle. Because this glitch response does not correspond to hardware behavior,simulator 110 presents anotification 512 in conjunction withsignal waveform graph 504 to inform the user thatsimulator 112 has detected, but not corrected, a mistimed forcing of EN at simulation cycle 973, as described above with reference to block 220 ofFIG. 2 . - Referring now to
FIG. 6 , there is a depicted a second exemplary embodiment of apresentation 500′ of simulation results generated bysimulator 112.Presentation 500′, likepresentation 500 ofFIG. 5 , may be presented bysimulator 112 via a display device during the simulation run (i.e., using substantially real time simulation results) and/or after the simulation run completes (e.g., from simulation results recorded in simulation log files 150). In the second embodiment,simulator 112 is further configured, either by default or by user configuration, to provide notification of mistimed sticks and, if possible, to alter the timing of the sticks to better reflect the operation of the design as realized in integrated circuitry. - During the simulation scenario depicted in
FIG. 6 ,simulator 110 receives an input (e.g., a call to PUTFAC API 134) requesting EN to be forced to the value b“1” coincident with the rising edge of CLOCK at simulation cycle 541. As described above with reference to block 212 ofFIG. 2 ,simulator 110 determines that the forcing of the value of EN is mistimed with respect to CLOCK, and accordingly applies the “stick” (automatically or in response to user confirmation) one cycle later at simulation cycle 542. Accordingly,simulation model 110 generates EN_DEL eight simulation cycles (i.e., a full CLOCK cycle) later at simulation cycle 550. As a result, the pulse generated bysimulation model 110 on RDWR_REQ has the proper length (e.g., a full CLOCK cycle) corresponding to expected hardware behavior.Simulator 110 further presents anotification 520 in conjunction withsignal waveform graph 504 to inform the user thatsimulator 112 has detected a mistimed forcing of EN at simulation cycle 541 and corrected the timing at which EN is forced at simulation cycle 542. - As has been described, in some embodiments, a computer identifies a storage element in a simulation model of an integrated circuit design that, during simulation of the integrated circuit design using the simulation model, is subject to having its value forced. In response to identifying the storage element, an indication of the storage element and the associated clock signal are stored in a database. In response to receiving an input indicating the value of the storage element is to be forced during cycle-based or event-based simulation, a determination is made by reference to the database whether or not forcing of the value is mistimed with reference to the associated clock signal. In response to a determination that the forcing of the value as indicated by the input is mistimed with reference to the associated clock signal, an indication that forcing of the value is mistimed is output. The user is thus notified about unrealistic alteration of values in the simulation model. In some embodiments, the simulator automatically modifies timing of application of the particular value to the storage element so that forcing of the value is not mistimed.
- While the present invention has been particularly shown as described with reference to one or more preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. For example, although aspects have been described with respect to a computer system executing program code that directs the functions of the present invention, it should be understood that present invention may alternatively or additionally be implemented as a program product including a computer-readable storage medium or device storing program code that can be processed by a data processing system. As utilized herein, the terms “computer-readable storage medium” and “computer-readable storage device” are defined to exclude signals per se and to include only those embodiments of machines, manufactures, and improvements thereof that are statutory under 35 U.S.C. §101. A computer-readable storage medium or device can include, without limitation, a volatile or non-volatile memory, a magnetic or optical storage device, a CD-ROM.
Claims (21)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/492,399 US20130332137A1 (en) | 2012-06-08 | 2012-06-08 | Identification of mistimed forcing of values in design simulation |
US14/099,459 US9507898B2 (en) | 2012-06-08 | 2013-12-06 | Identification of mistimed forcing of values in design simulation |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/492,399 US20130332137A1 (en) | 2012-06-08 | 2012-06-08 | Identification of mistimed forcing of values in design simulation |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/099,459 Continuation US9507898B2 (en) | 2012-06-08 | 2013-12-06 | Identification of mistimed forcing of values in design simulation |
Publications (1)
Publication Number | Publication Date |
---|---|
US20130332137A1 true US20130332137A1 (en) | 2013-12-12 |
Family
ID=49715974
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/492,399 Abandoned US20130332137A1 (en) | 2012-06-08 | 2012-06-08 | Identification of mistimed forcing of values in design simulation |
US14/099,459 Expired - Fee Related US9507898B2 (en) | 2012-06-08 | 2013-12-06 | Identification of mistimed forcing of values in design simulation |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/099,459 Expired - Fee Related US9507898B2 (en) | 2012-06-08 | 2013-12-06 | Identification of mistimed forcing of values in design simulation |
Country Status (1)
Country | Link |
---|---|
US (2) | US20130332137A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180238966A1 (en) * | 2017-02-22 | 2018-08-23 | General Electric Company | Power distribution systems and methods of testing responses to electrical conditions using a communication network |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060195822A1 (en) * | 1999-11-30 | 2006-08-31 | Beardslee John M | Method and system for debugging an electronic system |
US20090293031A1 (en) * | 2008-05-23 | 2009-11-26 | Darsow Craig M | Replicating Timing Data in Static Timing Analysis Operation |
US8332201B1 (en) * | 2006-05-26 | 2012-12-11 | Marvell International Ltd. | Innovative verification methodology for deeply embedded computational element |
US8566767B1 (en) * | 2011-11-23 | 2013-10-22 | Cadence Design Systems, Inc. | System and method for parametric intercoupling of static and dynamic analyses for synergistic integration in electronic design automation |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5220512A (en) | 1990-04-19 | 1993-06-15 | Lsi Logic Corporation | System for simultaneous, interactive presentation of electronic circuit diagrams and simulation data |
US6920418B2 (en) | 2000-12-30 | 2005-07-19 | International Business Machines Corporation | Detecting events within simulation models |
US20030125921A1 (en) | 2001-12-27 | 2003-07-03 | Matsushita Electric Industrial Co., Ltd. | Circuit simulation apparatus, circuit simulation method, circuit simulation program, and storage medium storing circuit simulation program |
US7437282B2 (en) | 2005-09-22 | 2008-10-14 | International Business Machines Corporation | Method and apparatus to provide alternative stimulus to signals internal to a model actively running on a logic simulation hardware emulator |
US7434193B2 (en) | 2006-02-02 | 2008-10-07 | International Business Machines Corporation | Method, system and program product for specifying a configuration for a digital system utilizing dial biasing weights |
US7493248B2 (en) | 2006-05-08 | 2009-02-17 | International Business Machines Corporation | Method, system and program product supporting phase events in a simulation model of a digital system |
-
2012
- 2012-06-08 US US13/492,399 patent/US20130332137A1/en not_active Abandoned
-
2013
- 2013-12-06 US US14/099,459 patent/US9507898B2/en not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060195822A1 (en) * | 1999-11-30 | 2006-08-31 | Beardslee John M | Method and system for debugging an electronic system |
US8332201B1 (en) * | 2006-05-26 | 2012-12-11 | Marvell International Ltd. | Innovative verification methodology for deeply embedded computational element |
US20090293031A1 (en) * | 2008-05-23 | 2009-11-26 | Darsow Craig M | Replicating Timing Data in Static Timing Analysis Operation |
US8566767B1 (en) * | 2011-11-23 | 2013-10-22 | Cadence Design Systems, Inc. | System and method for parametric intercoupling of static and dynamic analyses for synergistic integration in electronic design automation |
Non-Patent Citations (6)
Title |
---|
Arekapudi, Srikanth et al., "ATPG for Timing-Induced Functional Errors on Trigger Events in Hardware-Software Systems", 2002, Proceedings of the Seventh IEEE European Test Workshop, IEEE. * |
Floros, Andreas et al.,"The Time Dilation Scan Architecture for Timing Error Detection and Correction", 2008, IFIP/IEEE International Conference on Very Large Scale Integration (VLSI-SoC). * |
Hartl, Robert et al., "Improved Backwards Analysis for Architectural Vulnerability Factor Estimation", September 27 - 28, 2011, Semiconductor Conference Dresden (SCD), IEEE. * |
Metra, Cecilia et al., "On-Line Testing Scheme for Clock's Faults", 1997, International Test Conference, IEEE. * |
Soukup, T.J. et al., "Implementation of a Fiber-Optic Delay-Line Memory", June 10, 1992, Applied Optics, Vol. 31, No. 17, Optical Society of America. * |
Zhang, Qiushuang et al., "A Validation Fault for Timing-Induced Functional Errors", 2001, ITC International Test Conference, IEEE. * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180238966A1 (en) * | 2017-02-22 | 2018-08-23 | General Electric Company | Power distribution systems and methods of testing responses to electrical conditions using a communication network |
US10935604B2 (en) * | 2017-02-22 | 2021-03-02 | Abb Schweiz Ag | Power distribution systems and methods of testing responses to electrical conditions using a communication network |
Also Published As
Publication number | Publication date |
---|---|
US9507898B2 (en) | 2016-11-29 |
US20140095141A1 (en) | 2014-04-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7404160B2 (en) | Method and system for hardware based reporting of assertion information for emulation and hardware acceleration | |
US20050165597A1 (en) | Apparatus and method for performing hardware and software co-verification testing | |
US9600398B2 (en) | Method and apparatus for debugging HDL design code and test program code | |
US7246333B2 (en) | Apparatus and method for unified debug for simulation | |
US8271252B2 (en) | Automatic verification of device models | |
US9589087B2 (en) | Verification environments utilizing hardware description languages | |
JP6600011B2 (en) | Efficient waveform generation for emulation | |
US10282501B1 (en) | Support for multiple user defined assertion checkers in a multi-FPGA prototyping system | |
US10073933B2 (en) | Automatic generation of properties to assist hardware emulation | |
CN113835945A (en) | Chip testing method, device, equipment and system | |
KR20080055913A (en) | Development of assertions for integrated circuit design simulation | |
US9286426B2 (en) | Method and apparatus for testing | |
US20130024178A1 (en) | Playback methodology for verification components | |
US7606695B1 (en) | Self-checking simulations using dynamic data loading | |
US9239899B2 (en) | System and method for improved transaction based verification of design under test (DUT) to minimize bogus fails | |
US7606694B1 (en) | Framework for cycle accurate simulation | |
US9507898B2 (en) | Identification of mistimed forcing of values in design simulation | |
US11775718B2 (en) | Methods and apparatus to simulate metastability for circuit design verification | |
US6892154B1 (en) | Method and apparatus for developing multiple test cases from a base test case | |
US9280627B1 (en) | GUI based verification at multiple abstraction levels | |
US20140325468A1 (en) | Storage medium, and generation apparatus for generating transactions for performance evaluation | |
CN116205174A (en) | Asynchronous microprocessor verification method and system based on UVM | |
US20090150103A1 (en) | Computer-Based Method and System for Simulating Static Timing Clocking Results | |
US7340661B2 (en) | Computer program product for performing testing of a simulated storage device within a testing simulation environment | |
TW201933156A (en) | Method and apparatus of emulation techniques for enhanced FPGA validation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BALASUBRAMANIAN, SANTOSH;BROWN, AARON C.;CUMMINGS, DAVID W.;AND OTHERS;SIGNING DATES FROM 20120523 TO 20120524;REEL/FRAME:028346/0661 |
|
AS | Assignment |
Owner name: GLOBALFOUNDRIES U.S. 2 LLC, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:036550/0001 Effective date: 20150629 |
|
AS | Assignment |
Owner name: GLOBALFOUNDRIES INC., CAYMAN ISLANDS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GLOBALFOUNDRIES U.S. 2 LLC;GLOBALFOUNDRIES U.S. INC.;REEL/FRAME:036779/0001 Effective date: 20150910 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: GLOBALFOUNDRIES U.S. INC., NEW YORK Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION;REEL/FRAME:056987/0001 Effective date: 20201117 |