Efficient waveform generation for simulation

Abstract

Embodiments of the present disclosure relate to efficient waveform generation for simulation. A simulation environment includes a host system and a simulator. The host system configures the simulator to simulate a design under test (DUT), and the simulator thereby simulates the DUT. During simulation, the simulator tracks limited signals of the DUT and stores the values ​​of the tracked signals. When the values ​​of certain signals of the DUT are needed for analyzing or verifying the DUT but the signals are not tracked by the simulator, the host system simulates one or more sections of the DUT to obtain the values ​​of the signals. The signals tracked by the simulator are used as inputs for simulating one or more sections.

Description

[0001] This application is a divisional application of the Chinese patent application with application date of February 4, 2016, application number 201680024377.8, and invention name “Efficient Waveform Generation for Simulation”. Technical Field

[0002] The present disclosure relates generally to simulation of circuits and, more particularly, to obtaining simulation results. Background Art

[0003] Simulators have been developed to assist circuit designers in designing and debugging highly complex integrated circuits. Simulators include multiple reconfigurable components, such as field programmable gate arrays (FPGAs), that together can mimic the operation of a design under test (DUT). By using a simulator to mimic the operation of a DUT, designers can verify that the DUT meets various design requirements before manufacturing.

[0004] One aspect of simulation includes simulating DUT and retrieving simulation results from simulator. The simulation results can be analyzed to verify, for example, the timing relationship and digital logic operation of DUT. In one approach, the simulation results are transmitted to another system for analysis. For example, the waveform of the simulation result is generated at another system to graphically represent the timing relationship and digital logic operation of DUT. In advanced processes (e.g., 22nm and below), DUT can include billions of logic circuits and signals. Simulating such a complex DUT involves transmitting extremely large amounts of data including the states or values ​​of billions of signals from simulator to another system in a large number of cycles. Therefore, conventional simulation environments are inefficient in terms of hardware and communication resources for transmitting data without slowing down the simulator system. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Other advantages and features of the disclosed embodiments will become more apparent from the detailed description, the appended claims and the accompanying drawings (or figures).

[0006] Figure 1 is a block diagram of a simulation environment according to one embodiment.

[0007] Figure 2 An example of a simulation environment with an example circuit of a DUT according to one embodiment is illustrated.

[0008] Figure 3 is a block diagram of a host system according to one embodiment.

[0009] Figure 4 is a flow diagram illustrating a host system preparing a DUT for simulation according to one embodiment.

[0010] Figure 5is a flow chart of configuring a host system and a simulator for tracing signals of a DUT according to one embodiment.

[0011] Figure 6 One embodiment of components of an example machine capable of reading instructions from a machine-readable medium and executing them in a processor (or controller) is illustrated. DETAILED DESCRIPTION

[0012] By way of illustration only, the drawings and the following description relate to preferred embodiments. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily identified as viable alternatives that can be employed without departing from the principles claimed.

[0013] Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying drawings. The accompanying drawings depict embodiments of the disclosed systems (or methods) for illustrative purposes only. It should be appreciated from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

[0014] The same reference numerals are used in the drawings to identify the same elements. A letter following a reference numeral, such as "230A," indicates that the text refers specifically to the element with that particular reference numeral. A reference numeral in the text, such as "230," without a subsequent letter, refers to any or all of the elements in the drawings bearing that reference numeral.

[0015] Overview

[0016] The disclosed simulation environment performs bandwidth and resource efficient analysis on a design under test (DUT). An embodiment of the simulation environment includes a host system and a simulator. The host system configures the simulator to simulate the DUT, and the simulator thus simulates the DUT. During simulation, the simulator tracks limited signals of the DUT and stores the values ​​(e.g., states) of the tracked signals. In one embodiment, the tracked signals include multiple cycles of the DUT. When the values ​​of certain signals of the DUT need to be used to analyze or verify the DUT, but the signals are not tracked by the simulator, the host system determines one or more sections of the DUT that allow tracking signals and simulates those sections to generate untracked signals (e.g., which include one or more cycles). The signals tracked (i.e., simulated) by the simulator are used to simulate one or more sections. Therefore, by being able to simulate the sections of the DUT by the host system, the host system can obtain the values ​​of additional DUT signals, and the simulator can track fewer signals. Further, since the simulator tracks fewer signals, the values ​​of fewer signals are exchanged between the simulator and the host system, thereby achieving communication bandwidth savings. Additionally, the solution is very scalable. Since the required signals can be balanced by analog calculations, the solution is not affected by the DUT becoming larger and more complex. For example, fewer signals can be traced and more can be calculated by simulation.

[0017] Simulation in this context refers to emulating the behavior of an electronic design with configurable hardware components.

[0018] Simulation in this context refers to the use of software models to mimic the behavior of an electronic design.

[0019] A signal herein refers to, but is not limited to, a net, line, variable, port, or element of a design that has a value that is carried, monitored, or tracked.

[0020] Tracking / generating a signal herein refers to obtaining the value of a signal based on a simulation or emulation of an electronic design. Further, when referring to a signal herein, it refers to a signal or a value of a signal in an electronic design.

[0021] Simulation Environment

[0022] Figure 1 1 is a block diagram illustrating a simulation environment 100 according to one embodiment. The simulation environment 100 includes a simulator 110 and a host system 120. The simulator 110 and the host system 120 communicate through an interface 115.

[0023] Interface 115 is a communication medium that allows communication between host system 120 and emulator 110. In one embodiment, interface 115 is one or more cables with electrical connections. For example, interface 115 can be one or more RS232, USB, LAN, optical, IEEE 1394 (FireWire) or custom cables. In another embodiment, interface 115 is a wireless communication medium or network with one or more access points. For another example, interface 115 can be a wireless communication medium using Bluetooth or IEEE 802.11 protocol. In one embodiment, interface 115 is enabled during operation of host system 120 and emulator 110. In one embodiment, interface 115 is enabled only when host system 120 and emulator 110 need to exchange information with each other.

