X5-400M Matlab BSP Manual

X5-400M MATLAB BSP MANUAL
X5-400M Matlab BSP Manual

The X5-400M Matlab BSP Manual was prepared by the technical staff of Innovative Integration on July 14, 2010. For further assistance contact: Innovative Integration 2390-A Ward Ave Simi Valley, California 93065 PH: FAX: (805) 578-4260 (805) 578-4225
email: techsprt@innovative-dsp.com Website: www.innovative-dsp.com This document is copyright 2010 by Innovative Integration. All rights are reserved. VSS \ Distributions \ X5-400M \ Documentation \ Manual \ X5-400M BSP Master.odm #XXXXXX Rev 7.4
Innovative Integration Inc Copyright 2010
Table of Contents
X5-400M Matlab BSP Manual................................................................................................................2 Revision History.........................................................................................................................................7 Introduction................................................................................................................................................8
Key Features.......................................................................................................................................................................8 Hardware Design Using System Generator.............................................................................................................................9 Design Flows Using System Generator.............................................................................................................................9 Algorithm Exploration..................................................................................................................................................9 Implementing Part of a Larger Design.........................................................................................................................9 Implementing a Complete Design..............................................................................................................................10 System Level Modeling in System Generator.................................................................................................................10 System Generator Blockset........................................................................................................................................10 Xilinx Blockset...........................................................................................................................................................11 Innovative Integration Blockset.................................................................................................................................12 Bit-True and Cycle-True Modeling............................................................................................................................13 Timing and Clocking..................................................................................................................................................13 Automatic Code Generation.............................................................................................................................................14 Compiling and Simulating Using System Generator Block.......................................................................................14 Compilation Type and the Generate Button...............................................................................................................15 Compilation Results...................................................................................................................................................16 HDL Testbench..........................................................................................................................................................17 Compiling MATLAB Design into an FPGA...................................................................................................................17 Importing a System Generator Design into a Bigger System................................................................................................18 NGC Netlist Compilation.................................................................................................................................................18 Design Rules...............................................................................................................................................................19 Synthesis ....................................................................................................................................................................20 Simulation...................................................................................................................................................................21 Step-by-Step Example................................................................................................................................................21 Generating the NGC files for the System Generator Designs....................................................................................22 Synthesizing the Top Level Design............................................................................................................................22 Using FPGA Hardware in the Loop......................................................................................................................................23 Compiling a Model for Hardware Co-Simulation...........................................................................................................23 Choosing a Compilation Target..................................................................................................................................23 Invoking the Code Generator.....................................................................................................................................23 Hardware Co-Simulation Blocks.....................................................................................................................................24 Hardware Co-Simulation Clocking..................................................................................................................................24 Single-Step Clock.......................................................................................................................................................25 Free-Running Clock...................................................................................................................................................25 Selecting the Clock Mode..........................................................................................................................................25 Board-specific I/O Ports...................................................................................................................................................26
Software Prerequisites.............................................................................................................................27 Installation Instructions..........................................................................................................................28 Component Description...........................................................................................................................29

X5-400M Matlab BSP Manual 3
Innovative Integration Inc Copyright 2010 Overview..........................................................................................................................................................................29 ADC INTF Component....................................................................................................................................................30 DAC INTF Component....................................................................................................................................................31 DDR INTF Component....................................................................................................................................................34 ii_interleaver Component.................................................................................................................................................36 ii_deinterleaver Component.............................................................................................................................................38 ii_reorder Component......................................................................................................................................................40 ii_packetizer Component.................................................................................................................................................41 DAC SPI INTF Component.............................................................................................................................................45 PCI Express INTF Component........................................................................................................................................46 Digital IO Component......................................................................................................................................................47 System Configuration Component...................................................................................................................................48 QDR Interface Component .............................................................................................................................................50
Examples ..................................................................................................................................................53
Example: x5_400m_default.mdl......................................................................................................................................55 Example: fir_loopback.mdl..............................................................................................................................................58 Example : User Design ...................................................................................................................................................64 Procedure to generate a standalone bit image for X5-400M board.................................................................................67
Frequently Asked Questions...................................................................................................................69
List of Tables
Table 1. Xilinx Library Blocksets..........................................................................................................................................12 Table 2. Compilation Results................................................................................................................................................17 Table 3. ADC INTF Component pin assignments................................................................................................................31 Table 4. DAC INTF Component pin assignments................................................................................................................33 Table 5. DDR INTF Component pin assignments................................................................................................................35 Table 6. ii_interleaver Component pin assignments.............................................................................................................37 Table 7. ii_deinterleaver Component pin assignments.........................................................................................................39 Table 8. ii_reorder Component pin assignments..................................................................................................................40 Table 9. ii_packetizer Component pin assignments.............................................................................................................44 Table 10. Commands for DAC SPI INTF Component..........................................................................................................45 Table 11. DAC SPI INTF Component pin assignments........................................................................................................45 Table 12. PCIE TX Component pin assignments..................................................................................................................46 Table 13. PCIE RX Component pin assignments..................................................................................................................46 Table 14. Digital IO Component pin assignments.................................................................................................................47 Table 15. System Configuration Component pin assignments..............................................................................................49 Table 16. QDR Interface Component pin assignments.........................................................................................................52 Table 17. Matlab Examples for X5-400M board...................................................................................................................54
List of Figures
Figure 1. System Generator Blocksets...................................................................................................................................11 Figure 2. Innovative Integration BSP Library.......................................................................................................................12 Figure 3. Simulink Gateways.................................................................................................................................................13 Figure 4. Simulink Scope.......................................................................................................................................................14 Figure 5. Xilinx System Generator Block.............................................................................................................................15 Figure 6. Compilation Flow...................................................................................................................................................18 Figure 7. NGC compilation target.........................................................................................................................................19 Figure 8. Synthesis flow........................................................................................................................................................20 Figure 9. Design Block Diagram...........................................................................................................................................21 Figure 10. Invoking the code generator.................................................................................................................................23 Figure 11. Hardware Co-simulation......................................................................................................................................24 Figure 12. Hardware Co-simulation Library block...............................................................................................................24 Figure 13. Clock source selection for hardware Co-simulation............................................................................................25 Figure 14. Board Specific IO for X5-400M from Innovative Integration ...........................................................................26 Figure 15. X5 400M block diagram.......................................................................................................................................29 Figure 16. ADC INTF component.........................................................................................................................................30 Figure 17. ADC 0 INTF Panel...............................................................................................................................................30 Figure 18. DAC INTF component.........................................................................................................................................31 Figure 19. DAC 0 INTF panel...............................................................................................................................................32 Figure 20. DDR INTF Component........................................................................................................................................34 Figure 21. ii_interleaver component......................................................................................................................................36 Figure 22. ii_deinterleaver component..................................................................................................................................38 Figure 23. ii_reorder component...........................................................................................................................................40 Figure 24. ii_packetizer component.......................................................................................................................................41 Figure 25. ii_packetizer under the mask................................................................................................................................42 Figure 26. DAC SPI INTF component..................................................................................................................................45 Figure 27. PCIE INTF component.........................................................................................................................................46 Figure 28. DIO component....................................................................................................................................................47 Figure 29. System Configuration component........................................................................................................................48 Figure 30. QDR Interface Component...................................................................................................................................50 Figure 31. X5-400M Configuration Parameters....................................................................................................................53 Figure 32. X5_400M_default mdl file...................................................................................................................................55 Figure 33. X5-400M default Example System Generator Settings.......................................................................................56 Figure 34. X5_400M default hardware co-simulation file....................................................................................................57 Figure 35. X5_400M default hardware Co-simulation Settings............................................................................................57 Figure 36. FIR Filter Design mdl file....................................................................................................................................58 Figure 37. Low Pass Filter Design FDA Tool Setup.............................................................................................................58 Figure 38. FIR Loop back Example.......................................................................................................................................59 Figure 39. X5-400M FIR Loop back Example System Generator Settings..........................................................................60 Figure 40. FIR Loop back hardware co-simulation Example................................................................................................60 Figure 41. Hardware Co-simulation Settings........................................................................................................................61 Figure 42. DAC 0 output on the oscilloscope........................................................................................................................63 Figure 43. user_design mdl file.............................................................................................................................................64 Figure 44. X5-400M user design Example System Generator Settings................................................................................65 Figure 45. User design hardware co-simulation Example.....................................................................................................66 Figure 46. NGC netlist generation.........................................................................................................................................67 Figure 47. Clock Wrapper Example......................................................................................................................................68
Revision History
The following table shows the revision history for the Board Support Package. Date 10/28/2009 12/10/2009 Version 7.2 7.3 Revision Initial release 7.2 Matlab BSP (Amit Mane) Initial release 7.3 Matlab BSP (Amit Mane) System Clock for Matlab BSP is 200 MHz and for Framework logic is 250 MHz. PCIexpress is 4 lane for Matlab BSP and 8 lane for Framework logic Verified BSP using Rev E board 6/25/2010 7.4 Recompiled under ISE 12.1 (Amit Mane)
Introduction
System Generator for DSP is the industrys leading high-level tool for designing high performance DSP systems using FPGAs. The tool provides abstractions that enable designers to develop high performance signal processing algorithms with the industrys most advanced FPGAs, providing system modeling and automatic code generation from Simulink and MATLAB (The MathWorks, Inc.) Innovative Integration products, including the Velocia DSP and PMC cards, support FPGA development and debug through board support packages (BSP) that integrate the hardware with the System Generator with MATLAB. The BSP packages provide direct access to the hardware from the MATLAB environment for real-time, hardware-in-the-loop testing and debug.
Key Features
DSP Modeling. Build and debug high performance DSP systems in Simulink using Xilinx Blockset and Innovative Board Support Package (BSP). Xilinx blockset contains functions for signal processing such as FIR Filters and FFTs, error correction (i.e. Viterbi decoder, Reed-Solomon encoder/decoder), arithmetic, memories (e.g. FIFO, RAM,) and digital logic. The Innovative blockset contains functions for accessing various features on the board such as DDR memory, ADC, DAC, SBSRAM, RocketIO, PMC J4 interface. Automatic code generation of VHDL or Verilog from Simulink. Implement behavioral (RTL) generation and target specific IP cores from the Xilinx blockset. There is also a limited but useful ability to generate RTL functions written in MATLAB. Hardware co-simulation. Create an FPGA-in-the-Loop simulation target: a code generation option that allows you to validate working hardware and accelerate simulations in Simulink and MATLAB. Hardware/software co-design of embedded systems. Build and debug DSP co-processors for the Xilinx MicroBlaze 32-bit RISC processor. System Generator provides a shared memory abstraction of the HW/SW interface, automatically generating the DSP co-processor, the bus interface logic, software drivers, and software documentation for using the co-processor.
Hardware Design Using System Generator

