Download - 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 Integration2390-A Ward AveSimi Valley, California 93065
PH: (805) 578-4260FAX: (805) 578-4225
email: [email protected]: 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 ContentsX5-400M Matlab BSP Manual................................................................................................................2
Revision History.........................................................................................................................................7
Introduction................................................................................................................................................8Key Features.......................................................................................................................................................................8
Hardware Design Using System Generator.............................................................................................................................9Design Flows Using System Generator.............................................................................................................................9
Algorithm Exploration..................................................................................................................................................9Implementing Part of a Larger Design.........................................................................................................................9Implementing a Complete Design..............................................................................................................................10
System Level Modeling in System Generator.................................................................................................................10System Generator Blockset........................................................................................................................................10Xilinx Blockset...........................................................................................................................................................11Innovative Integration Blockset.................................................................................................................................12Bit-True and Cycle-True Modeling............................................................................................................................13Timing and Clocking..................................................................................................................................................13
Automatic Code Generation.............................................................................................................................................14Compiling and Simulating Using System Generator Block.......................................................................................14Compilation Type and the Generate Button...............................................................................................................15Compilation Results...................................................................................................................................................16HDL Testbench..........................................................................................................................................................17
Compiling MATLAB Design into an FPGA...................................................................................................................17Importing a System Generator Design into a Bigger System................................................................................................18
NGC Netlist Compilation.................................................................................................................................................18Design Rules...............................................................................................................................................................19Synthesis ....................................................................................................................................................................20Simulation...................................................................................................................................................................21Step-by-Step Example................................................................................................................................................21Generating the NGC files for the System Generator Designs....................................................................................22Synthesizing the Top Level Design............................................................................................................................22
Using FPGA Hardware in the Loop......................................................................................................................................23Compiling a Model for Hardware Co-Simulation...........................................................................................................23
Choosing a Compilation Target..................................................................................................................................23Invoking the Code Generator.....................................................................................................................................23
Hardware Co-Simulation Blocks.....................................................................................................................................24Hardware Co-Simulation Clocking..................................................................................................................................24
Single-Step Clock.......................................................................................................................................................25Free-Running Clock...................................................................................................................................................25Selecting 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..........................................................................................................................................................................29ADC INTF Component....................................................................................................................................................30DAC INTF Component....................................................................................................................................................31DDR INTF Component....................................................................................................................................................34ii_interleaver Component.................................................................................................................................................36ii_deinterleaver Component.............................................................................................................................................38ii_reorder Component......................................................................................................................................................40ii_packetizer Component.................................................................................................................................................41DAC SPI INTF Component.............................................................................................................................................45PCI Express INTF Component........................................................................................................................................46Digital IO Component......................................................................................................................................................47System Configuration Component...................................................................................................................................48QDR Interface Component .............................................................................................................................................50
Examples ..................................................................................................................................................53Example: x5_400m_default.mdl......................................................................................................................................55Example: fir_loopback.mdl..............................................................................................................................................58 Example : User Design ...................................................................................................................................................64Procedure to generate a standalone bit image for X5-400M board.................................................................................67
Frequently Asked Questions...................................................................................................................69
X5-400M Matlab BSP Manual 4
Innovative Integration Inc Copyright 2010
List of TablesTable 1. Xilinx Library Blocksets..........................................................................................................................................12Table 2. Compilation Results................................................................................................................................................17Table 3. ADC INTF Component pin assignments................................................................................................................31Table 4. DAC INTF Component pin assignments................................................................................................................33Table 5. DDR INTF Component pin assignments................................................................................................................35Table 6. ii_interleaver Component pin assignments.............................................................................................................37Table 7. ii_deinterleaver Component pin assignments.........................................................................................................39Table 8. ii_reorder Component pin assignments..................................................................................................................40Table 9. ii_packetizer Component pin assignments.............................................................................................................44Table 10. Commands for DAC SPI INTF Component..........................................................................................................45Table 11. DAC SPI INTF Component pin assignments........................................................................................................45Table 12. PCIE TX Component pin assignments..................................................................................................................46Table 13. PCIE RX Component pin assignments..................................................................................................................46Table 14. Digital IO Component pin assignments.................................................................................................................47Table 15. System Configuration Component pin assignments..............................................................................................49Table 16. QDR Interface Component pin assignments.........................................................................................................52Table 17. Matlab Examples for X5-400M board...................................................................................................................54
X5-400M Matlab BSP Manual 5
Innovative Integration Inc Copyright 2010
List of FiguresFigure 1. System Generator Blocksets...................................................................................................................................11Figure 2. Innovative Integration BSP Library.......................................................................................................................12Figure 3. Simulink Gateways.................................................................................................................................................13Figure 4. Simulink Scope.......................................................................................................................................................14Figure 5. Xilinx System Generator Block.............................................................................................................................15Figure 6. Compilation Flow...................................................................................................................................................18Figure 7. NGC compilation target.........................................................................................................................................19Figure 8. Synthesis flow........................................................................................................................................................20Figure 9. Design Block Diagram...........................................................................................................................................21Figure 10. Invoking the code generator.................................................................................................................................23Figure 11. Hardware Co-simulation......................................................................................................................................24Figure 12. Hardware Co-simulation Library block...............................................................................................................24Figure 13. Clock source selection for hardware Co-simulation............................................................................................25Figure 14. Board Specific IO for X5-400M from Innovative Integration ...........................................................................26Figure 15. X5 400M block diagram.......................................................................................................................................29Figure 16. ADC INTF component.........................................................................................................................................30Figure 17. ADC 0 INTF Panel...............................................................................................................................................30Figure 18. DAC INTF component.........................................................................................................................................31Figure 19. DAC 0 INTF panel...............................................................................................................................................32Figure 20. DDR INTF Component........................................................................................................................................34Figure 21. ii_interleaver component......................................................................................................................................36Figure 22. ii_deinterleaver component..................................................................................................................................38Figure 23. ii_reorder component...........................................................................................................................................40Figure 24. ii_packetizer component.......................................................................................................................................41Figure 25. ii_packetizer under the mask................................................................................................................................42Figure 26. DAC SPI INTF component..................................................................................................................................45Figure 27. PCIE INTF component.........................................................................................................................................46Figure 28. DIO component....................................................................................................................................................47Figure 29. System Configuration component........................................................................................................................48Figure 30. QDR Interface Component...................................................................................................................................50Figure 31. X5-400M Configuration Parameters....................................................................................................................53Figure 32. X5_400M_default mdl file...................................................................................................................................55Figure 33. X5-400M default Example System Generator Settings.......................................................................................56Figure 34. X5_400M default hardware co-simulation file....................................................................................................57Figure 35. X5_400M default hardware Co-simulation Settings............................................................................................57Figure 36. FIR Filter Design mdl file....................................................................................................................................58Figure 37. Low Pass Filter Design FDA Tool Setup.............................................................................................................58Figure 38. FIR Loop back Example.......................................................................................................................................59Figure 39. X5-400M FIR Loop back Example System Generator Settings..........................................................................60Figure 40. FIR Loop back hardware co-simulation Example................................................................................................60Figure 41. Hardware Co-simulation Settings........................................................................................................................61Figure 42. DAC 0 output on the oscilloscope........................................................................................................................63Figure 43. user_design mdl file.............................................................................................................................................64Figure 44. X5-400M user design Example System Generator Settings................................................................................65Figure 45. User design hardware co-simulation Example.....................................................................................................66Figure 46. NGC netlist generation.........................................................................................................................................67Figure 47. Clock Wrapper Example......................................................................................................................................68
X5-400M Matlab BSP Manual 6
Innovative Integration Inc Copyright 2010
Revision History
The following table shows the revision history for the Board Support Package.
Date Version Revision
10/28/2009 7.2 Initial release 7.2 Matlab BSP (Amit Mane)
12/10/2009 7.3 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)
X5-400M Matlab BSP Manual 7
Innovative Integration Inc Copyright 2010
Introduction
System Generator™ for DSP is the industry’s 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 industry’s 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.
X5-400M Matlab BSP Manual 8
Innovative Integration Inc Copyright 2010
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 ExplorationSystem 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 DesignOften 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.
X5-400M Matlab BSP Manual 9
Innovative Integration Inc Copyright 2010
Implementing a Complete DesignMany 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 BlocksetA 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.
X5-400M Matlab BSP Manual 10
Innovative Integration Inc Copyright 2010
Figure 1. System Generator Blocksets
Xilinx BlocksetThe 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 Every block in the Xilinx Blockset
Basic elements Standard building blocks for digital logic.
Communication Forward error correction and modulator blocks, commonly used in digital communications systems.
Control logic Blocks for control circuitry and state machines
Data types Blocks that convert data types (includes gateways).
DSP Digital signal processing (DSP) blocks.
Math Blocks that implement mathematical functions.
X5-400M Matlab BSP Manual 11
Innovative Integration Inc Copyright 2010
Memory Blocks that implement and access memories.
Shared memory Blocks that implement and access Xilinx shared memories.
Tools "Utility" blocks, e.g., code generation (System Generator block), resource estimation, HDL co-simulation, etc.
Table 1. Xilinx Library Blocksets
Innovative Integration BlocksetThe 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
X5-400M Matlab BSP Manual 12
Innovative Integration Inc Copyright 2010
Bit-True and Cycle-True ModelingSimulations 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.
X5-400M Matlab BSP Manual 13
Innovative Integration Inc Copyright 2010
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 BlockSystem 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.
X5-400M Matlab BSP Manual 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 ButtonPressing 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
X5-400M Matlab BSP Manual 15
Innovative Integration Inc Copyright 2010
• 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 ResultsThe 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 This contains most of the HDL for the design.
<design>_cw.vhd/.v This is a HDL wrapper for <design>_files.vhd/.v. It drives clocks and clock enables.
.edn and .ngc files 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
globals 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.
<design>_cw.xcf (or .ncf)
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.
<design>_cw.ise This allows the HDL and EDIF to be brought into the Xilinx project management tool Project Navigator.
hdlFiles This contains the full list of HDL files written by System Generator. The files are listed in the usual HDL dependency order.
X5-400M Matlab BSP Manual 16
Innovative Integration Inc Copyright 2010
synplify_<design>.prj, or xst_<design>.prj
These files allow the design to be compiled by the synthesis tool you specified
Vcom.do Modelsim script for behavioral simulationTable 2. Compilation Results
HDL TestbenchOrdinarily, 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.
X5-400M Matlab BSP Manual 17
Innovative Integration Inc Copyright 2010
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.
X5-400M Matlab BSP Manual 18
Innovative Integration Inc Copyright 2010
Figure 7. NGC compilation target
Design RulesWhen 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.
X5-400M Matlab BSP Manual 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.
X5-400M Matlab BSP Manual 20
Innovative Integration Inc Copyright 2010
SimulationWhen 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 ExampleIn 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
X5-400M Matlab BSP Manual 21
Innovative Integration Inc Copyright 2010
• 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 DesignsThe 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 DesignThe 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
X5-400M Matlab BSP Manual 22
Innovative Integration Inc Copyright 2010
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 TargetYou 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 GeneratorOnce 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
X5-400M Matlab BSP Manual 23
Innovative Integration Inc Copyright 2010
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.
X5-400M Matlab BSP Manual 24
Innovative Integration Inc Copyright 2010
Single-Step ClockIn 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 ClockIn 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 ModeNot 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
X5-400M Matlab BSP Manual 25
Innovative Integration Inc Copyright 2010
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 co-simulation 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
Innovative Integration Inc Copyright 2010
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. Matlab 7.8 (R2009a) /Simulink V7.3 (R2009a)
2. 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
X5-400M Matlab BSP Manual 27
Innovative Integration Inc Copyright 2010
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 “C:\<X5 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. 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.
3. type “setup_x5_400m” on Matlab Command prompt
4. Restart Matlab
5. type “xlrehash_xltarget_cache” on the Matlab command prompt
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
X5-400M Matlab BSP Manual 28
Innovative Integration Inc Copyright 2010
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.
Figure 15. X5 400M block diagram
X5-400M Matlab BSP Manual 29
QDR SRAM
PCIE
deframer Digital IO/Serial RapidIO
DDR2Queue 0
Alert
DDR2Queue 1
32
64
DACSPI
Trigger
128
128
64 FIFO32i16o
Offset/gain
Offset/gain
DAC1
Trigger
FIFO32i16o
FIFO32i32o
FIFO32i32o
Offset/gain
Offset/gain
Offset/gain
Offset/gain
Offset/gain
Offset/gain
DAC0
ADC1
ADC0
32
32
16
16
32
32
PCIEINTF
DDRQueue 0
DDRQueue 1
ADC0
ADC1
DAC0
DAC1
QDRSRAM
User Design
MATLAB/Simulink
Packetizer
Innovative Integration Inc Copyright 2010
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
X5-400M Matlab BSP Manual 30
Innovative Integration Inc Copyright 2010
Pin Direction Function
test In Test ramp enable
trig In Software trigger
dest_rdy In Destination ready
data[31:0] Out Input data
valid Out 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
X5-400M Matlab BSP Manual 31
Innovative Integration Inc Copyright 2010
Figure 19. DAC 0 INTF panel
Pin Direction Function
test In Software trigger
trig In Software trigger
data[31:0] In Output data
X5-400M Matlab BSP Manual 32
Innovative Integration Inc Copyright 2010
Pin Direction Function
wr In Write strobe
test_mode[1:0] In Test signal select'0' => ramp;'1' => sine wave
phase_inc0[23:0] In Phase incrementphase_inc = output_freq * 2^24 / dac_ref_clk
phase_inc1[23:0] In Phase incrementphase_inc = output_freq * 2^24 / dac_ref_clk
rdy Out FIFO is ready for incoming data
Table 4. DAC INTF Component pin assignments
X5-400M Matlab BSP Manual 33
Innovative Integration Inc Copyright 2010
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 Direction Function
din[127:0] In Input data
wr In Write strobe
rd In Read strobe
dout[127:0] Out Output data
X5-400M Matlab BSP Manual 34
Innovative Integration Inc Copyright 2010
Pin Direction Function
valid Out Data valid
ofifo_empty Out Output FIFO empty flag
ofifo_aempty Out Output FIFO almost empty flag
ififo_rdy Out Input FIFO ready signal
Table 5. DDR INTF Component pin assignments
X5-400M Matlab BSP Manual 35
Innovative Integration Inc Copyright 2010
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 Direction Function
reset In Reset
ch_en[1:0] In Channel enable; bit 0 is for channel 0 and bit 1 is for channel 1.
din0[31:0] In Data in
X5-400M Matlab BSP Manual 36
Innovative Integration Inc Copyright 2010
Pin Direction Function
din1[31:0] In Data in
wr0 In Write strobe
wr1 In Write strobe
check_en In Enable data checker
dout[127:0] Out Data out
valid Out Data valid
status Out Data checker status
chipscope_data[127:0] Out Chipscope test vector
Table 6. ii_interleaver Component pin assignments
X5-400M Matlab BSP Manual 37
Innovative Integration Inc Copyright 2010
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 Direction Function
reset In Reset
ch_en[1:0] In Channel enable; bit 0 is for channel 0 and bit 1 is for channel 1.
X5-400M Matlab BSP Manual 38
Innovative Integration Inc Copyright 2010
Pin Direction Function
src_empty In Source FIFO empty flag
src_aempty In Source FIFO almost empty flag
src_din[127:0] In Data in
src_valid In Data valid
dest0_rdy In Destination ready
dest1_rdy In Destination ready
src_rd_en Out Read enable to source
dest0_dout[31:0] Out Data out
dest0_valid Out Data valid
dest1_dout[31:0] Out Data out
dest1_valid Out Data valid
Table 7. ii_deinterleaver Component pin assignments
X5-400M Matlab BSP Manual 39
Innovative Integration Inc Copyright 2010
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 Direction Function
din[127:0] In Input data
dout[127:0] Out Output
adc_ch_en In(1..0) Adc channel Enable
Table 8. ii_reorder Component pin assignments
X5-400M Matlab BSP Manual 40
Innovative Integration Inc Copyright 2010
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
X5-400M Matlab BSP Manual 41
Innovative Integration Inc Copyright 2010
Figure 25. ii_packetizer under the mask
Pin Direction Function
reset In Reset
ch1_din[63:0] In Input data
ch2_din[63:0] In Input data
ch3_din[63:0] In Input data
ch4_din[63:0] In Input data
ch5_din[63:0] In Input data
dest_rdy In PCIe Destination ready signal
X5-400M Matlab BSP Manual 42
Innovative Integration Inc Copyright 2010
Pin Direction Function
ch2_pd_addr[7..0] In Peripheral ID for channel 2
ch3_pd_addr[7..0] In Peripheral ID for channel 3
ch4_pd_addr[7..0] In Peripheral ID for channel 4
ch5_pd_addr[7..0] In Peripheral ID for channel 5
aux_hdr2[31..0] In Auxiliary header
ch2_pkt_size[23..0] In Ch2 packet size
ch3_pkt_size[23..0] In Ch3 packet size
ch4_pkt_size[23..0] In Ch4 packet size
ch5_pkt_size[23..0] In Ch5 packet size
ch1_empty In Empty signal
ch2_empty In Empty signal
ch3_empty In Empty signal
ch4_empty In Empty signal
ch5_empty In Empty signal
ch1_aempty In Almost Empty signal
ch2_aempty In Almost Empty signal
ch3_aempty In Almost Empty signal
ch4_aempty In Almost Empty signal
ch5_aempty In Almost Empty signal
X5-400M Matlab BSP Manual 43
Innovative Integration Inc Copyright 2010
Pin Direction Function
ch1_din_vld In Data valid signal
ch2_din_vld In Data valid signal
Ch3_din_vld In Data valid signal
Ch4_din_vld In Data valid signal
Ch5_din_vld In Data valid signal
data_out[63:0] Out Data to PCIe interface
data_out_vld Out Data valid signal
ch1_rden Out Ch1 read signal
ch2_rden Out Ch2 read signal
ch3_rden Out Ch3 read signal
ch4_rden Out Ch4 read signal
ch5_rden Out Ch5 read signal
Table 9. ii_packetizer Component pin assignments
X5-400M Matlab BSP Manual 44
Innovative Integration Inc Copyright 2010
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 Fdac (MHz) dac_clk (MHz) interpolation
[spi_addr, spi_data, spi_wr]=dac_pll( 125, 1 ) 125 125 1
[spi_addr, spi_data, spi_wr]=dac_pll( 250, 2 ) 250 125 2
[spi_addr, spi_data, spi_wr]=dac_pll( 500, 4 ) 500 125 4
Table 10. Commands for DAC SPI INTF Component
Figure 26. DAC SPI INTF component
Pin Direction Function
addr[4:0] In SPI address
data[7:0] In SPI data
wr In Write strobe
Table 11. DAC SPI INTF Component pin assignments
X5-400M Matlab BSP Manual 45
Innovative Integration Inc Copyright 2010
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 Direction Function
data[63:0] In Output data
wr In Write strobe
rdy Out PCI express Transmit Interface Ready signal
Table 12. PCIE TX Component pin assignments
Pin Direction Function
data[63:0] Out Input data
valid Out Data valid
Table 13. PCIE RX Component pin assignments
X5-400M Matlab BSP Manual 46
Innovative Integration Inc Copyright 2010
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 Direction Function
dio_en In '1' => data from MATLAB'0' => data from software
tx_data[32:0] In Transmitted data
ctrl[4:0] In Input/output direction controlctrl(0) = '1' => ud( 7 downto 0 ) is an outputctrl(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
wr In Write strobe for tx_data
rd In Read strobe for rx_data
rx_data[33:0] Out Received data
Table 14. Digital IO Component pin assignments
X5-400M Matlab BSP Manual 47
Innovative Integration Inc Copyright 2010
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 Direction Function
en_config In Enable Configuration from Simulink'1' => From Simulink;'0' => From the host.
status44[31:0] In status_reg(44) to PCI Express interface
status45[31:0] In status_reg(45) to PCI Express interface
X5-400M Matlab BSP Manual 48
Innovative Integration Inc Copyright 2010
Pin Direction Function
status46[31:0] In status_reg(46) to PCI Express interface
status47[31:0] In status_reg(47) to PCI Express interface
clk_sel In Clock select'0' => external clock;'1' => 400 MHz onboard clock.
sync_en In Enable sync to ADC sample clk
matlab_gp_out[31..0] In General Purpose Data from Matlab to Framework Logic
clock_locked Out Clock locked signalsys_clk, ddr_ref_clk, ddr2_dcm, qdr0_dcm, qdr1_dcm are locked.
Temp[9:0] Out Temperature dataTemperature = temp * 0.492 - 273.15
sys_reset Out Reset is high if adc_run or dac_run is low.
init_reset Out Reset after loading the FPGA
ext_sync Out External trigger
ctl_reg44[31:0] Out ctl_reg(44) from PCI Express interface
ctl_reg45[31:0] Out ctl_reg(45) from PCI Express interface
ctl_reg46[31:0] Out ctl_reg(46) from PCI Express interface
ctl_reg47[31:0] Out ctl_reg(47) from PCI Express interface
matlab_gp_in[31..0] Out General Purpose data from Framework Logic to Matlab
adc_ch_en[1..0] Out ADC channel Enable signal
dac_ch_en[1..0] Out DAC channel enable signal
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
X5-400M Matlab BSP Manual 50
Innovative Integration Inc Copyright 2010
Pin Direction Function
enable In Enable ='1' QDR can be accessed from Matlab/Simulink environment. Enable = '0' QDR is available
reset In Active high reset signal
fast_mode In fast_mode = '1' allows the data capture into QDR memory at system clock rate
rollover In 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
end_addr[17:0] In End address for the fast_mode
wt_addr[17:0] In wt_addr specifies the write address to the QDR memory in regular SRAM mode or FIFO mode
wt_data[63:0] In Data to be written into the memory
wt In Write enable
read_addr[17:0] In Read address
rd In Read enable
fifo_mode_en In fifo_mode = '1'; rdata_rdy ='1' when QDR memory FIFO reaches fifo_thresh. User can read the data continuously from the memory.
fifo_rd In fifo_thresh
fifo_thresh[9:0] In Threshold for the FIFO
wt_rdy Out wt_rdy = '1' means data can be written into the QDR memory.wt_rdy = '0' means QDR memory busy
X5-400M Matlab BSP Manual 51
Innovative Integration Inc Copyright 2010
Pin Direction Function
raddr_rdy Out raddr_rdy='1' means new read access is allowed.
raddr_rdy='0' means QDR busy
rdata_rdy Out rdata_rdy = '1' means read data is available in the FIFO. Useful in FIFO mode
rd_data[63:0] Out Read data from the QDR memory
rd_valid Out Read valid signal
Table 16. QDR Interface Component pin assignments
X5-400M Matlab BSP Manual 52
Innovative Integration Inc Copyright 2010
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 optionstype=fixed-step; solver=discrete(no continuous state)
Figure 31. X5-400M Configuration Parameters
X5-400M Matlab BSP Manual 53
Innovative Integration Inc Copyright 2010
File name (.mdl) Contents
x5_400m_default This example shows standard connections in FrameWork Logic for data acquisition.
fir_loopback This example shows data loopbacked from ADC to DAC through a FIR lowpass filter.
user_design 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'.”
X5-400M Matlab BSP Manual 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
X5-400M Matlab BSP Manual 55
Innovative Integration Inc Copyright 2010
● 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.
X5-400M Matlab BSP Manual 56
Innovative Integration Inc Copyright 2010
Figure 34. X5_400M default hardware co-simulation file
To run this example on FPGA, follow these steps:
1. Connect the Xilinx POD to JP1 on X5-400M board
2. 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. Click on Simulation Run Button to start the example
4. As a result, the FPGA bit file is loaded on Viretx5 FPGA device on X5-400M board
5. Using device manager on the host PC, reenumerate the board
6. 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.
7. Open Snap Example from “<Innovative Malibu Root>X5-400M\Examples\Wave\Bcb11\Release” . Select appropriate BusMaster memory size. Capture the data from A/Ds.
X5-400M Matlab BSP Manual 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
X5-400M Matlab BSP Manual 58
Innovative Integration Inc Copyright 2010
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
X5-400M Matlab BSP Manual 59
Innovative Integration Inc Copyright 2010
● 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
Innovative Integration Inc Copyright 2010
To run this example on FPGA, follow these steps:
1. Connect the Xilinx POD to JP1 on X5-400M board
2. 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. Click on Simulation Run Button to start the example
4. As a result, the FPGA bit file will be loaded on Viretx5 FPGA device on X5-400M board
5. Using device manager on the host PC, reenumerate the board
6. Open Wave Example from “<Innovative Malibu Root>X5-400M\Examples\Wave\Bcb11\Release” and make settings as shown in below figures.
7. From configure menu tab, select appropriate Busmaster memory size
X5-400M Matlab BSP Manual 61
Innovative Integration Inc Copyright 2010
8. From stream menu tab, apply the stream by a click on
X5-400M Matlab BSP Manual 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
Innovative Integration Inc Copyright 2010
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
X5-400M Matlab BSP Manual 64
Innovative Integration Inc Copyright 2010
● 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 co-simulation. 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.
X5-400M Matlab BSP Manual 65
Innovative Integration Inc Copyright 2010
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.
X5-400M Matlab BSP Manual 66
Innovative Integration Inc Copyright 2010
Procedure to generate a standalone bit image for X5-400M board
1. Start using x5_400m_default mdl file and add custom logic
2. 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
3. Use ISE simulator or Modelsim for simulation if needed
4. Add this design in the x5_400m_default.mdl file for hardware cosimulation
5. Compile for hardware co-simulation
6. Verify the design using Snap or Wave example
7. Once the design is verified, the next step is to generate a standalone bit file for the FPGA
8. Remove all the memory mapped gateway from the design as shown in the x5_400m_implement.mdl file in the default example folder
9. Generate a ngc netlist without clock wrapper option as shown in figure
Figure 46. NGC netlist generation
X5-400M Matlab BSP Manual 67
Innovative Integration Inc Copyright 2010
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
X5-400M Matlab BSP Manual 68
Innovative Integration Inc Copyright 2010
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.
X5-400M Matlab BSP Manual 69
Innovative Integration Inc Copyright 2010
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.
X5-400M Matlab BSP Manual 70
Innovative Integration Inc Copyright 2010
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.
X5-400M Matlab BSP Manual 71