Model Composer provides hardware co-simulation, making it possible to incorporate a design running in an FPGA directly into a Simulink® simulation. This allows all (or a portion) of the Model Composer design that had been simulating in Simulink as sequential software to be executed in parallel on the FPGA, and can speed up simulation dramatically. Users of this flow can send larger data sets, or more test vectors, doing an exhaustive functional test of the implemented logic. This increased code coverage allows more corner cases to be verified to help identify design bugs in the logic. Data at the input to the compiled co-simulation block on the Simulink model is sent to the target FPGA, either as one transaction or a burst of transactions, executed for a given number of clock cycles in parallel, and read back to the model's co-simulation outputs.
Hardware co-simulation has two compilation types: burst or non-burst (standard). The burst mode provides much higher performance. Channels to each input of the compiled co-simulation target are opened and packets of data are sent to the open channel, followed by bursting to all of the remaining inputs. The FPGA design is executed in parallel for enough cycles to consume the data, and the target outputs are burst read in a channelized fashion. Bursting provides for less overhead to send and receive large amounts of data from the FPGA. However, burst mode is only supported through MATLAB® script-based hardware co-simulation of the Hardware Co-Simulation target and is not used within Simulink. Exhaustive data vectors can be scripted to test the functionality of the co-simulation target, and an example script is returned as part of the compilation. Non-burst mode has lower performance but allows a compiled co-simulation block to be used within Simulink in place of the original Model Composer design hierarchy.
Board support allows the JTAG-based physical interface to communicate with the co-simulation target: JTAG-based communication is available for most of the JTAG aware boards that exist as a project target in Vivado® . Boards from Xilinx partners are available and can be downloaded from the partner websites and installed as part of the Vivado Design Suite. Custom boards can also be created as detailed in Appendix A, Board Interface File, in the Vivado Design Suite User Guide: System-Level Design Entry (UG895). Setting up board awareness in Model Composer and the minimum tags needed in the board.xml file are detailed in the section Specifying Board Support in Model Composer HDL Blockset.
Hardware Co-Simulation compilation targets automatically create a bitstream based on the selected communication interface and associate it to a block.
- If a board is supported for JTAG hardware co-simulation, the
Hardware Co-Simulation option for Compilation is enabled in the System Generator token dialog box when you perform the procedure described
in Compiling a Model for Hardware Co-Simulation. If
the Hardware Co-Simulation option is grayed out
and disabled, you cannot perform JTAG hardware co-simulation on the board.
This support applies to the following types of boards:
Table 1. Board Support Board Name Display Name zed ZedBoard Zynq Evaluation and Development Kit ac701 Artix-7 AC701 Evaluation Platform 1.0/1.1 kc705 Kintex-7 KC705 Evaluation Platform 1.0/1.1 kcu105 Kintex UltraScale KCU105 Evaluation Platform vc707 Virtex-7 VC707 Evaluation Platform vc709 Virtex-7 VC709 Evaluation Platform vcu108 Virtex UltraScale VCU108 Evaluation Platform zc702 ZYNQ-7 ZC702 Evaluation Board zc706 ZYNQ-7 ZC706 Evaluation Board
- Xilinx boards installed as part of your Vivado installation.
- Partner boards, which are available and can be downloaded from the partner websites and installed as part of the Vivado Design Suite,
- Custom boards, which can be created in the Vivado Design Suite as detailed in Appendix A, Board Interface File, in the Vivado Design Suite User Guide: System-Level Design Entry (UG895).