[0024] The simulator 110 is a hardware system that simulates a design under test (DUT). The DUT includes one or more circuit designs. The simulated DUT can be combinatorial, sequential, or a combination of both. The simulator 110 includes multiple field programmable gate arrays (FPGAs) 220, which can be configured to simulate the DUT. Each FPGA 220 includes a trace memory 290 (e.g., a trace cache) that stores the values ​​of signals traced by the FPGA 220 during simulation (e.g., the state of the DUT signal during simulation). In other embodiments, the simulator 110 includes other types of configurable logic circuits instead of FPGAs 220. In other embodiments, the simulator 110 includes one or more trace memories 290 separate from the FPGA 205, wherein multiple FPGAs 220 can use the one or more trace memories 290 to store data. In other embodiments, the simulator 110 includes a mixture of FPGAs 220 or other configurable circuits and a mixture of memories located in the components or separate from them in order to implement an optimal trace system. In another embodiment, the simulator 110 does not include memory dedicated to tracing, and uses memory that can be used to model the design, or streams the traced data directly through the interface 115. After the simulation is completed or during the simulation, the simulator 110 can transmit the values ​​of the traced signals stored in the one or more trace memories 290 to the host system 120. The simulator 110 can also transmit the values ​​of the traced signals stored in the one or more trace memories in response to receiving a request from the host system 120 or before receiving a request from the host system 120. The values ​​of the traced signals transmitted by the simulator 110 to the host system can span multiple DUT cycles.

[0025] For a DUT to be simulated, the simulator 110 receives one or more binary files including a description of the DUT (e.g., a mapping of a gate-level or hardware description language (HDL)-level description of the DUT) from the host system 120 via the interface 115. The binary files describe the partitions of the DUT created by the host system 120 and the mapping of each partition to the FPGA 220. Based on the binary files, the simulator 110 configures each FPGA 220 to simulate the partition of the DUT mapped (assigned) to it, and to track certain signals in its corresponding partition. The FPGAs 220 collectively simulate the DUT. The values ​​of the signals tracked by the FPGAs 220 during simulation are temporarily stored by the FPGAs 220 in their trace memory 290 before being transmitted to the host system 120 via the interface 115. These signals, described below, are used to generate additional information and / or process the simulation results of the DUT.

[0026] The host system 120 configures the simulator 110 to simulate the design under test (DUT). The host system 120 can be a single computer or a collection of multiple computers. In an embodiment where the host system 120 is composed of multiple computers, the functions described herein as being performed by the host system 120 can be distributed among the multiple computers. The host system 120 can be indirectly connected to the simulator 110 through another device, a computer, or a network.

[0027] The host system 120 receives a description of the DUT to be simulated by the simulator 110 from a user. In one embodiment, the description of the DUT is in the form of a type of HDL, such as a register transfer language (RTL). The host system 120 creates a gate-level netlist based on the HDL description of the DUT. The host system 120 divides the DUT into a plurality of partitions using the HDL or gate-level netlist. The host system 120 maps (assigns) each partition to one or more FPGAs 220 included in the simulator 110. Together, the FPGAs 220 will simulate the DUT and track certain signals of the DUT.

[0028] The host system 120 creates a binary file that includes information to configure the FPGA 220 based on the DUT and the mapping. The binary file may include, for example, a design description (e.g., a gate-level or HDL description) of one or more partitions, mapping information (e.g., a mapping of the partitions), connection information (e.g., connections between components of the DUT and / or connections between FPGAs), and design constraints for the DUT.

[0029] In addition, the host system 120 identifies a section of the DUT that is to be available for simulation by the host system 120. A section of the DUT may be a portion of a partition or encompass an entire partition. In one embodiment, the collection of sections encompasses the entire DUT. Alternatively, the collection of sections may encompass a portion of the DUT. In another embodiment, a section of the DUT may be a portion of multiple partitions that may be available for simulation. In one embodiment, at least one edge (e.g., a circuit or signal) of a section corresponds to an edge (e.g., a circuit or signal) of a partition. In another embodiment, any edge (e.g., a circuit or signal) of a section may not correspond to an edge (e.g., a circuit or signal) of a partition.

[0030] The segments of the DUT are identified so that, when necessary, the host system 120 can simulate the segments to obtain the values ​​of certain signals of the DUT segments that are not tracked by the simulator 110 during the simulation of the DUT. Therefore, although the simulator 110 simulates the segments of the DUT when simulating the DUT, the host system 120 can also simulate the segments to generate additional signals that are not tracked by the simulator 110. As an example, assume that the value of a certain signal is required to perform DUT analysis, but the signal is not tracked by the simulator 110 during the simulation of the DUT. The host system 120 can simulate the segments of the DUT including the signal to obtain the value of the desired signal (i.e., generate the signal). In one embodiment, the host system 120 identifies and simulates the segments for each additional signal that needs to be generated (i.e., simulated). In another embodiment, the host system 120 identifies and simulates a subset of the DUT signals or segments of the entire DUT signals that are not tracked by the simulator 110.

[0031] The host system 120 creates one or more segment files describing the circuitry of each identified segment. In one embodiment, a segment file is created for each identified segment. For example, the segment file may be the original HDL, a modified HDL derived from the original HDL, an HDL derived from a gate-level netlist, a gate-level netlist, a system C model, a C / C++ model, a binary representation, or any representation of the design that allows simulation of a portion of the behavior of the design based on a subset of signals. The host system 120 also generates signal information that describes the signals generated for each identified segment of the DUT when simulated by the host system 120 and the signals tracked for each partition when simulated by the simulator 110. For the segment, the signal information also describes which signals (or values ​​of signals) are needed to simulate the segment. The required signals may be signals tracked by the simulator 110 during simulation. In one embodiment, the signals tracked by the simulator 110 during simulation are inputs to the identified segment. The required signals may also be signals obtained from simulating one or more other segments. The host system 120 stores the generated signal information, as well as the segment and binary files.

