《ADS_HDL_Cosimulation.pdf》由会员分享，可在线阅读，更多相关《ADS_HDL_Cosimulation.pdf（20页珍藏版）》请在三一文库上搜索。
1、HDL Cosimulation August 2005 ii Notice The information contained in this document is subject to change without notice. Agilent Technologies makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fi tness for a particul
2、ar purpose. Agilent Technologies shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty A copy of the specifi c warranty terms that apply to this software product is available upon r
3、equest from your Agilent Technologies representative. Restricted Rights Legend Use, duplication or disclosure by the U. S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 for DoD agenci
4、es, and subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 for other agencies. Agilent Technologies, Inc. 1983-2005 395 Page Mill Road, Palo Alto, CA 94304 U.S.A. Acknowledgments Mentor Graphics is a trademark of Mentor Graphics Corporatio
5、n in the U.S. and other countries. Microsoft, Windows, MS Windows, Windows NT, and MS-DOS are U.S. registered trademarks of Microsoft Corporation. Pentium is a U.S. registered trademark of Intel Corporation. PostScript and Acrobat are trademarks of Adobe Systems Incorporated. UNIX is a registered tr
6、ademark of the Open Group. Java is a U.S. trademark of Sun Microsystems, Inc. SystemC is a registered trademark of Open SystemC Initiative, Inc. in the United States and other countries and is used with permission. iii Contents 1HDL Cosimulation Introduction.1-1 Basic Requirements .1-2 Theory of Ope
7、ration .1-2 Supported HDL Data Types1-3 Bidirectional HDL Ports 1-4 Precision for Bit-Vector Type Ports .1-5 Automatic Clock and Set Signals1-5 Time-Specifi ed Signals in User HDL Code.1-6 HDL Simulator Licenses.1-7 HDL Cosimulation Components and Their Parameters1-8 HdlSrcFile.1-9 Inputs1-10 InputP
8、hases .1-10 InputPrecisions.1-10 Outputs.1-11 OutputPrecisions1-11 HdlModelName.1-11 HdlLibrary.1-12 HdlSimulatorGUI.1-12 CmdArgs 1-13 IterationTime.1-13 TimeUnit.1-14 Index iv Introduction1-1 Chapter 1: HDL Cosimulation Introduction With the ADS HDL cosimulation feature you can simulate components
9、represented in a hardware description language (HDL) in the same schematic with other ADS components. This integrated capability provides complete design fl exibility, and complements other ADS modules, including Digital Filter Designer. The ability to design all portions of a communications product
10、 in one integrated environment can eliminate design errors resulting from disconnects among design teams. By cosimulating with HDL designs, you can easily incorporate your existing HDL intellectual property into new designs. With HDL cosimulation, you can test hardware defi ned in HDL with a DSP alg
11、orithm, or use an algorithm written in HDL within an existing ADS design. VHDL and Verilog HDL are supported. ADS Ptolemy provides the signal processing simulation, while the ModelSimTM HDL simulator from Model Technology Incorporated, Verilog XL from Cadence Design Systems, or NC-SIM from Cadence D
12、esign Systems simulates the HDL code. This cosimulation capability in one design environment makes it easy to test HDL components along with complex ADS system designs and see the effect on the entire system. ImportantWhen using an HdlCosim component on the Sun5.10 platform, the ModelSim simulator w
13、ill error out because the ModelSim simulator is not supported on Sun5.10. When using a VxlCosim component with the Cadence Verilog-XL version 5.00p001, HDL cosimulation will fail. This failure is because Verilog-XL crashes and dumps core for certain types of Verilog code. 1-2Basic Requirements HDL C
14、osimulation Basic Requirements HDL Cosimulation is an optional feature of ADS. To run it, you must have: ADS Ptolemy simulator One of the following HDL simulators: ModelSim/PLUSTM Verilog XL NC-SIM NoteFor the latest versions of HDL simulators supported on ADS, see Before You Begin Check the System
15、Requirements in Windows Installation or UNIX and Linux Installation. Theory of Operation With the HDL Cosimulation feature, ADS Ptolemy has been confi gured to cosimulate with either the ModelSim, VerilogXL, or NC-SIM HDL simulator. In this use model, you fi rst create the HDL design. The design mus
16、t be compiled and it is recommended to test the simulation with ModelSim, VerilogXL, or NC-SIM before cosimulation. If the code is not compiled, you can use ADS to compile the code before cosimulation. Cosimulation requires information regarding the VHDL entity or Verilog module that you want to cos
17、imulate with. This is used to generate HDL wrappers that incorporate user code and C-interface code to create an inter-process communication (IPC) link between ADS and the HDL simulator. The cosimulation can be run in graphical user interface mode to monitor the HDL simulation. It can also be run in
18、 the background processing mode. HDL Cosimulation uses the ADS Ptolemy Synchronous Datafl ow (SDF) domain, in which numeric signals are consumed and produced by the HDL cosimulation component. There is no timing information communicated between ADS and the HDL simulator. ADS sends data into the HDL
19、simulator and receives data without any knowledge of the HDL timing. HDL Cosimulation does not use the ADS Ptolemy Timed Synchronous Datafl ow (TSDF) domain. Since the HDL cosimulation component acts as an ADS Ptolemy Supported HDL Data Types1-3 numeric component, any timed data from other ADS Ptole
20、my components will be converted to numeric at the HDL cosimulation components input. The HDL cosimulation component is a numeric component. Because the HDL simulation is time driven, it is initiated at every fi xed interval for each fi ring of the HDL cosimulation component in ADS. The time scale us
21、ed by the HDL simulator is independent of the ADS simulation. Each time the HDL cosimulation component is fi red, the HDL simulator receives input values from other ADS components and uses them to perform the HDL simulation. Once the HDL simulator is fi nished with its processing, it passes the simu
22、lation results back to ADS. These passed values are then the inputs for other ADS components, and thus the simulation cycle continues. This cycle repeats as many times as the scheduler requires. Each time the HDL cosimulation component is fi red, the HDL simulation duration is determined by the valu
23、e of the IterationTime parameter (see “IterationTime” on page 1-13) in the HDL cosimulation component. You must determine how long the HDL simulator should run before its outputs are sent back to the HDL component. This timing information should not be confused with the timing used in other ADS Ptol
24、emy timed components. From the HDL simulator engines point of view, the ADS input interface is viewed as forcing values onto the ports. At the output interface of the HDL cosimulation component, the results are converted back into ADS format and sent to the connecting ADS component. You can specify
25、the HDL simulation to run until the HDL simulator has no more events to process by specifying a negative iteration time. Using this method, the outputs are guaranteed to be stable since there are no more events left in the simulator that might change them. This method is less effi cient than the fi
26、xed positive iteration time method, as the HDL simulator must be monitored to determine when all events have been processed. Also, it will not work for certain HDL models where some designs never run out of events, such as those with internal clock signals. When a negative iteration time is specifi
27、ed for a Verilog module, a VHDL wrapper is used to instantiate the Verilog module. Supported HDL Data Types HDL cosimulation currently supports various bit and bit-vector type HDL ports; they are all mapped to the Ptolemy fi xed data type port. In the case of Verilog HDL, which supports only bit and
28、 bit-vector type ports, HDL cosimulation will support any type of Verilog port. In the case of VHDL, which has a 1-4Bidirectional HDL Ports HDL Cosimulation large set of data types, HDL cosimulation will only support the ports that are of bit and bit-vector types described in the IEEE std_logic_1164
29、 library. Bidirectional HDL Ports For a bidirectional VHDL port, two ports are created on the cosimulation model. One port is an input port named In, while the other port is an output port named Out. The input data on the inout type port is applied by ADS for the fi rst half of the HDL iteration tim
30、e; the signal value is then changed to a tri-state condition. You can drive the output data on an inout type port only during the second half of the HDL iteration time, when the value has been changed to a tri-state condition by ADS. You must set the inout port to a tri-state condition during the fi
31、 rst half of the HDL iteration time period, so that ADS can drive the new input data value on the inout port. Bidirectional ports are not supported in Verilog cosimulation. Precision for Bit-Vector Type Ports1-5 Precision for Bit-Vector Type Ports Bit-vector type HDL ports that get mapped to fi xed
32、type ports require precision for data conversion. The precision for inputs and outputs is specifi ed in the parameter named “Inputs” on page 1-10 and “Outputs” on page 1-11. The precision for a port is specifi ed as two integers separated with a dot (for example 2.14). The fi rst part is the number
33、of bits used for representing the integral part and the second is the number of bits used for representing the fractional part of the value on the port. By default, the arithmetic type is twos complement. To specify an unsigned arithmetic type, append u to the precision specifi cation. For example,
34、an unsigned 2.14 can be specifi ed as 2.14u. To repeat a particular precision specifi cation you can use square bracket notation. For example, 2.14u 2.14u 2.14u 1.2 3.4 3.4 can also be represented as 2.14u3 1.2 3.42. The least signifi cant bit (LSB) of the fi xed data will always be assigned to the
35、lowest indexed element, and the most signifi cant bit (MSB) will always be assigned to the highest indexed element of the HDL vector port. Since the fi xed data bit has only two possible values (0 and 1) the values x, u, z, -, w, and l for 9-state std_logic types are mapped to 0 and the value h is m
36、apped to 1. Automatic Clock and Set Signals HDL models that have pins named Clock and Set are treated differently. The HdlCosim component has pins named Clock and Set that are modeled as optional pins, meaning you can leave them unconnected. Clock and Set must be part of your Inputs specifi cation,
37、so that they will be processed as mentioned in the section “Inputs” on page 1-10. If you connect any signal to Clock and Set pins, that signal will be passed to the HDL port. If you leave the pins unconnected, the default Clock and Set signals will be driven on the Clock and Set HDL ports. The defau
38、lt clock is of a 50% duty cycle and has a period equal to the HDL iteration time. The positive clock edge occurs at IterationTime/2. The default value for the Set pin during the fi rst iteration is a logic low at 1/4 times the HDL iteration time, a logic high at 3/4 times the HDL iteration time, and
39、 a logic high for iterations after that. 1-6 Time-Specifi ed Signals in User HDL Code HDL Cosimulation The timing of application of inputs for the HDL code generated for a mixed logic is crucial. For example consider a multiplexer (non-clocked, or in general any combinational logic) followed by a la
40、tch (clocked, or any sequential logic). The input multiplexer would be triggered the moment input is applied and would produce results with zero delay. If the following component is a clocked component (for example, sequential logic like a latch), then it will be triggered during the same iteration
41、cycle at the positive edge of the clock. So, in the above example, the multiplexer and the latch will be triggered in the same clock cycle. In the corresponding fi xed-point design, the multiplexer followed by a latch (Clock and Set unconnected) would fi re the multiplexer in one cycle and the latch
42、 in the next, producing a delay of one cycle. The HDL cosimulation results will appear one cycle earlier when compared to the equivalent ADS component simulation results. To match the results, the inputs to the HDL cosimulation block must be delayed until after the positive edge of the clock or Iter
43、ationTime/2. The inputs will be applied to multiplexer or combinational logic after the positive clock edge. The latch will latch this result only in the next fi ring of the HDL cosimulation block or the next positive clock edge (the automatic clock has one positive clock edge per fi ring). The dela
44、y for each input ports is specifi ed in the parameter “InputPhases” on page 1-10. Time-Specifi ed Signals in User HDL Code When HDL code has internal clocks or time-specifi ed signals (for example, wait statements in VHDL code) the HDL cosimulation may keep running until all the events in the user H
45、DL code are processed. The number of events generated in user HDL code can be infi nite (for example, when you have an internal clock). You can avoid using an internal clock and use the ADS Clock instead (refer to the previous section “Automatic Clock and Set Signals” on page 1-5, above). If this is
46、 not possible, then infi nite event processing can be avoided if you know how long the HDL simulation needs to run to complete the cosimulation, with all of the ADS iterations. Different simulators have different mechanisms to break a simulation after a certain simulation time. Here is an example us
47、ing ModelSim: 1. Use the ModelSim simulator to create a fi le called test.do under your projects data directory. For example, test.do may look like this: HDL Simulator Licenses1-7 run 11000 quit -f 2. SetCmdArgs = “-do test.do” (refer to “CmdArgs” on page 1-13) on the HdlCosim component block. This
48、will stop the simulation after 11000 nsec. The total run time can be calculated as equal to: The number of ADS iterations (depends on the DF controller setup and the different sinks used in the design) multiplied by the IterationTime specifi ed on the HdlCosim block. Alternatively, you can also open
49、 the ModelSim UI mode and use multiple run 100 commands to see how long it takes before the ADS has completed its simulation message appears in the ModelSim UI. This time can then be used to create the test.do fi le. Do not use the run -all command, which will process all the events in the HDL simulation. HDL Simulator Licenses The HDL simulator can only be invoked for one HDL primary design unit, like an entity or a module. So for each HDL cosimulation model, a different HDL simulator is invoked, which uses an independent license. Currently, there is no way to