Address-based waveform database architecture

A waveform simulation system with a waveform database architecture satisfies different requirements of different waveform simulation tools. The waveform simulation system includes a waveform database configured to store one or more mappings that map one or more design objects to one or more memory addresses. The waveform simulation system also includes a packet processing module configured to receive simulation data from a simulation tool. The packet processing module is configured to translate the simulation data into translated simulation data that is independent of implementation details of the one or more design objects, based at least in part on the one or more mappings. In some cases, the translated simulation data may include event data stored in the waveform database.

TECHNICAL FIELD

The subject disclosure relates to waveform database architectures, and more specifically, to storage architectures for waveform simulations.

BACKGROUND

An electronic system may include different objects, such as circuits, buses, clocks, etc. Sometimes, in the design of an electronic system, different objects may be simulated using a simulation tool to obtain waveform simulation. Different simulation tools may be used for waveform simulation and viewing. For example, Vivado™ Simulator, Vivado™ Logic Analyzer, and System Generator™, all available at Xilinx, San Jose, Calif., are waveform tools that may be used to simulate and view waveforms, as well as to store waveform data for later review. Different tools may use different hardware definition languages (HDLs). Also, different tools may process waveforms in different ways. For example, some tools may output waveform data that is time-based, while other tools may output waveform data that is sample-based. Also, other tools may output waveform data that is clock-based.

SUMMARY

A method for storing data in a waveform database includes: obtaining a mapping that maps a design object being simulated to one or more memory addresses; receiving simulation data, wherein the simulation data corresponds to a change in a signal associated with the design object; translating, using a translator, the received simulation data based at least in part upon the mapping, wherein the translated simulation data has a format that is independent of an implementation detail of the design object; and storing the translated simulation data in the waveform database.

A method of retrieving data from a waveform database includes: receiving a request from a waveform viewer for a waveform of simulation data; identifying one or more memory addresses in a memory corresponding to the requested waveform based at least in part on a mapping that maps one or more design objects to the one or more memory addresses; determining one or more event data based on the one or more identified memory addresses, wherein the act of determining the one or more event data comprises accessing the one or more event data from the waveform database that stores the one or more event data in a format that is independent of implementation detail of the one or more design objects; and processing the one or more event data for presentation.

A waveform simulation system includes: a waveform database configured to store one or more mappings that map one or more design objects to one or more memory addresses; and a packet processing module configured to receive simulation data from a simulation tool, wherein the packet processing module is configured to translate the simulation data into translated simulation data that is independent of implementation details of the one or more design objects based at least in part on the one or more mappings; wherein the translated simulation data comprises event data stored in the waveform database.

Other aspects and features will be evident from reading the following detailed description.

DETAILED DESCRIPTION

A waveform database (WDB) architecture that satisfies different requirements of different waveform simulation tools is described herein. The waveform database architecture may be implemented in a waveform simulation system. In some cases, the waveform simulation system may be configured to run in a “live” mode and a “static” mode. In the “live” mode, a waveform simulation tool (e.g., HDL simulator, Vivado™ Simulator, Vivado™ Logic Analyzer, System Generator™′ etc.) is used to run a waveform simulation kernel process. As the simulation runs, event data are produced corresponding to changes in the waveform. These event data may be stored in a waveform database, and may also be observed and dynamically displayed by a waveform simulation viewer (e.g., window). In some cases, a user may perform certain actions using the waveform simulation viewer during the simulation process. For example, a user may operate the waveform simulation viewer to probe the waveform or to change the values of one or more simulation objects. The waveform simulation viewer may generate output based on the user operation, which output is received by the waveform simulation tool. The waveform simulation tool may then use the output from the waveform simulation viewer to update the simulation accordingly.

On the other hand, in the “static” mode, a user may use the waveform viewer to view previously created waveform data. A user may specify, using the waveform viewer, which signals/probes he or she wishes to view, as well as define the samples/time periods for the viewing. For example, a user may request to view a certain waveform between the simulation times of 100 ns and 500 ns. The corresponding data is then identified and retrieved from the waveform database to be viewed by the user on a waveform viewer.

FIG. 1illustrates a waveform simulation system100. The waveform simulation system100includes a simulator106, a memory buffer110, a packet processing module112, a waveform database114, and a waveform viewer116in communication with the waveform database114.