[0032] The host system 120 transmits the binary file to the simulator 110 so that the simulator 110 can configure the FPGAs 220 to simulate their corresponding mapped partitions. The host system 120 instructs the simulator 110 to simulate the DUT. Each FPGA 220 simulates its corresponding partition and stores the values ​​of the signals traced during simulation in its trace memory 290. In one embodiment, when the FPGA is not simulating the DUT, the contents of the trace memory 290 are transmitted to the host system 120 by the simulator 110 through the interface 115. In another embodiment, the simulator 110 transmits the contents of the trace memory 290 to the host system 120 through the interface 115 while the FPGA 220 is simulating the DUT, thereby generating and transmitting the traced information flow through the interface 115 in parallel with the simulation of the DUT.

[0033] Further, the host system 120 receives a verification setup indicating values ​​of DUT signals required for performing analysis or verification of the DUT. The verification setup may be, for example, a request from a user to trace certain signals of the DUT for debugging or testing the DUT. The verification setup may also include a state machine for analyzing the performance of the DUT. The verification setup may include a system C model, a C / C++ model, a program or script to analyze the design simulation results.

[0034] Based on the received verification settings, the host system 120 identifies the values ​​of the signals of the DUT that need to be obtained for performing the DUT analysis. Based on the stored signal information, the host system 120 identifies the section of the DUT that provides the values ​​of one or more of the identified signals when the section is simulated. Additionally, the host system 120 determines which of the signals tracked by the FPGA 220 of the simulator are needed to simulate the identified section.

[0035] The host system 120 retrieves one or more stored section files describing the design of the identified section and simulates the identified section using the values ​​of the trace signals received from the simulator 110. The simulation of the identified section causes the host system 120 to generate the identified signals (e.g., including multiple cycles) required for performing the DUT analysis. In one embodiment, the host system 120 generates a user interface that includes one or more identified signals displayed as waveforms. In one embodiment, if certain signals required for simulating the identified section are not traced by the simulator 110, the host system 120 simulates one or more other sections to generate those signals.

[0036] By emulating sections of the DUT in the host system 120, the host system 120 is able to generate certain signals of the DUT instead of the emulator 110 having to trace those signals, thereby limiting the amount of signals traced by the emulator 110. Further, because there are fewer signals to trace by the emulator 110, the amount of signal values ​​exchanged between the host system 120 and the emulator 110 is also reduced, thereby reducing the bandwidth used to transmit the same amount of global information between the emulator 110 and the host system 120. In addition, the amount of logic that may be added in the design or during the design process to be traced and transmitted to the host system 120 is reduced.

[0037] Figure 2 An example of a simulation environment 100 with an example circuit of a DUT according to one embodiment is illustrated. In this example, the simulator 110 includes two FPGAs 220A and 220B. FPGA 220A includes a trace memory 290A, and FPGA 220B includes a trace memory 290B. Based on a binary file received from a host system 120, FPGA 220A is configured to simulate a DUT partition 270A consisting of sections 285A and 285B. Additionally, FPGA 220B is configured to simulate a DUT partition 270B consisting of sections 285C and 285D. Each FPGA 220 simulates its corresponding partition 270, and the values ​​of the signals traced during simulation are stored by the FPGA 220 in its trace memory 290. In this example, when FPGA 220A simulates partition 270A, signals 232, 234, and 236 of section 285A are traced and stored in trace memory 290A (additional signals for section 285B may be traced). In this example, each section 285 is implemented in its corresponding partition 270. Alternatively, sections 285 may be implemented across multiple FPGAs 220, such that a portion of section 285 is implemented in FPGA 220 and a portion of the same section 285 is implemented in one or more other FPGAs 220.

[0038] The host system 120 includes a segment file 280A describing a segment 285A, a segment file 280B describing a segment 285B, a segment file 280C describing a segment 285C, and a segment file 280D describing a segment 285D. Assume in this example that the values ​​of signals 233, 235, 237, and / or 238 of segment 285A are needed for analyzing the DUT (e.g., a trace is requested by a user of the host system 120). The host system 120 can retrieve the values ​​of the traced signals 232, 234, and 236 from the trace memory 290A and simulate the segment 285A using the segment file 280A and the retrieved values ​​of the signals 232, 234, and 236 as inputs. By simulating the segment 285A, the host system 120 can generate the signals 233, 235, 237, and 238. Therefore, even though segment 285A has been emulated by FPGA 220A, host system 120 will simulate segment 285A to obtain the values ​​of signals 233 , 235 , 237 , and 238 .

[0039] In another example, only the value of signal 237 is needed for analyzing the DUT, but the host system 120 still retrieves the values ​​of traced signals 232, 234, and 236 from the trace memory 290A to simulate the segment 285A. By simulating the segment 285A, the host system 120 generates the signal 237. Additionally, the host system 120 can generate the signals 233 and 235 even if these signals 233 and 235 are not requested.

[0040] Since the host system 120 can obtain the values ​​of these signals 233, 235, 237, and 238 by simulating the section 285A, the simulator 110 does not have to be configured to trace those signals 233, 235, 237, and 238. In an environment where millions of signals are traced, a host system having a section capable of simulating the DUT will significantly reduce the number of signals that must be traced by the FPGA 220 and the number of values ​​of the signals exchanged between the simulator 110 and the host system 120, thereby saving simulation resources, communication bandwidth, and increasing simulation speed.

[0041] Further, the host system 120 simulates only those segments 285 that are necessary to obtain the desired signals. In this example, since only the value of the signal from segment 285A is needed, the host system 120 simulates only segment 285A and not segments 285B, 285C, and 285D, thereby conserving resources of the host system 120. However, if the values ​​of the signals from segments 285B, 285C, and / or 285D are needed, those segments may be simulated by the host system 120 simultaneously or sequentially with segment 285A.

