Patent Application
20110055779
The invention relates to the field of electronic device design. More specifically, various implementations of the invention are directed towards facilitating the verification of logical designs synthesized from non-sequential algorithmic descriptions of a hardware design.
Today, the design of electronic devices no longer begins with diagramming an electronic circuit. Instead, the design of modern electronic devices, and particularly integrated circuits (“IC's”), often begins at a very high level of abstraction. For example, a design may typically start with a designer creating a specification that describes particular desired functionality. This specification, which may be implemented in C, C++, SystemC, or some other programming language, describes the desired behavior of the device at a high level. Device designs at this level of abstraction are often referred to as “algorithmic designs,” “algorithmic descriptions,” or “electronic system level (“ESL”) designs”. Designers then take this algorithmic design, which may be executable, and create a logical design through a synthesis process. The logical design will often be embodied in a netlist. Frequently, the netlist is a register transfer level (“RTL”) netlist.
Designs at the register level are often implemented by a hardware description language (“HDL”) such as SystemC, Verilog, SystemVerilog, or Very High speed hardware description language (“VHDL”). A design implemented in HDL describes the operations of the design by defining the flow of signals or the transfer of data between various hardware components within the design. For example, an RTL design describes the interconnection and exchange of signals between hardware registers and the logical operations that are performed on those signals.
Designers subsequently perform a second transformation. This time, the register transfer level design is transformed into a gate level design. Gate level designs, like RTL designs, are also often embodied in a netlist, such as, a mapped netlist for example. Gate level designs describe the gates, such as AND gates, OR gates, and XOR gates that comprise the design, as well as their interconnections. In some cases, a gate level netlist is synthesized directly from an algorithmic description of the design, in effect bypassing the RTL netlist stage described above.
Once a gate level netlist is generated, the design is again taken and further transformations are performed on it. First the gate level design is synthesized into a transistor level design, which describes the actual physical components such as transistors, capacitors, and resistors as well as the interconnections between these physical components. Second, place and route tools then arrange the components described by the transistor level netlist and route connections between the arranged components. Lastly, layout tools are used to generate a mask that can be used to fabricate the electronic device, through for example an optical lithographic process.
In general, the process of generating a lower-level circuit description or representation of an electronic device (such as an RTL netlist or a gate level netlist), from a higher-level description of the electronic device (such as an algorithmic description,) is referred to as “synthesis.” Similarly, a software application used to generate a lower-level design from a higher-level design is often referred to as a “synthesis tool.”
Modern hardware designs are becoming increasingly complex and often include multiple component blocks specially designed to perform particular tasks or functions. Additionally, these designs are often capable of concurrently processing multiple tasks simultaneously. As used herein, a “concurrent design,” is a design that allows for the simultaneous execution of more than one process. In many cases, these simultaneously executing processes interact with each other. Design of “concurrent systems” is facilitated by the use of high-level algorithmic descriptions, as described above, wherein many of the functions defined by the algorithmic description are non-sequential. More particularly, many of the operations and functions (i.e. the non-sequential ones) do not have to be executed in a particular order.
Synthesizing a non-sequential algorithmic description for a circuit, results in a logical design that allows for the parallel execution of hardware processes. These concurrently executing processes share access to the same memory storage locations and often to the same data stored in memory. More particularly, a number of memory storage locations, such as, for example, a memory register, which will correspond to a variable in the algorithmic description, can be accessed by multiple processes. These shared memory locations are often referred to as “shared variables.” The timing of access to these “shared variables” by the different concurrent processes can cause the results of the process to differ. Although both results are valid, as those of skill in the art can appreciate, verification of a non-sequential algorithmic description against a synthesized logical design is difficult due to the results differing depending upon event execution and timing.
Various implementations of the invention provide methods and apparatuses for verifying a concurrent logical design and a corresponding non-sequential algorithmic description. In some implementations, verification of a non-sequential algorithmic description for a device design is facilitated by monitoring a simulation of the non-sequential algorithmic description and synchronizing the timing of selected events with timing from an already completed simulation of a corresponding logical design. With various implementations, the hierarchical blocks in the logical design are monitored during the prior simulation to record selected event information. Subsequently, the recorded event information may be used to synchronize the simulation of the non-sequential algorithmic description.
The present invention will be described by way of illustrative embodiments shown in the accompanying drawings in which like references denote similar elements, and in which:
The operations of the disclosed implementations may be described herein in a particular sequential order. However, it should be understood that this manner of description encompasses rearrangements, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the illustrated flow charts and block diagrams typically do not show the various ways in which particular methods can be used in conjunction with other methods.
It should also be noted that the detailed description sometimes uses terms like “determine” to describe the disclosed methods. Such terms are often high-level abstractions of the actual operations that are performed. The actual operations that correspond to these terms will often vary depending on the particular implementation, and will be readily discernible by one of ordinary skill in the art.
Furthermore, in various implementations of the invention, a mathematical model may be employed to represent an electronic device. With some implementations, a model describing the connectivity of the device, such as for example a netlist, is employed. Those of skill in the art will appreciate that the models, even mathematical models represent real world device designs and real world physical devices. Accordingly, manipulation of the model, even manipulation of the model when stored on a computer readable medium, results in a different device design. More particularly, manipulation of the model results in a transformation of the corresponding physical design and any physical device rendered or manufactured by the device design. Additionally, those of skill in the art can appreciate that during many electronic design and verification processes, the response of a device design to various signals or inputs is simulated. This simulated response corresponds to the actual physical response the device being modeled would have to these various signals or inputs.
Some of the methods described herein can be implemented by software stored on a computer readable storage medium, or executed on a computer. Accordingly, some of the disclosed methods may be implemented as part of a computer implemented electronic design automation (“EDA”) tool. The selected methods could be executed on a single computer or a computer networked with another computer or computers. For clarity, only those aspects of the software germane to these disclosed methods are described; product details well known in the art are omitted
As the techniques of the present invention may be implemented using software instructions, the components and operation of a generic programmable computer system on which various implementations of the invention may be employed is described. Accordingly,
The processing unit 105 and the system memory 107 are connected, either directly or indirectly, through a bus 113 or alternate communication structure, to one or more peripheral devices. For example, the processing unit 105 or the system memory 107 may be directly or indirectly connected to one or more additional devices, such as; a fixed memory storage device 115, for example, a magnetic disk drive; a removable memory storage device 117, for example, a removable solid state disk drive; an optical media device 119, for example, a digital video disk drive; or a removable media device 121, for example, a removable floppy drive. The processing unit 105 and the system memory 107 also may be directly or indirectly connected to one or more input devices 123 and one or more output devices 125. The input devices 123 may include, for example, a keyboard, a pointing device (such as a mouse, touchpad, stylus, trackball, or joystick), a scanner, a camera, and a microphone. The output devices 125 may include, for example, a monitor display, a printer and speakers. With various examples of the computing device 101, one or more of the peripheral devices 115-125 may be internally housed with the computing unit 103. Alternately, one or more of the peripheral devices 115-125 may be external to the housing for the computing unit 103 and connected to the bus 113 through, for example, a Universal Serial Bus (“USB”) connection.
With some implementations, the computing unit 103 may be directly or indirectly connected to one or more network interfaces 127 for communicating with other devices making up a network. The network interface 127 translates data and control signals from the computing unit 103 into network messages according to one or more communication protocols, such as the transmission control protocol (“TCP”) and the Internet protocol (“IP”). Also, the interface 127 may employ any suitable connection agent (or combination of agents) for connecting to a network, including, for example, a wireless transceiver, a modem, or an Ethernet connection.
It should be appreciated that the computing device 101 is shown here for illustrative purposes only, and it is not intended to be limiting. Various embodiments of the invention may be implemented using one or more computers that include the components of the computing device 101 illustrated in
As stated above, designs typically start at a high level of abstraction, such as, for example, as an algorithmic description 203 shown in
A discrepancy in the outputs 219 indicates an error in the design, the simulation, or both. However, as explained above, concurrent logical designs, such as, for example, those synthesized from a non-sequential algorithmic description, may generate a different output from the simulation than the corresponding algorithmic description will, although both outputs are correct. As a result, conventional verification techniques, such as, for example, the method 201, as not suitable for verifying modern concurrent logical designs.
As indicated, various implementations of the invention are applicable to enabling the verification of concurrent designs. An illustrative implementation will be described by reference to
The method 301 further includes an operation 305 for monitoring the logical design simulation 403. The test bench 401 includes a monitoring module 409 that enables accessing the logical design simulation 403 during simulation (i.e. while the simulation is being actively executed) and capturing data related to the logical design simulation 403. As used herein, such data will be referred to as “event data.” Examples of event data and illustrative techniques associated therewith will be described below. The method 301 additionally includes an operation 307 for logging selected event data 411 from the logical design simulation 403. In various implementations, the selected event data will be recorded into a text file and saved to a memory storage location.
Subsequently, the method 301 includes an operation 309 for identifying a simulation 413 of an algorithmic description 415 that corresponds to the logical design 405. In various implementations, the same simulation module 407 is used to implement both the logical design simulation 403 and the algorithmic description simulation 413. In alternative implementations, dedicated simulation modules 407 may be provided. The method 301 further includes an operation 313 for synchronizing the algorithmic description simulation 413 with the logged event data 411. A simulation synchronization module 417 is provided in the test bench 401 to facilitate the operation 313. Illustrative synchronization applications will be described below along with the further explanations of event data.
Lastly, the method 301 includes an operation 315 for comparing the results from the logical design simulation 403 and the algorithmic description simulation 413. Various options exist for determining a verification failure based on the operation 315 for comparing the simulation results. These options may depend upon the event data described below, and as such, will be addressed further in conjunction with the discussion of event data.
As described above, various implementations of the invention may be used to log or “record” event data during a simulation of a logical design, and subsequently, synchronize this event data with a simulation of a corresponding algorithmic description. The following discussion of illustrative event data, monitoring, and synchronization techniques, assumes that the structure of the algorithmic description is such that function calls at the top level or levels (e.g. hierarchically) become instances of modules in the logical design. For example,
In the following description of illustrative event data, it is further assumed that data is passed between these functions exclusively through the specific channel objects provided by the logic simulation modules. For example, the Catapult® suite of tools from Mentor Graphics Corporation of Wilsonville, OR utilizes a channel object called “ac_channel” that is used to transfer data between functions in a logical simulation.
As used herein, a module may refer to an algorithmic function as well as a hierarchical process in the logical design. It should be appreciated by those of skill in the art that a module, whether referring to a module in the algorithmic description or the logical design, refers to a self contained description of functional and behavioral characteristics of the design. The module communicates with the system via a “channel,” as introduced above, and is often used in a hierarchical fashion. For a more detailed description of modules and channels, the reader is pointed towards the text, Electronic Design Automation, Synthesis, Verification, and Test, Laung-Teng Wang et al. eds., Morgan Kaufmann, 2009, which book is incorporated entirely herein by reference.
Still, it is further assumed that these channels are first-in first-out and that they are sized such that data is not lost as it moves between modules. Although this is not a requirement, it limits the temporal effects in this type of design to when the data appears at the interface of a module. Additionally still, it may be assumed that each channel is synthesized to an instance of a monitoring port, such as, for example “mgc_pipe” provided in the Catapult® suite of verification tools. This allows for the observation or request of data related to the channel, such as, for example when reads and writes are occurring.
Further still, it may be assumed that when the algorithmic description and the logical design evaluate (e.g. process inputs during simulation) identical input states, there is a one-to-one correlation of channel accesses made in both the algorithmic description and the logical design.
As illustrated in
Given the event data 411, the operation 313 may synchronize the simulation 413 with the event data, such that the outputs from the simulation 403 and the simulation 413 can be used to verify the logical design 405. In various implementations, the event data corresponding to the test bench inputs is used by the test bench as inputs during the algorithmic description simulation 413. Additionally, when functions, within the algorithmic description 415 are executed (e.g. during the simulation 413,) the methods of the channels involved in the execution are overridden to return the event data corresponding to the particular input and function execution triggering the channel activity. With some implementations, data written to a channel from the algorithmic description 415 is compared to the counterpart event data captured by the operation 307. With further implementations, the channel data may be synchronized with the captured event data if needed. This will be addressed in greater detail below. Alternatively, if the channel data differs from the event data, then the verification may fail.
For example, given the following test bench, which as can be seen, calls “top” (ie. the main function in the algorithmic description 601) multiple times may be used to illustrate event logging of non-blocking reads. As can be appreciated, a non-blocking read is a request to access data that returns immediately, even when non data is available.
A sampling of events corresponding to a simulation of the logical design corresponding to the algorithmic description 601 is shown in Table 1. Each row shows the event log for a specific signal. However, as explained above, there is no temporal relationship among the rows. More particularly, B: p1:size returned 0 the 4th time it was called, therefore B: p1: data was not called for a 4th time until after the 5th (i.e. the 5th column) call to, B: p1:size.
Note that the resulting output sequence, [0, 1, 4, 2, 8, 3] is not what one would expect, or get, when running the algorithmic description 601 alone or in a conventional verification environment. More particularly, Table 2 shows a stand-alone run of the algorithmic description 601, as it executes sequentially, and as a result, propagates data with “zero delay.” Each column of this table represents a single iteration through the code. The rows are ordered sequentially as they would be called in the code. A dash indicates that the function was not called in the execution of that particular test iteration. Note that the resultant output sequence, [1, 2, 3, 4, 5, 6] does not match that of Table 1.
Conversely, Table 3 shows the results from a simulation run of the algorithmic description using various implementations of the present invention. Note that the rows of Table 3 map instances of the functions channel (i.e. the channels 509-513) using the ac_channel raeture of Catapult®. Particularly, ac_channel::available and ac_channel::read is mapped to the accesses of size and data from Table 1, respectively. Also note, that (1) was considered true when size >=1).
Using various implementations of the invention, such as, for example, the method 301, the channel state is asserted to correlate with the data from the logical simulation for each module's evaluation. For example, the 3rd call of module C (i.e. module 507 in
As can be seen, the output sequence from Table 3 now matches the output sequence from Table 1. That is, the output sequences from the two simulations now match.
It is important to note, that when the function call available( ) returns false, yet data actually exists in the channel, such as, for example, p3::available(1) in iteration 1, a non-blocking read is effectively delayed until the next call at least. Assuming as stated above, that the channel is a first-in first-out channel of sufficient size, the data will be retained indefinitely in the order it was written by the upstream module and will be read at some point. As a result, the data is seen by the module in the algorithmic description simulation in the same iteration it appeared in the logical design simulation.
Additionally, it is important to note that the second call to p2::available(1) returned true (See p2::available(1), Iteration 3 and 5 in Table 3), though the first datum will not be available (even with zero delay) until the 4th iteration (see row of A: din). In general, this occurs when a module evaluation occurs sooner, in relation to upstream modules' events or test input, in an algorithmic simulation that in a logical simulation. In the example corresponding to the above tables, module 507 (i.e. module C) was reading its inputs slower by several clock cycles, such that module 503 (i.e. module A), executing in parallel, wrote the ‘4’ prior to C's third evaluation. The delay and concurrence that allows this to happen is not modeled in the high-level programming languages used to describe circuits, such as, for example, C++. See p2::available(1), Iteration 4 in Table 3 for example.
When available( ) returns true when no data exists in the channel, various implementations will supply the requesting module with the event data. When this occurs, it is assumed that the delivering module will eventually deliver the exact data just advanced. If not, a validation error may be trigged and the validation may be marked as failing. However, when the correct data does appear from the module, it must be removed from the channel so as to avoid duplication.
This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 61/219,287 entitled “Verification of Hardware Synthesized from Non-Sequential Designs,” filed on Jun. 22, 2009, and naming Robert Condon et al. as inventors, which application is incorporated entirely herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61219287 | Jun 2009 | US |
