Patent Application
20100070257
NOT APPLICABLE
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates to evaluating the operation of electrical circuits, such as digital logic circuits, microprocessors, and the like.
Current digital logic design typically involves the use of a Hardware Description Language (HDL) to construct an abstract representation of a logic circuit. The most used HDLs today are: Verilog, SystemVerilog, and Very High Speed Integrated Circuit Hardware Description Language (VHDL). Using an HDL, a designer can construct a register transfer level (RTL) description of the logic circuit at a high level of abstraction. The RTL description may then be used to construct a gate-level description of the logic circuit, which may be implemented in an integrated circuit. The RTL description may also be provided to a logic simulator to simulate the response of the logic circuit to any desired set of inputs. Such simulation is used to verify the design of the circuit before it is physically constructed.
The verification of the design of a logic circuit is lengthy and generally involves a number of simulation runs. Simulation runs are triggered by verification failures or design changes. Verification failures can be diagnosed in several ways. One common diagnostic technique is to configure the logic simulator to generate a data “dump” file that describes the state of several selected signals in the design at several time intervals preceding and including the failure point. As is well-known by those skilled in the art, the generally accepted standard data dump file for this is the “Value Change Dump” (VCD) format, defined in the IEEE Standard 1364-2001.
While VCD files are helpful in detecting functional faults in the electrical circuit, they are not particularly useful in helping the designer understand and optimize performance aspects of the circuit's design. For example, a designer might want to know how often a particular circuit section is active to determine if power-saving circuitry should be added to it. As another example, a designer of a microprocessor might want to understand how often cache misses are occurring in the design, or how effective branch-execution prediction circuits are. Evaluating and optimizing performance aspects of a logic circuit has historically involved adding extra test circuitry to the RTL description of the circuit, such as specialized detection logic and counters, rebuilding the logic circuit with the test circuitry included, re-running simulations, and extracting the desired information by viewing waveforms generated from the test circuitry. This approach increases the costs and complexity of designing the electrical circuit since it requires extra engineering time to design and verify the added test circuitry, and to remove the test circuitry before the circuit's design is implemented in physical form (e.g., before the synthesis stage). In addition, there is a risk that the test circuitry may not be completely removed, or that portions of the designed electrical circuit are accidentally removed, leading to an ill-functioning or non-function implementation of the electrical circuit.
What is needed is a way to enable designers to easily evaluate and optimize performance aspects of their circuit designs without the aforementioned added costs, complexities, risks, and design time.
In accordance with the present invention, output characteristics of a Value Change Dump (VCD) file from a logic simulation provide useful event information pertaining to one or more performance aspects of a simulated electrical circuit, and that the event information of the VCD file may be evaluated to generate information on the one or more performance aspects. For example, a designer can identify a number of signals of the design that pertain to a selected performance aspect, and can construct an evaluation task that generates information about the selected performance aspect from the identified circuit signals. An evaluation task may comprise one or more logic and/or mathematical expressions that generate one or more performance metrics (e.g., outputs) for the selected performance aspect from the signals saved in the VCD file. (An evaluation task may also mirror the action of the test circuitry that designers currently add to the RTL descriptions of their circuits.) The one or more logic and/or mathematical expressions may then be evaluated from the VCD file to generate the performance metrics and provided to the designer. Because the evaluation of the VCD file occurs after simulation, there is no need to incorporate test circuitry into the RTL description of the logic design, thereby avoiding the many problems of the prior art approach described above.
Accordingly, one general embodiment of the invention is directed to a method for evaluating an electrical circuit, the method broadly comprising defining an output based on one or more input signals for which state indications are provided in a simulation dump file over a period of simulation time, and generating values of the output of an evaluation task at a plurality of simulation time points from the state representations.
Another general embodiment of the invention is directed to a method for evaluating an electrical circuit, the method broadly comprising obtaining access to a simulation dump file comprising state indications of the values of a plurality of signals of an electrical circuit at a plurality of simulation time points, and receiving at least one evaluation task, where the evaluation task defines at least one output based on one or more input signals, with each input signal being a signal for which state indications are provided in the simulation dump file. The method further comprises generating, from the simulation dump file, one or more state representations for the one or more input signals of the at least one evaluation task, with each state representation being representative of the state of an input signal over a period of simulation time, and generating values of the one or more outputs of said at least one evaluation task at a plurality of simulation time points from the one or more state representations.
Another general embodiment of the invention is directed to a computer-readable storage medium configured to store instruction sets which, when executed by a processor of a computer system, become operational with the processor for evaluating an electrical circuit. The exemplary computer-readable storage medium broadly comprises a first instruction set for obtaining access to a simulation dump file comprising state indications of the values of a plurality of signals of an electrical circuit at a plurality of simulation time points, and a second instruction set for receiving at least one evaluation task, where the evaluation task defines at least one output based on one or more input signals, with each input signal being a signal for which state indications are provided in the simulation dump file. The exemplary computer-readable storage medium further comprises a third instruction set for generating, from the simulation dump file, one or more state representations for the one or more input signals of the at least one evaluation task, each state representation being representative of the state of an input signal over a period of simulation time, and a fourth instruction set for generating values of the one or more outputs of said at least one evaluation task at a plurality of simulation time points from the one or more state representations.
Another embodiment of the invention is directed to a system for evaluating an electrical circuit, the system broadly comprising a processor and a memory coupled to the processor, where the memory is configured to store a plurality of instruction sets which, when executed by the processor, become operational with the processor for evaluating an electrical circuit. The memory comprises a first instruction set for obtaining access to a simulation dump file comprising state indications of the values of a plurality of signals of an electrical circuit at a plurality of simulation time points, and a second instruction set for receiving at least one evaluation task, where the evaluation task defines at least one output based on one or more input signals, with each input signal being a signal for which state indications are provided in the simulation dump file. The memory further comprises a third instruction set for generating, from the simulation dump file, one or more state representations for the one or more input signals of the at least one evaluation task, each state representation being representative of the state of an input signal over a period of simulation time, and a fourth instruction set for generating values of the one or more outputs of said at least one evaluation task at a plurality of simulation time points from the one or more state representations.
The above general embodiments and other embodiments of the invention are described in the Detailed Description with reference to the Figures. In the Figures, like numerals may reference like elements and descriptions of some elements may not be repeated.
Invention Overview. The present invention enables a designer to define one or more evalution outputs to be generated by evaluating the information stored in a simulation dump file. An evaluation output may comprise a Boolean expression generated from one or more signal values in the dump file, and each output may be provided for plotting as a function of the simulation time points. An evaluation output may also comprise a running count of the number of defined clock cycles such a Boolean expression is True. To provide this functionality, an exemplary method according to the present invention may comprise receiving a description of the desired evaluation outputs, which may be referred to as a set of evaluation tasks, and then parsing the description to identify the inputs needed for the tasks and to generate an evaluation structure for each desired evaluation output. Using “SigA” and “SigB[3:0]” as names of exemplary input signals, an exemplary task may define an evaluation output “Out1” as a Boolean function of the input signals:
Out1=SigA AND (SigB[3:0]==“1111”). [1]
Another exemplary task may be to define a clock cycle for the simulation, a Boolean expression that is to be evaluated at the start of each defined clock cycle, and a count that is to be incremented each time the Boolean expression is true at a start of a defined clock cycle. The task may be defined with the following set of statements:
Set_Clock_Cycle(Start_time,Length); [2]
Out2[7:0]=Count(SigA AND (SigB[3:0]==“1111”),Optional_Reset_Condition). [3]
In the first statement, the start time of the first full clock cycle of the simulation, as measured in the simulation time, is provided by the value of “Start_time.” This value is typically zero. The length of each clock cycle, which is assumed to be constant, is provided by “Length,” which specifies the cycle length in the simulation time. The cycle Length is an integer value in the time scale of the VCD file. (For example, if the time scale of the VCD file is 10 ns, a 1 microsecond clock cycle would be represented by Length=100). The clock cycle typically follows a clock signal of the simulation, beginning at the rising edge of the clock signal. If one wishes to define the clock cycle at the falling edge of the clock signal, one may change the value of “Start_time” to coincide with the first falling edge of the clock signal in the simulation. The next statement defines an eight-bit signal Out2[7:0] and a count for the number of cycles that the Boolean expression SigA AND (SigB[3:0]==“1111”) is True. The statement may also provide an optional reset condition, which is a Boolean expression of signals that, when True, resets the count for Out2[7:0] to zero at the simulation time for which the expression becomes True. The statements of the evaluation tasks may be prepared by the circuit designer and saved in a text file.
Simulation Dump Files. VCD, defined in IEEE Standard 1364, the IEEE Standard for Verilog Hardware Description Language, is an ASCII-based format for simulation dump files output by EDA logic simulation tools. The VCD dumpfile provides detailed step-by-step results of a simulation run for analysis, re-simulation, or design verification. The VCD file comprises a header section with date, simulation software information including version number, and timescale information; a variable definition section containing scope information and lists of signals instantiated in a given scope; value changes for selected signals in a given scope; and time entries every time there is a state change of the selected signals. The VCD file is not explicitly divided into sections; rather, sections are identified by keywords that belong to each section. For example, keyword $timescale identifies a header section and defines the timescale of the simulation, key $end terminates a section, and keyword $var identifies a variable definition section to define the signals. Each signal defined in a variable definition section is assigned a shorthand identification code, which comprises a combination of one or more ASCII printable characters, such as “!” and “˜”. The shorthands are used in the value change section, instead of the full names of the signals, to reduce the size of the dump file, and to speed up the generation of the dumpfile by reducing I/O file writes.
An exemplary VCD simulation dump file is shown in
Referring to
State Representation of the Input Signals. Generating state representations of the input signal may be as simple as reading the dump file for the values of the input signals at a given time point in the simulation, and then storing the values in a computer-readable memory. However, many aspects of the implementations of the methods, systems, and computer program products according to the present invention can be simplified by creating a data structure to represent the state values of the input signals at the simulation time points when any of the input signals changes state. For this,
Thereafter, as each additional time point is encounted, an additional instance of record DataState will be created and filled with data, and the previously created record instance will have its “next” value updated to point to the memory address of the newly added record instance. Each integer location in Values[Nmax] of the record structure DataState can hold up to 32 signal bits. If additional bits are needed, 64-bit or 128-bit integer definition may be used for Values[Nmax] in the struct definition. The values stored in Values[Nmax] correlate to the input signals named in Signal_Name_Array[Nmax]. That is, the value in Values[ii] is for the input signal named by Signal_Name_Array[ii], for any integer value of ii from 0 to (Nmax−1). The shorthands in Shorthands_Array[Nmax] correlate in a similar manner. When the “$dumpoff” keyword is encountered in the dumpfile, which indicates the end of the simulation time, an integer “EndTime” of the data structure of
In section (3) of the pseudo-code, the first time point from the value change section of the dump file is read, and a first instance of record DataState is created with its “timepoint” value set to the value of the first simulation time point (usually zero), its “next” pointer value set to “NULL,” and its “Values[N]” array set to values of the input signals at the time point. Conventional parsing code may be used to read the data from the value dump section according to the file's syntax, and the shorthands stored in Shorthands_Array[N] can be used to identify the values in the dump file. Section (4) of the pseudo-code reads the dump file for the next time point. Section (5) finds the values of the input signals. If none of the values have changed from the prior time point, then the pseudo-code proceeds to section (6). If any one of the values has changed, then another instance of record DataState is created with its “timepoint” value set to the current time point, its “next” pointer value set to “NULL,” and its “Values[N]” array set to values of the input signals at the time point. The newly-created record is then linked into the linked list pointed to by “ListDataStates” by changing the “next” pointer value of the previously added record to point to the memory address of the newly created record. Finally, in section (6) of the pseudo-code, the dump file is read for the next time point. If there is no next time point, then the process is ended and the value of EndTime is set to the last encounter simulation timepoint plus a small number; otherwise, the process goes back to section (5).
The above actions provide examples of implementing blocks 11 and 13 of
Parsing of Evaluation Tasks. Prior to generating the state representations of the input signals, the user's evaluation tasks are received, parsed, and embodied in data structures according to one embodiment.
Before discussing the parsing of the Evaluation Statements, however, the parsing of Boolean expressions and the generation of corresponding parse trees is first discussed.
A conventional-type recursive descent parser can be readily modified to create a ParseTree instance each time it creates a tree node, fill in the field values of the ParseTree instance as it processes the node, and to link the nodes in the structure of the parse tree. The result of this is shown in
Once the recursive descent parser has generated the record structure shown in
Value=RecursiveEvaluate(node_pointer,Values_pointer);
where node_pointer is a pointer to a ParseTree record of the tree, where Values_pointer is a pointer to an array that has the values of the input signals, and where the function returns a value in integer form. Upon the initial call to the RecursiveEvaluate( ), node_pointer may be set to the eval_output pointer of an EvalOutput record, and Values_pointer may be set to Values[Nmax] array of a DataState record (shown in
When the recursive evaluator is called to evaluate ParseTree Instance #1, it will return a value that is the Boolean AND of the values provided by its left and right children. Before it can compute the AND operation, however, it performs a function call of a second instance of itself (a recursive call) to obtain the value of the left child. After that, it performs a function call to a third instance of itself to obtain the value of the right child. These values may be stored in the “Value” fields of Parse Tree Instances #2 and #3, and they may be provided through return values from the function calls. The second and third instances may be called from the first instance as follows:
LeftVal=RecursiveEvaluate(left,Values_pointer);
RightVal=RecursiveEvaluate(right,Values_pointer);
With both of the right and left values obtained, the first instance of the recursive evaluator places the AND operation of the left and right values LeftVal and RightVal in the “Value” field of ParseTree Instance #1 and returns the result to the calling code. But before it can do that, the second and third instances of the evaluator must complete their tasks. The second instance of the evaluator does a simple Fetch operation to get the value of SigA. It stores this value in the “Value” field of ParseTree Instance #2 and provides this to the first instance of the evaluator as a return value LeftVal of the function call. The third instance of the recursive evaluator will return a Boolean value resulting from the EQUALS test applied to the values provided by its left and right children. Before it can compute the EQUALS operation, it first calls a fourth instance of itself to obtain the value of its left child. After that, it calls a fifth instance of itself to obtain the value of its right child. These values may be stored in the “Value” fields of Parse Tree Instances #4 and #5, and are provided through return values of the function calls. With both right and left values obtained, the third instance of the recursive evaluator places the result of the EQUALS test in the “Value” field of ParseTree Instance #3, and provides it to the first instance as a return value RightVal of the function call. The fourth instance of the evaluator does a simple Fetch operation to get the value of SigB[3:0]. It stores this value in the “Value” field of ParseTree Instance #4 and provides this to the third instance of the evaluator as a return value of the function call. The fifth instance of the evaluator does a simple Constant operation and returns the value stored in the “Value” field of ParseTree Instance #5.
Now that the details of parsing and evaluating the Boolean expressions present in the evaluation task statements have been discussed, the parsing of an entire evaluation task statement and the generation of a corresponding representation in an EvalOutput record are discussed next.
In the next code section, section (2b), the next word in the Evaluation Statement after the “=” sign is read. If the word is “Count”, then several additional actions in section (2b) are performed to process the Count statement. If not, the statement is a Boolean expression task, and is processed in section (2c) under the “else” branch of the test statement. In section (2b), the record's field “OutputCount” is set to True, and the Count statement is processed by reading Boolean evaluation expression from the Count statement, and then calling the recursive-descent parser to create a parse tree of ParseTree records to represent the expression. A pointer to the parse tree is then saved in the “eval_output” field of the newly created EvalOutput record. The Count statement is further read for an optional reset condition (Optional_Reset_Condition). If one is present, the Boolean expression for the reset condition is read and provided to the recursive-descent parser to create a parse tree of ParseTree records to represent the expression. A pointer to the parse tree is then saved in the “reset_count” field of the newly created EvalOutput record. Processing then goes to the end of the loop, as identified by the END_STATEMENT label, to process the next statement.
In section (2c), the Boolean expression task is processed by setting the record's field “OutputCount” to False, by reading Boolean evaluation expression from the Boolean task statement, and then calling the recursive-descent parser to create a parse tree of ParseTree records to represent the expression. A pointer to the parse tree is then saved in the “eval_output” field of the newly-created EvalOutput record. Processing then goes to the end of the loop, as identified by the END_STATEMENT label, to process the next statement.
The above actions provide an example of implementing block 12 of
Generation of the Evaluation Outputs.
The outer loop starts at section (2) of the pseudo-code. It begins by determining if the current simulation time is at the start of a clock cycle. If so, it sets CycleEdge to True, otherwise it sets CycleEdge to False. The determination of whether the current simulation time is at the start of a clock cycle can be done by performing an integer divide of the variable CurrentTime by the variable Cycle_Length, and comparing the reminder of the division to Cycle_Start. (The remainder of the integer division is commonly known as the “modulo” of the two division variables.) If the remainder is equal to Cycle_Start, then the current time is at a rising edge of the clock. If not, then the current time is not at a rising edge of the clock. Next, the inner loop is executed to generate the evaluation outputs from the values of the input signals at the current time. The inner loop will be described below in greater detail. After the inner loop, the execution of the pseudo-code proceeds to section (3), where the CurrentTime and the evaluation outputs are provided to an output subroutine, and the next value for the current time (CurrentTime) is computed. The output subroutine, called Output_Results_Subroutine(*), is described below. As for the next value of the current time, the start time of the next cycle from the current time first is computed. This may be done by performing an integer division of the current time by the cycle length, such as with the mathematic operators Trunc(Current_Time/Cycle_Length), then multiplying the result of the integer division by the Cycle_Length, which provides the cycle time just prior to the current time. One cycle length may then be added to this to get the NextCycleTime. As the next part of section (3), the link list of data states is read to find out the next simulation timepoint after the current time. This may be done by accessing CurrentDataState->next->timepoint. This next simulation time is compared to the value in NextCycleTime. If it is less than NextCycleTime, then the next value of CurrentTime is set to the next simulation time of the linked list of data states, and the CurrentDataState pointer is advanced to the next DataState record in the linked list of data states; otherwise, the next value of CurrentTime is set to NextCycleTime. The advancement of the CurrentDataState pointer may be done by the command “CurrentDataState=CurrentDataState->next;”.
The inner loop is now described. Temporary pointer Eval is set equal to EvalList, which is the start of the task list. Then Eval is stepped through each node of the EvalList linked list. The “OutputCount” field of Eval is tested to see if the evaluation task is a count task or a Boolean task. If it is a count task, section (2a) of the pseudo-code is executed. If it is a Boolean task, section (2b) of the pseudo-code is executed. In the Count processing, section (2a) first determines if a reset condition is specified by the count task. If one is present, it then calls the evaluator “RecursiveEvaluate” to evaluate the Boolean expression pointed to by “Eval->reset_count”. If the evaluation is true, then value of Eval is set to zero (Eval->Value=0); otherwise there is no change in the value. Next, it determines if the current time is at an edge of a cycle by testing to see if CycleEdge is True. If not, it proceeds to section (2c). If so, it calls the evaluator “RecursiveEvaluate” to evaluate the Boolean expression pointed to by “Eval->eval_output”. If the evaluation is True, then value of Eval is incremented by one. In the Boolean expression processing, section (2b) calls the evaluator “RecursiveEvaluate” to evaluate the Boolean expression pointed to by “Eval->eval_output”, and places the result in Eval->Value.
Both of sections (2a) and (2b) go to section (2c) for further processing. There, the Eval pointer is advanced to the next evaluation task in the list (“Eval=Eval->next;”).
The above actions provide an example of implementing block 14 of
As another implementation approach, self-writing code may be used in place of the parse trees to evaluate the output and reset expressions of the evaluation tasks. In such an implementation, the pointers eval_output and reset_count of an EvalOutput record may comprise pointers to code functions, and these code functions may be written during each execution of the program by the pseudo-code shown in
Output Subroutine. As indicated above, the Output_Results_Subroutine(*) is called in the outer loop to output the current time and the results of the evaluation outputs. The output subroutine can take many forms, depending upon the graphical user interface that is desired to provide the results. In the logic simulation art, there are several commercially-available graphical user interfaces generically called “VCD viewers.” In general, these products read in a VCD simulation dump file, present the user with a listing of the signals in the dump file, and allow the user to select a set of signals to be displaced. The VCD viewer also allows the user to advance through the time line of the simulations results. Accordingly, it would be advanteous to make use of existing VCD viewers, which may be done with an implementation of Output Results_Subroutine(*) shown in
The exemplary implementation of Output_Results_Subroutine(*) is provided in pseudo C-language code in
At section (1) of the pseudo-code, the global pointer PrevEvalList is tested to see if it is equal to “NULL”, which would indicate that this is the first call of the subroutine, and that the beginning of the VCD output file needs to be created. If it is equal to NULL, section (1) of the pseudo-code creates the output VCD file (which may have a fixed file name), writes header information to the output VCD file, writes timescale information to the output VCD file, and writes the variable definition section. The latter action is done by the while loop at section (1b), where pointer Eval steps through the CurrentEvalList linked list, and where the Data_Bits value, shorthand name, and full name of each evaluation output signal are written. Next, at section (1b), the “$dumpvars” keyword is written, and the initial values and shorthands of the evaluation outputs are written to the VCD file by a while loop, which steps pointer Eval through the CurrentEvalList linked list. After that, the “$end” keyword is written to the output VCD file to complete the $dumpvars command. Next, at section (1c), the linked list of records for PrevEvalList is created, and PrevEvalList is set to point to the linked list. Then the contents of the link list pointed to by CurrentEvalList are copied to the new linked list pointed to by PrevEvalList. The creation of the linked list for PrevEvalList may be integrated into the while loop of section (1a), and the copying of contents of the linked lists may be integrated into the while loop of section (1b). At this point, the global pointer PrevEvalList no longer has a NULL value. After this, the pseudo-code exits the subroutine.
Upon the next call of the subroutine, section (1) of the pseudo-code is not executed since PrevEvalList is no longer NULL. Instead, section (2) is executed. This section compares the evaluation outputs at the current time, as provided by CurrentEvalList, against their previous values, as provided by PrevEvalList. If there is no change in any of the output values, then no action is taken. If there is a change, then the current time is written to the file, along with shorthand of each output that has changed, along with its new value. Section (2) has a while loop that steps Eval and PrevEval through the CurrentEvalList and PrevEvalList linked lists in tandem, and compares the current and previous values of each output. If there is a difference between the values, the current time is written to the VCD output file if it is the first difference encountered by the while loop, followed by the value and shorthand of the output. The first difference encountered by the while loop is tracked by the Boolean variable FirstChange, which is set to True before the while loop, and then set to False after the first encounter. The writing of the current time is only done when FirstChange is true.
After section (2) is executed, section (3) is executed. This section copies the contents of the CurrentEvalList linked list to the PrevEvalList linked list in preparation for the next call of the subroutine. After all of the information has been written to the VCD file, the main subroutine may call a subroutine to write the “$dumpoff” command to the file, and to close the file. The subroutine may be modified to further output the values of the input signals. One of ordinary skill in the art may do this further modification with undue experimentation.
Merge VCD Files Program. Normally, there is no need to merge two VCD files. However, with the above inventions, it would be advantageous to have a facility that could merge the input simulation dump file with the output VCD file, thereby enabling a designer to view all of the signals of the simulation with the evaluation outputs in the output VCD file.
Section (2) starts by reading the first data dump lines of the input VCD files. It then starts a loop that steps through the data dump lines of the input VCD files and selectively writes the data dump lines to MergedFile based on the simulation times of the data dump lines. If the data dump lines of both input files have the same simulation time, then they are merged into one data dump line for MergedFile. If not, the data dump line of the file having the earlier simulation time is written to MergedFile. The start of the loop reads the simulation times of the current data dump lines into temporary integer variables Time1 (for FirstVCDfile) and Time2 (for SecondVCDfile). At section (2a), the two times are tested to see if they are equal. If they are, the data dump lines of both input files are merged and written to MergedFile, and the next lines of both input VCD files are read. If not, the pseudo-code progresses to section (2b), where the times Time1 and Time2 are tested to see if Time1 is less than Time2. If so, the current data dump line of FirstVCDfile is written to MergedFile, and the next data dump line of FirstVCDfile is read. If not, then Time2 is less than Time1, and the current data dump line of SecondVCDfile is written to MergedFile, and the next data dump line of SecondVCDfile is read. These tests are easily handled by a compound if-then-else statement, in which any order of the tests may be conducted.
Section (3) determines if the current line of either or both of the input VCD files is at the “$dumpoff” command. If both input VCD files are not at the “$dumpoff” command, then the execution of the pseudo-code returns back to the LOOP_START label of section (2) to do another iteration of the loop. If the FirstVCDfile is at the “$dumpoff” command, then the remainder of the data dump lines of SecondVCDfile are written to MergedFile. Otherwise, if the SecondVCDfile is at the “$dumpoff” command, then the remainder of the data dump lines of FirstVCDfile are written to MergedFile. At this point, all of the files may be closed, and the program exits operation. While the three tests of section (3) have been programmed into separate sections, it may be appreciated that they can be handled by a compound if-then-else statement, in which any order of the tests may be conducted.
The designer may then open MergedFile with a VCD viewer and view the evaluation outputs along with all of the simulation signals of the input VCD file. To provide a simple interface for the designer, a simple operating-system level script (e.g., a UNIX shell script) may be written to call the main program for generating the evaluation outputs, the VCDMerge(*) program, and the VCD viewer in successive order, and to manage the input, output, and merged VCD files.
System and Computer-Program Product Embodiments. The above method and pseudo-code embodiments may be implemented by computer-program products that direct a computer system to perform the actions of the methods and pseudo-codes. Each such computer-program product may comprise sets of instructions embodied on a computer-readable medium that directs the processor of a computer system to perform corresponding actions, including the creation of various data structures and/or self-writing code.
As shown in
User input devices 1040 include all possible types of devices and mechanisms for inputting information to computer system 1020. These may include a keyboard, a keypad, a touch screen incorporated into the display, and other types of input devices. In various embodiments, user input devices 1040 are typically embodied as a computer mouse, a trackball, a track pad, a joystick, a wireless remote, a drawing tablet, and the like. User input devices 1040 typically allow a user to select objects, icons, text and the like that appear on the monitor 1010 via a command such as a click of a button or the like.
User output devices 1030 include all possible types of devices and mechanisms for outputting information from computer 1020. These may include a display (e.g., monitor 1010), non-visual displays such as audio output devices, etc.
Communications interface 1050 provides an interface to other communication networks and devices. Communications interface 1050 may serve as an interface for receiving data from and transmitting data to other systems. Embodiments of communications interface 1050 typically include an Ethernet card, a modem (telephone, satellite, cable, ISDN), (asynchronous) digital subscriber line (DSL) unit, FireWire interface, USB interface, and the like. For example, communications interface 1050 may be coupled to a computer network, to a FireWire bus, or the like. In other embodiments, communications interface 1050 may be physically integrated on the motherboard of computer 1020, and may be a software program, such as soft DSL, or the like.
In various embodiments, computer system 1000 may also include software that enables communications over a network such as the HTTP, TCP/IP, RTP/RTSP protocols, and the like. In alternative embodiments of the present invention, other communications software and transfer protocols may also be used, for example IPX, UDP or the like.
In some embodiments, computer 1020 includes one or more Xeon microprocessors from Intel as processor(s) 1060. Further, in one embodiment, computer 1020 includes a UNIX-based operating system, such as Linux.
RAM 1070 and disk drive 1080 are examples of tangible computer-readable media configured to store data such as computer-program product embodiments of the present invention, including executable computer code, human-readable code, or the like. Other types of tangible computer-readable media include floppy disks, removable hard disks, optical storage media such as CD-ROMs, DVDs and bar codes, semiconductor memories such as flash memories, read-only-memories (ROMs), battery-backed volatile memories, networked storage devices, and the like. RAM 1070 and disk drive 1080 may be configured to store the basic programming and data constructs that provide the functionality of various embodiments of the present invention.
Software code modules and instructions that provide the functionality of the present invention may be stored in RAM 1070 and disk drive 1080. These software modules and instructions may be executed by processor(s) 1060. RAM 1070 and disk drive 1080 may also provide a repository for storing data used in accordance with the present invention.
RAM 1070 and disk drive 1080 may include a number of memories including a main random access memory (RAM) for storage of instructions and data during program execution and a read-only memory (ROM) in which fixed instructions are stored. RAM 1070 and disk drive 1080 may include a file storage subsystem providing persistent (non-volatile) storage for program and data files. RAM 1070 and disk drive 1080 may also include removable storage systems, such as removable flash memory.
Bus subsystem 1090 provides a mechanism for letting the various components and subsystems of computer 1020 communicate with each other as intended. Although bus subsystem 1090 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.
Example Task—Evaluation of a Pipelined Load-Store Unit of a RISC Processor. This exemplary task is to find the number of cycles for which all four associative data cache ways of a load-store unit of a RISC processor are accessed by load operations during a particular section of a program segment. This information could, for example, be used to calculate the power consumption caused by the load operations as they propagate through a microprocessor pipe, and could be used by a designer to implement a variety of power saving techniques. In the circuit, there are four signals, denoted as “lsu_data_me_ea[3:0]”, for the four respective associative data cache ways, each of which is in an active high state when its respective cache way is active. Also in the circuit, there is a fifth signal, denoted as “lsu_all_ld_ea”, which is in an active high state when the load-store unit is using one or more of the associative data cache ways for load operations. Thus, an appropriate set of evaluation tasks could be:
All_Active=((lsu_data_me_ea[3:0]=‘1111’) AND lsu_all_ld_ea);
Set_Clock_Cycle(0, 1);
Cnt_All[7:0]=Count((lsu_data_me_ea[3:0]=‘1111’) AND lsu_all_ld_ea), 0);
The first evaluation statement determines when all four data cache ways are active during loads, and the last two statements count the number of cycles in which the condition occurs, where the cycles start at timepoint 0 and each cycle is 1 timepoint in length. The input VCD file is provided by the file shown in
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the inventions as set forth in the claims. In addition, the techniques, methods, computer-program products, and systems of the present invention are suitable for use with a wide variety of EDA tools and methodologies for checking, verifying, editing, revising, and fixing circuit layouts. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