[0042] In one embodiment, the host system 120 simulates only a portion or sub-segment of the segment 285 to obtain the necessary signals for performing the analysis. For example, the signal 233 of the segment 285A may be needed to perform the analysis or simulate another segment 285, while the other signals 234, 235, 236, 237, and 238 are not needed. In this case, with the signal 232 as input, only the sub-segment of the segment 285A may be simulated to generate the signal 233, without having to simulate the entire segment 285A. As a result, the hardware resources to perform the simulation may be reduced, and the results may be obtained more quickly.

[0043] Figure 3 is a block diagram illustrating a host system 120 in more detail according to one embodiment. The host system 120 includes a design compiler 310, a mapping module 320, a runtime module 330, a simulation module 340, a segment module 350, a result module 360, and a storage device 370. Each of these components may be implemented as hardware, software, firmware, or a combination thereof.

[0044] The design compiler 310 converts the HDL of the DUT into gate-level logic. For a DUT to be simulated, the design compiler 310 receives a description of the DUT in HDL (e.g., RTL or other abstraction level). The design compiler 310 synthesizes the HDL of the DUT to create a gate-level netlist with a description of the DUT from the gate-level logic.

[0045] In one embodiment, the design compiler 310 identifies signals of the DUT to be traced by the simulator 110 during simulation of the DUT. In one embodiment, the identified signals do not include all signals in the DUT or all states of the DUT. In one embodiment, information indicating the signals of the DUT that should be traced is received from a user or from another system. The design compiler 310 incorporates signal tracing logic into the DUT to enable tracing of each identified signal. In one embodiment, the design compiler 310 incorporates the signal tracing logic prior to synthesizing the HDL to create a netlist. In this embodiment, prior to synthesis, the design compiler 310 retrieves the HDL of the signal tracing logic from the storage device 370 and edits the HDL of the DUT to include the retrieved HDL of the signal tracing logic.

[0046] In another embodiment, the design compiler 310 incorporates the signal tracing logic after building the netlist for the DUT. In this embodiment, the design compiler 310 retrieves the gate-level description of the signal tracing logic from the storage device 370 and compiles the gate-level netlist to include the gate-level description of the signal tracing logic.

[0047] In another embodiment, the description of the DUT received by the design compiler 310 already includes signal tracing logic. Therefore, in this embodiment, the design compiler 310 does not need to add signal tracing logic to trace the identified signals.

[0048] The mapping module 320 maps the DUT to the FPGA 220 of the simulator 110. After the design compiler 310 incorporates the signal tracking logic into the DUT and creates a gate-level netlist, the mapping module 320 uses the netlist to divide the DUT at the gate level into several partitions. In one embodiment, the mapping module 320 partitions the DUT by identifying one or more partitions of the DUT to be simulated based on the available sections and / or signals required to perform the DUT analysis. The mapping module 320 can identify one or more partitions in a manner that only a minimum number of signals can be traced by the simulator 110. In one embodiment, the mapping module 320 identifies one or more partitions based on the available bandwidth of the interface. Alternatively, the mapping module 320 can identify one or more partitions in a manner that only a minimum number of sections can be simulated by the host system 120. The mapping module 320 maps each partition to the corresponding FPGA 220 of the simulator 110. In one approach, the mapping module 320 performs partitioning and mapping using one or more of: design rules, design constraints (e.g., timing constraints or logic constraints), available resources in the FPGA 220, restrictions on the trace memory 290, gates formed by the HDL, HDL source code, user input, and information about the simulator 110.

[0049] The mapping module 320 generates one or more binary files to configure the FPGA to simulate its corresponding partition. In one embodiment, the mapping module 320 generates a binary file for each FPGA 220. The mapping module 320 stores the binary file in the storage device 370. The mapping module 320 also stores signal information in the storage device 370 indicating which signals are tracked by each FPGA 220 based on the mapping.

[0050] The segment module 350 identifies the segments of the DUT that are to be used by the simulation module 340 of the host system 120 for simulation. For example, the segment module 350 divides the DUT into several segments. Similar to the mapping module 320, the segment module 350 can use one or more of the following to identify the segments of the DUT to be simulated by the simulation module 340: simulation speed, number of HDL lines, number of gates generated by the HDL, number of required input signals, simulation constraints, design rules, design constraints, user input, and simulator information. The segment module 350 can create segments to speed up the execution of simulations or perform analysis of the DUT while considering the design itself without considering the hardware capacity. For example, when creating segments, the segment module 350 can consider the size of the interface, the number of signals, and / or the clock frequency of the signals of the segment. In addition, when creating segments, the segment module 350 can consider the time or the number of processes executed by one or more processors to simulate the segment. After identifying the sections of the DUT, the section module 350 generates a section file describing the design (e.g., circuit) of each identified section of the DUT. In one embodiment, the section module 350 creates a section file for each identified section. The section module 350 stores the section file in the storage device 370. The section module 350 also stores signal information in the storage device 370 that describes, for each described section, the DUT signals that are traced when simulating the section and the signals of the DUT (e.g., input signals) required to simulate the section.

[0051] The identified segments may include a portion of a partition or the entire partition. In one embodiment, the aggregate of the identified segments models the entire DUT. However, as described below, not all segments are simulated by simulation module 340 at the same time. In another embodiment, the aggregate of the identified segments models only a portion of the DUT. In yet another embodiment, a portion of the DUT may be included in multiple segments.

[0052] The runtime module 330 configures the simulator 110 to perform simulation of the DUT. The runtime module 330 transmits a binary file for the DUT stored in the storage device 370 to the simulator 110 via the interface 115 to configure the FPGA 220 of the simulator 110 to simulate the DUT. The runtime module 330 instructs the simulator 110 to simulate the DUT. In one embodiment, before the simulation starts or during the simulation of the DUT, the runtime module 330 transmits input parameters and / or a state machine to the simulator 110 to configure and control the simulation of the DUT.