The simulator106may be any simulation tool, and is configured to operate on one or more simulation objects (i.e., design objects being simulated)108. By means of non-limiting examples, the simulator106may be hardware description language (HDL) simulator, Vivado™ Logic Analyzer, Vivado™ Simulator, System Generator™, etc. In some cases, the simulation objects108may correspond to circuits, buses, clocks, and/or any other type of object that may be part of a design to be simulated, and may be implemented using Verilog, SystemVerilog, VHDL, or any other HDL. Verilog is a HDL used to model electronic systems. VHDL is a hardware description language used in electronic design automation to describe digital and mixed-signal systems such as field-programmable gate arrays and integrated circuits. VHDL may also be used as a general purpose parallel programming language in some cases. SystemVerilog is a combined HDL and hardware verification language based on extensions to Verilog. In other cases, the simulation objects108may correspond to elements of a physical circuit, as captured by circuit-testing hardware. For example, a circuit debugging tool (e.g., Vivado™ Logic Analyzer) may insert probes into a circuit on a chip that is positioned on a development board. The probes connect circuit elements to ports on the chip in such a way that the waveforms on the circuit elements may be captured from a processing unit, such as a computer, connected to the chip. In this example, simulation objects108may be software representations of the circuit elements to which the probes are connected.

The memory buffer110is coupled between the simulator106and the packet processing module112. The memory buffer110is configured to receive simulation data from the simulator106, and transmit the simulation data to the packet processing module112. In some cases, the memory buffer110may be a circular buffer. In other cases, the memory buffer110may be other types of buffer. In further cases, the memory buffer110is optional, and the waveform simulation system100may not include the memory buffer110. In such cases, the simulation data from the simulator106may be transmitted to the packet processing module112directly or through another component of the waveform simulation system100.

The packet processing module112is configured to receive the simulation data from the memory buffer110or from the simulator106, process the simulation data, and transmit the processed simulation data for storing in the waveform database114. In some cases, the simulation data may be partitioned and buffered before being stored in the waveform database114.

In some cases, the packing processing module112may also transmit the simulation data to the waveform viewer116for viewing by a user of the waveform viewer116. The transmission of the simulation data to the waveform viewer116may occur simultaneously with, before, or after, the transmission of the simulation data for storage at the waveform database114. In some cases, the packet processing module112is configured to organize the simulation data into one or more B-trees or other type of data structure. This may allow for easy retrieval and/or transmission of the simulation data. For example, a user may request to view a particular set of samples for a particular waveform, such as, waveform A between the sample times of 0 ns and 200 ns. By organizing the simulation data in a B-tree, simulation data corresponding to the requested set of samples may be quickly retrieved and displayed.

The waveform viewer116may include any type of program that can be used to display a simulated waveform to a user. In some cases, the waveform viewer116is configured to process signals from the packet processing module112, and to generate output signals for viewing by the user. The waveform viewer116may include a display for displaying information. Also, in some cases, the waveform viewer116may provide a user interface for allowing a user to enter input (e.g., commands). The user input is processed by the waveform viewer116, and is then transmitted by the waveform viewer116to the packet processing module112, which performs processing based on the user input. By means of non-limiting examples, the user input may be one or more commands for instructing a probing of the waveform being simulated, for changing values of one or more of the simulation objects108, etc., or a combination of the foregoing.

The simulation data stored in the waveform database114may be any data generated by the simulator106, and/or any data derived from the output of the simulator106, and/or any data derived from the output of the packet processing module112. In some cases, the simulation data stored in the waveform database114may include debugging data (DBG)120, event data122, and run-time type information (RTTI)124.

The DBG120contains data describing the structure of the design that the waveform simulation data is being generated for. These may include information on the circuits, signals, and probes of the design.

The event data122contains data on the actual event(s) returned by the simulation performed by the simulator106. For example, the event data122may indicate that a value of a particular signal (e.g., signal A) has changed (e.g., to value N) at a particular time (e.g., time T) in an event. In some cases, the DBG120may include mappings that map the design objects108to one or more addresses in a memory. This allows the event data122for the different design objects108to be in a format that is independent of the specific implementation of the design objects being simulated, and to be instead generically associated with addresses within the memory. Formats for storing events will be described in detail below.

The RTTI124defines the kind of values that design objects listed in the DBG120can hold. Also, in some cases, the RTTI124may include information that describes for each object referenced in the DBG120, how to interpret the values associated with the addresses in the event data122. Thus, the information in the RTTI124enables the waveform viewer116to take the address-based raw binary data from the event data122in the database, and translate them into human-readable form. In further cases, the RTTI124lets the waveform viewer116know how to decode certain information, such as bit information, using a encoding scheme.