System Generator is a system level modeling tool that facilitates FPGA hardware design. It extends Simulink in many ways to provide a modeling environment that is well suited to hardware design. The tool provides high level abstractions that are automatically compiled into an FPGA at the push of a button. The tool also provides access to underlying FPGA resources through low level abstractions, allowing the construction of highly efficient FPGA designs.
Design Flows Using System Generator

System Generator can be useful in many settings. Sometimes you may want to explore an algorithm without translating the design into hardware. Other times you might plan to use a System Generator design as part of something bigger. A third possibility is that a System Generator design is complete in its own right, and is to be used in FPGA hardware. This section describes all three possibilities. Algorithm Exploration System Generator is particularly useful for algorithm exploration, design prototyping, and model analysis. When these are the goals, the tool is used to flesh out an algorithm in order to get a feel for the design problems that are likely to be faced, and perhaps to estimate the cost and performance of an implementation in hardware. Work is preparatory, and there is little need to translate the design into hardware. In this setting, a designer assembles key portions of the design without worrying about fine points or detailed implementation. Simulink blocks and MATLAB .m code provide stimuli for simulations, and for analyzing results. Resource estimation gives a rough idea of the cost of the design in hardware. Experiments using hardware generation can suggest the hardware speeds that are possible. Once a promising approach has been identified, the design can be fleshed out. System Generator allows refinements to be done in steps, so some portions of the design can be made ready for implementation in hardware, while others remain high level and abstract. System Generator's facilities for incremental netlisting and hardware co-simulation are particularly useful when portions of a design are being refined. Implementing Part of a Larger Design Often System Generator is used to implement a portion of a larger design. For example, System Generator is a good setting in which to implement data paths and control, but is less well suited for sophisticated external interfaces that have strict timing requirements. In this case, it may be useful to implement parts of the design using System Generator, implement other parts outside, and then combine the parts into a working whole. A typical approach to this flow is to create an HDL wrapper that represents the entire design, and to use the System Generator portion as a component. The non-System Generator portions of the design can also be components in the wrapper, or can be instantiated directly in the wrapper.
Implementing a Complete Design Many times, everything needed for a design is available inside System Generator. For such a design, pressing the Generate button instructs System Generator to translate the design into HDL, and to write the files needed to process the HDL using downstream tools. The files written include the following:

HDL that implements the design itself A clock wrapper that encloses the design. This clock wrapper produces the clock and clock enable signals that the design needs. A HDL testbench that encloses the clock wrapper. The testbench allows results from Simulink simulations to be compared against RTL simulations in a tool such as ModelSim. Project files and scripts that allow various synthesis tools (XST and Synplify) to operate on System Generator HDL. Files that allow the System Generator HDL to be used as a project in Project Navigator
System Level Modeling in System Generator

Xilinx's System Generator allows device-specific hardware designs to be constructed directly in a flexible high level system modeling environment. In a System Generator design, signals are not just bits. They can be signed and unsigned fixed point numbers, and changes to the design automatically translate into appropriate changes in signal types. Blocks are not just stand-ins for hardware. They respond to their surroundings, automatically adjusting the results they produce and the hardware they become. System Generator allows designs to be composed from a variety of ingredients. Data flow models, traditional hardware design languages (VHDL, Verilog, and EDIF,) and functions derived from the MATLAB programming language, can be used side-by-side, simulated together, and synthesized into working hardware. System Generator simulation results are bit and cycle-accurate. This means results seen in simulation exactly match the results that are seen in hardware. System Generator simulations are considerably faster than those from traditional HDL simulators, and results are easier to analyze. System Generator Blockset A Simulink blockset is a library of blocks that can be connected in the Simulink block editor to create functional models of a dynamic system. For system modeling, System Generator blocksets are used like other Simulink blocksets in that the blocks provide abstractions of mathematical, logic, memory, and DSP functions that can be used to build sophisticated signal processing systems. There are also blocks that provide interfaces to other software tools (e.g., FDATool, ModelSim) as well as the System Generator code generation software. System Generator blocks are bit-true and cycle-true. Bit-true blocks produce values in Simulink that match corresponding values produced in hardware; cycle-true blocks produce corresponding values at corresponding times. This is in essence a what you see is what you get system that accurately represents the system performance in time and bits.
10
Figure 1. System Generator Blocksets Xilinx Blockset The Xilinx Blockset is a family of libraries that contain basic System Generator blocks. Some blocks are low level, providing access to device-specific hardware. Others are high level, implementing signal processing and advanced communications algorithms. For convenience, blocks with broad applicability (e.g., the Gateway I/O blocks) are members of several libraries. Every block is contained in the Index library as follows
Library Description
Index Basic elements Communication Control logic Data types DSP Math
Every block in the Xilinx Blockset Standard building blocks for digital logic. Forward error correction and modulator blocks, commonly used in digital communications systems. Blocks for control circuitry and state machines Blocks that convert data types (includes gateways). Digital signal processing (DSP) blocks. Blocks that implement mathematical functions. 11
Innovative Integration Inc Copyright 2010 Memory Shared memory Tools Blocks that implement and access memories. Blocks that implement and access Xilinx shared memories. "Utility" blocks, e.g., code generation (System Generator block), resource estimation, HDL cosimulation, etc. Table 1. Xilinx Library Blocksets
Innovative Integration Blockset The Innovative Integration (II) blockset is a library that contains board specific hardware and firmware components. For system modeling, these blocks can be used as Simulink blocks. Innovative Integration blockset provides means to communicate and control the resources available on the board such as DDR Memory, ADC, DAC, SRAM, RocketIO, PMC J4 interface etc.
Figure 2. Innovative Integration BSP Library
12
Bit-True and Cycle-True Modeling Simulations in System Generator are bit-true and cycle-true. To say a simulation is bit-true means that at the boundaries (i.e., interfaces between System Generator blocks and non-System Generator blocks,) a value produced in simulation is bit-for-bit identical to the corresponding value produced in hardware. To say a simulation is cycle-true means that at the boundaries, corresponding values are produced at corresponding times. The boundaries of the design are the points at which System Generator gateway blocks exist. When a design is translated into hardware, Gateway In (respectively, Gateway Out) blocks become top-level input (resp., output) ports. Timing and Clocking Discrete time systems - Designs in System Generator are discrete time systems. In other words, the signals and the blocks that produce them have associated sample rates. A block's sample rate determines how often the block is awoken (allowing its state to be updated.) System Generator sets most sample rates automatically. A few blocks, however, set sample rates explicitly or implicitly. A simple System Generator model illustrates the behavior of discrete time systems. Consider the model shown below. It contains a gateway that is driven by a Simulink source (Sine Wave,) and a second gateway that drives a Simulink sink (Scope.)
Figure 3. Simulink Gateways The Gateway In block is configured with a sample period of one second. The Gateway Out block converts the Xilinx fixed-point signal back to a double (so it can analyzed in the Simulink scope,) but does not alter sample rates. The scope output below shows the unaltered and sampled versions of the sine wave.
13
Figure 4. Simulink Scope
Multi-rate Systems - System Generator supports multi-rate designs, i.e., designs having signals running at several sample rates. System Generator automatically compiles multi-rate models into hardware. This allows multi-rate designs to be implemented in a way that is both natural and straightforward in Simulink. More information about multi-rate systems can be found in Xilinx System Generator manual.
Automatic Code Generation