[0053] The simulation module 340 simulates a section of the DUT. The simulation module 340 can simulate any type of section. The sections simulated by the simulation module 340 include combinatorial, sequential, or a combination of both types of circuits. In one embodiment, the simulation module 340 can simulate a non-synthesizable portion of a circuit. In another embodiment, the simulation module 340 is software that cannot compute anything other than signals, and in another embodiment, the simulation module 340 can be used to compute any kind of circuit, not limited to circuits compiled into a simulator.

[0054] The simulation module 340 receives verification settings indicating signals of the DUT required for performing analysis or verification of the DUT. The verification settings may include requests to trace certain signals or a state machine for analyzing the DUT. The verification settings may be received from a user, received from another system, or may be part of the simulator 110 or the DUT.

[0055] The simulation module 340 identifies the value of the signal of the DUT that needs to be obtained based on the verification setting. The simulation module 340 identifies which sections of the DUT produce one or more identified signals when simulated based on the signal information stored in the storage device 370. The simulation module 340 also determines which signals are needed to simulate the identified sections. The simulation module 340 identifies the required signals that have been tracked by the simulator 110. If the required signal has not been obtained from the simulator 110, the simulation module 340 requests and receives the signal from the simulator 110. In one embodiment, if the signal required to simulate the identified section is not tracked by the simulator 110, the simulation module 340 simulates one or more sections to obtain the required signal.

[0056] Based on the correspondence between the values ​​of the available signals and the inputs required for each segment, the simulation module 340 determines the segments to be simulated. In one embodiment, the simulation module 340 identifies the segments to be simulated in a manner that requires the minimum number of segments or the minimum number of input signals required to generate the required signals. Alternatively, the simulation module 340 identifies the segments to be simulated based on the available bandwidth of the interface 115.

[0057] In one embodiment, for one or more sections, instead of determining to simulate the entire section, the simulation module 340 may determine to simulate only a portion or subsection of the section of the DUT to generate one or more of the identified signals. The section or subsection of the section may be identified so that a minimum number of signals are traced or a minimum number of sections are simulated.

[0058] The simulation module 340 simulates each of the identified sections using the values ​​of the signals obtained (e.g., from the simulator 110 or by simulating other sections). The simulation module 340 may also simulate the sections using the input parameters provided (e.g., from the user). The simulation module 340 stores the values ​​of the signals tracked during the simulation of the sections in the storage device 370. In one embodiment, the simulation module 340 also retrieves from the simulator 110 the signals identified in the verification setup that have been tracked by the simulator 110 when simulating the DUT. The simulation module 340 stores the values ​​of the tracked signals retrieved from the simulator 110 in the storage device 370.

[0059] As an example, return to Figure 2 , assume that based on the verification setting, it is determined that the signal 237 in the section 285A needs to be traced, but the signal 237 is not traced by the simulator 110. In this case, the simulation module 340 will simulate the section 285A to obtain the signal 237.

[0060] As described above, additional segments may be simulated to generate the input signals required to simulate the segments. For example, assume a determination is made to simulate segment 285D to obtain a certain signal value from segment 285D. Further assume that signal 233 from segment 285A is the input to segment 285D. In order to be able to simulate segment 285D, segment 285A is first simulated to generate signal 233. Once signal 233 is obtained, segment 285D may be simulated.

[0061] The simulation module 340 is invoked and retrieves the traced signals according to the state of the interface 115. In one embodiment, the interface 115 between the simulator 110 and the host system 120 is enabled during simulation of the DUT. The simulation module 340 retrieves the values ​​of the signals traced by the simulator 110 during simulation of the DUT performed by the simulator 110. The simulation module 340 also simulates the identified sections during simulation of the DUT.

[0062] In one embodiment, while the interface 115 is enabled, the simulator 110 stores all or some of the tracked values ​​in the storage device 370. Regardless of whether the DUT is being simulated, the simulation module 340 can retrieve the values ​​of the signals stored in the storage device 370 by the simulator 110 and simulate some sections of the DUT to provide signal values ​​that have not yet been stored. The simulation module 340 can then store the simulated signal values ​​in the storage device 370, or provide these values ​​on a GUI interface, or provide these values ​​to a script or software program running on the host system 120, which may have requested some of those values.

[0063] In one embodiment, the interface 115 between the host system 120 and the simulator 110 is disabled during the simulation and enabled after the simulation is complete. After the host system 120 completes the simulation of the DUT or a portion of the DUT, the simulation is performed. When the simulation is complete, the simulation module 340 retrieves the signals traced during the simulation via the interface 115 and simulates the identified segments.

[0064] In one embodiment, simulation module 340 is called and retrieves the tracked signal in an interactive mode. In the interactive mode, simulation module 340 is called at a certain moment by a user monitoring a signal or a small set of signals. The user typically requests or selects the desired signal in a GUI interface such as Synopsys' Verdi waveform viewer. Simulation module 340 obtains additional signal values ​​based on the monitored signal through simulation. The simulation can be performed locally on a system (e.g., a host system) used to run Verdi.

[0065] In one embodiment, the simulation module 340 is called and retrieves the traced signals in a non-interactive mode. The simulation module 340 can operate without a user request, but can operate based on a script provided before the simulation. When the signal set is as large as the entire design, the non-interactive mode can be adopted.