The waveform simulation system100may selectively operate in a “live” mode or a “static” mode. In the “live” mode, the waveform simulation system100runs a kernel process102and a front-end process104. In particular, the simulator106is configured to run the kernel process102in the “live” mode. In the kernel process102, the simulator106performs simulation(s) on one or more design objects. In some cases, the simulator106may be configured to receive an input from the waveform viewer116, which provides the input in response to a command input by a user of the waveform viewer116. For example, a user may operate the waveform viewer116to change the values of one or more simulation objects, and/or to change a parameter associated with the simulation(s) to be performed by the simulator106. The simulator106then changes or updates simulation(s) and/or the design object(s) being simulated based on the input from the waveform viewer116. Simulation data obtained through the kernel process102are passed from the simulator106to the packet processing module112, which then performs in the front-end process104. In the illustrated example, the simulation data are passed from the simulator106to the packet processing module112through a circular buffer110. In other cases, the simulation data may be passed to the processing module112directly, or through another component.

In the “static” mode, the simulator106of the waveform simulation system100does not perform any simulation (FIG. 2). Instead, in the “static” mode, a user enters a command at the waveform viewer116, requesting one or more signals or waveforms for viewing by the user. The waveform viewer116then transmits the request to the waveform database114in response to the command. In some cases, the request may also specify a particular time or sample range for viewing. After the request from the waveform viewer116is received by the waveform database114, the waveform database114then accesses mappings to determine which addresses in memory to which the signals or waveforms specified by the request correspond. In some cases, data stored in the waveform database114may contain information on the objects of the simulations, and includes mappings that map simulation objects to memory address locations. In such cases, the accessing of the mappings may involve accessing such data (e.g., DBG120) that includes the mappings. Once the waveform database114determines the memory addresses, event data122corresponding to those memory addresses are retrieved from the waveform database114. In some cases, only the event data122that fall within the specified time/samples associated with the request are retrieved. In other cases, all event data122associated with the addresses are retrieved. In some cases, the retrieved event data122may be first used to construct one or more B-trees118or other types of data structures prior to being sent to the waveform viewer116for viewing by the user.

The waveform simulation system100may be implemented on one or more computing devices, such as one or more personal computers, one or more workstations, one or more laptops, one or more tablet devices, etc., or a combination thereof. In some cases, the kernel process102may be run on a first computing device, while the front-end process104may be run on a second computing device. In some cases, the waveform database114may be located on a database system separate from the computing devices that run kernel process102and the front-end process104.

FIG. 3-1illustrates an example of a format for data300stored in a waveform database. The data300may be an example of a simulation data stored in the waveform database114in the waveform simulation system100ofFIG. 1. As shown inFIG. 3-1, the data300comprises a header302, a table of contents (ToC)304, and a plurality of sections306. In some cases, the data300is in the form of a block-based file or a binary file. In other cases, the data300may be in other forms.

In some cases, the header302may be used to identify which application (e.g., simulation tool) was used to write the data300. The header302may also contain a version identifier and/or an indication of whether the file is valid or not (e.g., an isValid Boolean flag). In some cases, the version identifier in the header302may be used by a waveform viewer (e.g., the waveform viewer116) to determine how to read the contents of data300.

The ToC304is configured for use to identify and locate the various sections306of data300for reading and for performing operation on. In some cases, the ToC304comprises an array containing section descriptions of the different sections306in the data300. Each section description may contain an ID string for the respective section306, a format version of the respective section306, and/or any file/data offsets in the respective section306.

The sections306of the data300may include DBG308, waveform configuration information (WCFG)310, run-time type information (RTTI)312, streaming information314, and event data316. In the illustrated example, the DBG308and RTTI312are separate sections. In other cases, the DBG308and RTTI312may be combined into one section. It should be noted that the data300is not limited to the examples of the sections306. In other cases, the data300may include one or more additional section(s). In further cases, one of more of the sections306are optional, and the data300may not include all of the sections306.

The DBG308contains information on the design objects for the simulations, and includes mappings that map simulation design objects to memory address locations. The mappings allow for command (requesting particular signals and waveforms) received from the waveform viewer116to be used to retrieve events data316associated with memory addresses associated with the requested signals and waveforms.

WCFG310may comprise data that, when loaded by a waveform viewer, specifies which signals are to be displayed. The WCFG310may also include information indicating how waveform data are to be packaged for presentation to a user. In some cases, WCFG310may be in the form of an XML file. In other cases, WCFG310may be in other forms. The data300may contain multiple WCFGs310, wherein each WCFG instructs a waveform viewer to load a specific set of signals. Also, in some cases, when a user requests that a waveform database file be opened, the waveform viewer may automatically present one window for each WCFG.

