5.2 HiLDE: HiL Design Environment
5.2.4 HilDE Tool Flow
• Event based communication: to reduce the number of redundant I/O oper-ations, only data that actually changes has to be transferred. While this is straightforward to be implemented in software (Simulink provides appropriate functions), the hardware wrapper has to be extended. The register of every output port is extended with a mechanism to detect changes at the output. For nooutput ports an additional register withnobits stores the results of these de-tectors, and thus indicates which values must be read by the host computer. The number of additional read operations to retrieve this information is dependent on the bit-width of the bus to the host computer, resulting in an overall number of read accesses ˜nr:
˜
nr=∆(out) +l no wordwidth
m
(5.2)
where∆(out) is the number of output ports with a new value. Given thatnr denotes the number of read operations in the standard HiLDE wrapper, the benefitnrn˜r is dependent on the relation of I/Os with regularly changing values to the overall number of I/Os in the DUT. In general DUTs with irregularly changing I/Os will benefit from this technique.
• Transactors: whenever the sequence of events (value changes) is predefined, such as in communication protocols, the number of I/O operations can be reduced even further by implementing adaptors for the simulation and for the FPGA. The amount of savings here is dependent on the complexity of the protocol: instead of transferring all control-signals or control-signal changes, the adaptors detect protocol activity and transfer only the necessary data, such as address and data, the actual protocol handling is processed in the adaptors in the simulation environment and in the FPGA. While the functionality of the HiL simulation is not affected by this method, the amount of I/O operations for a protocol as described in [Kal02] can be reduced by over 90%.
vMAGIC
vMAGIC (VHDL Manipulation and Generation Interface) has been developed to provide a basis for all kinds of code generators by implementing three important basic tasks [16, 11, 17]:
• Reading an existing hardware description of a DUT
• Manipulation of existing hardware description
• Writing of manipulated and/or generated hardware description
Using vMAGIC accelerates design processes whenever uniform tasks can be auto-mated and reused many times, which is the case of the task of generating a HiLDE hardware wrapper (cf. section 5.2.1).
The vMAGIC API is a Java library compatible with run-time environments 1.5 and later. Therefore, it is platform independent and usable in command line tools, graphical user interfaces and scripts. The basic functionality is described in the following points:
Figure 5.11: vMAGIC Designflow, reading and writing VHDL is optional. As such a vMAGIC application can be a pure VHDL generator or analyzer
• Parser:vMAGIC implements a VHDL’93 compliant parser to transform VHDL code into a more convenient internal representation called AST (Abstract Syn-tax Tree). An AST in general contains all information from the code, while redundancy (parenthesis, semicolons and so on are implicitly included in the tree structure) is removed; this AST however is shaped in a way optimally suited for the manipulations described next.
The vMAGIC parser was generated using ANTLR 3.1 [Par95], a powerful parser generator; parsers generated with ANTLR support certain error recovery strategies. This implies that the vMAGIC parser can correct certain syntactical errors while parsing VHDL source code.
• Modification and generation of code: The AST by itself is a tree structure, which is not well suited for human interaction. To hide this structure behind a simple API, a set of so-called meta-classes was defined. Meta-classes com-bine the functionality to generate or modify specific VHDL constructs and the
knowledge how to interact with the AST, such that the developer is using a homogenous API with intuitive functions. E.g., Signal.getIdentifier() returns the identifier of a signal,new Process()creates a new VHDL process.
Objects of meta-classes are created either by the user, defining a VHDL design from scratch, or using a VHDL template. The template is parsed into an AST, which is then parsed by a tree parser generating the meta-objects and discarding the original tree. This approach is, again assuming that the tree grammar is correct, another means of ensuring that the generated code is correct regardless of coding style or context. The meta-objects implicitly define a descendible tree structure, beginning with aVhdlFileobject with members forEntityand Architectureobjects and so on. User programs work on this meta-tree rather than on the AST, allowing for intuitive software development for hardware generation or analysis purposes.
There are two different levels of abstraction represented by meta-classes: the so-called low-level classes represent basic VHDL constructs such as signal declarations or processes; the high-level meta-classes combine several low-level classes such as to create complex functionality like registers or state machines.
The use of high-level classes implies a higher level of abstraction and therefore an improved coding speed.
• VHDL Writer: To generate VHDL code from an AST, a VHDL Writer based on ANTLR’s StringTemplate system was developed. Again, a tree parser is used to analyse the tree and templates are used to generate VHDL code constructs.
These templates are defined in a single text file in a very simple format, such that the developers preference in coding style (e.g., the use of lower case or upper case letters for keywords, or using optional identifiers at the end of a process or entity) are implementable by changing this text file.
The vMAGIC design flow, as depicted in fig. 5.11, follows the three steps as described above. The generation of the HiLDE hardware wrapper is a very uniform procedure, usually varying only in the number and width of I/Os, or in the transfer mode as described above. The following steps are completed by a Java program utilizing vMAGIC:
1. Parse the DUT and a special template file
2. Create an instance of the host communication bus and connect the Synchronizer to the bus
3. Declare and instantiate the DUT in the template
4. Create registers for ever I/O port and connect them to the DUT instance 5. Add all registers to the bus
6. Generate configuration files for different simulators (currently Simulink, and CaMEL-View)
While the manual (error prone) implementation of the wrapper can take hours, the HiLDE Wrapper Generator takes seconds at most. To setup a HiLDE simulation, there are two possible tool flows, depending on weather the target simulation software is Matlab/Simulink or CaMEL-View. Both flows are described in the following sections.
Simulink Tool Flow
The design flow presented in this work supports any hardware VHDL-based descrip-tion. The tool-flow for a Matlab/Simulink based FPGA-iL simulation is presented in figure 5.12.
VHDL wrapper + CCodeElement
-parameters
MAP, PAR Configuration File
wrapper generation
CAMeL-View configuration HW generation
FPGA-in-the-Loop simulation
Software
(Host Computer)
Hardware
(RAPTOR2000 )
Netlist file VHDL file
Matlab/Simulink vMAGIC ISE (Xilinx)
Matlab/Simulink
Hardware description
Figure 5.12: Toolflow for HiL simulations with Matlab/Simulink
Typically, a SiL simulation is first done using a hardware description of the DUT.
After obtaining a satisfactory simulation, a vMAGIC application is used to integrate the DUT into the Matlab/Simulink framework, as described in the previous section.
The generated VHDL file can then be synthesised using vendor specific tools (e.g., ISE from Xilinx) to generate an FPGA configuration file. Configuration files for the Matlab/Simulink simulation interfaces are also generated by vMAGIC. Using these files, an FPGA-iL simulation can be setup in Matlab/Simulink.
The simulations are performed as usual. However, the designer can now realise whether the controller, which is executed on an FPGA module of the RAPTOR system, works as expected. In this stage more intensive tests can be conducted. Since the structure of the controller has already been designed and tested, the next step is an intensive test of its parameters or its response to different operative regions. This process is greatly accelerated by HiL simulations, besides the enhanced reliability provided by this kind of simulations.
CAMeL-View Tool Flow
FPGA-iL simulations with CAMeL-View as described in this thesis includes the use of several software tools (cf. figure 5.13). Starting with a description of the plant (e.g., a multi body system) the control engineering components (e.g., controller, observer)
are developed by the designer using CAMeL-View. After the parametrisation of these components, they are exported to Matlab/Simulink along with the model of the plant. In Matlab/Simulink the DUT can be translated to a hardware description after a digitalisation process. This step is done by using System Generator from Xilinx, which automatically generates structural hardware descriptions (e.g., netlists or VHDL) from a very high-level representation. This VHDL or netlist file, containing the implementation together with the corresponding interface description, serves as an input to HiLDE: a hardware wrapper is generated along with the appropriate CCodeElements and parameters for interfacing CAMeL-View. The design is now ready for hardware synthesis through Xilinx ISE, resulting in an FPGA-configuration bitstream containing the controller implementation as well as the appropriate interface for communication with the simulation environment. CAMeL-View can now start an FPGA-iL Simulation according to the steps in figure 5.8.
VHDL wrapper + CCodeElement
-parameters
MAP, PAR Configuration File wrapper generation
CAMeL-View configuration HW generation
HiL simulation with MBS-Model
Software
(Host Computer)
Hardware
(RAPTOR2000 )
Netlist file VHDL file
Matlab/Simulink vMAGIC ISE (Xilinx)
CAMeL-View MBS-Model
Controller /observer structure + parameter controller design
CAMeL-View
modelling
Hardware description
Figure 5.13: Toolflow for FPGA-in-the-Loop simulations with CAMeL-View