[0066] The result module 360 ​​provides the results from the simulated DUT and the sections of the simulated DUT. The result module 360 ​​processes the values ​​of the traced signals generated by the simulation of the DUT sections and the values ​​of the traced signals retrieved from the simulator 110. In one embodiment, the result module 360 ​​retrieves the values ​​of the traced signals from the storage device 370 and generates a user interface including a representation of the values ​​of the traced signals for display to the user. In one embodiment, the result module 360 ​​is a waveform viewer that generates a waveform of the traced signal for display. In one embodiment, the result module 360 ​​includes an API for creating a visual waveform of the traced signal for display to the user. Processing the traced signal can also include the result module 360 ​​counting events based on the traced signal. In another embodiment, the result module 360 ​​includes a binary program (obtained from a system C model, C / C++ model or any other software language) or script that processes the signal value to generate information based on the display of the signal value or information.

[0067] In one embodiment, one or more functions of host system 120 may be performed at another computer (eg, a dedicated computer or collection of machines). For example, design compiler 310 and mapping module 320 may be included in another computer for compiling and partitioning the DUT.

[0068] Figure 4is a flow chart illustrating the preparation of the host system 120 for emulating a DUT according to one embodiment. Other embodiments may perform the steps in a different order. Figure 4 Moreover, other embodiments may include different and / or additional steps than those described here.

[0069] The host system 120 obtains 410 a description of the DUT in HDL from the user. Based on the description of the DUT, the host system 120 generates configuration files for simulating the DUT in the simulator 110 and for the sections in the host system 120. Preferably, the host system 120 generates binary files to be loaded into the FPGA 220 of the simulator 110 and section files to be used by the host system 120 when one or more sections need to be simulated. In one embodiment, the host system 120 generates the binary files and the section files in parallel.

[0070] To generate the binary file, the host system 120 synthesizes 420 the HDL description of the DUT to create a gate-level netlist. In one embodiment, the host system 120 also obtains a predetermined list of signals of the DUT that should be traceable during simulation. To be able to trace each signal, the host system 120 incorporates signal tracing logic into the DUT. In one embodiment, the host system 120 incorporates the signal tracing logic by editing the HDL description of the DUT before synthesizing the HDL description. In another embodiment, the signal tracing logic is incorporated after the HDL description is synthesized by editing the netlist. In another embodiment, the description of the DUT obtained by the host system 120 includes the signal tracing logic.

[0071] The host system 120 divides 430 the DUT at the gate level into several partitions using the gate-level netlist. In one embodiment, the host system 120 divides the DUT by identifying one or more partitions of the DUT to be simulated based on the available sections and / or signals required to perform the analysis of the DUT. The host system 120 can identify one or more partitions in a manner that only a minimum number of signals can be tracked. Alternatively, the host system 120 can identify one or more partitions in a manner that the host system 120 will only need to simulate a minimum number of sections. The host system 120 maps 440 each partition to the FPGA 220 of the simulator 110. The host system 120 generates 450 a binary file that includes information to configure the FPGA 220 to simulate its corresponding mapped DUT partition.

[0072] To generate the section files, host system 120 identifies 460 sections of the DUT that are to be used for simulation (e.g., divides the DUT into sections). After identifying the sections of the DUT, host system 120 generates 470 section files for each section that describe the design of the section. Host system 120 stores the section files. Identifying the sections of the DUT may be based on at least one of: synthesis, partitioning, and mapping of the DUT for steps 420, 430, and 440, respectively. The list of signals in the identified sections of the DUT may be used for at least any of: synthesis, partitioning, mapping, and generating binary files for the DUT for steps 420, 430, 440, and 450, respectively.

[0073] After generating both the binary file for FPGA 220 and the segment file for simulation module 340, host system 120 stores 480 signal information for each partition, which indicates which signals are tracked when the partition is simulated. Host system 120 also stores, for each segment, signal information indicating which signals are tracked when the segment is simulated, and information indicating which input signals are needed to simulate the segment. Storage 480 may be performed in one or more of a database, a file, a hard disk, a memory, or an external storage device.

[0074] Figure 5 is a flowchart of configuring the host system 120 and the simulator 110 for tracing certain signals of the DUT according to one embodiment. Other embodiments may be performed in a different order. Figure 5 Moreover, other embodiments may include different and / or additional steps than those described here.

[0075] The host system 120 transmits 510 a binary file to the emulator to configure the FPGA 220 of the emulator 110 to emulate the DUT. The host system transmits 520 instructions to the emulator 110 to emulate the DUT.

[0076] The host system 120 identifies 530 the signals of the DUT required for analyzing the DUT (e.g., required by the user or required by the system). The host system 120 determines 540 which segments are to be simulated from the segment pool based on the identified signals to be able to obtain the identified signals. The host system 120 determines the segments to be simulated in a manner that requires a minimum number of segments or a minimum number of input signals (or traced signals) to produce the required signals. The host system 120 determines the segments to be simulated to generate one or more of the identified signals when simulated. The host system 120 can determine a sub-segment of the segment to be simulated rather than the entire segment. The host system 120 also determines 550 the signals traced by the simulator 110 to retrieve the segments determined for simulation.

[0077] The host system 120 obtains 560 the determined traced signals from the simulator 110. If the simulator 110 has traced the signals required for analyzing the DUT, the host system 120 also obtains the signals from the simulator 110. The host system 120 simulates 570 the determined sections of the DUT using the traced signals obtained from the simulator 110 and the section files describing the design of the sections. Based on the simulation of these sections, the required signals of the DUT are obtained / traced.

[0078] Computer architecture

[0079] Now go to Figure 6 , which is a block diagram illustrating components of an example machine capable of reading instructions from a machine-readable medium and executing them in one or more processors (or controllers). Specifically, Figure 6 A diagrammatic representation of a machine in the example form of a computer system 600 is shown within which instructions 624 (eg, software or program code) are used to cause the machine to perform (execute) the operations described herein. Figures 1 to 5 In addition, the computer system 600 can be used to Figure 1 One or more entities (eg, host system 120, emulator 110) among the entities illustrated in simulation environment 100.