RTTI312and streaming information314include information that are specific to certain waveform simulation tools, such as Vivado™ Logic Analyzer, Vivado™ Simulator, and System Generator™, etc. In some cases, RTTI312defines the kind of values that design objects listed in the DBG308can hold. For example, a clock signal in the DBG308may be listed as having a type ID of 10. The RTTI312may map the type ID of 10 to “single bit of Verilog logic”. In this example, when the waveform viewer accesses the RTTI312, it can then determine that the type ID of 10 in the DBG308means “single bit of Verilog logic”. In another example, a signal may be listed in the DBG308as having a type ID of 11. The RTTI312may map the type ID of 11 to “2-D array of VHDL std_logic”. In this example, when the waveform viewer116accesses the RTTI312, it can then determine that the type ID of 11 in the DBG308means “2-D array of VHDL std_logic”. Also, in some cases, the RTTI312may include information that describes for each object referenced in the DBG308, how to interpret the values associated with the addresses in the event section306. Thus, the information in the RTTI312enables the waveform viewer116to take the address-based raw binary data from the event section306in the database, and translate them into human-readable form. In further cases, the RTTI312lets the waveform viewer116know how to decode certain information, such as bit information, using a encoding scheme. Examples of encoding/decoding scheme will be described with reference to Table 1 and Table 2 below.

The streaming information314includes host-specific data. For example, the streaming information314may include data that is specific to certain application in the simulator106, in a debugging application, or in a waveform viewer. In other cases, a simulator may not have a need to, and may not, store host-specific data. Also, in other cases, a hardware debugging application (e.g., Vivado™ Logic Analyzer) may store application specific (e.g., Vivado™ Logic Analyzer-specific “probe”) information as the streaming information314. Thus, the section of the waveform database file format for streaming information314allows the waveform database file format to be flexible enough so that a host application may insert any kind of data of any length into the waveform database file for later retrieval, without requiring changes to the waveform database file format itself. In some cases, the waveform database format may have multiple sections for storing streaming information314.

Event data316includes event information generated by the simulator106. In some cases, the packet processing module112is configured to translate simulation data (which includes the event information) received from the simulator106into translated simulation data that is independent of implementation details of the one or more design objects for storage in the waveform database114. In such cases, the translated simulation data includes the event data316. The event data316may represent one or more events that correspond to changes in a signal or waveform associated with a simulation. The event(s) may correspond to addresses with an addressable memory space, instead of specific design objects of a simulation. This allows for events to be expressed independently of simulation tools, HDLs, and sampling schemes.

In some cases, the events represented by the event data316are organized into a plurality of buckets, allowing for event data associated with certain memory addresses to be retrieved more quickly.FIG. 3-2illustrates a bucketing scheme for organizing event data316. As shown in the figure, the bucketing scheme involves a plurality of buckets318. In some cases, each of the buckets318may correspond to an address range. For example, bucket318with bucket identification “bucket_0” may correspond to addresses between 0 and 99, bucket318with bucket identification “bucket_1” may correspond to addresses between 100 and 199, etc.

As shown inFIG. 3-2, as event data320are received over time, they may be placed into the buckets318based upon the addresses that they are associated with. Each of the buckets318may comprise a linked list or other data structure for retrieving the event data stored in the respective bucket318without having to traverse through event data associated with other buckets318. For example, a linked list for bucket_1 may be used to traverse from a first event associated with bucket_1 to a second event associated with bucket_1. This may be achieved without having to traverse through events associated with bucket_0 and bucket_2, even in the case in which the buckets bucket_0 and bucket_2 may contain events received chronologically between the events for bucket_1. It should be noted that the data structure for retrieving the event data in the bucket318is not limited to a linked list, and that other data structures may be used. By means of non-limiting examples, the data structure in each bucket318may be a b-tree, an unrolled list (combination of array and linked list), or any of other types of data structure.

For ease of explanation, the event data stored in the waveform database114may be expressed in the following format: “@t:addrN=V,” wherein t corresponds to a time or sample, N corresponds to a memory address, and V corresponds to a value that the memory at the address was set to. The stored event data may correspond to time-based simulation data, clock-based simulation data, or sample-based simulation data. In some cases, the simulation data using one kind of sampling may be converted to another kind of sampling for generating the event data. For example, clock-based data may be converted to time-based data. In such cases, the clock-based data, time-based data, or both, may be stored in the waveform database114as event data. In some cases, an event may refer to, or may be represented by, a range of addresses. For example, event data @0 ns: addr03-05=00 01 02 corresponds to an event occurring at 0 ns, where addresses 03, 04, and 05 are set to the values 00, 01, and 02, respectively).

As shown in the above example, the event data are stored in a format that is independent of simulation implementation details, such as HDL, circuit debugging probes, etc., such that they are not type specific. This is because the event data uses memory address(es) to represent events, and the memory addresses may store data that is independent of simulation implementation details. For example, the memory addresses referenced in the event data may be used to store Verilog bits, VHDL bits, or bits for other types of HDLs. In other cases, the memory addresses referenced in the event data may be used to store non-HDL data representations, such as Vivado™ Logic Analyzer probe data. Accordingly, any type of event that can be represented using one or more memory addresses may be created and stored in the waveform database114independent of the types of simulation.