System Generator automatically compiles designs into low level representations. The ways in which System Generator compiles a model can vary, and depend on settings in the System Generator block. In addition to producing HDL descriptions of hardware, the tool generates auxiliary files. Some files (e.g., project files, constraints files) assist downstream tools, while others (e.g., VHDL testbench) are used for design verification. System Generator also provides incremental netlisting, making it possible to augment models with results that System Generator itself has produced. Compiling and Simulating Using System Generator Block System Generator automatically compiles designs into low-level representations. Designs are compiled and simulated using the System Generator block. This section describes how to use the block. Before a System Generator design can be simulated or translated into hardware, the design must include a System Generator block. When creating a new design, it is a good idea to add a System Generator block immediately because it defines how the system will be compiled. The System Generator block is a member of the Xilinx Blockset's Basic Elements and Tools libraries. As with all Xilinx blocks, the System Generator block can also be found in the Index library.
14
Innovative Integration Inc Copyright 2010 A design must contain at least one System Generator block, but can contain several System Generator blocks on different levels (one per level.) A System Generator block that is underneath another in the hierarchy is a slave; one that is not a slave is a master. The scope of a System Generator block consists of the level of hierarchy into which it is embedded and all subsystems below that level. Certain parameters (e.g. Simulink System Period) can be specified only in a master. Once a System Generator block is added, it is possible to specify how code generation and simulation should be handled. The block's dialog box is shown below:
Figure 5. Xilinx System Generator Block Compilation Type and the Generate Button Pressing the Generate button instructs System Generator to compile a portion of the design into equivalent low-level results. The portion that is compiled is the sub-tree whose root is the subsystem containing the block. (To compile the entire design, use a System Generator block placed at the top of the design.) The compilation type (under Compilation) specifies the type of result that should be produced. The possible types are

Two types of Netlists, HDL Netlist and NGC Netlist Bitstream - produces an FPGA configuration bitstream that is ready to run in a hardware FPGA platform
15

EDK Export Tool - for exporting to the Xilinx Embedded Development Kit Various varieties of hardware co-simulation (i.e. Innovative Integration products) Timing Analysis - a report on the timing of the design
HDL Netlist is the type used most often. In this case, the result is a collection of HDL and EDIF files, and a few auxiliary files that simplify downstream processing. The collection is ready to be processed by a synthesis tool (e.g., XST,) and then fed to the Xilinx physical design tools (i.e. ngdbuild, map, par, and bitgen) to produce a configuration bitstream for a Xilinx FPGA. NGC Netlist is similar to HDL Netlist but the resulting files are NGC files instead of HDL files. When targeting the compile for hardware co-simulation, System Generator produces an FPGA configuration bitstream that is ready to run in a hardware FPGA platform. The particular platform depends on the variety chosen. For example, when the variety is Hardware Co-simulation->X5_400M_revE, the bitstream is suitable for the X5-400M board. System Generator also produces a hardware co-simulation block to which the bitstream is associated. This block is able to participate in Simulink simulations. It is functionally equivalent to the portion of the design from which it was derived, but is implemented by its bitstream. In a simulation, the block delivers the same results as those produced by the portion, but the results are calculated in working hardware. Compilation Results The low level files System Generator produces when HDL Netlist is selected on the System Generator block and Generate is pushed consist of HDL, NGC, and EDIF that implement the design. In addition, System Generator produces auxiliary files that simplify downstream processing, e.g., bringing the design into Project Navigator, simulating using ModelSim, and synthesizing using various synthesis tools. All files are written to the target directory specified on the System Generator block. If no testbench is requested, the key files produced by System Generator are the following:
File name or type Description
<design>.vhd/.v <design>_cw.vhd/.v .edn and .ngc files
This contains most of the HDL for the design. This is a HDL wrapper for <design>_files.vhd/.v. It drives clocks and clock enables. Besides writing HDL, System Generator runs CORE Generator (coregen) to implement portions of the design. Coregen writes EDIF files whose names typically look something like multiplier_virtex2_6_0_83438798287b830b.edn. Other required files may be supplied as .ngc files This file consists of key/value pairs that describe the design. The file is organized as a Perl hash table so that the keys and values can be made available to Perl scripts using Perl evals. This contains timing and port location constraints. These are used by the Xilinx synthesis tool XST and the Xilinx implementation tools. If the synthesis tool is set to something other than XST, then the suffix is changed to .ncf. This allows the HDL and EDIF to be brought into the Xilinx project management tool Project Navigator. This contains the full list of HDL files written by System Generator. The files are listed in the usual HDL dependency order.
globals <design>_cw.xcf (or .ncf) <design>_cw.ise hdlFiles
16
Innovative Integration Inc Copyright 2010 synplify_<design>.prj, or xst_<design>.prj Vcom.do These files allow the design to be compiled by the synthesis tool you specified
Modelsim script for behavioral simulation Table 2. Compilation Results
HDL Testbench Ordinarily, System Generator designs are bit and cycle-accurate, so Simulink simulation results exactly match those seen in hardware. There are, however, times when it is useful to compare Simulink simulation results against those obtained from an HDL simulator. In particular, this makes sense when the design contains black boxes. The Create Testbench checkbox in the System Generator block makes this possible. Suppose the design is named <design>, and a System Generator block is placed at the top of the design. Suppose also that in the block the Compilation field is set to HDL Netlist, and the Create Testbench checkbox is selected. When the Generate button is pushed, System Generator produces the usual files for the design, and in addition writes the following: 1. A file named <design>_tb.vhd/.v that contains a testbench HDL entity 2. Various .dat files that contain test vectors for use in an HDL testbench simulation 3. Scripts vcom.do and vsim.do that can be used in ModelSim to compile and simulate the testbench, comparing Simulink test vectors against those produced in HDL System Generator generates the .dat files by saving the values that pass through gateways. In the HDL simulation, input values from the .dat files are stimuli, and output values are expected results. The testbench is simply a wrapper that feeds the stimuli to the HDL for the design, then compares HDL results against expected ones.
Compiling MATLAB Design into an FPGA

System Generator provides direct support for MATLAB through the MCode block. The MCode block applies input values to an M-function for evaluation using Xilinx's fixed-point data type. The evaluation is done once for each sample period. The block is capable of keeping internal states with the use of persistent state variables. The input ports of the block are determined by the input arguments of the specified M-function and the output ports of the block are determined by the output arguments of the M-function. The block provides a convenient way to build finite state machines, control logic, and computation heavy systems. In order to construct an MCode block, an M-function must be written. The M-file must be in the directory of the model file that is to use the M-file or in a directory in the MATLAB path. Additional examples can be found at the System Generator User Guide.
17
Importing a System Generator Design into a Bigger System

A System Generator design is often incorporated as a part of a larger HDL design. This section shows how to embed two System Generator designs into a larger design, and how VHDL created by System Generator can be incorporated into a simulation model of the overall system. The most convenient way to incorporate a System Generator design into an HDL design is to encapsulate the entire design into a single binary module in the NGC binary netlist format used by the Xilinx ISE tool suite. In this case, the System Generator design is viewed as a black box by the logic synthesis tool. The design flow to import a System Generator design into a larger system is shown in Figure 6.
Figure 6. Compilation Flow
NGC Netlist Compilation

Selecting the NGC Netlist compilation target from the System Generator block, as shown in Figure 7, instructs System Generator to compile the design into a standalone Xilinx NGC binary netlist file. When System Generator is configured to exclude clock wrapper logic, the design is compiled into <design>.ngc in the target directory, where <design> is derived from the name of the portion of the System Generator model being compiled. The clock wrapper can be excluded from the design using the System Generator Token. The NGC netlist contains both the logic and constraint information for your design. This means that all HDL, cores, and constraint files normally created by System Generator are encapsulated within a single file. We will show how multiple NGC files can be used as modules in a larger design.
18
Figure 7. NGC compilation target
Design Rules When a System Generator model is to be included into a larger design, there are two design rules that must be followed. First, no Gateway or System Generator block should specify an IOB/CLK location constraint. Otherwise, the NGDBuild tool will issue the following warning: WARNING:NgdBuild:483 - Attribute "LOC" on "clk" is on the wrong type of object. Please see the Constraints Guide for more information on this attribute. Second, I/O buffers must not be inserted in the NGC netlist during synthesis. Instead, I/O buffers should be instantiated in the top level HDL code. Second, I/O buffers must not be inserted in the NGC netlist during synthesis. Instead, I/O buffers should be instantiated in the top level HDL code.
19
Innovative Integration Inc Copyright 2010 Synthesis Figure 8 shows the synthesis flow for an entire design when the NGC Netlist compilation target is used.
Figure 8. Synthesis flow The System Generator NGC module can be directly instantiated inside the top level VHDL entity as follows:
component x5_400m_implement is port ( . . . ); end component; attribute box_type of x5_400m_implement : component is "black_box"; attribute syn_black_box of x5_400m_implement : component is true;
To make this process easier, System Generator creates an HDL component instantiation template when the design is compiled using the NGC target. When VHDL is selected as the hardware description language, the template is saved in the target directory as <design>_cw.vho (or <design>.vho when the clock wrapper is excluded.) The file is saved using a .veo extension when Verilog is selected as the hardware description language. You may use the component template to instantiate the component in your top level entity. The box_type attribute should be used when synthesizing your VHDL with XST and the syn_black_box attribute should be used with Synplify.
20
Innovative Integration Inc Copyright 2010 Simulation When you compile a System Generator model into an NGC target, the VHDL files created by System Generator are necessary only for HDL simulation. They should not be included into the Project Navigator project for synthesis. This increases the performance of Project Navigator and synthesis of the top level. If you wish to run the entire design through an HDL simulator, you need to specify a custom ModelSim .do file in Project Navigator, since the VHDL files are not included in the project. In addition to the VHDL files, you will need to place the memory initialization (.mif) and coefficient (.coe) files in the same directory as the VHDL files Step-by-Step Example In this example, two NGC netlists from System Generator are imported into a larger VHDL design. Design #1 is named SPRAM and design #2 is MAC_FIR. The top level VHDL entity combines the two data ports and a control signal from the SPRAM design to create a bidirectional bus. The top level VHDL also instantiates the MAC_FIR design and supplies it a separate clock signal named clk2. A block diagram of this design is shown in Figure 9.
Figure 9. Design Block Diagram The files used in this example are provided in <path_to_sysgen>\examples\import. The default path to sysgen would be $MATLAB\toolbox\xilinx\sysgen. The following files are provided:

