Patent Application
20160342727
This invention relates to the field of integrated circuit design verification and in particular to simulation of an integrated circuit design. More particularly the invention relates to a system, method and computer program product for computing clock path delta delays and reporting conditions that will cause the simulation to generate incorrect results.
Electronic chip designers frequently simulate Register-Transfer-Level (RTL) designs with little or no timing information. Silicon signals have propagation delays so the simulation result may differ from actual silicon behavior. This difference of behavior can lead to a real functional bug being missed in simulation. It can also lead to simulation failures in an otherwise valid design that are time-consuming to diagnose. Many of these differences are due to incorrect estimation of propagation time between clock and data paths causing a data to be propagated earlier than it would in actual silicon. This problem is known as a shoot-through situation in simulation.
Most modern electronic chip designs have power budgets. Electronic chip designers manage the power by introducing lower-frequency, divide-by-N clocks in the design and by gating clocks. This introduction of logic in the clock path can cause race conditions and complicates timing verification.
Consider the VHDL signal-assignment statements or the corresponding Verilog non-blocking assignment statements:
A<=B;
C<=A;
Under normal circumstances with a common clock, signal C will be assigned the old-value of A and A will be assigned the value of B. Simulators evaluate the expressions on the right hand side of the assignment operator and then assign the values to the variables on the left hand side an infinitesimally small time later. This interval between evaluation and assignment is called a delta-delay.
Simulators add delta-delays for various types of constructs (e.g. assignments) in a RTL description. These delta-delays are not always predictably added and they differ from one simulator to another. This would not be a problem if all the paths of a clock contained an equal number of delta-delays, but in practice, this is not always the case. We may end up with a situation where a flop is clocked one or more delta cycles earlier than another flop. This results in a shoot-through situation, where data is passed from the early clocked flop (source) to the late clocked flop (destination).
Designers are often confused by these types of simulation errors and can spend a long time debugging them. Designers frequently try to solve these problems by balancing the clock tree. They try to insert buffers in different clock paths so that each clock path has the same delta-delay. This is often a difficult and time-consuming task.
Designers would benefit from having a tool that accurately reports and helps correct conditions causing the simulation to generate incorrect results. Designers want such a tool to provide an easy means for solving the problems.
A shoot-through RTL Checker reads RTL design files, uses a simulator delta cycle definition, computes clock delta delays, reports and helps correct conditions that will cause the simulation to generate incorrect results. In particular, a method for checking simulation timing errors of an electronic circuit design reads one or more design files, reads or determines simulator delta cycle delays, identifies source and destination memory elements, analyzes the number of delta delay cycles between clock sources and memory element clock pins, optionally computes the data path delays if so directed by the user, and based on the delta delay analysis on clock path reports conditions that will cause RTL simulation to generate incorrect results. The design files are then corrected to avoid the reported conditions.
A method and corresponding system for checking an integrated circuit design by identifying and correcting in advance expected shoot-through behavior of a circuit simulator in accord with the present invention is implemented as RTL checker software running on a computer system. The system comprises a computer processor having access to data storage and user-interactive input/output devices, wherein the data storage stores the RTL checker software and also preferably simulator delta cycle definitions corresponding to one or more circuit simulators. When executed by the computer processor, the RTL checker software is operative to receive, by a data storage accessible to a processor, a circuit register-transfer-level (RTL) description of at least a portion of an integrated circuit design to be run on a specified simulator. The RTL description is analyzed by the processor to determine numbers of delta delay cycles for clock and data paths of the circuit design when run on the specified simulator. Preferably, this may be done by using delta cycle definitions of the specified simulator retrieved by the processor from the data storage. Next, the processor identifies, from the determined delta delay cycles and according to rules designated in the RTL checker software, any conditions in the circuit design expected to produce shoot-through behavior when run on the specified simulator. Any such identified conditions are reported to at least one of the data storage and to a user-interactive input/output device, and the RTL description is corrected as needed based on the reported conditions, the corrected description being saved in data storage for running on the specified simulator. The corrections may be performed automatically by the processor in response to the identifying of a condition of expected shoot-through behavior, and then preferably the automatic correction would be displayed on the user-interactive input/output device for confirmation or rejection by a user.
Conditions of expected shoot-through behavior are determined by first identifying any interacting source and destination memory elements in the circuit design, determining whether there is a difference of clock path delays between those two memory elements, and then determining whether an after/# clause assignment statement specifying an explicit delay is absent in a data path of the source memory element. In this case the correction would introduce the absent after/# clause assignment statement into the data path of the source memory element. Likewise, if an after/# clause assignment statement specifying an explicit delay is found to be present in a clock path of either source memory element, the correction would be to remove such statement from the determined clock paths. If any clock divider is found to be present after a common clock point for both source and destination memory elements, and if it is also determined there is a non-zero delay for the clock path to the destination memory element that is absent in the clock path to the source memory element producing a delta delay from the common clock point, then an appropriation correction would add an after/# clause assignment statement specifying an explicit delay corresponding to the non-zero delay to the clock path for the destination memory element. Also, shoot-through behavior would be expected for memory elements in a circuit design that are connected to an output port if it is determined that an after/# clause assignment statement specifying an explicit delay is absent in a data path of that memory element. If desired, a user may be allowed to specify that certain data paths should not be checked, but instead ignored.
A shoot-through RTL Checker (STC) reads RTL design files, uses a simulator delta cycle definition, computes clock path delta delays, reports and helps correct conditions that will cause the simulation to generate incorrect results. The STC uses the simulator delta cycle definition to understand how a specific version of a simulator inserts delta delays. The STC recommends using delayed assignments in the data path where necessary to solve the simulation problem. The STC analyzes each clock source in turn, looking for pairs of connected memory elements driven by that same clock source. The STC reports a shoot-through simulation error if the following conditions are true:
In addition the STC reports any explicit delay present on the clock paths to the user. This is because such uncommon practice would create further opportunity for erroneous simulation mismatches that should be avoided. The reported error will be fixed manually, semi-automatically or fully-automatically. In one embodiment, the STC automatically modifies the RTL design files to remove explicit delays on the clock paths.
The second process sig_a_proc in 110 assigns the value of signal sig_x to signal sig_a and depends on the rising edge of signal clock. Simulation waveform 120 shows signal sig_a transitioning from low to high when it is assigned the value of signal sig_x. Simulation waveform 120 shows signal sig_a is assigned the new value at a delta-delay time after the signal clock transitions from low to high.
The third process sig_b_proc in 110 assigns the value of signal sig_a to signal sig_b and depends on the rising edge of signal clock_half. Simulation waveform 120 shows signal sig_b transitioning from low to high when it is assigned the value of signal sig_a. Simulation waveform 120 shows signal sig_b is assigned the new value at a delta-delay time after the signal clock_half transitions from low to high. Signal sig_b is assigned the new value of sig_a because it uses the value of sig_a evaluated on the rising edge of signal clock_half.
Simulation waveform 130 shows the simulation results with respect to physical time increments as seen by an electronic designer. In simulation waveform 130 the electronic designer sees signal sig_b transition at the same time as signal sig_a and sees signal sig_b being assigned the new value of signal sig_a.
Since non-blocking assignments can trigger additional steps in the same time cycle, the change in sig_a can be captured by sig_b in the same clock cycle. This issue is happening because of the task scheduling sequence during simulation. In VHDL, this problem occurs because of delta delays and in Verilog, this occurs because of “non-blocking assignment can further trigger blocking/non-blocking assignment”.
In S420 the STC starts a loop for processing each of the clock sources in the RTL design. On the first iteration of the loop the STC looks for the first clock source. On subsequent iterations the STC looks for next unprocessed clock source. In S430 the STC checks if it found an unprocessed clock source. If the STC found an unprocessed clock source it proceeds to S440. If the STC did not find an unprocessed clock source the STC exits.
In S440 the STC calculates the delta delay cycles from the current clock source to the clock pins of connected memory elements. Memory elements include registers, latches and other synchronous elements controlled by a clock. In S450 the STC starts a loop for processing each pair of connected memory elements using the current clock source. On the first iteration of the loop the STC looks for the first pair of connected memory elements. On subsequent iterations the STC looks for the next unprocessed pair of connected memory elements. Pairs of memory elements that have same number of delta delay cycles from the clock source to their clock pin are ignored. In S460 the STC checks if it found an unprocessed pair of memory elements. If the STC found an unprocessed pair of memory elements the STC proceeds to S470. If the STC did not find an unprocessed pair of memory elements it loops back to S420.
Mux-based clock dividers need to be handled carefully to get an accurate analysis. When a clock drives a Mux-select and memory element outputs drive the Mux's data inputs, only the mux-select is considered as being in the clock path. The other mux inputs are considered as being in the data path.
In S470 the STC determines if a shoot-through simulation error will occur. If the source memory element has an explicit delay the STC concludes that no shoot-through simulation error will occur. If the clock path from a clock source to a memory element clock pin has an explicit delay the STC reports a warning and in one embodiment modifies the design to automatically remove the explicit delay. Clock paths should not use delayed assignment. An explicit delay is specified in a delayed assignment statement. The STC calculates a clock path difference, the difference in delta delays from clock source to memory element clock pin. If the delay in the source clock path is less than the delay in destination clock path, the STC determines that a shoot-through simulation error may occur. The designer who wants to balance the clock trees needs to know when the source clock path delay is less than the destination clock path delay.
The designer can specify that the STC should compare the clock path delay difference to the data path delay. This allows the designer to fix problems by changing the data path. In this case the STC calculates the delta delay on the data path between the memory elements. If the clock path delay difference is greater than the data path delay, the STC reports a shoot-through simulation error. In one embodiment the STC ignores data paths indicated by the user. The user can mark design elements to be ignored by assigning attributes in the RTL or by listing them in a special file.
In one embodiment the STC checks for a no_delay_comparison parameter. The user can apply this parameter to the entire design or to part of the design. When the no_delay_comparison parameter is set to “yes”, the STC will check the presence of a delayed assignment statement when there is non-zero delay in the destination clock path after a common clock point. The common clock point is a net which is common to both source and destination clock paths.
If in S470 the STC determines that a shoot-through simulation error will occur, the STC proceeds to S480. If the STC determines that a shoot-through simulation error will not occur the STC loops back to S450. In S480 the STC reports and in S490 corrects the expected shoot-through simulation error. In one embodiment, the STC writes the details of the shoot-through simulation error into a report. In the same or another embodiment, the STC makes a specific recommendation of changing the RTL to add a delayed assignment in the data path. Delayed assignment will prevent the simulation problem. In another embodiment, the STC automatically modifies the RTL to add a delayed assignment in the data path. The STC proceeds to loop back to S450.
The embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit.
The STC 520 runs as an application program on a central processing unit (CPU). In one embodiment the STC is embedded in an application program that makes multiple checks. The STC 520 interacts with a logic designer through an input device, 560 and a display, 570. The STC 520 displays STC checking results on the display, 570. A logic designer specifies STC inputs, starts the STC and views results using the input device 560 and display 570. A logic designer views a list of shoot-through simulator issues on the display 570. In one embodiment the STC 520 reads a simulator delta cycle definition 510 from a file. The STC 520 reads RTL and/or netlist design files 550. The STC 520 reads STC run-time options from a specified file or directly from the user through input device 560. The STC run-time options include a list of paths to ignore and whether to compare clock path delay differences to the data path delay. In one embodiment the STC 520 stores the shoot-through checking results in a file as a report 540. In one embodiment, the STC 520 updates the RTL and/or netlist design files 550 to automatically correct the detected errors.