Although a particular format for the event data is described above, it is understood that the event data are not restricted to this particular format, and that any alternative format may be used.

FIG. 4illustrates a system400for storing and retrieving data. The system400may be used to implement a portion of the waveform simulation system100ofFIG. 1. As shown inFIG. 4, the system400includes a host application402that writes data to the waveform database406through an application programming interface (API)404. The host application402may be a waveform simulation tool such as Vivado™ Simulator or Vivado™ Logic Analyzer, or any other type of application capable of producing or providing waveform simulation data for one or more design objects. In some cases, the API404may be implemented as a part of the packet processing module112illustrated inFIG. 1. In other cases, the API404may be implemented as an alternative to the packet processing module112inFIG. 1. Also, in some cases, the host application402may be a part of the simulator106illustrated inFIG. 1, the waveform database406may be an example of the waveform database114ofFIG. 1, and the waveform viewer408may be an example of the waveform viewer116ofFIG. 1.

In the illustrated example, the API404is configured to convert event data received from host application402into a format (e.g., the event format described above) usable for storage of the data by the waveform database406. Thus, API404may be used to receive data from multiple different types of host applications having different data formats (e.g., some host applications may return sampling based data, while other host applications return clock cycled based data), to be converted into a common format stored on WDB406. In addition, the API404may be configured to receive, from the host application402, mappings that map (1) host-defined design objects to addresses and (2) host-defined design objects to data types, and store them in DBG412and RTTI416, respectively. In the illustrated example, the DBG412and RTTI416are shown as separate sections. In other cases, the DBG412and RTTI416may be combined into a single section.

For example, in some cases, design objects may be implemented in Verilog, VHDL, or any other type of HDL.FIG. 5-1illustrates an example of a Verilog bus in memory. A Verilog bus having four-value logic up to 32 bits is represented by two 32 bit (or 4 byte) sections of memory. For example, the two 32 bit sections may include a first 4-byte section containing bits A0through A31, and a second 4-byte section containing bits B0through B31. The A and B values are binary values, which when combined may be used to determine the value of a corresponding bus bit as illustrated in Table 1 below. In Table 1, “X” corresponds to conflict, and “Z” corresponds to high impedance. For instance, a 3-bit Verilog bus may be represented in memory by two 4-byte sections, each comprising 3 data bits (corresponding to A and B) and29trailing zeroes, as illustrated inFIG. 5-2.

On the other hand, VHDL may use a nine-value logic system, and each VHDL bit corresponds to a byte in memory. Table 2 below illustrates how a byte in memory may correspond to a value of a VHDL bit.

It is appreciated that although Verilog and VHDL are used in the above examples, design objects in a simulation may be implemented with other types of HDLs and be processed by the API404. In addition, in other cases, the API404may process other third party API schemes having other types of bit logic.

Returning toFIG. 4, in some cases, the simulation data are processing by the API404, and are stored in the waveform database406after being processed by the API404. As described above, in the some cases, the simulation data may include DBG412, which includes information regarding the design objects and mappings that map the design objects to memory addresses. The simulation data may also include RTTI416, which includes mappings that map the design objects to data types. Also, the simulation data may include event data414, which include information regarding the actual changes in the signals during simulation.

During use of the system400, a user at the waveform viewer408may send requests to the waveform database406in order to view stored simulation data. In response to the requests, the waveform database406then retrieves the requested simulation data, and transmits them for presentation to the user through the waveform viewer408. In some cases, the waveform viewer408may interface with a memory formatter410, which is configured to format raw event data from the waveform database406such that the even data can be presented to the user at the waveform viewer408. In the illustrated example, the memory formatter410is illustrated as a separate component from the waveform viewer408and the waveform database406. In other cases, the memory formatter410may be a part of the waveform viewer408, or a part of the waveform database406. Also, in other cases, the memory formatter410may be coupled between the waveform database406and the waveform viewer408.

FIG. 6illustrates examples of event data being stored in a memory cell600over time. The event data may be an example of the event data122,316,414referenced previously. In the illustrated example, the memory cell600comprises an array of memory addresses, each corresponding to one byte, although it will be understood that any other addressable memory scheme may be used. At 0 ns, address 11 of memory cell600is set to a value of “25,” while address 04 is set to 9C. At 100 ns, address 42 is set to a value of 3F, while at 200 ns, addresses 31, 32, and 33 are set to 00, 01, and 02, respectively. Thus, for the time between 0 ns and 200 ns, the waveform database will have stored the following event data:

