Opal-RT RT-XSG toolbox
User Guide
RTXSG-UG-15-01
OPAL-RT Technologies Inc.
TABLE of CONTENTS
CHAPTER 1: INTRODUCTION
About the Opal-RT RT-XSG toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Hardware description language (HDL) and fixed-point numbering . . . 3
Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Organization of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
CHAPTER 2: REQUIREMENTS
Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
CHAPTER 3: HARDWARE DESIGN USING THE RT-XSG TOOLBOX
Field-Programmable Gate Arrays (FPGAs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
RT-XSG-compatible software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Matlab/Simulink® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Xilinx Vivado Design Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Opal-RT Real-Time LABoratory (RT-LAB®) . . . . . . . . . . . . . . . . . . . 7
Introduction to the RT-XSG hardware I/O interfaces. . . . . . . . . . . . . . . . . . . . . 8
RT-XSG FPGA model creation paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
CHAPTER 4: BUILDING MODELS WITH RT-XSG
System generator for DSP toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Mandatory blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Target platform selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Configuration file version selection. . . . . . . . . . . . . . . . . . . . . . . . 13
Hardware configuration set up. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Xilinx System Generator Block . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Building a RT-LAB-compatible RT-XSG model . . . . . . . . . . . . . . . . . . . . . . . . 16
FPGA Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
DataIN and DataOUT Blocks: . . . . . . . . . . . . . . . . . . . . . . . 18
LoadIN and LoadOUT Blocks: . . . . . . . . . . . . . . . . . . . . . . . 20
I/O Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Simulation State Block: . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
ModelSync Tag: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Augmented Dword 33-bit data vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Creating a CONF file for an RT-XSG design . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Supported reconfigurable hardware . . . . . . . . . . . . . . . . . . . . . . . 29
Analog and digital signal types supported in the CONF file . . . . . . . 29
Groups, sections and subsections . . . . . . . . . . . . . . . . . . . . . . . . 30
Manual generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Inserting custom VHDL files into a model . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
© 2015 Opal-RT Technologies Inc.
1
OPAL-RT Technologies Inc.
TABLE of CONTENTS
Offline simulation of a design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Configuration file generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
FPGA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
CHAPTER 5: TROUBLESHOOTING
Test example models and demos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Physical resource shortage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
APPENDIX A: RT-XSG SIMULINK LIBRARY
© 2015 Opal-RT Technologies Inc.
2
© 2015 Opal-RT Technologies Inc. All rights reserved for all countries.
Information in this document is subject to change without notice, and does not represent a commitment on the part
of OPAL-RT Technologies. The software and associated files described in this document are furnished under a license
agreement, and can only be used or copied in accordance with the terms of the agreement. No part of this document
may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying,
recording, or information and retrieval systems, for any purpose other than the purchaser's personal use, without
express written permission of OPAL-RT Technologies Incorporated.
Documents and information relating to or associated with OPAL-RT products, business, or activities, including but
not limited to financial information; data or statements; trade secrets; product research and development; existing
and future product designs and performance specifications; marketing plans or techniques, client lists, computer
programs, processes, and know-how that have been clearly identified and properly marked by OPAL-RT as
“proprietary information,” trade secrets, or company confidential information. The information must have been
developed by OPAL-RT and is not made available to the public without the express consent of OPAL-RT or its legal
counsel.
ARTEMIS, RT-EVENTS, RT-LAB and DINAMO are trademarks of Opal-RT Technologies, Inc. MATLAB, Simulink, RealTime Workshop and SimPowerSystem are trademarks of The Mathworks, Inc. LabVIEW is a trademark of National
Instruments, Inc. QNX is a trademark of QNX Software Systems Ltd. All other brand and product names are
trademarks or service marks of their respective holders and are hereby acknowledged.
We have done our best to ensure that the material found in this publication is both useful and accurate. However,
please be aware that errors may exist in this publication, and that neither the authors nor OPAL-RT Technologies
make any guarantees concerning the accuracy of the information found here or in the use to which it may be put.
Published in Canada
Contact Us
For additional information you may contact the Customer Support team at Opal-RT at the following coordinates:
Tool-Free (US and Canada)
1-877-935-2323 (08:30-17:30 EST)
Phone
1-514-935-2323
Fax
1-514-935-4994
E-mail
support@opal-rt.com
info@opal-rt.com
sales@opal-rt.com
Mail
1751 Richardson Street
Suite 2525
Montreal, Quebec
H3K 1G6
Web
www.opal-rt.com
1
Introduction
1.1
About the Opal-RT RT-XSG toolbox
RT-XSG is a toolbox developed by Opal-RT Technologies inc. It is invoked from within the Xilinx Vivado
Design Suite System Generator environment. It is used to produce the configuration files (or
bitstreams) of the FPGAs of the OPAL-RT simulators.
The user has the freedom to generate a custom, application specific model to be implemented onto the
FPGA device. RT-XSG blockset provides signal conditioning and conversion modules that can then be
attached to the custom model for real-time, hardware-in-the-loop data processing. RT-XSG provides a
convenient, Simulink-based way to build the user model.
The RT-XSG toolbox thus makes FPGA-based cosimulation more straightforward by managing
automatically the configuration file generation according to the specific processing algorithm to be
implemented on the targeted FPGA. It also manages the configuration of the FPGA, as well as t he
transfer of high-bandwidth data between RT-LAB simulation models and the user-defined custom
system running on the FPGA.
1.2
Key Features
Reconfigurability
The supported platform FPGA devices can be configured exactly as required by the user, not just with
the board manufacturer default configuration. Integration with Simulink and the System Generator for
DSP toolbox from Xilinx allows the transfer of Simulink submodels to the FPGA processor for distributed
processing.
In addition, standard and user-developed functions can be stored on the on-board Flash memory for
instant start-up. RT-LAB-compatible platforms can be remotely configured using a network-based
utility. Additionally, all RT-XSG supported products are configurable on-the-fly using a JTAG connection
and the device vendor programming software.
The present guide covers features and blocks compatible with the following OPAL-RT products :
• Xilinx VC707 Virtex-7 based platforms : OP5607 and OP7020;
• Trenz TE0741 Kintex-7 based platforms : OP4510 and OP4520;
• Avnet MMPK7 Kintex-7 based platform : OP4500.
For support of Xilinx Spartan3 or Virtex6 based platforms, please refer to RT-XSG 2.3.x user guide.
Performance
All of our supported products enable update rates of 100 MHz or 200 MHz, providing the capability to
perform time-stamped capture and generation of digital events for high precision switching of signals
such as PWM I/O signaling up to very high frequencies, as I/O scheduling is performed directly on the
board.
Channel Density
Our supported products let the user configure the I/O interfaces to the FPGA computational node
according to its needs. The I/O blockset target the I/O conditioning modules such as the OP5300 family
RTXSG-UG-15-01
1
Introduction
Key Features
in order to provide real-time access to interface I/O signals. The channel density for each of the
supported platform is indicated in the user guide of each specific board (refer to Section 1.3 below).
RTXSG-UG-15-01
2
Hardware description language (HDL) and fixed-point numbering
Intended Audience and Required Skills and Knowledge
The intended user of the Opal-RT RT-XSG Toolbox is a R&D, algorithm or Test Engineer that needs a
reconfigurable, very-high-speed, portable and low-cost processing unit with good analog and/or digital
I/O capabilities.
1.2.1 Hardware description language (HDL) and fixed-point numbering
With the help of Xilinx’s System Generator for DSP Blockset, only minimal programmable logic technical
knowledge is needed to use the RT-XSG-supported platforms. This blockset is used to translate a
Simulink design built using particular library blocks into HDL. This translated design is used by Opal-RT
tools to give access to I/O interfaces and debugging facilities.
However, the user should be familiar with the fixed-point numerical format and fixed-point data
processing. The use of floating point numbers is very heavily resource consuming into FPGA processing
devices and is not suitable in RT-XSG devices as the interface to the conversion modules is in a fixedpoint format. A minimal training on FPGA architecture is also recommended.
1.2.2 Simulink
Simulink is a software package developed by the Mathworks that enables modeling, simulation and
analysis of dynamic systems. Models are described graphically, following a precise format based on a
library of blocks. RT-XSG uses Simulink to define models that will be executed by the reconfigurable
platform. It is expected that the user has a clear understanding of Simulink operation, particularly
regarding the model definition and simulation parameters.
1.3
Organization of this Guide
This document is the user guide. The topics covered are:
• Introduction on page 1- Provides an introduction to simulation
and the principles behind the use of the RT-XSG toolbox for
Matlab/Simulink.
• Requirements on page 5 - Software requirements for the use of
the RT-XSG toolbox .
• Hardware Design using the RT-XSG toolbox on page 7 Desciption of the paradigms behind the RT-XSG environment.
• Building models with RT-XSG on page 11 - Describes the
procedure to develop a RT-XSG-compatible model.
• Troubleshooting on page 37 - Useful topics to resolve RT-XSG
problems.
An overview of the RT-XSG blockset of Simulink blocks is provided in Appendix A.
RTXSG-UG-15-01
3
Conventions
Introduction
1.4
Conventions
Opal-RT guides use the following conventions:
Table 1: General and Typographical Conventions
THIS CONVENTION
Bold
Note:
INDICATES
User interface elements, text that must be typed exactly as shown.
Emphasizes or supplements parts of the text. You can disregard the information in
a note and still complete a task.
Warning:
Describes an action that must be avoided or followed to obtain desired results.
Recommendation:
Describes an action that you may or may not follow and still complete a task.
Code
Sampel code.
Italics
Reference work titles.
Blue Text
Cross-references (internal or external) or hypertext links.
RTXSG-UG-15-01
4
2
Requirements
2.1
Software requirements
The RT-XSG toolbox needs the following software in order to be able to generate a programming file for
the reconfigurable device and to program the platform:
Recommended configuration (with Matlab/Simulink RT-XSG support):
• Microsoft Windows 7 (32-bit or 64-bit version);
• Xilinx Vivado Design Suite 2015.2 with System Generator for DSP,
• Matlab R2014b, 64-bit version
Complete compatibility charts:
1. Hardware chassis and Xilinx Vivado:
RT-XSG-compatible board
OP4500 Chassis
Xilinx Vivado
2015.2
X
Avnet MMPK7 (Kintex7)
OP4510 Chassis
X
Trenz TE0471 (Kintex7)
OP5607 Chassis
X
Xilinx VC707 (Virtex7)
OP7020 Chassis
X
Xilinx VC707 (Virtex7)
N/A - Xilinx Vivado Unsupported
X - Xilinx Vivado and RT-XSG supported
RTXSG-UG-15-01
5
Software requirements
Requirements
2. Xilinx Vivado and Matlab:
Xilinx / Matlab
compatibility
Matlab R2014b
Xilinx Vivado
2015.2
X
N/A - Xilinx Vivado or RT-XSG Unsupported
X - Xilinx and RT-XSG supported
3. Xilinx Vivado and Windows:
Xilinx / Matlab
compatibility
Windows 7
Xilinx Vivado
2015.2
X
N/A - Xilinx Vivado Unsupported
X - Xilinx Vivado and RT-XSG supported
RTXSG-UG-15-01
6
Hardware Design using the RT-XSG toolbox
3.1
3
Field-Programmable Gate Arrays (FPGAs)
An FPGA is a programmable logic semiconductor device. Depending on the device model, it includes a
certain number of programmable logic blocks and built-in functions. Many devices, including all OpalRT-supported devices, are fully reconfigurable, enabling the user to sequentially perform any number of
custom processing on the target platform.
3.2
RT-XSG-compatible software
3.2.1 Matlab/Simulink®
MATLAB is a technical computing software package that integrates programming, calculation and
visualization. MATLAB also includes Simulink; this software package is discussed below. As RT-LAB and
RT-XSG work in conjunction with this environment to define models, the user must be familiar with
aspects of MATLAB as related to Simulink.
Simulink is a software package that enables modeling, simulation and analysis of dynamic systems.
Models are described graphically, following a precise format based on a library of blocks. RT-XSG uses
Simulink to define models that will be converted into configuration data for the targeted platform. It is
expected that you have a clear understanding of Simulink operation, particularly regarding model
definition and the model various simulation parameters.
3.2.2 Xilinx Vivado Design Suite
Xilinx is one of the world major FPGA vendor. The Vivado Design Suite is a complete set of tools
designed by Xilinx, inc. to access, manage and generate the configuration data for their FPGAs. From
within Matlab/Simulink, the System Generator for DSP toolbox, also designed by Xilinx inc., gives
access to a block set suited for implementation on an FPGA. It is assumed that the reader is familiar
with the Xilinx System Generator for DSP toolbox. Please refer to the Xilinx System Generator for DSP
User Guide and introductory tutorials for more information on this toolbox.
Although the user does not have to access them manually, many other components from the Vivado
Design suite are indirectly called from both the System Generator for DSP and RT-XSG toolboxes.
Please refer to the Vivado Design Suite documentation for information on each specific component.
Some of the supported platforms enable the creation of VHDL-only model descriptions. This
configuration does not require Matlab/Simulink, as the configuration data generation is performed from
within the Vivado Design Suite Project Navigator. Detailed information on the use of this feature can be
found in the specific platform RT-XSG documentation (see section 1.3).
3.2.3 Opal-RT Real-Time LABoratory (RT-LAB®)
RT-LAB™ is a distributed real-time platform that facilitates the design process for engineering systems
by taking engineers from Simulink or SystemBuild dynamic models to real-time with hardware-in-theloop simulations, in a very short time, at a low cost. Its scalability allows the developer to add
compute-power where and when needed. It is flexible enough to be applied to the most complex
simulation and control problem, whether it is for real-time hardware-in-the-loop applications or for
speeding up model execution, control and test.
RTXSG-UG-15-01
7
Introduction to the RT-XSG hardware I/O interfaces
Hardware Design using the RT-XSG toolbox
RT-LAB provides tools for running simulations of highly complex models on a network of distributed
run-time targets, communicating via ultra low-latency technologies, in order to achieve the required
performance. In addition, RT-LAB's modular design enables the delivery of economical systems by
supplying only the modules needed by the application in order to minimize computational requirements
and meet customers price targets. This is essential for high-volume embedded applications.
Formerly an integrated component of RT-LAB, the RT-XSG toolbox incorporates features to
communicate at very high speed with a RT-LAB model running in real-time.
3.3
Introduction to the RT-XSG hardware I/O interfaces
A general data processing block diagram is illustrated in Figure 1. The role of the RT-XSG toolbox is to
provide the user with all the facilities necessary to feed the custom processing block with appropriate
data, and to send the generated outputs to an appropriate target. In Figure 1, these roles are
symbolized by the two bold arrows.
Inputs
Signal generators;
System inputs.
Custom
processing
Outputs
Oscilloscope;
System outputs;
Data logging.
Figure 1:General data processing block diagram.
The ‘Input’ and ‘Output’ can be implemented as needed by the application. As examples, consider the
four following cases:
•
Direct input and monitoring devices, as external signal generators and
oscilloscopes, respectively;
•
In a hardware-in-the-loop simulation, outputs are used outside the box to
generate the inputs directly by the hardware under test;
•
In a FPGA-accelerated simulation, as when RT-XSG is used in conjunction with
RT-LAB, the ‘Custom processing’ block is used to offload part of the processing
from the software processor onto the FPGA board. In this case, inputs come
from the processor, and the outputs loop back to the same software model;
•
Any combination of the above.
The type of input/output channel configuration is application specific. Nevertheless, the maximum
channels count is platform-dependent, and is indicated in the specific platform RT-XSG documentation
(see section 1.3).
3.4
RT-XSG FPGA model creation paradigm
In Figure 1, the ‘Custom Processing’ block is designed by the user. It is often referred to as the “User
model”. For simplicity purposes, some structural and technical features are transparent from the user
when working with the RT-XSG toolbox. Specifically, the User model signals are attached to a “base
configuration”, which is the top-level hierarchical entity of the reprogrammable device and is invisible to
the user. The base configuration serves as an interface from the user model to the outside world (i.e.
the components and ports on the target platform outside the programmable device). It manages signal
routing and I/O configuration compatibility with the user model, high-speed bidirectional
RTXSG-UG-15-01
8
RT-XSG FPGA model creation paradigm
communication with any RT-LAB model, along with the LCD user interface for platforms that incorporate
such feature.
The RT-XSG toolbox provides a series of block libraries that give access to a variety of analog and digital
I/O interfaces, along with blocks that enable the transfer of digital signals to and from a RT-LAB
simulation model in real-time. The toolbox facilitates the interface management so that the user can
concentrate on the algorithmic processing part of the design.
Note: A RT-XSG model is usually designed from within the Matlab/Simulink environment. Blocks from the RT-XSG libraries incorporate System
Generator blocks under their mask. Moreover, the FPGA User description model must be built using ONLY blocks from the System Generator for
DSP Blockset. It is advised to pass through the System Generator for DSP tutorials before starting to use the RT-XSG toolbox.
RTXSG-UG-15-01
9
Hardware Design using the RT-XSG toolbox
RTXSG-UG-15-01
RT-XSG FPGA model creation paradigm
10
4
Building models with RT-XSG
This chapter covers important topics related to the creation of a RT-XSG Simulink model. It is assumed
that the user is already familiar with the System Generator for DSP toolbox.
4.1
System generator for DSP toolbox
Xilinx System Generator for DSP is a toolbox provided by Xilinx that consists in two Simulink simulation
libraries1. Using the blocks in these libraries and blocks from the RT-XSG library, a user can construct
and simulate his own FPGA design, download it to the FPGA chip of the reconfigurable I/O card
supported by Opal-RT Technologies, and integrate it in a real-time simulation. Moreover, the System
Generator for DSP toolbox allows a user to create and simulate his own FPGA design without the need
for knowing traditional HDL languages, all in a Matlab/Simulink environment.
The design can implement DSP algorithms like filters, CORDIC algorithms, PWM generators, waveform
generators and much more, and can interface with the I/O cards supported by Opal-RT Technologies.
Note: Simulink designs made using the System Generator for DSP Blockset use intrinsically fixed-point data processing algorithms. Good
knowledge of this numbering format is strongly recommended for the designers of Opal-RT RT-XSG models and, more generally, of any design
including blocks from the System Generator for DSP Blockset.
4.2
Gateways
The System Generator for DSP toolbox is able to convert a model-based Simulink design into an
Hardware Description Language (HDL) file. A programmable device configuration file is then generated
from this HDL description. Input and output ports of the model to be implemented on such device are
inserted in the Simulink model as “Gateway In” and “Gateway Out” blocks, from the Xilinx Blockset
(See Figure 2).
In
Gateway In
Out
Gateway Out
Figure 2:Gateway In and Gateway Out blocks
In an RT-XSG model, the target board is selected by the user in the first designing steps. As the board
layout is fixed, the user does not have control on the input and output port definition. The RT-XSG
library block sets provide the user with all necessary interface blocks. Although the “Gateway In” and
“Gateway Out” blocks are not directly visible by the user on the top hierarchical level of the model, they
are still present under the mask of each of these blocks. In general, interface blocks between the User
model and the external world show a “blue \ yellow” background pattern, while interface blocks
1.Refer to the System Generator for DSP User Guide for further information and tutorials on how to use the toolbox.
RTXSG-UG-15-01
11
Building models with RT-XSG
Mandatory blocks
between the user model and a RT-LAB CPU model have a “blue \ turquoise” background pattern. As an
example, Figure 3 gives the essential interface blocks available for each hardware supported.
Figure 3:Interface blocks (a) to the RT-LAB model and (b) to the external world.
Other interface blocks may be found in the library of each specific FPGA (available via the Simulink
browser), to address specific hardware or support specific communication protocols.
Note that as the user does not have control on the physical board layout, no additional gateway should
be added by the user other than the ones located inside the RT-XSG library blocks.
4.3
4.3.1
Mandatory blocks
Target platform selection
The target platform is selected from the “Opal-RT FPGA Synthesis Manager” block, located in the RTXSG/Tools Blockset. The target platform is selected by the “FPGA development board” drop-down list
(See Figure 4). Many configuration settings are automatically set upon the selection of the target
platform.
It also allows the generation process to be launched
Note: As the different target platforms have different I/O capabilities, the choice of the interface blocks is strongly dependent on the selected
board. Refer to each board documentation for information on the interface blocks compatibility.
RTXSG-UG-15-01
12
Configuration file version selection
OPAL-RT FPGA
Synthesis manager
SynthesisManager
Figure 4:Opal-RT FPGA Synthesis Manager icon and mask. The target platform is selected by the “FPGA
development board” drop-down list.
4.3.2
Configuration file version selection
The configuration file version is used to identify the function of any FPGA configuration. From RT-LAB, it
is possible to retrieve the configuration file version used to configure any RT-XSG-compatible
programmable device. The configuration file version is the combination of the release identification
number (“Version”) and the minor identification number (“Minor ID”). Generally, a single minor
identification number is assigned to a specific intended behavior of the FPGA configuration, while the
release identification number identify subsequent versions of the same design. Figure 5 shows the icon
and mask of the “Version” block, used to set those two identification numbers, located in the RTXSG/Common Blockset
RTXSG-UG-15-01
13
Building models with RT-XSG
Hardware configuration set up
.
Version
1
Version
Figure 5:“Version” block icon and mask, used to set the configuration file version identification numbers.
4.3.3
Hardware configuration set up
The Hardware Configuration Block is provided to help the user select the appropriate analog or digital,
input or output signal interface of the targeted system. The user should specify in this block the exact
configuration of the I/O modules of the system.
Once this block is configured, the user may use the I/O Block to access any I/O interface. The I/O Block
provides the user with all the available signal interface board locations according to the requested
signal type (analog or digital) and direction (input or output).
Figure 6 shows the icon and mask of the “Hardware Configuration” block, used to set the Active Control
card, chassis from factor and the IO card configuration. It is located in the RT-XSG/MMPK7, RTXSG/TE0741 and RT-XSG/VC707 Blocksets
Active Control Card: Select the board on which the FPGA model is run.
Chassis Form Factor: Select the chassis model name. This parameter modifies the Hardware
Configuration Pane and helps locate the available I/O interfaces. Note that ‘FlatIO’ refers to the OP56xx
chassis.
Hardware Configuration: Select the carrier type and then the corresponding modules
RTXSG-UG-15-01
14
Xilinx System Generator Block
Figure 6:“Hardware Configuration” block icon and mask
4.3.4
Xilinx System Generator Block
Every Simulink model containing a block from Xilinx toolbox must contain a System Generator Block. It
allows to select different simulation parameters like: the type of FPGA ship to program, the type of
FPGA language to use, the clock frequency of the design between other.
When generating FPGA configuration files, the Synthesis Manager block takes care of the required
settings, hence for this case it is not necessary to set the mask parameters.
RTXSG-UG-15-01
15
Building a RT-LAB-compatible RT-XSG model
Building models with RT-XSG
Figure 7:Xilinx “System Generator” block icon and mask.
4.4
Building a RT-LAB-compatible RT-XSG model
When designing and RT-XSG-based RT-LAB application, two Simulink models must be created. The first
one, hereafter called the “FPGA model”, contains the RT-XSG blocks required to build the configuration
file to be downloaded in the reconfigurable chip of the target platform.
The second model, the “CPU model”, runs on the target node and contains several interface blocks, the
“OpCtrl” and the different IO functionality blocks, in order to manage the communication between the
CPU model and the FPGA board. These blocks can be interpreted as a bridge between software and
hardware. The CPU model communicates and receives in real-time the data samples to and from the
FPGA through the PCIe bus.
While the “OpCtrl” and the IO blocks of the older FPGA boards (supported in RT-XSG up to 2.3.x) where
located in separate libraries of the RT-LAB I/O blockset, the blocks for the newer FPGA, like Kintex7 and
Virtex7, are unified and located in the RT-LAB I/O/Common library. The “Board Type” parameter of the
“OpCtrl” block allows the user to select the targeted FPGA board.
Example CPU and FPGA models are provided with RT-LAB under folder <RTXSG_ROOT
Folder>\Examples\Rt-Lab\ and can be used as a start point for building your specific FPGA design.
RTXSG-UG-15-01
16
FPGA Model
4.4.1
FPGA Model
Inside the FPGA model, besides the logic to be implemented on the FPGA, certain blocks are required to
establish communication with the CPU Model and also to interact with the IO cards.
Figure 8 shows the OP4510 I/O example model, which can be found at C:\OPAL-RT\RTXSG\v3.x.x.x\Examples\Rt-Lab\Opal-RT\OP4510\Advanced\AIO_DIO_TSDIO_PWMIO_QEIO\Simulink
Figure 8:“ OP4510 I/O Example model
RTXSG-UG-15-01
17
DataIN and DataOUT Blocks:
Building models with RT-XSG
4.4.1.1 DataIN and DataOUT Blocks:
The RT-XSG ’DataIN’ and ’DataOUT’ library blocks control data transfers to and from the CPU.
The DataIN block is used to receive data coming from the CPU model and pass them to the FPGA
model at runtime. The block can have up to 32 ports of 33 bits (see Section 4.5) in the Xilinx UFix
format. Data coming from the DataIN block is updated at the rate of the CPU model simulation time
step. The receive mode can be either synchronous or asynchronous.
The DataIN block contains one input (Data_IN) that can be used for offline simulation, in synchronous
mode. Each element of the vector connected at this input is provided on its associated DataINx output
port. During the generation process (and in the final bitstream file), this Data_IN input is automatically
disabled and the blocks connected to it are discarded. The input of the DataIN block then become the
values sent from the CPU model through DataIn Send blocks.
Figure 9:“Example of basic DataIN implementation
The synchronous mode is associated to the default mode of the DataIn Send block in the CPU model
(one data per port per time-step), there is not time multiplexing on the CPU side. This mode is shown
in Figure 9 for three DataIN ports.
Figure 10:DataIN synchronous mode, assuming there are five (5) FPGA steps in one (1) CPU step:
The asynchronous mode is used when there is time multiplexing on the CPU side. It returns up to 250
words to the FPGA model during each CPU time step. The exact time of arrival in the FPGA model is
unknown.
RTXSG-UG-15-01
18
DataIN and DataOUT Blocks:
The Start of Frame option, allows the user to easily unpack the data when multiple data is being
received per calculation step through the same port (asynchronous mode). This signal is a pulse, of one
FPGA period clock duration, and it is received right before the first valid data of the incoming data
frame at each calculation step. For Example, a value of 010000000000101 in this field sets input ports
1 and 3 and 15 (MSB to LSB port representation) to output the Start of Frame pulse. For this, new ports
labeled SoftIN3, SoftIN5 and SoftIN15 will appear right below the corresponding DataIN port number.
The DataOUT block is used to send data from the FPGA model to the CPU model at runtime. The block
can have up to 32 ports of 33 bits (see Section 4.5) in the Xilinx UFix format. These can be
synchronized and the send mode can either be register or FIFO.
The sample period is usually 10ns on the input ports of the block but data samples are sent to the CPU
model at the CPU model rate.
The block has the capability to show the values to be sent to the FPGA model through its Data_Out
output port during offline simulation. During generation (and in the final bitstream file), this output port
is not used.
Figure 11:DataOUT basic implementation example
The register mode is used when time multiplexing is not needed. It returns one word to the CPU
model at every CPU time step. Only the last data computed on the FPGA is sent to the CPU model.
Figure 12:DataOUT register mode explanation
RTXSG-UG-15-01
19
LoadIN and LoadOUT Blocks:
Building models with RT-XSG
The FIFO mode is used when time multiplexing is needed. The « buffer » on the FPGA can store up to
250 words. To decide if a sample will be stored or not, the block looks for the MSB (bit 32) connected to
that DataOut port. The MSB is the valid bit. If the valid bit is 1, the sample is stored. If the valid bit is
0, the sample is discarded.
Figure 13:DataOUT FIFO mode explanation (FPGA side)
Considering those 3 FPGA steps occurred in the order displayed (Figure 13), we will receive on the CPU
model the results shown in Figure 14.
Figure 14:DataOUT FIFO mode explanation (CPU side)
4.4.1.2 LoadIN and LoadOUT Blocks:
The LoadIN block is used to receive data coming from the CPU model and pass them to the FPGA
model at an specific time. The block can have up to 32 ports of 33 bits (See section 4.5) in the Xilinx
UFix format. Data coming from one of the ports of LoadIN is updated only when its enable signal is
received. The receive mode can be either synchronous or asynchronous. It contains one input (Cfg_IN)
that can be used for offline simulation.
The LoadOUT block is used to send data from the FPGA model to the CPU model at an specific time.
The block can have up to 32 ports of 33 bits (see Section 4.5) in the Xilinx UFix format. These can be
RTXSG-UG-15-01
20
I/O Block
synchronized and the send mode can either be register or FIFO. Data is sent out to the CPU only when
the enable signal for the related port is received.
4.4.1.3 I/O Block
This block gives access to all I/O modules controlled by the targeted FPGA. It uses the Hardware
Configuration block to determine all the interface modules available according to the requested signal
type (analog or digital) and direction (input or output). Implementation of the external connections is
also available to enable offline simulation of the complete system, including external hardware setup.
Note that the block input and output ports depend upon the selected interface board.
Figure 15:I/O Block and mask
The parameters to be set inside its mask are:
- Type: Type of signal to be interfaced (either analog or digital).
- Direction: Direction of signal to be interfaced (either input or output).
RTXSG-UG-15-01
21
Building models with RT-XSG
Analog Output Interface
- Interface: This parameter drop-down menu lists all available interfaces available according to the
selected “Type” and “Direction” parameters and the configuration of the ‘Hardware Config’ block. The
user chooses the appropriate interface to manage the specific signal.
- Characteristics: This parameter is not editable. It shows the interface board characteristics for an
easy identification of the board that corresponds to the selected interface location.
- Multiplex input/output signals: This checkbox can be used to concatenate multiple input or output
signals on the same Simulink net. This may help the user to build cleaner schematics.
- Number of channels: This parameter is used to select the number of channels to appear on the
block icon. This option is not available when the “Multiplex input/output signal” option is selected. In
this case, the channel number is set to the maximal value allowed by the selected interface board
- Show external signal port(s): This checkbox is used to add input or output ports to the block that
represent the external world, from the active control card point of view. These ports can be used to
connect the signals to a model of the external device connected to the signal conditioning modules. This
feature can be very useful for offline simulation of the FPGA model.
4.4.1.3.1
Analog Output Interface
One Analog Output block is used to access all 16 channels of one Analog Output mezzanine installed on
the simulator. Channels can be accessed individually or by groups of two if the option Multiplex is
selected.
When channels are addressed individually, each input of the block represents one channel and must be
driven by a Fix16_11 bit word. The MSB (bit 15) is the sign. Four bits (bits 14 to 11) represent the
integer value while the remaining 11 bits (bits 10 to 0) represent the fractional part. This logic implies
that the Analog Output range is within [+15.999, -16] volts. This is compatible with the DAC chip range
and resolution used on Opal-RT’s Analog Output mezzanine.
When signals are multiplexed (addressed by groups of two), each input of the block represents two
channels and must be driven by a UFix33_0 bit word. The MSB (bit 32) is the valid bit. Bits 31 to 16
represent channel x+1 while bits 15 to 0 represent channel x. The valid bit must be set to 1 for the
outputs to be active. Each channel must have a format equivalent to the Fix16_11 numeric format.
Figure 16:Analog Out Interface block, (a) No multiplexing of signals, (b) Multiplex option selected
RTXSG-UG-15-01
22
Analog Input Interface
The update rate of the outputs can be selected by the user (down to 1us) through the « Convert » input
of the block. To do so, the user must provide a pulse with the required period (for example 1us). The
“ModelSync” signal can be used also (see section 4.4.1.5). As of now, only one update rate can be
selected for all 16 channels.
Figure 17:Analog Out Interface block, implementation example
4.4.1.3.2
Analog Input Interface
One Analog Input block is used to access all 16 channels of one Analog Input mezzanine installed on
the simulator. Channels can be accessed individually or by groups of two (Multiplex option selected).
The acquisition rate of the inputs can be selected by the user (down to 2.5us) through the « Convert »
input of the block. To do so, the user must provide a pulse with the required frequency (for example
2.5us). As of now, only one acquisition rate can be selected for all 16 Analog Input channels.
Figure 18:Analog In Interface block, (a) No multiplexing of signals, (b) Multiplex option selected
When channels are addressed individually, each output of the block represents one channel and is a
Fix16_10 bit word. The MSB (bit 15) is the sign. Four bits (bits 14 to 10) represent the integer value
while the remaining 10 bits (bits 9 to 0) represent the fractional part. This logic implies a range of
[+31.999, -32] volts. The ADC mezzanine by default can do [+20, -20].
RTXSG-UG-15-01
23
Digital Output Interface
Building models with RT-XSG
When Multiplex option is selected (groups of two), each output of the block represents two channels
and is a UFix33_0 bit word. The MSB (bit 32) is the valid bit. Bits 31 to 16 represent channel x+1 while
bits 15 to 0 represent channel x. Each channel is represented using Fix16_10.
Figure 19:Analog In Interface block, implementation example
4.4.1.3.3
Digital Output Interface
One Digital Output block is used to access all 32 channels of one Digital Output mezzanine installed on
the simulator. Channels can be accessed individually or merged in a single 32-bit word.
The update rate is limited by the hardware conditioning only. At some point, the rising time of the
digital output becomes too important compared to the period of the digital signal / PWM. At this point,
the « logic level » detection does not occur fast enough for the duty cycle to be properly represented.
Figure 20:Rising time effect. If this Time high was supposed to represent 50% of the period of the PWM, the
effective pulse shows only around 35%
When channels are addressed individually, each input of the block represents one channel and must be
driven by a 1 bit word. When grouped in a 32-bit word, bit 0 (LSB) will drive channel 0 while bit 31
(MSB) will drive channel 31. A low voltage level is sent as 0 while a high voltage level is sent as 1. The
voltage level itself is set by the user at the hardware level (for example 0 to 5V, 0 to 12V, etc.).
RTXSG-UG-15-01
24
Digital In Interface
Figure 21:Digital Out Interface block, (a) No multiplexing of signals, (b) Multiplex option selected
4.4.1.3.4
Digital In Interface
One Digital Input block is used to access all 32 channels of one Digital Input mezzanine installed on the
simulator. Channels can be accessed individually or retrieved in a single 32-bit word. The update rate is
limited by the hardware conditioning only.
When no multiplexing, each output of the block represents one channel, coded on 1 bit. When grouped,
bit 0 (LSB) represents channel 0 while bit 31 (MSB) represents channel 31. A low voltage level is
returned as 0 while a high voltage level is returned as 1.
RTXSG-UG-15-01
25
Building models with RT-XSG
Simulation State Block:
Figure 22:Digital In Interface block, (a) No multiplexing of signals, (b) Multiplex option selected
4.4.1.4 Simulation State Block:
The Simulation State block returns the various states of the CPU model to the FPGA model. The CPU
model states are Stopped, Pause, Execute, Reset and Load. The Simulation State returns one if the
state is true/active and returns zero if the state is false/inactive. Each output have a size of 1 bit.
This block is commonly (Figure 23) used to define Digital output or Analog output states when the
model is not in execution mode.
RTXSG-UG-15-01
26
ModelSync Tag:
Figure 23:Simulation State Block implementation Example for Dout protection
Note: A bitstream starts running and driving I/Os a few seconds after the simulator is powered on (as
soon as the FPGA chip is powered on). The user cannot control I/Os until the simulation is executing.
This is why such kind of protection is needed depending on applications.
4.4.1.5 ModelSync Tag:
Synchronization pulse train whose period is equal to the specific CPU application time step is available
as a signal named “ModelSync” (available by using a Simulink “From” block). This rate is adjusted to
the actual CPU model step size at the start of the CPU model execution. This rate is typically ranges
from tens to hundreds of microseconds, which is much larger than the FPGA clock period (usually
10ns).
For I/O mapping FPGA generation, it can be used to set the update rates of the I/O blocks or the for the
DataOut block synchronization for example. The tag can also be used for any other purposes at any
place in the FPGA model.
Figure 24:ModelSync, synchronization pulse train
RTXSG-UG-15-01
27
Augmented Dword 33-bit data vectors
Building models with RT-XSG
For the user’s reference, this ModelSync From tag is linked to the ModelSync GoTo tag, found (hidden)
under the RT-XSG « Version » block.
4.5
Augmented Dword 33-bit data vectors
Many RT-XSG blocks communicating 32-bit data vectors (“double words”, or dwords) have input and/or
output ports 33-bit wide. This format is referred to as an “Augmented Dword”. The 33rd bit (the MSB) is
a “valid” bit, used to sample the 32 LSBs by a register or a buffer. Thus, the data output from the
DataIN and from the ADC interface blocks can be sampled when the MSB is found to be active.
Parallely, the DataOUT and the DAC interface blocks sample the input data when the MSB of the 33-bit
inputs is active. A typical application of the 33rd bit of the Augmented Dword to register the data is
illustrated by Figure 25.
In consequence, outputs from the first blocks can be fed directly to the inputs of the latter blocks, and
the data sampling will be performed correctly. Note that even if the “valid” (33rd) bit is activated only
once for each sample period of each signal of the DataIN and ADC interface blocks, the output data
remains unchanged until the next valid data is available, indicated by a new pulse on the 33rd bit of
each output vector.
DataIN
block
DataINi
Slice MSB
Enable
Register
Slice 32
LSBs
Data
Figure 25:Use of the 33rd bit of the Augmented Dword to register the 32-bit data vector.
4.6
Creating a CONF file for an RT-XSG design
An RT-XSG model can be accessed with application-specific RT-LAB blocks from the Opal-RT I/O library. These
blocks perform all the required data scaling and packaging to control the different analog and digital interface
blocks in the RT-XSG model. The CONF file is a text-based file giving the I/O type, count and location related to
each DataIn and DataOut port accessed by the RT-LAB blocks (see Figure 26 for a sample file). The CONF file
must be supplied to the RT-LAB model along with the FPGA configuration file (BIN file), with the same file name
except for the extension.
When is a CONF file required?
The CONF file is required only if the developer wants to access the signals using the application-specific blocks
from the Opal-RT I/O library. It is not required if the signals are interfaced through the lower-level DataIN Send
and DataOUT Recv blocks, for which data scaling and packaging are designed manually by the developer.
RTXSG-UG-15-01
28
Supported reconfigurable hardware
Figure 26:Example of a CONF file.
4.6.1
Supported reconfigurable hardware
The use of application-specific Opal-RT I/O blocks through a CONF file is compatible with all FPGAs supported by
RT-XSG.
4.6.2
Analog and digital signal types supported in the CONF file
The signal types described in Table 2, below, can be referenced by the CONF file so that the Opal-RT I/O blocks
are able to scale and package the communication signals correctly. It is also possible to design custom I/O blocks
that would use additional custom reserved signal names referenced by the CONF file.
Table 2: CONF file supported signal types
I/O type
Direction
Reserved name
Description
AnalogIn
Input
AI
Standard static analog input, inside the range
[-16V, 16V], one value per channel, per time
step.
AnalogOut
Output
AO
Standard static analog output, inside the
range [-16V, 16V], one value per channel, per
time step.
DigitalIn
Input
DI
Standard static digital input (0 or 1). One
value per channel, per time step.
DigitalOut
Output
DO
Standard static digital output (0 or 1). One
value per channel, per time step.
RTXSG-UG-15-01
29
Groups, sections and subsections
Building models with RT-XSG
I/O type
Direction
Reserved name
Description
EventDetector
Input
TSDI
A vector of states and times, giving precise
information on all events that occurred on
each channel during the last time step (in the
RT-Events format).
Event Generator
Output
TSDO
A vector of states and times, giving precise
information on all events that are requested
on each channel during the next time step (in
the RT-Events format).
PWM In
Input
PWMI
Duty and Frequency are retrieve from the
Pulse Width Modulated signals connected to
the digital input during the last time step.
PWM Out
Output
PWMO
Pulse Width Modulated signals produced using
the carrier frequency and the duty cycle
during the next time step.
EncoderIn
Input
QEI
Angle and speed (frequency) of a quadratureencoded digital input triplet (A, B, Z).
EncoderOut
Output
QEO
Requested speed (frequency) of a quadratureencoded digital output triplet (A, B, Z).
Resolver In
Input
RI
Basic resolver, two poles, retrieve angle and
speed from the resolved signal.
Resolver Out
Output
RO
Single-Ended or Differential resolver signals
TSB In
Input
TOM
Time-stamped bridge input signal, giving
equivalent RT-Events signals used by the TSB
block.
Input/Output
Any other name
Any other type name is permitted but can only
be used with the low-level DataIN Send or
DataOut Recv blocks.
Input/Output
Any other name
To send or receive raw data to / from the FPGA
at an specific time when the enable signal is
sent.
DataIn Send
DataOut Recv
LoadIn
LoadOut
4.6.3
Groups, sections and subsections
In order to facilitate I/O lines of Opal-RT hardware are organized in a certain number of groups, sections and
subsections. A group (formally named slot) corresponds to a specific position of digital or analog hardware
interface inside the Opal-RT chassis. Each group consists typically in two I/O mezzanine cards, formelly referred
to as sections, and labelled A and B. Each section is broken down into subsections of eight channels each.
The number of available groups depends on the chassis type, and the number of subsections composing each
section of the group depends on the hardware that is installed in the section. A 32-channel interface card will be
referred to as 4 subsections of eight channels.
As a standard, one RT-LAB interface blocks from the Opal-RT I/O Blockset targets one subsection of hardware,
and each block is associated to one DataIn or DataOut port in the RT-XSG model.
RTXSG-UG-15-01
30
Manual generation
The different subsections referenced by a CONF file can be accessed independently from any number of
subsystems, provided that each subsystem contains the corresponding OpCtrl or OpLnk block (refer to the help of
these blocks for more information). However, each DataIn or DataOut port can be used only by one block in the
RT-LAB design.
Note: Each line of the CONF file corresponds to one DataIN or DataOUT port number, and manages the signals of only one signal subsection. In
the case of FPGA configurations that implement multiplexing of more signal types on the same subsections, more than one DataIN channel can
provide packaged data that relates to the same subsection, the signal type selection being managed by a dedicated port from the DataIn or
LoadIn block.
4.6.4
Manual generation
Manual description of the CONF file is needed.
The following template can be used, adding one row per DataIn and DataOut channel, as required. It is not
mandatory to include all ports in the CONF file: only the ports that will used by application-specific blocks from
the Opal-RT I/O library are required. For some of the IO blocks LoadIN is required and it must be specified in the
conf file. See Figure 26 and Table 4.
PortName
Description
Slot
Section
Subsection
Count
Size
DataIn1
AO
1
A
1
8
16
DataIn2
DO
2
A
1
8
1
DataIn3
TSDO
2
A
2
-1
32
DataIn4
PWMO
2
A
3
8
64
(...)
(...)
(...)
(...)
(...)
(...)
(...)
DataOut1
DI
2
B
1
8
1
DataOut2
TSDI
2
B
2
-1
32
(...)
(...)
(...)
(...)
(...)
(...)
(...)
LoadIn1
PWMO
2
A
3
8
64
(...)
(...)
(...)
(...)
(...)
(...)
(...)
Column description
PortName: The port number from either the DataIn or DataOut block.
Description: Signal type (either one of the reserved names from Table 2 or any other name if the signal is to be
used with the DataIn Send or DataOut Recv block)
Slot: Location of the I/O interface hardware in the chassis.
Section: Section of the I/O interface hardware (A or B).
Subsection: 8-channel signal subsection of the corresponding slot/section pair.
Count: Number of items to send per time step. A value of “-1” is written for signal types for which the data count
is not known a priori in RT-XSG (e.g. TSDI and TSDO signal types, as the number of events per time step is set in
the Opal-RT I/O block itself).
Size: Size in bits of each item to be sent. If Size < 17 bits and Count > 1, many items are concatenated into 32bit packets for optimal communication between the RT-LAB and RT-XSG models.
Note: The typical count and size of the different Opal-RT I/O blocks are indicated in Table 3.
RTXSG-UG-15-01
31
Manual generation
Building models with RT-XSG
Table 3: Typical count and size for the blocks from the Opal-RT I/O library
Signal reserved
name
Typical Count
Typical Size
AI
8
16
8 analog channels, each with one 16-bit data to receive per time step.
AO
8
16
8 analog channels, each with one 16-bit data to send per time step.
DI
8
1
8 digital channels, each with one 1-bit data to receive per time step.
DO
8
1
8 digital channels, each with one 1-bit data to send per time step.
TSDI
-1
32
The length of the RT-Events signal (32-bit) depends on the event count set
in RT-LAB.
TSDO
-1
32
The length of the RT-Events signal (32-bit) depends on the event count set
in RT-LAB.
PWMI
8
64
8 digital channels, each with one 64-bit data to receive per time step.
PWMO
8
64
8 digital channels, each with one 64-bit data to receive per time step.
QEI
2
16
The signal exchanged between RT-XSG and RT-LAB is the angle an rate
values, expressed in a 48-bit data. 6 digital channels are used in the
subsection (two A, B, Z triplets).
QEO
2
48
The signal exchanged between RT-LAB and RT-XSG is the frequency values
and other parameters, expressed in a 16-bit data. 6 digital channels are
used in the subsection (two A, B, Z triplets).
RI
2
96
Angle and speed is retrieve in a 96 bit data, 3 analog input channels are
used to receive the external carrier, sine and cosine and 1analog out
channel might be used to output the carrier
RO
2
160
TOM
8
16
Description
Parameters to generate the resolver signals are expressed in a 160bit data,
1 analog input channel might be used to receive the external carrier and 3
analog out channels for carrier, sine and cosine
8 digital channels, each with one 16-bit data to receive per time step.
Table 4: Opal-RT I/O blocks that require LoadIn
RTXSG-UG-15-01
Signal reserved
name
Typical Count
Typical Size
PWMO
8
64
QEI
2
32
QEO
2
32
RI
2
256
32
Inserting custom VHDL files into a model
4.7
Signal reserved
name
Typical Count
Typical Size
RO
2
32
Inserting custom VHDL files into a model
The easiest way to include custom VHDL into an RT-XSG model is to use the System Generator for DSP
‘Blackbox‘ block. Refer to the System Generator for DSP documentation for details on how to use this
block.
Note 1: During compilation, the RT-XSG toolbox uses a copy of the RT-XSG model to generate the configuration file. This compilation is run in
a temporary folder to prevent any file corruption. As a result, the VHDL file location in the M configuration file of the blackbox bust be specified
as an absolute path, instead of the default relative path.
Note 2: Any non VHDL generation (for instance, DCP files) that must be available during compilation are to be placed in the Matlab current
directory prior to the configuration file generation.
4.8
Offline simulation of a design
Offline simulation of a RT-XSG design in conjunction with a RT-LAB model is not yet possible. Offline
simulation of a standalone RT-XSG model is possible by following the procedure described in the
System Generator for DSP toolbox documentation.
4.9
Configuration file generation
The generation of the FPGA programming file is managed by the “Opal-RT FPGA Synthesis Manager”
block. This block is located in the RT-XSG/Tools Blockset, and must always be present in a RT-XSG
model, with the other mandatory blocks (see section 4.3).
The generation is launched by clicking the “Generate programming file” button in the block graphical
user interface (GUI) (See Figure 27). The file creation may require a lot of time to complete, depending
on the host computer performance, the model complexity1 and the resources available in the target
platform FPGA. Typical configuration file generation time ranges from ten minutes to several hours.
1.The model complexity in this case is a multidimensional term. One side of a complexity problem is related to the number of basic
logical blocks required to perform the processing described by the model. However, the more complex issue of timing constraints is
of major influence on the time required to generate an FPGA configuration file. In particular, long combinational paths in the design
may induce routing delays in the FPGA nets in the order of the chip clock period. If the propagation of a signal in any combination path
in the design exceeds the FPGA clock period, the configuration file generation will fail. Routing the design according to timing constraints specific to each board is an iterative operation, and may require much time to complete.
RTXSG-UG-15-01
33
Configuration file generation
Building models with RT-XSG
Figure 27:The FPGA configuration file is created by clicking the “Generate programming file” button in the OpalRT FPGA Synthesis Manager block GUI.
In order to generate the programming file, the following steps must be performed:
• Verify the correctness of the design using the “Update diagram”
button from the Simulink toolbar and correct the errors, if any;
• Verify all the mandatory blocks applicable (section 4.3) are placed
inside the model
• Insert a ‘Synthesis Manager’ block into your design. In this block
GUI, select the appropriate reprogrammable platform from the list
and click the “Generate programming file” button.
The following steps are performed during the configuration file generation:
1.
The configuration options associated to the specific target platform chosen in
the Opal-RT Synthesis Manager block are set. The “System Generator” block
from the System Generator for DSP toolbox library is modified with the
appropriate options. Thus, any manual setting done by the user in this block is
not used for the configuration file generation;
2.
The RT-XSG model is completed by adding dummy elements to unused inputs
and output ports of the model (for example, if any interface block is not
present in the original RT-XSG model);
RTXSG-UG-15-01
34
FPGA configuration
3.
All required hardware cores are generated using the Coregen tool from the
Vivado IP Integrator;
4.
The “System Generator” block is invoked and the Configuration file generation
is performed. A new window is displayed, logging the ongoing process. During
this step, Vivado Design Suite is called in non-project flow to perform logic
synthesis, implementation (place & route) and bitstream generation. If any
error occurs during this step, the following files contain the log of the processes
until the error occurs:
• <model folder>\RT-XSG Reports\Synthesis.result:
Log of the synthesis process, during which the generated HDL code is
compiled and translated into logical equations;
• <model folder>\RT-XSG Reports\Xflow.result:
Log of the following processes, during which the synthesized design is
converted into elements specific to the targeted FPGA device. Those
elements are then placed into the device and routed together according to
the specific timing constraints of the target platform. Generation errors,
including resource shortage or routing errors, can be found by parsing this
file.
• <compilation folder>/netlist/vivado/bitstream_generation.rpt
Log the result of the majors steps of the bitstream generation (e.g.
link_design, place_design, route_design).
The result of this step is the FPGA configuration file itself (*.bit);
5.
The target platform Flash memory configuration file is generated from the
FPGA configuration. The Flash memory enables the device to reconfigure itself
automatically after the system power-on. The format of this file is platformdependent (*.bin or *.mcs);
6.
Configuration files are copied into the model folder.
4.10 FPGA configuration
Once the bitstream generation is complete, the bitsrteam must be loaded in the FPGA.
Direct programmation of the FPGA from the Windows computer can be done by the use of the Hardware Manager tool of Vivado.
A JTAG cable must then be connected between an USB port of the windows computer and the JTAG port of the chassis where
the targeted FPGA is located.
However, programming the FPGA via JTAG does not make the bitstream persistent if the chassis is reset or powered off. To
overcome this limitation, RT-LAB and RT-XSG make use of a flash memory of the FPGA board in order to store the bistream
configuration file, so it can be reloaded automatically in the FPGA at power up.
The transfer of the bitstream to the target computer, and its copy in the flash memory of the FPGA are handled by RT-LAB
during the Load phase of the RT-LAB model. For this phase to execute properly the following conditions must be met:
•
the bitstream file and its associated configuration file must be copied to the folder of the RT-LAB model
•
an “OpCtrl” block must be present in one target subsystem (SM_ or SS_) of the RT-LAB model
•
the “OpCtrl” block must specify :
•
the Board Type coresponding to the targeted FPGA,
•
the Bitstream Filename (with .bin extension)
•
the Board index of the FPGA, which is a value between 0 and 255, set on the chassis by the use of dip
switches. This number is used to distinguish between FPGAs of the same type connected to the same
target computer,
After the bitstream file is transferred to the target computer, the tool flash_update is called by RT-LAB.
RTXSG-UG-15-01
35
Building models with RT-XSG
FPGA configuration
This tool first sets the FPGA in programming mode by loading a bitstream called “SAFE” bitstream pre-stored in the FPGA during
factory tests at OPAL-RT. When the FPGA is in SAFE mode, flash_update transfers the new confguration file to the flash memory
of the FPGA. When the bitstream transfer is completed, flash_update sends a command to the FPGA so it reloads itself with
the new bitstream.
Warnings or errors occurrig during flash_update execution are listed in the display window of the RT-LAB model subsystem.
Flash programing is performed only if needed, i.e. when the bitstream specified in the RT-LAB model is different from he
bitstream already programmed in the FPGA.
RTXSG-UG-15-01
36
Troubleshooting
5.1
5
Test example models and demos
Example models can be accessed from Matlab demo browser. To open the example models, type >>
demos on the Matlab prompt, and run one of the “Opal-RT RT-XSG” demo models. The example models
are located in the following folder: <RT_XSG root folder>\Examples.
5.2
Physical resource shortage
Resource management in an FPGA design is a complex science. Even if the target platform includes a
dense reconfigurable device, resource may come to an end. In this case, design optimization for
resource usage must be performed. The first step to this optimization is to look at the map (or
XFlow.results) report.
This file gives informations on which type of resource is insufficient in the device. The designer must
find which of the blocks in the design can be optimized to free these resources. In particular, a small
decrease applied to memory or DSP block port widths can improve significantly the resource usage
efficiency of the entire system.
Parallely, routing problems may occur if long combinational paths are found between sequential
elements in the system. Routing fails if the optimizer is not able to ensure that the signal coming out
from any sequential element has the time to reach all its target sequential elements between two
successive sampling steps. This problem can be resolved by either inserting sequential elements
(registers or delay blocks) into the path to resample the data or by decreasing the sampling rate of the
signal.
RTXSG-UG-15-01
37
Troubleshooting
38
Physical resource shortage
RTXSG-UG-15-01
Appendices
RTXSG-UG-11-01
RT-XSG Simulink library
A
The RT-XSG blockset is organized in a series of sub-libraries accessible via the library browser of Simulink.
Figure 28:Overview of RT-XSG blockset
Applications
The blocks of this library are used for producing or interpreting waveform signals typical to RCP or HIL
simulations, and that can be connected to I/O mangement blocks.
- standard blocks like PWM, Resolver, Encoder orTime-stamp input/Ouput blocks are located at the toplevel of the Applications library,
- the RCP sub-library contains advanced PWM blocks and an Analog Input synchronization block,
Appendix A
40
- the RT-XSG Drive library contains a phase-domain permanent machine model and a series of
quadrature tansformation blocks (Park, Clarke, Concordia).
Common
The Common blockset contains blocks that can be used with any FPGA supported by RT-XSG.
Mathematics
This library contains the RT-XSG Floating-Point (FPGA) library.
MPPK7, TE0471, VC707
These libraries contains the blocksets specific to the FPGAs supported by RT-XSG, They are oranized in
three sub-libraries :
Data packing and unpacking : contain blocks to be connected to I/O interface blocks for roducing or interpreting waveform signals,
Inter-FPGA COMM: contain blocks used in FPGA simulations distributed over two or more FPGAs
when the FPGA calculation step must be synchronmized and data must be exchanged between the
FPGAs via high-speed links,
LowSpeedCommunication: contain blocks of the OAL-RT ORION communication protocol.
Tools
This library contains the Synthesis manager block, fixed-point and floating point conversion blocks and
the XSG Scope library.
Appendix A
Opal-RT XSG BLOCKS
41