[0080] The example computer system 600 includes a processor 602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), one or more application specific integrated circuits (ASICs), one or more radio frequency integrated circuits (RFICs), or any combination of these), a main memory 604, and a static memory 606, which are configured to communicate with each other via a bus 608. The computer system 600 may also include a graphics display unit 610 (e.g., a plasma display panel (PDP), a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)). The computer system 600 may also include an alphanumeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit 616, a signal generating device 618 (e.g., a speaker), and a network interface device 620, which are also configured to communicate via the bus 608. In addition, the computer system 600 may have a touch-sensitive display.

[0081] The storage unit 616 includes a machine-readable medium 622 on which are stored instructions 624 (e.g., software) that implement any one or more of the methodologies or functions described herein. During execution by the computer system 600, the instructions 624 (e.g., software) may also reside completely or at least partially within the main memory 604 or within the processor 602 (e.g., within the processor's cache memory), the main memory 604 and the processor 602 also constituting machine-readable media. The instructions 624 (e.g., software) may be transmitted or received over a network 626 via the network interface device 620.

[0082] Although the machine-readable medium 622 is shown as a single medium in the example embodiment, the term "machine-readable medium" should be considered to include a single medium or multiple media (e.g., a centralized database or distributed database, or associated caches and servers) that can store instructions (e.g., instructions 624). The term "machine-readable medium" should also be considered to include any medium that can store instructions (e.g., instructions 624) for execution by a machine and cause the machine to perform any one or more of the methodologies disclosed herein. The term "machine-readable medium" includes, but is not limited to, data storage repositories in the form of solid-state memories, optical media, and magnetic media.

[0083] As is known in the art, the computer system 600 may have Figure 6 In addition, the computer system 600 may lack some of the components shown. For example, the computer system 600 used as the emulator 110 may include one or more hardware processors 602, multiple storage units 616, a network interface device 620, and multiple configurable logic circuits (as described above with reference to FIG. Figure 1 ), and other components, but may lack an alphanumeric input device 612 and a cursor control device 614. As another example, a computer system 600 used as a host system 120 may include one or more hardware processors 602. A host system 120 with multiple processors 602 may execute multiple simulations in parallel on multiple threads, processes, and / or machines. Subsets of segments may be distributed by a user or automatically distributed by a software program to generate a set of signals based on a set of input signals through simulations performed in parallel.

[0084] Additional Configuration Considerations

[0085] Advantageously, the disclosed system and method can realize the saving of simulation resources and simulation resources. By tracking only a few signals (e.g., the boundaries of a segment) from the simulator, the simulator does not have to track all signals. Therefore, the values ​​of fewer signals are exchanged between the simulator and the host system, so communication bandwidth or throughput can be saved. Using several tracked signals, the size of the DUT being simulated and verified becomes scalable. In addition, by selecting the segment with the minimum number of segments or the minimum number of input signals to generate the required signal for performing the analysis, simulation resources and simulation resources can be saved, and the speed of obtaining the value of the required signal can be increased.

[0086] It should be noted that although the subject matter is described in the context of a simulation environment for simulating digital circuits and systems, the principles described can be applied to the analysis of any digital electronic device. Also, although the examples herein are in the context of a simulation environment including an FPGA, the principles described herein can be applied to other analysis of hardware implementations of any digital logic circuit or software simulation such as EDA.

[0087] Throughout the specification, multiple instances can be implemented as parts, operations or structures described as single instances. Although the individual operations of one or more methods are illustrated and described as separate operations, one or more operations in the individual operations can be performed simultaneously, and the operations do not need to be performed in the illustrated order. The structure and functionality presented as the separate components in the example configuration can be implemented as a combined structure or parts. Similarly, the structure and functionality presented as a single component can be implemented as a separate component. These and other changes, modifications, additions and improvements fall within the scope of the subject matter of this paper.

[0088] like Figures 1 to 5 As illustrated, certain embodiments are described herein as, for example, including logic or a number of components, modules (which may also be referred to herein as "tools"), or mechanisms. Modules may constitute software modules (e.g., code presented on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., stand-alone computers, client or server computer systems) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or an application portion) as a hardware module that operates to perform certain operations as described herein.

[0089] In some embodiments, the hardware modules may be implemented in electronic form. For example, the hardware modules may include permanently configured dedicated circuits or logic (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. The hardware modules may also include programmable logic or circuits (e.g., as included in a general-purpose processor or other programmable processor) that are temporarily configured to perform certain operations by software. The hardware modules implemented herein may be implemented in dedicated and permanently configured circuits or in temporarily configured circuits (e.g., configured by software).

[0090] The various operations of the example methods described herein are performed, at least in part, by one or more processors (e.g., processor 602), which are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, these processors may constitute processor-implemented modules that operate to perform one or more operations or functions. In some example embodiments, the modules referenced herein may include processor-implemented modules.

[0091] The one or more processors may also be operable to support execution of the related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some of the operations may be performed by a computer group (as an example of a machine including a processor), which may be accessed via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an application program interface (API)).

[0092] The performance of certain operations in the operation can be distributed among one or more processors, not only residing in a single machine, but also deployed across multiple machines. In some example embodiments, one or more processors or processor-implemented modules can be located in a single geographic location (e.g., in a home environment, an office environment, or a server farm). In other example embodiments, one or more processors or processor-implemented modules can be distributed across several geographic locations.

[0093] Some parts of this specification are presented in accordance with algorithms or symbolic representations of operations on data stored as bits or binary digital signals in machine memory (e.g., computer memory). These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the field of data processing to convey the essence of their work to those of skill in the art. As used herein, an "algorithm" is a self-consistent sequence of operations or similar processing that results in a desired result. In this context, algorithms and operations relate to physical operations of physical quantities. Typically, but not necessarily, such quantities can take the form of electrical, magnetic or optical signals that can be stored, accessed, transmitted, combined, compared or otherwise manipulated by a machine. Sometimes, primarily for reasons of common use, words such as "data", "content", "bit", "value", "element", "symbol", "character", "term", "number", "digit", etc. are used to refer to these signals. However, these words are merely convenient labels and are associated with appropriate physical quantities.