Because the event data stored in the waveform database are independent of implementation details (such as the design object that originated the event, the HDL that the design object was implemented in, etc.) of the design objects, mappings in the waveform database that map one or more design objects with one or more addresses are used to identify the relevant events when a user requests to view a particular signal or waveform. Table 3 below illustrates an example of waveform database format for mapping design objects in a simulation to addresses. The mapping shown in the example of Table 3 may be considered an example of DBG120/308/412. DBG contents.

In the above examples, a first design object (with type “VHDL std_logic” in the example) is mapped to address 21, and a second design object (with type “Verilog bus” in the example) is mapped to address 40. The DBG may specify for each design object a scope and/or name of the object, an object type (which, for example, may identify the HDL that the object was implemented in), the memory address of the object, and the length for the object in memory. For example, Table 3 illustrates a 1-bit VHDL clock mapped to address 21 of memory, and a 3-bit Verilog bus mapped to address 40 of memory. In accordance with the VHDL and Verilog formats described above, the VHDL clock will occupy the byte associated with address 21 of memory, while the Verilog bus will occupy addresses 40-47 (8 bytes, or two 4-byte sections), with the first 3 bits of addresses 40-43 and 44-47 corresponding to bus data (seeFIG. 5-2). In some cases, the above mappings may be DBG120/308/412stored in the waveform database114/406.

It should be noted that the DBG120/308/412is not limited to the example shown in Table 3, and that the DBG120/308/412may have other formats and/or other information in other cases. As another example, the “Type” column in Table 3 may be replaced with a type ID. Using the above example, the type description “VHDL std_logic” may be replaced with type ID 15. In such cases, the RTTI124/312/416may including information (e.g., mapping) associating the type ID 15 with the type description (e.g., “VHDL std_logic”). The RTTI124/312/416may also include information (e.g., mapping) associating the type ID or the type description with a corresponding encoding scheme, such as that as shown in Table 2. In some cases in which the DBG412and RTTI416may be combined into a single section, all of these data may be included in Table 3 as parts of the DBG120/308/412.

As discussed, the information in the RTTI124/312/416enables the waveform viewer116to take the address-based raw binary data from the event data122in the database, and translate them into human-readable form. In some cases, the address-based raw binary data may be the values that addresses for the event data316can take on over the course of simulation time, such as those shown in the examples ofFIG. 6. Suppose the event data316contains the following address-based raw binary data:@100 ns: 40=02. From the example of Table 3, the waveform viewer can tell that this address corresponds to the design object/top/out/bus. However, without the RTTI information, the waveform viewer would not be able to tell what the value 02 means. Following the above example, the RTTI tells the waveform viewer that it's a Verilog bus, which means that the value at address 44 is also necessary because such object address has a 3 bit length. In this example, the address value for the address 44 may be assumed to be 00. Using these information, together with the information in the example of Table 1 for Verilog encoding, it can be determined that the 02 value is the A value, and that the 00 value is the B value, which should be interpreted as the 3-bit pattern “010.”

In another example, the DBG120/308/412in the above example shown in Table 3 may have the following format shown in Table 4, and the RTTI may have the following format shown in Table 5.

In this example, the “/top/out/bus” object is illustrated as having object type ID 2. Looking at type ID 2 in the RTTI table, we see that it is a 1-D array whose elements are of type ID 3, which is an enumeration. An enumeration is a fixed set of named values (also called enumerators). In some cases, when conversion to human-readable format is performed, binary values from the event data316are translated to these enumerators.

Also, in the above example, the “Value encoding” column in the RTTI table indicates how the memory values from the event data316are to be interpreted. “1 value per byte” means to assign each enumerator a byte value, starting with 00 for the first enumerator. As such, a byte value of 03 indicates the fourth enumerator. In this example, Type ID 1 is defined in such a way that it corresponds to the standard VHDL logic encoding, thereby matching the example of Table 2 described previously.

In addition, in the above example, “A value/B value” refers to the encoding style ofFIG. 5-1. This encoding indicates that one bit each should be taken from the A word and B word and combined, giving a combined value in the range of binary 00 to 11 (or decimal 0 to 3). That combined value is then used to choose one of the enumerators. Because there are 4 possible combined values, an enumerator using this encoding can define a maximum of 4 enumerators. In this example, Type ID 3 is defined in such a way that it corresponds to the standard Verilog encoding of Table 1 described previously.

It should be noted that while RTTI itself may not be HDL-specific, an HDL simulator may construct HDL types in terms of RTTI types. Also, in some cases, the API404may define its own RTTI types that are similar to, but distinct from, HDL types. Table 6 shows one example of this scenario.