spram.mdl - System Generator design #1 mac_fir.mdl - System Generator design #2
Files within the sub-directory named top_level:

top_level.vhd Top level VHDL file top_level_testbench.vhd Top level VHDL testbench file
21

top_level.ise Project Navigator project for compiling top_level design top_level_testbench.do Custom ModelSim .do file wave.do ModelSim .do file called by top_level_testbench.do to display waveforms
Generating the NGC files for the System Generator Designs The steps used to create the NGC files are as follows
Open the first design, spram.mdl, in MATLAB. This is a multirate design due to the down sampling block placed after the output of the Single Port RAM. You should verify the constraints for this design have been applied properly by looking at the PAR report Double click on the System Generator block, select the NGC Netlist target and press the Generate button. By pressing the Generate button, the NGC file for this design is created in the <path_to_sysgen>\examples\import\ngc_netlist1 directory Repeat steps 1 and 2 for the mac_fir.mdl model. The NGC file for this design is created in the <path_to_sysgen>\examples\import\ngc_netlist2 directory
Synthesizing the Top Level Design The next two steps are used to synthesize the top_level design:
Copy all the .ngc files from the ngc_netlist1 and ngc_netlist2 directories to the top_level project directory so that NGDBUILD can fill the Black Box in the top_level.vhd file. The .ngc files created are named spram_cw.ngc and mac_fir_cw.ngc Now we synthesize the top-level design. In Windows Explorer, go to the <path_to_sysgen>\examples\import\top_level directory and double click on the Project Navigator project file named top_level.ise. Select top_level-behavior in the Sources in Project window and then double left click on the Place & Route Report process (the process is under Implement Design -> Place & Route) process in the Processes for Source window.
There are a few important things to keep in mind during each phase of the process. While creating a System Generator design:
IOB constraints should not be specified on Gateways in the System Generator model; neither should the System Generator block specify a clock pin location Use the NGC Netlist compilation target in the System Generator block. The NGC netlist file that System Generator produces contains both the logic and constraint information for your design
To instantiate System Generator in the top_level HDL:

Use a black box and assign the appropriate black box attribute The ce port is not connected to registers within your design. It is provide so that the VHDL file can be imported as a Black Box within System Generator 22
Using FPGA Hardware in the Loop

System Generator provides hardware co-simulation, making it possible to incorporate a design running in an FPGA directly into a Simulink simulation. Hardware Co-simulation compilation targets automatically create a bitstream and associate it to a block. When the design is simulated in Simulink, results for the compiled portion are calculated in hardware. This allows the compiled portion to be tested in actual hardware, and can speed up simulation dramatically.
Compiling a Model for Hardware Co-Simulation

The starting point for hardware co-simulation is the creating in MATLAB with System Generator a model or subsystem you would like to run in hardware. A model can be co-simulated, provided it meets the requirements of the underlying hardware platform. This model must include a System Generator block; this block defines how the model should be compiled into hardware. The first step, once you have a model that you are ready to run in hardware, is to open the System Generator block dialog box and select a compilation type under Compilation. Choosing a Compilation Target You may choose the hardware co-simulation platform you would like System Generator to compile code for by selecting an appropriate compilation type in the System Generator block dialog box. Hardware co-simulation targets are organized under the Hardware Co-Simulation sub-menu in the Compilation dialog box field. When you install System Generator, several hardware co-simulation compilation targets are automatically installed. You may also install additional plug-in compilation targets that add hardware co-simulation support for your FPGA platform. Invoking the Code Generator Once you have selected a compilation target you can invoke the System Generator code generator to compile the model for hardware co-simulation. The code generator is invoked by pressing the Generate button in the System Generator block dialog box as shown in Figure 10. The code generator produces a FPGA configuration bitstream for your design that is suitable for hardware co-simulation. System Generator not only generates the HDL and netlist files for your model during the compilation process, but it also runs the downstream tools necessary to produce an FPGA configuration file. The configuration bitstream contains the hardware associated with your model, and also contains additional interfacing logic that allows System Generator to communicate with your design using a physical interface between the platform and the PC. This logic includes a memory map interface over which System Generator can read and write values to the input and output ports on your design. It also includes any platform-specific circuitry (e.g., DCMs, external component wiring) that is required for the target FPGA platform to function correctly.
Figure 10. Invoking the code generator
23
Hardware Co-Simulation Blocks

System Generator automatically creates a new hardware co-simulation block once it has finished compiling your design into an FPGA bitstream. A Simulink library is also created in order to store the hardware co-simulation block. At this point, you can copy the block out of the library and use it in your System Generator design as you would other Simulink and System Generator blocks.
Figure 11. Hardware Co-simulation The hardware co-simulation block assumes the external interface of the model or subsystem from which it is derived. The port names on the hardware co-simulation block match the ports names on the original subsystem. The port types and rates also match the original design.
Figure 12. Hardware Co-simulation Library block
Hardware Co-Simulation Clocking

There are several ways in which a System Generator hardware co-simulation block can be synchronized with its associated FPGA hardware. In single-step mode, the FPGA is in effect clocked from Simulink, whereas in free-running clock mode, the FPGA runs off an internal clock, and is sampled asynchronously when Simulink wakes up the hardware co-simulation block.
24
Innovative Integration Inc Copyright 2010 Single-Step Clock In single-step clock mode, the hardware is kept in lock step with the software simulation. This is achieved by providing a single clock pulse (or some number of clock pulses if the FPGA is over-clocked with respect to the input/output rates) to the hardware for each simulation cycle. In this mode, the hardware co-simulation block is bit-true and cycle-true to the original model. Because the hardware co-simulation block is in effect producing the clock signal for the FPGA hardware only when Simulink awakens it, the overhead associated with the rest of the Simulink model's simulation, and the communication overhead (e.g. bus latency) between Simulink and the FPGA platform can significantly limit the performance achieved by the hardware. As a general rule of thumb, as long as the amount of computation inside the FPGA is significant with respect to the communication overhead (e.g. the amount of logic is large, or the hardware is significantly over-clocked,) the hardware will provide significant simulation speed-up. Free-Running Clock In free-running clock mode, the hardware runs asynchronously relative to the software simulation. Unlike the single-step clock mode, where Simulink effectively generates the FPGA clock, in free-running mode, the hardware clock runs continuously inside the FPGA itself. In this mode, simulation is not bit and cycle true to the original model, because Simulink is only sampling the internal state of the hardware at the times when Simulink awakes the hardware co-simulation block. The FPGA port I/O is no longer synchronized with events in Simulink. When an event occurs on a Simulink port, the value is either read from or written to the corresponding port in hardware at that time. However, since an unknown number of clock cycles have elapsed in hardware between port events, the current state of the hardware cannot be reconciled to the original System Generator model. For many streaming applications, this is in fact highly desirable, as it allows the FPGA to work at full speed, synchronizing only periodically to Simulink. In free-running mode, you must build explicit synchronization mechanisms into the System Generator model. A simple example is a status register, exposed as an output port on the hardware co-simulation block, which is set in hardware when a condition is met. The rest of the System Generator model can poll the status register to determine the state of the hardware. Selecting the Clock Mode Not every hardware platform supports a free running clock. However, for those that do, the parameters dialog box for the hardware co-simulation block provides a means to select the desired clocking mode. You may change the co-simulation clocking mode before simulation starts by selecting either the Single stepped or Free running radio button under the Clocking etch box.
Figure 13. Clock source selection for hardware Co-simulation
25
Board-specific I/O Ports

FPGA platforms often include a variety of on-board devices (e.g., external memory, analog to digital converters, etc.) that the FPGA can communicate with. For a variety of reasons, it may be useful to form connections to these components in your System Generator models, and to use these components during hardware co-simulation. For example, if your board includes external memory, you may want to define the control and interface logic to this memory in your System Generator design, and use the physical memory during hardware co-simulation. You can interface to these types of components by including board-specific I/O ports in your System Generator models. A board-specific port is a port that is wired to an FPGA pad when the model is compiled for hardware co-simulation. Note that this type of port differs from standard co-simulation ports that are controlled by a corresponding port on a hardware cosimulation block.
Figure 14. Board Specific IO for X5-400M from Innovative Integration A board-specific I/O port is implemented using special non-memory mapped gateway blocks that tell System Generator to wire the signals to the appropriate FPGA pins when the model is compiled into hardware. To connect a System Generator signal to a board-specific port, connect the appropriate wire to the special gateway (in the same way as is done for a traditional gateway.) Non-memory mapped gateways that are common to a specific device are often packaged together in a Simulink subsystem or library. The Innovative Integration BSP, for example, provides a library of external device interface subsystems, including analog to digital converters, digital to analog converters, RocketIOs, and external memory. The interface subsystems are constructed using Gateways that specify board-specific port connections. These subsystems are treated like other System Generator subsystems during simulation (i.e., they perform double precision to Xilinx fixed-type conversions.) When System Generator compiles the design into hardware it connects the signals that are associated with the Gateways to the appropriate external devices they signify in hardware. X5-400M Matlab BSP Manual 26
Software Prerequisites
You must have the following software installed before installing the System Generator.