[0094] Unless otherwise noted, discussions herein using words such as "process," "compute," "calculate," "determine," "present," "display," and the like may refer to the actions or processes of a machine (e.g., a computer) that operates on or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0095] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily refer to the same embodiment.

[0096] The expressions "coupled" and "connected" and their derivatives may be used to describe some embodiments. For example, the term "coupled" may be used to describe some embodiments to indicate that two or more elements are in direct physical or electrical contact. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other. The embodiments are not limited in this context.

[0097] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof, are intended to cover non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent to those processes, methods, articles, or apparatuses. Further, unless expressly stated to the contrary, "or" refers to an inclusive or, not an exclusive or. For example, a condition A or B satisfies any of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exist).

[0098] In addition, "a" or "an" is used to describe elements and components of the embodiments herein. This is merely for convenience and to give a general sense of the invention. The description should be read to include one or at least one, and the singular also includes the plural, unless it is obvious that it has another meaning.

[0099] After reading this disclosure, those skilled in the art will appreciate additional alternative structural designs and functional designs for implementing the principles described herein. Therefore, although specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise configurations and components disclosed herein. Various modifications, changes and variations that are obvious to those skilled in the art may be made in the arrangement, operation and details of the methods and devices disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

1. A computer-implemented method, performed on a host system, for reducing bandwidth between the host system and an emulator, the method comprising: The host system identifies a first signal of a design under test (DUT) to be traced, the DUT comprising a plurality of sections, the host system having a plurality of section files, each section file corresponding to a respective section file of the plurality of section files of the DUT; identifying, based on the plurality of section files, a section of the DUT that, when simulated, provides the first signal, wherein the first signal is not traced by the simulator; determining, based on the identified segment, a second signal tracked by the simulator; receiving a second signal tracked by the simulator; as well as The first signal is generated using the received second signal. 2 . The method of claim 1 , further comprising generating a third signal for evaluating functionality of the DUT, the third signal not being requested to be traced.

3. The method according to claim 1, further comprising: creating a plurality of partitions of the DUT, wherein a partition corresponds to one or more of the plurality of sections; as well as A plurality of binary files are created, wherein each binary file describes a corresponding partition of the DUT and maps the corresponding partition to a field programmable gate array FPGA. 4 . The method of claim 3 , further comprising sending the plurality of binary files to the simulator, wherein the simulator uses the plurality of binary files to configure a plurality of FPGAs.

5. The method according to claim 1, further comprising: identifying at least one segment of the plurality of segments, the identified segment including the first signal; as well as A plurality of section files are created, a section file of the plurality of section files describing the circuitry of the identified section.

6. The method of claim 5, wherein the identified at least one segment includes a first segment and a second segment, further comprising: generating a third signal of the first segment based on a second signal traced by the simulator; as well as Based on the third signal of the first section, a first signal of the second section is generated. The method of claim 1 , further comprising receiving a user request to track the first signal.

8. The method of claim 1, wherein the second signal is received along with additional signals from the simulator after completing simulation of the DUT. 9 . The method of claim 1 , further comprising generating a user interface for display, the user interface comprising respective values ​​of the first signal and the second signal.

10. The method of claim 1, further comprising generating the plurality of segments based on a number of signals or a number of processes performed by the host system to emulate each segment.

11. A non-transitory computer readable medium storing instructions which, when executed by a host system, cause the host system to: a first signal identifying a design under test (DUT) to be traced, the DUT comprising a plurality of sections, the host system having a plurality of section files, each section file corresponding to a respective section file of the plurality of section files of the DUT; identifying, based on the plurality of section files, a section of the DUT that, when simulated, provides the first signal, wherein the first signal is not traced by a simulator; determining, based on the identified segment, a second signal tracked by the simulator; receiving a second signal tracked by the simulator; as well as The first signal is generated using the received second signal.

12. The non-transitory computer readable medium of claim 11, wherein the instructions further cause the host system to generate a third signal for evaluating functionality of the DUT, the third signal not requested to be traced.

13. The non-transitory computer readable medium of claim 11, wherein the instructions further cause the host system to: creating a plurality of partitions of the DUT, wherein a partition corresponds to one or more of the plurality of sections; and A plurality of binary files are created, wherein each binary file describes a corresponding partition of the DUT and maps the corresponding partition to a field programmable gate array FPGA.

14. The non-transitory computer readable medium of claim 13, wherein the instructions further cause the host system to send the plurality of binary files to the emulator, wherein the emulator configures a plurality of FPGAs using the plurality of binary files.

15. The non-transitory computer readable medium of claim 11, wherein the instructions further cause the host system to: identifying at least one segment of the plurality of segments, the identified segment comprising the first signal; and A plurality of section files are created, a section file of the plurality of section files describing the circuitry of the identified section.

16. The non-transitory computer readable medium of claim 15, wherein the identified at least one segment comprises a first segment and a second segment, and wherein the instructions further cause the host system to: generating a third signal of the first segment based on a second signal traced by the simulator; and Based on the third signal of the first section, a first signal of the second section is generated.

17. The non-transitory computer-readable medium of claim 11, wherein the instructions further cause the host system to receive a user request to track the first signal.

18. The non-transitory computer readable medium of claim 11, wherein the second signal is received along with additional signals from the simulator after completing simulation of the DUT.

19. The non-transitory computer-readable medium of claim 11, wherein the instructions further cause the host system to generate a user interface for display, the user interface including respective values ​​of the first signal and the second signal.

20. The non-transitory computer readable medium of claim 11, wherein the instructions further cause the host system to generate the plurality of segments based on a number of signals or a number of processes performed by the host system to simulate each segment.

Images