In the above example, through the API404, the host application402may define design objects that are “bits” having type ID 1. The host application402may also define 1-D arrays (e.g., busses), having type ID 2. The enumerator list for a “bit” is similar to that of Verilog. The encoding is similar to VHDL, in that the enumerators are assigned byte values starting from 00 for the first enumerator “0.”

As illustrated in the above example, in some cases, the host application402may provide its own RTTI for storage in the waveform database. In some cases, the simulator106may not be a host application. In such cases, the simulator106may provide its own RTTI directly to the waveform database. For example, with reference toFIG. 1, in some cases, the simulator106may provide RTTI124directly to the waveform database114for storage. In other cases, the simulator106may provide RTTI information to the packet processing module112, which processes the RTTI information to obtain RTTI124for storage in the waveform database114.

FIG. 7illustrates a method700of processing simulation data. In some cases, the method700may be performed using the waveform simulation system100ofFIG. 1. In other cases, the method700may be performed by other types of waveform simulation system, or by waveform simulation system having a different configuration from that ofFIG. 1. In further cases, the method700may be performed by a waveform analyzer. For ease of explanation, the description will refer to the examples of design objects illustrated in Table 3 above. However, it should be understood that the method700may apply to any types of design objects.

At item702, mappings are obtained that map design objects to addresses in memory. For example, as indicated in Table 3 above, a VHDL clock is mapped to address 21 of memory, and a 3-bit Verilog bus is mapped to address 40 of memory. These mappings may be stored as DGB data and/or RTTI data in a waveform database (e.g., the waveform database114ofFIG. 1). In some cases, the mappings may map at least one object implemented using a first type of data encoding, and at least one object implemented using a second type of data encoding that is different from the first type. For example, the mappings may map a first object in Verilog, SystemVerilog, HDL (e.g., VHDL), or a non-HDL data format. The mappings may also map a second object in Verilog, SystemVerilog, HDL (e.g., VHDL), or a non-HDL data format, but having a format type that is different from that of the first object.

Next, at item704, simulation data are received. In some cases, the act of receiving the simulation data may be performed by the packet processing module112that receives the simulation data from the simulator106. Also, in some cases in which the packet processing module112includes the API404, and in which the simulator106includes the host application402, the act of receiving the simulation data may be performed by the API404that receives the simulation data from the host application402. In other cases in which the API404is implemented as an alternative to the packet processing module112, the act of receiving the simulation data may be performed by the API404. In some cases, the simulation data may indicate certain events associated with the simulation performed by the simulator106. For example, the simulation data may indicate that at time 0 ns, the clock value is set to 1, and the bus value is set to 0, while at 100 ns, the clock value is set to 0, and the bus value is set to 2. Thus, the simulation data may be design object-specific, and may correspond to a change in a signal associated with a certain design object being simulated.

Next, at item706, the simulation data is translated. It should be noted that the term “translate” or any of other similar terms, may refer to any processing of data. Also, a translated data may include more information, fewer information, different information, or the same information but in a different format, compared to the original data before the translation. In some cases, the packet processing module112may function as a translator that translates the simulation data based at least in part on the mappings obtained at item702. In other cases in which the packet processing module112includes the API404, the API404may function as a translator that translates the received simulation data. In some cases, the processing module112/API404may be configured to translate the simulation data into a common format based upon the HDL used to implement the design objects, as well as the mappings that map the design objects to the memory addresses. For example, the processing module112/API404may convert the above-described events indicated by the simulation data into the following:

Thus, as shown in the above example, the simulation data may be translated into translated simulation data so that it is not design object-specific. In particular, as shown in the above example, the translated simulation data comprises a time value, a memory address identifier, and a signal value, none of which indicates implementation details of the design objects. Thus, the translated simulation data has a format that is independent of an implementation detail of the design object. In some cases, the translated simulation data may be considered event data because they indicate events at certain time points. Also, as shown in the above example, the translated simulation data corresponds to a change in a memory value having an address that is mapped to certain design object based on the mapping.

Once the simulation data have been translated into a format that is independent of the design object being simulated, they are then stored into the waveform database (item708).

After the translated simulation data are stored in the waveform database, the simulation data may be retrieved.FIG. 8illustrates a method of retrieving simulation data from a waveform database.

At item802, a request is received by the waveform database to retrieve a waveform of simulation data. The waveform database may be the waveform database114ofFIG. 1or the waveform database406ofFIG. 4, for example. The request may be generated based on a request by a user entered at a waveform viewer (e.g., the waveform viewer116ofFIG. 1or the waveform viewer408ofFIG. 4). In some cases, the request is sent by a waveform viewer116/408automatically in response to a user specifying a particular simulation to view. Using the above example, a user may request to view the waveform stored for the 3-bit Verilog bus. In other examples, the user may request to view waveform associated with other design object(s). Also, in some cases, the request from the waveform viewer may include a sample range or a time range associated with the requested waveform.