Microsoft Windows XP professional Sp2 or Sp3 (32 Bit) One of the following versions of MATLAB from Mathworks Inc. 1. 2. Matlab 7.8 (R2009a) /Simulink V7.3 (R2009a) Matlab 7.9 (R2009b) /Simulink V7.4(R2009b)
Note : Matlab/Simulink must be installed in a directory with no spaces e.g C:\matlab

Xilinx System Generator 12.1 Xilinx ISE Foundation 12.1 along with inbuilt ISE simulator
Note : Xilinx ISE must be installed in a directory with no spaces e.g C:\Xilinx Some other features in System Generator require following software components to be installed:
HDL simulator required for HDL cosimulation using Xilinx System Generator and Simulink.System Generator HDL co-simulation interfaces are compatible with Xilinx ISE Simulator, ModelSim Xilinx Edition MXE (an option with ISE Foundation) and ModelSim PE or SE, version v6.5b or later, from Model Technology Inc. Xilinx Chipscope Pro 12.1 is required for on chip debugging
Note: Please make sure that Microsoft windows Environment variable $Xilinx must be set and point to your ISE software installation directory. Any new further updates may be downloaded from Xilinx Download center. Note : Environment variables TEMP and TMP must be set to C:/TEMP
27
Installation Instructions
The X5-400M module BSP is provided as a zip file named x5_400M_rev*.zip. This zip file can be found at Root Directory>\400M\Matlab\rev_*\BSP. Follow the steps listed below to install Board Support Package 1. If you have already installed X5-400M BSP, please make sure that following folders are deleted before a fresh installation. - ii_dsp_lib -> This folder is located at C:\Innovative\Sysgen\ -- X5_400M_rev* --> This folder is located at <Sysgen Root > \plugins\compilation\Hardware Co-Simulation 2. 3. 4. 5. Open Matlab and change the Matlab current directory to C:\<X5 Root Directory>\400M\Matlab\rev_#/BSP which contains the the x5_400m_rev*.zip file. type setup_x5_400m on Matlab Command prompt Restart Matlab type xlrehash_xltarget_cache on the Matlab command prompt C:\<X5
X5-400M Module provides a Simulink library located at <Xilinx root directory>\dsp_tools\sysgen\plugins\compilation\Hardware Co-Simulation\x5_400m_rev*. Target FPGA is XC5VSX95T-1. All the examples can be found under C:\<X5 Root Directory>\400M\Matlab\rev_*\Examples The compilation and implementation properties can be changed to fit user specific requirements. The required file is stored at

<System Generator Root>\sysgen\hwcosim\jtag\balanced_jtag.opt <System Generator Root>\sysgen\hwcosim\jtag\bitgen_jtag.opt
28
Component Description
Overview
The block diagram below shows hardware structure inside FPGA. The blue components are infrastructures for communication with onboard devices, such as DDR, QDR, ADC, DAC. The white block is MATLAB/Simulink component allowing us to do graphical design and hardware co-simulation. The green blocks are II blocks to talk to the infrastructures. Your design can be built and simulated using Xilinx System Generator. Then you can put the project on the datapath and use the interface component as required. The whole design can be compiled to a bitstream, downloaded to FPGA, and simulated with hardware. After the design is verified in hardware co-simulation, jtag gateways can be removed and the project can be synthesized as a stand alone logic in the hardware. DDR2 Queue 0 128
DDR Queue 0
Offset/ gain 32 Offset/ gain
ADC0
FIFO 32i32o
Alert
32
Trigger
32
Packetizer
ADC0
Offset/ gain Offset/ gain Offset/ gain Offset/ gain
ADC1
FIFO 32i32o
32
DAC0
FIFO 32i16o
PCIE
64
PCIE INTF
ADC1
User Design
DAC0
16
Trigger
DAC1
64
MATLAB/ Simulink
32
DDR Queue 1 QDR SRAM
Offset/ gain Offset/ gain
DAC1
FIFO 32i16o
128 deframer DDR2 Queue 1
16
QDR Digital IO SRAM /Serial RapidIO Figure 15. X5 400M block diagram
DAC SPI
29
ADC INTF Component

This component sends out data after triggering at sample clock and error correction. Settings, such as software trigger, are from Simulink when en_config = 1 in System Configuration block. Test ramp is enabled when test = 1 for both ADC channels. Data sampled at time t is put in data(31 downto 16), and data sampled at time t+1 is put in data(15 downto 0). data(31 downto 16) = adc(t); data(15 downto 0) = adc(t+1); The configuration panel in ADC0 INTF block provides the controls to trigger, enable frame mode, and calibrations without host software. When Use External Trigger is checked, trigger from SYNC port is used as ADC/DAC trigger. When Trigger Type is set to Level, ADC samples data when trigger is high. When Trigger Type is set to Positive Edge, ADC samples data after the first positive edge of trigger. There is an embedded flow control for ADC interface. For example, you can use destination FIFO not empty flag as dest_rdy for adc0_intf; or you can watch the destination FIFO write count and send a ready flag when the count is less than a threshold.
Figure 16. ADC INTF component
Figure 17. ADC 0 INTF Panel
30
Pin test trig dest_rdy data[31:0] valid
Direction In In In Out Out
Function Test ramp enable Software trigger Destination ready Input data Data valid
Table 3. ADC INTF Component pin assignments
DAC INTF Component

This component is passing data for triggering at sample clock and error correction. Settings, such as software trigger, are from Simulink when en_config = 1 in System Configuration block. Test signal is enabled when test = 1 for both DAC channels. Port test mode = 0 enables a ramp, and test mode = 1 enables a sine wave generator. Ports "phase_inc0" and "phase_inc1" are the phase increment for the dual tone sine wave generator. phase_inc = output frequency * 2^24 / dac_ref_clk; data(31 downto 16) = dac(t); data(15 downto 0) = dac(t+1); The configuration panel provides the controls for calibration and enable frame mode without host software. When Use External Trigger is checked, trigger from SYNC port is used as ADC/DAC trigger. When Trigger Type is set to Level, ADC samples data when trigger is high. When Trigger Type is set to Positive Edge, ADC samples data after the first positive edge of trigger. Data can be sent with a valid signal by watching the level of ready flag.
Figure 18. DAC INTF component
31
Figure 19. DAC 0 INTF panel
Pin test trig data[31:0]
Direction In In In
Function Software trigger Software trigger Output data
32
Innovative Integration Inc Copyright 2010 Pin wr test_mode[1:0] Direction In In Function Write strobe Test signal select '0' => ramp; '1' => sine wave Phase increment phase_inc = output_freq * 2^24 / dac_ref_clk Phase increment phase_inc = output_freq * 2^24 / dac_ref_clk FIFO is ready for incoming data
phase_inc0[23:0]
In
phase_inc1[23:0]
In
rdy
Out
Table 4. DAC INTF Component pin assignments
33
DDR INTF Component

