This document is a reference guide for system designers who are unfamiliar with the
System Generator v2.1 and the Xilinx Blockset.
Manual Contents
This guide covers the following topics:
•Chapter 1, Introduction, gives a high-level overview of the System Generator and
its uses.
•Chapter 2, Xilinx Blockset Overview, describes the Xilinx Blockset: how to
instantiate a Xilinx block within your Simulink model, how to configure it
through its block parameters dialog box, the common options that can be used in
several of the blocks, and the nature of the signals used in the System Generator
software.
•Chapter 3,Xilinx Blocks, describes the details of each block, including options, and
use of Xilinx LogiCOREs. This chapter also tells where to find descriptions of
the cores on your computer.
•Chapter 4, System Generator Software Features, describes the System Generator
software and gives tips for using it to create efficient hardware designs.
•Chapter 5, Using the Xilinx Software, tells, step-by-step, how to use System
Generator as a front-end to the Xilinx Foundation 4.1i ISE software, from VHDL
to bitstream generation.
•Chapter 6, Auxiliary Files, contains instructions for accessing System Generator
demo designs, as well as a list of Perl scripts that are delivered with the System
Generator software. The demo designs show examples of designs using Xilinx
blocks. The scripts are used by the System Generator to create auxiliary project
files, but can also be used as stand-alone tools.
2Xilinx Development System
Additional Resources
For additional information, go to http://support.xilinx.com. The following
table lists some additional resources.
ResourceDescription/URL
IP CenterInformation on Xilinx LogiCOREs and IP solutions.
http://www.xilinx.com/ipcenter/
This page contains a link to the Xilinx Xtreme DSP solutions page.
Technical TipsLatest news, design tips, and patch information for the Xilinx design environment.
http://support.xilinx.com/xlnx/xil_tt_home.jsp
TutorialsTutorials covering Xilinx ISE 4.1i design flows, from design entry to verification and
MATLAB , Simulink , DSP design, and other company information.
http://www.mathworks.com
3
Xilinx System Generator v2.1 Reference Guide
Conventions
This document uses the following conventions. An example illustrates each
convention.
Typographical
The following conventions are used for all System Generator documents.
•Courier font (a fixed-width font) indicates messages, prompts, menu pick
items, and dialog box entries that the system displays.
speed grade: - 100
•Courier bold indicates literal commands that you enter in a command-line
prompt or dialog box. However, triangular braces “<>” in Courier bold are not
literal.
>> cd <your $MATLAB home directory>
•Italic font denotes the following items.
♦Introduction of words being used with a context-specific definition
The System Generator provides bit true and cycle true modeling.
♦References to other manuals or sections in this manual
See the Development System Reference Guide for more information.
♦Emphasis in text
If a wire is drawn so that it overlaps the pin of a symbol, the two nets are not
connected.
4Xilinx Development System
Contents
Chapter 1Introduction
Industry and Product Overview .................................................................................8
System Generator .....................................................................................................9
System Level Modeling with System Generator .......................................................9
The System Generator Design Flow .........................................................................10
Arithmetic Data Types ..............................................................................................12
This chapter describes the basic concepts and tools of the System Generator v2.1.
This chapter contains the following sections.
•Industry and Product Overview
•System Generator
•System Level Modeling with System Generator
•The System Generator Design Flow
•Arithmetic Data Types
•Hardware Handshaking
Chapter 1
•Bit-true and Cycle-true Modeling
Industry and Product Overview
In recent years, field-programmable gate arrays (FPGAs) have become key
components in implementing high performance digital signal processing (DSP)
systems, especially in the areas of digital communications, networking, video, and
imaging. The logic fabric of today's FPGAs consists not only of look-up tables,
registers, multiplexers, distributed and block memory, but also dedicated circuitry for
fast adders, multipliers, and I/O processing (e.g., giga-bit I/O). The memory
bandwidth of a modern FPGA far exceeds that of a microprocessor or DSP processor
running at clock rates two to ten times that of the FPGA. Coupled with a capability
for implementing highly parallel arithmetic architectures, this makes the FPGA
ideally suited for creating high-performance custom data path processors for tasks
such as digital filtering, fast Fourier transforms, and forward error correction.
For example, all major telecommunication providers have adopted FPGAs for highperformance DSP out of necessity. A third-generation (3G) wireless base station
typically contains FPGAs and ASICs in addition to microprocessors and digital signal
processors (DSPs). The processors and DSPs, even when running at GHz clock rates,
are increasingly used for relatively low MIPs packet level processing, with the chip
and symbol rate processing being implemented in the FPGAs and ASICs. The fluidity
of emerging standards often makes FPGAs, which can be reprogrammed in the field,
better suited than ASICs.
Despite these characteristics, broader acceptance of FPGAs in the DSP community has
historically been hampered by several factors. First, there is a general lack of
familiarity with hardware design and especially, FPGAs. DSP engineers conversant
with programming in C or assembly language are often unfamiliar with digital design
using hardware description languages (HDLs) such as VHDL or Verilog.
Furthermore, although VHDL provides many high level abstractions and language
8Xilinx Development System
constructs for simulation, its synthesizable subset is far too restrictive for system
design.
System Generator is a software tool for modeling and designing FPGA-based DSP
systems in Simulink. The tool presents a high level abstract view of a DSP system, yet
nevertheless automatically maps the system to a faithful hardware implementation.
What is most significant is that System Generator provides these services without
substantially compromising either the quality of the abstract view or the performance
of the hardware implementation.
System Generator
Simulink provides a powerful high level modeling environment for DSP systems, and
consequently is widely used for algorithm development and verification. System
Generator maintains an abstraction level very much in keeping with the traditional
Simulink blocksets, but at the same time automatically translates designs into
hardware implementations that are faithful, synthesizable, and efficient.
The implementation is faithful in that the system model and hardware
implementation are bit-identical and cycle-identical at sample times defined in
Simulink. The implementation is made efficient through the instantiation of
intellectual property (IP) blocks that provide a range of functionality from arithmetic
operations to complex DSP functions. These IP blocks have been carefully designed
to run at high speed and to be area efficient. In System Generator, the capabilities of
IP blocks have been extended transparently and automatically to fit gracefully into a
system level framework. For example, although the underlying IP blocks operate on
unsigned integers, System Generator allows signed and unsigned fixed point
numbers to be used, including saturation arithmetic and rounding. User-defined IP
blocks can be incorporated into a System Generator model as black boxes which will
be embedded by the tool into the HDL implementation of the design.
Introduction
System Level Modeling with System Generator
The creation of a DSP design begins with a mathematical description of the operations
needed and concludes with a hardware realization of the algorithm. The hardware
implementation is rarely faithful to the original functional description --instead it is
faithful enough. The challenge is to make the hardware area and speed efficient while
still producing acceptable results.
In a typical design flow --a flow supported by System Generator-- the following steps
occur:
1.Describe the algorithm in mathematical terms,
2.Realize the algorithm in the design environment, initially using double precision,
3.Trim double precision arithmetic down to fixed point,
4.Translate the design into efficient hardware.
Step 4 is error prone because it can be difficult to guarantee the hardware implements
the design faithfully. System Generator eliminates this concern by automatically
generating a faithful hardware implementation.
Step 3 is error prone because an efficient hardware implementation uses just enough
fixed point precision to give correct results. System Generator does not automate this
step, which typically involves subtle trade off analysis, but it does provide tools to
make the process tractable. You might wonder why it is not possible to eliminate Step
System Generator9
Xilinx System Generator v2.1 Reference Guide
3 and simply use floating point operations in hardware. The answer is that most
operations have a sufficiently small dynamic range that a fixed point representation is
acceptable, and the hardware realization of fixed point is considerably cheaper.
The System Generator Design Flow
Simulink provides a graphical environment for creating and modeling dynamical
systems. System Generator consists of a Simulink library called the Xilinx Blockset,
and software to translate a Simulink model into a hardware realization of the model.
System Generator maps system parameters defined in Simulink (e.g. as mask
variables in Xilinx Blockset blocks), into entities and architectures, ports, signals, and
attributes in a hardware realization. In addition, System Generator automatically
produces command files for FPGA synthesis, HDL simulation, and implementation
tools, so that the user can work entirely in graphical environments in going from
system specification to hardware realization.
10Xilinx Development System
The System Generator design flow is shown in the following figure.
Introduction
Library
(including
Xilinx
Blockset)
Simulation
including
S-functions
Synthesis
ENTITY mult IS
GENERIC(w:
PORT(a,b:IN
PORT(y:OUT
END ENTITY
...
VHDL
Input
MATLAB Environment
System Model
1–
Z
+
k
System Generator
Code Generation Software
- map to IP libraries
- control signals
- VHDL design
- HDL testbench
- constraints
- simulation scripts, project files
Core
Parameters
Output
Simulink
Simulation
Data
Xilinx
DesignTools
Environment
Synthesis
Compiler
EDIF
FPGA
Place & Route
Bit stream
EDIF + Timing
CORE
Generator
Test
Vectors
Logic
Simulator
Pass/Fail
Figure 1-1: System Generator design flow diagram
The Xilinx Blockset is accessible in the Simulink library browser, and elements can be
freely combined with other Simulink elements. Only those subsystems denoted as
Xilinx black boxes, and blocks and subsystems consisting of blocks from the Xilinx
Blockset are translated by System Generator into a hardware realization. The
generation process is controlled from the System Generator block found in the Xilinx
Blockset Basic Elements library. The System Generator parameterization GUI allows
the user to choose the target FPGA device, target system clock period, and other
implementation options.
System Generator translates the Simulink model into a hardware realization by
mapping Xilinx Blockset elements into IP library modules, inferring control signals
and circuitry from system parameters (e.g. sample periods), and converting the
The System Generator Design Flow11
Xilinx System Generator v2.1 Reference Guide
Simulink hierarchy into a hierarchical VHDL netlist. In addition, System Generator
creates the necessary command files to create the IP block netlists using CORE
Generator, invokes CORE Generator, and creates project and script files for HDL
simulation, synthesis, technology mapping, placement, routing, and bit stream
generation. To ensure efficient compilation of multi-rate systems, System Generator
creates constraint files for the physical implementation tools. System Generator also
creates an HDL test bench for the generated realization, including test vectors
computed during Simulink simulation.
Arithmetic Data Types
System Generator provides the three arithmetic data types that are of greatest use in
DSP: double precision floating point, and signed and unsigned fixed point numbers.
Floating point data cannot be converted into hardware, but is supported for
simulation and modeling.
The set of signed arbitrary precision fixed point numbers has nice mathematical
properties, allowing for operations that are much cleaner than those on familiar
floating point representations. Operations on floating point numbers entail implicit
rounding on the result, and consequently, desirable algebraic characteristics such as
associativity and distributivity are lost. Both are retained for arbitrary precision fixed
point numbers.
System Generator allows the quantization of the design to be addressed as an issue
separate from the implementation of the mathematical algorithm. The transition from
double precision to fixed point can be done selectively. In practice this means the
designer gets the design working using double precision, then converts to fixed point
incrementally. At all times, these three representations can be freely intermingled
without any changes to the signal flow graph. This mixing is possible because library
building blocks are polymorphic, changing their internal behavior based on the types
of their inputs.
There is another benefit from this scheme in which quantization events are broken out
as separate design parameters. At every point and stage of the design, the designer
can specify how both the overflow and the rounding issues are to be addressed. For
cases of overflow, the designer can choose whether or not saturation should be
applied, and do so in consideration of the hardware cost versus the benefit to the
system design. Saturation is a more faithful reflection of the underlying mathematics,
but more expensive in hardware; wrapping is inexpensive but less faithful. It is also
possible to trap overflow events in the system level simulation, which can be a useful
debugging mechanism in the design of subsystem that are intended never to result in
overflow.
Likewise, when quantizing at the least significant bit, the designer can choose
whether the value should be truncated (with no hardware cost) or rounded under
some particular rule (possibly improving the system design, but with added cost in
hardware).
In System Generator, many operators support full precision outputs, which means that
the output precision is always sufficient to carry out the operation without loss
information. Combined with the data type propagation rules supported in Simulink,
this allows great convenience when designing an algorithm. Naturally, any operator
that increases the output width of its inputs (e.g. an adder) cannot feed back on itself
with full precision.
The designer specifies the translation to fixed precision at key points in the design (in
particular, at gateways from the outside world and in feedback loops), and System
12Xilinx Development System
Generator then propagates signal types and precisions as appropriate. The
automatically chosen type is the least expensive that preserves full precision.
Translations from signed to unsigned and vice versa are automatic as well.
System Generator also allows designs to contain elements that cannot be realized in
hardware, but assist development and debugging. Examples of such elements are
signal sources, scopes, and machinery that tracks the divergence between fixed point
and double precision calculations. System Generator automatically discards such
elements when asked to translate to hardware.
Hardware Handshaking
In Simulink, time evolution is defined by sample rates for each block in the system.
There are propagation rules along signals so that not every block need set an explicit
sample period. This is extremely flexible, but has implications for modeling
hardware. Sequential circuits are clocked, and a key aspect of designing, especially
multirate systems, is the interplay between clock and clock enable signals. Although
abstracted, a bit and cycle true simulation must have mechanisms for defining and
controlling clocked behavior in the system model.
Every signal has a fixed point value as defined in the previous section. In addition, it
carries an implicit boolean valid bit that can be used to achieve hardware handshakes
between blocks. For example, upon startup, a pipeline may define its output invalid
until it has flushed its pipe. By inspecting the valid bits of its inputs, a block can
determine how to process its input data.
Introduction
Multirate Systems
Multirate systems can be implemented in System Generator by using sample rate
conversion blocks for up-sampling and down-sampling. The necessary control logic
is automatically generated when the design is netlisted. Before netlisting, the sample
rates in the system are normalized to integer values; in hardware, the system clock
period corresponds to the GCD of the integer sample periods. Clock enables are used
to activate the hardware blocks at the appropriate moment in time with respect to the
system clock.
Consider for example, the multirate system model shown in the figure below, which
consists of I/O registers, an up-sampler, an anti-aliasing filter, and a down-sampler.
The input signal is up-sampled by a factor of two, and subsequently down-sampled
by a factor of three, giving an overall sample rate conversion by a factor of 2/3. The
ST blocks in the system model extract the sample period from a Simulink signal,
which can then be displayed. In the example, the input sample period is one. In the
generated hardware implementation shown below the system model, each element is
driven by the system clock, with its respective clock enable driven according to its
sample period in the original system model.
Figure 1-2: Example of a multirate system model
Hardware Handshaking13
Xilinx System Generator v2.1 Reference Guide
Bit-True and Cycle-True Modeling
System Generator produces a hardware implementation that is bit and cycle true to
the system level simulation. We define the term bit and cycle true at the boundaries of
the design. The boundaries of a design in System Generator are specified by the
presence of Gateway In and Gateway Out blocks. These form interfaces between data
representation within System Generator and data types that can be examined and
manipulated in the standard Simulink environment. The gateways are translated into
ports in the implemented hardware design. The Gateway In blocks become input
ports to the design and the Gateway Out blocks become output ports.
In the Simulink simulation, Gateway in and Out blocks have data samples flowing
through at regular sample periods. The values flowing in provide the stimuli, and
those flowing out represent the response. In the generated hardware, if an identical
stimulus sequence is presented at the input ports (at clock events corresponding to the
input sample periods), then identical output sequences will be observed (here at clock
events corresponding to Simulink output events). The values presented to the
hardware input ports and produced by the output ports are bit vectors interpreted as
representing the fixed point values of the Simulink simulation. This correspondence
between Simulink and hardware results is guaranteed to hold regardless of the
particular input stimulus to the design or the positioning or number of Gateway Out
blocks.
Automatic Testbench Generation
For a black box instantiation, the design must provide both a Simulink model and an
implementation. System Generator cannot automatically provide the verification that
the two representationsof the black box match. Toassist the designer in verifying that
the system model simulated in Simulink mirrors the generated hardware circuit, a
VHDL test bench is automatically created during HDL code generation.
Test bench input stimuli are recorded by Gateway In blocks during Simulink
simulation. These blocks quantize double precision input date into a fixed point
representation. The fixed point values are saved to a data file and then used as input
stimuli during VHDL simulation.
Gateway Out blocks convert the fixed point representation into Simulink floating
point and define the output data ports of the HDL design. The signal connected to the
input of a Gateway In block is sampled at a given sample rate and is used as expecteddata in the HDL simulation.
During HDL code generation, each Gateway In block is translated to a VHDL
component which reads the input stimuli. Gateway Out blocks are translated to
components that compare the VHDL results to the expected results. The comparisons
are performed at the blocks' sample rates. Only values which are tagged as valid by
the valid bit are compared.
The fixed point data type in Simulink is represented using a std_logic_vector in
VHDL. The position of the binary point, size of the container, and treatment of sign
are supplied to the VHDL as generic parameters. To ease the interpretation of fixed
point types in VHDL, the Gateway In and Out blocks convert the
std_logic_vector into a real number representation by using the generic
parameter information. A sequence of real numbers can then be viewed as an analog
waveform in an HDL simulator.
14Xilinx Development System
Xilinx Blockset Overview
This chapter gives an overview of the Xilinx Blockset, including background
information on underlying blockset implementation, which will help you understand
how each block can be used to create and simulate your designs.
This chapter contains the following sections.
•What is a Xilinx Block?
•Instantiating Xilinx Blocks Within a Simulink Model
•The Block Parameters Dialog Box
•The Nature of Signals in the Xilinx Blockset
Xilinx Blockset Overview
Chapter 2
•Use of Xilinx Smart-IP Cores by the System Generator
•Common Options in Xilinx Block Parameters Dialog Box
What is a Xilinx Block?
The Xilinx Blockset is a Simulink
library, accessible from the Simulink
library browser. It consists of building
blocks that can be instantiated within
a Simulink model and, like other
Simulink blocksets, blocks can be
combined to form subsystems and
arbitrary hierarchies. The Xilinx
Gateway blocks (from the Xilinx
Blockset’s MATLAB I/O library) are
used to interface between the Xilinx
Blockset fixed point data type and
other Simulink blocks.
Every Xilinx Block can be configured
using a block parameters dialog box, with
few exceptions even during
simulation. Many blocks share
common parameters, which are
described later in this chapter. Most
also have parameters specific to the
function computed.
The System Generator is able to
generate an FPGA implementation consisting of RTF VHDL and Xilinx Smart-IP
Cores from a Simulink subsystem built from the Xilinx Blockset. The overall design,
including test environment, may consist of arbitrary Simulink blocks. However, the
What is a Xilinx Block?15
Xilinx System Generator v2.1 Reference Guide
portion of a Simulink model to be implemented in an FPGA must be built exclusively
of Xilinx blocks, with the exception of subsystems denoted as black boxes.
Instantiating Xilinx Blocks within a Simulink Model
Xilinx blocks can be dragged (from the Simulink library browser, or from an
expanded sheet showing the blocks in the library) and dropped onto a Simulink
model sheet. Double-clicking on a block icon will open its block parameters dialog
box and allow customization of that instance of the block. It is also possible to build
user libraries of customized blocks and subsystems. Refer to the manual: UsingSimulink from The MathWorks.
The Xilinx blocks operate on fixed point data, using an arbitrary precision arithmetic
type. The Gateway blocks found in the Xilinx MATLAB I/O library comprise the
interface between Xilinx blocks and other Simulink blocks, and enable Xilinx blocks to
be freely instantiated within a Simulink model. Of course, the only blocks that System
Generator will convert to hardware are those from the Xilinx Blockset.
The Block Parameters Dialog Box
Most Xilinx blocks have parameters that can be configured. The typical block has a
dialog box with several common parameters (common to most blocks in the blockset)
and some specific parameters (specific to the particular block only). Double-clicking
on any block icon on a sheet will open its block parameters dialog box. Details of the
use of each block’s parameters dialog can be found elsewhere in this document.
Each parameters dialog contains four buttons: OK, Cancel, Help, and Apply.Apply applies your configuration changes to the block, leaving the box still visible on
your screen. Help launches HTML help information for the block. Cancel closes the
box without saving any changes, and OK applies your configuration changes and
closes the box.
Figure 2-1: Buttons common to each block parameters dialog box
The Nature of Signals in the Xilinx Blockset
The fundamental scalar signal type in Simulink is double precision floating point. In
contrast, for bit and cycle true simulation of hardware, System Generator signals are
representedin an arbitrary precision fixed point arithmetic type. The Xilinx GatewayIn block converts double precision values into fixed point, and the Gateway Out
block converts fixed point values back into double precision floating point.
Some blocks produce full precision values by default, which is to say their output
signal has sufficient precision to represent the output without rounding error or
overflow. Some blocks also support the option of defining the output precision to be a
specific arithmetic type (e.g., 16-bit signed data with 8 bits of fraction), with
quantization options of rounding or truncation, and with overflow options of
saturation or truncation.
16Xilinx Development System
Xilinx Blockset Overview
As an example, the figures shown below depict the Xilinx Negate block parameters
dialog box with full and user defined precision. Note in the latter case the additional
options for selecting quantization and overflow behavior.
Figure 2-2: User-Defined Precision Options (available if selected instead of full
precision)
Valid and Invalid Data
In the Xilinx Blockset portion of a Simulink model, every data sample is accompanied
by a handshake validation signal. In the corresponding hardware, every data-carrying
bus has a companion net that carries a valid or invalid status indicator. This is a
commonly used handshaking mechanism. There are different circumstances under
which the status indicator may be set to invalid. For example, invalid data might
mean that a pipeline has not yet filled up, or it may denote bursty outputs, as with an
FFT. Blocks in the Xilinx Blockset can use this valid bit signal to determine what to do
with the input data. Some of the Xilinx blocks, for example, the storage blocks and the
FFT, use the valid bit to determine when to store input data.
Port Data Types
Selecting the Port Data Types option (under the Format menu in the Simulink
window) shows the data type and precision of a signal. An example port data type
string is Fix_11_9, which indicates that the signal is a signed 11-bit number with the
binary point 9 bits from the right side. Similarly, an unsigned signal is indicated by the
UFix_ prefix.
The Nature of Signals in the Xilinx Blockset17
Xilinx System Generator v2.1 Reference Guide
Use of Xilinx Smart-IP Cores by the System Generator
To increase hardware performance, most System Generator blocks are implemented
using Xilinx Smart-IP (Intellectual Property) LogiCOREs. These are hand crafted
modules that make optimal use of FPGA resources to maximize performance. Some
System Generator blocks map onto multiple LogiCOREs, for example, the 1024-point
FFT, maps onto Dual Port Memory blocks as well as the FFT core itself.
Some Xilinx blocks also can be implemented as synthesizable VHDL modules, hence
the LogiCORE is an option. When such a block cannot be implemented as a
LogiCORE, System Generator automatically maps the block onto the synthesizable
module. For example, the Xilinx Negate block generates a LogiCORE if you specify
input of up to 256 bits, but for more than 256 bits the block is realized in synthesizable
VHDL.
Many Xilinx blocks have implementations only as LogiCOREs. The reason for this is
circuit performance. Because they are handcrafted for FPGA implementation,
LogiCOREs have predictable performance in all design contexts. For example, the
Xilinx FIR Filter block can be implemented only as the Distributed Arithmetic FIR
Filter LogiCORE.
During algorithm exploration in Simulink and System Generator, it is common to
iterate through block customization, Simulink simulation, and code generation. When
you incorporate Black Box functionality, you can also add HDL simulation to this
flow. To speed this design cycle, it is possible to instruct System Generator to not
invoke Xilinx CORE Generator to re-generate LogiCOREs that have already been
generated and have not changed. This can be done on individual blocks by the
Generate Core checkbox control, or globally using the System Generator block
parameters dialog box.
Licensed Cores
The System Generator targets a suite of new ready-to-use licensed LogiCORE
algorithms for forward error correction (FEC), which are critical for detecting and
correcting errors in wired and wireless communication systems during transmission
of data to optimize the use of available bandwidth. The new algorithms include ReedSolomon Encoder/ Decoder, a Viterbi Decoder, and an Interleaver/De-interleaver.
These cores may be used for communication applications such as broadcast
equipment, wireless LAN, cable modems, xDSL, satellite communications,
microwave networks, and digital TV.
The System Generator allows you to build and simulate your FEC designs in Simulink
using the Xilinx Blockset Communication library. System Generator creates a VHDL
design and testbench that allows you to do a VHDL simulation of the FEC cores. Free
evaluation versions of the FEC cores provide the behavioral models needed for VHDL
simulation. The System Generator will allow you to generate the licensed core using
the Xilinx CORE Generator after you have purchased and installed the FEC cores.
Licensing information, as well as instructions for downloading the cores, can be
found at the Xilinx IP Center:
http://www.xilinx.com/ipcenter/fec_index.htm.
18Xilinx Development System
Xilinx LogiCORE Versions
The Xilinx LogiCORE blocks (indicating the version numbers being supported by
the System Generator) used in Xilinx System Generator v2.1 are listed below.
Encoder
DDSDDSV4.0
Dual Port RamMEM_DP_BLOCKV3.2
FIFOSYNC_FIFOV3.0
FFTFFT and MEM_DP_BLOCKV1.0 (Virtex, Spartan-II),
FIR FilterDA_FIRV6.0
Interleaver/
Deinterleaver
InverterGATE_BUSV5.0
LogicalGATE_BUSV5.0
Multiplier (mult)MULT_GENV4.0
Mutiplexer (mux)BUS_MUXV5.0
NegateTWOS_COMPV5.0
RelationalCOMPAREV5.0
RS DecoderRS_DECODERV2.0
RS EncoderRS_ENCODERV2.0
Sine CosineSIN_COSV3.0
Single Port RAMMEM_SP_BLOCK and
State MachinesMEM_SP_BLOCK and
ROMMEM_SP_BLOCK and
Viterbi DecoderVITERBIV1.0
RAM_SHIFTV5.0
CONVOLUTIONV1.0
INTERLEAVERV1.1
DIST_MEM
DIST_MEM
DIST_MEM
Xilinx Blockset Overview
V2.0 (Virtex-II)
V3.2 (MEM_DP_BLOCK)
V3.2(BRAM), V5.0 (dist.)
V3.2(BRAM), V5.0 (dist.)
V3.2 (BRAM), V5.0 (dist.)
Common Options in Block Parameters Dialog Box
Each Xilinx block has several configurable parameters, seen in the block parameters
dialog box. Many of these parameters are specific to that particular block. Those block
Common Options in Block Parameters Dialog Box19
Xilinx System Generator v2.1 Reference Guide
specific parameters are described in the specific block documentation in the next
chapter.
The remainder of the parameters in each block’s parameters dialog box are common
to most blocks. These common parameters are described below.
Arithmetic Type
In the Type field of the block parameters dialog box, you can choose unsigned or
signed (two’s complement) as the datatype of the output signal.
Implement with Xilinx Smart-IP Core (if possible)
This checkbox (sometimes referred to as the Use Core checkbox) asks the software to
instantiate a core in the generated VHDL. If you do not select this checkbox, the
software will instead create synthesizable VHDL.
Selecting this option does not guarantee that a Xilinx LogiCORE will be used. If the
parameters for your block are such that a core cannot be generated, synthesizable
VHDL will be generated instead. The System Generator software determines this at
code generation time.
Generate Core
Latency
When the Generate Core checkbox is selected, the Xilinx CORE Generator will be
invoked during System Generator code generation. If Generate Core is not selected, a
Xilinx LogiCORE will not be generated, and if the core doesn’t already exist in your
project directory, subsequently running the Xilinx Implementation tools will produce
an error.
If you select Implement with Xilinx Smart-IP Core but do not select
Generate Core, you will be able to simulate your generated VHDL because (1) a
core will be instantiated in the VHDL, and (2) the behavioral VHDL models will be
available for a simulator to use. However, you will not be able to complete
implementation into a Xilinx FPGA until you have also generated the core.
In some blocks, only the Generate Core option is available. If the Implementwith Smart IP-Core option is not available, only a core implementation is
available from the System Generator, but no synthesizable VHDL implementation.
Use Placement Information for Core
If Generate Core is selected,the generated core includes relative placement
information. This generally results in a faster implementation. Because the placement
is constrained by this information, it can sometimes hinder the place and route
software.
Many elements in the Xilinx Blockset have a latency option. This defines the number
of sample periods by which the block’s output is delayed. One sample period may
correspond to multiple clock cycles in the corresponding FPGA implementation (for
example, when the hardware is overclocked with respect to the Simulink model).
System Generator v2.1 does not perform extensive pipelining; additional latency is
usually implemented as a shift register on the output of the block.
20Xilinx Development System
Precision
The fundamental computational mode in the Xilinx Blockset is arbitrary precision
fixed point arithmetic. Most blocks give you the option of choosing the precision, i.e.
the number of bits and binary point position.
By default, the output of Xilinx blocks is full precision; that is, sufficient precision to
represent the result without error. Most blocks have a User-Defined precision option
that fixes the number of total and fractional bits.
Number of Bits
When you have specify user-defined precision, you will be asked to specify how
many bits the output should have.
Binary Point
You will also be asked to specify how many bits are to the right of the binary point
(i.e., the size of the fraction). The binary point position must be between zero and the
number of bits in the number’s container.
Overflow and Quantization
Xilinx Blockset Overview
When user-defined precision is selected, errors may result from overflow or
quantization. Overflow occurs if a value lies outside the representable range.
Quantization error occurs if the number of fractional bits is insufficient to represent
the fractional portion of a value.
The Xilinx fixed point data type supports several options for user-defined precision.
In the case of overflow, the options are to saturate to the largest positive (or smallest
negative) value, wrap the value (i.e., discard any significant bits beyond the mostsignificant bit in the fixed point number), or flag an overflow as a Simulink error
during simulation.
In the case of quantization, the options are to round to the nearest representable value
or to the value farthest from zero if there are two equidistant nearest representable
values, or to truncate the data (i.e., discard bits to the right of the least significant bit).
It is important to realize that whatever option is selected, the generated HDL model
and Simulink model will behave identically.
Override with Doubles
An Override with Doubles message appears on many Xilinx Blocks, with some
variations. Variations are:
Override Computation with Doubles
Override Constant with Double
Override Output with Doubles
Override Storage with Doubles
Most Simulink blocks use double precision floating point signals and arithmetic.
However, when such a signal passes through Xilinx Gateway In block, it is converted
to a fixed point signal. Later, when passing through a Xilinx Gateway Out block, the
signals are converted back into double precision floating point.
Common Options in Block Parameters Dialog Box21
Xilinx System Generator v2.1 Reference Guide
In the Simulink environment, the Override with Doubles option allows you to
simulate the entire design in double precision floating point.
This option is useful in selecting fixed point widths or when debugging. If you detect
unacceptable quahtization errors with fixed point signals, you can choose to simulate
your entire design, or only specific blocks, using double precision floating point
signals and arithmetic operations. This option will help you discover which part of
your design is responsible for the unacceptable quantization error.
You may choose Override with Doubles on a particular block. You may also choose
this option for an entire sheet or an entire subsystem (the sheet plus underlying
hierarchy) by instantiating a System Generator token on the sheet, and choosing
Override with Doubles as one of the System Generator block’s configurable
parameters.
When the output of one block with Override with Doubles set is connected to the
input of another block where the option is also set, data samples are transmitted in
double precision.
You can easily identify which blocks are currently set to Override with Doubles.
When this option is set, affected Xilinx blocks are displayed in gray rather than the
normal blue or yellow.
Sample Period
Data streams are processed at a specific sample rate as they flow through Simulink.
Typically, each block detects the input sample rate and produces the correct sample
rate on its output. Xilinx blocks Up Sample and Down Sample provide a means to
increase or decrease sample rates.
Use Explicit Sample Period
If you select Use Explicit Sample Period rather than the default, you may set the
sample period required for all the block outputs. This is useful when implementing
features such as feedback loops in your design. In a feedback loop, it is not possible
for the System Generator to determine a default sample rate, because the loop makes
an input sample rate depend on a yet-to-be-determined output sample rate. System
Generator under these circumstances requires you to supply a hint to establish sample
periods throughout a loop.
The following image (the Concat block’s parameters dialog box) shows the options
with Use Explicit Sample Period selected.
Figure 2-3: Use Explicit Sample Period options (available if selected)
22Xilinx Development System
Xilinx Blocks
This chapter describes each Xilinx block in detail. Xilinx blocks are grouped within six
categories, also shown in the Simulink library browser. They are:
•Basic Elements
•Communication
•DSP
•Math
•MATLAB I/O
•Memory
Xilinx Blocks
Chapter 3
•State Machine
Basic Elements
The Xilinx Basic Elements library includes the standard building blocks for digital
designs. Using these blocks, you may insert delay, change the sample rate, and
introduce constants, counters, multiplexers, etc. The Basic Elements library also has
two special blocks: the System Generator and the Black Box.
System Generator
Simulink simulation and code generation.
The System Generator is a special Xilinx block that invokes the tool’s
code generation software.
By placing the System Generator token on your Simulink project sheet,
you can generate HDL and Xilinx LogiCOREs for all the Xilinx blocks
on that sheet and on any sheets beneath it in the hierarchy. The System
Generator block parameters dialog box allows you to tailor your
Basic Elements23
Xilinx System Generator v2.1 Reference Guide
Block Parameters Dialog Box
The block parameters dialog box can be invoked by double-clicking the icon in your
Simulink model.
Figure 3-1: System Generator block parameters dialog box
Parameters specific to the System Generator block are:
•Xilinx Product Family
Supported families currently are: Virtex, Virtex2, Spartan2, and VirtexE.
•Target Directory
Specify where the output files (VHDL, cores, and project files) will be written. It is
suggested that you create a separate directory (away from your Simulink model
files) to generate your files in order to keep your Xilinx project files and Simulink
model files directories organized separately.
•System Clock Period
Enter the desired System Clock Period of your design in nanoseconds (ns). This
information will be passed to the Xilinx software tools through the user
constraints file (.ucf) that will be created by the System Generator. This value
will be used as the global PERIOD constraint and multi-cycle paths will be
constrained to a multiple of this value.
•Create Testbench
Checking the Create Testbench box instructs the tool to save test vectors to be
used downstream, during behavioral simulation.
When the Create Testbench box is checked, a VHDL testbench wrapper file is
created for your design. Data vectors (created during Simulink simulation) are
also generated.
24Xilinx Development System
Xilinx Blocks
The wrapper file is named to match the top level VHDL file generated for your
project. For example, if your top level file is named design_project, the
wrapper is called design_project_testbench.vhd. The top level of the
project is taken to be the Simulink sheet from which you invoked the System
Generator token.
In addition to the testbench VHDL file, test vectors (.dat files) are also generated.
These vectors represent the inputs and expected outputs seen in Simulink
simulation. The testbench (which uses these test vectors) can be run in a
behavioral simulator such as ModelSim from Model Technology.It will report any
discrepancies between the Simulink and VHDL simulations.
•Global Clock Enable and Global Clear
A global clock enable or clear clock signal can be added to the design by selecting
these options. This may result in a large fanout signal thus degrading system
performance. Use this option only if absolutely necessary.
•Override with Doubles
The System Generator token allows you to override fixed point values with
double precision values for your Simulink simulation. This is particularly useful
during design and debugging. The Override with Doubles directive from a
System Generator token is applied to all Xilinx blocks on the same sheet and
recursively through all subsystems on the sheet. Additional System Generator
tokens can be inserted into the subsystems to selectively mask this effect. For an
explanation of the Override with Doubles behavior, see the Common
Parameters section of the previous chapter.
•Generate Cores
The Generate Cores pulldown menu on the System Generator token gives three
ways to determine for which blocks the Xilinx LogiCOREs should be generated. They
are:
♦According to Block Masks: Each block that uses a Xilinx LogiCORE has
a Generate Core checkbox on its parameters dialog box. When
According to Block Masks is selected on the System Generator dialog,
a core is generated for each block whose Generate Core box is checked.
♦Everywhere Available: When Everywhere Available is selected,
cores are generated without regard to the settings of Generate Core checkboxes on individual blocks.
♦Not Needed - Already Generated: When Not Needed - Already
Generated is selected, no cores are generated. This is useful in the early
stages of design development because it saves the time that would otherwise
be used in unnecessary calls to the Xilinx CORE Generator. When, in the later
stages, you plan to run the design through the Xilinx Implementation tools,
you must remember to regenerate your design with According to BlockMasks or Everywhere Available selected so that your cores are up to
date.
•Generate button
Finally, clicking the Generate button invokes the code generation software, and
your Simulink design is converted to VHDL and Xilinx LogiCOREs. Note that the
Cancel button is active during code generation. If you want to cancel the code
generation phase while it is running, you may do so by selecting Cancel during
code generation.
Basic Elements25
Xilinx System Generator v2.1 Reference Guide
Addressable Shift Register
The Xilinx Addressable Shift Register block is a variable-length
shift register (or delay chain). This block differs from the Xilinx
Delay block in that the amount of latency experienced by data
from input to block output is variable and depends on the address
value.
Data presented to the block will traverse the entire delay chain.
The output of the block is not necessarily the output of the last register in the chain,
however. Instead, the output of the block is taken from the register pointed to by the
address presented on the addr port.
Block Interface
The block interface (inputs and outputs as seen on the Addressable Shift Register
icon) are as follows:
Input signals:
d data input
addr address
en enable signal
Output signals:
q data output
In Simulink, the addr port is given priority over the data (d) port, i.e. on each
successive cycle, the addressed data value is read from the register before the shift
operation occurs. This order is needed in the Simulink software model to guarantee
one clock cycle of latency between the data port and the first register of the delay
chain. (If the shift operation were to come first, followed by the read, then there would
be no delay, and the hardware would be incorrect.)
26Xilinx Development System
Xilinx Blocks
Block Parameters Dialog Box
The Addressable Shift Register Block Parameters Dialog Box can be invoked by
double-clicking the icon in your Simulink model.
Parameters specific to the Addressable Shift Register block are:
•Infer Maximum Latency (depth) using Address Port Width: you can
choose to allow the block to automatically determine the depth or maximum
latency of the shift-register based on the bit-width of the address port.
•Maximum Latency (depth): In the case thaqt the maximum latency is not
inferred (previous option), the maximum latency can be set explicitly.It must be a
positive integer.
•Allow Additional Hardware in Certain Rate-Change Cases: several
rate-change conditions require the use of extra hardware beyond that used by the
IP core to make it compliant with the Simulink simulation output. A rate-change
condition will be detected if the address and data rates differ and the address port
is running at a non-system rate. Choosing this parameter allows additonal
hardware to be used in these cases.
•Use Enable Port: when checked, the optional enable port is activated.
Other parameters used by this block are explained in the Common Parameters section
of the previous chapter.
Xilinx LogiCORE
The block always uses the Xilinx LogiCORE Ram-based Shift Register V5.0. When the
Generate Core parameter is checked, the Use Placement Information
parameter provides the option of generating the core as a Relationally Placed Macro
(RPM) or as unplaced logic.
The core datasheet can be found on your local disk at:
The Xilinx Black Box token enables you to instantiate your own
specialized functions in your model, and subsequently into a generated
design. Like the System Generator token, the Black Box token can be
placed in any Simulink subsystem, identifying the subsystem as a black
box. If you choose to include functionality in your Simulink model that
does not exist in the current blockset, any Simulink subsystem can be
treated as a black box. You may want to build a model out of non-Xilinx blocks for an
HDL representation of functionality that you want to turn into a Simulink model.
To create a black box in the System Generator, you must supply both a Simulink
model and a corresponding HDL file.
Incorporating mixed language black boxes
System Generator creates VHDL for the Xilinx blocks in your design. But if you
include a black box that is written in Verilog HDL, System Generator will produce a
mixed language project.
A VHDL black box and a Verilog black box share the same interface, as is seen below
in the description of the block parameters. You must specify the VHDL/Verilog
design unit name, and specify types, names, and values of generics or parameters.
You must also specify how many clocks the black box has and how these clocks
should be associated with ports.
In addition, you must specify whether you are inserting a VHDL black box or a
Verilog black box by choosing the appropriate language in the HDL Language option
on the Black Box block parameter dialog. System Generator will generate a
corresponding wrapper in the chosen language.
Block Parameters Dialog Box
The Black Box block parameters dialog box encapsulates the design information
necessary for the compiler to create the correct instantiation interfaces. This black box
support allows you to abstract commonly used control signals and ports, and then
28Xilinx Development System
Xilinx Blocks
infer them in the generated VHDL. The block parameters dialog box can be invoked
by double-clicking the icon in your Simulink model.
Figure 3-3: Black Box block parameters dialog box
Parameters specified as cell arrays (generic or parameter names, types, and values)
permit several methods for entering data. You can specify your data directly in the
dialog box as shown. You may also specify the cell arrays as MATLAB expressions.
This is useful if you have many elements in your cell arrays. Generic types can be any
VHDL type. Parameter types can be any Verilog type.
The black box block parameters dialog box allows you to specify multiple clocks on a
black box. To handle more than one clock, the System Generator must be told how fast
each clock should run. To specify a clock’s speed, you must associate the clock to a
port on the black box; the frequency of the clock is then the frequency of the signal
passing through the port. System Generator allows more than one port to be
associated to a clock, but all associated ports must have the same frequency.
Note - Constant inputs match any paired frequency.
For example, a black box with two ports (a fast input and a slow output) should have
clocks called fast_clk and slow_clk with frequencies that match those of the
Basic Elements29
Xilinx System Generator v2.1 Reference Guide
input and output ports respectively. To configure the black box, enter the parameters
in the black box block parameters dialog box as shown in the figure below.
Figure 3-4: Customizing Clocks in the Black Box block parameters dialog box
These settings indicate that the black box should have clocks named fast_clk and
slow_clk. The fast_clk should have the same frequency as the samples presented
to input port #1, and the slow_clk should have the same frequency as output port
#1.
Concat
The Xilinx Concat block performs a concatenation of two bit vectors
represented by unsigned integer numbers, i.e. two unsigned numbers
with binary points at position zero.
The Xilinx Reinterpret block provides capabilities that can extend the
functionality of the Concat block.
Block Interface
The block has two input ports and one output port. The two input ports are labeled
hi and low. The number input to the hi port will occupy the most significant bits of
the output and the number that is input to the low port will occupy the least
significant bits of the output.
Block Parameters Dialog Box
The block parameters dialog box can be invoked by double-clicking the icon in your
Simulink model.
Figure 3-5: Concat block parameters dialog box
Parameters used by this block are explained in the Common Parameters section of the
previous chapter.
The Concat block does not use a Xilinx LogiCORE.
30Xilinx Development System
Loading...
+ 118 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.