At item804, one or more addresses are identified that correspond with the requested waveform using mappings stored in the waveform database. In some cases, the one or more addresses may be identified based at least in part upon one or more mappings that map one or more design objects associated with the waveform with one or more memory addresses. For example, in some cases, the mappings may be indicated by the DBG120/308/412stored in the waveform database114/406. Thus, in some cases, the act of identifying the address(es) may include accessing DBG120/308/412in the waveform database114/406. Following the above example, the mappings from the DBG120/308/142may be used to identify addresses 40 through 47 as corresponding to the 3-bit Verilog bus. In other examples, the mappings may be used to identify address(es) for other design object(s).

Also, in some cases, the act of identifying the one or more addresses may be based at least in part upon a type of data encoding (e.g., a type of HDL) used to implement one or more design objects associated with the requested waveform. For example, in some cases, the mappings may map one or more design objects with one or more memory addresses based on the type of HDL used to implement the one or more design objects. In such cases, when the mappings are accessed, certain memory addresses may be identified based on the type of HDL used to implement one or more design objects associated with the requested waveform.

In some cases, the identifying of the address(es) in item804may be performed by the waveform database114/406. In other cases, the identifying of the address(es) in item804may be performed by the waveform viewer116/408. In further cases, the identifying of the address(es) in item804may be performed by the memory formatter410.

At item806, one or more event data are determined based on the identified address(es). Following the above example, the event at time=0 ns has value 00 for address 40, the event at time=0 ns has value 00 for address 44, and the event at time=100 ns has value 02 for address 40, based on the following simulation data retrieved from the waveform database:

As shown in the above example, the waveform database stores the event data in a format that is independent of implementation detail of the one or more design objects. In some cases, the determining of the event data in item806may be performed by the waveform database114/406. In other cases, the determining of the event data in item806may be performed by the waveform viewer116/408. In further cases, the determining of the event data in item806may be performed by the memory formatter410.

At item808, the event data are processed for presentation to a user. In some cases, a memory image may be constructed for each time specified in the retrieved events.FIG. 9illustrates memory images900constructed for the times (e.g., 0 ns and 100 ns) specified in the above examples of the events. At time 0 ns, addresses 40 and 44 have value of 0. However, at time 100 ns, address 40 has a value of 02, while address 44 has a value of 0. In the illustrated example, the memory addresses 40-47 are for the waveform corresponding to the design object (the 3-bit Verilog bus in the above example). Therefore, the memory images900include memory addresses 40-47. In some cases, the memory images are translated into a displayable format to be viewed by the user. In other cases, event data for individual addresses may be translated into a displayable format directly, without the construction of memory images900. In some cases, the processing of the event data in item808may be performed by the waveform viewer116/408. In other cases, the processing of the event data in item808may be performed by the memory formatter410. In further cases, the processing of the event data in item808may be performed by the waveform database114/406.

Also, in some cases, the act of processing the event data in item808may include creating one or more data structures using the one or more events. In some cases, the purpose of the data structure(s) is to collect all of the events relevant to a single address, a single design object, a single waveform, or any combination of the foregoing. The data structure(s) may be any type of data structure. For example, the data structure(s) may be B-tree(s). In such cases the waveform viewer116/408may use information in the B-tree(s) to present information to the user.

Also, in some cases, the act of processing the event data may include accessing the mappings that map one or more design objects to the one or more memory addresses. For example, the DBG120/412indicating the mappings may be accessed, and the mappings may be used to determine the design objects to which the event data corresponds. In some cases, the accessing of the mappings may be performed by the waveform viewer116/408. In other cases, the accessing of the mappings may be performed by the memory formatter410. In further cases, the accessing of the mappings may be performed by the waveform database114/406. In one implementation, the memory formatter410may obtain memory images (e.g., the memory images illustrated inFIG. 9) and information regarding the design object(s) to which the memory images belong based on the mapping(s). Following the above example, the memory formatter410may determine, based on the mapping(s), that the memory images is for a Verilog bus, and that the bus has a value of “0” at 0 ns, and a value of “2” at 100 ns.

In some cases, the memory formatter410may additionally send instructions to the waveform viewer116/408on how to prepare (e.g., construct) the waveform. For example, the waveform may be constructed in a first way if sample-based viewing is desired, and it alternatively may be constructed in a second way if clock-based viewing is desired. The user is thus able to selectively view the waveform on the waveform viewer116/408in different formats.