In X5-400M, two 256 MByte queues of virtual FIFO have been implemented. Each queue is independently managed and is essentially a large data FIFO for each ADC and DAC data flow. For the 128 bits din and dout ports, the first 16 bits data should be aligned to the MSB, and the last data is aligned to LSB as follows. The queues can be used for any purpose. In the FrameWork Logic, the queues are used to buffer the incoming data from ADCs and outgoing data to the DACs. din(127 downto 112) = data(t); din(111 downto 96) = data(t+1); din( 95 downto 80) = data(t+2); din( 79 downto 64) = data(t+3); din( 63 downto 48) = data(t+4); din( 47 downto 32) = data(t+5); din( 31 downto 16) = data(t+6); din( 15 downto 0) = data(t+7);
Figure 20. DDR INTF Component
Pin din[127:0] wr rd dout[127:0]
Direction In In In Out
Function Input data Write strobe Read strobe Output data
34
Innovative Integration Inc Copyright 2010 Pin valid ofifo_empty ofifo_aempty ififo_rdy Direction Out Out Out Out Function Data valid Output FIFO empty flag Output FIFO almost empty flag Input FIFO ready signal
Table 5. DDR INTF Component pin assignments
35
ii_interleaver Component
This component interleaves incoming 32 bits data from two input channels as follows. channel_en(0) = 1 => channel 0 is enable; channel_en(1) = 1 => channel 1 is enable. Both channels are enabled. At time = t, din0(31 downto 0) is [a | b]; din1(31 downto 0) is [c | d]. At time = t+1, din0(31 downto 0) is [e | f]; din1(31 downto 0) is [g | h]. At time = t+2, dout(127 downto 0) is [c | a | d | b | g | e | h | f]. Only one channel is enabled. At time = t, din0(31 downto 0) is [a | b]; din0(31 downto 0) is [c | d]. At time = t+1, din0(31 downto 0) is [e | f]; din0(31 downto 0) is [g | h]. At time = t+2, dout(127 downto 0) is [a | b | c | d | e | f | g | h].
Figure 21. ii_interleaver component Pin reset ch_en[1:0] Direction In In Function Reset Channel enable; bit 0 is for channel 0 and bit 1 is for channel 1. Data in
din0[31:0]
In
36
Innovative Integration Inc Copyright 2010 Pin din1[31:0] wr0 wr1 check_en dout[127:0] valid status chipscope_data[127:0] Direction In In In In Out Out Out Out Function Data in Write strobe Write strobe Enable data checker Data out Data valid Data checker status Chipscope test vector
Table 6. ii_interleaver Component pin assignments
37
ii_deinterleaver Component
This component deinterleaves incoming 128 bits data to two output channels as follows. channel_en(0) = 1 => channel 0 is enable; channel_en(1) = 1 => channel 1 is enable. Both channels are enabled. At time = t, din(127 downto 0) is [a | b | c | d | e | f | g | h]. At time = t+1, dout0(31 downto 0) is [b | d]; dout1(31 downto 0) is [a | c]. At time = t+2, dout0(31 downto 0) is [f | h]; dout1(31 downto 0) is [e | g]. Only one channel is enabled. At time = t, din(127 downto 0) is [a | b | c | d | e | f | g | h]. At time = t+1, dout0(31 downto 0) is [a | b]. At time = t+2, dout0(31 downto 0) is [c | d]. At time = t+3, dout0(31 downto 0) is [e | f]. At time = t+4, dout0(31 downto 0) is [g | h].
Figure 22. ii_deinterleaver component
Pin reset ch_en[1:0]
Direction In In
Function Reset Channel enable; bit 0 is for channel 0 and bit 1 is for channel 1.
38
Innovative Integration Inc Copyright 2010 Pin src_empty src_aempty src_din[127:0] src_valid dest0_rdy dest1_rdy src_rd_en dest0_dout[31:0] dest0_valid dest1_dout[31:0] dest1_valid Direction In In In In In In Out Out Out Out Out Function Source FIFO empty flag Source FIFO almost empty flag Data in Data valid Destination ready Destination ready Read enable to source Data out Data valid Data out Data valid
Table 7. ii_deinterleaver Component pin assignments
39
ii_reorder Component
This component is used to re-order the data for little-endian system. It is usually used in front of packetizer to rearrange the data for little-endian system. When both channels are enabled, input data is [data1(t) | data0(t) | data1(t+1) | data0(t+1)]. Output data is [data1(t) | data0(t) | data1(t+1) | data0(t+1)]. When one channel is enabled, input data is [data0(t) | data0(t+1) | data0(t+2) | data0(t+3)]. Output data is [data0(t+1) | data0(t) | data0(t+3) | data0(t+2)].
Figure 23. ii_reorder component
Pin din[127:0] dout[127:0] adc_ch_en
Direction In Out In(1..0)
Function Input data Output Adc channel Enable
Table 8. ii_reorder Component pin assignments
40
ii_packetizer Component
This component packetizes the incoming data with a header, including packet ID and packet size. The packetizer will collect enough data according to the packet size from one channel, packetize the data with header, and move to the next enabled channel. Currently, channel 0 is reserved to alert component. If we look under the mask, the packetizer is instantiated as a Xilinx System Generator black box. The corresponding files are located in <Xilinx root>\DSP_Tools\sysgen\plugins\compilation\Hardware Co-Simulation\X5_400M_Rev#\ii_packetizer_config.m and C:\Innovative\Sysgen\II_DSP_LIB\vhdl\X5\ii_packetizer.vhd. More sophisticated packet system can be made by changing the vhdl code and m file. Details can be found in Xilinx System Generator Help by typing Black Box. Be aware to keep all the yellow gateways, which are the input/output non-memory map ports to the top FrameWork Logic file.
Figure 24. ii_packetizer component
41
Figure 25. ii_packetizer under the mask
Pin reset ch1_din[63:0] ch2_din[63:0] ch3_din[63:0] ch4_din[63:0] ch5_din[63:0] dest_rdy
Direction In In In In In In In
Function Reset Input data Input data Input data Input data Input data PCIe Destination ready signal
42
Innovative Integration Inc Copyright 2010 Pin ch2_pd_addr[7..0] ch3_pd_addr[7..0] ch4_pd_addr[7..0] ch5_pd_addr[7..0] aux_hdr2[31..0] ch2_pkt_size[23..0] ch3_pkt_size[23..0] ch4_pkt_size[23..0] ch5_pkt_size[23..0] ch1_empty ch2_empty ch3_empty ch4_empty ch5_empty ch1_aempty ch2_aempty ch3_aempty ch4_aempty ch5_aempty Direction In In In In In In In In In In In In In In In In In In In Function Peripheral ID for channel 2 Peripheral ID for channel 3 Peripheral ID for channel 4 Peripheral ID for channel 5 Auxiliary header Ch2 packet size Ch3 packet size Ch4 packet size Ch5 packet size Empty signal Empty signal Empty signal Empty signal Empty signal Almost Empty signal Almost Empty signal Almost Empty signal Almost Empty signal Almost Empty signal
43
Innovative Integration Inc Copyright 2010 Pin ch1_din_vld ch2_din_vld Ch3_din_vld Ch4_din_vld Ch5_din_vld data_out[63:0] data_out_vld ch1_rden ch2_rden ch3_rden ch4_rden ch5_rden Direction In In In In In Out Out Out Out Out Out Out Function Data valid signal Data valid signal Data valid signal Data valid signal Data valid signal Data to PCIe interface Data valid signal Ch1 read signal Ch2 read signal Ch3 read signal Ch4 read signal Ch5 read signal
Table 9. ii_packetizer Component pin assignments
44
DAC SPI INTF Component

