« PreviousContinue »
cdé " _ TM. 153.; —- ————-— H;/<5/~ — ~ " " 5:’. _i_ _ K—-I////////////////////////////// /////5%//////////////////////////////////////////II s - —— -2 ~ lfl __ ____.__ ../ - -2 _ z / - _ o '/ * n ID ___ __________ __j\n/ _ _ _ In /% Q __ _i__. 0 ’ 4 _ _ [-1 O -25? T an — 4 :4 —o/ - ~I ‘I T I a A is? M N QI oz ~<r N §\;—<I~z SI (11 \l> <~II <r <~Iz SI r~II U --‘I - -@'l—=l—<=Il- -»@¢-=»I- a -4- = -aI—=I--I- - -=>lIn Q, In In In /,_,/ln ,,, =0 W 1n In In V, In E, .. -s-e—a- -2&4-.-.2’-3 -ea -at-a-as"; -63- _ 9 sl 'O‘m'O_Q_O' -;sé-e~,,-s-a-a-a-a-,,-s- sl J____.L___l___.__l____L_ 0 "’ ~/ I ”’ ,_, I--I QI N QI N I I I I-' .. (D .__ ___...a,|......|. -- I I U Z E "* I" "‘ 2 Q — -----2-a-2-- - - _ -~ an °°/ Q _ ---§-~-§-a-/ - - . R O %
iii \—+’///////////////////////////////J ////
1 VARIABLE CLOCKING IN HARDWARE CO-SIMULATION
The present invention generally relates to simulating electronic circuit designs. More particularly, the invention relates to performing hardware co-simulation of electronic circuit designs.
A high level modeling system (HLMS) is a software tool in which electronic designs can be described, simulated, and translated by machine into a design realization. An HLMS provides a higher level of abstraction for describing an electronic circuit than a hardware description language (HDL) simulation enviromnent such as the ModelSim enviromnent from the Model Technology company. An HLMS generally provides a mathematical representation of signals, as compared to standard logic vectors in a hardware description language (HDL). It is desirable for the high-level abstractions to be precisely correlated with the ultimate implementation representation, both in simulation semantics and in implementation. The System Generator tool for DSP (Sysgen) and ACCELDSPTM from XILINX, Inc., and SIMULINK® and MATLAB® enviromnents from The MathWorks, Inc., are examples of such HLMSs.
An HLMS for electronic circuit design generally offers abstractions that are not available in traditional HDLs. For example, an HLMS is likely to offer abstractions that relate to signal propagation and signal state, while an HDL may support a detailed representation that more closely models a realized electronic circuit. An electronic design modeled in an HLMS may be viewed as a collection of components that communicate through signals. Signals are discrete, timevarying sequences of values. An HLMS generally provides abstractions to support implementing synchronous designs without requiring the specification of explicit references to clocks or clock signals. Instead of providing a detailed, event driven simulation, an HLMS may also provide abstractions wherein clock-synclironous state changes are scheduled to occur at regular intervals, and in which there is no notion of the timing characteristics related to the intended implementation as an electronic circuit. In further support of creating high-level designs, an HLMS may also represent states in terms of numerical (or other abstract) values instead of representing states in a detailed format analogous to standard logic vectors.
An HLMS such as Sysgen also has the capability to generate objects for co-simulating using a hardware platform. Co-simulation generally refers to dividing a design into portions and simulating the portions on two or more platforms. There are different types of platforms on which designs may be co-simulated.
Example co-simulation platforms include both softwarebased and hardware-based systems. The MODELSIM® simulation enviromnent from Mentor Graphics Corp. and the NC-Sim simulator from Cadence Design Systems, Inc., are example software-based systems, and the Wildcard and BENONE® hardware-based platforms from Annapolis Microsystems and Nallatech, Inc., respectively, are example hardware-based systems. The WildCard and BENONE boards are often used for algorithm exploration and design prototyping, and include programmable logic devices (PLDs). In software-based co-simulations, the user may per
form a behavioral simulation or perform simulation using a synthesized and mapped version of the design.
In a hardware-based system, a portion of the design is emulated on a hardware platform that includes a programmable logic device (PLD), such as a field programmable gate array (FPGA). Co-simulating on a hardware platform may be used to reduce the time required for a simulation run.
In a typical hardware-based co-simulation system, a hardware co-simulation interface (HWCIF) is combined with the portion of the design to be emulated (“hardware block”) on the PLD, for example. The HWCIF supports interactions between the parts of the design simulated in a software-based system and the hardware block. To facilitate lock-step simulations, the HWCIF also controls the clocking of the hardware block. The clock signal to the hardware block is temporarily gated off during the transmission of stimuli and results. When the transmission completes, a single or multiple clock cycle pulses are applied to the hardware block synchronous with the software simulation cycle.
In current hardware co-simulation systems the clock signal to the hardware block is controlled by the HWCIF, and the HWCIF may control stepping of the clock signal or allow the clock to run freely. In the step mode, the HWCIF issues an altemating bit pattern to produce a single cycle or a number of cycles for the clock signal to the hardware block. In the free running mode, the clock signal provided to the hardware block is generally the same as the clock signal used by the HWCIF.
The present invention addresses one or more issues in such co-simulation arrangements that may have been unrecognized.
The invention provides various approaches for co-simulating an electronic circuit design. In one embodiment, a cosimulation system comprises a data processing arrangement that executes a simulator for simulating a first block of an electronic circuit design. A first clock source generates a first clock signal, and a second clock source generates a second clock signal. The first and second clock signals are independent one from another, and an operating frequency of the second clock signal is dynamically adjustable from a clock control interface. A programmable logic device (PLD) is configured with logic that includes a co-simulation interface clocked by the first clock signal, a second block of the electronic circuit design that is clocked by the second clock signal, and a synclironizer that controls data transmission between the co-simulation interface and the second block.
In another embodiment, a method is provided for co-simulating an electronic circuit design. The method comprises simulating a first block of the design in a simulator executing on a data processing arrangement. A second block of the design is simulated in a programmable logic device (PLD) that is coupled to the data processing arrangement. The simulating of the second block includes transmitting data between the first block and the second block via a co-simulation interface implemented on the PLD. A first clock signal is provided to the co-simulation interface from a first clock source, and a second clock signal is provided to the second block from a second clock source. The first and second clock signals are independent one from another. Transmission of data between the co-simulation interface and the second block is synchronized. The result data from the simulating of the first and second blocks is stored, the frequency of the second clock signal is changed, and the simulation is repeated.
Another embodiment, of a co-simulation system, comprises means for simulating a first block of an electronic circuit design, means for generating a first clock signal, and means for generating a second clock signal. The first and second clock signals are independent one from another, and an operating frequency of the second clock signal is dynamically adjustable. A programmable logic device (PLD) is coupled to the means for simulating and is configured with logic that includes a co-simulation interface coupled to the means for generating the first clock signal, and a secondblock of the design coupled to the co-simulation interface and fi1rther coupled to the means for generating the second clock signal. The PLD also is configured with a means for controlling data transmission between the co-simulation interface and the second block.
It will be appreciated that various other embodiments are set forth in the Detailed Description and Claims which follow.
BRIEF DESCRIPTION OF THE DRAWINGS
Various aspects and advantages of the invention will become apparent upon review of the following detailed description and upon reference to the drawings, in which:
FIG. 1 is a functional block diagram of a co-simulation arrangement having independent clock sources for a co-simulation interface and a simulated hardware block;
FIG. 2 illustrates in fiirther detail an embodiment of register banks and clock selection circuitry;
FIG. 3 illustrates in fiirther detail an example embodiment of a synchronizer;
FIG. 4 is a flow chart of an example process for co-simulating an electronic circuit design using independent clock sources and dynamically adjusting the clock source that clocks the logic block being simulated in hardware; and
FIG. 5 illustrates an example FPGA architecture on which a system may be implemented using the various approaches described herein.
DETAILED DESCRIPTION OF THE DRAWINGS
In current co-simulation systems the clock signal applied to the hardware block may be controlled via the hardware co-simulation interface (HWCIF), either by stepping the clock signal (applying a selected number of cycles of the clock signal) or allowing the clock to run freely (no counting of clock cycles). However, because the clock signal to the hardware block is strongly coupled to the HWCIF, the range of clock frequencies that may be tested is constrained by the HWCIF. The constraints thereby limit the possible test scenarios for the design. For example, in one scenario the hardware block may need to be simulated at a certain frequency in order to test the required fimctionality. However, that certain frequency may not be achievable in the simulation when constrained by the HWCIF. A specific example is to perfonn runtime bit error rate testing with a free-rumiing clock to the hardware block. In another scenario, the hardware block may need to be clocked at a lower frequency in order to satisfy the timing constraints for the block’ s critical paths. However, that lower frequency may be below that which the HWCIF is capable of providing. For benchmark or verification purposes, it is sometimes required or desired to sweep through a range of frequencies of the clock signal to the hardware block. Rather than changing or re-implementing the design, it would be preferable to dynamically change the frequency of the clock signal to the hardware block while the hardware block
is rumiing. However, the tight coupling of the HWCIF to the clock signal to the hardware block prevents this type of test1ng.
The various embodiments of the invention address these and other problems by providing a co-simulation system that has independent clock sources for the hardware co-simulation interface and the hardware block. A software-based simulator executes on a data processing arrangement for simulating a part of the design. The data processing arrangement also hosts an interface that provides external, dynamic control over the frequency of the clock signal provided to the hardware block. Based on design requirements and/ or simulation results, the clock to the hardware block may be dynamically adjusted.
A programmable logic device (PLD), which is part of the co-simulation system, is configured with logic that implements the functions of the hardware block and logic that provides a co-simulation interface. The co-simulation interface on the PLD is clocked by a first clock source, and the hardware block is clocked by a second clock source. The first and second clock sources are independent (i.e., the clock outputs of the two clock sources are independent one from another) and each may be internal or extemal to the PLD. The PLD is fiirther configured with a synchronizer that is coupled to the first and second clock sources. The synchronizer controls data transmission between the co-simulation interface and the hardware block. In some embodiments, the syncl1ronizer provides single and multi-step control over the second clock source.
FIG. 1 is a functional block diagram of a co-simulation arrangement 100 having independent clock sources 102 and 104 for the co-simulation interface 106 and for the hardware block 108, respectively. The simulation arrangement further includes a data processing arrangement 112 that hosts a simulator 114, and a hardware co-simulation platfonn 116 having a programmable logic device PLD 118.
The data processing arrangement 112 hosts simulator 114, in which a portion of the design (i.e., logic block 122) is simulated. In one embodiment the data processing system is a computer workstation and in an altemative embodiment the data processing arrangement may be a collection of workstations coupled to a network. In some embodiments, the data processing arrangement may be a large-scale, multi-processor, shared-memory computer system.
The simulator 114 is a software program that executes on the data processing arrangement and that provides fiinctions for simulating logic block 122 in combination with hardwarebased simulation of logic block 108. Example simulators include MODELSIM and NC-Sim, as identified above. Those skilled in the art will recognize that various other simulators are operable in accordance with the embodiments of the invention.
The clock control component 124 is also hosted on data processing arrangement 112. The clock control provides an interface for changing the operating frequency of clock source 104 while the logic block 108 is simulated in hardware. The clock control may be an integrated part of the simulator or may be a tool operated separately from the simulator. The clock control may be interactively operated by a user via a user interface or may be programrnatically operated via a simulation control program (not shown) that analyzes and automatically responds to simulation result data by adjusting the clock frequency. Generally, the simulator govems the clock control based on the simulation requirements.
To control clock source 104, the simulator 114 issues commands to the hardware co-simulation interface 106 over the same communication channel that is used for sending co
simulation commands. The clock control capability is implemented as clock control commands. The hardware co-simulation interface 106 translates these commands into control signals to the clock resources, such as clock multiplexers and digital clock managers on the PLD. Line 123 illustrates the control to these clock resources.
The hardware co-simulation platfonn 116 includes a PLD 118 for simulating the logic block 108. Example hardwarebased co-simulation platfonns are the Wildcard and BENONE platforms referenced above. The PLD 118, in an example embodiment, is a field programmable gate array (FPGA). Depending on simulation requirements, other types of PLDs, such as CPLDs, may be used in the co-simulation.
The hardware co-simulation interface 106 is implemented in configurable logic on the PLD and provides the interface between the simulator 114 and the simulating of the logic block 108 on the PLD. The implementation of the hardware co-simulation interface depends on application requirements and example options include Joint Test Action Group (J TAG), Ethemet, and Peripheral Component Intercormect (PCI) interfaces.
The interface functions provided by the co-simulation interface include data transfer and clock mode commands. The data transfer functions are for moving simulation data between the simulator 114 and the hardware-simulated logic block 108. The simulation data may be sourced from logic block 122 and destined to logic block 108 and/or the converse. The comrnand interface is for commands from the simulator for controlling the clock mode to the logic block. The clock modes in the example embodiment include n-step and free running. In n-step mode the simulator 114 individually triggers n steps of the clock hw_clk signal 132 to the logic block 108; and in free running mode, the hw_clk signal steps at the rate of the clock source 104.
Synchronizer 134 controls data transfer between the domain of clock source 104 and the domain of clock source 102. In addition, the syncl1ronizer controls clock selectors 136, which provide the hw_clk signal to the logic block 108 and which provide the mm_clk 144 signal to the register bank 140. For data input to the logic block 108, clock source 102 enables input registers in register bank 142, and the mm_clk signal enables (based on clock source 104 and selectors 136 controlled by the syncl1ronizer) input registers in register bank 140. For data output from logic block 108, the mm_clk signal enables output registers in register bank 140, and the clock source 102 enables corresponding output registers in register bank 142.
Data input and output controls, as well as clock mode controls, are input from co-simulation interface 106 to synchror1izer 134 via control line 146. The synchronizer acknowledges receipt of data and clock mode commands on ACK line 148. Synchronizer 134 generates clock control signals on lines 150 and 152 for providing the hw_clk signal 132 and mm_clk signal 144 according to the clock mode.
Either or both of the clock sources 102 and 104 may be internal or external to the PLD. In one embodiment, an internal clock source is implemented using the digital clock manager (DCM) to implement a frequency synthesizer in a PLD. FPGAs from Xilinx are examples of PLDs having such resources that support dynamic reconfiguration of the clock resource while the logic block 108 is operating on the FPGA. Those skilled in the art will recognize other suitable types of PLDs from other sources for implementing a controllable internal clock source. An external clock source may be either a direct clock source extemal to the PLD, or an internally synthesized clock source based on an external clock source.
In another embodiment, one or both of the clock sources 104 and 108 are implemented external to the PLD. Extemal, synthesized clock generators can be used to supply the required clock sources with specific frequencies. Several clock generators equipped with an IEEE-488 communication bus can be programmed at runtime to generate different frequencies. The simulator 114 can use this programmable interface to adjust the clock sources dynamically.
Whether intemal or extemal, the separate and independent clock sources 102 and 104 pennit the co-simulation interface 106 and logic block 108 to be operated at different frequencies. Clock source 104 may be configured to run faster than, slower than, or at the same rate as clock source 102.
FIG. 2 illustrates in further detail an embodiment of the register banks 140 and 142 and clock selection circuitry 136. The diagram further illustrates the decoupling of the clock sources of the co-simulation interface and the hardware logic block. Clock source 102 provides the CLKIF signal 202 and clock source 104 provides the CLKS signal 204. The CLKS signal, hw_clk signal 132 to the logic block 108, and mm_clk signal 144 to the registers 206 and 208 all have the same frequency. The hw_clk 132 is gated to provide a clock signal according to the selected clock mode. The mm_clk 144 is gated to provide synchronization between the hardware block 108 within the clock domain of clock source 104.
In the example embodiment, the gating of the hw_clk 132 is implemented with a multiplexer 212. Multiplexer 212 selects between the clock signal from the second clock source and a steady-state signal based on the clock mode. The synchronizer 134 generates the hw_ce signal, the state of which is stored in register 216, to select between the delayed CLKS signal and the steady state signal. The state of the hw_ce signal depends on the clock mode. For example, in step mode the hw_ce signal is asserted for n cycles, and in free-rumling mode, the hw_ce signal remains asserted until the clock mode is changed. The syncl1ronizer 134 asserts the hw_ce signal based on the step_cnt and clk_mode signals 218 and 220 that are input via the registers 222 and 224 of the co-simulation interface, respectively.
To meet the setup and hold time requirements of the clock multiplexers, CLKS is delayed using delay circuit 226 before driving the clock multiplexers 212 and 228. A symmetric arrangement is used to gate hw_clk 132 and mm_clk 144, which allows skew between the two clock signals to be easily minimized during place-and-route of the design and supporting interface circuitry.
The sync signal 232 that is input to the syncl1ronizer via register 234 signals the availability of input data or expectation of output data to the hardware block 108. In response, the synchronizer asserts the hw_mrn_ce signal, the state of wl1ich is stored in register 236, to control selection of CLKS instead of the steady state signal at multiplexer 228. The mm_clk signal from multiplexer 228 enables the storage of data in registers 206 and 208 in the domain of clock source 104. In the domain of clock source 102, the CLKIF clock signal enables the registers 242 and 244 for data transfer. Once the data transfer is complete, the syncl1ronizer asserts the ack signal for retum to the co-simulation interface via register 246.
Registers 206, 208, 242, and 244 illustrate a portion of a memory map interface between the co-simulation interface and the logic block. The memory map includes a set of register pairs, two of which are shown in FIG. 2. One pair includes registers 206 and 242 and another pair includes registers 208 and 244. Each pair corresponds to one I/O port of the logic block 108. The co-simulation interface maps memory addresses of registers 242 and 244 to the correspond