Designing integrated circuits often involves consideration of various factors that relate to electronics, circuits, analog functions, logic, and other functionality. Before an integrated circuit device is released for production, the device may undergo a series of simulation tests to ensure that it will operate as planned and expected. These simulation tests are referred to as design verification. Design verification emulates bugs and other issues that may occur in a device, so that the design team can remedy mistakes before they reach the end customer.
Verification often involves several engineers collaborating in a combined effort to check and test multiple circuits under various circumstances and operating environments. The standardized protocol Universal Verification Methodology (UVM) is a common framework that allows for unified verification techniques for integrated circuits, streamlining the verification process. However, UVM still requires laborious manual coding and de-bugging, both of which are time consuming and labor intensive. Such efforts are also prone to manual errors, as users manually process, navigate, and try to clearly understand large amounts of data.
The present disclosure describes a computer and/ or computer processor configured to generate test code based on a graphical representation of a test scenario. The graphical test scenario sequence simulates testing on an integrated circuit device. The processor is in communication with a user interface and a memory (e.g., an electronic storage device such as a hard drive or a memory chip). The computer processor is configured to execute a variety of programs, which may collectively be referred to as a graphical sequence builder.
The programs execute (e.g., the programs are processed or run by the processor) to generate test code based on a graphical representation of a test scenario. The programs include a building program that builds a flow chart for display on a user interface (e.g., an interface display on a computer monitor), with graphical event modules representing source code of test scenarios. A flow control program displays graphical flow control operators representing source code associated with logical elements connecting graphical event modules in the flow chart. The code generating program can merge the source code associated with the graphic event modules and the graphical flow control operators to preserve the sequence or “flow” of the source code represented graphically in the flow chart. A user can rearrange modules by dragging and dropping them within the flow chart, and the code generating program will generate new source code to represent the re-assembled sequence.
A navigation program allows a user to interact with the user interface. The navigation program executes to operate functionality, which functionality can include expanding display windows, toggling between windows, zooming in and out of the flow chart, panning, manually inputting commands in a command terminal, selecting event and flow logic modules, and dragging and dropping graphical event modules. Upon assembly of the flow chart, the graphical test scenario source code is written to a file, saved and outputted to the end user.
The implementation of graphics representing source code alleviates laborious manual coding and de-bugging, which are time consuming and labor intensive. The graphical sequence builder also mitigates manual errors, since it alleviates the need for a user to process, navigate, and clearly understand large amounts of data.
These and other benefits may become clearer upon making a thorough review and study of the following detailed description.
The present disclosure describes examples of computer implementable techniques or programs that allow efficient and convenient production of test scenarios when compared to manual coding techniques. These programs may be referred to collectively as a “graphical sequence builder,” or a “graphical sequence builder.” Certain embodiments of the graphical sequence builder can create virtual test simulations in a graphical environment to be simulated on an integrated circuit.
The graphical sequence builder includes programs that add graphical test modules to a graphical environment via a user interface, and assemble a graphical test scenario in the form of a flow chart. Using these programs a user can add or delete graphical modules to the graphical flow chart to manipulate from a user interface to manipulate the test scenario without needing to rely on manual coding. For example, a user add graphical modules by way of a drop-down or other type of list or menu, via a drag and drop feature, via keyboard shortcuts, or via other techniques that do not necessarily involve manual coding. The graphical sequence builder also includes programs that add flow control operators (or flow control modules) that dictate or otherwise regulate the flow the test sequence among the graphical test modules in the flow chart. For example, the flow control operators inform the flow chart which test modules should precede and/or follow another in the test sequence, and can also indicate whether certain logic conditions apply to the sequence.
Certain aspects of the graphical sequence builder also include a navigation program that provides a graphical interface that facilitates navigation among various components of the graphical sequence builder (e.g., the graphical environment, the source code, the command line terminal, etc.). The navigation program allows the user to display and edit existing components at various levels, and in various formats (e.g., graphical format, source code format, hybrid formats, etc.).
The drawings present block diagrams, flow diagrams, screen shots and other graphics depicting implantation and operation of various examples of the graphical sequence builder and related components.
In some embodiments, the input device 20b and the display 20a can be the same, or at least intertwined. For example, the user interface 20 can include a touch screen that provides both the function of the display 20a and the input device 20b.
The CPU 10 also comprises and/or accesses memory 70, which can be an electronic storage device. For example, the memory 70 can include a thumb drive, an SD card (or micro SD card), RAM memory, a hard drive, or other storage media, or a combination of such memory. The memory 70 can also be stored on the cloud 80, for example, and in some embodiments can include or be in communication with a network 60 or some other device that allows information stored on the memory 70 to communicate with the CPU 10, and the user interface 20.
In one example, one program (e.g., the building program 13) or a combination of the programs operate within the UVM framework; a standardized protocol designed to help unify techniques for verifying integrated circuit designs. The UVM provides a library of automation features that are compatible with the System Verilog language. The UVM provides a common framework for developing verification environments, however using UVM requires manual coding, which can be time consuming and laborious for engineers. To facilitate this process, the building program 13 uses graphical representations of test scenarios that are associated with source code. For example, instead of a user manually writing the source code for a certain test sequence, the building program 13 enables the user to drag and drop graphical modules into the flow chart 38 that represent the source code for the test sequence. This can serve to essentially “copy and paste” the source code for the sequence into a file that the graphical sequence builder can use to ultimately generate the source code making up the test scenario sequence.
A flow control program 14 helps design and organize the flow between the graphical event modules of the flow chart 38. In response to receiving an “add logic” signal from the user interface 20, the flow control program 14 displays flow logic operators in the graphical environment in relation to the flow chart 38 via the user interface 20. For example, a user may click on a logic operator 45 of the drop-down menu 43 (shown in
Some examples of the graphical sequence builder also include a code generating program 15. The CPU 10 executes the code generating program 15 to generate test code based on the source code associated with the graphical event modules of the flow chart and the flow control modules. For example, the code generating program 15 stitches together the source code in such a manner that retains the sequence of the source code associated with each module in the graphical environment. The code generated by the code generating program 15 can then be used to simulate the test scenario on an integrated circuit.
As noted above, some examples of the graphical sequence builder include a navigation program 140. The CPU 10 can execute the navigation program 140 to allow a user to manipulate, edit, and modify the display of a user interface 20. The navigation program 140 can control the display of the source code associated with the graphical environment via the user interface 20 in response to receiving a command, such as a display control input signal generated by a user via the user interface 20.
The block diagram example of
An example screenshot of a hybrid view 27 consisting of four views displayed on a user interface 20 is shown in
The navigation program 140 can also operate to display a panned view of the flow chart 38 in response to receiving a pan signal from the user interface 20, wherein the panned view can display aspects of the flow chart 38 which are horizontally wider than the graphical view 25 window on the user interface 20. For example, a user executes the navigation program 140 by clicking and sliding a slide bar to the right or to the left to display aspects of the flow chart 38 which are horizontally wider than the graphical view 25 window on the user interface 20.
The flow chart 38 can also be configured to display a fit to screen view in response to receiving a fit to screen signal from the user interface 20, such that the graphical view 25 window is expanded to occupy the entire display on the user interface 20. For example, the user clicks on a box icon 27 in the upper-right corner of any of the windows or the hybrid view window on the user interface 20 sending a fit to screen signal that is received by the navigation program 140 that executes to expand any of the windows or the hybrid view window to fill the entire screen on the user interface 20.
A code view 26 window is displayed in the upper left window of
In
When a user selects an event module 44 or a flow control module 45 the building program 13 and/or the flow control program 14 will display the module as a graphic in the graphical environment of the graphical view window 25.
In
UVM_Messages facilitate communication between the building program 13 and the user interface 20. The user can set one message per UVM_Message graphical event module 56, and may set the severity to one of a variety of severity indicator levels. These levels can include, for example, one or more of the following: UVM_INFO, UVM_WARNING, UVM_ERROR, UVM_FATAL to indicate, for example, information about the sequence, a warning of a potential issue in the sequence, a run-time or other type of error in the sequence, or a fatal issue with the sequence. If UVM_INFO is selected, then the user may set the message “verbosity” to one of the following: UVM_NONE, UVM_LOW, UVM_MEDIUM, UVM_HIGH, UVM_FULL, and UVM_DEBUG. Variables can be added for printing inside the message.
In a computer, a register is a small set of data holding places that are part of the CPU. The register may hold a storage address, source code, a bit sequence or individual characters. The graphical register access module 54 represents the source code associated with accessing the CPU registers and is used for read and write transaction to the register files. The register access module 54 is a software model of the registers of an electronic circuit device, or chip. The model holds the expected value of each of the device's registers at any given time. During simulation, the actual registers value of the device is read and checked versus the register model. In addition, there is a register access module that performs read and write operation to the registers. The graphical register access module 54 has several “register access types”, such as write, read, and poll, that are visible in a pop-up upon clicking the graphic. Until the register access type and register access are defined, the component (e.g., a graphical event module or graphical flow control module) is not validated, and the user may not select another component, or leave the test scenario.
Another useful event action component of the event module array 44 of the drop-down menu 43 is a wait event. The graphical wait event module 55 is associated with source code of the building program 13 relaying to the test sequence to wait a specified time until a specific event occurs in the test scenario via a “wait for” command in the source code, which may include clock cycle, (e.g., in terms of nanoseconds and picoseconds). The exact time for the program to pause is selected from the wait time event module from the action blocks 44 of the drop-down menu 43.
A user can write and/ or modify code associated with the test sequence by selecting the custom code block of the drop-down menu 43.
A Fork node is created by default with two threads. For example,
The user may add or remove threads. Removing a thread with a component defined on it will invoke a confirmation pop-up. The user may define a name for each thread to be displayed on the flow chart 38. Hovering over a thread will highlight it in the flow chart 38.
Certain embodiments of the disclosure also present methods for generating test code to be used to simulate testing on an integrated circuit. The methods can be carried out by a computer, or a computer processor executing the programs of
According to one embodiment of the method 100, a user selects 201 an event module from the action blocks from a graphical drop-down menu and the event module is displayed as a graphical event module in a flow chart. The flow chart may display, by default, a start node and an end node associated with source code to start and end the test scenario, respectively. Two or more graphical event modules may be combined into a single nested graphical event module in response to receiving a signal from the user interface.
In the same manner as the add event graphic signal, the add logic signal also accesses an array of flow logic operators on a memory. The flow logic operators in the array are associated with source code that executes to simulate flow logic as part of the test scenario. According to the method 100, a user can select 202 a flow logic operator from the flow controls from a graphical drop-down menu and the flow control module is displayed as a graphical flow control module in the flow chart. At least one graphical flow logic operator (associated with a flow logic operator from the array of flow logic operators) connects graphical event modules in the flow chart in order to build a test scenario.
The source code associated with each graphical event module and each graphical flow logic operator of the test scenario is then merged 203 to generate a test code, wherein the merging of the graphical event module source code with the flow logic operator source code maintains the sequence of the graphical event module source code and the flow logic operator source code based on the flow chart. This merging 203 is dictated by the flow logic. Furthermore, the user can rearrange the graphical event modules by dragging and dropping modules within the flow chart. The method 100 can then re-merged 204 the source code to maintain the new sequence of the graphical event module source code and the flow logic operator source code. The re-merging 204 of the source code based on the rearranging of the componentry (i.e., the graphical event modules and flow logic operators), may also be dictated by the flow logic operator.
In one embodiment, the code viewing window displays the source code associated with selected objects in the flow chart in response to receiving a view code signal from the user interface directed to at least one selected object in the flow chart. In another embodiment, a parameter viewing window on the user interface, the parameter viewing window displays test scenario parameters associated with selected objects in the flow chart in response to receiving a view parameter signal directed from the user interface directed to at least one selected object in the flow chart, wherein the test scenario parameters includes at least one of a sequence name, a sequence description, a sequence variable, and a sequence condition.
In some examples, the generated source code associated with the graphical sequence test builder is written to a file, saved, and then outputted 205. The outputted test scenario file can be compilable, thereby alleviating a need for the end user to “generate” action. So configured, the graphical sequence builder outputs 205 a test scenario to be run on an integrated circuit without involving manual coding or de-bugging.
This disclosure describes preferred embodiments and examples of the present technology. It should be recognized that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the scope of the invention as set forth in the claims, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept. It should also be understood that features of one embodiment may be combined with features of other embodiments to provide yet other embodiments as desired. Further, all reference discussed in this document are hereby incorporated by reference in their entirety.
This application claims priority to U.S. provisional application No. 62/292,605, filed on Feb. 8, 2016, titled “Graphical Sequence Builder,” which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
62292605 | Feb 2016 | US |