This component is an SPI port interface to the TI DAC5687. DAC5687 is configured prior to operation for data modes, clock configurations and other initialization steps over this SPI port. MATLAB/Simulink provides an easy way to configure registers by editing vectors in MATLAB Workspace and send them through SPI interface. There is a dac_pll.m file in every example folder for the simple PLL configuration. In MATLAB Command Window, please type [spi_addr, spi_data, spi_wr]=dac_pll( ref_clk, interpolation ), where ref_clk is the clock source from on board crystal or external clock; and interpolation can be 1, 2, 4 to match the input data rate plllock (dac_clk), which is basically the same as ref_clk, and output sample rate (Fdac) of DAC5687. There are some examples in the following table. More complicated operations can be done by changing the register values through the SPI interface. Please download the datasheet for advanced applications. (http://focus.ti.com/docs/prod/folders/print/dac5687.html ) Command [spi_addr, spi_data, spi_wr]=dac_pll( 125, 1 ) [spi_addr, spi_data, spi_wr]=dac_pll( 250, 2 ) [spi_addr, spi_data, spi_wr]=dac_pll( 500, 4 ) Fdac (MHz) 125 250 500 dac_clk (MHz) 125 125 125 interpolation 1 2 4
Table 10. Commands for DAC SPI INTF Component
Figure 26. DAC SPI INTF component
Pin addr[4:0] data[7:0] wr
Direction In In In
Function SPI address SPI data Write strobe
Table 11. DAC SPI INTF Component pin assignments
45
PCI Express INTF Component

PCIE TX component sends packets to the host through PCI Express interface and RX component deframes the data from PCI Express interface. The input and output data width is 64 bits. Rdy signal from the Tx interface is used for pacing the data flow. When rdy='1' PCI_TX_INTF can accept more data. For the PCIE_RX_INTF data, the order is as follows. din(63 downto 48) = data(t); din(47 downto 32) = data(t+2); din(31 downto 16) = data(t+3); din(15 downto 0) = data(t+4).
Figure 27. PCIE INTF component Pin data[63:0] wr rdy Direction In In Out Function Output data Write strobe PCI express Transmit Interface Ready signal
Table 12. PCIE TX Component pin assignments
Pin data[63:0] valid
Direction Out Out
Function Input data Data valid
Table 13. PCIE RX Component pin assignments
46
Digital IO Component
This component is a simple digital IO port that has an input register and output register. It may be used as a simple digital control port or easily customized. Port dio_en controls a mux to use data from the software or MATLAB/Simulink project. The 33 bit rx_data is connected to a register, which is written when rd is low. tx_data writes the output register when wr is high. The source VHDL is available in <X5 root>\400M\Logic\Rev#\source\ii_dio.vhd.
Figure 28. DIO component
Pin dio_en
Direction In
Function '1' => data from MATLAB '0' => data from software Transmitted data Input/output direction control ctrl(0) = '1' => ud( 7 downto 0 ) is an output ctrl(1) = '1' => ud( 15 downto 8 ) is an output ctrl(2) = '1' => ud( 23 downto 16 ) is an output ctrl(3) = '1' => ud( 31 downto 24 ) is an output ctrl(4) = '1' => ud( 33 ) is an output Write strobe for tx_data Read strobe for rx_data Received data
tx_data[32:0] ctrl[4:0]
In In
wr rd rx_data[33:0]
In In Out
Table 14. Digital IO Component pin assignments
47
System Configuration Component

This component provides communication with the host computer and allows controls from ctl_reg44~47 and read data back through status44~47. Port en_config enables the settings, such as test, test mode, gain/offset, and DAC SPI interface, from Simulink environment. If en_config = 0, all the settings are from the host software. This port provides the possibility to work without supports from software in logic development. Using clk_sel, users can use the onboard crystal or external clock as ADC/DAC sample clock. Port clk_locked shows DCM is locked and DDR, QDR are ready to be used. Port sys_reset provides system reset to Simulink components. When adc_run or dac_run is low, sys_reset is high. You can generate a reset for every run from software. Port init_reset provides a one time reset after the FPGA is loaded. Port ext_sync makes it possible to use external trigger in the MATLAB project. On the panel, ADC sample clock can be sent to SYNC port for debug purpose, or use SYNC port as an external trigger input.
Figure 29. System Configuration component
Pin en_config
Direction In
Function Enable Configuration from Simulink '1' => From Simulink; '0' => From the host. status_reg(44) to PCI Express interface status_reg(45) to PCI Express interface
status44[31:0] status45[31:0]
In In
48
Innovative Integration Inc Copyright 2010 Pin status46[31:0] status47[31:0] clk_sel Direction In In In Function status_reg(46) to PCI Express interface status_reg(47) to PCI Express interface Clock select '0' => external clock; '1' => 400 MHz onboard clock. Enable sync to ADC sample clk General Purpose Data from Matlab to Framework Logic Clock locked signal sys_clk, ddr_ref_clk, qdr1_dcm are locked. ddr2_dcm, qdr0_dcm,
sync_en matlab_gp_out[31..0] clock_locked
In In Out
Temp[9:0]
Out
Temperature data Temperature = temp * 0.492 - 273.15 Reset is high if adc_run or dac_run is low. Reset after loading the FPGA External trigger ctl_reg(44) from PCI Express interface ctl_reg(45) from PCI Express interface ctl_reg(46) from PCI Express interface ctl_reg(47) from PCI Express interface General Purpose data from Framework Logic to Matlab ADC channel Enable signal DAC channel enable signal
sys_reset init_reset ext_sync ctl_reg44[31:0] ctl_reg45[31:0] ctl_reg46[31:0] ctl_reg47[31:0] matlab_gp_in[31..0] adc_ch_en[1..0] dac_ch_en[1..0]
Out Out Out Out Out Out Out Out Out Out
Table 15. System Configuration Component pin assignments X5-400M Matlab BSP Manual 49
Innovative Integration Inc Copyright 2010 QDR Interface Component The X5-400M has two 512Kx36 QDR-II SRAM memory banks comprised of one Cypress Technology CY7C1314BV18 (or equivalent) device each. QDR-II architecture has a separate read and write port to access the memory array so that concurrent accesses are supported. The read port has dedicated data outputs to support read operations and the write port has dedicated data inputs to support write operations. QDR-II architecture has separate data inputs and data outputs to completely eliminate the need to turn-around the data bus required with common I/O devices. Access to each port is accomplished through a common address bus. QDR component can be used in variety of ways. Enable input allows the access from Matlab/Simulink environment. QDR memory can be used to snap real time data. This data can be read into the Matlab/Simulink environment using the slow JTAG cable. In this setting user can set fast_mode = '1' and set the end_addr to limit the number of points to be written into the memory. wt_addr input specifies the start address. This memory can also be used in a FIFO mode by setting fifo_mode_en= '1'. In this mode user specifies the threshold at which the rdata_rdy flag is set. Maximum allowed threshold is 1023. fifo_rd signal is used to read this data from the QDR memory component. In this mode once the rdata_rdy flag is set, user must read all the points specified as fifo_threshold. QDR memory can also be used as regular random access memory. When enable='0', fifo_mode_en ='0' and fast_mode = '0', data can be written using wt_addr wt_data and wt signals. For reading the data rd_addr and rd signals are used. The read data is available as rd_data port along with rd_valid signal. Table shows all the signals associated with qdr intf component .
Figure 30. QDR Interface Component
50
Pin enable
Direction In
Function Enable ='1' QDR can be accessed from Matlab/Simulink environment. Enable = '0' QDR is available Active high reset signal fast_mode = '1' allows the data capture into QDR memory at system clock rate Rollover = '1' means once the write address equals the end_addr in fast_mode , the write address is rolled back to start address. Rollover = '0' means writes to memory are ignored once the write address reaches end_addr
reset fast_mode rollover
In In In
end_addr[17:0] wt_addr[17:0] wt_data[63:0] wt read_addr[17:0] rd fifo_mode_en
In In In In In In In
End address for the fast_mode wt_addr specifies the write address to the QDR memory in regular SRAM mode or FIFO mode Data to be written into the memory Write enable Read address Read enable fifo_mode = '1'; rdata_rdy ='1' when QDR memory FIFO reaches fifo_thresh. User can read the data continuously from the memory. fifo_thresh Threshold for the FIFO wt_rdy = '1' means data can be written into the QDR memory.wt_rdy = '0' means QDR memory busy
fifo_rd fifo_thresh[9:0] wt_rdy
In In Out
51
Innovative Integration Inc Copyright 2010 Pin raddr_rdy Direction Out Function raddr_rdy='1' means new read access is allowed. raddr_rdy='0' means QDR busy rdata_rdy rd_data[63:0] rd_valid Out Out Out rdata_rdy = '1' means read data is available in the FIFO. Useful in FIFO mode Read data from the QDR memory Read valid signal
Table 16. QDR Interface Component pin assignments
52
Examples
Numerous examples are provided with the board support package to demonstrate the functionality of various features on the board. All the examples are stored at <your top folder>\400\Matlab\rev_#\Examples. These examples can be used to implement the user intended functionality. All the examples consist of two different Simulink .mdl files namely the design file and the hardware Co-simulation file. The H/W Co-simulation file essentially consists of bitstream and the gateways associated with the bitstream to perform real time testing of the logic. The hardware co-simulation is done using a Parallel IV cable or a USB cable. Before running all the examples, please make sure that H/W Co-simulation block is in free running mode. You can set the simulation parameters as follows
Simulation->configuration parameters->solver options type=fixed-step; solver=discrete(no continuous state)
Figure 31. X5-400M Configuration Parameters
53
Innovative Integration Inc Copyright 2010 File name (.mdl) x5_400m_default fir_loopback user_design Contents This example shows standard connections in FrameWork Logic for data acquisition. This example shows data loopbacked from ADC to DAC through a FIR lowpass filter. This example shows explains where and how to place an user's application. Table 17. Matlab Examples for X5-400M board On X5 400M board, users need to run dac_pll.m to generate PLL setting for DAC SPI interface. Enter [spi_addr, spi_data, spi_wr]=dac_pll(125,1); in MATLAB Command Window to generate a configuration. Read Component Description\DAC SPI INTF for more details. Users can edit vectors in dac_pll.m and send them through SPI interface for different applications. To use the settings from Simulink environment, please make sure that en_config = '1'. To give controls back to the host software, please set en_config = '0'.
54
Innovative Integration Inc Copyright 2010 Example: x5_400m_default.mdl This example shows standard connections in FrameWork Logic. The 32 bits ADC 0 and ADC 1 data is interleaved and sent to DDR queue 0 for data buffering. The data out of queue 0 goes through an asymmetric FIFO and packetized for PCIE_TX_INTF. Data movements between FIFOs are flow controlled by ii_flow_ctrl or data valid strobe. Data from the host is removed header and sent to MATLAB component through PCIE_RX_INTF, buffered in DDR queue 1, and deinterleaved as two 32 bits data for DAC 0 and DAC 1.The project is actually a component in FrameWork Logic, and the board support package interface blocks are wrappers for the input/output ports. So most of the components are necessary to be instantiated in the compilation. For example, you need to keep System_Configuration, ADC0/1_INTF, DAC0/1_INTF, DDR_Queue_0/1, ii_packetizer, PCIE_TX/RX_INTF, SRAM0/1_INTF, DIO_INTF, DAC_SPI_INTF. You can remove ii_interleaver, ii_deinterleaver, ii_flow_ctrl, ii_reorder, V5_FIFO. The rest yellow gateways will become jtag ports exchanging data between MATLAB/Simulink and FPGA in hardware co-simulation.
Figure 32. X5_400M_default mdl file To compile this example for hardware Co-simulation follow these steps:

Select Simulink system period (sec) = 1/200e6 by typing Ts=1/200e6 on Matlab command prompt. Double click on Xilinx System Generator token and enter the following in the resulting window Select x5_400m_revE as compilation target Select target directory for the compilation results as netlist_default 55

Select synthesis tool as XST Select hardware description language as VHDL Set Simulink System Period (sec) as Ts Click on generate
Figure 33. X5-400M default Example System Generator Settings As a result of compilation, a hardware co-simulation library component will be generated, which will be used for actual hardware co-simulation. Default example is provided with x5_400m_default_hwcosim.mdl file. All the non memory mapped gateways appear in the Simulink generated hardware co-simulation library. Figure below shows the hardware co-simulation mdl file. If the project is compiled without any timing problem, a hardware co-simulation block and a bit file will be generated in the target folder. We can create signal sources from Simulink toolbox and send them to FPGA through JTAG cable. After loading the generated bit file through Xilinx JTAG pod, the FPGA is free running at system clock. You need to restart the computer or re-enumerate the board in Windows Device Manager to enable PCI Express connection. After rebooting the machine, please run hardware co-simulation with Skip device configuration checked as in figure shown below. Which avoids loading the logic and removing the PCI Express connection again.
56
Figure 34. X5_400M default hardware co-simulation file To run this example on FPGA, follow these steps: 1. 2. Connect the Xilinx POD to JP1 on X5-400M board Double click on X4_400M_default_hwcosim component, enable the clock source as free running and browse for appropriate default example bitfile in the resulting window, then press OK.
Figure 35. X5_400M default hardware Co-simulation Settings 3. 4. 5. 6. 7. Click on Simulation Run Button to start the example As a result, the FPGA bit file is loaded on Viretx5 FPGA device on X5-400M board Using device manager on the host PC, reenumerate the board In case re-running of the example is desired, the need to re-enumerate the board can be avoided by double clicking on X4_400M_default_hwcosim component and enabling skip device configuration mode under advanced settings. Open Snap Example from <Innovative Malibu Root>X5-400M\Examples\Wave\Bcb11\Release . Select appropriate BusMaster memory size. Capture the data from A/Ds. 57
Innovative Integration Inc Copyright 2010 Example: fir_loopback.mdl In this example, a signal from ADC0_INTF is loop-backed through a low pass filter to DAC0_INTF. ADC/DAC sample rate is set as 67.5Mhz with external clock and system clock is 200 MHz. User can select other sampling rates below 200MHz using external clock. Note that the System clock is 200MHz for hardware co-simulation and hence maximum sample clock is 200MHz. The 32 bits ADC data is converted to 16 bits using a asymmetric FIFO for digital signal processing. It is converted to 32 bits data again for DAC0_INTF. The flow control is done by using ii_flow_ctrl and FIFO write count. Figure below shows the filter design mdl file. FDATool is used to design the Low Pass filter. The passband of the frequency response is 0.1 and the stopband is 0.2 of the normalized sampling rate. The coefficients are passed to FIR Compiler v3_2 by filling xlfda_numerator('FDATool') as coefficient vector. The output of DA FIR V9 is 32 bits, and the slice block helps to determine the location of MSB to get the best precision. It shows the possibility to use the powerful tool in FPGA design for now and in future. Once the filter is verified using Simulink Source , it is copied into the fir_loop back example as shown in Figure.
Figure 36. FIR Filter Design mdl file
Figure 37. Low Pass Filter Design FDA Tool Setup
58
Figure 38. FIR Loop back Example To compile this example for hardware co-simulation, follow these steps:

Select Simulink system period (sec) = 1/200e6 by typing Ts=1/200e6 on Matlab command prompt. Double click on Xilinx System Generator token and enter the following in the resulting window Select x5_400m_revE as compilation target Select target directory for the compilation results as netlist_fir_loop_back Select synthesis tool as XST Select hardware description language as VHDL Set Simulink System Period (sec) as Ts
59
Click on generate
Figure 39. X5-400M FIR Loop back Example System Generator Settings As a result of compilation, a hardware co-simulation library component will be generated which can be used for actual hardware co-simulation. Default example is provided with fir_loopback_hwcosim.mdl file. All the non memory mapped gateways appear in the Simulink generated hardware co-simulation library. Figure shows the hardware co-simulation mdl file.
Figure 40. FIR Loop back hardware co-simulation Example X5-400M Matlab BSP Manual 60
To run this example on FPGA, follow these steps: 1. 2. Connect the Xilinx POD to JP1 on X5-400M board Double click on fir_loopback_hwcosim component, enable the clock source as free running and browse for appropriate fir loopback example bitfile in the resulting window, then press OK.
Figure 41. Hardware Co-simulation Settings 3. 4. 5. 6. 7. Click on Simulation Run Button to start the example As a result, the FPGA bit file will be loaded on Viretx5 FPGA device on X5-400M board Using device manager on the host PC, reenumerate the board Open Wave Example from <Innovative Malibu Root>X5-400M\Examples\Wave\Bcb11\Release and make settings as shown in below figures. From configure menu tab, select appropriate Busmaster memory size
61
8.
From stream menu tab, apply the stream by a click on
62
Innovative Integration Inc Copyright 2010 9. From Debug menu tab, locate x5_400m_after.txt from FIR Loop back example folder and run the script by a click on
A simple experiment can be done with this example. Connect a function generator on ADC0 and an oscilloscope on DAC0. The generated sine wave starts from 1 MHz and the frequency is increased steadily to 8 MHz. On the scope, the amplitude should be gradually attenuated by the filter.
Figure 42. DAC 0 output on the oscilloscope In case re-running of the example is desired, the need to re-enumerate the board can be avoided by double clicking on fir_loopback_hwcosim component and enabling skip device configuration mode under advanced settings. X5-400M Matlab BSP Manual 63
Example : User Design

This example is provided as a starting template for the custom user design. Since no custom logic is added to this design, this mdl file should act as default example. User can develop and add their own logic in this mdl file. Once the Logic is verified using hardware cosimulation, the next step is to build a standalone bit image for the FPGA. The dat from each ADC is passed through a 32 in 16 bit out FIFO to give access to individual ADC samples to the User. Similarly data from the PCI RX interface also can be grabbed for adding custom logic.
Figure 43. user_design mdl file To compile this example for hardware Co-simulation follow these steps:

Select Simulink system period (sec) = 1/200e6 by typing Ts=1/200e6 on Matlab command prompt. Double click on Xilinx System Generator token and enter the following in the resulting window Select x5_400m_revE as compilation target Select target directory for the compilation results as netlist_user_design
64

Select synthesis tool as XST Select hardware description language as VHDL Set Simulink System Period (sec) as Ts Click on generate
Figure 44. X5-400M user design Example System Generator Settings
As a result of compilation, a h/w co-simulation library component is generated. This component is used for actual h/w cosimulation. Digital IO example is provided with user_design_hwcosim.mdl file. All the non memory mapped gateways appear in the Simulink generated h/w co-simulation library.
65
Figure 45. User design hardware co-simulation Example
Matlab/Simulink can work only upto 200MHz system clock. This restriction is because of the hardware cosimulation logic added by System Generator . Once the working of signal processing chain is verified at 200MHz system clock, user can compile this logic into standalone bit file with system clock at 250MHz.
66
Procedure to generate a standalone bit image for X5-400M board

1. 2. 3. 4. 5. 6. 7. 8. 9. Start using x5_400m_default mdl file and add custom logic If needed run a separate Matlab/Simulink simulation to verify the custom logic e.g Designing a DDC , FFT or filter using a separate mdl file Use ISE simulator or Modelsim for simulation if needed Add this design in the x5_400m_default.mdl file for hardware cosimulation Compile for hardware co-simulation Verify the design using Snap or Wave example Once the design is verified, the next step is to generate a standalone bit file for the FPGA Remove all the memory mapped gateway from the design as shown in the x5_400m_implement.mdl file in the default example folder Generate a ngc netlist without clock wrapper option as shown in figure
Figure 46. NGC netlist generation X5-400M Matlab BSP Manual 67
Figure 47. Clock Wrapper Example 10. Open the Xilinx ISE project at <X5 Root>/400M/Matlab/rev_E/Logic 11. Copy the ngc (your_desing_name.ngc) into the ISE project folder 12. change the name of the x4_400m_implement component to the name of ngc netlist generated by the Matlab/Simulink 13. Set the generic implementation_logic = '1' in the x5_400m_top.vhd file 14. Recompile the design and generate the bit file
68
Frequently Asked Questions

Q1: When I open the x5_400m_default.mdl file , I can not see the library components. I get errors as bad link. Ans : Before opening x5_400m_default.mdl file, open simulink library browser, open the II X5_400M Rev E Blockset library and II DSP LIB by a right click on that specific libraries and then try to open x5_400m_default.mdl file. Q2: How do I connect the JTAG with X5_400m device? Ans : After fixing the X5_400m device in to the host PCIe slot, use the 14pin ribbon connector cable that connects platform cable USB II with X5_400m device. When cable is connected to a mating connector on the X5_400m device, the status LED is illuminated as a function of the voltage present on pin 2(Vref). Make sure the connectivity between platform cable USB II and X5_400m device(by connecting the pin1 of platform cable USB II to the pin1- squared base of JTAG mating connector on X5_400m device) as wrong connection may leads to failure of X5_400m device and host system. Platform cable USB II uses a tri-color status LED to indicate the presence of target voltage. The statue LED is amber when any one or more of the following condition exist: The cable is not connected to X5_400m device The Host system is not powered The voltage on the Vref pin is <_ + 1.3V. The status LED is Green when all of the following condition exist: The cable is connected to X5_400m device The Host system is powered The voltage on the Vref pin is >_ + 1.5V. Table below summarizes the various status LED states.
69
Q3:Why can't I compile the examples in MATLAB or load the projects into Xilinx ISE when I first installed the BSP? After BSP installation, please right-click the installation folder and uncheck the read-only option. In the hardware co-simulation example, please double-click on the cosim block and check the path of bitstream.
Q4:When I run the hardware cosim example, Simulink showed the error: Could not open the programming cable. Please check if cable is correctly attached to the connector. Is the light on Jtag pod green? Is the red line on the Jtag cord align to the square mark on the connector. Please double-click the cosim block and see if the right cable is selected, as shown in the picture.
70
Q5:When I run the hardware cosim example, the result is different from what I expect. Please double-click the cosim block and see if the block is in free-running mode, as shown in the picture.
Q6:I had high timing score problem in the PAR process. What can I do to reduce the timing problem? The similar problem is discussed in Chapter 3 Design Flow. First, you can use Floorplanner and see if there is any signal traveled a long distance to its destination. You can buffer the signal by adding registers in Simulink. Second, you can use Timing Analyzer to locate the timing errors. You can either improve the problems according to the instructions in Timing Analyzer or rearrange the corresponding components in the floor plan. Q7:I saw license not found error in the compilation. Please check if you are using Microsoft Remote Desktop. If not, please contact tech support in II.
71

X5-400M Matlab BSP Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

X5-400M Matlab BSP Manual

Uploaded by

Copyright:

Available Formats

X5-400M MATLAB BSP MANUAL