US20070260443A1 - Method, system and program product supporting specification of signals for simulation result viewing - Google Patents
Method, system and program product supporting specification of signals for simulation result viewing Download PDFInfo
- Publication number
- US20070260443A1 US20070260443A1 US11/381,437 US38143706A US2007260443A1 US 20070260443 A1 US20070260443 A1 US 20070260443A1 US 38143706 A US38143706 A US 38143706A US 2007260443 A1 US2007260443 A1 US 2007260443A1
- Authority
- US
- United States
- Prior art keywords
- signal
- signal group
- entity
- name
- design entity
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004088 simulation Methods 0.000 title claims abstract description 89
- 238000000034 method Methods 0.000 title claims abstract description 77
- 238000012545 processing Methods 0.000 claims abstract description 45
- 230000004044 response Effects 0.000 claims abstract description 23
- 238000013461 design Methods 0.000 claims description 123
- 238000004321 preservation Methods 0.000 claims description 9
- 238000013500 data storage Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 description 50
- 238000010586 diagram Methods 0.000 description 9
- 239000013598 vector Substances 0.000 description 3
- 102000015779 HDL Lipoproteins Human genes 0.000 description 2
- 108010010234 HDL Lipoproteins Proteins 0.000 description 2
- 210000001072 colon Anatomy 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000012938 design process Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000012552 review Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000005094 computer simulation Methods 0.000 description 1
- 238000011960 computer-aided design Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
Definitions
- the present invention relates in general to simulating digital devices, modules and systems, and in particular, to computer simulation of digital devices, modules and systems.
- Verifying the logical correctness of a digital design and debugging the design, if necessary, are very important steps in most digital design processes.
- Logic networks are tested either by actually building networks or by simulating networks on a computer. As logic networks become highly complex, it becomes necessary to simulate a design before the design is actually built. This is especially true when the design is implemented as an integrated circuit, since the fabrication of integrated circuits requires considerable time and correction of mistakes is quite costly.
- the goal of digital design simulation is the verification of the logical correctness of the design.
- ECAD electronic computer-aided design
- VHDL hardware description language
- a simulator is then utilized to verify the logical correctness of the design prior to developing a circuit layout.
- a simulator is typically a software tool that operates on a digital representation, or simulation model of a circuit, and a list of input stimuli (i.e., testcase) representing inputs of the digital system.
- a simulator generates a numerical representation of the response of the circuit, which may then either be viewed on the display screen as a list of values or further interpreted, often by a separate software program, and presented on the display screen in graphical form.
- the simulator may be run either on a general-purpose computer or on another piece of electronic apparatus, typically attached to a general purpose computer, specially designed for simulation. Simulators that run entirely in software on a general-purpose computer will hereinafter be referred to as “software simulators”. Simulators that are run with the assistance of specially designed electronic apparatus will hereinafter be referred to as “hardware simulators”.
- simulation executable model a translation from an HDL description to a simulation format, hereinafter referred to as a simulation executable model, is required.
- AET all events trace
- conventional AET viewers permit a user to input an Input/Output (I/O) list specifying signals in the simulation executable model that the user desires to view.
- I/O Input/Output
- a conventional AET viewer presents to the user only those signals within the simulation executable model that are identified within the I/O list.
- the present invention recognizes that user entry of the I/O list (e.g., utilizing a keyboard) is tedious and time consuming, particularly for complex simulation executable models. Accordingly, the present invention provides to a method, system and program product for simulation processing.
- a data set including at least one entry specifying a signal group by a predetermined signal group name is received by a data processing system.
- the entry in the data set is processed to identify the signal group name.
- Signal group information associated with an event trace file containing simulation results is accessed to determine signal names of multiple signals that are members of the signal group. Simulation results from the event trace file that are associated with instances of said multiple signals are then included within a presentation of simulation results.
- FIG. 1 is a pictorial representation of a data processing system in accordance with the present invention
- FIG. 2 depicts a representative hardware environment of the data processing system illustrated in FIG. 1 ;
- FIG. 3A is a simplified block diagram illustrating a digital design entity in accordance with the teachings of the present invention.
- FIG. 3B is a diagrammatic representation depicting a simulation model in accordance with the teachings of the present invention.
- FIG. 3C is a flow diagram illustrating of a model build process in accordance with the teachings of the present invention.
- FIG. 3D is a block diagram depicting simulation model data structures representing a design in accordance with the teachings of the present invention.
- FIG. 4 is a flow diagram depicting simulation of a simulation executable model and presenting the results of simulation to a user
- FIG. 5A depicts a first conventional I/O list in accordance with the prior art
- FIG. 5B depicts a second conventional I/O list in accordance with the prior art
- FIGS. 5C-5D illustrate exemplary I/O lists in accordance with the present invention
- FIG. 6A depicts an exemplary design entity HDL file including signal group descriptors in accordance with the present invention
- FIG. 6B illustrates an exemplary design entity HDL file including nested signal group descriptors in accordance with the present invention.
- FIGS. 7A-7C together form a high-level logical flowchart of an exemplary process by which an AET viewer processes an I/O list to generate a presentation of an AET file in accordance with the present invention.
- data processing system 10 comprises a workstation 12 to which one or more nodes 13 are connected.
- Workstation 12 preferably comprises a high performance multiprocessor computer, such as one of the POWER line of computer systems available from International Business Machines (IBM) Corporation of Armonk, N.Y.
- Workstation 12 preferably includes nonvolatile and volatile internal storage for storing software applications comprising an ECAD system, which can be utilized to develop and verify a digital circuit design in accordance with the method and system of the present invention.
- nodes 13 include a display device 14 , a keyboard 16 , and a mouse 20 .
- the ECAD software applications executed within workstation 12 preferably display a graphic user interface (GUI) within display screen 22 of display device 14 with which a digital circuit designer can interact using a keyboard 16 and mouse 20 .
- GUI graphic user interface
- FIG. 2 is a more detailed block diagram of data processing system 10 .
- data processing system 10 includes one or more Central Processing Units (CPUs) 24 , such as a conventional microprocessor, and a number of other components interconnected via system interconnect 26 .
- CPUs such as CPU 24 typically include a control unit that organizes data and program storage in a computer memory and transfers the data and other information between the various parts of the computer system.
- CPUs also generally include one or more arithmetic logic units that execute arithmetical and logical operations, such as addition, comparison, multiplication and so forth.
- Data processing system 10 further includes a random-access memory (RAM) 28 , a read-only memory (ROM) 30 , a display adapter 32 supporting connection of a display device 14 , and an I/O adapter 34 for connecting peripheral devices (e.g., disk and tape drives 33 ).
- Data processing system 10 further includes a communications adapter 42 for connecting data processing system 10 to a communications network and a user interface adapter 36 for connecting keyboard 16 , mouse 20 , speaker 38 , microphone 40 , and/or other user interface devices to system interconnect 26 .
- data processing system 10 operates under the control of an operating system (e.g., AIX) and one or more other programs, which may reside in any suitable computer-readable media such as RAM 28 , ROM 30 , a magnetic disk, magnetic tape, or optical disk (the last three being located in disk and tape drives 33 ).
- AIX e.g., AIX
- FIG. 3A is a block diagram representation of an exemplary design entity 300 in which the method and system of the present invention may be implemented.
- Design entity 300 is defined by a number of components: an entity name, entity ports, and a representation of the function performed by design entity 300 .
- Each entity within a given model has a unique name (not explicitly shown in FIG. 3A ) that is declared in the HDL description of each entity.
- each entity typically contains a number of signal interconnections, known as ports, to signals outside the entity. These outside signals may be primary input/outputs (I/Os) of an overall design or signals connecting to other entities within an overall design.
- I/Os primary input/outputs
- ports are categorized as belonging to one of three distinct types: input ports, output ports, and bi-directional ports.
- Design entity 300 is depicted in as having a number of input ports 303 that convey signals into design entity 300 .
- Input ports 303 are connected to input signals 301 .
- design entity 300 includes a number of output ports 306 that convey signals out of design entity 300 .
- Output ports 306 are connected to a set of output signals 304 .
- Bi-directional ports 305 are utilized to convey signals into and out of design entity 300 .
- Bi-directional ports 305 are in turn connected to a set of bi-directional signals 309 .
- An entity, such as design entity 300 need not contain ports of all three types, and in the degenerate case, contains no ports at all.
- a mapping technique To accomplish the connection of entity ports to external signals, a mapping technique, known as a “port map”, is utilized.
- a port map (not explicitly depicted in FIG. 3A ) consists of a specified correspondence between entity port names and external signals to which the entity is connected.
- ECAD software is utilized to connect external signals to appropriate ports of the entity according to a port map specification.
- design entity 300 contains a body section 308 that describes one or more functions performed by design entity 300 .
- body section 308 contains an interconnection of logic gates, storage elements, etc., in addition to instantiations of other entities.
- instantiating an entity within another entity a hierarchical description of an overall design is achieved.
- a microprocessor may contain multiple instances of an identical functional unit. As such, the microprocessor itself will often be modeled as a single entity. Within the microprocessor entity, multiple instantiations of any duplicated functional entities will be present.
- Simulation model 329 includes multiple hierarchical design entities. For visual simplicity and clarity, many of the ports and signals interconnecting the entities within simulation model 329 have not been explicitly shown. In any model, one and only one entity is the so-called “top-level entity”.
- a top-level entity 320 is that entity which encompasses all other entities within simulation model 329 . That is to say, top-level entity 320 instantiates, either directly or indirectly, all descendant entities within a design.
- Simulation model 329 consists of top-level entity 320 which directly instantiates two instances, 321 a and 321 b , of an FXU entity 321 . Each instantiation has an associated description, which contains an entity name and a unique instantiation name.
- description 310 is labeled “TOP:TOP”.
- Description 310 includes an entity name 312 , labeled as the “TOP” preceding the colon, and also includes an instantiation name 314 , labeled as the “TOP” following the colon.
- Top-level entity 320 is at the highest level within the hierarchy of simulation model 329 .
- An entity that instantiates a descendant entity will be referred to hereinafter as an “ancestor” of the descendant entity.
- Top-level entity 320 is therefore the ancestor that directly instantiates FXU entity instantiations 321 a and 321 b .
- the instantiation names of all instantiations must be unique.
- instantiation 321 a of FXU entity 321 single instance entities 325 a and 326 a of entity A 325 and entity B 326 respectively, are directly instantiated.
- instantiation 321 b of the same FXU entity contains instantiations 325 b and 326 b of entity A 325 and entity B 326 respectively.
- instantiation 326 a and instantiation 326 b each directly instantiate a single instance of entity C 327 as entities 327 a and 327 b , respectively.
- Each entity is constructed from one or more HDL files that contain the information necessary to describe the entity.
- the instantiation identifier for a given instantiation is a string consisting of the enclosing entity instantiation names proceeding from the top-level entity instantiation name. For example, the instantiation identifier of instantiation 327 a of entity C 327 within instantiation 321 a of FXU entity 321 is “TOP.FXU0.B.C”. This identifier serves to uniquely identify each instantiation within a simulation model.
- a variety of signals are instantiated (e.g., signals E, F 0 , F 1 , G, H 0 , H 1 , L, M, N, P and Q).
- Each signal has an associated signal name (e.g., “M”) and a signal instantiation identifier, which in a preferred embodiment, is a string consisting of the enclosing entity instantiation names proceeding from the top-level entity instantiation name and terminating with the signal name.
- the instantiation identifier of signal M within instantiation 321 a of FXU entity 321 is “TOP.FXU0.A.M”. This instantiation identifier serves to uniquely identify each signal instantiation within a simulation model.
- signals for example, signal P( 0 . . . 4 ), can be multi-bit signal vectors. It should also be noted that some signals (e.g., signals TOP.FXU0.E, TOP.FXU1.E, TOP.FXU0.G and TOP.FXU1.G) are renamed (as signals TOP.FXU0.F0, TOP.FXU1.F1, TOP.FXU0.H0 and TOP.FXU1.H1, respectively) as they cross design entity boundaries.
- signals TOP.FXU0.E, TOP.FXU1.E, TOP.FXU0.G and TOP.FXU1.G are renamed (as signals TOP.FXU0.F0, TOP.FXU1.F1, TOP.FXU0.H0 and TOP.FXU1.H1, respectively) as they cross design entity boundaries.
- FIG. 3C there is depicted a flow diagram of a model build process which may be implemented in a preferred embodiment of the present invention.
- the process begins with one or more design entity HDL source code files 340 and, potentially, one or more design entity intermediate format files 345 , hereinafter referred to as “proto files” 345 , available from a previous run of an HDL compiler 342 .
- HDL compiler 342 processes HDL file(s) 340 beginning with the top level entity of a simulation model and proceeding in a recursive fashion through all HDL or proto file(s) describing a complete simulation model.
- HDL compiler 342 For each of HDL files 340 during the compilation process, HDL compiler 342 examines proto files 345 to determine if a previously compiled proto file is available and consistent. If such a file is available and consistent, HDL compiler 342 will not recompile that particular file, but will rather refer to an extant proto file. If no such proto file is available or the proto file is not consistent, HDL compiler 342 explicitly recompiles the HDL file 340 in question and creates a proto file 344 for use in subsequent compilations. Such a process will be referred to hereinafter as “incremental compilation” and can greatly speed the process of creating a simulation executable model 348 . Once created by HDL compiler 342 , proto files 344 are available to serve as proto files 345 in subsequent compilations.
- HDL compiler 342 In addition to proto files 344 , HDL compiler 342 also creates two sets of data structures, design entity proto data structures 341 and design entity instance data structures 343 , in memory 44 of computer system 10 .
- Design entity proto data structures 341 and design entity instance data structures 343 serve as a memory image of the contents of a simulation executable model 348 .
- Data structures 341 and 343 are passed, via memory 44 , to a model build tool 346 that processes data structures 341 and 343 into simulation executable model 348 .
- each entity is described by a single HDL file. Depending on convention or the particular HDL in which the current invention is practiced, this restriction may be required. However, in certain circumstances or for certain HDLs it is possible to describe an entity by utilizing more than one HDL file. Those skilled in the art will appreciate and understand the extensions necessary to practice the present invention if entities are permitted to be described by multiple HDL files. Furthermore, it will be assumed that there is a direct correspondence, for each entity, between the entity name and both of the following: the name of the HDL file representing the entity, and the name of the proto file for the entity.
- an HDL source code file corresponding to a given entity will be referred to by an entity name followed by “.vhdl”.
- the HDL source code file that describes top-level entity 320 will be referred to as TOP.vhdl.
- This labeling convention serves as a notational convenience only and should not be construed as limiting the applicability of the present invention to HDLs other than VHDL.
- each entity may instantiate, either directly or indirectly, one or more other entities.
- the FXU entity directly instantiates A entity 325 and B entity 326 .
- B entity 326 directly instantiates C entity 327 .
- FXU entity 321 instantiates, directly or indirectly, A entity 325 , B entity 326 and C entity 327 .
- Those entities, that are directly or indirectly instantiated by another entity will be referred to hereinafter as “descendants”.
- the descendants of top level entity 320 are FXU entity 321 , A entity 325 , B entity 326 , and C entity 327 .
- each entity has a unique set of descendants and that each time an entity is instantiated, a unique instance of the entity and its descendants is created.
- FXU entity 321 is instantiated twice, FXU:FXU 0 321 a and FXU:FXU 1 321 b , by top-level entity 320 .
- Each instantiation of FXU entity 321 creates a unique set of instances of the FXU, A, B, and C entities.
- a BOM is a list of HDL files having date and time stamps of the entity itself and the entity's descendants.
- the BOM for an entity is stored in proto file 344 after compilation of the entity. Therefore, when HDL compiler 342 compiles a particular HDL source code file among HDL files 340 , a proto file 344 is generated that includes a BOM listing the HDL files 340 that constitute the entity and the entity's descendants, if any.
- the BOM also contains the date and time stamp for each of the HDL files referenced as each appeared on disk/tape 33 of computer system 10 when the HDL file was being compiled.
- HDL compiler 342 will recompile HDL file 340 on a subsequent re-compilation as will be described in further detail below.
- the HDL files referenced by the BOM of FXU entity 321 are FXU.vhdl, A.vhdl, B.vhdl and C.vhdl, each with appropriate date and time stamps.
- the files referenced by the BOM of top-level entity 320 are TOP.vhdl, FXU.vhdl, A.vhdl, B.vhdl, C.vhdl, and FPU.vhdl with appropriate date and time stamps.
- HDL compiler 342 creates an image of the structure of a simulation model in main memory 44 of computer system 10 .
- This memory image is comprised of the following components: “proto” data structures 341 and “instance” data structures 343 .
- a proto is a data structure that, for each entity in the model, contains information about the ports of the entity, the body contents of the entity, and a list of references to other entities directly instantiated by the entity (in what follows, the term “proto” will be utilized to refer to the in-memory data structure described above and the term “proto file” will be utilized to describe intermediate format file(s) 344 ).
- Proto files 344 are therefore on-disk representations of the in-memory proto data structure produced by HDL compiler 342 .
- An instance data structure is a data structure that, for each instance of an entity within a model, contains the instance name for the instance, the name of the entity the instance refers to, and the port map information necessary to interconnect the entity with external signals.
- each entity will have only one proto data structure, while, in the case of multiple instantiations of an entity, each entity may have one or more instance data structures.
- HDL compiler 342 follows a recursive method of compilation in which successive entities of the model are considered and loaded from proto files 345 if such files are available and are consistent with the HDL source files constituting those entities and their descendants. For each entity that cannot be loaded from existing proto files 345 , HDL compiler 342 recursively examines the descendants of the entity, loads those descendant entities available from proto file(s) 345 and creates, as needed, proto files 344 for those descendants that are inconsistent with proto files 345 . Pseudocode for the main control loop of HDL compiler 342 is shown below (the line numbers to the right of the pseudocode are not a part of the pseudocode, but merely serve as a notational convenience).
- routine process_HDL_file( ) (line 5)
- routine proto_loaded( ) (line 15)
- the proto data structure for the top level entity will never be present in memory because the process starts without any proto data structures loaded into memory 44 . If a matching proto data structure is present in memory 44 , instance data structures for the current entity and the current entity's descendants, if any, are created as necessary in memory 44 by routine create_instance( ) (line 75).
- routine exists_proto_file( ) examines proto files 345 to determine if a proto file exists for the entity. If and only if a matching proto file exists, routine check_bom( ) is called to determine whether proto file 345 is consistent. In order to determine whether the proto file is consistent, the BOM for the proto file is examined. Routine check_bom( ) examines each HDL source code file listed in the BOM to determine if the date or time stamps for the HDL source code file have changed or if the HDL source code file has been deleted. If either condition occurs for any file in the BOM, the proto file is inconsistent and routine check_bom( ) fails.
- routine load_proto( ) loads the proto file and any descendant proto files into memory 44 , thus creating proto data structures 341 for the current entity and the current entity's descendants, if any.
- process_HDL_file( ) ensures that once a proto file has been verified as consistent, all of its descendant proto files, if any, are also consistent.
- routine parse_HDL_file( ) loads the HDL source code file for the current entity.
- Routine parse_HDL_file( ) (line 35) examines the HDL source code file for syntactic correctness and determines which descendant entities, if any, are instantiated by the current entity.
- Lines 40, 45, and 50 constitute a loop in which the routine process_HDL_file( ) is recursively called to process the descendent entities that are called by the current entity. This process repeats recursively traversing all the descendants of the current entity in a depth-first fashion creating proto data structures 341 and proto data files 344 of all descendants of the current entity.
- Control then passes to line 60 where a new proto file 344 , including an associated BOM, is written to disk 33 by routine write_proto_file( ).
- routine create_instance( ) creates instance data structures 343 for the current entity and any descendant entities as necessary.
- process_HDL_file( ) (line 5) recursively processes the entire simulation model creating an in-memory image of the model consisting of proto data structures 341 and instance data structures 343 .
- the present invention further permits the designer to include within design entity HDL files 340 one or more signal group directives 350 identifying particular signals that are likely to be of interest when viewing the results of simulating simulation executable model 348 .
- Exemplary semantics for signal group directives 350 is described below with reference to FIGS. 6A-6B .
- HDL compiler 342 in addition to the processing described above, preferably processes signal group directives 350 to generate signal group information (SGI) 400 , which represents the signal instantiation identifiers of the signals of interest utilizing any convenient data structure (e.g., linked list, table, etc.).
- Model build tool 346 then places the signal group information (SGI) 400 , optionally with some additional transformation in format, within simulation executable model 348 .
- FIG. 3D there is depicted a block diagram representing compiled data structures, which may be implemented in a preferred embodiment of the present invention.
- Memory 44 contains proto data structures 361 , one for each of the entities referred to in simulation model 329 .
- instantiations in simulation model 329 are represented by instance data structures 362 .
- Instance data structures 362 are connected by means of pointers indicating the hierarchical nature of the instantiations of the entities within simulation model 329 .
- memory 44 contains SGI 400 .
- Model build tool 346 in FIG. 3C processes the contents of memory 44 into memory data structures in order to produce simulation executable model 348 .
- FIG. 4 there is depicted a flow diagram of a process for simulating a design and viewing simulation results in accordance with the present invention.
- a software and/or hardware simulator 404 is utilized to stimulate simulation executable model 348 with a testcase 402 to simulate operation of a digital design.
- an all events trace (AET) file 406 records data representing the response of simulation executable model 348 to testcase 402 .
- the data within AET file 406 includes values of various signals and/or storage elements within simulation executable model 348 over time as well as SGI 400 .
- AET viewer 410 In order to review the contents of AET file 406 , a user generally employs a separate or integrated viewer program, referred to herein as AET viewer 410 .
- the user may request AET viewer 410 to present data from AET file 406 either in a graphical format within display screen 22 or in hardcopy format.
- the user can advantageously restrict the presentation of data by AET viewer 410 to particular signals of interest by specifying in a data set (referred to herein as an I/O list 408 ) the signals of interest.
- a conventional I/O list 500 in accordance with the prior art is a list containing a large number of entries each setting forth a signal instantiation identifier of one of the signals of interest, which in this case comprise all of the signals within FXU instantiation 321 a of FIG. 3B .
- the user must enter each of a potentially large number of signal instantiation identifiers utilizing keyboard 16 . This conventional technique of manually keying in signal instantiation identifiers is tedious and error prone.
- simulators 404 do not preserve the signal names of signals in descendant design entities that cross design entity boundaries into higher level design entities. Instead, to eliminate signal duplication in the AET file, such simulators 404 only identify a signal in the AET file by its signal name in the highest level design entity in which it appears. Consequently, if a simulator 404 that does not preserve signal names is employed, the user must specify a signal within the I/O list 500 utilizing a signal instantiation identifier that employs the signal name of the signal from the highest level design entity in which the signal appears. For example, as can be seen by comparing entry 502 of FIG. 5A with corresponding entry 504 of I/O list 500 ′ of FIG.
- the user of a simulator 404 that does not preserve signal names must utilize the signal instantiation identifier F 0 as depicted at reference numeral 504 rather than the signal instantiation identifier FXU.E as illustrated at reference numeral 502 .
- a user of AET viewer 410 whose work predominantly pertains to a descendant design entity may have difficulty in determining or easily recalling signal names utilized in a higher level design entity that instantiates the lower level design entity with which the user is familiar.
- I/O list 408 is list containing one or more entries.
- an entry of I/O list 408 such as entry 510 , may identify a group of one or more signals of interest by a signal group instantiation identifier corresponding to information within SGI 400 .
- the signal group instantiation identifier is formed similarly to a signal instantiation identifier and consists of a string of the enclosing entity instantiation names proceeding from the top-level entity instantiation name and terminating with the signal group name enclosed by a pair of angular brackets (“ ⁇ ” and “>”) indicating that the bracketed contents are a member of a separate signal group namespace.
- the six signals of interest within FXU entity instantiation 321 a can simply be identified by the single entry “FXU0. ⁇ FXU_Group>”, rather than by individually entering the signal instantiation identifiers within I/O list 408 .
- the individual signals comprising the signal group FXU_Group are specified utilizing signal group directives 350 within design entity HDL files 340 .
- design entity HDL file 340 a includes conventional HDL source code describing a design entity, which in this case is design entity FXU 321 .
- the conventional HDL source code includes a port map 600 and signal assignment statements 602 .
- design entity HDL file 340 a includes unconventional HDL comments containing signal group directives 350 ( FIG. 3C ) in accordance with the present invention.
- the signal group directives 350 include two different types of signal group directives: a signal group declaration 610 and a signal preservation directive 620 .
- Signal group declaration 610 begins with an HDL comment of the form “--!! Signal Group signal_group_name;” and ends with an HDL comment of the form “--!! END Signal Group signal_group_name;”, where signal_group_name is a signal group name (in this example, FXU_Group) that is unique for the given target design entity.
- FXU_Group signal group name
- signal names are specified relative to the target design entity (e.g., FXU design entity 321 ).
- the target design entity e.g., FXU design entity 321
- At least some embodiments of the present invention permit signal names higher in the design entity hierarchy to be specified relative to the target design entity utilizing the conventional syntax “.. ⁇ ” to indicate a next higher level of hierarchy.
- the user is preferably permitted to further specify additional attributes related to the presentation of signals within signal group declaration 610 .
- additional attributes related to the presentation of signals within signal group declaration 610 .
- the user can specify a desired color for a signal, a default to a waveform or binary signal representation, a desired justification of unaligned bit vectors, etc.
- the user has specified a left justification of the 5-bit signal vector B.C.P( 0 . . . 4 ).
- a signal group declaration such as signal group declaration 630
- a signal group declaration also preferably permits the user to specify nested signal groups to any legal depth.
- the user simply includes a statement in a signal group declaration referring to the instantiation identifier of the nested signal group with the signal group enclosed in angular brackets (i.e., “ ⁇ ” and “>”).
- angular brackets permits HDL compiler 342 to discriminate between the namespaces of signals and signal group names.
- a signal preservation directive 620 is utilized to instruct a simulator 404 that by default does not preserve the lower-level signal name of a renamed signal to do so for a particular renamed signal (e.g., signal G).
- a particular renamed signal e.g., signal G.
- AET file 406 will contain data for signal instantiation identifiers TOP.FXU0.G and TOP.FXU1.G.
- the capability to preserve a familiar signal name eliminates the need for the user to enter into an I/O list the possibly unfamiliar signal instantiation identifiers TOP.FXU1.H0 and TOP.FXU1.H1 to view the signal data of preserved signal G.
- FIGS. 7A-7C there is depicted a high level logical flowchart of an exemplary process by which AET viewer 410 processes an I/O list 408 in accordance with the present invention.
- AET viewer 410 processes an I/O list 408 in accordance with the present invention.
- operations are depicted logically rather than sequentially, and many of the illustrated operations can be performed in parallel or in an alternative order.
- the process begins at block 700 of FIG. 7A and then proceeds to block 702 , which illustrates a determination of whether or not a user has entered a reference scope for the I/O list 408 , that is, a scope of simulation executable model 348 by reference to which all other I/O list entries will be parsed.
- the reference scope is the top level design entity instance in the simulation executable model 348 , for example, top-level design entity instance 320 of FIG. 3B .
- the user is permitted to enter a command further limiting the reference scope of the form “Scope limit:instance_string0.[design_entity].instance_string1”,where instance_string0 and instance_string1 are optional design entity instance strings (that for instrance_string0 begins with the top-level design entity instance) and design_entity enclosed in square brackets is an optional design entity name.
- a legal reference scope command includes at least one of the three optional fields instance_string0, [design_entity], and instance_string1.
- the reference scope command can be communicated to AET viewer 410 , for example, via a command line or within I/O list 408 . If inserted within an I/O list 408 , the reference scope command preferably applies to all entries in that I/O list 408 .
- AET viewer 410 sets the reference scope by default to the top level design entity instance of the simulation executable model 348 , as illustrated at block 704 . Thereafter, the process passes through page connector A to FIG. 7B . If AET viewer 410 determines at block 702 that the user has entered a different reference scope, AET viewer 410 further parses the reference scope command to determine at block 710 whether or not the reference scope command contains bracketed syntax (e.g., [design_entity]). If not, the process proceeds to block 713 , which illustrates AET viewer 410 determining whether of not the design entity instance specified by the reference scope command exists in the simulation executable model 348 .
- bracketed syntax e.g., [design_entity]
- processing terminates with an error at block 715 . If so, the process passes from block 713 to block 720 , which depicts AET viewer 410 setting the reference scope to the particular design entity instance specified within the instance_string0 field of the reference scope command. For example, assuming simulation executable model 329 of FIG. 3B , the reference scope command “Scope limit:TOP.FXU0” sets the reference scope to instance 321 a of FXU design entity 321 . With this reference scope, entry 510 of I/O list 408 of FIG. 5C can be simplified as ⁇ FXU_Group>. Thereafter, the process passes through page connector A to FIG. 7B .
- AET viewer 410 next determines at block 712 whether or not the named design entity exists within simulation executable model 348 . If not, processing ends with an error at block 714 . If, however, the specified design entity is present in simulation executable model 348 , AET viewer 410 recursively searches simulation executable model 348 to identify all the instances of the design entity that are present within the portion of simulation executable model 348 defined by instance_string0, if present. As indicated at block 718 , if no instances of the specified design entity exist within the specified scope, processing terminates with an error at block 714 .
- AET viewer 410 determines at block 718 that at least one instance of the specified design entity was located within the specified scope, AET viewer 410 further determines at block 722 if only a single instance of the design entity was found within the specified scope. If so, the process passes to block 720 , which illustrates AET viewer 410 setting that single instance of the design entity as the reference scope. Thereafter, the process passes through page connector A to FIG. 7B .
- AET viewer 410 determines at block 722 that more than one instance of the specified design entity was found within the specified scope, AET viewer 410 presents a list of the design entity instances to the user for selection, for example, via a graphical menu displayed within display screen 22 (block 724 ). AET viewer 410 then receives user input designating a single one of the multiple design entity instances as defining the desired reference scope, as illustrated at block 726 . For example, assuming simulation executable model 329 of FIGS. 3B and I/O list 408 ′ of FIG. 5D , the reference scope command “Scope limit:[FXU]” given at reference numeral 512 of FIG.
- the signal group can be specified as ⁇ FXU_Group>, as shown in entry 512 of I/O list 408 ′ of FIG. 5D . Thereafter, the process passes to block 720 , which has been described.
- the process begins at page connector A and then proceeds to block 730 , which represents a processing loop in which AET viewer 410 processes each entry within one or more I/O lists to 408 to construct a presentation of AET file 406 . If AET viewer 410 determines at block 730 that all entries within the I/O list(s) have been processed the process passes to block 732 , which is described below. If, however, at least one entry within an I/O list 408 remains to be processed, the process proceeds to block 740 , which depicts AET viewer 410 moving to the first or next signal-identifying entry within the I/O list 408 and initializing a working scope for the entry to the reference scope. Signal-identifying entries within I/O lists 408 are processed with respect to (i.e., as impliedly limited by) the reference scope and take the general form:
- Block 740 depicts AET viewer 410 determining whether the current signal-identifying entry has a leading design entity instance qualifier (e.g., instance_string2). If not, the process passes to block 752 , which is described below. If so, the process proceeds from block 742 to block 744 , which illustrates AET viewer 410 determining whether or not the specified design entity instance exists within the reference scope of simulation executable model 348 . If not, processing terminates with an error at block 746 . If so, the process proceeds to block 750 .
- Block 750 illustrates AET viewer 410 setting the current scope to the scope formed by appending the scope defined by the design entity instance qualifier to the reference scope.
- AET viewer 410 determines at block 752 whether or not the next field within the signal-identifying entry of I/O list 408 is a design_entity qualifier enclosed in square brackets. If not, the process passes through page connector B to FIG. 7C . If so, processing of the signal-identifying entry continues at block 754 .
- Block 754 shows AET viewer 410 recursively searching simulation executable mode 1348 to locate all design entity instances within the current scope having an entity name matching the specified design entity name.
- AET viewer 410 determines at block 756 whether or not any such design entity instances exist. If not, processing ends with an error condition at block 746 . If so, AET viewer 410 further determines at block 760 whether or not the bracketed syntax includes an asterisk signifying the inclusion of all design entity instances within the specified scope. If so, AET viewer 410 narrows the working scope(s) of the entry to the one or more design entity instance(s) located at block 754 (block 761 ). Thereafter, the process passes through page connector B to FIG. 7C .
- block 762 which illustrates AET viewer 410 determining whether a single design entity instance was discovered at block 754 . If so, the working scope is set at block 764 to the single design entity instance. Thereafter, the process passes through page connector B to FIG. 7C . If, on the other hand, AET viewer 410 determines at block 762 that more than one design entity instances was discovered at block 754 , AET viewer 410 presents a list of the design entity instances to the user for selection, for example, via a graphical menu displayed within display screen 22 (block 770 ).
- AET viewer 410 then receives user input designating one or more of the multiple design entity instances as defining the desired working scope, as illustrated at block 772 . Thereafter, the process passes to block 764 , which depicts AET viewer 410 establishing one or more working scopes in accordance with the user's selection. Thereafter, the process passes through page connector B to FIG. 7C .
- the process begins at page connector B and then proceeds to block 774 , which depicts AET viewer 410 further parsing the signal-identifying entry to determine whether the entry contains a further instance qualifier (e.g., instance_string3) to limit the working scope(s). If not, the process passes to block 780 , which is described below. If so, AET viewer 410 determines at block 776 whether or not the specified design entity instance(s) exist. If not, the process ends with an error at block 786 . If the specified design entity instance(s) exist, AET viewer 410 narrows the working scope(s) of the current signal-identifying entry to the design entity instance(s) indicated by the second instance qualifier (block 778 ). Thereafter, the process passes to block 780 .
- a further instance qualifier e.g., instance_string3
- Block 780 depicts AET viewer 410 further parsing the signal-identifying entry of I/O list 408 to determine if the terminal signals field of the entry contains a single signal name or a signal group name. If the signals field contains a signal name, AET viewer 410 next determines at block 781 if the specified signal exists within the working scope(s). If not, processing terminates at block 786 with an error condition. If AET viewer 410 determines at block 781 if the specified signal exists within the working scope(s). If not, processing terminates at block 786 with an error condition. If so, AET viewer 410 adds the specified signal(s) to the presentation of AET file 406 (block 782 ). Thereafter, the process returns to block 730 of FIG. 7B via page connector C.
- the process passes to block 783 , which depicts AET viewer 410 determining whether the signals field contains empty angle brackets. If so, AET viewer 410 recursively locates all signal group instances within the design entity instances within the working scope(s), as shown at block 784 . If AET viewer determines that none exists at block 785 , processing ends with an error at block 786 . If, on the other hand, AET viewer 410 determines at block 785 that one or more signal groups are present, AET viewer 410 determines the individual signals comprising the signal groups from SGI 400 and adds all such signals to the presentation at block 790 . Thereafter, the process returns through page connector C to FIG. 7B .
- Block 787 illustrates AET viewer 410 recursively locating instances of the specified signal group instances within the design entity instances within the working scope(s).
- block 788 if no signal group instances are located, processing ends with an error condition at block 786 .
- processing proceeds to block 790 and following blocks which have been described.
- the present invention provides a method, system and program product for processing simulation results for presentation.
- the amount of user input required to filter the presentation of simulation results is substantially reduced through the use of predetermined signal groups and, optionally, the use of scope commands.
- the ease of understanding simulation results is enhanced through support of signal preservation directives that enable a designer to designate signals for which signal names are to be preserved in the presence of signal renaming.
- one of the embodiments of the invention can be implemented with program code resident in random access memory 28 or non-volatile storage of one or more computer systems configured generally as described in FIG. 1 and FIG. 2 .
- the set of program code may be stored in another computer readable storage device, such as disk drive 33 or CD-ROM, or in data storage of another computer and transmitted over a local area network or a wide area network, such as the Internet, when desired by the user.
- the program code embodied in a computer usable medium may be referred to as a computer program product.
Abstract
Description
- 1. Technical Field
- The present invention relates in general to simulating digital devices, modules and systems, and in particular, to computer simulation of digital devices, modules and systems.
- 2. Description of the Related Art
- Verifying the logical correctness of a digital design and debugging the design, if necessary, are very important steps in most digital design processes. Logic networks are tested either by actually building networks or by simulating networks on a computer. As logic networks become highly complex, it becomes necessary to simulate a design before the design is actually built. This is especially true when the design is implemented as an integrated circuit, since the fabrication of integrated circuits requires considerable time and correction of mistakes is quite costly. The goal of digital design simulation is the verification of the logical correctness of the design.
- In a typical automated design process that is supported by a conventional electronic computer-aided design (ECAD) system, a designer enters a high-level description utilizing a hardware description language (HDL), such as VHDL, producing a representation of the various circuit blocks and their interconnections. The ECAD system compiles the design description into a format that is best suited for simulation. A simulator is then utilized to verify the logical correctness of the design prior to developing a circuit layout.
- A simulator is typically a software tool that operates on a digital representation, or simulation model of a circuit, and a list of input stimuli (i.e., testcase) representing inputs of the digital system. A simulator generates a numerical representation of the response of the circuit, which may then either be viewed on the display screen as a list of values or further interpreted, often by a separate software program, and presented on the display screen in graphical form. The simulator may be run either on a general-purpose computer or on another piece of electronic apparatus, typically attached to a general purpose computer, specially designed for simulation. Simulators that run entirely in software on a general-purpose computer will hereinafter be referred to as “software simulators”. Simulators that are run with the assistance of specially designed electronic apparatus will hereinafter be referred to as “hardware simulators”.
- Usually, software simulators perform a very large number of calculations and operate slowly from the user's point of view. In order to optimize performance, the format of the simulation model is designed for very efficient use by the simulator. Hardware simulators, by nature, require that the simulation model comprising the circuit description be communicated in a specially designed format. In either case, a translation from an HDL description to a simulation format, hereinafter referred to as a simulation executable model, is required.
- The result of the application of the testcase to the simulation executable model by the simulator is referred to herein as an “all events trace” (AET). The AET contains the logic values of signals and/or storage elements within the simulation executable model. An AET viewer can be utilized to present by the contents of the AET to the user for review and analysis.
- As will be appreciated, for large simulation executable models, a vast amount of data will be present in the AET, not all of which will be relevant to the user. Accordingly, conventional AET viewers permit a user to input an Input/Output (I/O) list specifying signals in the simulation executable model that the user desires to view. In response, a conventional AET viewer presents to the user only those signals within the simulation executable model that are identified within the I/O list.
- The present invention recognizes that user entry of the I/O list (e.g., utilizing a keyboard) is tedious and time consuming, particularly for complex simulation executable models. Accordingly, the present invention provides to a method, system and program product for simulation processing.
- According to an exemplary method, a data set including at least one entry specifying a signal group by a predetermined signal group name is received by a data processing system. In response to receipt of the data set, the entry in the data set is processed to identify the signal group name. Signal group information associated with an event trace file containing simulation results is accessed to determine signal names of multiple signals that are members of the signal group. Simulation results from the event trace file that are associated with instances of said multiple signals are then included within a presentation of simulation results.
- All objects, features, and advantages of the present invention will become apparent in the following detailed written description.
- The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
-
FIG. 1 is a pictorial representation of a data processing system in accordance with the present invention; -
FIG. 2 depicts a representative hardware environment of the data processing system illustrated inFIG. 1 ; -
FIG. 3A is a simplified block diagram illustrating a digital design entity in accordance with the teachings of the present invention; -
FIG. 3B is a diagrammatic representation depicting a simulation model in accordance with the teachings of the present invention; -
FIG. 3C is a flow diagram illustrating of a model build process in accordance with the teachings of the present invention; -
FIG. 3D is a block diagram depicting simulation model data structures representing a design in accordance with the teachings of the present invention; -
FIG. 4 is a flow diagram depicting simulation of a simulation executable model and presenting the results of simulation to a user; -
FIG. 5A depicts a first conventional I/O list in accordance with the prior art; -
FIG. 5B depicts a second conventional I/O list in accordance with the prior art; -
FIGS. 5C-5D illustrate exemplary I/O lists in accordance with the present invention; -
FIG. 6A depicts an exemplary design entity HDL file including signal group descriptors in accordance with the present invention; -
FIG. 6B illustrates an exemplary design entity HDL file including nested signal group descriptors in accordance with the present invention; and -
FIGS. 7A-7C together form a high-level logical flowchart of an exemplary process by which an AET viewer processes an I/O list to generate a presentation of an AET file in accordance with the present invention. - With reference now to the figures, and in particular with reference to
FIG. 1 , there is depicted a pictorial representation of a data processing system 10 with which the present invention may be advantageously utilized. As illustrated, data processing system 10 comprises aworkstation 12 to which one ormore nodes 13 are connected.Workstation 12 preferably comprises a high performance multiprocessor computer, such as one of the POWER line of computer systems available from International Business Machines (IBM) Corporation of Armonk, N.Y.Workstation 12 preferably includes nonvolatile and volatile internal storage for storing software applications comprising an ECAD system, which can be utilized to develop and verify a digital circuit design in accordance with the method and system of the present invention. As depicted,nodes 13 include adisplay device 14, akeyboard 16, and amouse 20. The ECAD software applications executed withinworkstation 12 preferably display a graphic user interface (GUI) withindisplay screen 22 ofdisplay device 14 with which a digital circuit designer can interact using akeyboard 16 andmouse 20. Thus, by entering appropriateinputs utilizing keyboard 16 andmouse 20, the digital circuit designer is able to develop and verify a digital circuit design according to the method described further hereinbelow. -
FIG. 2 is a more detailed block diagram of data processing system 10. As illustrated, data processing system 10 includes one or more Central Processing Units (CPUs) 24, such as a conventional microprocessor, and a number of other components interconnected viasystem interconnect 26. Although not depicted inFIG. 2 , CPUs such asCPU 24 typically include a control unit that organizes data and program storage in a computer memory and transfers the data and other information between the various parts of the computer system. CPUs also generally include one or more arithmetic logic units that execute arithmetical and logical operations, such as addition, comparison, multiplication and so forth. - Data processing system 10 further includes a random-access memory (RAM) 28, a read-only memory (ROM) 30, a
display adapter 32 supporting connection of adisplay device 14, and an I/O adapter 34 for connecting peripheral devices (e.g., disk and tape drives 33). Data processing system 10 further includes acommunications adapter 42 for connecting data processing system 10 to a communications network and auser interface adapter 36 for connectingkeyboard 16,mouse 20,speaker 38,microphone 40, and/or other user interface devices tosystem interconnect 26. - As will be appreciated by those skilled in the art, data processing system 10 operates under the control of an operating system (e.g., AIX) and one or more other programs, which may reside in any suitable computer-readable media such as RAM 28,
ROM 30, a magnetic disk, magnetic tape, or optical disk (the last three being located in disk and tape drives 33). - Simulated digital circuit design models are comprised of at least one and usually many sub-units referred to hereinafter as design entities.
FIG. 3A is a block diagram representation of anexemplary design entity 300 in which the method and system of the present invention may be implemented.Design entity 300 is defined by a number of components: an entity name, entity ports, and a representation of the function performed bydesign entity 300. Each entity within a given model has a unique name (not explicitly shown inFIG. 3A ) that is declared in the HDL description of each entity. Furthermore, each entity typically contains a number of signal interconnections, known as ports, to signals outside the entity. These outside signals may be primary input/outputs (I/Os) of an overall design or signals connecting to other entities within an overall design. - Typically, ports are categorized as belonging to one of three distinct types: input ports, output ports, and bi-directional ports.
Design entity 300 is depicted in as having a number ofinput ports 303 that convey signals intodesign entity 300.Input ports 303 are connected to input signals 301. In addition,design entity 300 includes a number ofoutput ports 306 that convey signals out ofdesign entity 300.Output ports 306 are connected to a set of output signals 304.Bi-directional ports 305 are utilized to convey signals into and out ofdesign entity 300.Bi-directional ports 305 are in turn connected to a set ofbi-directional signals 309. An entity, such asdesign entity 300, need not contain ports of all three types, and in the degenerate case, contains no ports at all. To accomplish the connection of entity ports to external signals, a mapping technique, known as a “port map”, is utilized. A port map (not explicitly depicted inFIG. 3A ) consists of a specified correspondence between entity port names and external signals to which the entity is connected. When building a simulation model, ECAD software is utilized to connect external signals to appropriate ports of the entity according to a port map specification. - Finally,
design entity 300 contains abody section 308 that describes one or more functions performed bydesign entity 300. In the case of a digital design,body section 308 contains an interconnection of logic gates, storage elements, etc., in addition to instantiations of other entities. By instantiating an entity within another entity, a hierarchical description of an overall design is achieved. For example, a microprocessor may contain multiple instances of an identical functional unit. As such, the microprocessor itself will often be modeled as a single entity. Within the microprocessor entity, multiple instantiations of any duplicated functional entities will be present. - Referring now to
FIG. 3B , there is illustrated a diagrammatic representation of anexemplary simulation model 329 that may be utilized in a preferred embodiment of the present invention.Simulation model 329 includes multiple hierarchical design entities. For visual simplicity and clarity, many of the ports and signals interconnecting the entities withinsimulation model 329 have not been explicitly shown. In any model, one and only one entity is the so-called “top-level entity”. A top-level entity 320 is that entity which encompasses all other entities withinsimulation model 329. That is to say, top-level entity 320 instantiates, either directly or indirectly, all descendant entities within a design.Simulation model 329 consists of top-level entity 320 which directly instantiates two instances, 321 a and 321 b, of an FXU entity 321. Each instantiation has an associated description, which contains an entity name and a unique instantiation name. For top-level entity 320,description 310 is labeled “TOP:TOP”.Description 310 includes anentity name 312, labeled as the “TOP” preceding the colon, and also includes aninstantiation name 314, labeled as the “TOP” following the colon. - It is possible for a particular entity to be instantiated multiple times as is depicted with
instantiations Instantiations level entity 320 is at the highest level within the hierarchy ofsimulation model 329. An entity that instantiates a descendant entity will be referred to hereinafter as an “ancestor” of the descendant entity. Top-level entity 320 is therefore the ancestor that directly instantiates FXU entity instantiations 321 a and 321 b. At any given level of a simulation model hierarchy, the instantiation names of all instantiations must be unique. - Within
instantiation 321 a of FXU entity 321,single instance entities instantiation 321 b of the same FXU entity containsinstantiations 325 b and 326 b of entity A 325 and entity B 326 respectively. In a similar manner, instantiation 326 a and instantiation 326 b each directly instantiate a single instance of entity C 327 asentities - Associated with each entity instantiation is a so called “instantiation identifier”. The instantiation identifier for a given instantiation is a string consisting of the enclosing entity instantiation names proceeding from the top-level entity instantiation name. For example, the instantiation identifier of
instantiation 327 a of entity C 327 withininstantiation 321 a of FXU entity 321 is “TOP.FXU0.B.C”. This identifier serves to uniquely identify each instantiation within a simulation model. - Within
exemplary simulation model 329, a variety of signals are instantiated (e.g., signals E, F0, F1, G, H0, H1, L, M, N, P and Q). Each signal has an associated signal name (e.g., “M”) and a signal instantiation identifier, which in a preferred embodiment, is a string consisting of the enclosing entity instantiation names proceeding from the top-level entity instantiation name and terminating with the signal name. Thus, the instantiation identifier of signal M withininstantiation 321 a of FXU entity 321 is “TOP.FXU0.A.M”. This instantiation identifier serves to uniquely identify each signal instantiation within a simulation model. It should be noted that signals, for example, signal P(0 . . . 4), can be multi-bit signal vectors. It should also be noted that some signals (e.g., signals TOP.FXU0.E, TOP.FXU1.E, TOP.FXU0.G and TOP.FXU1.G) are renamed (as signals TOP.FXU0.F0, TOP.FXU1.F1, TOP.FXU0.H0 and TOP.FXU1.H1, respectively) as they cross design entity boundaries. - Referring now to
FIG. 3C , there is depicted a flow diagram of a model build process which may be implemented in a preferred embodiment of the present invention. The process begins with one or more design entity HDL source code files 340 and, potentially, one or more design entity intermediate format files 345, hereinafter referred to as “proto files” 345, available from a previous run of anHDL compiler 342.HDL compiler 342 processes HDL file(s) 340 beginning with the top level entity of a simulation model and proceeding in a recursive fashion through all HDL or proto file(s) describing a complete simulation model. For each of HDL files 340 during the compilation process,HDL compiler 342 examinesproto files 345 to determine if a previously compiled proto file is available and consistent. If such a file is available and consistent,HDL compiler 342 will not recompile that particular file, but will rather refer to an extant proto file. If no such proto file is available or the proto file is not consistent,HDL compiler 342 explicitly recompiles the HDL file 340 in question and creates a proto file 344 for use in subsequent compilations. Such a process will be referred to hereinafter as “incremental compilation” and can greatly speed the process of creating a simulationexecutable model 348. Once created byHDL compiler 342, proto files 344 are available to serve asproto files 345 in subsequent compilations. - In addition to proto files 344,
HDL compiler 342 also creates two sets of data structures, design entity proto data structures 341 and design entityinstance data structures 343, inmemory 44 of computer system 10. Design entity proto data structures 341 and design entityinstance data structures 343, serve as a memory image of the contents of a simulationexecutable model 348.Data structures 341 and 343 are passed, viamemory 44, to a model build tool 346 that processesdata structures 341 and 343 into simulationexecutable model 348. - It will be assumed hereinafter that each entity is described by a single HDL file. Depending on convention or the particular HDL in which the current invention is practiced, this restriction may be required. However, in certain circumstances or for certain HDLs it is possible to describe an entity by utilizing more than one HDL file. Those skilled in the art will appreciate and understand the extensions necessary to practice the present invention if entities are permitted to be described by multiple HDL files. Furthermore, it will be assumed that there is a direct correspondence, for each entity, between the entity name and both of the following: the name of the HDL file representing the entity, and the name of the proto file for the entity.
- In the following description, an HDL source code file corresponding to a given entity will be referred to by an entity name followed by “.vhdl”. For example, the HDL source code file that describes top-
level entity 320 will be referred to as TOP.vhdl. This labeling convention serves as a notational convenience only and should not be construed as limiting the applicability of the present invention to HDLs other than VHDL. - Returning to
FIG. 3B , it can be seen that each entity may instantiate, either directly or indirectly, one or more other entities. For example, the FXU entity directly instantiates A entity 325 and B entity 326. Furthermore, B entity 326 directly instantiates C entity 327. Therefore, FXU entity 321 instantiates, directly or indirectly, A entity 325, B entity 326 and C entity 327. Those entities, that are directly or indirectly instantiated by another entity, will be referred to hereinafter as “descendants”. The descendants oftop level entity 320 are FXU entity 321, A entity 325, B entity 326, and C entity 327. It can be seen that each entity has a unique set of descendants and that each time an entity is instantiated, a unique instance of the entity and its descendants is created. Withinsimulation model 329, FXU entity 321 is instantiated twice, FXU:FXU0 321 a and FXU:FXU1 321 b, by top-level entity 320. Each instantiation of FXU entity 321 creates a unique set of instances of the FXU, A, B, and C entities. - For each entity, it is possible to define what is referred to as a “bill-of-materials” or BOM. A BOM is a list of HDL files having date and time stamps of the entity itself and the entity's descendants. Referring again to
FIG. 3C , the BOM for an entity is stored in proto file 344 after compilation of the entity. Therefore, whenHDL compiler 342 compiles a particular HDL source code file among HDL files 340, a proto file 344 is generated that includes a BOM listing the HDL files 340 that constitute the entity and the entity's descendants, if any. The BOM also contains the date and time stamp for each of the HDL files referenced as each appeared on disk/tape 33 of computer system 10 when the HDL file was being compiled. - If any of the HDL files constituting an entity or the entity's descendants is subsequently changed, proto file 344 will be flagged as inconsistent and
HDL compiler 342 will recompile HDL file 340 on a subsequent re-compilation as will be described in further detail below. For example, going back toFIG. 3B , the HDL files referenced by the BOM of FXU entity 321 are FXU.vhdl, A.vhdl, B.vhdl and C.vhdl, each with appropriate date and time stamps. The files referenced by the BOM of top-level entity 320 are TOP.vhdl, FXU.vhdl, A.vhdl, B.vhdl, C.vhdl, and FPU.vhdl with appropriate date and time stamps. - Returning to
FIG. 3C ,HDL compiler 342 creates an image of the structure of a simulation model inmain memory 44 of computer system 10. This memory image is comprised of the following components: “proto” data structures 341 and “instance”data structures 343. A proto is a data structure that, for each entity in the model, contains information about the ports of the entity, the body contents of the entity, and a list of references to other entities directly instantiated by the entity (in what follows, the term “proto” will be utilized to refer to the in-memory data structure described above and the term “proto file” will be utilized to describe intermediate format file(s) 344). Proto files 344 are therefore on-disk representations of the in-memory proto data structure produced byHDL compiler 342. - An instance data structure is a data structure that, for each instance of an entity within a model, contains the instance name for the instance, the name of the entity the instance refers to, and the port map information necessary to interconnect the entity with external signals. During compilation, each entity will have only one proto data structure, while, in the case of multiple instantiations of an entity, each entity may have one or more instance data structures.
- In order to incrementally compile a model efficiently,
HDL compiler 342 follows a recursive method of compilation in which successive entities of the model are considered and loaded fromproto files 345 if such files are available and are consistent with the HDL source files constituting those entities and their descendants. For each entity that cannot be loaded from existingproto files 345,HDL compiler 342 recursively examines the descendants of the entity, loads those descendant entities available from proto file(s) 345 and creates, as needed, proto files 344 for those descendants that are inconsistent withproto files 345. Pseudocode for the main control loop ofHDL compiler 342 is shown below (the line numbers to the right of the pseudocode are not a part of the pseudocode, but merely serve as a notational convenience).process_HDL_file(file) 5 { 10 if (NOT proto_loaded(file)) { 15 if (exists_proto_file(file) AND check_bom(file)) { 20 load_proto(file); 25 } else { 30 parse_HDL_file(file) 35 for (all instances in file) { 40 process_HDL_file(instance); 45 } 50 create_proto(file); 55 write_proto_file(file); 60 } 65 } 70 create_instance(file): 75 } 80 - When
compiler 342 is initially invoked, no proto data structures 341 orinstance data structures 343 are present inmemory 44 of computer system 10. The main control loop, routine process_HDL_file( ) (line 5), is invoked and passed the name of the top level entity by means of parameter “file”. The algorithm first determines if a proto data structure for the current entity is present inmemory 44 by means of routine proto_loaded( ) (line 15). Note that the proto data structure for the top level entity will never be present in memory because the process starts without any proto data structures loaded intomemory 44. If a matching proto data structure is present inmemory 44, instance data structures for the current entity and the current entity's descendants, if any, are created as necessary inmemory 44 by routine create_instance( ) (line 75). - However, if a matching proto data structure is not present in
memory 44, control passes toline 20 where routine exists_proto_file( ) examinesproto files 345 to determine if a proto file exists for the entity. If and only if a matching proto file exists, routine check_bom( ) is called to determine whetherproto file 345 is consistent. In order to determine whether the proto file is consistent, the BOM for the proto file is examined. Routine check_bom( ) examines each HDL source code file listed in the BOM to determine if the date or time stamps for the HDL source code file have changed or if the HDL source code file has been deleted. If either condition occurs for any file in the BOM, the proto file is inconsistent and routine check_bom( ) fails. However, if check_bom( ) is successful, control is passed to line 25 where routine load_proto( ) loads the proto file and any descendant proto files intomemory 44, thus creating proto data structures 341 for the current entity and the current entity's descendants, if any. The construction of process_HDL_file( ) ensures that once a proto file has been verified as consistent, all of its descendant proto files, if any, are also consistent. - If the proto file is either non-existent or is not consistent, control passes to line 35 where routine parse_HDL_file( ) loads the HDL source code file for the current entity. Routine parse_HDL_file( ) (line 35) examines the HDL source code file for syntactic correctness and determines which descendant entities, if any, are instantiated by the current entity.
Lines 40, 45, and 50 constitute a loop in which the routine process_HDL_file( ) is recursively called to process the descendent entities that are called by the current entity. This process repeats recursively traversing all the descendants of the current entity in a depth-first fashion creating proto data structures 341 and proto data files 344 of all descendants of the current entity. Once the descendant entities are processed, control passes to line 55 where a new proto data structure is created for the current entity inmemory 44 by routine create_proto( ). Control then passes to line 60 where a new proto file 344, including an associated BOM, is written todisk 33 by routine write_proto_file( ). Finally, control passes to line 75 where routine create_instance( ) createsinstance data structures 343 for the current entity and any descendant entities as necessary. In this manner, process_HDL_file( ) (line 5) recursively processes the entire simulation model creating an in-memory image of the model consisting of proto data structures 341 andinstance data structures 343. - As further shown in
FIG. 3C , the present invention further permits the designer to include within design entity HDL files 340 one or moresignal group directives 350 identifying particular signals that are likely to be of interest when viewing the results of simulating simulationexecutable model 348. Exemplary semantics forsignal group directives 350 is described below with reference toFIGS. 6A-6B .HDL compiler 342, in addition to the processing described above, preferably processessignal group directives 350 to generate signal group information (SGI) 400, which represents the signal instantiation identifiers of the signals of interest utilizing any convenient data structure (e.g., linked list, table, etc.). Model build tool 346 then places the signal group information (SGI) 400, optionally with some additional transformation in format, within simulationexecutable model 348. - With reference now to
FIG. 3D there is depicted a block diagram representing compiled data structures, which may be implemented in a preferred embodiment of the present invention.Memory 44 containsproto data structures 361, one for each of the entities referred to insimulation model 329. In addition, instantiations insimulation model 329 are represented byinstance data structures 362.Instance data structures 362 are connected by means of pointers indicating the hierarchical nature of the instantiations of the entities withinsimulation model 329. Finally,memory 44 containsSGI 400. Model build tool 346 inFIG. 3C processes the contents ofmemory 44 into memory data structures in order to produce simulationexecutable model 348. - Referring now to
FIG. 4 , there is depicted a flow diagram of a process for simulating a design and viewing simulation results in accordance with the present invention. As shown, once a simulationexecutable model 348 has been obtained by the process ofFIG. 3C , a software and/orhardware simulator 404 is utilized to stimulate simulationexecutable model 348 with atestcase 402 to simulate operation of a digital design. During the simulation, an all events trace (AET) file 406 records data representing the response of simulationexecutable model 348 totestcase 402. The data within AET file 406 includes values of various signals and/or storage elements within simulationexecutable model 348 over time as well asSGI 400. - In order to review the contents of
AET file 406, a user generally employs a separate or integrated viewer program, referred to herein asAET viewer 410. For example, the user may requestAET viewer 410 to present data from AET file 406 either in a graphical format withindisplay screen 22 or in hardcopy format. As described hereinabove, the user can advantageously restrict the presentation of data byAET viewer 410 to particular signals of interest by specifying in a data set (referred to herein as an I/O list 408) the signals of interest. - As illustrated in
FIG. 5A , a conventional I/O list 500 in accordance with the prior art is a list containing a large number of entries each setting forth a signal instantiation identifier of one of the signals of interest, which in this case comprise all of the signals withinFXU instantiation 321 a ofFIG. 3B . Thus, as will be appreciated from the simplified example given inFIG. 5A , in the prior art the user must enter each of a potentially large number of signal instantiationidentifiers utilizing keyboard 16. This conventional technique of manually keying in signal instantiation identifiers is tedious and error prone. - Additionally, some
simulators 404 do not preserve the signal names of signals in descendant design entities that cross design entity boundaries into higher level design entities. Instead, to eliminate signal duplication in the AET file,such simulators 404 only identify a signal in the AET file by its signal name in the highest level design entity in which it appears. Consequently, if asimulator 404 that does not preserve signal names is employed, the user must specify a signal within the I/O list 500 utilizing a signal instantiation identifier that employs the signal name of the signal from the highest level design entity in which the signal appears. For example, as can be seen by comparingentry 502 ofFIG. 5A withcorresponding entry 504 of I/O list 500′ ofFIG. 5B , the user of asimulator 404 that does not preserve signal names must utilize the signal instantiation identifier F0 as depicted atreference numeral 504 rather than the signal instantiation identifier FXU.E as illustrated atreference numeral 502. As will be appreciated, a user ofAET viewer 410 whose work predominantly pertains to a descendant design entity may have difficulty in determining or easily recalling signal names utilized in a higher level design entity that instantiates the lower level design entity with which the user is familiar. - In place of a conventional I/
O list AET viewer 410 to instead filter presentation of data from AET file 406 utilizing one or more improved I/O lists 408 in accordance withFIG. 5C . As depicted inFIG. 5C , I/O list 408 is list containing one or more entries. In addition to zero or more entries containing conventional signal instantiation identifiers as depicted inFIG. 5A or 5B, an entry of I/O list 408, such asentry 510, may identify a group of one or more signals of interest by a signal group instantiation identifier corresponding to information withinSGI 400. - As shown, the signal group instantiation identifier is formed similarly to a signal instantiation identifier and consists of a string of the enclosing entity instantiation names proceeding from the top-level entity instantiation name and terminating with the signal group name enclosed by a pair of angular brackets (“<” and “>”) indicating that the bracketed contents are a member of a separate signal group namespace. Thus, the six signals of interest within FXU entity instantiation 321 a can simply be identified by the single entry “FXU0.<FXU_Group>”, rather than by individually entering the signal instantiation identifiers within I/
O list 408. As indicated above, the individual signals comprising the signal group FXU_Group are specified utilizingsignal group directives 350 within design entity HDL files 340. - With reference now to
FIG. 6A , there is illustrated an exemplary embodiment of a design entity HDL file 340 a in accordance with the present invention. As will be appreciated by those skilled in the art, design entity HDL file 340 a includes conventional HDL source code describing a design entity, which in this case is design entity FXU 321. The conventional HDL source code includes aport map 600 andsignal assignment statements 602. In addition, design entity HDL file 340 a includes unconventional HDL comments containing signal group directives 350 (FIG. 3C ) in accordance with the present invention. - In design entity HDL file 340 a, the
signal group directives 350 include two different types of signal group directives: asignal group declaration 610 and asignal preservation directive 620.Signal group declaration 610 begins with an HDL comment of the form “--!! Signal Group signal_group_name;” and ends with an HDL comment of the form “--!! END Signal Group signal_group_name;”, where signal_group_name is a signal group name (in this example, FXU_Group) that is unique for the given target design entity. Between the beginning and ending statements ofsignal group declaration 610, the signal names of one or more signals of interest are listed in the desired order of presentation byAET viewer 410. In this embodiment, signal names are specified relative to the target design entity (e.g., FXU design entity 321). At least some embodiments of the present invention permit signal names higher in the design entity hierarchy to be specified relative to the target design entity utilizing the conventional syntax “..\” to indicate a next higher level of hierarchy. - The user is preferably permitted to further specify additional attributes related to the presentation of signals within
signal group declaration 610. For example, the user can specify a desired color for a signal, a default to a waveform or binary signal representation, a desired justification of unaligned bit vectors, etc. Thus, instatement 612 ofsignal group declaration 610 the user has specified a left justification of the 5-bit signal vector B.C.P(0 . . . 4). - As further depicted in design entity HDL file 340 b of
FIG. 6B , a signal group declaration, such assignal group declaration 630, also preferably permits the user to specify nested signal groups to any legal depth. To specify a nested signal group comprising a portion of a larger signal group, the user simply includes a statement in a signal group declaration referring to the instantiation identifier of the nested signal group with the signal group enclosed in angular brackets (i.e., “<” and “>”). The use of angular brackets permitsHDL compiler 342 to discriminate between the namespaces of signals and signal group names. - Referring back to
FIG. 6A , asignal preservation directive 620 is utilized to instruct asimulator 404 that by default does not preserve the lower-level signal name of a renamed signal to do so for a particular renamed signal (e.g., signal G). Thus, assumingsimulator 404 does not preserve the lower-level names of renamed signals by default, AET file 406 will contain data for signal instantiation identifiers TOP.FXU0.G and TOP.FXU1.G. As discussed above with reference toFIG. 5B , the capability to preserve a familiar signal name eliminates the need for the user to enter into an I/O list the possibly unfamiliar signal instantiation identifiers TOP.FXU1.H0 and TOP.FXU1.H1 to view the signal data of preserved signal G. - With reference now to
FIGS. 7A-7C , there is depicted a high level logical flowchart of an exemplary process by whichAET viewer 410 processes an I/O list 408 in accordance with the present invention. As a logical flowchart, operations are depicted logically rather than sequentially, and many of the illustrated operations can be performed in parallel or in an alternative order. - As illustrated, the process begins at
block 700 ofFIG. 7A and then proceeds to block 702, which illustrates a determination of whether or not a user has entered a reference scope for the I/O list 408, that is, a scope of simulationexecutable model 348 by reference to which all other I/O list entries will be parsed. By default, the reference scope is the top level design entity instance in the simulationexecutable model 348, for example, top-leveldesign entity instance 320 ofFIG. 3B . In one embodiment, the user is permitted to enter a command further limiting the reference scope of the form “Scope limit:instance_string0.[design_entity].instance_string1”,where instance_string0 and instance_string1 are optional design entity instance strings (that for instrance_string0 begins with the top-level design entity instance) and design_entity enclosed in square brackets is an optional design entity name. A legal reference scope command includes at least one of the three optional fields instance_string0, [design_entity], and instance_string1. The reference scope command can be communicated toAET viewer 410, for example, via a command line or within I/O list 408. If inserted within an I/O list 408, the reference scope command preferably applies to all entries in that I/O list 408. - As indicated at
block 702, if the user has not entered a different reference scope,AET viewer 410 sets the reference scope by default to the top level design entity instance of the simulationexecutable model 348, as illustrated atblock 704. Thereafter, the process passes through page connector A toFIG. 7B . IfAET viewer 410 determines atblock 702 that the user has entered a different reference scope,AET viewer 410 further parses the reference scope command to determine atblock 710 whether or not the reference scope command contains bracketed syntax (e.g., [design_entity]). If not, the process proceeds to block 713, which illustratesAET viewer 410 determining whether of not the design entity instance specified by the reference scope command exists in the simulationexecutable model 348. If not, processing terminates with an error atblock 715. If so, the process passes fromblock 713 to block 720, which depictsAET viewer 410 setting the reference scope to the particular design entity instance specified within the instance_string0 field of the reference scope command. For example, assuming simulationexecutable model 329 ofFIG. 3B , the reference scope command “Scope limit:TOP.FXU0” sets the reference scope toinstance 321 a of FXU design entity 321. With this reference scope,entry 510 of I/O list 408 ofFIG. 5C can be simplified as <FXU_Group>. Thereafter, the process passes through page connector A toFIG. 7B . - Returning to block 710, in response to a determination that the reference scope command employs bracketed syntax,
AET viewer 410 next determines atblock 712 whether or not the named design entity exists within simulationexecutable model 348. If not, processing ends with an error atblock 714. If, however, the specified design entity is present in simulationexecutable model 348,AET viewer 410 recursively searches simulationexecutable model 348 to identify all the instances of the design entity that are present within the portion of simulationexecutable model 348 defined by instance_string0, if present. As indicated atblock 718, if no instances of the specified design entity exist within the specified scope, processing terminates with an error atblock 714. IfAET viewer 410 determines atblock 718 that at least one instance of the specified design entity was located within the specified scope,AET viewer 410 further determines atblock 722 if only a single instance of the design entity was found within the specified scope. If so, the process passes to block 720, which illustratesAET viewer 410 setting that single instance of the design entity as the reference scope. Thereafter, the process passes through page connector A toFIG. 7B . - If
AET viewer 410 determines atblock 722 that more than one instance of the specified design entity was found within the specified scope,AET viewer 410 presents a list of the design entity instances to the user for selection, for example, via a graphical menu displayed within display screen 22 (block 724).AET viewer 410 then receives user input designating a single one of the multiple design entity instances as defining the desired reference scope, as illustrated atblock 726. For example, assuming simulationexecutable model 329 ofFIGS. 3B and I/O list 408′ ofFIG. 5D , the reference scope command “Scope limit:[FXU]” given atreference numeral 512 ofFIG. 5D would causeAET viewer 410 to locateFXU instances executable model 329 and present instance identifiers ofinstances FXU instance entry 512 of I/O list 408′ ofFIG. 5D . Thereafter, the process passes to block 720, which has been described. - Referring now to
FIG. 7B , the process begins at page connector A and then proceeds to block 730, which represents a processing loop in whichAET viewer 410 processes each entry within one or more I/O lists to 408 to construct a presentation ofAET file 406. IfAET viewer 410 determines atblock 730 that all entries within the I/O list(s) have been processed the process passes to block 732, which is described below. If, however, at least one entry within an I/O list 408 remains to be processed, the process proceeds to block 740, which depictsAET viewer 410 moving to the first or next signal-identifying entry within the I/O list 408 and initializing a working scope for the entry to the reference scope. Signal-identifying entries within I/O lists 408 are processed with respect to (i.e., as impliedly limited by) the reference scope and take the general form: - instance_string2.[design_entity*].instance_string3.signals
- where:
-
-
- instance_string2 and instance_string3 are optional design entity instance strings;
- design entity enclosed in square brackets (i.e., “[” and “]”) is an optional design entity name;
- * is an optional universal operator indicating all design_entity instances within the specified scope; and
- signals is a required parameter that specifies a signal name, a signal group name enclosed in angular brackets (i.e., “<” and “>”), or empty angular brackets signifying all signal groups within the specified scope.
- The process shown in
FIG. 7B proceeds fromblock 740 to block 742, which depictsAET viewer 410 determining whether the current signal-identifying entry has a leading design entity instance qualifier (e.g., instance_string2). If not, the process passes to block 752, which is described below. If so, the process proceeds fromblock 742 to block 744, which illustratesAET viewer 410 determining whether or not the specified design entity instance exists within the reference scope of simulationexecutable model 348. If not, processing terminates with an error atblock 746. If so, the process proceeds to block 750.Block 750 illustratesAET viewer 410 setting the current scope to the scope formed by appending the scope defined by the design entity instance qualifier to the reference scope. Next,AET viewer 410 determines atblock 752 whether or not the next field within the signal-identifying entry of I/O list 408 is a design_entity qualifier enclosed in square brackets. If not, the process passes through page connector B toFIG. 7C . If so, processing of the signal-identifying entry continues atblock 754. -
Block 754 showsAET viewer 410 recursively searching simulation executable mode 1348 to locate all design entity instances within the current scope having an entity name matching the specified design entity name.AET viewer 410 then determines atblock 756 whether or not any such design entity instances exist. If not, processing ends with an error condition atblock 746. If so,AET viewer 410 further determines atblock 760 whether or not the bracketed syntax includes an asterisk signifying the inclusion of all design entity instances within the specified scope. If so,AET viewer 410 narrows the working scope(s) of the entry to the one or more design entity instance(s) located at block 754 (block 761). Thereafter, the process passes through page connector B toFIG. 7C . - Returning to block 760, in response to a negative determination, the process proceeds to block 762, which illustrates
AET viewer 410 determining whether a single design entity instance was discovered atblock 754. If so, the working scope is set atblock 764 to the single design entity instance. Thereafter, the process passes through page connector B toFIG. 7C . If, on the other hand,AET viewer 410 determines atblock 762 that more than one design entity instances was discovered atblock 754,AET viewer 410 presents a list of the design entity instances to the user for selection, for example, via a graphical menu displayed within display screen 22 (block 770).AET viewer 410 then receives user input designating one or more of the multiple design entity instances as defining the desired working scope, as illustrated atblock 772. Thereafter, the process passes to block 764, which depictsAET viewer 410 establishing one or more working scopes in accordance with the user's selection. Thereafter, the process passes through page connector B toFIG. 7C . - With reference now to
FIG. 7C , the process begins at page connector B and then proceeds to block 774, which depictsAET viewer 410 further parsing the signal-identifying entry to determine whether the entry contains a further instance qualifier (e.g., instance_string3) to limit the working scope(s). If not, the process passes to block 780, which is described below. If so,AET viewer 410 determines atblock 776 whether or not the specified design entity instance(s) exist. If not, the process ends with an error atblock 786. If the specified design entity instance(s) exist,AET viewer 410 narrows the working scope(s) of the current signal-identifying entry to the design entity instance(s) indicated by the second instance qualifier (block 778). Thereafter, the process passes to block 780. -
Block 780 depictsAET viewer 410 further parsing the signal-identifying entry of I/O list 408 to determine if the terminal signals field of the entry contains a single signal name or a signal group name. If the signals field contains a signal name,AET viewer 410 next determines atblock 781 if the specified signal exists within the working scope(s). If not, processing terminates atblock 786 with an error condition. IfAET viewer 410 determines atblock 781 if the specified signal exists within the working scope(s). If not, processing terminates atblock 786 with an error condition. If so,AET viewer 410 adds the specified signal(s) to the presentation of AET file 406 (block 782). Thereafter, the process returns to block 730 ofFIG. 7B via page connector C. - Referring again to block 780, in response to determining that the signals field of the signal-identifying entry does not contain a signal name, the process passes to block 783, which depicts
AET viewer 410 determining whether the signals field contains empty angle brackets. If so,AET viewer 410 recursively locates all signal group instances within the design entity instances within the working scope(s), as shown atblock 784. If AET viewer determines that none exists atblock 785, processing ends with an error atblock 786. If, on the other hand,AET viewer 410 determines atblock 785 that one or more signal groups are present,AET viewer 410 determines the individual signals comprising the signal groups fromSGI 400 and adds all such signals to the presentation atblock 790. Thereafter, the process returns through page connector C toFIG. 7B . - Returning to block 783, if
AET viewer 410 determines that the signals field of the signal-identifying entry of I/O list 408 does not contain empty angle brackets, but instead specifies a signal group name within angle brackets, the process passes to block 787.Block 787 illustratesAET viewer 410 recursively locating instances of the specified signal group instances within the design entity instances within the working scope(s). As represented byblock 788, if no signal group instances are located, processing ends with an error condition atblock 786. Alternatively, if at least one instance of the named signal group is located, processing proceeds to block 790 and following blocks which have been described. - As has been described, the present invention provides a method, system and program product for processing simulation results for presentation. In accordance with the present invention, the amount of user input required to filter the presentation of simulation results is substantially reduced through the use of predetermined signal groups and, optionally, the use of scope commands. In addition, the ease of understanding simulation results is enhanced through support of signal preservation directives that enable a designer to designate signals for which signal names are to be preserved in the presence of signal renaming.
- While the invention has been particularly shown as described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. For example, one of the embodiments of the invention can be implemented with program code resident in random access memory 28 or non-volatile storage of one or more computer systems configured generally as described in
FIG. 1 andFIG. 2 . Until required by computer system 10, the set of program code may be stored in another computer readable storage device, such asdisk drive 33 or CD-ROM, or in data storage of another computer and transmitted over a local area network or a wide area network, such as the Internet, when desired by the user. The program code embodied in a computer usable medium may be referred to as a computer program product.
Claims (18)
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/381,437 US7711537B2 (en) | 2006-05-03 | 2006-05-03 | Signals for simulation result viewing |
PCT/EP2007/054255 WO2007128753A1 (en) | 2006-05-03 | 2007-05-02 | Method, system and program product supporting specification of signals for simulation result viewing |
EP07728709A EP2021963A1 (en) | 2006-05-03 | 2007-05-02 | Method, system and program product supporting specification of signals for simulation result viewing |
JP2009508341A JP5039130B2 (en) | 2006-05-03 | 2007-05-02 | Methods, systems, and program products that support specification of signals for displaying simulation results |
CN2007800115291A CN101410841B (en) | 2006-05-03 | 2007-05-02 | Method, system and program product supporting specification of signals for simulation result viewing |
US12/129,813 US7617085B2 (en) | 2006-05-03 | 2008-05-30 | Program product supporting specification of signals for simulation result viewing |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/381,437 US7711537B2 (en) | 2006-05-03 | 2006-05-03 | Signals for simulation result viewing |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/129,813 Continuation US7617085B2 (en) | 2006-05-03 | 2008-05-30 | Program product supporting specification of signals for simulation result viewing |
Publications (2)
Publication Number | Publication Date |
---|---|
US20070260443A1 true US20070260443A1 (en) | 2007-11-08 |
US7711537B2 US7711537B2 (en) | 2010-05-04 |
Family
ID=38268901
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/381,437 Expired - Fee Related US7711537B2 (en) | 2006-05-03 | 2006-05-03 | Signals for simulation result viewing |
US12/129,813 Expired - Fee Related US7617085B2 (en) | 2006-05-03 | 2008-05-30 | Program product supporting specification of signals for simulation result viewing |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/129,813 Expired - Fee Related US7617085B2 (en) | 2006-05-03 | 2008-05-30 | Program product supporting specification of signals for simulation result viewing |
Country Status (5)
Country | Link |
---|---|
US (2) | US7711537B2 (en) |
EP (1) | EP2021963A1 (en) |
JP (1) | JP5039130B2 (en) |
CN (1) | CN101410841B (en) |
WO (1) | WO2007128753A1 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100153898A1 (en) * | 2008-12-16 | 2010-06-17 | International Business Machines Corporation | Model build in the presence of a non-binding reference |
US20120041987A1 (en) * | 2010-08-10 | 2012-02-16 | Nigel James Brock | System and method for analyzing data |
US8160857B2 (en) | 2008-12-16 | 2012-04-17 | International Business Machines Corporation | Selective compilation of a simulation model in view of unavailable higher level signals |
US20160286418A1 (en) * | 2015-03-24 | 2016-09-29 | Anritsu Corporation | Fading simulator and mobile terminal testing system |
US20170019195A1 (en) * | 2015-07-17 | 2017-01-19 | Anritsu Corporation | Fading simulator and method of producing fading signal |
US9652726B2 (en) | 2010-08-10 | 2017-05-16 | X Systems, Llc | System and method for analyzing data |
US9665916B2 (en) | 2010-08-10 | 2017-05-30 | X Systems, Llc | System and method for analyzing data |
CN109918742A (en) * | 2019-02-15 | 2019-06-21 | 湖南高至科技有限公司 | A kind of data distribution and management method based on analogue system |
US10635766B2 (en) | 2016-12-12 | 2020-04-28 | International Business Machines Corporation | Simulation employing level-dependent multitype events |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7146260B2 (en) | 2001-04-24 | 2006-12-05 | Medius, Inc. | Method and apparatus for dynamic configuration of multiprocessor system |
CN116776787B (en) * | 2023-08-22 | 2023-11-17 | 北京云枢创新软件技术有限公司 | Automatic recognition method of signal alias, electronic equipment and medium |
Citations (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5212650A (en) * | 1986-09-12 | 1993-05-18 | Digital Equipment Corporation | Procedure and data structure for synthesis and transformation of logic circuit designs |
US5369753A (en) * | 1990-06-15 | 1994-11-29 | Compaq Computer Corporation | Method and apparatus for achieving multilevel inclusion in multilevel cache hierarchies |
US5604895A (en) * | 1994-02-22 | 1997-02-18 | Motorola Inc. | Method and apparatus for inserting computer code into a high level language (HLL) software model of an electrical circuit to monitor test coverage of the software model when exposed to test inputs |
US6052809A (en) * | 1997-10-16 | 2000-04-18 | Teradyne, Inc. | Method for generating test patterns |
US6053947A (en) * | 1997-05-31 | 2000-04-25 | Lucent Technologies, Inc. | Simulation model using object-oriented programming |
US6117181A (en) * | 1996-03-22 | 2000-09-12 | Sun Microsystems, Inc. | Synchronization mechanism for distributed hardware simulation |
US6195629B1 (en) * | 1998-11-09 | 2001-02-27 | International Business Machines Corporation | Method and system for selectively disabling simulation model instrumentation |
US6195627B1 (en) * | 1998-11-09 | 2001-02-27 | International Business Machines Corporation | Method and system for instrumenting simulation models |
US6202042B1 (en) * | 1998-11-09 | 2001-03-13 | International Business Machines Corporation | Hardware simulator instrumentation |
US6285914B1 (en) * | 1997-12-30 | 2001-09-04 | Hyundai Electronics Industries Co., Ltd. | Verification method by means of comparing internal state traces |
US6295623B1 (en) * | 1999-01-29 | 2001-09-25 | Credence Systems Corporation | System for testing real and simulated versions of an integrated circuit |
US20020019969A1 (en) * | 1999-10-29 | 2002-02-14 | Hellestrand Graham R | Hardware and software co-simulation including simulating the cache of a target processor |
US20020032559A1 (en) * | 1999-10-29 | 2002-03-14 | Hellestrand Graham R. | Hardware and software co-simulation including executing an analyzed user program |
US20020046391A1 (en) * | 2000-08-31 | 2002-04-18 | Hitachi, Ltd. | Method for generating behavior model description of circuit and apparatus for logic verification |
US20020049576A1 (en) * | 2000-07-05 | 2002-04-25 | Meyer Steven J. | Digital and analog mixed signal simulation using PLI API |
US6393426B1 (en) * | 1997-01-28 | 2002-05-21 | Pliant Technologies, Inc. | Method for modeling, storing and transferring data in neutral form |
US20020123874A1 (en) * | 2000-12-30 | 2002-09-05 | International Business Machines Corporation | Detecting events within simulation models |
US20020128809A1 (en) * | 2000-12-30 | 2002-09-12 | International Business Machines Corporation | Randomized simulation model instrumentation |
US20020129333A1 (en) * | 2000-06-05 | 2002-09-12 | Sundeep Chandhoke | System and method for programmatically generating a graphical program based on a sequence of motion control, machine vision, and data acquisition (DAQ) operations |
US20020152060A1 (en) * | 1998-08-31 | 2002-10-17 | Tseng Ping-Sheng | Inter-chip communication system |
US6470478B1 (en) * | 1999-06-29 | 2002-10-22 | International Business Machines Corporation | Method and system for counting events within a simulation model |
US20030005416A1 (en) * | 2001-06-05 | 2003-01-02 | Renate Henftling | Fault search method and apparatus |
US6519612B1 (en) * | 1996-11-27 | 2003-02-11 | 1Vision Software, Inc. | Internet storage manipulation and navigation system |
US20030037222A1 (en) * | 2001-08-17 | 2003-02-20 | Emberson David R. | Method and apparatus for controlling a massively parallel processing environment |
US20030035375A1 (en) * | 2001-08-17 | 2003-02-20 | Freeman Jay R. | Method and apparatus for routing of messages in a cycle-based system |
US6546532B1 (en) * | 2000-06-20 | 2003-04-08 | Unisys Corporation | Method and apparatus for traversing and placing cells using a placement tool |
US20030101039A1 (en) * | 2001-10-30 | 2003-05-29 | International Business Machines Corporation | Maintaining data integrity within a distributed simulation environment |
US6581191B1 (en) * | 1999-11-30 | 2003-06-17 | Synplicity, Inc. | Hardware debugging in a hardware description language |
US20030121011A1 (en) * | 1999-06-30 | 2003-06-26 | Cirrus Logic, Inc. | Functional coverage analysis systems and methods for verification test suites |
US20030144828A1 (en) * | 2001-07-30 | 2003-07-31 | Lin Sharon Sheau-Pyng | Hub array system and method |
US20030188299A1 (en) * | 2001-08-17 | 2003-10-02 | Broughton Jeffrey M. | Method and apparatus for simulation system compiler |
US20030192032A1 (en) * | 1998-02-17 | 2003-10-09 | National Instruments Corporation | System and method for debugging a software program |
US6668364B2 (en) * | 1999-05-17 | 2003-12-23 | Synplicity, Inc. | Methods and apparatuses for designing integrated circuits |
US6687710B1 (en) * | 1999-12-03 | 2004-02-03 | Synchronicity Software, Inc. | Intellectual property library management system |
US6720565B2 (en) * | 1999-06-30 | 2004-04-13 | Applied Materials, Inc. | Real-time prediction of and correction of proximity resist heating in raster scan particle beam lithography |
US6751583B1 (en) * | 1999-10-29 | 2004-06-15 | Vast Systems Technology Corporation | Hardware and software co-simulation including simulating a target processor using binary translation |
US20050137840A1 (en) * | 2001-08-15 | 2005-06-23 | National Instruments Corporation | Network-based system for configuring a programmable hardware element in a modeling system using hardware configuration programs determined based on a user specification |
US20070067150A1 (en) * | 2005-09-22 | 2007-03-22 | International Business Machines Corporation | Method and apparatus to provide alternative stimulus to signals internal to a model actively running on a logic simulation hardware emulator |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5369763A (en) | 1989-02-01 | 1994-11-29 | Kansas State University Research Foundation | Data storage and retrieval system with improved data base structure |
JPH03116276A (en) * | 1989-09-29 | 1991-05-17 | Ricoh Co Ltd | Waveform data processing method for logical simulation |
JPH05151304A (en) * | 1991-11-28 | 1993-06-18 | Nec Corp | Electronic circuit waveform analyzing device |
JP3140174B2 (en) * | 1992-06-09 | 2001-03-05 | 株式会社リコー | Waveform data display device |
JP3028792B2 (en) * | 1997-08-25 | 2000-04-04 | 日本電気株式会社 | Simulation analysis apparatus and simulation analysis method |
DE10329147A1 (en) * | 2003-06-27 | 2005-01-20 | Siemens Ag | Linking and displaying signals of a device for hardware simulation and elements of a listing of a program |
US7283944B2 (en) * | 2003-12-15 | 2007-10-16 | Springsoft, Inc. | Circuit simulation bus transaction analysis |
CN1560743A (en) * | 2004-03-11 | 2005-01-05 | 浙江大学 | Cooperative simulation experimental platform of multi medium processor |
US20060015314A1 (en) * | 2004-06-30 | 2006-01-19 | International Business Machines Corporation | Methods, systems and program products for annotating system traces with control program information and presenting annotated system traces |
-
2006
- 2006-05-03 US US11/381,437 patent/US7711537B2/en not_active Expired - Fee Related
-
2007
- 2007-05-02 EP EP07728709A patent/EP2021963A1/en not_active Withdrawn
- 2007-05-02 WO PCT/EP2007/054255 patent/WO2007128753A1/en active Application Filing
- 2007-05-02 JP JP2009508341A patent/JP5039130B2/en not_active Expired - Fee Related
- 2007-05-02 CN CN2007800115291A patent/CN101410841B/en not_active Expired - Fee Related
-
2008
- 2008-05-30 US US12/129,813 patent/US7617085B2/en not_active Expired - Fee Related
Patent Citations (43)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5212650A (en) * | 1986-09-12 | 1993-05-18 | Digital Equipment Corporation | Procedure and data structure for synthesis and transformation of logic circuit designs |
US5369753A (en) * | 1990-06-15 | 1994-11-29 | Compaq Computer Corporation | Method and apparatus for achieving multilevel inclusion in multilevel cache hierarchies |
US5604895A (en) * | 1994-02-22 | 1997-02-18 | Motorola Inc. | Method and apparatus for inserting computer code into a high level language (HLL) software model of an electrical circuit to monitor test coverage of the software model when exposed to test inputs |
US6345242B1 (en) * | 1996-03-22 | 2002-02-05 | Sun Microsystems, Inc. | Synchronization mechanism for distributed hardware simulation |
US6117181A (en) * | 1996-03-22 | 2000-09-12 | Sun Microsystems, Inc. | Synchronization mechanism for distributed hardware simulation |
US6519612B1 (en) * | 1996-11-27 | 2003-02-11 | 1Vision Software, Inc. | Internet storage manipulation and navigation system |
US6393426B1 (en) * | 1997-01-28 | 2002-05-21 | Pliant Technologies, Inc. | Method for modeling, storing and transferring data in neutral form |
US6053947A (en) * | 1997-05-31 | 2000-04-25 | Lucent Technologies, Inc. | Simulation model using object-oriented programming |
US6052809A (en) * | 1997-10-16 | 2000-04-18 | Teradyne, Inc. | Method for generating test patterns |
US6285914B1 (en) * | 1997-12-30 | 2001-09-04 | Hyundai Electronics Industries Co., Ltd. | Verification method by means of comparing internal state traces |
US20030192032A1 (en) * | 1998-02-17 | 2003-10-09 | National Instruments Corporation | System and method for debugging a software program |
US20050102125A1 (en) * | 1998-08-31 | 2005-05-12 | Verisity Design, Inc. | Inter-chip communication system |
US20020152060A1 (en) * | 1998-08-31 | 2002-10-17 | Tseng Ping-Sheng | Inter-chip communication system |
US6202042B1 (en) * | 1998-11-09 | 2001-03-13 | International Business Machines Corporation | Hardware simulator instrumentation |
US6195627B1 (en) * | 1998-11-09 | 2001-02-27 | International Business Machines Corporation | Method and system for instrumenting simulation models |
US6195629B1 (en) * | 1998-11-09 | 2001-02-27 | International Business Machines Corporation | Method and system for selectively disabling simulation model instrumentation |
US6295623B1 (en) * | 1999-01-29 | 2001-09-25 | Credence Systems Corporation | System for testing real and simulated versions of an integrated circuit |
US6668364B2 (en) * | 1999-05-17 | 2003-12-23 | Synplicity, Inc. | Methods and apparatuses for designing integrated circuits |
US6470478B1 (en) * | 1999-06-29 | 2002-10-22 | International Business Machines Corporation | Method and system for counting events within a simulation model |
US6720565B2 (en) * | 1999-06-30 | 2004-04-13 | Applied Materials, Inc. | Real-time prediction of and correction of proximity resist heating in raster scan particle beam lithography |
US20030121011A1 (en) * | 1999-06-30 | 2003-06-26 | Cirrus Logic, Inc. | Functional coverage analysis systems and methods for verification test suites |
US20020019969A1 (en) * | 1999-10-29 | 2002-02-14 | Hellestrand Graham R | Hardware and software co-simulation including simulating the cache of a target processor |
US6751583B1 (en) * | 1999-10-29 | 2004-06-15 | Vast Systems Technology Corporation | Hardware and software co-simulation including simulating a target processor using binary translation |
US20020032559A1 (en) * | 1999-10-29 | 2002-03-14 | Hellestrand Graham R. | Hardware and software co-simulation including executing an analyzed user program |
US6581191B1 (en) * | 1999-11-30 | 2003-06-17 | Synplicity, Inc. | Hardware debugging in a hardware description language |
US20050125754A1 (en) * | 1999-11-30 | 2005-06-09 | Schubert Nils E. | Hardware debugging in a hardware description language |
US6618839B1 (en) * | 1999-11-30 | 2003-09-09 | Synplicity, Inc. | Method and system for providing an electronic system design with enhanced debugging capabilities |
US6687710B1 (en) * | 1999-12-03 | 2004-02-03 | Synchronicity Software, Inc. | Intellectual property library management system |
US20020129333A1 (en) * | 2000-06-05 | 2002-09-12 | Sundeep Chandhoke | System and method for programmatically generating a graphical program based on a sequence of motion control, machine vision, and data acquisition (DAQ) operations |
US6546532B1 (en) * | 2000-06-20 | 2003-04-08 | Unisys Corporation | Method and apparatus for traversing and placing cells using a placement tool |
US20020049576A1 (en) * | 2000-07-05 | 2002-04-25 | Meyer Steven J. | Digital and analog mixed signal simulation using PLI API |
US20020046391A1 (en) * | 2000-08-31 | 2002-04-18 | Hitachi, Ltd. | Method for generating behavior model description of circuit and apparatus for logic verification |
US20020123874A1 (en) * | 2000-12-30 | 2002-09-05 | International Business Machines Corporation | Detecting events within simulation models |
US20020128809A1 (en) * | 2000-12-30 | 2002-09-12 | International Business Machines Corporation | Randomized simulation model instrumentation |
US20030005416A1 (en) * | 2001-06-05 | 2003-01-02 | Renate Henftling | Fault search method and apparatus |
US6754763B2 (en) * | 2001-07-30 | 2004-06-22 | Axis Systems, Inc. | Multi-board connection system for use in electronic design automation |
US20030144828A1 (en) * | 2001-07-30 | 2003-07-31 | Lin Sharon Sheau-Pyng | Hub array system and method |
US20050137840A1 (en) * | 2001-08-15 | 2005-06-23 | National Instruments Corporation | Network-based system for configuring a programmable hardware element in a modeling system using hardware configuration programs determined based on a user specification |
US20030188299A1 (en) * | 2001-08-17 | 2003-10-02 | Broughton Jeffrey M. | Method and apparatus for simulation system compiler |
US20030037222A1 (en) * | 2001-08-17 | 2003-02-20 | Emberson David R. | Method and apparatus for controlling a massively parallel processing environment |
US20030035375A1 (en) * | 2001-08-17 | 2003-02-20 | Freeman Jay R. | Method and apparatus for routing of messages in a cycle-based system |
US20030101039A1 (en) * | 2001-10-30 | 2003-05-29 | International Business Machines Corporation | Maintaining data integrity within a distributed simulation environment |
US20070067150A1 (en) * | 2005-09-22 | 2007-03-22 | International Business Machines Corporation | Method and apparatus to provide alternative stimulus to signals internal to a model actively running on a logic simulation hardware emulator |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100153898A1 (en) * | 2008-12-16 | 2010-06-17 | International Business Machines Corporation | Model build in the presence of a non-binding reference |
US8160857B2 (en) | 2008-12-16 | 2012-04-17 | International Business Machines Corporation | Selective compilation of a simulation model in view of unavailable higher level signals |
US8453080B2 (en) | 2008-12-16 | 2013-05-28 | International Business Machines Corporation | Model build in the presence of a non-binding reference |
US20120041987A1 (en) * | 2010-08-10 | 2012-02-16 | Nigel James Brock | System and method for analyzing data |
US9652726B2 (en) | 2010-08-10 | 2017-05-16 | X Systems, Llc | System and method for analyzing data |
US9665836B2 (en) * | 2010-08-10 | 2017-05-30 | X Systems, Llc | System and method for analyzing data |
US9665916B2 (en) | 2010-08-10 | 2017-05-30 | X Systems, Llc | System and method for analyzing data |
US20160286418A1 (en) * | 2015-03-24 | 2016-09-29 | Anritsu Corporation | Fading simulator and mobile terminal testing system |
US20170019195A1 (en) * | 2015-07-17 | 2017-01-19 | Anritsu Corporation | Fading simulator and method of producing fading signal |
US9590750B2 (en) * | 2015-07-17 | 2017-03-07 | Anritsu Corporation | Fading simulator and method of producing fading signal |
US10635766B2 (en) | 2016-12-12 | 2020-04-28 | International Business Machines Corporation | Simulation employing level-dependent multitype events |
CN109918742A (en) * | 2019-02-15 | 2019-06-21 | 湖南高至科技有限公司 | A kind of data distribution and management method based on analogue system |
Also Published As
Publication number | Publication date |
---|---|
JP2009535726A (en) | 2009-10-01 |
JP5039130B2 (en) | 2012-10-03 |
US7711537B2 (en) | 2010-05-04 |
CN101410841A (en) | 2009-04-15 |
US7617085B2 (en) | 2009-11-10 |
WO2007128753A1 (en) | 2007-11-15 |
CN101410841B (en) | 2011-01-12 |
EP2021963A1 (en) | 2009-02-11 |
US20080229193A1 (en) | 2008-09-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7617085B2 (en) | Program product supporting specification of signals for simulation result viewing | |
US9612806B2 (en) | Verification of computer-executable code generated from a model | |
US8869103B2 (en) | Using intermediate representations to verify computer-executable code generated from a model | |
US5831869A (en) | Method of compacting data representations of hierarchical logic designs used for static timing analysis | |
CN100435154C (en) | Method, system for providing a configuration specification language supporting selective presentation of configuration entities | |
US5111413A (en) | Computer-aided engineering | |
US5880971A (en) | Methodology for deriving executable low-level structural descriptions and valid physical implementations of circuits and systems from semantic specifications and descriptions thereof | |
US5933356A (en) | Method and system for creating and verifying structural logic model of electronic design from behavioral description, including generation of logic and timing models | |
US7912694B2 (en) | Print events in the simulation of a digital system | |
JP2009535726A5 (en) | ||
US5727187A (en) | Method of using logical names in post-synthesis electronic design automation systems | |
US20070088740A1 (en) | Information system development | |
EP1025492B1 (en) | Method for the generation of isa simulators and assemblers from a machine description | |
US8108199B2 (en) | Phase events in a simulation model of a digital system | |
US8160857B2 (en) | Selective compilation of a simulation model in view of unavailable higher level signals | |
US7236918B2 (en) | Method and system for selective compilation of instrumentation entities into a simulation model of a digital design | |
US20080195368A1 (en) | Method, system and program product for selectively removing instrumentation logic from a simulation model | |
US7835899B2 (en) | Sequential logic in simulation instrumentation of an electronic system | |
Cheng et al. | Enabling automated analysis through the formalization of object-oriented modeling diagrams | |
Cheng et al. | Formalizing and integrating the dynamic model for object-oriented modeling | |
EP2718821B1 (en) | Verification of computer-executable code generated from a model | |
US7506287B2 (en) | Method, system, and program product for pre-compile processing of hardware design language (HDL) source files | |
Page | Vantage Spreadsheet-a new approach to VHDL simulation | |
Kamppi | Library management implementation on Kactus2 IP-XACT tool | |
Langtangen et al. | Programming of finite element solvers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION,NEW YO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BOBOK, GABOR;ROESNER, WOLFGANG;WILLIAMS, DEREK E;SIGNING DATES FROM 20060427 TO 20060501;REEL/FRAME:017631/0210 Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BOBOK, GABOR;ROESNER, WOLFGANG;WILLIAMS, DEREK E;REEL/FRAME:017631/0210;SIGNING DATES FROM 20060427 TO 20060501 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
REMI | Maintenance fee reminder mailed | ||
LAPS | Lapse for failure to pay maintenance fees | ||
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20140504 |
|
AS | Assignment |
Owner name: GLOBALFOUNDRIES U.S. 2 LLC, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:036550/0001 Effective date: 20150629 |
|
AS | Assignment |
Owner name: GLOBALFOUNDRIES INC., CAYMAN ISLANDS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GLOBALFOUNDRIES U.S. 2 LLC;GLOBALFOUNDRIES U.S. INC.;REEL/FRAME:036779/0001 Effective date: 20150910 |