HDL Verifier™ User's Guide

HDL Verifier™
User’s Guide
R2014a
How to Contact MathWorks
www.mathworks.com Web
comp.soft-sys.matlab Newsgroup
www.mathworks.com/contact_TS.html Technical Support
[email protected] Product enhancement suggestions

[email protected] Bug reports
[email protected] Documentation error reports
[email protected] Order status, license renewals, passcodes
[email protected] Sales, pricing, and general information
508-647-7000 (Phone)
508-647-7001 (Fax)
The MathWorks, Inc.

3 Apple Hill Drive
Natick, MA 01760-2098
For contact information about worldwide offices, see the MathWorks Web site.
HDL Verifier™ User’s Guide
© COPYRIGHT 2003–2014 by The MathWorks, Inc.
The software described in this document is furnished under a license agreement. The software may be used
or copied only under the terms of the license agreement. No part of this manual may be photocopied or
reproduced in any form without prior written consent from The MathWorks, Inc.
FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation
by, for, or through the federal government of the United States. By accepting delivery of the Program
or Documentation, the government hereby agrees that this software or documentation qualifies as
commercial computer software or commercial computer software documentation as such terms are used
or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and
conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern
the use, modification, reproduction, release, performance, display, and disclosure of the Program and
Documentation by the federal government (or other entity acquiring for or through the federal government)
and shall supersede any conflicting contractual terms or conditions. If this License fails to meet the
government’s needs or is inconsistent in any respect with federal procurement law, the government agrees
to return the Program and Documentation, unused, to The MathWorks, Inc.
Trademarks
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See
www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand
names may be trademarks or registered trademarks of their respective holders.
Patents
MathWorks products are protected by one or more U.S. patents. Please see
www.mathworks.com/patents for more information.
Revision History
August 2003 Online only New for Version 1 (Release 13SP1)
February 2004 Online only Revised for Version 1.1 (Release 13SP1)
June 2004 Online only Revised for Version 1.1.1 (Release 14)
October 2004 Online only Revised for Version 1.2 (Release 14SP1)
December 2004 Online only Revised for Version 1.3 (Release 14SP1+)
March 2005 Online only Revised for Version 1.3.1 (Release 14SP2)
September 2005 Online only Revised for Version 1.4 (Release 14SP3)
March 2006 Online only Revised for Version 2.0 (Release 2006a)
September 2006 Online only Revised for Version 2.1 (Release 2006b)
October 2008 Online only Revised for Version 2.5 (Release 2008b)
April 2011 Online only Revised for Version 3.3 (Release 2011a)
Contents
HDL Verification with Cosimulation

HDL Cosimulation Using MATLAB Test Bench
Function
1
MATLAB as a Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Create a MATLAB Test Bench ...................... 1-4
Code HDL Modules for Verification Using MATLAB . . 1-5

Overview to Coding HDL Modules for Verification with
MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Choose HDL Module Name for Use with MATLAB Test
Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Specify Port Direction Modes in HDL Module for Use with
Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Specify Port Data Types in HDL Modules for Use with Test
Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Compile and Elaborate HDL Design for Use with Test
Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Sample VHDL Entity Definition . . . . . . . . . . . . . . . . . . . . . 1-10
Code an HDL Verifier Test Bench Function . . . . . . . . . . 1-11

Process for Coding MATLAB HDL Verifier Functions . . . . 1-11
Syntax of a Test Bench Function . . . . . . . . . . . . . . . . . . . . . 1-12
Sample MATLAB Test Bench Function . . . . . . . . . . . . . . . . 1-12
Place Test Bench on MATLAB Search Path . . . . . . . . . . 1-20

Use MATLAB which Function to Find Test Bench . . . . . . . 1-20
Add Test Bench Function to MATLAB Search Path . . . . . . 1-20
Start Server for MATLAB—HDL Simulator

Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Start MATLAB Server for Test Bench Session . . . . . . . . . . 1-21
v
Example of Starting MATLAB Server for Test Bench
Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Start HDL Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

Start the HDL Simulator for Test Bench Session . . . . . . . . 1-23
Load an HDL Design for Verification . . . . . . . . . . . . . . . . . 1-23
Bind Test Bench Function Calls With matlabtb . . . . . . . 1-24

Invoke MATLAB Test Bench Command matlabtb . . . . . . . 1-24
Bind HDL Module Component to MATLAB Test Bench
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Schedule Options for a Test Bench Session . . . . . . . . . . . 1-28

About Scheduling Options for Test Bench Sessions . . . . . . 1-28
Schedule Test Bench Session Using matlabtb
Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Schedule Test Bench Functions With the tnext
Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
Run MATLAB Test Bench Simulation . . . . . . . . . . . . . . . . 1-32

Process for Running MATLAB Test Bench Cosimulation . . 1-32
Check MATLAB Server’s Link Status for Test Bench
Cosimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Run Test Bench Cosimulation . . . . . . . . . . . . . . . . . . . . . . . 1-33
Apply Stimuli to Test Bench Session with force
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37
Restart Test Bench Simulation . . . . . . . . . . . . . . . . . . . . . . 1-39
Stop Test Bench Simulation . . . . . . . . . . . . . . . . . . . . . . . . 1-40
Verify HDL Model with MATLAB Testbench . . . . . . . . . 1-41

Tutorial Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41
Set Up Tutorial Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
Start the MATLAB Server . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
Start ModelSim Simulator and Set Up for Cosimulation . . 1-44
Develop VHDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
Compile VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-48
Develop MATLAB Function . . . . . . . . . . . . . . . . . . . . . . . . . 1-49
Load Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51
Run Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53
Shut Down Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58
vi Contents
Automatic Cosimulation Verification . . . . . . . . . . . . . . . . 1-60
HDL Cosimulation Using MATLAB Component

Function
2
MATLAB Function as a Component . . . . . . . . . . . . . . . . . 2-2
Create a MATLAB Component Function . . . . . . . . . . . . . 2-4
Code HDL Modules for Visualization Using MATLAB . . 2-5

Overview to Coding HDL Modules for Visualization with
MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Choose HDL Module Name for Use with MATLAB
Component Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Specify Port Direction Modes in HDL Module for Use with
Component Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Specify Port Data Types in HDL Modules for Use with
Compile and Elaborate HDL Design for Use with
Create an HDL Verifier MATLAB Component

Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Overview to Coding an HDL Verifier Component
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Syntax of a Component Function . . . . . . . . . . . . . . . . . . . . . 2-11
Place Component Function on MATLAB Search

Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Use MATLAB which Function to Find Component
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Add Component Function to MATLAB Search Path . . . . . 2-12
Start Connection to HDL Simulator . . . . . . . . . . . . . . . . . 2-13

Start MATLAB Server for Component Function Session . . 2-13
Example of Starting MATLAB Server for Component
Function Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
vii
Start HDL Simulator for Component Session . . . . . . . . . . . 2-15
Load HDL Design for Visualization . . . . . . . . . . . . . . . . . . . 2-15
Bind Component Function Calls With matlabcp . . . . . . 2-16

Invoke MATLAB Component Function Command
matlabcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Bind HDL Module Component to MATLAB Component
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Schedule Options for a Component Session . . . . . . . . . . 2-20

About Scheduling Options for Component Sessions . . . . . . 2-20
Schedule Component Session Using matlabcp
Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Schedule Component Functions Using the tnext
Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Run MATLAB Component Function Simulation . . . . . . 2-24

Process for Running MATLAB Component Function
Cosimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Check MATLAB Server’s Link Status for Component
Cosimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Run Component Function Cosimulation . . . . . . . . . . . . . . . 2-25
Apply Stimuli to Component Function with force
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Restart Component Simulation . . . . . . . . . . . . . . . . . . . . . . 2-31
Stop Component Simulation . . . . . . . . . . . . . . . . . . . . . . . . 2-32
HDL Cosimulation Using MATLAB System

Object
3
Create a MATLAB System Object . . . . . . . . . . . . . . . . . . . . 3-2
Verify Viterbi Decoder Using MATLAB System Object

and Mentor Graphics ModelSim . . . . . . . . . . . . . . . . . . 3-3
viii Contents
Simulink Test Bench for HDL Component
4
Simulink as a Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Communications During Test Bench Cosimulation . . . . . . 4-2
HDL Cosimulation Block Features for Test Bench
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Simulink Test Bench Cosimulation . . . . . . . . . . . . . . . . . . 4-7
Create Simulink Model for Test Bench Cosimulation . . 4-8

Create Simulink Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Run Test Bench Hardware Model in Simulink . . . . . . . . . . 4-8
Add Value Change Dump (VCD) File (Optional) . . . . . . . . . 4-8
Code an HDL Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9

Overview to Coding HDL Components for Simulink Test
Bench Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Specify Port Direction Modes in the HDL Component for
Test Bench Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Specify Port Data Types in the HDL Component for Test
Bench Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Compile and Elaborate HDL Design for Test Bench Use . . 4-11

Start HDL Simulator from MATLAB . . . . . . . . . . . . . . . . . 4-12
Load Instance of HDL Module for Test Bench
Cosimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Add HDL Cosimulation Block to Model . . . . . . . . . . . . . . 4-14

Insert HDL Cosimulation Block . . . . . . . . . . . . . . . . . . . . . . 4-14
Connect Block Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Define HDL Cosimulation Block Interface . . . . . . . . . . . 4-16

Open HDL Cosimulation Block Interface . . . . . . . . . . . . . . 4-16
Map HDL Signals to Block Ports . . . . . . . . . . . . . . . . . . . . . 4-17
Specify Signal Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
Configure Simulink and HDL Simulator Timing
Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
ix
Configure Communication Link in the HDL Cosimulation
Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Specify Pre- and Post-Simulation Tcl Commands with HDL
Cosimulation Block Parameters Dialog Box . . . . . . . . . . 4-38
Programmatically Control Block Parameters . . . . . . . . . . . 4-41
Run a Test Bench Cosimulation Session . . . . . . . . . . . . . 4-44

Set Simulink Model Configuration Parameters . . . . . . . . . 4-44
Determine Available Socket Port Number . . . . . . . . . . . . . 4-46
Check Connection Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46
Run and Test Test Bench Cosimulation Model . . . . . . . . . . 4-46
Avoid Race Conditions in HDL Simulation with Test Bench
Cosimulation and the HDL Verifier HDL Cosimulation
Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
Verify HDL Model with Simulink Test Bench . . . . . . . . . 4-51

Tutorial Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51
Develop VHDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
Compile VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53
Create Simulink Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55
Set Up ModelSim for Use with Simulink . . . . . . . . . . . . . . . 4-63
Load Instances of VHDL Entity for Cosimulation with
Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-64
Run Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-66
Shut Down Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-69
Test Bench Automatic Verification with Simulink . . . . 4-70
Replace HDL Component with Simulink

Algorithm
5
Component Simulation with Simulink . . . . . . . . . . . . . . . 5-2
How the HDL Simulator and Simulink Software
Communicate Using HDL Verifier For Component
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
HDL Cosimulation Block Features for Component
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
x Contents
Replace HDL Component with Simulink Algorithm . . . 5-6
Code an HDL Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

Overview to Coding HDL Modules for Simulink Component
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Specify Port Direction Modes in HDL Module for Component
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Specify Port Data Types in HDL Module for Component
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Compile and Elaborate HDL Design for Component
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Create Simulink Model for Component Cosimulation . . 5-10

Simulink Model for Component Cosimulation . . . . . . . . . . 5-10
Run and Test Component Hardware Model in Simulink . . 5-10
Add Value Change Dump (VCD) File to Component Model
(Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10

Start HDL Simulator from MATLAB . . . . . . . . . . . . . . . . . 5-11
Load Instance of HDL Module for Component
Cosimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Add HDL Cosimulation Block to Model . . . . . . . . . . . . . . 5-13

Insert HDL Cosimulation Block . . . . . . . . . . . . . . . . . . . . . . 5-13
Connect Block Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Define HDL Cosimulation Block Interface . . . . . . . . . . . 5-15

Open HDL Cosimulation Block Interface . . . . . . . . . . . . . . 5-15
Map HDL Signals to Block Ports . . . . . . . . . . . . . . . . . . . . . 5-16
Specify Signal Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
Configure Communication Link in the HDL Cosimulation
Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Specify Pre- and Post-Simulation Tcl Commands with HDL
Cosimulation Block Parameters Dialog Box . . . . . . . . . . 5-37
Programmatically Control Block Parameters . . . . . . . . . . . 5-40
Run a Component Cosimulation Session . . . . . . . . . . . . . 5-43

Simulink Software Configuration Parameters . . . . . . . . . . 5-43
xi
Determine Available Socket Port Number . . . . . . . . . . . . . 5-45
Check Connection Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45
Run and Test Component Cosimulation Model . . . . . . . . . . 5-45
Avoid Race Conditions in HDL Simulation with Component
Cosimulation and the HDL Verifier HDL Cosimulation
Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
Record Simulink Signal State Transitions for

Post-Processing
6
Add a Value Change Dump (VCD) File . . . . . . . . . . . . . . . 6-2
Introduction to the To VCD File Block . . . . . . . . . . . . . . . . 6-2
Using the To VCD File Block . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Visually Compare Simulink Signals with HDL

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Tutorial: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Tutorial: Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
HDL Code Import for Cosimulation

7
Import HDL Code With the HDL Cosimulation
Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
HDL Code Import Features . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
HDL Code Import Workflows . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Cosimulation Wizard Navigation . . . . . . . . . . . . . . . . . . . . . 7-4
Cosimulation Wizard Limitations . . . . . . . . . . . . . . . . . . . . 7-4
Invoking the Cosimulation Wizard . . . . . . . . . . . . . . . . . . 7-5
Import HDL Code for MATLAB Function . . . . . . . . . . . . 7-6

Cosimulation Type—MATLAB Function . . . . . . . . . . . . . . . 7-6
HDL Files—MATLAB Function . . . . . . . . . . . . . . . . . . . . . . 7-8
xii Contents
HDL Compilation—MATLAB Function . . . . . . . . . . . . . . . . 7-10
HDL Modules—MATLAB Function . . . . . . . . . . . . . . . . . . . 7-12
Callback Schedule—MATLAB Function . . . . . . . . . . . . . . . 7-14
Script Generation—MATLAB Function . . . . . . . . . . . . . . . 7-16
Complete the Component or Test Bench Function . . . . . . . 7-17
Import HDL Code for MATLAB System Object . . . . . . . . 7-20

Cosimulation Type—MATLAB System Object . . . . . . . . . . 7-20
HDL Files—MATLAB System Object . . . . . . . . . . . . . . . . . 7-23
HDL Compilation—MATLAB System Object . . . . . . . . . . . 7-25
Simulation Options—MATLAB System Object . . . . . . . . . . 7-26
Input/Output Ports—MATLAB System Objects . . . . . . . . . 7-28
Output Port Details—MATLAB System Object . . . . . . . . . 7-29
Clock/Reset Details—MATLAB System Object . . . . . . . . . . 7-30
Start Time Alignment—MATLAB System Object . . . . . . . 7-31
System Object Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33
Write System Object Test Bench . . . . . . . . . . . . . . . . . . . . . 7-34
Run Cosimulation and Verify HDL Design . . . . . . . . . . . . . 7-36
Import HDL Code for HDL Cosimulation Block . . . . . . . 7-37

Cosimulation Type—Simulink Block . . . . . . . . . . . . . . . . . . 7-37
HDL Files—Simulink Block . . . . . . . . . . . . . . . . . . . . . . . . . 7-39
HDL Compilation—Simulink Block . . . . . . . . . . . . . . . . . . . 7-41
Simulation Options—Simulink Block . . . . . . . . . . . . . . . . . 7-43
Input/Output Ports—Simulink Block . . . . . . . . . . . . . . . . . 7-45
Output Port Details—Simulink Block . . . . . . . . . . . . . . . . . 7-46
Clock/Reset Details—Simulink Block . . . . . . . . . . . . . . . . . 7-48
Start Time Alignment—Simulink Block . . . . . . . . . . . . . . . 7-49
Generate Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-51
Complete Simulink Model . . . . . . . . . . . . . . . . . . . . . . . . . . 7-52
Performing Cosimulation .......................... 7-53
HDL Cosimulation Wizard Tutorials . . . . . . . . . . . . . . . . . 7-55

Cosimulation Wizard for MATLAB System Object . . . . . . . 7-55
Verify Raised Cosine Filter Design Using MATLAB . . . . . 7-61
Verify Raised Cosine Filter Design Using Simulink . . . . . . 7-77
Help Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-98

Cosimulation Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-98
HDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-100
HDL Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-102
xiii
HDL Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-103
HDL Cosimulation Reference

8
Startup for HDL Cosimulation . . . . . . . . . . . . . . . . . . . . . . 8-2
Machine Configuration Requirements . . . . . . . . . . . . . . . . . 8-2
HDL Simulator Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
HDL Verifier Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Setup Diagnostics and Customization . . . . . . . . . . . . . . . . . 8-18
Cross-Network Cosimulation . . . . . . . . . . . . . . . . . . . . . . . . 8-27
Test Bench and Component Function Options . . . . . . . . 8-35

Writing Functions Using the HDL Instance Object . . . . . . 8-35
Writing Functions Using Port Information . . . . . . . . . . . . . 8-40
Direct Feedthrough Cosimulation . . . . . . . . . . . . . . . . . . . 8-46

Applying Direct Feedthrough to Eliminate Block Simulation
Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46
Simulation Speed Improvement Tips . . . . . . . . . . . . . . . . 8-51

Obtaining Baseline Performance Numbers . . . . . . . . . . . . . 8-51
Analyzing Simulation Performance . . . . . . . . . . . . . . . . . . . 8-51
Cosimulating Frame-Based Signals with Simulink . . . . . . 8-53
Race Conditions in HDL Simulators . . . . . . . . . . . . . . . . . 8-62

Avoiding Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-62
Potential Race Conditions in Simulink Cosimulation
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-62
Potential Race Conditions in MATLAB Cosimulation
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-64
Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-64
Data Type Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-65

Converting HDL Data to Send to MATLAB . . . . . . . . . . . . 8-65
Array Indexing Differences Between MATLAB and
HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-68
Converting Data for Manipulation . . . . . . . . . . . . . . . . . . . . 8-69
xiv Contents
Converting Data for Return to the HDL Simulator . . . . . . 8-70
Simulation Timescales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-74

Overview to the Representation of Simulation Time . . . . . 8-74
Defining the Simulink and HDL Simulator Timing
Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-75
Setting the Timing Mode with HDL Verifier . . . . . . . . . . . . 8-76
Relative Timing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-77
Absolute Timing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-82
Timing Mode Usage Considerations . . . . . . . . . . . . . . . . . . 8-84
Setting HDL Cosimulation Block Port Sample Times . . . . 8-86
Clock, Reset, and Enable Signals . . . . . . . . . . . . . . . . . . . . 8-88

Driving Clocks, Resets, and Enables . . . . . . . . . . . . . . . . . . 8-88
Adding Signals Using Simulink Blocks . . . . . . . . . . . . . . . . 8-88
Creating Optional Clocks with the Clocks Pane of the HDL
Cosimulation Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-89
Driving Signals by Adding Force Commands . . . . . . . . . . . 8-92
TCP/IP Socket Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-95
System Objects
9
Create System Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Create a System object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Change a System object Property . . . . . . . . . . . . . . . . . . . . 9-3
Check if a System object Property Has Changed . . . . . . . . 9-3
Run a System object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Display Available System Objects . . . . . . . . . . . . . . . . . . . . 9-3
Set Up System Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

Create a New System object . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
Retrieve System object Property Values . . . . . . . . . . . . . . . 9-4
Set System object Property Values . . . . . . . . . . . . . . . . . . . 9-4
Process Data Using System Objects . . . . . . . . . . . . . . . . . 9-7

What are System object Methods? . . . . . . . . . . . . . . . . . . . . 9-7
xv
The Step Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Common Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Advantages of Using Methods . . . . . . . . . . . . . . . . . . . . . . . 9-9
Tuning System object Properties in MATLAB . . . . . . . . 9-10

Understand System object Modes . . . . . . . . . . . . . . . . . . . . 9-10
Change Properties While Running System Objects . . . . . . 9-11
Change System object Input Complexity or Dimensions . . 9-11
Find Help and Examples for System Objects . . . . . . . . . 9-12
FPGA-in-the-Loop
About FPGA-in-the-Loop (FIL) Simulation
10
FPGA-in-the-Loop (FIL) Simulation . . . . . . . . . . . . . . . . . 10-2
What is FPGA-in-the-Loop Simulation? . . . . . . . . . . . . . . . 10-2
What You Need To Know . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
FIL Preparation
11
FPGA-in-the-Loop Simulation Workflows . . . . . . . . . . . . 11-2
Prepare DUT For FIL Interface Generation . . . . . . . . . . 11-4

Prepare Files and Information Required for FIL Interface
Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Apply FIL System Object Requirements . . . . . . . . . . . . . . . 11-5
Apply FIL Block Requirements . . . . . . . . . . . . . . . . . . . . . . 11-10
Set Up Hardware and Hardware Tools . . . . . . . . . . . . . . . 11-18

Step 1. Set Up FPGA Development Board . . . . . . . . . . . . . 11-18
Step 2. Set Up Board Connection . . . . . . . . . . . . . . . . . . . . . 11-18
Step 3. Set Up FPGA Design Software Tools . . . . . . . . . . . 11-24
xvi Contents
FPGA Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25
FIL Interface Generation and Simulation

12
FIL Interface Generation with the FIL Wizard . . . . . . . 12-2
FIL Block Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
FIL System Object Generation . . . . . . . . . . . . . . . . . . . . . . . 12-12
Perform FPGA-in-the-Loop Simulation . . . . . . . . . . . . . . 12-27

FIL Block Setup and Simulation . . . . . . . . . . . . . . . . . . . . . 12-27
FIL System Object Setup and Simulation . . . . . . . . . . . . . . 12-30
FIL Using HDL Coder HDL Workflow Advisor

13
FIL with HDL Workflow Advisor In Simulink . . . . . . . . 13-2
Step 1: Start HDL Workflow Advisor . . . . . . . . . . . . . . . . . 13-2
Step 2: Set Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Step 3: Prepare Model for HDL Code Generation . . . . . . . . 13-3
Step 4: HDL Code Generation . . . . . . . . . . . . . . . . . . . . . . . 13-4
Step 5: Set FPGA-in-the-Loop Options . . . . . . . . . . . . . . . . 13-4
Step 6: Build and Run FPGA-in-the-Loop . . . . . . . . . . . . . . 13-7
FIL with HDL Workflow Advisor In MATLAB . . . . . . . . 13-9

Step 1: Start HDL Workflow Advisor . . . . . . . . . . . . . . . . . 13-9
Step 2: Select Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Step 3: Select Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Step 4: Select FPGA-in-the-Loop Options . . . . . . . . . . . . . . 13-9
Step 5: Build and Run FPGA-in-the-Loop . . . . . . . . . . . . . . 13-13
xvii
Troubleshooting FPGA-in-the-Loop
14
Troubleshooting FIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
FIL Examples
15
Verify HDL Implementation of PID Controller Using
FPGA-in-the-Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Verify Digital Up-Converter Using

FPGA-in-the-Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-12
HDL Verifier FPGA Board Support Packages

16
FPGA Board Support Packages for FIL . . . . . . . . . . . . . . 16-2
Support Package for BEEcube miniBEE Hardware

Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3
BEEcube miniBEE Hardware Platform for FIL . . . . . . . . . 16-3
miniBEE Hardware Platform and the FIL Wizard . . . . . . . 16-3
miniBEE and the FIL Block Mask . . . . . . . . . . . . . . . . . . . . 16-4
Open Examples for This Support Package . . . . . . . . . . . 16-6

Using the Help Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Using Support Package Installer . . . . . . . . . . . . . . . . . . . . . 16-8
Install This Support Package on Other Computers . . . 16-10
Support Packages and Support Package Installer . . . . 16-12

What Is a Support Package? . . . . . . . . . . . . . . . . . . . . . . . . . 16-12
xviii Contents
What Is Support Package Installer? . . . . . . . . . . . . . . . . . . 16-12
FPGA Board Customization

17
FPGA Board Customization . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Custom Board Management . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
FPGA Board Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17-3
Create Custom FPGA Board Definition . . . . . . . . . . . . . . 17-8
Create Xilinx KC705 Evaluation Board Definition

File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9
What You Need to Know Before Starting . . . . . . . . . . . . . . 17-9
Start New FPGA Board Wizard . . . . . . . . . . . . . . . . . . . . . . 17-10
Provide Basic Board Information . . . . . . . . . . . . . . . . . . . . . 17-11
Specify FPGA Interface Information . . . . . . . . . . . . . . . . . . 17-13
Enter FPGA Pin Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14
Run Optional Validation Tests . . . . . . . . . . . . . . . . . . . . . . . 17-16
Save Board Definition File . . . . . . . . . . . . . . . . . . . . . . . . . . 17-18
Use New FPGA Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-19
FPGA Board Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-23

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-23
Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
FIL Enabled/Turnkey Enabled . . . . . . . . . . . . . . . . . . . . . . . 17-25
Create Custom Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
Add Board From File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
Get More Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
View/Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-26
Remove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-26
Clone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-26
Validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-26
New FPGA Board Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-27

Basic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-29
xix
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-30
FIL I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-32
Turnkey I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-34
Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-37
Finish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-38
FPGA Board Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-39

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-39
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-41
SystemC TLM 2.0 Generation

How TLM Component Generation Works
18
TLM Generation Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 18-2
The TLM Generation Process . . . . . . . . . . . . . . . . . . . . . . . 18-4
Generated TLM Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-7
TLM Component Architecture

19
TLM Component Architecture . . . . . . . . . . . . . . . . . . . . . . 19-2
Overview of Component Features . . . . . . . . . . . . . . . . . . . . 19-2
Single or Multiple Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . 19-5
Memory Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-5
Command and Status Register . . . . . . . . . . . . . . . . . . . . . . . 19-11
Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-19
Test and Set Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-19
Tunable Parameter Registers . . . . . . . . . . . . . . . . . . . . . . . . 19-19
Algorithm Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-19
Register and Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-20
Temporal Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-22
xx Contents
TLM Component Timing Values . . . . . . . . . . . . . . . . . . . . . 19-27
TLM Component Naming and Packaging . . . . . . . . . . . . . . 19-28
Getting Started with TLM Component

Generation
20
Getting Started with TLM Generator . . . . . . . . . . . . . . . . 20-2
Generate TLM Component

21
TLM Component Generation Overview . . . . . . . . . . . . . . 21-2
TLM Component Generation Workflow . . . . . . . . . . . . . . . . 21-2
Subsystem Guidelines and Limitations . . . . . . . . . . . . . . . . 21-2
Select TLM Generator System Target . . . . . . . . . . . . . . . . 21-4
Select TLM Mapping Options . . . . . . . . . . . . . . . . . . . . . . . 21-6
Select TLM Processing Options . . . . . . . . . . . . . . . . . . . . . 21-10
Select TLM Timing Options . . . . . . . . . . . . . . . . . . . . . . . . . 21-11
Select TLM Testbench Options . . . . . . . . . . . . . . . . . . . . . . 21-13
Select TLM Compilation Options . . . . . . . . . . . . . . . . . . . . 21-15
Generate Component and Test Bench . . . . . . . . . . . . . . . 21-16
xxi
Run TLM Component Test Bench
22
Testing TLM Components . . . . . . . . . . . . . . . . . . . . . . . . . . 22-2
TLM Component Test Bench Overview . . . . . . . . . . . . . . . . 22-2
TLM Component Compilation . . . . . . . . . . . . . . . . . . . . . . . 22-2
Automatic Verification of the Generated Component . . . . . 22-3
Report Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-3
Working with Configurations . . . . . . . . . . . . . . . . . . . . . . . . 22-3
Considerations When Creating a TLM Component Test
Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-4
TLM Component Test Bench Generation Options . . . . . 22-6

Verbose Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-6
Run-Time Timing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-6
Input and Output Buffer Triggering Modes . . . . . . . . . . . . 22-6
Run TLM Component Test Bench . . . . . . . . . . . . . . . . . . . 22-8
Export TLM Component to SystemC

Environment
23
TLM Component Compiler Options . . . . . . . . . . . . . . . . . . 23-2
About the TLM Component Compiler Options . . . . . . . . . . 23-2
SystemC Include Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2
SystemC Library Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2
SystemC Library Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-3
TLM Include Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-3
Export TLM Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-4

Identify Generated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-4
Create Static Library with TLM Component . . . . . . . . . . . 23-6
Create Standalone Executable with TLM Component . . . . 23-8
TLM Component Constructor and Default

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-10
xxii Contents
Configuration Parameters for TLM Generator
Target
24
TLM Component Generation . . . . . . . . . . . . . . . . . . . . . . . 24-2
TLM Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-2
TLM Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-9
TLM Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-17
TLM Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-21
TLM Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-26
SystemVerilog DPI Component Generation

25
SystemVerilog DPI Component Generation . . . . . . . . . . 25-2
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-2
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-3
Generated Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-4
Generated SystemVerilog Wrapper . . . . . . . . . . . . . . . . . . . 25-4
Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-7
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-8
Generate SystemVerilog DPI Component and Test

Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-9
Set Up Model for Code Generation . . . . . . . . . . . . . . . . . . . . 25-9
Generate SystemVerilog DPI Component . . . . . . . . . . . . . . 25-11
Build Shared Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-12
Run Generated Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . . 25-13
Customize Generated SystemVerilog Code . . . . . . . . . . . 25-14

Set Up Model for Customized Code Generation . . . . . . . . . 25-14
Generate Customized SystemVerilog DPI Component . . . . 25-18
Build Shared Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-18
Export SystemVerilog DPI Component to SystemVerilog

Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-20
xxiii
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-20
Tune Gain Parameter During Simulation . . . . . . . . . . . . 25-21

Example Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-21
Create a Simple Gain Model . . . . . . . . . . . . . . . . . . . . . . . . . 25-21
Create Data Object for Gain Parameter . . . . . . . . . . . . . . . 25-22
Generate SystemVerilog DPI Component . . . . . . . . . . . . . . 25-24
Add Parameter Tuning Code to SystemVerilog File . . . . . . 25-25
Run Simulation With Parameter Change . . . . . . . . . . . . . . 25-26
Context-Sensitive Help for Generated

SystemVerilog DPI Component
26
SystemVerilog DPI Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-2
SystemVerilog DPI Overview . . . . . . . . . . . . . . . . . . . . . . . . 26-3
Customize SystemVerilog generated code . . . . . . . . . . . . . . 26-4
Source file template: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-5
Generate test bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-6
xxiv Contents
HDL Verification with
Cosimulation
• Chapter 1, “HDL Cosimulation Using MATLAB Test Bench Function”

• Chapter 2, “HDL Cosimulation Using MATLAB Component
Function”
• Chapter 3, “HDL Cosimulation Using MATLAB System Object”
• Chapter 4, “Simulink Test Bench for HDL Component”
• Chapter 5, “Replace HDL Component with Simulink Algorithm”
• Chapter 6, “Record Simulink Signal State Transitions for
Post-Processing”
• Chapter 7, “HDL Code Import for Cosimulation”
• Chapter 8, “HDL Cosimulation Reference”
• Chapter 9, “System Objects”
1
HDL Cosimulation Using

MATLAB Test Bench
Function
• “MATLAB as a Test Bench” on page 1-2

• “Create a MATLAB Test Bench” on page 1-4
• “Code HDL Modules for Verification Using MATLAB ” on page 1-5
• “Code an HDL Verifier Test Bench Function” on page 1-11
• “Place Test Bench on MATLAB Search Path” on page 1-20
• “Start Server for MATLAB—HDL Simulator Connection” on page 1-21
• “Start HDL Simulator” on page 1-23
• “Bind Test Bench Function Calls With matlabtb” on page 1-24
• “Schedule Options for a Test Bench Session” on page 1-28
• “Run MATLAB Test Bench Simulation” on page 1-32
• “Stop Test Bench Simulation” on page 1-40
• “Verify HDL Model with MATLAB Testbench” on page 1-41
• “Automatic Cosimulation Verification” on page 1-60
1 HDL Cosimulation Using MATLAB Test Bench Function
MATLAB as a Test Bench

The HDL Verifier™ software provides a means for verifying HDL modules
within the MATLAB® environment. You do so by coding an HDL model and
a MATLAB function that can share data with the HDL model. This chapter
discusses the programming, interfacing, and scheduling conventions for
MATLAB test bench functions that communicate with the HDL simulator.
MATLAB test bench functions let you verify the performance of the HDL
model, or of components within the model. A test bench function drives
values onto signals connected to input ports of an HDL design under test and
receives signal values from the output ports of the module.
The following figure shows how a MATLAB function wraps around and
communicates with the HDL simulator during a test bench simulation session.
MATLAB
MATLAB test bench M-Function
Stimulus Response
HDL Simulator
HDL Entity
Output Input
Arguments IN OUT Arguments
When linked with MATLAB, the HDL simulator functions as the client, with
MATLAB as the server. The following figure shows a multiple-client scenario
connecting to the server at TCP/IP socket port 4449.
1-2
MATLAB as a Test Bench
MATLAB
HDL Simulator Link Server
Port
Client 4449
HDL Simulator Link

Client
The MATLAB server can service multiple simultaneous HDL simulator

sessions and HDL modules. However, you should follow recommended
guidelines to help the server track the I/O associated with each module and
session. The MATLAB server, which you start with the supplied MATLAB
function hdldaemon, waits for connection requests from instances of the HDL
simulator running on the same or different computers. When the server
receives a request, it executes the specified MATLAB function you have coded
to perform tasks on behalf of a module in your HDL design. Parameters that
you specify when you start the server indicate whether the server establishes
shared memory or TCP/IP socket communication links.
Refer to “Machine Configuration Requirements” on page 8-2 for valid machine

configurations.
Note The programming, interfacing, and scheduling conventions for test

bench functions and component functions are virtually identical. For the most
part, the same procedures apply to both types of functions.
1-3
Create a MATLAB Test Bench

The following workflow steps describe how to create a MATLAB test bench
session for cosimulation with the HDL simulator using HDL Verifier.
1 “Code HDL Modules for Verification Using MATLAB ” on page 1-5
2 “Code an HDL Verifier Test Bench Function” on page 1-11
3 “Place Test Bench on MATLAB Search Path” on page 1-20
4 “Start Server for MATLAB—HDL Simulator Connection” on page 1-21
5 “Start HDL Simulator” on page 1-23
6 “Bind Test Bench Function Calls With matlabtb” on page 1-24
7 “Schedule Options for a Test Bench Session” on page 1-28
8 Set breakpoints for interactive HDL debug (optional).
9 “Run MATLAB Test Bench Simulation” on page 1-32
10 “Stop Test Bench Simulation” on page 1-40
1-4
Code HDL Modules for Verification Using MATLAB

In this section...
“Overview to Coding HDL Modules for Verification with MATLAB” on
page 1-5
“Choose HDL Module Name for Use with MATLAB Test Bench” on page 1-6
“Specify Port Direction Modes in HDL Module for Use with Test Bench”
on page 1-6
“Specify Port Data Types in HDL Modules for Use with Test Bench” on
page 1-6
“Compile and Elaborate HDL Design for Use with Test Bench” on page 1-8
“Sample VHDL Entity Definition” on page 1-10
Overview to Coding HDL Modules for Verification

with MATLAB
The most basic element of communication in the HDL Verifier interface is the
HDL module. The interface passes all data between the HDL simulator and
MATLAB as port data. The HDL Verifier software works with any existing
HDL module. However, when you code an HDL module that is targeted for
MATLAB verification, you should consider its name, the types of data to be
shared between the two environments, and the direction modes. The sections
within this chapter cover these topics.
The process for coding HDL modules for MATLAB verification is as follows:
• “Choose HDL Module Name for Use with MATLAB Test Bench” on page 1-6
• “Specify Port Direction Modes in HDL Module for Use with Test Bench”
on page 1-6
• “Specify Port Data Types in HDL Modules for Use with Test Bench” on
page 1-6
• “Compile and Elaborate HDL Design for Use with Test Bench” on page 1-8
1-5
Choose HDL Module Name for Use with MATLAB Test

Bench
Although not required, when naming the HDL module, consider choosing a
name that also can be used as a MATLAB function name. (Generally, naming
rules for VHDL or Verilog and MATLAB are compatible.) By default, HDL
Verifier software assumes that an HDL module and its simulation function
share the same name. See “Bind Test Bench Function Calls With matlabtb”
on page 1-24.
For details on MATLAB function-naming guidelines, see “MATLAB

Programming Tips” on files and file names in the MATLAB documentation.
Specify Port Direction Modes in HDL Module for Use

with Test Bench
In your module statement, you must specify each port with a direction mode
(input, output, or bidirectional). The following table defines these three modes.
Use VHDL Use Verilog For Ports That...

Mode... Mode...
IN input Represent signals that can be driven by a
MATLAB function
OUT output Represent signal values that are passed to
a MATLAB function
INOUT inout Represent bidirectional signals that can
be driven by or pass values to a MATLAB
function

Test Bench
This section describes how to specify data types compatible with MATLAB
for ports in your HDL modules. For details on how the HDL Verifier
interface converts data types for the MATLAB environment, see “Data Type
Conversions” on page 8-65.
1-6
Note If you use unsupported types, the HDL Verifier software issues a
warning and ignores the port at run time. For example, if you define your
interface with five ports, one of which is a VHDL access port, at run time,
then the interface displays a warning and your code sees only four ports.
Port Data Types for VHDL Entities

In your entity statement, you must define each port that you plan to test
with MATLAB with a VHDL data type that is supported by the HDL Verifier
software. The interface can convert scalar and array data of the following
VHDL types to comparable MATLAB types:
• STD_LOGIC, STD_ULOGIC, BIT, STD_LOGIC_VECTOR, STD_ULOGIC_VECTOR,

and BIT_VECTOR
• INTEGER and NATURAL
• REAL
• TIME
• Enumerated types, including user-defined enumerated types and
CHARACTER
The interface also supports all subtypes and arrays of the preceding types.
Note The HDL Verifier software does not support VHDL extended identifiers
for the following components:
• Port and signal names used in cosimulation

• Enum literals when used as array indices of port and signal names used
in cosimulation
However, the software does support basic identifiers for VHDL.
1-7
Port Data Types for Verilog Modules

In your module definition, you must define each port that you plan to test
with MATLAB with a Verilog port data type that is supported by the HDL
Verifier software. The interface can convert data of the following Verilog port
types to comparable MATLAB types:
• reg
• integer
• wire
Note HDL Verifier software does not support Verilog escaped identifiers for
port and signal names used in cosimulation. However, it does support simple
identifiers for Verilog.
Compile and Elaborate HDL Design for Use with Test

Bench
After you create or edit your HDL source files, use the HDL simulator
compiler to compile and debug the code.
Compilation for ModelSim
You have the option of invoking the compiler from menus in the ModelSim
graphic interface or from the command line with the vcom command. The
following sequence of ModelSim commands creates and maps the design
library work and compiles the VHDL file modsimrand.vhd:
ModelSim> vlib work

ModelSim> vmap work work
ModelSim> vcom modsimrand.vhd
The following sequence of ModelSim commands creates and maps the design
library work and compiles the Verilog file test.v:
ModelSim> vlib work

ModelSim> vlog test.v
1-8
Note You should provide read/write access to the signals that are connecting
to the MATLAB session for cosimulation. For higher performance, you
want to provide access only to those signals used in cosimulation. You can
check read/write access through the HDL simulator—see HDL simulator
documentation for details.
Compilation for Incisive
The Cadence Incisive simulator allows for 1-step and 3-step processes for HDL
compilation, elaboration, and simulation. The following Cadence Incisive
simulator command compiles the Verilog file test.v:
sh> ncvlog test.v
The following Cadence Incisive simulator command compiles and elaborates

the Verilog design test.v, and then loads it for simulation, in a single step:
sh> ncverilog +gui +access+rwc +linedebug test.v
The following sequence of Cadence Incisive simulator commands performs all

the same processes in multiple steps:
sh> ncvlog -linedebug test.v

sh> ncelab -access +rwc test
sh> ncsim test
to the MATLAB session for cosimulation. The previous example shows
how to provide read/write access to all signals in your design. For higher
performance, you want to provide access only to those signals used in
cosimulation. See the description of the +access flag to ncverilog and the
-access argument to ncelab for details.
For more examples, see the HDL Verifier tutorials and demos. For details on
using the HDL compiler, see the simulator documentation.
1-9
Sample VHDL Entity Definition

This sample VHDL code fragment defines the entity decoder. By default, the
entity is associated with MATLAB test bench function decoder.
The keyword PORT marks the start of the entity’s port clause, which defines
two IN ports—isum and qsum—and three OUT ports—adj, dvalid, and odata.
The output ports drive signals to MATLAB function input ports for processing.
The input ports receive signals from the MATLAB function output ports.
Both input ports are defined as vectors consisting of five standard logic values.
The output port adj is also defined as a standard logic vector, but consists
of only two values. The output ports dvalid and odata are defined as scalar
standard logic ports. For information on how the HDL Verifier interface
converts data of standard logic scalar and array types for use in the MATLAB
environment, see “Data Type Conversions” on page 8-65.
ENTITY decoder IS
PORT (
isum : IN std_logic_vector(4 DOWNTO 0);
qsum : IN std_logic_vector(4 DOWNTO 0);
adj : OUT std_logic_vector(1 DOWNTO 0);
dvalid : OUT std_logic;
odata : OUT std_logic);
END decoder ;
1-10
Code an HDL Verifier™ Test Bench Function
Code an HDL Verifier Test Bench Function

In this section...
“Process for Coding MATLAB HDL Verifier Functions” on page 1-11
“Syntax of a Test Bench Function” on page 1-12
“Sample MATLAB Test Bench Function” on page 1-12
Process for Coding MATLAB HDL Verifier Functions

Coding a MATLAB function that is to verify an HDL module or component
requires that you follow specific coding conventions. You must also
understand the data type conversions that occur, and program data type
conversions for operating on data and returning data to the HDL simulator.
To code a MATLAB function that is to verify an HDL module or component,

perform the following steps:
1 Learn the syntax for a MATLAB HDL Verifier test bench function (see
“Syntax of a Test Bench Function” on page 1-12).
2 Understand how HDL Verifier software converts data from the HDL
simulator for use in the MATLAB environment (see “Data Type
Conversions” on page 8-65).
3 Choose a name for the MATLAB function (see “Bind HDL Module
Component to MATLAB Test Bench Function” on page 1-26).
4 Define expected parameters in the function definition line (see “MATLAB

Function Syntax and Function Argument Definitions” on page 8-40).
5 Determine the types of port data being passed into the function (see
“MATLAB Function Syntax and Function Argument Definitions” on page
8-40).
6 Extract and, if applicable to the simulation, apply information received

in the portinfo structure (see “Gaining Access to and Applying Port
Information” on page 8-44).
1-11
7 Convert data for manipulation in the MATLAB environment, as applicable

(see “Converting HDL Data to Send to MATLAB” on page 8-65 ).
8 Convert data that needs to be returned to the HDL simulator (see

“Converting Data for Return to the HDL Simulator” on page 8-70).
Syntax of a Test Bench Function

The syntax of a MATLAB test bench function is
function [iport, tnext] = MyFunctionName(oport, tnow, portinfo)
See the “MATLAB Function Syntax and Function Argument Definitions” on

page 8-40 for an explanation of each of the function arguments.
Sample MATLAB Test Bench Function

This section uses a sample MATLAB function to identify sections of a
MATLAB test bench function required by the HDL Verifier software. You
can see the full text of the code used in this sample in the section “MATLAB
Function Example: manchester_decoder.m” on page 1-17.
For ModelSim Users This example uses a VHDL entity and MATLAB
function code drawn from the decoder portion of the Manchester Receiver
example. For the complete VHDL and function code listings, see the following
files:
matlabroot\toolbox\edalink\extensions\modelsim\modelsimdemos\vhdl\manchester\decoder.vhd
matlabroot\toolbox\edalink\extensions\modelsim\modelsimdemos\manchester_decoder.m
As the first step to coding a MATLAB test bench function, you must
understand how the data modeled in the VHDL entity maps to data in the
MATLAB environment. The VHDL entity decoder is defined as follows:
ENTITY decoder IS
PORT (
isum : IN std_logic_vector(4 DOWNTO 0);
qsum : IN std_logic_vector(4 DOWNTO 0);
1-12
adj : OUT std_logic_vector(1 DOWNTO 0);

dvalid : OUT std_logic;
odata : OUT std_logic
);
END decoder ;
The following discussion highlights key lines of code in the definition of the
manchester_decoder MATLAB function:
1 Specify the MATLAB function name and required parameters.
The following code is the function declaration of the manchester_decoder

MATLAB function.
function [iport,tnext] = manchester_decoder(oport,tnow,portinfo)
See “MATLAB Function Syntax and Function Argument Definitions” on

page 8-40.
The function declaration performs the following actions:

• Names the function. This declaration names the function
manchester_decoder, which differs from the entity name decoder.
Because the names differ, the function name must be specified explicitly
later when the entity is initialized for verification with the matlabtb or
matlabtbeval function. See “Bind HDL Module Component to MATLAB
Test Bench Function” on page 1-26.
• Defines required argument and return parameters. A MATLAB test
bench function must return two parameters, iport and tnext, and pass
three arguments, oport, tnow, and portinfo, and must appear in the
order shown. See “MATLAB Function Syntax and Function Argument
Definitions” on page 8-40.
The function outputs must be initialized to empty values, as in the
following code example:
tnext = [];
iport = struct();
You should initialize the function outputs at the beginning of the

function, to follow recommended best practice.
1-13
The following figure shows the relationship between the entity’s ports
and the MATLAB function’s iport and oport parameters.
Input Signals Output Signals
oport.adj (2)
iport.isum (5)
decoder.vhd oport.dvalid(1)
iport.qsum (5)
oport.odata(1)
For more information on the required MATLAB test bench function

parameters, see “MATLAB Function Syntax and Function Argument
2 Make note of the data types of ports defined for the entity being
simulated.
The HDL Verifier software converts HDL data types to comparable

MATLAB data types and vice versa. As you develop your MATLAB
function, you must know the types of the data that it receives from the
HDL simulator and needs to return to the HDL simulator.
The VHDL entity defined for this example consists of the following ports
VHDL Example Port Definitions
Port Direction Type... Converts

to/Requires
Conversion to...
isum IN STD_LOGIC_VECTOR(4 DOWNTO 0) A 5-bit column
or row vector of
characters where
each bit maps to
a standard logic
character literal.
qsum IN STD_LOGIC_VECTOR(4 DOWNTO 0) A 5-bit column
or row vector of
characters where
each bit maps to
a standard logic
character literal.
1-14
VHDL Example Port Definitions (Continued)
Port Direction Type... Converts

to/Requires
Conversion to...
adj OUT STD_LOGIC_VECTOR(1 DOWNTO 0) A 2-element
column vector of
characters. Each
character matches
a corresponding
character literal
that represents
a logic state and
maps to a single
bit.
dvalid OUT STD_LOGIC A character that
matches the
character literal
representing the
logic state.
odata OUT STD_LOGIC A character that
matches the
character literal
representing the
logic state.
For more information on interface data type conversions, see “Data Type
3 Set up any required timing parameters.
The tnext assignment statement sets up timing parameter tnext such

that the simulator calls back the MATLAB function every nanosecond.
tnext = tnow+1e-9;
4 Convert output port data to MATLAB data types for processing.
1-15
The following code excerpt illustrates data type conversion of output port
data.
%% Compute one row and plot

isum = isum + 1;
adj(isum) = mvl2dec(oport.adj');
data(isum) = mvl2dec([oport.dvalid oport.odata]);
.
.
.
The two calls to mvl2dec convert the binary data that the MATLAB
function receives from the entity’s output ports, adj, dvalid, and odata to
unsigned decimal values that MATLAB can compute. The function converts
the 2-bit transposed vector oport.adj to a decimal value in the range 0 to
4 and oport.dvalid and oport.odata to the decimal value 0 or 1.

8-40 provides a summary of the types of data conversions to consider when
coding simulation MATLAB functions.
5 Convert data to be returned to the HDL simulator.
The following code excerpt illustrates data type conversion of data to be

returned to the HDL simulator.
if isum == 17
iport.isum = dec2mvl(isum,5);
iport.qsum = dec2mvl(qsum,5);
else
iport.isum = dec2mvl(isum,5);
end
The three calls to dec2mvl convert the decimal values computed by

MATLAB to binary data that the MATLAB function can deposit to the
entity’s input ports, isum and qsum. In each case, the function converts a
decimal value to 5-element bit vector with each bit representing a character
that maps to a character literal representing a logic state.
1-16
“Converting Data for Return to the HDL Simulator” on page 8-70 provides
a summary of the types of data conversions to consider when returning
data to the HDL simulator.
MATLAB Function Example: manchester_decoder.m

function [iport,tnext] = manchester_decoder(oport,tnow,portinfo)
% MANCHESTER_DECODER Test bench for VHDL 'decoder'
% [IPORT,TNEXT]=MANCHESTER_DECODER(OPORT,TNOW,PORTINFO) -
% Implements a test of the VHDL decoder entity which is part
% of the Manchester receiver demo. This test bench plots
% the IQ mapping produced by the decoder.
%
% iport oport
% +-----------+
% isum -(5)->| |-(2)-> adj
% qsum -(5)->| decoder |-(1)-> dvalid
% | |-(1)-> odata
% +-----------+
%
% isum - Inphase Convolution value
% qsum - Quadrature Convolution value
% adj - Clock adjustment ('01','00','10')
% dvalid - Data validity ('1' = data is valid)
% odata - Recovered data stream
%
% Adjust = 0 (00b), generate full 16 cycle waveform
% Copyright 2003-2009 The MathWorks, Inc.
persistent isum;
persistent qsum;
%persistent ga;
persistent x;
persistent y;
persistent adj;
persistent data;
global testisdone;
% This useful feature allows you to manually
% reset the plot by simply typing: >manchester_decoder
1-17
tnext = [];
iport = struct();
if nargin == 0,
isum = [];
return;
end
if exist('portinfo') == 1
isum = [];
end
tnext = tnow+1e-9;
if isempty(isum), %% First call
scale = 9;
isum = 0;
qsum = 0;
for k=1:2,
ga(k) = subplot(2,1,k);
axis([-1 17 -1 17]);
ylabel('Quadrature');
line([0 16],[8 8],'Color','r','LineStyle',':','LineWidth',1)
line([8 8],[0 16],'Color','r','LineStyle',':','LineWidth',1)
end
xlabel('Inphase');
subplot(2,1,1);
title('Clock Adjustment (adj)');
subplot(2,1,2);
title('Data with Validity');
iport.isum = '00000';
iport.qsum = '00000';
return;
end
% compute one row, then plot

isum = isum + 1;
adj(isum) = bin2dec(oport.adj');
data(isum) = bin2dec([oport.dvalid oport.odata]);
if isum == 17,
1-18
subplot(2,1,1);
for k=0:16,
if adj(k+1) == 0, % Bang on!
line(k,qsum,'color','k','Marker','o');
elseif adj(k+1) == 1, %
line(k,qsum,'color','r','Marker','<');
else
line(k,qsum,'color','b','Marker','>');
end
end
subplot(2,1,2);
for k=0:16,
if data(k+1) < 2, % Invalid
line(k,qsum,'color','r','Marker','X');
else
if data(k+1) == 2, %Valid and 0!
line(k,qsum,'color','g','Marker','o');
else
line(k,qsum,'color','k','Marker','.');
end
end
end
isum = 0;
qsum = qsum + 1;
if qsum == 17,
qsum = 0;
disp('done');
tnext = []; % suspend callbacks
testisdone = 1;
return;
end
iport.isum = dec2bin(isum,5);
iport.qsum = dec2bin(qsum,5);
else
iport.isum = dec2bin(isum,5);
end
1-19
Place Test Bench on MATLAB Search Path

In this section...
“Use MATLAB which Function to Find Test Bench” on page 1-20
“Add Test Bench Function to MATLAB Search Path” on page 1-20
Use MATLAB which Function to Find Test Bench

The MATLAB function that you are associating with an HDL component must
be on the MATLAB search path or reside in the current working folder (see
the MATLAB cd function). To verify whether the function is accessible, use
the MATLAB which function. The following call to which checks whether the
function MyVhdlFunction is on the MATLAB search path, for example:
which MyVhdlFunction
/work/incisive/MySym/MyVhdlFunction.m
If the specified function is on the search path, which displays the complete
path to the function. If the function is not on the search path, which informs
you that the file was not found.
Add Test Bench Function to MATLAB Search Path

To add a MATLAB function to the MATLAB search path, open the Set
Path window by clicking File > Set Path, or use the addpath command.
Alternatively, for temporary access, you can change the MATLAB working
folder to a desired location with the cd command.
1-20
Start Server for MATLAB—HDL Simulator Connection
Start Server for MATLAB—HDL Simulator Connection

In this section...
“Start MATLAB Server for Test Bench Session” on page 1-21
“Example of Starting MATLAB Server for Test Bench Session” on page 1-22
Start MATLAB Server for Test Bench Session

Start the MATLAB server as follows:
1 Start MATLAB.
2 In the MATLAB Command Window, call the hdldaemon function with

property name/property value pairs that specify whether the HDL Verifier
software is to perform the following tasks:
• Use shared memory or TCP/IP socket communication
• Return time values in seconds or as 64-bit integers
See hdldaemon reference documentation for when and how to specify property
name/property value pairs and for more examples of using hdldaemon.
The communication mode that you specify (shared memory or TCP/IP sockets)
must match what you specify for the communication mode when you initialize
the HDL simulator for use with a MATLAB cosimulation session using the
matlabtb or matlabcp function. In addition, if you specify TCP/IP socket
mode, the socket port that you specify with hdldaemon and matlabtb or
matlabcp must match. See “TCP/IP Socket Ports” on page 8-95 for more
information .

modules and clients. However, your code must track the I/O associated with
each entity or client.
1-21
Note You cannot begin an HDL Verifier transaction between MATLAB and
the HDL simulator from MATLAB. The MATLAB server simply responds to
function call requests that it receives from the HDL simulator.
Example of Starting MATLAB Server for Test Bench

Session
The following command specifies using socket communication on port 4449
and a 64-bit time resolution format for the MATLAB function’s output ports.
hdldaemon('socket', 4449, 'time', 'int64')
1-22
Start HDL Simulator
Start HDL Simulator

In this section...
“Start the HDL Simulator for Test Bench Session” on page 1-23
“Load an HDL Design for Verification” on page 1-23
Start the HDL Simulator for Test Bench Session

Start the HDL simulator directly from MATLAB by calling the HDL Verifier
function vsim or nclaunch.
>>vsim
You can call vsim or nclaunch with additional parameters; see the reference
pages for details.
You must make sure the HDL simulator executables — also called vsim
(ModelSim®) and nclaunch (Cadence Incisive®) — are on the system path. See
your system documentation for instruction on setting environment variables.
Linux Users Make sure the HDL simulator executable is still on the system
path after the shell is launched from MATLAB. If it is not, make sure the
shell startup file does not remove it from the path environment variable.
Load an HDL Design for Verification

After you start the HDL simulator from MATLAB with a call to vsim or
nclaunch, load an instance of an HDL module for verification or visualization
with the function vsimmatlab or hdlsimmatlab. At this point, you should
have coded and compiled your HDL model. Issue the function vsimmatlab or
hdlsimmatlab for each instance of an entity or module in your model that you
want to cosimulate. For example (for use with Incisive):
hdlsimmatlab work.osc_top
This command loads the HDL Verifier library, opens a simulation workspace
for osc_top, and display a series of messages in the HDL simulator command
window as the simulator loads the entity (see example for remaining code).
1-23
Bind Test Bench Function Calls With matlabtb

In this section...
“Invoke MATLAB Test Bench Command matlabtb” on page 1-24
“Bind HDL Module Component to MATLAB Test Bench Function” on page
1-26
Invoke MATLAB Test Bench Command matlabtb

You invoke matlabtb by issuing the command in the HDL simulator. See
the Examples section of the matlabtb reference page for several examples
of invoking matlabtb.
Be sure to follow the path specifications for MATLAB test bench sessions
when invoking matlabtb, as explained in “Specify HDL Signal/Port and
Module Paths for MATLAB Test Bench Cosimulation” on page 1-24.
For instructions in issuing the matlabtb command, see “Run MATLAB Test
Bench Simulation” on page 1-32.
Specify HDL Signal/Port and Module Paths for MATLAB Test

Bench Cosimulation
HDL Verifier software has specific requirements for specifying HDL design
hierarchy, the syntax of which is described in the following sections: one for
Verilog at the top level, and one for VHDL at the top level. Do not use a file
name hierarchy in place of the design hierarchy name.
The rules stated in this section apply to signal/port and module path
specifications for MATLAB cosimulation sessions. Other specifications may
work but the HDL Verifier software does not officially recognize nor support
them.
In the following example:
matlabtb u_osc_filter -mfunc oscfilter
1-24
u_osc_filter is the top-level component. If you specify a subcomponent,

you must follow valid module path specifications for MATLAB cosimulation
sessions.
Path Specifications for MATLAB Link Sessions with Verilog Top Level.
• The path specification must start with a top-level module name.

• The path specification can include "." or "/" path delimiters, but it cannot
include mixed delimiters.
• The leaf module or signal must match the HDL language of the top-level
module.
The following examples show valid signal and module path specifications:
top.port_or_sig
/top/sub/port_or_sig
top
top/sub
top.sub1.sub2
The following examples show invalid signal and module path specifications:
• top.sub/port_or_sig
Why this specification is invalid: You cannot use mixed delimiters.
• :sub:port_or_sig
:
:sub
Why this specification is invalid: When you use VHDL-specific delimiters
you limit the interoperability with paths when moving between HDL
simulators and between VHDL and Verilog.
Path Specifications for MATLAB Link Sessions with VHDL Top Level.
• The path specification can include the top-level module name, but you do
not have to include it.
1-25
module.
Examples for ModelSim and Incisive Users
top.port_or_sig
/sub/port_or_sig
top
top/sub
top.sub1.sub2
:
:sub
Bind HDL Module Component to MATLAB Test Bench

Function
By default, the HDL Verifier software assumes that the name for a MATLAB
function matches the name of the HDL module that the function verifies.
When you create a test bench or component function that has a different name
than the design under test, you must associate the design with the MATLAB
function using the -mfunc argument to matlabtb. This argument associates
the HDL module instance to a MATLAB function that has a different name
from the HDL instance.
1-26
For more information on the -mfunc argument and for a full list of matlabtb
parameters, see the matlabtb function reference.
For details on MATLAB function naming guidelines, see "MATLAB

Programming Tips" on files and file names in the MATLAB documentation.
Example of Binding Test Bench and Component Function Calls

In this first example, you form an association between the inverter_vl
component and the MATLAB test bench function inverter_tb by invoking the
function matlabtb with the -mfunc argument when you set up the simulation.
matlabtb inverter_vl -mfunc inverter_tb
The matlabtb command instructs the HDL simulator to call back the
inverter_tb function when inverter_vl executes in the simulation.
In this second example, you bind the model osc_top.u_osc_filter to the

component function oscfilter:
matlabcp osc_top.u_osc_filter -mfunc oscfilter
When the HDL simulator calls the oscfilter callback, the function knows to
operate on the model osc_top.u_osc_filter.
1-27
Schedule Options for a Test Bench Session

In this section...
“About Scheduling Options for Test Bench Sessions” on page 1-28
“Schedule Test Bench Session Using matlabtb Arguments” on page 1-28
“Schedule Test Bench Functions With the tnext Parameter” on page 1-29
About Scheduling Options for Test Bench Sessions

There are two ways to schedule the invocation of a MATLAB function:
• Using the arguments to the HDL Verifier function matlabtb or matlabcp

• Inside the MATLAB function using the tnext parameter
The two types of scheduling are not mutually exclusive. You can combine
the matlabtb or matlabcp timing arguments and the tnext parameter of a
MATLAB function to schedule test bench or component session callbacks.
Schedule Test Bench Session Using matlabtb

Arguments
By default, the HDL Verifier software invokes a MATLAB test bench
or component function once (at the time that you make the call to
matlabtb/matlabcp). If you want to apply more control, and execute the
MATLAB function more than once, use the command scheduling options.
With these options, you can specify when and how often the HDL Verifier
software invokes the relevant MATLAB function. If applicable, modify the
function or specify timing arguments when you begin a MATLAB test bench
or component function session with the matlabtb/matlabcp function.
You can schedule a MATLAB test bench or component function to execute

using the command arguments under any of the following conditions:
• Discrete time values—Based on time specifications that can also include

repeat intervals and a stop time
• Rising edge—When a specified signal experiences a rising edge
1-28
- VHDL: Rising edge is {0 or L} to {1 or H}.

- Verilog: Rising edge is the transition from 0 to x, z, or 1, and from x
or z to 1.
• Falling edge—When a specified signal experiences a falling edge
- VHDL: Falling edge is {1 or H} to {0 or L}.
- Verilog: Falling edge is the transition from 1 to x, z, or 0, and from
x or z to 0.
• Signal state change—When a specified signal changes state, based on a
list using the -sensitivity argument to matlabtb.
Schedule Test Bench Functions With the tnext

Parameter
You can control the callback timing of a MATLAB function by using that
function’s tnext parameter. This parameter passes a time value to the HDL
simulator, and the value gets added to the simulation schedule for that
function. If the function returns a null value ([]) , the software does not add
any new entries to the schedule.
You can set the value of tnext to a value of type double or int64. Specify
double to express the callback time in seconds. For example, to schedule
a callback in 1 ns, specify::
tnext = 1e-9
Specify int64 to convert to an integer multiple of the current HDL simulator

time resolution limit. For example: if the HDL simulator time precision is 1
ns, to schedule a callback at 100 ns, specify:
tnext=int64(100)
1-29
Note The tnext parameter represents time from the start of the simulation.
Therefore, tnext must always be greater than tnow. If it is less, the software
does not schedule a callback.
For more information on tnext and the function prototype, see “MATLAB
Function Syntax and Function Argument Definitions” on page 8-40.
Examples of Scheduling with tnext

In this first example, each time the HDL simulator calls the test bench
function (via HDL Verifier), tnext schedules the next callback to the MATLAB
function for 1 ns later, relative to the current simulation time:
tnext = [];
.
.
.
tnext = tnow+1e-9;
Using tnext you can dynamically decide the callback scheduling based on
criteria specific to the operation of the test bench. For example, you can decide
to stop scheduling callbacks when a data signal has a certain value:
if qsum == 17,
qsum = 0;
disp('done');
testisdone = 1;
return;
end
This next example demonstrates scheduling a component session using tnext.

In the Oscillator example, the oscfilter function calculates a time interval
at which the HDL simulator calls the callbacks. The component function
calculates this interval on the first call to oscfilter and stores the result in the
variable fastestrate. The variable fastestrate represents the sample period of
the fastest oversampling rate supported by the filter. The function derives
this rate from a base sampling period of 80 ns.
1-30
The following assignment statement sets the timing parameter tnext. This
parameter schedules the next callback to the MATLAB component function,
relative to the current simulation time (tnow).
tnext = tnow + fastestrate;
The function returns a new value for tnext each time the HDL simulator
calls the function.
1-31
Run MATLAB Test Bench Simulation

In this section...
“Process for Running MATLAB Test Bench Cosimulation” on page 1-32
“Check MATLAB Server’s Link Status for Test Bench Cosimulation” on
page 1-32
“Run Test Bench Cosimulation” on page 1-33
“Apply Stimuli to Test Bench Session with force Command” on page 1-37
“Restart Test Bench Simulation” on page 1-39
Process for Running MATLAB Test Bench Cosimulation

To start and control the execution of a simulation in the MATLAB
environment, perform the following steps:
1 “Check MATLAB Server’s Link Status for Test Bench Cosimulation” on

page 1-32
3 “Apply Stimuli to Test Bench Session with force Command” on page 1-37
4 “Restart Test Bench Simulation” on page 1-39 (if applicable).
Check MATLAB Server’s Link Status for Test Bench

Cosimulation
The first step to starting an HDL simulator and MATLAB test bench or
component function session is to check the MATLAB server’s link status. Is
the server running? If the server is running, what mode of communication
and, if applicable, what TCP/IP socket port is the server using for its links?
You can retrieve this information by using the MATLAB function hdldaemon
with the 'status' option. For example:
hdldaemon('status')
The function displays a message that indicates whether the server is running
and, if it is running, the number of connections it is handling. For example:
1-32
HDLDaemon socket server is running on port 4449 with 0 connections
If the server is not running, the message reads
HDLDaemon is NOT running
See the Options: Inputs section in the hdldaemon reference documentation

for information on determining the mode of communication and the TCP/IP
socket in use.
Run Test Bench Cosimulation

You can run a cosimulation session using both the MATLAB and HDL
simulator GUIs (typical) or, to reduce memory demand, you can run the
cosimulation using the command line interface (CLI) or in batch mode.
• “Cosimulation with MATLAB Using the HDL Simulator GUI” on page 1-33
• “Cosimulation with MATLAB Using the Command Line Interface (CLI)”
on page 1-35
• “Cosimulation with MATLAB Using Batch Mode” on page 1-36
Cosimulation with MATLAB Using the HDL Simulator GUI

These steps describe a typical sequence for running a simulation interactively
from the main HDL simulator window:
1 Set breakpoints in the HDL and MATLAB code to verify and analyze
simulation progress.
How you set breakpoints in the HDL simulator will vary depending on
what simulator application you are using.
In MATLAB, there are several ways you can set breakpoints; for example,
by using the Set/Clear Breakpoint button on the toolbar.
2 Issue matlabtb command at the HDL simulator prompt.
When you begin a specific test bench or component session, you specify
parameters that identify the following information:
1-33
• The mode and, if applicable, TCP/IP data for connecting to a MATLAB

server (see matlabtb reference)
• The MATLAB function that is associated with and executes on behalf
of the HDL instance (see “Bind HDL Module Component to MATLAB
Test Bench Function” on page 1-26)
• Timing specifications and other control data that specifies when the
module’s MATLAB function is to be called (see “Schedule Options for a
Test Bench Session” on page 1-28).
For example:
hdlsim> matlabtb osc_top -sensitivity /osc_top/sine_out

-socket 4448 -mfunc hosctb
3 Start the simulation by entering the HDL simulator run command.
The run command offers a variety of options for applying control over how
a simulation runs (refer to your HDL simulator documentation for details).
For example, you can specify that a simulation run for several time steps.
The following command instructs the HDL simulator to run the loaded
simulation for 50000 time steps:
run 50000
4 Step through the simulation and examine values.
How you step through the simulation in the HDL simulator will vary
depending on what simulator application you are using.
In MATLAB, there are several ways you can step through code; for
example, by clicking the Step toolbar button.
5 When you block execution of the MATLAB function, the HDL simulator
also blocks and remains blocked until you clear all breakpoints in the
function’s code.
6 Resume the simulation, as desired.
How you resume the simulation in the HDL simulator will vary depending
on what simulator application you are using.
1-34
In MATLAB, there are several ways you can resume the simulation; for
example, by clicking the Continue toolbar button.
The following HDL simulator command resumes a simulation:
run -continue
For more information on HDL simulator and MATLAB debugging features,

see the HDL simulator documentation and MATLAB online help or
documentation.
Cosimulation with MATLAB Using the Command Line Interface

(CLI)
Running your cosimulation session using the command-line interface allows
you to interact with the HDL simulator during cosimulation, which can be
helpful for debugging.
To use the CLI, specify "CLI" as the property value for the run mode
parameter of the HDL Verifier HDL simulator launch command.
The Tcl command you build to pass to the HDL simulator launch command
must contain the run command or no cosimulation will take place.
Caution Close the terminal window by entering "quit -f" at the command
prompt. Do not close the terminal window by clicking the "X" in the upper
right-hand corner. This causes a memory-type error to be issued from the
system. This is not a bug with HDL Verifier but just the way the HDL
simulator behaves in this context.
You can type CTRL+C to interrupt and terminate the simulation in the HDL
simulator but this action also causes the memory-type error to be displayed.
Specify CLI mode with nclaunch (Cadence Incisive)
Issue the nclaunch command with "CLI" as the runmode property value, as
follows (example entered into the MATLAB editor):
tclcmd = { ['cd ',projdir],...
1-35
['exec ncvlog ' srcfile],...

'exec ncelab -access +wc lowpass_filter',...
['hdlsimmatlab -gui lowpass_filter ', ...
' -input "{@matlabtb lowpass_filter 10ns -repeat 10ns ...
-mfunc filter_tb_incisive}"',...
' -input "{@force lowpass_filter.clk_enable 1 -after 0ns}"',...
' -input "{@force lowpass_filter.reset 1 -after 0ns 0 -after 22ns}"',...
' -input "{@force lowpass_filter.clk 1 -after 0ns 0 -after 5ns ...
-repeat 10ns}"',...
' -input "{@deposit lowpass_filter.filter_in 0}"',...
]};
nclaunch('tclstart',tclcmd,'runmode','CLI');
Specify CLI mode with vsim (Mentor Graphics ModelSim)
Issue the vsim command with "CLI" as the runmode property value, as follows
(example entered into the MATLAB editor):
tclcmd = { ['cd ',unixprojdir],...

'vlib work',... %create library (if applicable)
'force /osc_top/clk_enable 1 0',...
'force /osc_top/reset 1 0, 0 120 ns',...
'force /osc_top/clk 1 0 ns, 0 40 ns -r 80ns',...
};
vsim('tclstart',tclcmd,'runmode','CLI');
Cosimulation with MATLAB Using Batch Mode

Running your cosimulation session in batch mode allows you to keep the
process in the background, reducing demand on memory by disengaging the
GUI.
To use the batch mode, specify "Batch" as the property value for the run mode
parameter of the HDL Verifier HDL simulator launch command. After you
issue the HDL Verifier HDL simulator launch command with batch mode
specified, start the simulation in Simulink. To stop the HDL simulator before
the simulation is completed, issue the breakHdlSim command.
1-36
Specify Batch mode with nclaunch (Cadence Incisive)
Issue the nclaunch command with "Batch" as the runmode parameter, as

follows:
nclaunch('tclstart',manchestercmds,'runmode','Batch')
You can also set runmode to "Batch with Xterm", which starts the HDL
simulator in the background but shows the session in an Xterm.
Specify Batch mode with vsim (Mentor Graphics ModelSim)
On Windows, specifying batch mode causes ModelSim to be run in a

non-interactive command window. On Linux, specifying batch mode causes
Modelsim to be run in the background with no window.
Issue the vsim command with "Batch" as the runmode parameter, as follows:
>> vsim('tclstart',manchestercmds,'runmode','Batch')
Apply Stimuli to Test Bench Session with force

Command
After you establish a connection between the HDL simulator and MATLAB,
you can then apply stimuli to the test bench or component cosimulation
environment. One way of applying stimuli is through the iport parameter of
the linked MATLAB function. This parameter forces signal values by deposit.
Other ways to apply stimuli include issuing force commands in the HDL
simulator main window (for ModelSim, you can also use the Edit > Clock
option in the ModelSim Signals window).
For example, consider the following sequence of force commands:
• Incisive
force osc_top.clk_enable 1 -after 0ns

force osc_top.reset 0 -after 0ns 1 -after 40ns 0 -after 120ns
force osc_top.clk 1 -after 0ns 0 -after 40ns -repeat 80ns
• ModelSim
1-37
VSIM n> force clk 0 0 ns, 1 5 ns -repeat 10 ns

VSIM n> force clk_en 1 0
VSIM n> force reset 0 0
These commands drive the following signals:
• The clk signal to 0 at 0 nanoseconds after the current simulation time

and to 1 at 5 nanoseconds after the current HDL simulation time. This
cycle repeats starting at 10 nanoseconds after the current simulation
time, causing transitions from 1 to 0 and 0 to 1 every 5 nanoseconds, as
the following diagram shows.
1
0
...
t 0 5 10 20 30
For example,
force /foobar/clk 0 0, 1 5 -repeat 10
• The clk_en signal to 1 at 0 nanoseconds after the current simulation time.

• The reset signal to 0 at 0 nanoseconds after the current simulation time.
Incisive Users: Using HDL to Code Clock Signals Instead of

the force Command
You should consider using HDL to code clock signals as force is a lower
performance solution in the current version of Cadence Incisive simulators.
The following are ways that a periodic force might be introduced:
• Via the Clock pane in the HDL Cosimulation block

• Via pre/post Tcl commands in the HDL Cosimulation block
• Via a user-input Tcl script to ncsim
All three approaches may lead to performance degradation.
1-38
Restart Test Bench Simulation

Because the HDL simulator issues the service requests during a MATLAB
cosimulation session, you must restart the session from the HDL simulator.
To restart a session, perform the following steps:
1 Make the HDL simulator your active window, if your input focus was not
already set to that application.
2 Reload HDL design elements and reset the simulation time to zero.
3 Reissue the matlabtb or matlabcp command.
Note To restart a simulation that is in progress, issue a break command and

end the current simulation session before restarting a new session.
1-39
Stop Test Bench Simulation

When you are ready to stop a test bench session, it is best to do so in an
orderly way to avoid possible corruption of files and to see that all application
tasks shut down cleanly. You should stop a session as follows:
2 Halt the simulation. You must quit the simulation at the HDL simulator
side or MATLAB may hang until the simulator is quit.
3 Close your project.
4 Exit the HDL simulator, if you are finished with the application.
5 Quit MATLAB, if you are finished with the application. If you want to
shut down the server manually, stop the server by calling hdldaemon with
the 'kill' option:
hdldaemon('kill')
For more information on closing HDL simulator sessions, see the HDL
simulator documentation.
1-40
Verify HDL Model with MATLAB Testbench

In this section...
“Tutorial Overview” on page 1-41
“Set Up Tutorial Files” on page 1-42
“Start the MATLAB Server” on page 1-42
“Start ModelSim Simulator and Set Up for Cosimulation” on page 1-44
“Develop VHDL Code” on page 1-46
“Compile VHDL” on page 1-48
“Develop MATLAB Function” on page 1-49
“Load Simulation” on page 1-51
“Run Simulation” on page 1-53
“Shut Down Simulation” on page 1-58
Tutorial Overview
This tutorial guides you through the basic steps for setting up an HDL
Verifier application that uses MATLAB to verify a simple HDL design. In this
tutorial, you develop, simulate, and verify a model of a pseudorandom number
generator based on the Fibonacci sequence. The model is coded in VHDL.
Note This tutorial demonstrates creating and running a test bench using
ModelSim SE 6.5. If you are not using this version, the messages and screen
images from ModelSim may not appear to you exactly as they do in this
tutorial.
This tutorial requires MATLAB, the HDL Verifier software, and the
ModelSim HDL simulator.
In this tutorial, you will perform the following steps:
1 “Set Up Tutorial Files” on page 1-42
1-41
2 “Start the MATLAB Server” on page 1-42
3 “Start ModelSim Simulator and Set Up for Cosimulation” on page 1-44
4 “Develop VHDL Code” on page 1-46
5 “Develop VHDL Code” on page 1-46
6 “Develop MATLAB Function” on page 1-49
7 “Load Simulation” on page 1-51
8 “Run Simulation” on page 1-53
9 “Shut Down Simulation” on page 1-58
Set Up Tutorial Files

To help others have access to copies of the tutorial files, set up a folder for
your own tutorial work:
1 Create a folder outside the scope of your MATLAB installation folder into
which you can copy the tutorial files. The folder must be writable. This
tutorial assumes that you create a folder named MyPlayArea.
2 Copy the following files to the folder you just created:
matlabroot\toolbox\edalink\extensions\modelsim\modelsimdemos\modsimrand_pl
matlabroot\toolbox\edalink\extensions\modelsim\modelsimdemos\VHDL\modsimra
Start the MATLAB Server

This section describes starting MATLAB, setting up the current folder for
completing the tutorial, starting the product’s MATLAB server component,
and checking for client connections, using shared memory or the server’s
TCP/IP socket mode. These instructions assume you are familiar with the
MATLAB user interface.
Perform the following steps:
1 Start MATLAB.
1-42
2 Set your MATLAB current folder to the folder you created in “Set Up
Tutorial Files” on page 1-42.
3 Verify that the MATLAB server is running by calling function hdldaemon

with the 'status' option in the MATLAB Command Window as shown
here:
hdldaemon('status')
If the server is not running, the function displays
If the server is running in TCP/IP socket mode, the message reads
HDLDaemon socket server is running on Port portnum with 0 connections
If the server is running in shared memory mode, the message reads
HDLDaemon shared memory server is running with 0 connections
If the server is not currently running, skip to step 5.
4 Shut down the server by typing
hdldaemon('kill')
You will see the following message that confirms that the server was shut
down.
HDLDaemon server was shutdown
5 Start the server in TCP/IP socket mode by calling hdldaemon with the
property name/property value pair 'socket' 0. The value 0 specifies
that the operating system assign the server a TCP/IP socket port that is
available on your system. For example
hdldaemon('socket', 0)
The server informs you that it has started by displaying the following
message. The portnum will be specific to your system:
HDLDaemon socket server is running on Port portnum with 0 connections
1-43
Make note of portnum as you will need it when you issue the matlabtb
command in “Load Simulation” on page 1-51.
You can alternatively specify that the MATLAB server use shared memory
communication instead of TCP/IP socket communication; however, for this
tutorial we will use socket communication as means of demonstrating this
type of connection. For details on how to specify the various options, see
the description of hdldaemon.
Start ModelSim Simulator and Set Up for

Cosimulation
This section describes the basic procedure for starting the ModelSim software
and setting up a ModelSim design library. These instructions assume you are
familiar with the ModelSim user interface.
1 Start ModelSim from the MATLAB environment by calling the function

vsim in the MATLAB Command Window.
vsim
This function launches and configures ModelSim for use with the HDL
Verifier software. The first folder of ModelSim matches your MATLAB
current folder.
2 Verify the current ModelSim folder. You can verify that the current
ModelSim folder matches the MATLAB current folder by entering the ls
command in the ModelSim command window.
1-44
The command should list the files modsimrand.vhd, modsimrand_plot.m,

transcript, and compile_and_launch.tcl.
If it does not, change your ModelSim folder to the current MATLAB folder.
You can find the current MATLAB folder by looking in the Current Folder
Browser or by viewing the Current folder navigation bar. In ModelSim, you
can change the working folder by issuing the command
cd directory
Where directory is the folder you want to work from. Or you may also
change directory by selecting File > Change Directory....
3 Create a design library to hold your compilation results. To create the

library and required _info file, enter the vlib and vmap commands as
follows:
ModelSim> vlib work
Note You must use the ModelSim File menu or vlib command to create
the library folder so that the required _info file is created. Do not create
the library with operating system commands.
1-45
Develop VHDL Code

After setting up a design library, typically you would use the ModelSim Editor
to create and modify your HDL code. For this tutorial, you do not need to
create the VHDL code yourself. Instead, open and examine the existing file
modsimrand.vhd. This section highlights areas of code in modsimrand.vhd
that are of interest for a ModelSim and MATLAB test bench.
If you choose not to examine the HDL code at this time, skip to “Compile
VHDL” on page 1-48.
You can open modsimrand.vhd in the edit window with the edit command, as
follows:
ModelSim> edit modsimrand.vhd
ModelSim opens its edit window and displays the VHDL code for
modsimrand.vhd.
1-46
While you are viewing the file, note the following:
• The line ENTITY modsimrand contains the definition for the VHDL entity
modsimrand:
ENTITY modsimrand IS
PORT (
clk : IN std_logic ;
clk_en : IN std_logic ;
reset : IN std_logic ;
dout : OUT std_logic_vector (31 DOWNTO 0);
END modsimrand;
This is the entity that will be verified in the MATLAB environment during
the tutorial. Note the following:
- By default, the MATLAB server assumes that the name of the MATLAB
function that verifies the entity in the MATLAB environment is the
same as the entity name. You have the option of naming the MATLAB
function explicitly. However, if you do not specify a name, the server
1-47
expects the function name to match the entity name. In this example,
the MATLAB function name is modsimrand_plot and does not match.
- The entity must be defined with a PORT clause that includes at least one
port definition. Each port definition must specify a port mode (IN, OUT,
or INOUT) and a VHDL data type that is supported by the HDL Verifier
software. For a list of the supported types, see “Code HDL Modules for
Verification Using MATLAB ” on page 1-5.
The entity modsimrand in this example is defined with three input
ports clk, clk_en, and reset of type STD_LOGIC and output port dout
of type STD_LOGIC_VECTOR. The output port passes simulation output
data out to the MATLAB function for verification. The optional input
ports receive clock and reset signals from the function. Alternatively, the
input ports can receive signals from ModelSim force commands.
For more information on coding port entities for use with MATLAB, see
“Code HDL Modules for Verification Using MATLAB ” on page 1-5.
• The remaining code for modsimrand.vhd defines a behavioral architecture
for modsimrand that writes a randomly generated Fibonacci sequence to an
output register when the clock experiences a rising edge.
When you are finished examining the file, close the ModelSim edit window.
Compile VHDL
After you create or edit your VHDL source files, compile them. As part of this
tutorial, compile modsimrand.vhd. One way of compiling the file is to click the
file name in the project workspace and select Compile > Compile All. An
alternative is to specify modsimrand.vhd with the vcom command, as follows:
If the compilation succeeds, messages appear in the command window and

the compiler populates the work library with the compilation results.
1-48
Develop MATLAB Function

The HDL Verifier software verifies HDL hardware in MATLAB as a function.
Typically, at this point you would create or edit a MATLAB function that
meets HDL Verifier requirements. For this tutorial, you do not need to
develop the MATLAB test bench function yourself. Instead, open and examine
the existing file modsimrand_plot.m.
If you choose not to examine the HDL code at this time, skip to “Load
Simulation” on page 1-51.
Note modsimrand_plot.m is a lower-level component of the

MATLAB Random Number Generator example. Plotting code within
modsimrand_plot.m is not discussed in the next section. This tutorial focuses
only on those parts of modsimrand_plot.m that are required for MATLAB to
verify a VHDL model.
You can open modsimrand_plot.m in the MATLAB Editor. For example:
edit modsimrand_plot.m
While you are viewing the file, note the following:
• On line 1, you will find the MATLAB function name specified along with its
required parameters:
function [iport,tnext] = modsimrand_plot(oport,tnow,portinfo)
1-49
This function definition is significant because it represents the

communication channel between MATLAB and ModelSim. Note:
- When coding the function, you must define the function with two output
parameters, iport and tnext, and three input parameters, oport, tnow,
and portinfo. See “MATLAB Function Syntax and Function Argument
- You can use the iport parameter to drive input signals instead
of, or in addition to, using other signal sources, such as ModelSim
force commands. Depending on your application, you might use any
combination of input sources. However, if multiple sources drive signals
to a single iport, you will need a resolution function to handle signal
contention.
• On lines 22 and 23, you will find some parameter initialization:
tnext = [];
iport = struct();
In this case, function outputs iport and tnext are initialized to empty
values.
• When coding a MATLAB function for use with HDL Verifier, you need to
know the types of the data that the test bench function receives from and
needs to return to ModelSim and how HDL Verifier handles this data; see
“Data Type Conversions” on page 8-65. This function includes the following
port data type definitions and conversions:
- The entity defined for this tutorial consists of three input ports of type
STD_LOGIC and an output port of type STD_LOGIC_VECTOR.
- Data of type STD_LOGIC_VECTOR consists of a column vector of characters
with one bit per character.
- The interface converts scalar data of type STD_LOGIC to a character that
matches the character literal for the corresponding enumerated type.
On line 62, the line of code containing oport.dout shows how the data that
a MATLAB function receives from ModelSim might need to be converted
for use in the MATLAB environment:
ud.buffer(cyc) = mvl2dec(oport.dout)
1-50
In this case, the function receives STD_LOGIC_VECTOR data on oport. The

function mvl2dec converts the bit vector to a decimal value that can be
used in arithmetic computations. “Data Type Conversions” on page 8-65
provides a summary of the types of data conversions to consider when
coding your own MATLAB functions.
• Feel free to browse through the rest of modsimrand_plot.m. When you are
finished, go to “Load Simulation” on page 1-51.
Load Simulation
After you compile the VHDL source file, you are ready to load the model
for simulation. This section explains how to load an instance of entity
modsimrand for simulation:
1 Load the instance of modsimrand for verification. To load the instance,

specify the vsimmatlab command as follows:
ModelSim> vsimmatlab modsimrand
The vsimmatlab command starts the ModelSim simulator, vsim,

specifically for use with MATLAB. ModelSim displays a series of messages
in the command window as it loads the entity’s packages and architecture.
1-51
2 Initialize the simulator for verifying modsimrand with MATLAB. You

initialize ModelSim by using the HDL Verifier matlabtb command. This
command defines the communication link and a callback to a MATLAB
function that executes in MATLAB on behalf of ModelSim. In addition,
the matlabtb command can specify parameters that control when the
MATLAB function executes.
For this tutorial, enter the following matlabtb command:
1-52
> matlabtb modsimrand -mfunc modsimrand_plot -rising /modsimrand/clk -socket portnum
Arguments in the command line specify the following conditions:

• modsimrand—Specifies the VHDL module to cosimulate.
• -mfunc modsimrand_plot—Links an instance of the entity modsimrand
to the MATLAB function modsimrand_plot.m. The argument is required
because the entity name is not the same as the test bench function name.
• -rising /modsimrand/clk—Specifies that the test bench function be
called whenever signal /modsimrand/clk experiences a rising edge.
• -socketportnum—Specifies the port number issued with or returned by
the call to hdldaemon in “Start the MATLAB Server” on page 1-42.
3 Initialize clock and reset input signals. You can drive simulation input
signals using several mechanisms, including ModelSim force commands
and an iport parameter (see “Syntax of a Test Bench Function” on page
1-12). For now, enter the following force commands:
> force /modsimrand/clk 0 0 ns, 1 5 ns -repeat 10 ns

> force /modsimrand/clk_en 1
> force /modsimrand/reset 1 0, 0 50 ns
The first command forces the clk signal to value 0 at 0 nanoseconds and to
1 at 5 nanoseconds. After 10 nanoseconds, the cycle starts to repeat every
10 nanoseconds. The second and third force commands set clk_en to 1
and reset to 1 at 0 nanoseconds and to 0 at 50 nanoseconds.
The ModelSim environment is ready to run a simulation. Now, you need to

set up the MATLAB function.
Run Simulation
This section explains how to start and monitor this simulation, and rerun it, if
you desire. When you have completed as many simulation runs as desired,
shut down the simulation as described in the next section.
Running the Simulation for the First Time

Before running the simulation for the first time, you must verify the client
connection. You may also want to set breakpoints for debugging.
1-53
1 Open ModelSim and MATLAB windows.
2 In MATLAB, verify the client connection by calling hdldaemon with the

'status' option:
hdldaemon('status')
This function returns a message indicating a connection exists:
HDLDaemon socket server is running on port 4795 with 1 connection
Or
HDLDaemon shared memory server is running with 1 connection
Note If you attempt to run the simulation before starting the hdldaemon
in MATLAB, you will receive the following warning:
#ML Warn - MATLAB server not available (yet),

The entity 'modsimrand' will not be active
3 Open modsimrand_plot.m in the MATLAB Editor.
4 Search for oport.dout and set a breakpoint at that line by clicking next to
the line number. A red breakpoint marker will appear.
5 Return to ModelSim and enter the following command in the command

window:
> run 80000
This command instructs ModelSim to advance the simulation 80,000 time

steps (80,000 nanoseconds using the default time step period). Because
you previously set a breakpoint in modsimrand_plot.m, however, the
simulation runs in MATLAB until it reaches the breakpoint.
1-54
ModelSim is now blocked and remains blocked until you explicitly unblock
it. While the simulation is blocked, note that MATLAB displays the data
that ModelSim passed to the MATLAB function in the Workspace window.
In ModelSim, an empty figure window opens. You can use this window to
plot data generated by the simulation.
6 Examine oport, portinfo, and tnow by hovering over these arguments

inside the MATLAB Editor. Observe that tnow, the current simulation
time, is set to 0. Also notice that, because the simulation has reached
a breakpoint during the first call to modsimrand_plot, the portinfo
argument is visible in the MATLAB workspace.
7 Click Continue in the MATLAB Editor. The next time the breakpoint
is reached, notice that portinfo no longer appears in the MATLAB
1-55
workspace. The portinfo function does not show because it is passed in

only on the first function invocation. Also note that the value of tnow
advances from 0 to 5e-009.
8 Clear the breakpoint by clicking the red breakpoint marker.
9 Unblock ModelSim and continue the simulation by clicking Continue in

the MATLAB Editor.
The simulation runs to completion. As the simulation progresses, it plots

generated data in a figure window. When the simulation completes, the
figure window appears as shown here.
1-56
The simulation runs in MATLAB until it reaches the breakpoint that you just
set. Continue the simulation/debugging session as desired.
Rerunning the Simulation

If you want to run the simulation again, you must restart the simulation in
ModelSim, reinitialize the clock, and reset input signals. To do so:
1 Close the figure window.
2 Restart the simulation with the following command:
1-57
> restart
The Restart dialog box appears. Leave all the options enabled, and click
Restart.
Note The Restart button clears the simulation context established by a

matlabtb command. Thus, after restarting ModelSim, you must reissue
the previous command or issue a new command.
3 Reissue the matlabtb command in the HDL simulator.
> matlabtb modsimrand -mfunc modsimrand_plot -rising /modsimrand/clk -socket portnum
4 Open modsimrand_plot.m in the MATLAB Editor.
5 Set a breakpoint at the same line as in the previous run.
6 Return to ModelSim and re-enter the following commands to reinitialize

clock and input signals:
> force /modsimrand/clk 0 0,1 5 ns -repeat 10 ns

> force /modsimrand/clk_en 1
> force /modsimrand/reset 1 0, 0 50 ns
7 Enter a command to start the simulation, for example:
> run 80000
Shut Down Simulation

This section explains how to shut down a simulation in an orderly way.
In ModelSim, perform the following steps:
1 Stop the simulation on the client side by selecting Simulate > End
Simulation or entering the quit command.
2 Quit ModelSim.
1-58
In MATLAB, you can just quit the application, which will shut down the
simulation and also close MATLAB.
To shut down the server without closing MATLAB, you have the option of
calling hdldaemon with the 'kill' option:
hdldaemon('kill')
The following message appears, confirming that the server was shut down:
HDLDaemon server was shutdown
1-59
Automatic Cosimulation Verification

Cosimulate the device-under-test (DUT) in ModelSim or Cadence Incisive.
You can optionally include a test bench in MATLAB. To use this feature, you
must have an HDL Coder™ license.
1 Start the MATLAB to HDL Workflow Advisor.
2 At step HDL Verification, click Verify with Cosimulation.
1-60
Automatic Cosimulation Verification
3 Select Generate HDL test bench to instruct HDL Coder to generate HDL
test bench code from your MATLAB test script (optional).
4 Select Log outputs for comparison plots if you would like to log and
plot outputs of the reference design function and HDL simulator (optional).
5 For Cosimulate for use with, select either Mentor Graphics ModelSim
or Cadence Incisive as the HDL simulator you want for cosimulation.
6 For HDL simulator run mode in cosimulation, select Batch mode for
non-interactive simulation. Select GUI mode to view waverforms.
7 Select Simulate generated cosimulation test bench to automatically

verify the generated HDL code in a cosimulation test bench.
8 For Advanced Options, select and set the optional parameters according
to the descriptions in the following table.
Parameter Description
Clock high time (ns) Specify the number of nanoseconds
the clock is high.
Clock low time (ns) Specify the number of nanoseconds
the clock is low.
Hold time (ns) Specify the hold time for input
signals and forced reset signals.
Clock enable delay (in clock Specify time (in clock cycles)
cycles) between deassertion of reset and
assertion of clock enable.
Reset length (in clock cycles) Specify time (in clock cycles)
between assertion and deassertion
of reset.
9 Optionally, select Skip this step if you don’t want to verify with
cosimulation.
10 Click Run.
1-61
If you selected Batch mode, a command window appears to launch

the HDL simulator and run the cosimulation. This window is closed
programmatically. If you selected GUI mode, the HDL simulator is opened
and left open after simulation so that you may examine the waveforms
and other signal data.
If there are errors, those messages appear in the message pane. Correct
any errors and click Run.
1-62
2

MATLAB Component
Function
• “MATLAB Function as a Component” on page 2-2

• “Create a MATLAB Component Function” on page 2-4
• “Code HDL Modules for Visualization Using MATLAB” on page 2-5
• “Create an HDL Verifier MATLAB Component Function” on page 2-10
• “Place Component Function on MATLAB Search Path” on page 2-12
• “Start Connection to HDL Simulator” on page 2-13
• “Bind Component Function Calls With matlabcp” on page 2-16
• “Schedule Options for a Component Session” on page 2-20
• “Run MATLAB Component Function Simulation” on page 2-24
• “Stop Component Simulation” on page 2-32
2 HDL Cosimulation Using MATLAB Component Function
MATLAB Function as a Component

The HDL Verifier software provides a means for visualizing HDL components
within the MATLAB environment. You do so by coding an HDL model and
a MATLAB function that can share data with the HDL model. This chapter
discusses the programming, interfacing, and scheduling conventions for
MATLAB component functions that communicate with the HDL simulator.
MATLAB component functions simulate the behavior of components in the

HDL model. A stub module (providing port definitions only) in the HDL model
passes its input signals to the MATLAB component function. The MATLAB
component processes this data and returns the results to the outputs of the
stub module. A MATLAB component typically provides some functionality
(such as a filter) that is not yet implemented in the HDL code.
The following figure shows how an HDL simulator wraps around a MATLAB
component function and how MATLAB communicates with the HDL
simulator during a component simulation session.
When linked with MATLAB, the HDL simulator functions as the client, with
MATLAB as the server. The following figure shows a multiple-client scenario
connecting to the server at TCP/IP socket port 4449.
2-2
MATLAB Function as a Component
MATLAB
HDL Simulator Link Server
Port
Client 4449
HDL Simulator Link

Client

sessions and HDL modules. However, you should follow recommended
guidelines to help the server track the I/O associated with each module and
session. The MATLAB server, which you start with the supplied MATLAB
function hdldaemon, waits for connection requests from instances of the HDL
simulator running on the same or different computers. When the server
receives a request, it executes the specified MATLAB function you have coded
to perform tasks on behalf of a module in your HDL design. Parameters that
you specify when you start the server indicate whether the server establishes
shared memory or TCP/IP socket communication links.
Refer to “Machine Configuration Requirements” on page 8-2 for valid machine

configurations.
Note The programming, interfacing, and scheduling conventions for test

bench functions and component functions are virtually identical. For the most
part, the same procedures apply to both types of functions.
2-3
Create a MATLAB Component Function

The following workflow steps describe how to create a MATLAB component
function for cosimulation with the HDL simulator using HDL Verifier.
1 Create HDL module. Compile, elaborate, and simulate model in HDL

simulator . See “Code HDL Modules for Visualization Using MATLAB”
on page 2-5.
2 Create component MATLAB function. See “Create an HDL Verifier

MATLAB Component Function” on page 2-10.
3 Place component function on MATLAB search path. See “Place Component

Function on MATLAB Search Path” on page 2-12.
4 Start hdldaemon to provide connectivity for HDL simulator. See “Start

Connection to HDL Simulator” on page 2-13.
5 Launch HDL simulator for use with MATLAB and load HDL Verifier
libraries. See “Start HDL Simulator” on page 2-15
6 Bind HDL instance with component function using matlabcp. See “Bind
Component Function Calls With matlabcp” on page 2-16.
7 Add scheduling options. See “Schedule Options for a Component Session”

on page 2-20.
9 Run cosimulation from HDL simulator. See “Run MATLAB Component

Function Simulation” on page 2-24.
10 Disconnect session. See “Stop Component Simulation” on page 2-32.
2-4
Code HDL Modules for Visualization Using MATLAB

In this section...
“Overview to Coding HDL Modules for Visualization with MATLAB” on
page 2-5
“Choose HDL Module Name for Use with MATLAB Component Function”
on page 2-6
“Specify Port Direction Modes in HDL Module for Use with Component
Functions” on page 2-6
“Specify Port Data Types in HDL Modules for Use with Component
Functions” on page 2-6
“Compile and Elaborate HDL Design for Use with Component Functions”
on page 2-8
Overview to Coding HDL Modules for Visualization

with MATLAB
The most basic element of communication in the HDL Verifier interface is the
HDL module. The interface passes all data between the HDL simulator and
MATLAB as port data. The HDL Verifier software works with any existing
MATLAB verification, you should consider its name, the types of data to be
shared between the two environments, and the direction modes. The sections
within this chapter cover these topics.
The process for coding HDL modules for MATLAB visualization is as follows:
• Choose an HDL module name.

• Specify port direction modes in HDL components.
• Specify port data types in HDL components.
• Compile and debug the HDL model.
2-5
Choose HDL Module Name for Use with MATLAB

Component Function
Although not required, when naming the HDL module, consider choosing a
name that also can be used as a MATLAB function name. (Generally, naming
rules for VHDL or Verilog and MATLAB are compatible.) By default, HDL
Verifier software assumes that an HDL module and its simulation function
share the same name. See “Bind Test Bench Function Calls With matlabtb”
on page 1-24.
For details on MATLAB function-naming guidelines, see “MATLAB

Programming Tips” on files and file names in the MATLAB documentation.
Specify Port Direction Modes in HDL Module for Use

with Component Functions

Mode... Mode...
MATLAB function
a MATLAB function
function

Component Functions
2-6


and BIT_VECTOR
• REAL
• TIME
CHARACTER

in cosimulation
2-7
Port Data Types for Verilog Modules

• reg
• integer
• wire
Compile and Elaborate HDL Design for Use with

Component Functions
After you create or edit your HDL source files, use the HDL simulator
compiler to compile and debug the code.
Compilation for ModelSim
You have the option of invoking the compiler from menus in the ModelSim
graphic interface or from the command line with the vcom command. The
following sequence of ModelSim commands creates and maps the design
library work and compiles the VHDL file modsimrand.vhd:
ModelSim> vlib work

The following sequence of ModelSim commands creates and maps the design
library work and compiles the Verilog file test.v:
ModelSim> vlib work

ModelSim> vlog test.v
2-8
to the MATLAB session for cosimulation. For higher performance, you
want to provide access only to those signals used in cosimulation. You can
check read/write access through the HDL simulator—see HDL simulator
Compilation for Incisive
The Cadence Incisive simulator allows for 1-step and 3-step processes for HDL
compilation, elaboration, and simulation. The following Cadence Incisive
simulator command compiles the Verilog file test.v:
sh> ncvlog test.v
The following Cadence Incisive simulator command compiles and elaborates

the Verilog design test.v, and then loads it for simulation, in a single step:
sh> ncverilog +gui +access+rwc +linedebug test.v
The following sequence of Cadence Incisive simulator commands performs all

the same processes in multiple steps:
sh> ncvlog -linedebug test.v

sh> ncelab -access +rwc test
sh> ncsim test
to the MATLAB session for cosimulation. The previous example shows
how to provide read/write access to all signals in your design. For higher
performance, you want to provide access only to those signals used in
cosimulation. See the description of the +access flag to ncverilog and the
-access argument to ncelab for details.
For more examples, see the HDL Verifier tutorials and demos. For details on
using the HDL compiler, see the simulator documentation.
2-9
Create an HDL Verifier MATLAB Component Function

In this section...
“Overview to Coding an HDL Verifier Component Function” on page 2-10
“Syntax of a Component Function” on page 2-11
Overview to Coding an HDL Verifier Component

Function
Coding a MATLAB function that is to visualize an HDL module or component
requires that you follow specific coding conventions. You must also
understand the data type conversions that occur, and program data type
conversions for operating on data and returning data to the HDL simulator.
To code a MATLAB function that is to verify an HDL module or component,

1 Learn the syntax for a MATLAB HDL Verifier component function (see
“Syntax of a Component Function” on page 2-11.).
2 Understand how HDL Verifier software converts data from the HDL
simulator for use in the MATLAB environment (see “Data Type
Conversions” on page 8-65).
3 Choose a name for the MATLAB component function (see “Bind Component
Function Calls With matlabcp” on page 2-16).
4 Define expected parameters in the component function definition line

(see “MATLAB Function Syntax and Function Argument Definitions” on
page 8-40).
5 Determine the types of port data being passed into the function (see
8-40).
6 Extract and, if applicable to the simulation, apply information received

in the portinfo structure (see “Gaining Access to and Applying Port
Information” on page 8-44).
2-10
Create an HDL Verifier™ MATLAB® Component Function
7 Convert data for manipulation in the MATLAB environment, as applicable

(see “Converting HDL Data to Send to MATLAB” on page 8-65).
8 Convert data that needs to be returned to the HDL simulator (see

“Converting Data for Return to the HDL Simulator” on page 8-70).
Syntax of a Component Function

The syntax of a MATLAB component function is
The input/output arguments (iport and oport) for a MATLAB component

function are the reverse of the port arguments for a MATLAB test bench
function. That is, the MATLAB component function returns signal data to the
outputs and receives data from the inputs of the associated HDL module.
Initialize the function outputs to empty values at the beginning of the function
as in the following example:
tnext = [];
oport = struct();
See “MATLAB Function Syntax and Function Argument Definitions” on

page 8-40 for an explanation of each of the function arguments. For more
information on using tnext and tnow for simulation scheduling with
matlabcp, see “Schedule Component Functions Using the tnext Parameter”
on page 2-21.
2-11
Place Component Function on MATLAB Search Path

In this section...
“Use MATLAB which Function to Find Component Function” on page 2-12
“Add Component Function to MATLAB Search Path” on page 2-12
Use MATLAB which Function to Find Component

Function
The MATLAB function that you are associating with an HDL component must
be on the MATLAB search path or reside in the current working folder (see
the MATLAB cd function). To verify whether the function is accessible, use
the MATLAB which function. The following call to which checks whether the
function MyVhdlFunction is on the MATLAB search path, for example:
which MyVhdlFunction
/work/incisive/MySym/MyVhdlFunction.m
If the specified function is on the search path, which displays the complete
path to the function. If the function is not on the search path, which informs
you that the file was not found.
Add Component Function to MATLAB Search Path

To add a MATLAB function to the MATLAB search path, open the Set
Path window by clicking File > Set Path, or use the addpath command.
Alternatively, for temporary access, you can change the MATLAB working
folder to a desired location with the cd command.
2-12
Start Connection to HDL Simulator
Start Connection to HDL Simulator

In this section...
“Start MATLAB Server for Component Function Session” on page 2-13
“Example of Starting MATLAB Server for Component Function Session”
on page 2-14
Start MATLAB Server for Component Function Session

Start the MATLAB server as follows:
1 Start MATLAB.
2 In the MATLAB Command Window, call the hdldaemon function with

property name/property value pairs that specify whether the HDL Verifier
software is to perform the following tasks:
• Use shared memory or TCP/IP socket communication
• Return time values in seconds or as 64-bit integers
See hdldaemon reference documentation for when and how to specify property
name/property value pairs and for more examples of using hdldaemon.
The communication mode that you specify (shared memory or TCP/IP sockets)
must match what you specify for the communication mode when you initialize
the HDL simulator for use with a MATLAB cosimulation session using the
matlabtb or matlabcp function. In addition, if you specify TCP/IP socket
mode, the socket port that you specify with hdldaemon and matlabtb or
matlabcp must match. See “TCP/IP Socket Ports” on page 8-95 for more
information .

modules and clients. However, your code must track the I/O associated with
each entity or client.
2-13
Note You cannot begin an HDL Verifier transaction between MATLAB and
the HDL simulator from MATLAB. The MATLAB server simply responds to
function call requests that it receives from the HDL simulator.
Example of Starting MATLAB Server for Component

Function Session
The following command specifies using socket communication on port 4449
and a 64-bit time resolution format for the MATLAB function’s output ports.
hdldaemon('socket', 4449, 'time', 'int64')
2-14
Start HDL Simulator
Start HDL Simulator

In this section...
“Start HDL Simulator for Component Session” on page 2-15
“Load HDL Design for Visualization” on page 2-15
Start HDL Simulator for Component Session

>>vsim
pages for details.
(ModelSim) and nclaunch (Cadence Incisive) — are on the system path. See
Load HDL Design for Visualization

After you start the HDL simulator from MATLAB with a call to vsim or
nclaunch, load an instance of an HDL module for verification or visualization
with the function vsimmatlab or hdlsimmatlab. At this point, you should
have coded and compiled your HDL model. Issue the function vsimmatlab or
hdlsimmatlab for each instance of an entity or module in your model that you
want to cosimulate. For example (for use with Incisive):
hdlsimmatlab work.osc_top
This command loads the HDL Verifier library, opens a simulation workspace
for osc_top, and display a series of messages in the HDL simulator command
window as the simulator loads the entity (see example for remaining code).
2-15
Bind Component Function Calls With matlabcp

In this section...
“Invoke MATLAB Component Function Command matlabcp” on page 2-16
“Bind HDL Module Component to MATLAB Component Function” on page
2-18
Invoke MATLAB Component Function Command

matlabcp
You invoke matlabcp by issuing the command in the HDL simulator. See
the Examples section of the matlabcp reference page for several examples
of invoking matlabcp.
Be sure to follow the path specifications for MATLAB component function

sessions when invoking matlabcp, as explained in “Specify HDL Signal/Port
and Module Paths for MATLAB Component Function Cosimulation” on page
2-16.
For instructions in issuing the matlabcp command, see “Run MATLAB Test
Bench Simulation” on page 1-32.
Specify HDL Signal/Port and Module Paths for MATLAB

Component Function Cosimulation
HDL Verifier software has specific requirements for specifying HDL design
hierarchy, the syntax of which is described in the following sections: one for
Verilog at the top level, and one for VHDL at the top level. Do not use a file
name hierarchy in place of the design hierarchy name.
The rules stated in this section apply to signal/port and module path
specifications for MATLAB cosimulation sessions. Other specifications may
work but the HDL Verifier software does not officially recognize nor support
them.
In the following example:
matlabtb u_osc_filter -mfunc oscfilter
2-16
u_osc_filter is the top-level component. If you specify a subcomponent,

you must follow valid module path specifications for MATLAB cosimulation
sessions.
Path Specifications for MATLAB Link Sessions with Verilog Top Level.
• The path specification must start with a top-level module name.

module.
top.port_or_sig
top
top/sub
top.sub1.sub2
:
:sub
Path Specifications for MATLAB Link Sessions with VHDL Top Level.
• The path specification can include the top-level module name, but you do
not have to include it.
2-17
module.
Examples for ModelSim and Incisive Users
top.port_or_sig
/sub/port_or_sig
top
top/sub
top.sub1.sub2
:
:sub
Bind HDL Module Component to MATLAB Component

Function
By default, the HDL Verifier software assumes that the name for a MATLAB
function matches the name of the HDL module that the function verifies.
When you create a test bench or component function that has a different name
than the design under test, you must associate the design with the MATLAB
function using the -mfunc argument to matlabtb. This argument associates
the HDL module instance to a MATLAB function that has a different name
from the HDL instance.
2-18
For more information on the -mfunc argument and for a full list of matlabtb
parameters, see the matlabtb function reference.
For details on MATLAB function naming guidelines, see "MATLAB

Programming Tips" on files and file names in the MATLAB documentation.
Example of Binding Test Bench and Component Function Calls

In this first example, you form an association between the inverter_vl
component and the MATLAB test bench function inverter_tb by invoking the
function matlabtb with the -mfunc argument when you set up the simulation.
matlabtb inverter_vl -mfunc inverter_tb
The matlabtb command instructs the HDL simulator to call back the
inverter_tb function when inverter_vl executes in the simulation.
In this second example, you bind the model osc_top.u_osc_filter to the

component function oscfilter:
matlabcp osc_top.u_osc_filter -mfunc oscfilter
When the HDL simulator calls the oscfilter callback, the function knows to
operate on the model osc_top.u_osc_filter.
2-19
Schedule Options for a Component Session

In this section...
“About Scheduling Options for Component Sessions” on page 2-20
“Schedule Component Session Using matlabcp Arguments” on page 2-20
“Schedule Component Functions Using the tnext Parameter” on page 2-21
About Scheduling Options for Component Sessions

There are two ways to schedule the invocation of a MATLAB function:
• Using the arguments to the HDL Verifier function matlabtb or matlabcp

• Inside the MATLAB function using the tnext parameter
The two types of scheduling are not mutually exclusive. You can combine
the matlabtb or matlabcp timing arguments and the tnext parameter of a
MATLAB function to schedule test bench or component session callbacks.
Schedule Component Session Using matlabcp

Arguments
By default, the HDL Verifier software invokes a MATLAB test bench
or component function once (at the time that you make the call to
matlabtb/matlabcp). If you want to apply more control, and execute the
MATLAB function more than once, use the command scheduling options.
With these options, you can specify when and how often the HDL Verifier
software invokes the relevant MATLAB function. If applicable, modify the
function or specify timing arguments when you begin a MATLAB test bench
or component function session with the matlabtb/matlabcp function.
You can schedule a MATLAB test bench or component function to execute

using the command arguments under any of the following conditions:
• Discrete time values—Based on time specifications that can also include

repeat intervals and a stop time
• Rising edge—When a specified signal experiences a rising edge
2-20
- VHDL: Rising edge is {0 or L} to {1 or H}.

- Verilog: Rising edge is the transition from 0 to x, z, or 1, and from x
or z to 1.
• Falling edge—When a specified signal experiences a falling edge
- VHDL: Falling edge is {1 or H} to {0 or L}.
- Verilog: Falling edge is the transition from 1 to x, z, or 0, and from
x or z to 0.
• Signal state change—When a specified signal changes state, based on a
list using the -sensitivity argument to matlabtb.
Schedule Component Functions Using the tnext

Parameter
You can control the callback timing of a MATLAB function by using that
function’s tnext parameter. This parameter passes a time value to the HDL
simulator, and the value gets added to the simulation schedule for that
function. If the function returns a null value ([]) , the software does not add
any new entries to the schedule.
You can set the value of tnext to a value of type double or int64. Specify
double to express the callback time in seconds. For example, to schedule
a callback in 1 ns, specify::
tnext = 1e-9
Specify int64 to convert to an integer multiple of the current HDL simulator

time resolution limit. For example: if the HDL simulator time precision is 1
ns, to schedule a callback at 100 ns, specify:
tnext=int64(100)
2-21
Note The tnext parameter represents time from the start of the simulation.
Therefore, tnext must always be greater than tnow. If it is less, the software
does not schedule a callback.
For more information on tnext and the function prototype, see “MATLAB
Function Syntax and Function Argument Definitions” on page 8-40.
Examples of Scheduling with tnext

In this first example, each time the HDL simulator calls the test bench
function (via HDL Verifier), tnext schedules the next callback to the MATLAB
function for 1 ns later, relative to the current simulation time:
tnext = [];
.
.
.
tnext = tnow+1e-9;
Using tnext you can dynamically decide the callback scheduling based on
criteria specific to the operation of the test bench. For example, you can decide
to stop scheduling callbacks when a data signal has a certain value:
if qsum == 17,
qsum = 0;
disp('done');
testisdone = 1;
return;
end
This next example demonstrates scheduling a component session using tnext.

In the Oscillator example, the oscfilter function calculates a time interval
at which the HDL simulator calls the callbacks. The component function
calculates this interval on the first call to oscfilter and stores the result in the
variable fastestrate. The variable fastestrate represents the sample period of
the fastest oversampling rate supported by the filter. The function derives
this rate from a base sampling period of 80 ns.
2-22
The following assignment statement sets the timing parameter tnext. This
parameter schedules the next callback to the MATLAB component function,
relative to the current simulation time (tnow).
tnext = tnow + fastestrate;
The function returns a new value for tnext each time the HDL simulator
calls the function.
2-23
Run MATLAB Component Function Simulation

In this section...
“Process for Running MATLAB Component Function Cosimulation” on
page 2-24
“Check MATLAB Server’s Link Status for Component Cosimulation” on
page 2-24
“Run Component Function Cosimulation” on page 2-25
“Apply Stimuli to Component Function with force Command” on page 2-29
“Restart Component Simulation” on page 2-31
Process for Running MATLAB Component Function

Cosimulation
To start and control the execution of a simulation in the MATLAB
environment, perform the following steps:
1 “Check MATLAB Server’s Link Status for Test Bench Cosimulation” on

page 1-32
3 “Apply Stimuli to Test Bench Session with force Command” on page 1-37
4 “Restart Test Bench Simulation” on page 1-39 (if applicable).
Check MATLAB Server’s Link Status for Component

Cosimulation
The first step to starting an HDL simulator and MATLAB test bench or
component function session is to check the MATLAB server’s link status. Is
the server running? If the server is running, what mode of communication
and, if applicable, what TCP/IP socket port is the server using for its links?
You can retrieve this information by using the MATLAB function hdldaemon
with the 'status' option. For example:
hdldaemon('status')
2-24
The function displays a message that indicates whether the server is running
and, if it is running, the number of connections it is handling. For example:
HDLDaemon socket server is running on port 4449 with 0 connections
If the server is not running, the message reads
See the Options: Inputs section in the hdldaemon reference documentation

for information on determining the mode of communication and the TCP/IP
socket in use.
Run Component Function Cosimulation

You can run a cosimulation session using both the MATLAB and HDL
simulator GUIs (typical) or, to reduce memory demand, you can run the
cosimulation using the command line interface (CLI) or in batch mode.
• “Cosimulation with MATLAB Using the HDL Simulator GUI” on page 1-33
• “Cosimulation with MATLAB Using the Command Line Interface (CLI)”
on page 1-35
• “Cosimulation with MATLAB Using Batch Mode” on page 1-36
Cosimulation with MATLAB Using the HDL Simulator GUI

These steps describe a typical sequence for running a simulation interactively
from the main HDL simulator window:
1 Set breakpoints in the HDL and MATLAB code to verify and analyze
simulation progress.
How you set breakpoints in the HDL simulator will vary depending on
what simulator application you are using.
In MATLAB, there are several ways you can set breakpoints; for example,
by using the Set/Clear Breakpoint button on the toolbar.
2 Issue matlabtb command at the HDL simulator prompt.
2-25
When you begin a specific test bench or component session, you specify
parameters that identify the following information:
• The mode and, if applicable, TCP/IP data for connecting to a MATLAB
server (see matlabtb reference)
• The MATLAB function that is associated with and executes on behalf
of the HDL instance (see “Bind HDL Module Component to MATLAB
Test Bench Function” on page 1-26)
• Timing specifications and other control data that specifies when the
module’s MATLAB function is to be called (see “Schedule Options for a
Test Bench Session” on page 1-28).
For example:
hdlsim> matlabtb osc_top -sensitivity /osc_top/sine_out

-socket 4448 -mfunc hosctb
3 Start the simulation by entering the HDL simulator run command.
The run command offers a variety of options for applying control over how
a simulation runs (refer to your HDL simulator documentation for details).
For example, you can specify that a simulation run for several time steps.
The following command instructs the HDL simulator to run the loaded
simulation for 50000 time steps:
run 50000
4 Step through the simulation and examine values.
How you step through the simulation in the HDL simulator will vary
depending on what simulator application you are using.
In MATLAB, there are several ways you can step through code; for
example, by clicking the Step toolbar button.
5 When you block execution of the MATLAB function, the HDL simulator
also blocks and remains blocked until you clear all breakpoints in the
function’s code.
6 Resume the simulation, as desired.
2-26
How you resume the simulation in the HDL simulator will vary depending
on what simulator application you are using.
In MATLAB, there are several ways you can resume the simulation; for
example, by clicking the Continue toolbar button.
The following HDL simulator command resumes a simulation:
run -continue
For more information on HDL simulator and MATLAB debugging features,

see the HDL simulator documentation and MATLAB online help or
documentation.
Cosimulation with MATLAB Using the Command Line Interface

(CLI)
The Tcl command you build to pass to the HDL simulator launch command
must contain the run command or no cosimulation will take place.
2-27
tclcmd = { ['cd ',projdir],...

['exec ncvlog ' srcfile],...
'exec ncelab -access +wc lowpass_filter',...
['hdlsimmatlab -gui lowpass_filter ', ...
' -input "{@matlabtb lowpass_filter 10ns -repeat 10ns ...
-mfunc filter_tb_incisive}"',...
' -input "{@force lowpass_filter.clk_enable 1 -after 0ns}"',...
' -input "{@force lowpass_filter.reset 1 -after 0ns 0 -after 22ns}"',...
' -input "{@force lowpass_filter.clk 1 -after 0ns 0 -after 5ns ...
-repeat 10ns}"',...
' -input "{@deposit lowpass_filter.filter_in 0}"',...
]};
Specify CLI mode with vsim (Mentor Graphics ModelSim)

'vlib work',... %create library (if applicable)
'force /osc_top/clk_enable 1 0',...
'force /osc_top/reset 1 0, 0 120 ns',...
'force /osc_top/clk 1 0 ns, 0 40 ns -r 80ns',...
};
Cosimulation with MATLAB Using Batch Mode

GUI.
2-28

follows:

Apply Stimuli to Component Function with force

Command
After you establish a connection between the HDL simulator and MATLAB,
you can then apply stimuli to the test bench or component cosimulation
environment. One way of applying stimuli is through the iport parameter of
the linked MATLAB function. This parameter forces signal values by deposit.
Other ways to apply stimuli include issuing force commands in the HDL
simulator main window (for ModelSim, you can also use the Edit > Clock
option in the ModelSim Signals window).
For example, consider the following sequence of force commands:
• Incisive
2-29
force osc_top.clk_enable 1 -after 0ns

force osc_top.reset 0 -after 0ns 1 -after 40ns 0 -after 120ns
force osc_top.clk 1 -after 0ns 0 -after 40ns -repeat 80ns
• ModelSim
VSIM n> force clk 0 0 ns, 1 5 ns -repeat 10 ns

VSIM n> force clk_en 1 0
VSIM n> force reset 0 0
These commands drive the following signals:
• The clk signal to 0 at 0 nanoseconds after the current simulation time

and to 1 at 5 nanoseconds after the current HDL simulation time. This
cycle repeats starting at 10 nanoseconds after the current simulation
time, causing transitions from 1 to 0 and 0 to 1 every 5 nanoseconds, as
the following diagram shows.
1
0
...
t 0 5 10 20 30
For example,
force /foobar/clk 0 0, 1 5 -repeat 10
• The clk_en signal to 1 at 0 nanoseconds after the current simulation time.

• The reset signal to 0 at 0 nanoseconds after the current simulation time.
Incisive Users: Using HDL to Code Clock Signals Instead of

the force Command
You should consider using HDL to code clock signals as force is a lower
performance solution in the current version of Cadence Incisive simulators.
The following are ways that a periodic force might be introduced:
• Via the Clock pane in the HDL Cosimulation block

• Via pre/post Tcl commands in the HDL Cosimulation block
2-30
• Via a user-input Tcl script to ncsim
All three approaches may lead to performance degradation.
Restart Component Simulation

Because the HDL simulator issues the service requests during a MATLAB
cosimulation session, you must restart the session from the HDL simulator.
To restart a session, perform the following steps:
2 Reload HDL design elements and reset the simulation time to zero.
3 Reissue the matlabtb or matlabcp command.
Note To restart a simulation that is in progress, issue a break command and

end the current simulation session before restarting a new session.
2-31
Stop Component Simulation

When you are ready to stop a test bench or component session, it is best to do
so in an orderly way to avoid possible corruption of files and to see that all
application tasks shut down cleanly. You should stop a session as follows:
2 Halt the simulation. You must quit the simulation at the HDL simulator
side or MATLAB may hang until the simulator is quit.
3 Close your project.
4 Exit the HDL simulator, if you are finished with the application.
5 Quit MATLAB, if you are finished with the application. If you want to
shut down the server manually, stop the server by calling hdldaemon with
the 'kill' option:
hdldaemon('kill')
For more information on closing HDL simulator sessions, see the HDL
simulator documentation.
2-32
3

MATLAB System Object
• “Create a MATLAB System Object” on page 3-2

• “Verify Viterbi Decoder Using MATLAB System Object and Mentor
Graphics ModelSim” on page 3-3
3 HDL Cosimulation Using MATLAB System Object
Create a MATLAB System Object

The HDL Verifier software provides a means for verifying HDL modules using
the HDL Cosimulation System object™. You can use the System object as a
test bench or you can use it to represent a component still under design. You
can use the Cosimulation Wizard to create an HDL Cosimulation System
object from existing HDL code or you can create and populate the System
object manually.
The easiest way to create a test bench System object is by using existing
HDL code and the HDL Cosimulation Wizard. You can also create an HDL
Cosimulation System object manually. In the following section,“Verify Viterbi
Decoder Using MATLAB System Object and Mentor Graphics ModelSim” on
page 3-3, you will find an example of how to use the HDL Cosimulation System
object and ModelSim to cosimulate a Viterbi decoder implanted in VHDL.
You can find out more about the HDL Cosimulation Wizard and creating
System objects within these topics:
• “Import HDL Code With the HDL Cosimulation Wizard” on page 7-2
This chapter contains an example for converting existing HDL Code to a
System object test bench using the HDL Cosimulation Wizard.
• General information about System objects:
- “Create System Objects” on page 9-2
- “Set Up System Objects” on page 9-4
- “Process Data Using System Objects” on page 9-7
- “Tuning System object Properties in MATLAB” on page 9-10
You can also refer to the section on “Find Help and Examples for System
Objects” on page 9-12 for more general assistance.
3-2
Verify Viterbi Decoder Using MATLAB System Object and Mentor Graphics ModelSim
Verify Viterbi Decoder Using MATLAB System Object and

Mentor Graphics ModelSim
This example shows you how to use MATLAB® System objects and Mentor
Graphics® ModelSim® to cosimulate a Viterbi decoder implemented in VHDL.
Set Simulation Parameters and Instantiate Communication System Objects
The following code sets up the simulation parameters and instantiates

the system objects that represent the channel encoder, BPSK modulator,
AWGN channel, BPSK demodulator, and error rate calculator. Those objects
comprise the system around the Viterbi decoder and can be thought of as the
test bed for the Viterbi HDL implementation.
EsNo = 0; % Energy per symbol to noise power spectrum density ratio in dB

FrameSize = 1024; % Number of bits in each frame
% Convolution Encoder
hConEnc = comm.ConvolutionalEncoder;
% BPSK Modulator
hMod = comm.BPSKModulator;
% AWGN channel
hChan = comm.AWGNChannel('NoiseMethod', ...
'Signal to noise ratio (Es/No)',...
'SamplesPerSymbol',1,...
'EsNo',EsNo);
% BPSK demodulator
hDemod = comm.BPSKDemodulator('DecisionMethod','Log-likelihood ratio',...
'Variance',0.5*10^(-EsNo/10));
% Error Rate Calculator
hError = comm.ErrorRate('ComputationDelay',100,'ReceiveDelay', 58);
Instantiate the Cosimulation System Object
The hdlcosim function returns an HDL cosimulation System object, which

represents the HDL implementation of the Viterbi decoder in this simulation
system.
hDec = hdlcosim('InputSignals', {'/viterbi_block/In1','/viterbi_block/In

'OutputSignals', {'/viterbi_block/Out1'}, ...
3-3
'OutputSigned', false, ...

'OutputFractionLengths', 0, ...
'TCLPreSimulationCommand', 'force /viterbi_block/clk_ena
'TCLPostSimulationCommand', 'echo "done";', ...
'PreRunTime', {10,'ns'}, ...
'Connection', {'Shared'}, ...
'SampleTime', {10,'ns'});
Launch HDL Simulator
The vsim command launches ModelSim. The launched ModelSim session

compiles the HDL design and loads the HDL simulation. You are ready to
perform cosimulation when the HDL simulation is fully loaded in ModelSim.
disp('Waiting for HDL simulator to launch ...');

vsim('tclstart',viterbi_tclcmds_modelsim('vsimmatlabsysobj'));
processid = pingHdlSim(240);
disp('Ready for cosimulation ...');
Run Cosimulation
This example simulates the BPSK communication system in MATLAB

incorporating the Viterbi decoder HDL implementation via the cosimulation
System object. This section of the code calls the processing loop to process the
data frame-by-frame with 1024 bits in each data frame.
for counter = 1:20480/FrameSize

data = randi([0 1],FrameSize,1);
encodedData = step(hConEnc, data);
modSignal = step(hMod, encodedData);
receivedSignal = step(hChan, modSignal);
demodSignalSD = step(hDemod, receivedSignal);
quantizedValue = fi(4-demodSignalSD,0,3,0);
input1 = quantizedValue(1:2:2*FrameSize);
input2 = quantizedValue(2:2:2*FrameSize);
receivedBits = step(hDec,input1, input2);
errors = step(hError, data, double(receivedBits));
end
Display the Bit-Error Rate
3-4
Verify Viterbi Decoder Using MATLAB System Object and Mentor Graphics ModelSim
The Bit-Error Rate is displayed for the Viterbi decoder.
sprintf('Bit Error Rate is %d\n',errors(1))
Destroy Cosimulation System Object to Release HDL Simulator
The HDL simulator is unblocked when the HDL cosimulation system object is
destroyed in MATLAB. Close the ModelSim session manually.
clear hDec;
% This concludes the "Verifying Viterbi Decoder Using MATLAB System Object
% and ModelSim" example.
3-5
3-6
4
Simulink Test Bench for

HDL Component
• “Simulink as a Test Bench” on page 4-2

• “Simulink Test Bench Cosimulation” on page 4-7
• “Create Simulink Model for Test Bench Cosimulation” on page 4-8
• “Code an HDL Component” on page 4-9
• “Add HDL Cosimulation Block to Model” on page 4-14
• “Define HDL Cosimulation Block Interface” on page 4-16
• “Run a Test Bench Cosimulation Session” on page 4-44
• “Verify HDL Model with Simulink Test Bench” on page 4-51
• “Test Bench Automatic Verification with Simulink” on page 4-70
4 Simulink Test Bench for HDL Component
Simulink as a Test Bench

In this section...
“Communications During Test Bench Cosimulation” on page 4-2
“HDL Cosimulation Block Features for Test Bench Simulation” on page 4-5
Communications During Test Bench Cosimulation

When you link the HDL simulator with a Simulink® application, the simulator
functions as the server, as shown in the following figure.
Link
HDL Simulator Request Simulink
In Out Client
Server Response
Out In
In this case, the HDL simulator responds to simulation requests it receives

from cosimulation blocks in a Simulink model. You begin a cosimulation
session from Simulink. After a session is started, you can use Simulink
and the HDL simulator to monitor simulation progress and results. For
example, you might add signals to a wave window to monitor simulation
timing diagrams.
As the following figure shows, multiple cosimulation blocks in a Simulink

model can request the service of multiple instances of the HDL simulator,
using unique TCP/IP socket ports.
HDL Simulator
Server
Port Link
4449 Simulink
Link Client
Port
4448
HDL Simulator
Server
4-2
When you link the HDL simulator with a Simulink application, the simulator
functions as the server. Using the HDL Verifier communications interface,
an HDL Cosimulation block cosimulates a hardware component by applying
input signals to and reading output signals from an HDL model under
simulation in the HDL simulator.
This figure shows a sample Simulink model that includes an HDL

Cosimulation block. The connection is using shared memory.
The HDL Cosimulation block models a Manchester receiver that is coded in

HDL. Other blocks and subsystems in the model include the following:
• Frequency Error Range block, Frequency Error Slider block, and Phase
Event block
• Manchester encoder subsystem
• Data alignment subsystem
• Inphase/Quadrature (I/Q) capture subsystem
• Error Rate Calculation block from the Communications System Toolbox™
software
• Bit Errors block
4-3
• Data Scope block

• Discrete-Time Scatter Plot Scope block from the Communications System
Toolbox software
For information on getting started with Simulink software, see the Simulink
online help or documentation.
How Simulink Drives Cosimulation Signals

Although you can bind the output ports of an HDL Cosimulation block to
any signal in an HDL model hierarchy, you must use some caution when
connecting signals to input ports. You want to verify that the signal you are
binding to does not have other drivers. If it does, use resolved logic types;
otherwise you may get unpredictable results.
If you need to use a signal that has multiple drivers and it is resolved (for
example, it is of VHDL type STD_LOGIC) , Simulink applies the resolution
function at each time step defined by the signal’s Simulink sample rate.
Depending on the other drivers, the Simulink value may or may not get
applied. Furthermore, Simulink has no control over signal changes that occur
between its sample times.
Note Verify that signals used in cosimulation have read/write access. You
can check read/write access through the HDL simulator—see HDL simulator
This rule applies to all signals on the Ports, Clocks, and Simulation panes
and to signals added to the model in any other manner.
Multirate Signals During Test Bench Cosimulation

HDL Verifier software supports the use of multirate signals, signals that are
sampled or updated at different rates, in a single HDL Cosimulation block.
An HDL Cosimulation block exchanges data for each signal at the Simulink
sample rate for that signal. For input signals, an HDL Cosimulation block
accepts and honors all signal rates.
4-4
The HDL Cosimulation block also lets you specify an independent sample
time for each output port. You must explicitly set the sample time for each
output port, or accept the default. Using this setting lets you control the
rate at which Simulink updates an output port by reading the corresponding
signal from the HDL simulator.
Continuous Time Signals

Use the Simulink Zero-Order Hold block to apply a zero-order hold (ZOH) on
continuous signals that are driven into an HDL Cosimulation block.
HDL Cosimulation Block Features for Test Bench

Simulation
The HDL Verifier HDL Cosimulation Block links hardware components that
are concurrently simulating in the HDL simulator to the rest of a Simulink
model.
You can link Simulink and the HDL simulator in two possible ways:
• As a single HDL Cosimulation block fitted into the framework of a larger

system-oriented Simulink model.
• As a Simulink model made up of a collection of HDL Cosimulation blocks,
each representing a specific hardware component.
The block mask contains panels for entering port and signal information,
setting communication modes, adding clocks (Incisive and ModelSim only),
specifying pre- and post-simulation Tcl commands (Incisive and ModelSim
only), and defining the timing relationship.
After you code one of your model’s components in VHDL or Verilog and
simulate it in the HDL simulator environment, you integrate the HDL
representation into your Simulink model as an HDL Cosimulation block.
There is one block for each supported HDL simulator. These blocks are
located in the Simulink Library, within the HDL Verifier block library. As
an example, the block for use with Mentor Graphics ModelSim is shown in
the next figure.
4-5
You configure an HDL Cosimulation block by specifying values for parameters

in a block parameters dialog box. The HDL Cosimulation block parameters
dialog box consists of tabbed panes that specify the following information:
• Ports Pane: Block input and output ports that correspond to signals,
including internal signals, of your HDL design, and an output sample time.
• Connection Pane: Type of communication and related settings to be used
for exchanging data between simulators.
• Timescales Pane: The timing relationship between Simulink software
and the HDL simulator.
• Clocks Pane (Incisive and ModelSim only): Optional rising-edge and
falling-edge clocks to apply to your model.
• Simulation Pane (Incisive and ModelSim only): Tcl commands to run
before and after a simulation.
For more detail on each of these panes, see the HDL Cosimulation reference
page.
4-6
Simulink Test Bench Cosimulation
Simulink Test Bench Cosimulation

The following workflow steps describe how to cosimulate an HDL design using
Simulink software as a test bench.
1 Create Simulink model. See “Create Simulink Model for Test Bench
Cosimulation” on page 4-8.
2 Code HDL module. Compile, elaborate, and simulate model in HDL

simulator. See “Code an HDL Component” on page 4-9.
3 Start HDL simulator for use with MATLAB and Simulink and load HDL
Verifier libraries. See “Start HDL Simulator” on page 4-12
4 Add HDL Cosimulation block. See “Add HDL Cosimulation Block to Model”
on page 4-14.
5 Define HDL Cosimulation block interface. See “Define HDL Cosimulation

Block Interface” on page 4-16.
7 Start simulation in HDL simulator. See “Run a Test Bench Cosimulation

Session” on page 4-44.
4-7
Create Simulink Model for Test Bench Cosimulation

In this section...
“Create Simulink Model” on page 4-8
“Run Test Bench Hardware Model in Simulink” on page 4-8
“Add Value Change Dump (VCD) File (Optional)” on page 4-8
Create Simulink Model

Create a Simulink test bench model by adding Simulink blocks from the
Simulink Block libraries. For help with creating a Simulink model, see the
Simulink documentation.
Run Test Bench Hardware Model in Simulink

If you design a Simulink model first, run and test your model thoroughly
before replacing or adding hardware model components as HDL Verifier
Cosimulation blocks.
Add Value Change Dump (VCD) File (Optional)

You might want to add a VCD file to log changes to variable values during a
simulation session. See “Add a Value Change Dump (VCD) File” on page 6-2
for instructions on adding the To VCD File block.
4-8
Code an HDL Component

In this section...
“Overview to Coding HDL Components for Simulink Test Bench Sessions”
on page 4-9
“Specify Port Direction Modes in the HDL Component for Test Bench Use”
on page 4-9
“Specify Port Data Types in the HDL Component for Test Bench Use” on
page 4-10
“Compile and Elaborate HDL Design for Test Bench Use” on page 4-11
Overview to Coding HDL Components for Simulink

Test Bench Sessions
The HDL Verifier interface passes all data between the HDL simulator and
Simulink as port data. The HDL Verifier software works with any existing
Simulink verification, you should consider the types of data to be shared
between the two environments and the direction modes.
Specify Port Direction Modes in the HDL Component

for Test Bench Use

Mode... Mode...
MATLAB function
a MATLAB function
function
4-9
Specify Port Data Types in the HDL Component for

Test Bench Use
• reg
• integer
• wire


and BIT_VECTOR
• REAL
• TIME
CHARACTER
4-10

in cosimulation
Port Data Types for Verilog Entities. In your module definition, you must
define each port that you plan to test with MATLAB with a Verilog port
data type that is supported by the HDL Verifier software. The interface can
convert data of the following Verilog port types to comparable MATLAB types:
• reg
• integer
• wire
Compile and Elaborate HDL Design for Test Bench Use

Refer to the HDL simulator documentation for instruction in compiling and
elaborating the HDL design.
4-11
Start HDL Simulator

In this section...
“Start HDL Simulator from MATLAB” on page 4-12
“Load Instance of HDL Module for Test Bench Cosimulation” on page 4-12
Start HDL Simulator from MATLAB

>>vsim
Note that if both tools (MATLAB and the HDL simulator) are not running on
the same system, you must start the HDL simulator manually and load the
HDL Verifier libraries yourself. See “HDL Verifier Libraries” on page 8-11.
pages for details.
Load Instance of HDL Module for Test Bench

Cosimulation
Incisive users load an instance of the HDL module for cosimulation using the
hdlsimulink function. ModelSim users do the same using the vsimulink
function.
4-12
Start HDL Simulator
Example of loading HDL Module instance — Incisive users
After you start the HDL simulator from MATLAB, load an instance of an
HDL module for cosimulation with the function hdlsimulink. Issue the
command for each instance of an HDL module in your model that you want to
cosimulate.
For example:
hdlsimulink work.manchester
Example of loading HDL Module instance — ModelSim users
After you start the HDL simulator from MATLAB, load an instance of an HDL
module for cosimulation with the function vsimulink. Issue the command for
each instance of an HDL module in your model that you want to cosimulate.
For example:
vsimulink work.manchester
This command opens a simulation workspace for manchester and displays a

series of messages in the HDL simulator command window as the simulator
loads the packages and architectures for the HDL module.
4-13
Add HDL Cosimulation Block to Model

In this section...
“Insert HDL Cosimulation Block” on page 4-14
“Connect Block Ports” on page 4-15
Insert HDL Cosimulation Block

After you code one of your model’s components in VHDL or Verilog
and simulate it in the HDL simulator environment, integrate the HDL
representation into your Simulink model as an HDL Cosimulation block by
performing the following steps:
1 Open your Simulink model, if it is not already open.
2 Delete the model component that the HDL Cosimulation block is to replace.
3 In the Simulink Library Browser, click the HDL Verifier block library. You
can then select the block library for your supported HDL simulator. Select
either the Mentor Graphics® ModelSim HDL Cosimulation block, or the
Cadence Incisive HDL Cosimulation block, as shown below.
4-14
4 Copy the HDL Cosimulation block icon from the Library Browser to your
model. Simulink creates a link to the block at the point where you drop
the block icon.
Connect Block Ports

Connect any HDL Cosimulation block ports to the applicable block ports in
your Simulink model.
• To model a sink device, configure the block with inputs only.

• To model a source device, configure the block with outputs only.
4-15
Define HDL Cosimulation Block Interface

In this section...
“Open HDL Cosimulation Block Interface” on page 4-16
“Map HDL Signals to Block Ports” on page 4-17
“Specify Signal Data Types” on page 4-32
“Configure Simulink and HDL Simulator Timing Relationship” on page 4-32
“Configure Communication Link in the HDL Cosimulation Block” on page
4-35
“Specify Pre- and Post-Simulation Tcl Commands with HDL Cosimulation
Block Parameters Dialog Box” on page 4-38
“Programmatically Control Block Parameters” on page 4-41
Open HDL Cosimulation Block Interface

To open the block parameters dialog box for the HDL Cosimulation block,
double-click the block icon. Simulink displays the following Block Parameters
dialog box (as an example, the dialog box for the HDL Cosimulation block for
use with ModelSim is shown below).
4-16
Map HDL Signals to Block Ports

• “Specify HDL Signal/Port and Module Paths for Cosimulation” on page 4-18
• “Get Signal Information from HDL Simulator” on page 4-20
• “Enter Signal Information Manually” on page 4-26
• “Control Output Port Directly by Value of Input Port” on page 4-31
The first step to configuring your HDL Verifier Cosimulation block is to map
signals and signal instances of your HDL design to port definitions in your
HDL Cosimulation block. In addition to identifying input and output ports,
4-17
you can specify a sample time for each output port. You can also specify a
fixed-point data type for each output port.
The signals that you map can be at any level of the HDL design hierarchy.
To map the signals, you can perform either of the following actions:
• Enter signal information manually into the Ports pane of the HDL
Cosimulation Block Parameters dialog box (see “Enter Signal Information
Manually” on page 4-26). This approach can be more efficient when
you want to connect a small number of signals from your HDL model
to Simulink.
• Use the Auto Fill button to have the HDL Cosimulation block obtain
signal information for you by transmitting a query to the HDL simulator.
This approach can save significant effort when you want to cosimulate
an HDL model that has many signals that you want to connect to your
Simulink model. However, in some cases, you will need to edit the signal
data returned by the query. See “Get Signal Information from HDL
Simulator” on page 4-20 for details.
Note Verify that signals used in cosimulation have read/write access. For
higher performance, you want to provide access only to those signals used
in cosimulation. This rule applies to all signals on the Ports, Clocks, and
Simulation panes, and to all signals added in any other manner.
Specify HDL Signal/Port and Module Paths for Cosimulation

These rules are for signal/port and module path specifications in Simulink.
Other specifications may work but are not explicitly or implicitly supported in
this or future releases.
HDL designs generally do have hierarchy; that is the reason for this syntax.
This specification does not represent a file name hierarchy.
Path specifications must follow the rules listed in the following sections:
• “Path Specifications for Simulink Cosimulation Sessions with Verilog Top

Level” on page 4-19
4-18
• “Path Specifications for Simulink Cosimulation Sessions with VHDL Top

Path Specifications for Simulink Cosimulation Sessions with Verilog

Top Level.
• Path specification must start with a top-level module name.

• Path specification can include "." or "/" path delimiters, but cannot include
a mixture.
module.
top.port_or_sig
top
top/sub
top.sub1.sub2
:
:sub
Path Specifications for Simulink Cosimulation Sessions with VHDL

Top Level.
• Path specification may include the top-level module name but it is not
required.
4-19
a mixture.
module.
top.port_or_sig
/sub/port_or_sig
top
top/sub
top.sub1.sub2
:
:sub
Get Signal Information from HDL Simulator

The Auto Fill button lets you begin an HDL simulator query and supply a
path to a component or module in an HDL model under simulation in the
HDL simulator. Usually, some change of the port information is required
after the query completes. You must have the HDL simulator running with
the HDL module loaded for Auto Fill to work.
The following example describes the required steps.
4-20
Note The example is based on a modified copy of the Manchester Receiver

model, in which all signals were first deleted from the Ports and Clocks
panes.
1 Open the block parameters dialog box for the HDL Cosimulation block.
Click the Ports tab. The Ports pane opens (as an example, the Ports
pane for the HDL Cosimulation block for use with ModelSim is shown
in the illustrations below).
4-21
Tip Delete all ports before performing Auto Fill to make sure that no
unused signal remains in the Ports list at any time.
2 Click the Auto Fill button. The Auto Fill dialog box opens.
This modal dialog box requests an instance path to a component or module

in your HDL model; here you enter an explicit HDL path into the edit
field. The path you enter is not a file path and has nothing to do with the
source files.
3 In this example, the Auto Fill feature obtains port data for a
VHDL component called manchester. The HDL path is specified as
/top/manchester (path specifications will vary depending on your
HDL simulator; see “Specify HDL Signal/Port and Module Paths for
Cosimulation” on page 4-18).
4 Click OK to dismiss the dialog box and the query is transmitted.
5 After the HDL simulator returns the port data, the Auto Fill feature enters
it into the Ports pane, as shown in the following figure (examples shown
for use with Cadence Incisive).
4-22
6 Click Apply to commit the port additions.
7 Delete unused signals from Ports pane and add Clock signal.
The preceding figure shows that the query entered clock, clock enable, and
reset ports (labeled clk, enable, and reset respectively) into the ports list.
Delete the enable and reset signals from the Ports pane, and add the clk
signal in the Clocks pane.
These actions result in the signals shown in the next figures.
4-23
4-24
8 Auto Fill returns default values for output ports:
• Sample time: 1
• Data type: Inherit
• Fraction length: Inherit
You may need to change these values as required by your model. In this
example, the Sample time should be set to 10 for all outputs. See also
“Specify Signal Data Types” on page 4-32.
9 Before closing the HDL Cosimulation block parameters dialog box, click
Apply to commit any edits you have made.
Observe that Auto Fill returned information about all inputs and outputs
for the targeted component. In many cases, this will include signals that
function in the HDL simulator but cannot be connected in the Simulink
model. You may delete any such entries from the list in the Ports pane if
they are unwanted. You can drive the signals from Simulink; you just have to
define their values by laying down Simulink blocks.
4-25
Note that Auto Fill does not return information for internal signals. If your
Simulink model needs to access such signals, you must enter them into the
Ports pane manually. For example, in the case of the Manchester Receiver
model, you would need to add output port entries for top/manchester/sync_i,
top/manchester/isum_i, and top/manchester/qsum_i, as shown in step 8.
Incisive and ModelSim users: Note that clk, reset, and clk_enable may be
in the Clocks and Simulation panes but they don’t have to be. These signals
can be ports if you choose to drive them explicitly from Simulink.
Note When you import VHDL signals using Auto Fill, the HDL simulator
returns the signal names in all capitals.
Enter Signal Information Manually

To enter signal information directly in the Ports pane, perform the following
steps:
1 In the HDL simulator, determine the signal path names for the HDL
signals you plan to define in your block. For example, in the ModelSim
simulator, the following wave window shows all signals are subordinate to
the top-level module manchester.
4-26
2 In Simulink, open the block parameters dialog box for your HDL
Cosimulation block, if it is not already open.
3 Select the Ports pane tab. Simulink displays the following dialog box
(example shown for use with Incisive).
4-27
In this pane, you define the HDL signals of your design that you want to
include in your Simulink block and set a sample time and data type for
output ports. The parameters that you should specify on the Ports pane
depend on the type of device the block is modeling as follows:
• For a device having both inputs and outputs: specify block input ports,
block output ports, output sample times and output data types.
For output ports, accept the default or enter an explicit sample time.
Data types can be specified explicitly, or set to Inherit (the default). In
the default case, the output port data type is inherited either from the
signal connected to the port, or derived from the HDL model.
• For a sink device: specify block output ports.
• For a source device: specify block input ports.
4-28
4 Enter signal path names in the Full HDL name column by double-clicking
on the existing default signal.
• Use HDL simulator path name syntax (as described in “Specify HDL
Signal/Port and Module Paths for MATLAB Test Bench Cosimulation”
on page 1-24).
• If you are adding signals, click New and then edit the default values.
Select either Input or Output from the I/O Mode column.
• If you want to, set the Sample Time, Data Type, and Fraction Length
parameters for signals explicitly, as discussed in the remaining steps.
When you have finished editing clock signals, click Apply to register your
changes with Simulink.
The following dialog box shows port definitions for an HDL Cosimulation
block. The signal path names match path names that appear in the HDL
simulator wave window (Incisive example shown).
4-29
Note When you define an input port, make sure that only one source is
set up to force input to that port. If multiple sources drive a signal, your
Simulink model may produce unpredictable results.
5 You must specify a sample time for the output ports. Simulink uses the
value that you specify, and the current settings of the Timescales pane,
to calculate an actual simulation sample time.
For more information on sample times in the HDL Verifier cosimulation

environment, see “Simulation Timescales” on page 8-74.
4-30
6 You can configure the fixed-point data type of each output port explicitly
if desired, or use a default (Inherited). In the default case, Simulink
determines the data type for an output port as follows:
If Simulink can determine the data type of the signal connected to the
output port, it applies that data type to the output port. For example,
the data type of a connected Signal Specification block is known by
back-propagation. Otherwise, Simulink queries the HDL simulator to
determine the data type of the signal from the HDL module.
To assign an explicit fixed-point data type to a signal, perform the following

steps:
a Select either Signed or Unsigned from the Data Type column.
b If the signal has a fractional part, enter the Fraction Length.
For example, if the model has an 8-bit signal with Signed data type and
a Fraction Length of 5, the HDL Cosimulation block assigns it the
data type sfix8_En5. If the model has an Unsigned 16-bit signal with no
fractional part (a Fraction Length of 0), the HDL Cosimulation block
assigns it the data type ufix16.
7 Before closing the dialog box, click Apply to register your edits.
Control Output Port Directly by Value of Input Port

Enabling direct feedthrough allows input port value changes to propagate to
the output ports in zero time, thus eliminating the possible delay at output
sample in HDL designs with pure combinational logic. Specify the option to
enable direct feedthrough on the Ports pane, as shown in the following figure.
4-31
For more about the direct feedthrough feature, see “Direct Feedthrough
Specify Signal Data Types

The Data Type and Fraction Length parameters apply only to output
signals. See Data Type and Fraction Length on the Ports pane description
of the HDL Cosimulation block.

Relationship
You configure the timing relationship between Simulink and the HDL
simulator by using the Timescales pane of the block parameters dialog box.
Before setting the Timescales parameters, read “Simulation Timescales” on
page 8-74 to understand the supported timing modes and the issues that will
determine your choice of timing mode.
You can specify either a relative or an absolute timing relationship between

Simulink and the HDL simulator in the Timescales pane, as described in the
HDL Cosimulation block reference.
Simulink and HDL Simulator Timing Relationship

The differences in the representation of simulation time can be reconciled in
one of two ways using the HDL Verifier interface:
• By defining the timing relationship manually (with Timescales pane)

When you define the relationship manually, you determine how many
femtoseconds, picoseconds, nanoseconds, microseconds, milliseconds,
seconds, or ticks in the HDL simulator represent 1 second in Simulink.
This quantity of HDL simulator time can be expressed in one of the

following ways:
- In relative terms (i.e., as some number of HDL simulator ticks). In
this case, the cosimulation is said to operate in relative timing mode.
4-32
The HDL Cosimulation block defaults to relative timing mode for

cosimulation. For more on relative timing mode, see “Relative Timing
Mode” on page 8-77.
- In absolute units (such as milliseconds or nanoseconds). In this case, the
cosimulation is said to operate in absolute timing mode. For more on
absolute timing mode, see “Absolute Timing Mode” on page 8-82.
For more on relative and absolute time, see “Simulation Timescales” on
page 8-74.
• By allowing HDL Verifier to define the timescale (with Timescales pane)
When you allow the link software to define the timing relationship, it
attempts to set the timescale factor between the HDL simulator and
Simulink to be as close as possible to 1 second in the HDL simulator = 1
second in Simulink. If this setting is not possible, the link product attempts
to set the signal rate on the Simulink model port to the lowest possible
number of HDL simulator ticks.
Before you begin, verify that the HDL simulator is running. HDL Verifier
software can get the resolution limit of the HDL simulator only when that
simulator is running.
You can choose to have HDL Verifier calculate a timescale while you are
setting the parameters on the block dialog by clicking the Timescale
option then clicking Determine Timescale Now or you can have HDL
Verifier calculate the timescale when simulation begins by selecting
Automatically determine timescale at start of simulation.
4-33
When you click Determine Timescale Now, HDL Verifier connects

Simulink with the HDL simulator so that it can use the HDL simulator
resolution to calculate the best timescale. You can accept the timescale
HDL Verifier suggests or you can make changes in the port list directly.
If you want to revert to the originally calculated settings, click Use
Suggested Timescale. If you want to view sample times for all ports in
the HDL design, select Show all ports and clocks.
4-34
If you select Automatically determine timescale at start of

simulation, you get the same dialog when the simulation starts in
Simulink. Make the same adjustments at that time, if applicable, that
you would if you clicked Determine Timescale Now when you were
configuring the block.
Configure Communication Link in the HDL

Cosimulation Block
You must select shared memory or socket communication (see “HDL
Cosimulation with MATLAB or Simulink”).
4-35
After you decide which type of communication, configure a block’s

communication link with the Connection pane of the block parameters
dialog box (example shown for use with ModelSim).
The following steps guide you through the communication configuration:
1 Determine whether Simulink and the HDL simulator are running on the
same computer. If they are, skip to step 4.
2 Clear the The HDL simulator is running on this computer check

box. (This check box defaults to selected.) Because Simulink and the HDL
simulator are running on different computers, HDL Verifier sets the
Connection method to Socket.
4-36
3 Enter the host name of the computer that is running your HDL simulation
(in the HDL simulator) in the Host name text field. In the Port number
or service text field, specify a valid port number or service for your
computer system. For information on choosing TCP/IP socket ports, see
“TCP/IP Socket Ports” on page 8-95. Skip to step 5.
4 If the HDL simulator and Simulink are running on the same computer,
decide whether you are going to use shared memory or TCP/IP sockets for
the communication channel. For information on the different modes of
communication, see “HDL Cosimulation with MATLAB or Simulink”.
If you choose TCP/IP socket communication, specify a valid port number

or service for your computer system in the Port number or service text
field. For information on choosing TCP/IP socket ports, see “TCP/IP Socket
Ports” on page 8-95.
If you choose shared memory communication, select the Shared memory

check box.
5 If you want to bypass the HDL simulator when you run a Simulink
simulation, use the Connection Mode options to specify what type of
simulation connection you want. Select one of the following options:
• Full Simulation: Confirm interface and run HDL simulation (default).
• Confirm Interface Only: Check HDL simulator for expected signal
names, dimensions, and data types, but do not run HDL simulation.
• No Connection: Do not communicate with the HDL simulator. The
HDL simulator does not need to be started.
With the second and third options, HDL Verifier software does not
communicate with the HDL simulator during Simulink simulation.
6 Click Apply.
The following example dialog box shows communication definitions for an

HDL Cosimulation block. The block is configured for Simulink and the HDL
simulator running on the same computer, communicating in TCP/IP socket
mode over TCP/IP port 4449.
4-37
Specify Pre- and Post-Simulation Tcl Commands with

HDL Cosimulation Block Parameters Dialog Box
You have the option of specifying Tcl commands to execute before and after
the HDL simulator simulates the HDL component of your Simulink model.
Tcl is a programmable scripting language supported by most HDL simulation
environments. Use of Tcl can range from something as simple as a one-line
puts command to confirm that a simulation is running or as complete as
a complex script that performs an extensive simulation initialization and
startup sequence. For example, you can use the Post- simulation command
field on the Simulation Pane to instruct the HDL simulator to restart at the
end of a simulation run.
4-38
Note for ModelSim Users After each simulation, it takes ModelSim time
to update the coverage result. To prevent the potential conflict between this
process and the next cosimulation session, add a short pause between each
successive simulation.
You can specify the pre-simulation and post-simulation Tcl commands

by entering Tcl commands in the Pre-simulation commands or
Post-simulation commands text fields in the Simulation pane of the HDL
Cosimulation block mask.
To specify Tcl commands, perform the following steps:
1 Select the Simulation tab of the Block Parameters dialog box. The dialog
box appears as follows (example shown for use with ModelSim).
4-39
The Pre-simulation commands text box includes a puts command for

reference purposes.
2 Enter one or more commands in the Pre-simulation command and

Post-simulation command text boxes. You can specify one Tcl command
per line in the text box or enter multiple commands per line by appending
each command with a semicolon (;), which is the standard Tcl concatenation
operator.
ModelSim DO Files
Alternatively, you can create a ModelSim DO file that lists Tcl commands
and then specify that file with the ModelSim do command as shown in
the following figure.
4-40
3 Click Apply.
Programmatically Control Block Parameters

One way to control block parameters is through the HDL Cosimulation
block graphical dialog box. However, you can also control blocks by
programmatically controlling the mask parameter values and the running of
simulations. Parameter values can be read using the Simulink get_param
function and written using the Simulink set_param function. All block
parameters have attributes that indicate whether they are:
4-41
• Tunable — The attributes can change during the simulation run.

• Evaluated — The parameter string value undergoes an evaluation to
determine its actual value used by the S-Function.
The HDL Cosimulation block does not have any tunable parameters; thus,
you get an error if you try to change a value while the simulation is running.
However, it does have a few evaluated parameters.
You can see the list of parameters and their attributes by performing
a right-mouse click on the block, selecting View Mask, and then the
Parameters tab. The Variable column shows the programmatic parameter
names. Alternatively, you can get the names programmatically by selecting
the HDL Cosimulation block and then typing the following commands at
the MATLAB prompt:
>> get_param(gcb, 'DialogParameters')
Some examples of using MATLAB to control simulations and mask parameter

values follow. Usually, the commands are put into a script or function file and
are called by several callback hooks available to the model developer. You can
place the code in any of these suggested locations, or anywhere you choose:
• In the model workspace, for example, View > Model Explorer > Simulink
Root > model_name > Model Workspace, option Data Source is set
to Model File.
• In a model callback, for example, File > Model Properties > Callbacks.
• A subsystem callback (right-mouse click on an empty subsystem and then
select Properties > Callbacks). Many of the HDL Verifier demos use
this technique to start the HDL simulator by placing MATLAB code in
the OpenFcn callback.
• The HDL Cosimulation block callback (right-mouse click on HDL
Cosimulation block, and then select Properties > Callbacks).
Example: Scripting the Value of the Socket Number for HDL

Simulator Communication
In a regression environment, you may need to determine the socket number
for the Simulink/HDL simulator connection during the simulation to avoid
4-42
collisions with other simulation runs. This example shows code that could
handle that task. The script is for a 32-bit Linux platform.
ttcp_exec = [matlabroot '/toolbox/shared/hdllink/scripts/ttcp_glnx'];

[status, results] = system([ttcp_exec ' -a']);
if ~s
parsed_result = textscan(results,'%s');
avail_port = parsed_result{1}{2};
else
error(results);
end
set_param('MyModel/HDL Cosimulation', 'CommPortNumber', avail_port);
4-43
Run a Test Bench Cosimulation Session

In this section...
“Set Simulink Model Configuration Parameters” on page 4-44
“Determine Available Socket Port Number” on page 4-46
“Check Connection Status” on page 4-46
“Run and Test Test Bench Cosimulation Model” on page 4-46
“Avoid Race Conditions in HDL Simulation with Test Bench Cosimulation
and the HDL Verifier HDL Cosimulation Block” on page 4-49
Set Simulink Model Configuration Parameters

When you create a Simulink model that includes one or more HDL Verifier
Cosimulation blocks, you might want to adjust certain Simulink parameter
settings to best meet the needs of HDL modeling. For example, you might
want to adjust the value of the Stop time parameter in the Solver pane of
the Model Configuration Parameters dialog box.
You can adjust the parameters individually or you can use the MATLAB
file dspstartup, which lets you automate the configuration process so that
every new model that you create is preconfigured with the following relevant
parameter settings:
Parameter Default Setting

'SingleTaskRateTransMsg' 'error'
'Solver' 'fixedstepdiscrete'
'SolverMode' 'singletasking'
'StartTime' '0.0'
'StopTime' 'inf'
'FixedStep' 'auto'
'SaveTime' 'off'
'SaveOutput' 'off'
'AlgebraicLoopMsg' 'error'
4-44
The default settings for SaveTime and SaveOutput improve simulation

performance.
You can use dspstartup by entering it at the MATLAB command line or

by adding it to the Simulink startup.m file. You also have the option of
customizing dspstartup settings. For example, you might want to adjust the
StopTime to a value that is optimal for your simulations, or set SaveTime to
"on" to record simulation sample times.
4-45
For more information on using and customizing dspstartup, see the DSP
System Toolbox™ documentation. For more information about automating
tasks at startup, see the description of the startup command in the MATLAB
documentation.
Determine Available Socket Port Number

To determine an available socket number use: ttcp -a a shell prompt.
Check Connection Status

You can check the connection status by clicking the Update diagram button or
by selecting Simulation > Update Diagram. If your have an error in the
connection, Simulink will notify you.
The MATLAB command pingHdlSim can also be used to check the connection
status. If a -1 is returned, then there is no connection with the HDL simulator.
Run and Test Test Bench Cosimulation Model

In general, the last stage of cosimulation is to run and test your model. There
are some steps you must be aware of when changing your model during or
between cosimulation sessions. although your testing methods may vary
depending on which HDL simulator you have, You can review these steps in
“Run and Test Test Bench Cosimulation Model” on page 4-46.
You can run the cosimulation in one of three ways:
• “Cosimulation Using the Simulink and HDL Simulator GUIs” on page 4-46
• “Cosimulation with Simulink Using the Command Line Interface (CLI)”
on page 4-47
• “Cosimulation with Simulink Using Batch Mode” on page 4-48
Cosimulation Using the Simulink and HDL Simulator GUIs

Start the HDL simulator and load your HDL design. For test bench
cosimulation, begin simulation first in the HDL simulator. Then, in Simulink,
click Simulation > Run or the Run Simulation button. Simulink runs the
4-46
model and displays any errors that it detects. You can alternate between the
HDL simulator and Simulink GUIs to monitor the cosimulation results.
For component cosimulation, start the simulation in Simulink first, then

begin simulation in the HDL simulator.
You can specify "GUI" as the property value for the run mode parameter of
the HDL Verifier HDL simulator launch command, but since using the GUI is
the default mode for HDL Verifier, you do not have to.
Cosimulation with Simulink Using the Command Line Interface

(CLI)

['exec ncvlog -linedebug ',unixsrcfile1],...
'exec ncelab -access +wc work.inverter_vl',...
'hdlsimulink -gui work.inverter_vl'
4-47
};
Specify CLI mode with vsim ( Mentor Graphics ModelSim)
tclcmd = {'vlib work',...

'vlog addone_vlog.v add_vlog.v top_frame.v',...
'vsimulink top =socket 5002'};
Cosimulation with Simulink Using Batch Mode

GUI.

follows:
4-48

Test Cosimulation
If you wish to reset a clock during a cosimulation, you can do so in one of
these ways:
• By entering HDL simulator force commands at the HDL simulator

command prompt
• By specifying HDL simulatorforce commands in the Post- simulation
command text field on the Simulation pane of the HDL Verifier
Cosimulation block parameters dialog box.
See also “Clock, Reset, and Enable Signals” on page 8-88.
If you change any part of the Simulink model, including the HDL
Cosimulation block parameters, update the diagram to reflect those changes.
You can do this update in one of the following ways:
• Rerun the simulation

• Click the Update diagram button
• Select Simulation > Update Diagram
Avoid Race Conditions in HDL Simulation with

Test Bench Cosimulation and the HDL Verifier HDL
Cosimulation Block
In the HDL simulator, you cannot control the order in which clock signals
(rising-edge or falling-edge) defined in the HDL Cosimulation block are
applied, relative to the data inputs driven by these clocks. If you are careful
to verify the relationship between the data and active edges of the clock, you
4-49
can avoid race conditions that could create differing cosimulation results. See
“Race Conditions in HDL Simulators” on page 8-62.
4-50
Verify HDL Model with Simulink Test Bench

In this section...
“Tutorial Overview” on page 4-51
“Develop VHDL Code” on page 4-52
“Compile VHDL” on page 4-53
“Create Simulink Model” on page 4-55
“Set Up ModelSim for Use with Simulink” on page 4-63
“Load Instances of VHDL Entity for Cosimulation with Simulink” on page
4-64
“Run Simulation” on page 4-66
“Shut Down Simulation” on page 4-69
Tutorial Overview
This chapter guides you through the basic steps for setting up an HDL
Verifier session that uses Simulink and the HDL Cosimulation block to
verify an HDL model. The HDL Cosimulation block cosimulates a hardware
component by applying input signals to and reading output signals from an
HDL model under simulation in ModelSim. The HDL Cosimulation block
supports simulation of either VHDL or Verilog models. In the tutorial in this
section, you will cosimulate a simple VHDL model.
Note This tutorial is specific to ModelSim users; however, much of the

process will be the same for Incisive users.
invertercmds.m File
Included with your HDL Verifier installation is
the file invertercmds.m, located in the folder
matlabroot/toolbox/edalink/extensions/modelsim/modelsimdemos. The
returned cell array can be passed as parameters (’cmd’) to vsimulink. These
parameters, when used with the vsimulink command, launch ModelSim and
build the VHDL source file created in “Develop VHDL Code” on page 4-52.
4-51
Use of this file is not required. It is provided only for your convenience. You
may complete each step manually and forego using this file, if you so choose.
Develop VHDL Code

A typical Simulink and ModelSim scenario is to create a model for a specific
hardware component in ModelSim that you later need to integrate into a
larger Simulink model. The first step is to design and develop a VHDL model
in ModelSim. In this tutorial, you use ModelSim and VHDL to develop a
model that represents the following inverter:
...10101000 sin 8
8 sout ...01010111
The VHDL entity for this model will represent 8-bit streams of input and
output signal values with an IN port and OUT port of type STD_LOGIC_VECTOR.
An input clock signal of type STD_LOGIC will trigger the bit inversion process
when set.
1 Start ModelSim
2 Change to the writable folder MyPlayArea, which you may have created for
another tutorial. If you have not created the folder, create it now. The
folder must be writable.
ModelSim>cd C:/MyPlayArea
3 Open a new VHDL source edit window.
4 Add the following VHDL code:
---------------------------------------------------
-- Simulink and ModelSim Inverter Tutorial
--
-- Copyright 2003-2004 The MathWorks, Inc.
4-52
--
---------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ENTITY inverter IS PORT (
sin : IN std_logic_vector(7 DOWNTO 0);
sout: OUT std_logic_vector(7 DOWNTO 0);
clk : IN std_logic
);
END inverter;
LIBRARY ieee;
ARCHITECTURE behavioral OF inverter IS
BEGIN
PROCESS(clk)
BEGIN
IF (clk'EVENT AND clk = '1') THEN
sout <= NOT sin;
END IF;
END PROCESS;
END behavioral;
5 Save the file to inverter.vhd.
Compile VHDL
This section explains how to set up a design library and compile
inverter.vhd, as follows:
1 Verify that the file inverter.vhd is in the current folder by entering the
ls command at the ModelSim command prompt.
2 Create a design library to hold your compilation results. To create the

library and required _info file, enter the vlib and vmap commands as
follows:
ModelSim> vlib work
4-53
If the design library work already exists, ModelSim does not overwrite the
current library, but displays the following warning:
# ** Warning: (vlib-34) Library already exists at "work".
Note You must use the ModelSim File menu or vlib command to create
the library folder so that the required _info file is created. Do not create
the library with operating system commands.
3 Compile the VHDL file. One way of compiling the file is to click the
file name in the project workspace and select Compile > Compile All.
Another alternative is to specify the name of the VHDL file with the vcom
command, as follows:
ModelSim> vcom inverter.vhd
If the compilations succeed, informational messages appear in the

command window and the compiler populates the work library with the
compilation results.
Instead of compiling manually, you may choose to use the invertercmds.m

file. See the section about “invertercmds.m File” on page 4-51.
4-54
Create Simulink Model

Now create your Simulink model. For this tutorial, you create a simple
Simulink model that drives input into a block representing the VHDL
inverter you coded in “Develop VHDL Code” on page 4-52 and displays the
inverted output.
Start by creating a model, as follows:
1 Start MATLAB, if it is not already running. Open a new model window.

Then, open the Simulink Library Browser.
2 Drag the following blocks from the Simulink Library Browser to your
model window:
• Constant block from the Simulink Source library

• HDL Cosimulation block from the HDL Verifier block library
• Display block from the Simulink Sink library
Arrange the three blocks in the order shown in the following figure.
Next, configure the Constant block, which is the model’s input source, by
performing the following actions:
1 Double-click the Constant block icon to open the Constant block parameters
dialog box. Enter the following parameter values in the Main pane:
• Constant value: 0
• Sample time: 10
4-55
Later you can change these initial values to see the effect various sample
times have on different simulation runs.
The dialog box should now appear as follows.
2 Click the Signal Attributes tab. The dialog box now displays the Output
data type mode menu.
Select uint8 from the Output data type mode menu. This data type
specification is supported by HDL Verifier software without the need for a
type conversion. It maps directly to the VHDL type for the VHDL port sin,
STD_LOGIC_VECTOR(7 DOWNTO 0).
The dialog box should now appear as follows.
4-56
3 Click OK. The Constant block parameters dialog box closes and the value
in the Constant block icon changes to 0.
Next, configure the HDL Cosimulation block, which represents the inverter
model written in VHDL. Start with the Ports pane, by performing the
following actions:
1 Double-click the HDL Cosimulation block icon. The Block Parameters

dialog box for the HDL Cosimulation block appears. Click the Ports tab.
2 In the Ports pane, select the sample signal /top/sig1 from the signal list
in the center of the pane by double-clicking on it.
4-57
3 Replace the sample signal path name /top/sig1 with /inverter/sin.

Then click Apply. The signal name on the HDL Cosimulation block
changes.
4 Similarly, select the sample signal /top/sig2. Change the Full HDL
Name to /inverter/sout. Select Output from the I/O Mode list. Change
the Sample Time parameter to 10. Then click Apply to update the list.
5 Select the sample signal /top/sig3. Click the Delete button. The signal is
now removed from the list.
The Ports pane should appear as follows.
Now configure the parameters of the Connection pane by performing the

following actions:
4-58
1 Click the Connection tab.
2 Leave Connection Mode as Full Simulation.
3 Select socket from the Connection method list. This option specifies
that Simulink and ModelSim will communicate via a designated TCP/IP
socket port. Observe that two additional fields, Port number or service
and Host name, are now visible.
Note that, because The HDL simulator is running on this computer

option option is selected by default, the Host name field is disabled. In
this configuration, both Simulink and ModelSim execute on the same
computer, so you do not need to enter a remote host system name.
4 In the Port number or service text box, enter socket port number 4449
or, if this port is not available on your system, another valid port number
or service name. The model will use TCP/IP socket communication to link
with ModelSim. Note what you enter for this parameter. You will specify
the same socket port information when you set up ModelSim for linking
with Simulink.
The Connection pane should appear as follows.
4-59
5 Click Apply.
Now configure the Clocks pane by performing the following actions:
1 Click the Clocks tab.
2 Click the New button. A new clock signal with an empty signal name
is added to the signal list.
3 Double-click on the new signal name to edit. Enter the signal path
/inverter/clk. Then select Rising from the Edge list. Set the Period
parameter to 10.
4 The Clocks pane should appear as follows.
5 Click Apply.
Next, enter some simple Tcl commands to be executed before and after
simulation, as follows:
1 Click the Simulation tab.
4-60
2 In the Pre-simulation commands text box, enter the following Tcl

command:
echo "Running inverter in Simulink!"
3 In the Post-simulation commands text box, enter
echo "Done"
The Simulation pane should appear as follows.
4 Click Apply.
Next, view the Timescales pane to make sure it is set to its default
parameters, as follows:
1 Click the Timescales tab.
2 The default settings of the Timescales pane are shown in the following
figure. These settings are required for operation of this example. See
“Simulation Timescales” on page 8-74 for further information.
4-61
3 Click OK to close the Function Block Parameters dialog box.
The final step is to connect the blocks, configure model-wide parameters, and
save the model. Perform the following actions:
1 Connect the blocks as shown in the following figure.
4-62
At this point, you might also want to consider adjusting block annotations.
2 Configure the Simulink solver options for a fixed-step, discrete simulation;

this is required for cosimulation operation. Perform the following actions:
a Select Model Configuration Parameters from the Simulation menu
in the model window. The Model Configuration Parameters dialog box
opens, displaying the Solver options pane.
b Select Fixed-step from the Type menu.
c Select Discrete (no continuous states) from the Solver menu.
d Click Apply.
e Click OK to close the Model Configuration Parameters dialog box.
See “Set Simulink Model Configuration Parameters” on page 4-44 for

further information on Simulink settings that are optimal for use with
HDL Verifier software.
3 Save the model.
Set Up ModelSim for Use with Simulink

You now have a VHDL representation of an inverter and a Simulink model
that applies the inverter. To start ModelSim such that it is ready for use
with Simulink, enter the following command line in the MATLAB Command
Window:
vsim('socketsimulink', 4449)
Note If you entered a different socket port specification when you configured
the HDL Cosimulation block in Simulink, replace the port number 4449 in
the preceding command line with the applicable socket port information for
your model. The vsim function informs ModelSim of the TCP/IP socket to use
for establishing a communication link with your Simulink model.
To launch ModelSim, you may choose instead to use the invertercmds.m file.
See the section about “invertercmds.m File” on page 4-51.
4-63
Load Instances of VHDL Entity for Cosimulation with

Simulink
This section explains how to use the vsimulink command to load an instance
of your VHDL entity for cosimulation with Simulink. The vsimulink
command is an HDL Verifier variant of the ModelSim vsim command. It is
made available as part of the ModelSim configuration.
To load an instance of the inverter entity, perform the following actions:
1 Change your input focus to the ModelSim window.
2 If your VHD file is not in the current folder, change your folder to the
location of your inverter.vhd file. For example:
ModelSim> cd C:/MyPlayArea
3 Enter the following vsimulink command:
ModelSim> vsimulink work.inverter
ModelSim starts the vsim simulator such that it is ready to simulate entity
inverter in the context of your Simulink model. The ModelSim command
window display should be similar to the following.
4-64
Instead of loading the entity manually, you may choose to use the
invertercmds.m file. See the section about “invertercmds.m File” on page
4-51.
4-65
Run Simulation
This section guides you through a scenario of running and monitoring a
cosimulation session.
Perform the following actions:
1 Open and add the inverter signals to a wave window by entering the
following ModelSim command:
VSIM n> add wave /inverter/*
The following wave window appears.
2 Change your input focus to your Simulink model window.
4-66
3 Start a Simulink simulation. The value in the Display block changes to

255. Also note the changes that occur in the ModelSim wave window. You
might need to zoom in to get a better view of the signal data.
4 In the Simulink model, change Constant value to 255, save the model,
and start another simulation. The value in the Display block changes to 0
and the ModelSim wave window is updated as follows.
4-67
5 In the Simulink Model, change Constant value to 2 and Sample time

to 20 and start another simulation. This time, the value in the Display
block changes to 253 and the ModelSim wave window appears as shown in
4-68
Note the change in the sample time in the wave window.
Shut Down Simulation

This section explains how to shut down a simulation in an orderly way, as
follows:
1 In ModelSim, stop the simulation by selecting Simulate > End

Simulation.
2 Quit ModelSim.
3 Close the Simulink model window.
4-69
Test Bench Automatic Verification with Simulink

The automatic verification feature integrates verification as part of the
workflow for HDL Cosimulation using the HDL Workflow Advisor. During
this workflow, Simulink generates a test bench model for HDL Cosimulation.
This test bench model compares the generated HDL DUT outputs (coming
through the HDL Cosimulation block) with the original Simulink block
outputs. The automatic verification step automatically runs this test bench.
This step returns pass/fail information depending if the outputs of the HDL
DUT match the output of original Simulink block in the test bench.
1 Open HDL Workflow Advisor for your model.
2 Step 1.1, select Generic ASIC/FPGA.
3 Run all steps under 2, Prepare Model For HDL Code Generation.
4 At step 3.2, Generate RTL Code and Testbench, select Generate

cosimulation model (requires HDL Verifier). Then select either
Mentor Graphics ModelSim or Cadence Incisive for your HDL
simulator. Selecting these options causes step 3.3 to appear.
4-70
Test Bench Automatic Verification with Simulink®
5 At step 3.3, click Run This Task. The HDL Workflow Advisor and HDL
Verifier verify the generated HDL using cosimulation between the HDL
Simulator and the Simulink test bench. Any relevant status messages are
displayed in the status window in the HDL Workflow Advisor.
4-71
4-72
5
Replace HDL Component

with Simulink Algorithm
• “Component Simulation with Simulink” on page 5-2

• “Replace HDL Component with Simulink Algorithm” on page 5-6
• “Code an HDL Component” on page 5-7
• “Create Simulink Model for Component Cosimulation” on page 5-10
• “Add HDL Cosimulation Block to Model” on page 5-13
• “Define HDL Cosimulation Block Interface” on page 5-15
• “Run a Component Cosimulation Session” on page 5-43
5 Replace HDL Component with Simulink Algorithm
Component Simulation with Simulink

In this section...
“How the HDL Simulator and Simulink Software Communicate Using HDL
Verifier For Component Simulation” on page 5-2
“HDL Cosimulation Block Features for Component Simulation” on page 5-4
How the HDL Simulator and Simulink Software

Communicate Using HDL Verifier For Component
Simulation
When you link the HDL simulator with a Simulink application, the
simulator functions as the server. As the following diagram shows, the HDL
Cosimulation blocks inside the Simulink model accept signals from the HDL
module under simulation in the HDL simulator via the output ports on the
Ports panes and return data via the input ports on the Ports panes.
5-2
How Simulink Drives Cosimulation Signals

Although you can bind the output ports of an HDL Cosimulation block to
any signal in an HDL model hierarchy, you must use some caution when
connecting signals to input ports. You want to verify that the signal you are
binding to does not have other drivers. If it does, use resolved logic types;
otherwise you may get unpredictable results.
If you need to use a signal that has multiple drivers and it is resolved (for
example, it is of VHDL type STD_LOGIC) , Simulink applies the resolution
function at each time step defined by the signal’s Simulink sample rate.
Depending on the other drivers, the Simulink value may or may not get
applied. Furthermore, Simulink has no control over signal changes that occur
between its sample times.
Note Verify that signals used in cosimulation have read/write access. You
can check read/write access through the HDL simulator—see HDL simulator
This rule applies to all signals on the Ports, Clocks, and Simulation panes
and to signals added to the model in any other manner.
Multirate Signals During Component Cosimulation

HDL Verifier software supports the use of multirate signals, signals that are
sampled or updated at different rates, in a single HDL Cosimulation block.
An HDL Cosimulation block exchanges data for each signal at the Simulink
sample rate for that signal. For input signals, an HDL Cosimulation block
accepts and honors all signal rates.
The HDL Cosimulation block also lets you specify an independent sample
time for each output port. You must explicitly set the sample time for each
output port, or accept the default. Using this setting lets you control the
rate at which Simulink updates an output port by reading the corresponding
signal from the HDL simulator.
5-3
Continuous Time Signals

Use the Simulink Zero-Order Hold block to apply a zero-order hold (ZOH) on
continuous signals that are driven into an HDL Cosimulation block.
HDL Cosimulation Block Features for Component

Simulation
The HDL Verifier HDL Cosimulation Block links hardware components that
are concurrently simulating in the HDL simulator to the rest of a Simulink
model.
You can link Simulink and the HDL simulator in two possible ways:
• As a single HDL Cosimulation block fitted into the framework of a larger

system-oriented Simulink model.
• As a Simulink model made up of a collection of HDL Cosimulation blocks,
each representing a specific hardware component.
The block mask contains panels for entering port and signal information,
setting communication modes, adding clocks (Incisive and ModelSim only),
specifying pre- and post-simulation Tcl commands (Incisive and ModelSim
only), and defining the timing relationship.
After you code one of your model’s components in VHDL or Verilog and
simulate it in the HDL simulator environment, you integrate the HDL
representation into your Simulink model as an HDL Cosimulation block.
There is one block for each supported HDL simulator. These blocks are
located in the Simulink Library, within the HDL Verifier block library. As
an example, the block for use with Mentor Graphics ModelSim is shown in
the next figure.
5-4
You configure an HDL Cosimulation block by specifying values for parameters

in a block parameters dialog box. The HDL Cosimulation block parameters
dialog box consists of tabbed panes that specify the following information:
• Ports Pane: Block input and output ports that correspond to signals,
including internal signals, of your HDL design, and an output sample time.
• Connection Pane: Type of communication and related settings to be used
for exchanging data between simulators.
• Timescales Pane: The timing relationship between Simulink software
and the HDL simulator.
• Clocks Pane (Incisive and ModelSim only): Optional rising-edge and
falling-edge clocks to apply to your model.
• Simulation Pane (Incisive and ModelSim only): Tcl commands to run
before and after a simulation.
5-5
Replace HDL Component with Simulink Algorithm

The following workflow steps describe how to cosimulate an HDL design that
tests the algorithm being modeled with the Simulink software.
1 Create, compile, and elaborate HDL design. See “Code an HDL Component”
on page 5-7.
2 Design algorithm and model algorithm in Simulink. See “Create Simulink

Model for Component Cosimulation” on page 5-10.
3 Start HDL simulator for use with MATLAB and Simulink and load HDL
Verifier libraries. See “Start HDL Simulator” on page 5-11.
4 Add one or more HDL Cosimulation blocks to provide communication

between simulators. See “Add HDL Cosimulation Block to Model” on page
5-13.
5 Define HDL Cosimulation block interfaces. See “Define HDL Cosimulation

Block Interface” on page 5-15.
6 Start simulation in Simulink. See “Run a Component Cosimulation

7 Run cosimulation in HDL simulator. See “Run a Component Cosimulation

5-6

In this section...
“Overview to Coding HDL Modules for Simulink Component Simulation”
on page 5-7
“Specify Port Direction Modes in HDL Module for Component Simulation”
on page 5-7
“Specify Port Data Types in HDL Module for Component Simulation” on
page 5-8
“Compile and Elaborate HDL Design for Component Simulation” on page
5-9
Overview to Coding HDL Modules for Simulink

Component Simulation
The HDL Verifier interface passes all data between the HDL simulator and
Simulink as port data. The HDL Verifier software works with any existing
Simulink verification, you should consider the types of data to be shared
between the two environments and the direction modes.
Specify Port Direction Modes in HDL Module for

5-7

Mode... Mode...
MATLAB function
a MATLAB function
function
Specify Port Data Types in HDL Module for



and BIT_VECTOR
• REAL
5-8
• TIME
CHARACTER

in cosimulation
Port Data Types for Verilog Modules. In your module definition, you
must define each port that you plan to test with MATLAB with a Verilog port
data type that is supported by the HDL Verifier software. The interface can
convert data of the following Verilog port types to comparable MATLAB types:
• reg
• integer
• wire
Compile and Elaborate HDL Design for Component

Simulation
Refer to the HDL simulator documentation for instruction in compiling and
elaborating the HDL design.
5-9
Create Simulink Model for Component Cosimulation

In this section...
“Simulink Model for Component Cosimulation” on page 5-10
“Run and Test Component Hardware Model in Simulink” on page 5-10
“Add Value Change Dump (VCD) File to Component Model (Optional)”
on page 5-10
Simulink Model for Component Cosimulation

For the most part, there is nothing different about creating a Simulink model
to act as an HDL component than there is from creating a Simulink model
to use as a test bench. When using Simulink as a component, you may have
multiple HDL Cosimulation blocks rather than a single HDL Cosimulation
block, though there’s no limitation on how many HDL Cosimulation blocks
you may use in either situation.
Create a Simulink test bench model by adding Simulink blocks from the
Simulink Block libraries. For help with creating a Simulink model, see the
Run and Test Component Hardware Model in

Simulink
If you design a Simulink model first, run and test your model thoroughly
before replacing or adding hardware model components as HDL Verifier
Cosimulation blocks.
Add Value Change Dump (VCD) File to Component

Model (Optional)
You might want to add a VCD file to log changes to variable values during a
simulation session. See “Add a Value Change Dump (VCD) File” on page 6-2
for instructions on adding the To VCD File block.
5-10
Start HDL Simulator
Start HDL Simulator

In this section...
“Start HDL Simulator from MATLAB” on page 5-11
“Load Instance of HDL Module for Component Cosimulation” on page 5-11
Start HDL Simulator from MATLAB

>>vsim
Note that if both tools (MATLAB and the HDL simulator) are not running on
the same system, you must start the HDL simulator manually and load the
HDL Verifier libraries yourself. See “HDL Verifier Libraries” on page 8-11.
pages for details.
Load Instance of HDL Module for Component

Cosimulation
Incisive users load an instance of the HDL module for cosimulation using the
hdlsimulink function. ModelSim users do the same using the vsimulink
function.
5-11
Example of loading HDL Module instance — Incisive users
After you start the HDL simulator from MATLAB, load an instance of an
HDL module for cosimulation with the function hdlsimulink. Issue the
command for each instance of an HDL module in your model that you want to
cosimulate.
For example:
hdlsimulink work.manchester
Example of loading HDL Module instance — ModelSim users
After you start the HDL simulator from MATLAB, load an instance of an HDL
module for cosimulation with the function vsimulink. Issue the command for
each instance of an HDL module in your model that you want to cosimulate.
For example:
vsimulink work.manchester
This command opens a simulation workspace for manchester and displays a

series of messages in the HDL simulator command window as the simulator
loads the packages and architectures for the HDL module.
5-12

In this section...
“Insert HDL Cosimulation Block” on page 5-13
“Connect Block Ports” on page 5-14
Insert HDL Cosimulation Block

After you code one of your model’s components in VHDL or Verilog
and simulate it in the HDL simulator environment, integrate the HDL
representation into your Simulink model as an HDL Cosimulation block by
performing the following steps:
2 Delete the model component that the HDL Cosimulation block is to replace.
3 In the Simulink Library Browser, click the HDL Verifier block library. You
can then select the block library for your supported HDL simulator. Select
either the Mentor Graphics ModelSim HDL Cosimulation block, or the
Cadence Incisive HDL Cosimulation block, as shown below.
5-13
4 Copy the HDL Cosimulation block icon from the Library Browser to your
model. Simulink creates a link to the block at the point where you drop
the block icon.
Connect Block Ports

Connect any HDL Cosimulation block ports to the applicable block ports in
your Simulink model.
• To model a sink device, configure the block with inputs only.

• To model a source device, configure the block with outputs only.
5-14

In this section...
“Open HDL Cosimulation Block Interface” on page 5-15
“Map HDL Signals to Block Ports” on page 5-16
“Specify Signal Data Types” on page 5-31
“Configure Simulink and HDL Simulator Timing Relationship” on page 5-31
“Configure Communication Link in the HDL Cosimulation Block” on page
5-34
“Specify Pre- and Post-Simulation Tcl Commands with HDL Cosimulation
Block Parameters Dialog Box” on page 5-37
“Programmatically Control Block Parameters” on page 5-40
Open HDL Cosimulation Block Interface

To open the block parameters dialog box for the HDL Cosimulation block,
double-click the block icon. Simulink displays the following Block Parameters
dialog box (as an example, the dialog box for the HDL Cosimulation block for
use with ModelSim is shown below).
5-15
Map HDL Signals to Block Ports

• “Specify HDL Signal/Port and Module Paths for Cosimulation” on page 5-17
• “Get Signal Information from the HDL Simulator” on page 5-19
• “Enter Signal Information Manually” on page 5-25
• “Control Output Port Directly by Value of Input Port” on page 5-30
The first step to configuring your HDL Verifier Cosimulation block is to map
signals and signal instances of your HDL design to port definitions in your
HDL Cosimulation block. In addition to identifying input and output ports,
5-16
you can specify a sample time for each output port. You can also specify a
fixed-point data type for each output port.
The signals that you map can be at any level of the HDL design hierarchy.
To map the signals, you can perform either of the following actions:
• Enter signal information manually into the Ports pane of the HDL
Cosimulation Block Parameters dialog box (see “Enter Signal Information
Manually” on page 4-26). This approach can be more efficient when
you want to connect a small number of signals from your HDL model
to Simulink.
• Use the Auto Fill button to have the HDL Cosimulation block obtain
signal information for you by transmitting a query to the HDL simulator.
This approach can save significant effort when you want to cosimulate
an HDL model that has many signals that you want to connect to your
Simulink model. However, in some cases, you will need to edit the signal
data returned by the query. See “Get Signal Information from HDL
Simulator” on page 4-20 for details.
Note Verify that signals used in cosimulation have read/write access. For
higher performance, you want to provide access only to those signals used
in cosimulation. This rule applies to all signals on the Ports, Clocks, and
Simulation panes, and to all signals added in any other manner.
Specify HDL Signal/Port and Module Paths for Cosimulation

These rules are for signal/port and module path specifications in Simulink.
Other specifications may work but are not explicitly or implicitly supported in
this or future releases.
HDL designs generally do have hierarchy; that is the reason for this syntax.
This specification does not represent a file name hierarchy.
Path specifications must follow the rules listed in the following sections:
• “Path Specifications for Simulink Cosimulation Sessions with Verilog Top

5-17
• “Path Specifications for Simulink Cosimulation Sessions with VHDL Top

Path Specifications for Simulink Cosimulation Sessions with Verilog

Top Level.
• Path specification must start with a top-level module name.

a mixture.
module.
top.port_or_sig
top
top/sub
top.sub1.sub2
:
:sub
Path Specifications for Simulink Cosimulation Sessions with VHDL

Top Level.
• Path specification may include the top-level module name but it is not
required.
5-18
a mixture.
module.
top.port_or_sig
/sub/port_or_sig
top
top/sub
top.sub1.sub2
:
:sub
Get Signal Information from the HDL Simulator

The Auto Fill button lets you begin an HDL simulator query and supply a
path to a component or module in an HDL model under simulation in the
HDL simulator. Usually, some change of the port information is required
after the query completes. You must have the HDL simulator running with
the HDL module loaded for Auto Fill to work.
The following example describes the required steps.
5-19
Note The example is based on a modified copy of the Manchester Receiver

model, in which all signals were first deleted from the Ports and Clocks
panes.
1 Open the block parameters dialog box for the HDL Cosimulation block.
Click the Ports tab. The Ports pane opens (as an example, the Ports
pane for the HDL Cosimulation block for use with ModelSim is shown
in the illustrations below).
5-20
Tip Delete all ports before performing Auto Fill to make sure that no
unused signal remains in the Ports list at any time.
2 Click the Auto Fill button. The Auto Fill dialog box opens.
This modal dialog box requests an instance path to a component or module

in your HDL model; here you enter an explicit HDL path into the edit
field. The path you enter is not a file path and has nothing to do with the
source files.
3 In this example, the Auto Fill feature obtains port data for a
VHDL component called manchester. The HDL path is specified as
/top/manchester (path specifications will vary depending on your
HDL simulator; see “Specify HDL Signal/Port and Module Paths for
Cosimulation” on page 4-18).
4 Click OK to dismiss the dialog box and the query is transmitted.
5 After the HDL simulator returns the port data, the Auto Fill feature enters
it into the Ports pane, as shown in the following figure (examples shown
for use with Cadence Incisive).
5-21
6 Click Apply to commit the port additions.
7 Delete unused signals from Ports pane and add Clock signal.
The preceding figure shows that the query entered clock, clock enable, and
reset ports (labeled clk, enable, and reset respectively) into the ports list.
Delete the enable and reset signals from the Ports pane, and add the clk
signal in the Clocks pane.
These actions result in the signals shown in the next figures.
5-22
5-23
8 Auto Fill returns default values for output ports:
• Sample time: 1
• Data type: Inherit
• Fraction length: Inherit
You may need to change these values as required by your model. In this
example, the Sample time should be set to 10 for all outputs. See also
“Specify Signal Data Types” on page 4-32.
9 Before closing the HDL Cosimulation block parameters dialog box, click
Apply to commit any edits you have made.
Observe that Auto Fill returned information about all inputs and outputs
for the targeted component. In many cases, this will include signals that
function in the HDL simulator but cannot be connected in the Simulink
model. You may delete any such entries from the list in the Ports pane if
they are unwanted. You can drive the signals from Simulink; you just have to
define their values by laying down Simulink blocks.
5-24
Note that Auto Fill does not return information for internal signals. If your
Simulink model needs to access such signals, you must enter them into the
Ports pane manually. For example, in the case of the Manchester Receiver
model, you would need to add output port entries for top/manchester/sync_i,
top/manchester/isum_i, and top/manchester/qsum_i, as shown in step 8.
Incisive and ModelSim users: Note that clk, reset, and clk_enable may be
in the Clocks and Simulation panes but they don’t have to be. These signals
can be ports if you choose to drive them explicitly from Simulink.
Note When you import VHDL signals using Auto Fill, the HDL simulator
returns the signal names in all capitals.
Enter Signal Information Manually

To enter signal information directly in the Ports pane, perform the following
steps:
1 In the HDL simulator, determine the signal path names for the HDL
signals you plan to define in your block. For example, in the ModelSim
simulator, the following wave window shows all signals are subordinate to
the top-level module manchester.
5-25
2 In Simulink, open the block parameters dialog box for your HDL
Cosimulation block, if it is not already open.
3 Select the Ports pane tab. Simulink displays the following dialog box
(example shown for use with Incisive).
5-26
In this pane, you define the HDL signals of your design that you want to
include in your Simulink block and set a sample time and data type for
output ports. The parameters that you should specify on the Ports pane
depend on the type of device the block is modeling as follows:
• For a device having both inputs and outputs: specify block input ports,
block output ports, output sample times and output data types.
For output ports, accept the default or enter an explicit sample time.
Data types can be specified explicitly, or set to Inherit (the default). In
the default case, the output port data type is inherited either from the
signal connected to the port, or derived from the HDL model.
• For a sink device: specify block output ports.
• For a source device: specify block input ports.
5-27
4 Enter signal path names in the Full HDL name column by double-clicking
on the existing default signal.
• Use HDL simulator path name syntax (as described in “Specify HDL
Signal/Port and Module Paths for MATLAB Test Bench Cosimulation”
on page 1-24).
• If you are adding signals, click New and then edit the default values.
Select either Input or Output from the I/O Mode column.
• If you want to, set the Sample Time, Data Type, and Fraction Length
parameters for signals explicitly, as discussed in the remaining steps.
When you have finished editing clock signals, click Apply to register your
The following dialog box shows port definitions for an HDL Cosimulation
block. The signal path names match path names that appear in the HDL
simulator wave window (Incisive example shown).
5-28
Note When you define an input port, make sure that only one source is
set up to force input to that port. If multiple sources drive a signal, your
Simulink model may produce unpredictable results.
5 You must specify a sample time for the output ports. Simulink uses the
value that you specify, and the current settings of the Timescales pane,
to calculate an actual simulation sample time.
For more information on sample times in the HDL Verifier cosimulation

environment, see “Simulation Timescales” on page 8-74.
5-29
6 You can configure the fixed-point data type of each output port explicitly
if desired, or use a default (Inherited). In the default case, Simulink
determines the data type for an output port as follows:
If Simulink can determine the data type of the signal connected to the
output port, it applies that data type to the output port. For example,
the data type of a connected Signal Specification block is known by
back-propagation. Otherwise, Simulink queries the HDL simulator to
determine the data type of the signal from the HDL module.
To assign an explicit fixed-point data type to a signal, perform the following

steps:
a Select either Signed or Unsigned from the Data Type column.
b If the signal has a fractional part, enter the Fraction Length.
For example, if the model has an 8-bit signal with Signed data type and
a Fraction Length of 5, the HDL Cosimulation block assigns it the
data type sfix8_En5. If the model has an Unsigned 16-bit signal with no
fractional part (a Fraction Length of 0), the HDL Cosimulation block
assigns it the data type ufix16.
7 Before closing the dialog box, click Apply to register your edits.
Control Output Port Directly by Value of Input Port

Enabling direct feedthrough allows input port value changes to propagate to
the output ports in zero time, thus eliminating the possible delay at output
sample in HDL designs with pure combinational logic. Specify the option to
enable direct feedthrough on the Ports pane, as shown in the following figure.
5-30
For more about the direct feedthrough feature, see “Direct Feedthrough
Specify Signal Data Types

The Data Type and Fraction Length parameters apply only to output
signals. See Data Type and Fraction Length on the Ports pane description
of the HDL Cosimulation block.

Relationship
You configure the timing relationship between Simulink and the HDL
simulator by using the Timescales pane of the block parameters dialog box.
Before setting the Timescales parameters, read “Simulation Timescales” on
page 8-74 to understand the supported timing modes and the issues that will
determine your choice of timing mode.
You can specify either a relative or an absolute timing relationship between

Simulink and the HDL simulator in the Timescales pane, as described in the
HDL Cosimulation block reference.
Define Simulink and HDL Simulator Timing Relationship


This quantity of HDL simulator time can be expressed in one of the

following ways:
- In relative terms (i.e., as some number of HDL simulator ticks). In
this case, the cosimulation is said to operate in relative timing mode.
5-31
The HDL Cosimulation block defaults to relative timing mode for

cosimulation. For more on relative timing mode, see “Relative Timing
Mode” on page 8-77.
- In absolute units (such as milliseconds or nanoseconds). In this case, the
For more on relative and absolute time, see “Simulation Timescales” on
page 8-74.
When you allow the link software to define the timing relationship, it
attempts to set the timescale factor between the HDL simulator and
Simulink to be as close as possible to 1 second in the HDL simulator = 1
second in Simulink. If this setting is not possible, the link product attempts
to set the signal rate on the Simulink model port to the lowest possible
number of HDL simulator ticks.
Before you begin, verify that the HDL simulator is running. HDL Verifier
software can get the resolution limit of the HDL simulator only when that
simulator is running.
setting the parameters on the block dialog by clicking the Timescale
option then clicking Determine Timescale Now or you can have HDL
Verifier calculate the timescale when simulation begins by selecting
Automatically determine timescale at start of simulation.
5-32
When you click Determine Timescale Now, HDL Verifier connects

Simulink with the HDL simulator so that it can use the HDL simulator
resolution to calculate the best timescale. You can accept the timescale
HDL Verifier suggests or you can make changes in the port list directly.
If you want to revert to the originally calculated settings, click Use
Suggested Timescale. If you want to view sample times for all ports in
the HDL design, select Show all ports and clocks.
5-33
If you select Automatically determine timescale at start of

simulation, you get the same dialog when the simulation starts in
Simulink. Make the same adjustments at that time, if applicable, that
you would if you clicked Determine Timescale Now when you were
configuring the block.
Configure Communication Link in the HDL

Cosimulation Block
You must select shared memory or socket communication (see “HDL
Cosimulation with MATLAB or Simulink”).
5-34
After you decide which type of communication, configure a block’s

communication link with the Connection pane of the block parameters
dialog box (example shown for use with ModelSim).
The following steps guide you through the communication configuration:
1 Determine whether Simulink and the HDL simulator are running on the
same computer. If they are, skip to step 4.
2 Clear the The HDL simulator is running on this computer check

box. (This check box defaults to selected.) Because Simulink and the HDL
simulator are running on different computers, HDL Verifier sets the
Connection method to Socket.
5-35
3 Enter the host name of the computer that is running your HDL simulation
(in the HDL simulator) in the Host name text field. In the Port number
or service text field, specify a valid port number or service for your
computer system. For information on choosing TCP/IP socket ports, see
“TCP/IP Socket Ports” on page 8-95. Skip to step 5.
4 If the HDL simulator and Simulink are running on the same computer,
decide whether you are going to use shared memory or TCP/IP sockets for
the communication channel. For information on the different modes of
communication, see “HDL Cosimulation with MATLAB or Simulink”.
If you choose TCP/IP socket communication, specify a valid port number

or service for your computer system in the Port number or service text
field. For information on choosing TCP/IP socket ports, see “TCP/IP Socket
Ports” on page 8-95.
If you choose shared memory communication, select the Shared memory

check box.
5 If you want to bypass the HDL simulator when you run a Simulink
simulation, use the Connection Mode options to specify what type of
simulation connection you want. Select one of the following options:
• Full Simulation: Confirm interface and run HDL simulation (default).
• Confirm Interface Only: Check HDL simulator for expected signal
names, dimensions, and data types, but do not run HDL simulation.
• No Connection: Do not communicate with the HDL simulator. The
HDL simulator does not need to be started.
With the second and third options, HDL Verifier software does not
communicate with the HDL simulator during Simulink simulation.
6 Click Apply.
The following example dialog box shows communication definitions for an

HDL Cosimulation block. The block is configured for Simulink and the HDL
simulator running on the same computer, communicating in TCP/IP socket
mode over TCP/IP port 4449.
5-36
Specify Pre- and Post-Simulation Tcl Commands with

HDL Cosimulation Block Parameters Dialog Box
You have the option of specifying Tcl commands to execute before and after
the HDL simulator simulates the HDL component of your Simulink model.
Tcl is a programmable scripting language supported by most HDL simulation
environments. Use of Tcl can range from something as simple as a one-line
puts command to confirm that a simulation is running or as complete as
a complex script that performs an extensive simulation initialization and
startup sequence. For example, you can use the Post- simulation command
field on the Simulation Pane to instruct the HDL simulator to restart at the
end of a simulation run.
5-37
Note for ModelSim Users After each simulation, it takes ModelSim time
to update the coverage result. To prevent the potential conflict between this
process and the next cosimulation session, add a short pause between each
successive simulation.
You can specify the pre-simulation and post-simulation Tcl commands

by entering Tcl commands in the Pre-simulation commands or
Post-simulation commands text fields in the Simulation pane of the HDL
Cosimulation block mask.
To specify Tcl commands, perform the following steps:
1 Select the Simulation tab of the Block Parameters dialog box. The dialog
box appears as follows (example shown for use with ModelSim).
5-38
The Pre-simulation commands text box includes a puts command for

reference purposes.
2 Enter one or more commands in the Pre-simulation command and

Post-simulation command text boxes. You can specify one Tcl command
per line in the text box or enter multiple commands per line by appending
each command with a semicolon (;), which is the standard Tcl concatenation
operator.
ModelSim DO Files
Alternatively, you can create a ModelSim DO file that lists Tcl commands
and then specify that file with the ModelSim do command as shown in
5-39
3 Click Apply.
Programmatically Control Block Parameters

One way to control block parameters is through the HDL Cosimulation
block graphical dialog box. However, you can also control blocks by
programmatically controlling the mask parameter values and the running of
simulations. Parameter values can be read using the Simulink get_param
function and written using the Simulink set_param function. All block
parameters have attributes that indicate whether they are:
5-40
• Tunable — The attributes can change during the simulation run.

• Evaluated — The parameter string value undergoes an evaluation to
determine its actual value used by the S-Function.
The HDL Cosimulation block does not have any tunable parameters; thus,
you get an error if you try to change a value while the simulation is running.
However, it does have a few evaluated parameters.
You can see the list of parameters and their attributes by performing
a right-mouse click on the block, selecting View Mask, and then the
Parameters tab. The Variable column shows the programmatic parameter
names. Alternatively, you can get the names programmatically by selecting
the HDL Cosimulation block and then typing the following commands at
the MATLAB prompt:
>> get_param(gcb, 'DialogParameters')
Some examples of using MATLAB to control simulations and mask parameter

values follow. Usually, the commands are put into a script or function file and
are called by several callback hooks available to the model developer. You can
place the code in any of these suggested locations, or anywhere you choose:
• In the model workspace, for example, View > Model Explorer > Simulink
Root > model_name > Model Workspace, option Data Source is set
to Model File.
• In a model callback, for example, File > Model Properties > Callbacks.
• A subsystem callback (right-mouse click on an empty subsystem and then
select Properties > Callbacks). Many of the HDL Verifier demos use
this technique to start the HDL simulator by placing MATLAB code in
the OpenFcn callback.
• The HDL Cosimulation block callback (right-mouse click on HDL
Cosimulation block, and then select Properties > Callbacks).
Example: Scripting the Value of the Socket Number for HDL

Simulator Communication
In a regression environment, you may need to determine the socket number
for the Simulink/HDL simulator connection during the simulation to avoid
5-41
collisions with other simulation runs. This example shows code that could
handle that task. The script is for a 32-bit Linux platform.
ttcp_exec = [matlabroot '/toolbox/shared/hdllink/scripts/ttcp_glnx'];

[status, results] = system([ttcp_exec ' -a']);
if ~s
parsed_result = textscan(results,'%s');
avail_port = parsed_result{1}{2};
else
error(results);
end
set_param('MyModel/HDL Cosimulation', 'CommPortNumber', avail_port);
5-42
Run a Component Cosimulation Session

In this section...
“Simulink Software Configuration Parameters” on page 5-43
“Determine Available Socket Port Number” on page 5-45
“Check Connection Status” on page 5-45
“Run and Test Component Cosimulation Model” on page 5-45
“Avoid Race Conditions in HDL Simulation with Component Cosimulation
and the HDL Verifier HDL Cosimulation Block” on page 5-48
Simulink Software Configuration Parameters

When you create a Simulink model that includes one or more HDL Verifier
Cosimulation blocks, you might want to adjust certain Simulink parameter
settings to best meet the needs of HDL modeling. For example, you might
want to adjust the value of the Stop time parameter in the Solver pane of
the Model Configuration Parameters dialog box.
You can adjust the parameters individually or you can use the MATLAB
file dspstartup, which lets you automate the configuration process so that
every new model that you create is preconfigured with the following relevant
parameter settings:
Parameter Default Setting

'SingleTaskRateTransMsg' 'error'
'Solver' 'fixedstepdiscrete'
'SolverMode' 'singletasking'
'StartTime' '0.0'
'StopTime' 'inf'
'FixedStep' 'auto'
'SaveTime' 'off'
'SaveOutput' 'off'
'AlgebraicLoopMsg' 'error'
5-43
The default settings for SaveTime and SaveOutput improve simulation

performance.
You can use dspstartup by entering it at the MATLAB command line or

by adding it to the Simulink startup.m file. You also have the option of
customizing dspstartup settings. For example, you might want to adjust the
StopTime to a value that is optimal for your simulations, or set SaveTime to
"on" to record simulation sample times.
5-44
For more information on using and customizing dspstartup, see the DSP
System Toolbox documentation. For more information about automating
tasks at startup, see the description of the startup command in the MATLAB
documentation.
Determine Available Socket Port Number

To determine an available socket number use: ttcp -a a shell prompt.
Check Connection Status

You can check the connection status by clicking the Update diagram button or
by selecting Simulation > Update Diagram. If your have an error in the
connection, Simulink will notify you.
The MATLAB command pingHdlSim can also be used to check the connection
status. If a -1 is returned, then there is no connection with the HDL simulator.
Run and Test Component Cosimulation Model

In general, the last stage of cosimulation is to run and test your model. There
are some steps you must be aware of when changing your model during or
between cosimulation sessions. although your testing methods may vary
depending on which HDL simulator you have, You can review these steps in
“Run and Test Test Bench Cosimulation Model” on page 4-46.
You can run the cosimulation in one of three ways:
• “Cosimulation Using the Simulink and HDL Simulator GUIs” on page 4-46
• “Cosimulation with Simulink Using the Command Line Interface (CLI)”
on page 4-47
• “Cosimulation with Simulink Using Batch Mode” on page 4-48
Cosimulation Using the Simulink and HDL Simulator GUIs

Start the HDL simulator and load your HDL design. For test bench
cosimulation, begin simulation first in the HDL simulator. Then, in Simulink,
click Simulation > Run or the Run Simulation button. Simulink runs the
5-45
model and displays any errors that it detects. You can alternate between the
HDL simulator and Simulink GUIs to monitor the cosimulation results.
For component cosimulation, start the simulation in Simulink first, then

begin simulation in the HDL simulator.
You can specify "GUI" as the property value for the run mode parameter of
the HDL Verifier HDL simulator launch command, but since using the GUI is
the default mode for HDL Verifier, you do not have to.
Cosimulation with Simulink Using the Command Line Interface

(CLI)

['exec ncvlog -linedebug ',unixsrcfile1],...
'exec ncelab -access +wc work.inverter_vl',...
'hdlsimulink -gui work.inverter_vl'
5-46
};
Specify CLI mode with vsim ( Mentor Graphics ModelSim)
tclcmd = {'vlib work',...

'vlog addone_vlog.v add_vlog.v top_frame.v',...
'vsimulink top =socket 5002'};
Cosimulation with Simulink Using Batch Mode

GUI.

follows:
5-47

Test Cosimulation
If you wish to reset a clock during a cosimulation, you can do so in one of
these ways:
• By entering HDL simulator force commands at the HDL simulator

command prompt
• By specifying HDL simulatorforce commands in the Post- simulation
command text field on the Simulation pane of the HDL Verifier
Cosimulation block parameters dialog box.
See also “Clock, Reset, and Enable Signals” on page 8-88.
If you change any part of the Simulink model, including the HDL
Cosimulation block parameters, update the diagram to reflect those changes.
You can do this update in one of the following ways:
• Rerun the simulation

• Click the Update diagram button
• Select Simulation > Update Diagram
Avoid Race Conditions in HDL Simulation with

Component Cosimulation and the HDL Verifier HDL
Cosimulation Block
In the HDL simulator, you cannot control the order in which clock signals
(rising-edge or falling-edge) defined in the HDL Cosimulation block are
applied, relative to the data inputs driven by these clocks. If you are careful
to verify the relationship between the data and active edges of the clock, you
5-48
can avoid race conditions that could create differing cosimulation results. See
“Race Conditions in HDL Simulators” on page 8-62.
5-49
5-50
6
Record Simulink Signal

State Transitions for
Post-Processing
• “Add a Value Change Dump (VCD) File” on page 6-2

• “Visually Compare Simulink Signals with HDL Signals” on page 6-6
6 Record Simulink Signal State Transitions for Post-Processing
Add a Value Change Dump (VCD) File

In this section...
“Introduction to the To VCD File Block” on page 6-2
“Using the To VCD File Block” on page 6-3
Introduction to the To VCD File Block

A value change dump (VCD) file logs changes to variable values, such as the
values of signals, in a file during a simulation session. VCD files can be useful
during design verification. Some examples of how you might apply VCD files
include the following cases:
• For comparing results of multiple simulation runs, using the same or

different simulator environments
• As input to post-simulation analysis tools
• For porting areas of an existing design to a new design
VCD files can provide data that you might not otherwise acquire unless you
understood the details of a device’s internal logic. In addition, they include
data that can be graphically displayed or analyzed with postprocessing tools,
including, for example, the extraction of data about a particular section of a
design hierarchy or data generated during a specific time interval.
Another example, this specifically for ModelSim users, is the ModelSim

vcd2wlf tool, which converts a VCD file to a Wave Log Format (WLF) file that
you can view in a ModelSim wave window.
The To VCD File block provided in the HDL Verifier block library serves as a
VCD file generator during Simulink sessions. The block generates a VCD file
that contains information about changes to signals connected to the block’s
input ports and names the file with a specified file name.
Note The To VCD File block logs changes to states '1' and '0' only. The
block does not log changes to states 'X' and 'Z'.
6-2
Using the To VCD File Block

To generate a VCD file, perform the following steps:
2 Identify where you want to add the To VCD File block. For example, you
might temporarily replace a scope with this block.
3 In the Simulink Library Browser, click HDL Verifier and then select the
block library for your HDL simulator. You will see the HDL Cosimulation
block icon and the To VCD File block icon.
4 Copy the To VCD File block from the Library Browser to your model by
clicking the block and dragging it from the browser to your model window.
5 Connect the block ports to the applicable blocks in your Simulink model.
Note Because multidimensional signals are not part of the VCD

specification, they are flattened to a 1D vector in the file.
6 Configure the To VCD File block by specifying values for parameters in the
Block Parameters dialog box, as follows:
a Double-click the block icon. Simulink displays the following dialog box.
6-3
b Specify a file name for the generated VCD file in the VCD file name
text box.
• If you specify a file name only, Simulink places the file in your current
MATLAB folder.
• Specify a complete path name to place the generated file in a different
location.
• If you want the generated file to have a .vcd file type extension, you
must specify it explicitly.
6-4
Note Do not give the same file name to different VCD blocks. Doing so
results in invalid VCD files.
c Specify an integer in the Number of input ports text box that indicates
the number of block input ports on which signal data is to be collected.
The block can handle up to 943 (830,584) signals, each of which maps to
a unique symbol in the VCD file.
d Click OK.
7 Choose a timing relationship between Simulink and the HDL simulator.

The time scale options specify a correspondence between one second of
Simulink time and some quantity of HDL simulator time. Choose relative
time or absolute time. For more on the To VCD File time scale, see the
reference documentation for the To VCD File block.
8 Run the simulation. Simulink captures the simulation data in the VCD
file as the simulation runs.
For a description of the VCD file format see “VCD File Format”. For a sample
application of a VCD file, see “Visually Compare Simulink Signals with HDL
Signals” on page 6-6.
6-5
Visually Compare Simulink Signals with HDL Signals

In this section...
“Tutorial: Overview” on page 6-6
“Tutorial: Instructions” on page 6-6
Tutorial: Overview
Note This tutorial and the tool used are specific to ModelSim users; however,
much of the process will be the same for Incisive users with a similar tool. See
HDL simulator documentation for details.
VCD files include data that can be graphically displayed or analyzed with
postprocessing tools. An example of such a tool is the ModelSim vcd2wlf tool,
which converts a VCD file to a WLF file that you can then view in a ModelSim
wave window. This tutorial shows how you might apply the vcd2wlf tool.
Tutorial: Instructions
Perform the following steps to view VCD data:
1 Place a copy of the Manchester Receiver Simulink example

modelmanchestermodel in a writable folder.
2 Open your writable copy of the Manchester Receiver model. For example,
select File > Open, select the file manchestermodel and click Open. The
Simulink model should appear as follows. The HDL Cosimulation block is
marked “VHDL Manchester Receiver”.
6-6
Do not follow the numbered steps in the Manchester Receiver model.

Follow only the steps provided in this tutorial.
3 Open the Library Browser.
4 Replace the Signal Scope block with a To VCD File block, as follows:
a Delete the Signal Scope block. The lines representing the signal
connections to that block change to dashed lines, indicating the
disconnection.
b Find and open the HDL Verifier block library.
6-7
c Click “For Use with Mentor Graphics ModelSim” to access the HDL
Verifier Simulink blocks for use with ModelSim.
d Copy the To VCD File block from the Library Browser to the model by
clicking the block and dragging it from the browser to the location in
your model window previously occupied by the Signal Scope block.
e Double-click the To VCD File block icon. The Block Parameters dialog
box appears.
f Type MyVCDfile.vcd in the VCD file name text box.
g Type 4 in the Number of input ports text box.
h Click OK. Simulink applies the new parameters to the block.
5 Connect the signals Original Data, Recovered Data, Recovered Clock,

and Data Validity to the block ports. The following display highlights the
modified area of the model.
6-8
6 Save the model.
7 Select the following command line from the instructional text that appears
in the demonstration model:
vsim('tclstart',manchestercmds,'socketsimulink',4442)
8 Paste the command in the MATLAB Command Window and execute the
command line. This command starts ModelSim and configures it for a
Simulink cosimulation session.
9 Open the HDL Cosimulation block parameters dialog box and select the
Connection tab. Change the Connection method to Socket and “4442” for
the TCP/IP socket port. The port you specify here must match the value
specified in the call to the vsim command in the previous step.
10 Start the simulation from the Simulink model window.
11 When the simulation is complete, locate, open, and browse through the
generated VCD file, MyVCDfile.vcd (any text editor will do).
12 Close the VCD file.
13 Change your input focus to ModelSim and end the simulation.
14 Change the current folder to the folder containing the VCD file and enter
the following command at the ModelSim command prompt:
6-9
vcd2wlf MyVCDfile.vcd MyVCDfile.wlf
The vcd2wlf utility converts the VCD file to a WLF file that you display
with the command vsim -view.
15 In ModelSim, open the wave file MyVCDfile.wlf as data set MyVCDwlf

by entering the following command:
vsim -view MyVCDfile.wlf
16 Open the MyVCDwlf data set with the following command:
add wave MyVCDfile:/*
A wave window appears showing the signals logged in the VCD file.
17 Click the Zoom Full button to view the signal data. The wave window
should appear as follows.
6-10
18 Exit the simulation. One way of exiting is to enter the following command:
dataset close MyVCDfile
ModelSim closes the data set, clears the wave window, and exits the
simulation.
For more information on the vcd2wlf utility and working with data sets, see
the ModelSim documentation.
6-11
6-12
7
HDL Code Import for

Cosimulation
• “Import HDL Code With the HDL Cosimulation Wizard” on page 7-2
• “Invoking the Cosimulation Wizard” on page 7-5
• “Import HDL Code for MATLAB Function” on page 7-6
• “Import HDL Code for MATLAB System Object” on page 7-20
• “Import HDL Code for HDL Cosimulation Block” on page 7-37
• “Performing Cosimulation” on page 7-53
• “HDL Cosimulation Wizard Tutorials” on page 7-55
• “Help Button” on page 7-98
7 HDL Code Import for Cosimulation
Import HDL Code With the HDL Cosimulation Wizard

In this section...
“HDL Code Import Features” on page 7-2
“HDL Code Import Workflows” on page 7-3
“Cosimulation Wizard Navigation” on page 7-4
“Cosimulation Wizard Limitations” on page 7-4
HDL Code Import Features

The HDL Verifier Cosimulation Wizard lets you take existing HDL code,
from any source, and use it to create a MATLAB component or test bench
function, System object, or Simulink HDL Cosimulation block. You can then
use one of these cosimulation interfaces for cosimulation with a supported
HDL simulator (see “Supported EDA Tools and Hardware”).
Each cosimulation type workflow requires that you complete the generated
cosimulation interface when the wizard is completed. For example, if you
specified a MATLAB function, the generated script contains some simple port
I/O instructions and empty routines, which you will then need to complete
for HDL cosimulation.
What You Need to Know

You are expected to understand the following about the HDL code you want to
import:
• The name of the HDL files or compilation scripts to use in creating the
block or function
• For Simulink blocks and MATLAB System objects:
- The name of the top module to be used for cosimulation
- Output port types and sample times
- Whether there are clocks and resets and which of them you want to
use, and timing parameters
- Timescale
7-2
Import HDL Code With the HDL Cosimulation Wizard
• For MATLAB functions:

- Whether you want to create a component function or test bench function,
or both
- How you want to trigger the callback (rising or falling edge, repeat,
sensitivity)
For Simulink blocks, you must also have a destination model to receive the
newly-generated block.
What the Cosimulation Wizard Needs to Know

The Cosimulation Wizard guides you through specifying the following types
of information (some information depends on which type of cosimulation
interface you want it to create):
• Type of cosimulation (MATLAB, MATLAB System object, or Simulink)

• Which HDL simulator to use
• HDL files to be included and compilation instructions
• HDL module information
• Callback details
• Input and output port details
• Clock and reset information and HDL simulator start time alignment
HDL Code Import Workflows

To learn more about how to use the Cosimulation Wizard, follow the workflow
documentation specific to the cosimulation interface you want to create:

When you are ready to begin, start with “Invoking the Cosimulation Wizard”
on page 7-5.
7-3
Cosimulation Wizard Navigation

On each selection pane there is a status window and navigational options.
• The status window displays the current status of the options you have
selected. Warnings are displayed here also.
• Click Help to display this HDL Code Import topic.
• Click Cancel to exit the Cosimulation Wizard without creating a
cosimulation component.
• Click Back and Next to navigate forwards and backwards, respectively,
through the application. Note that you can move forwards only after you
have provided all information for the step you are on.
The last step of the Cosimulation Wizard generates the function scripts,
System objects, or blocks and launches the specified HDL simulator.
• If you select a function or System object, the MATLAB Editor opens with
the unfinished script or System object ready for editing.
• If you select a block, Simulink opens with the new block inside an untitled
model.
Cosimulation Wizard Limitations

• When creating an HDL Cosimulation block or System object for use with
Simulink, you may access only the I/O ports on the top level of the HDL
design. If you want to cosimulate at multiple levels of your design, you
cannot use this application to set up your HDL Cosimulation block or
System object.
• You cannot create multiple HDL Cosimulation blocks, nor can you use
multiple generated HDL Cosimulation blocks in the same model. This is
primarily because you can only access the top level of the HDL design.
There is no need for additional blocks.
7-4
Invoking the Cosimulation Wizard
Invoking the Cosimulation Wizard

1 Start MATLAB.
2 Enter the following command at the command prompt:
cosimWizard
The Cosimulation Wizard opens.
Select one of the following topics to continue instruction for the cosimulation
interface you selected:

7-5
Import HDL Code for MATLAB Function

In this section...
“Cosimulation Type—MATLAB Function” on page 7-6
“HDL Files—MATLAB Function” on page 7-8
“HDL Compilation—MATLAB Function” on page 7-10
“HDL Modules—MATLAB Function” on page 7-12
“Callback Schedule—MATLAB Function” on page 7-14
“Script Generation—MATLAB Function” on page 7-16
“Complete the Component or Test Bench Function” on page 7-17
Cosimulation Type—MATLAB Function

If you have not yet done so, invoke the Cosimulation Wizard. See “Invoking
the Cosimulation Wizard” on page 7-5.
7-6
1 In the Cosimulation Type pane, select MATLAB in the field HDL

cosimulation with to create a MATLAB function template (test bench
or component).
2 Select ModelSim or Incisive for the HDL Simulator.
3 Select Use HDL simulator executables on the system path if that is

where the files are located. The Cosimulation Wizard assumes by default
that they are on the system path.
If the HDL simulator executables are not on the system path, select Use
the following HDL simulator executables at the following location
and specify the folder location in the text box below.
If you click Next and the Cosimulation Wizard does not find the
executables, the following occurs:
• You are returned to this dialog and the Cosimulation Wizard displays
an error in the status pane.
7-7
• The Cosimulation Wizard switches the option to Use the following

HDL simulator executables at the following location.
• The Cosimulation Wizard makes the HDL simulation path field editable.
You must enter a valid path to the HDL simulator executables before you
are allowed to continue.
4 Click Next.
HDL Files—MATLAB Function
In the HDL Files pane, specify the files to be used in creating the function
or block.
• The Cosimulation Wizard attempts to determine the file type of each

file and display the type in the File List next to the file name. If the
7-8
Cosimulation Wizard cannot determine the type or displays the wrong

type, you can change the type directly in the File Type column.
• If possible, the Cosimulation Wizard will determine the compilation order
automatically using HDL simulator provided functionality. This means
you can add the files in any order.
• If you are using ModelSim, you will see compilation scripts listed as .do files
(ModelSim macro file). If you are using Incisive®, you will see compilation
scripts listed as system scripts.
1 Click Add to select one or more file names.
2 Remove files by first highlighting the file name in the File List, then
clicking Remove Selected File.
3 Click Next.
7-9
HDL Compilation—MATLAB Function
In the HDL Compilation pane, you can review the generated HDL
compilation commands. You may override and/or customize those commands,
if you wish. If you included compilation scripts instead of HDL files, this pane
will show you the command to run those scripts.
1 Enter any changes to the commands in the Compilation Commands box.
7-10
Note Do not include system shell commands; for example:
set file = a.vhd vcom $file
When control returns to the Cosimulation Wizard from executing the

command, the variable no longer holds the value that was set. If you do try
to include this type of command, you will see an error in the Status panel.
2 Click Restore default commands to go back to the generated HDL

compilation commands. You are asked to confirm that you want to discard
any changes.
3 Click Next to proceed.
7-11
HDL Modules—MATLAB Function
In the HDL Module pane, provide the name of the HDL module to be used
in cosimulation.
1 Enter the name of the module at Name of HDL module to cosimulate

with.
2 Specify additional simulation options at Simulation options. For

example, in the previous image, the options shown are:
• HDL simulator resolution
• Turn off optimizations that remove signals from the simulation view
Click Restore Defaults to change the options back to the default.
7-12
3 For Connection method, select Shared Memory if your firewall policy

does not allow TCP/IP socket communication.
4 Click Next to proceed to the next step. At this time in the process, the
application performs the following actions in a command window:
• Starts the HDL simulator.
• Loads the HDL module in the HDL simulator.
• Starts the HDL server, and waits to receive notice that the server has
started.
• Connects with the HDL server to get the port information.
• Disconnects and shuts down the HDL server.
7-13
Callback Schedule—MATLAB Function
1 In the Callback Schedule pane, enter multiple component or test

bench function callbacks from the HDL simulator. Enter the following
information for each callback function:
• Callback type: select matlabcp to create a component function or
matlabtb to create a test bench function.
• Callback name (optional): Specify the name of component or test
bench function, if it is not the same as the HDL component. The default
7-14
assumption is that the function name is the same as the HDL component
name.
• HDL component: Enter component name manually or browse for it
by clicking Browse.
• Trigger mode: Specify one of the following to trigger the callback
function:
– Repeat
– Rising Edge
– Falling Edge
– Sensitivity
• Sample time (ns) or Trigger Signal:
– If you selected trigger Repeat, enter the sample time in nanoseconds.
– If you selected Rising Edge, Falling Edge, or Sensitivity,
Sample time (ns) changes to Trigger Signal. Enter the signal
name to be used to trigger the callback.
You can browse the existing signals in the HDL component you specified
by clicking Browse.
2 Click Add to add the command to the MATLAB Callback Functions list.
If you have more callback functions you want to schedule, repeat the above
steps. If you want to remove any callback functions, highlight the line you
want to remove and click Remove.
Note If you attempt to add a callback function for the same HDL module
as an existing callback function in the MATLAB Callback Functions list,
the new callback function will overwrite the existing one (this is true even
if you change the callback type). You will see a warning in the Status
window:
Warning: This HDL component already has a scheduled callback function, which is
replaced by this new one.
7-15
3 Click Next.
Script Generation—MATLAB Function
1 Click Back to review or change your settings.
2 Click Finish to generate scripts.
7-16
Generated Files—MATLAB Function

The Cosimulation Wizard creates the following files and opens each one in a
separate MATLAB Editor windows.
• launchHDLsimulator: script for launching the HDL simulator for

cosimulation with MATLAB.
• compileHDLDesign: compilation script you can re-use for subsequent
compilation of this particular component.
• Function files (*.m): component and test bench customized function
templates, one for each component specified in the Cosimulation Wizard.
Complete the Component or Test Bench Function

The template that the wizard generates contains some simple port I/O
instructions and empty routines where you add your own code, as shown in the
example below. For a full example of creating and using a MATLAB function,
see “Verify Raised Cosine Filter Design Using MATLAB” on page 7-61.
function osc_top_u_osc_filter1x(obj)
% Automatically generated MATLAB(R) callback function.
% Copyright 2010 The MathWorks, Inc.

% $Revision $
% Initialize state of callback function.

if (strcmp(obj.simstatus,'Init'))
disp('Initializing states ...');
% Store port information in userdata

% The name strings of ports that sends data from HDL simulator to
% MATLAB callback function
obj.userdata.FromHdlPortNames = fields(obj.portinfo.out);
obj.userdata.FromHdlPortNum = length(fields(obj.portinfo.out));
% The name strings of ports that sends data from MATLAB callback
% function to HDL simulator
obj.userdata.ToHdlPortNames = fields(obj.portinfo.in);
obj.userdata.ToHdlPortNum = length(fields(obj.portinfo.in));
7-17
% Initialize state
obj.userdata.State = 0;
end
% Obj.tnow is the current HDL simulation time specified in seconds

disp(['Callback function is executed at time ' num2str(obj.tnow)]);
if(obj.userdata.FromHdlPortNum > 0)
% The name of the first input port
portName = obj.userdata.FromHdlPortNames{1};
disp(['Reading input port ' portName]);
% Convert the multi-valued logic value of the first port to decimal
portValueDec = mvl2dec( ...
obj.portvalues.(portName), ... % Multi-valued logic of the first port
obj.portinfo.out.(portName).size); %#ok<NASGU> % Bit width
% Then perform any necessary operations on this value passed by HDL simulator.
% ...
% Optionally, you can translate the port value into fixed point object,
% e.g.
% myfiobj = fi(portValueDec,1, 16, 4);
end
% Update your state(s). In the following example, we use this internal

% state to implement a one-bit counter
obj.userdata.State = ~obj.userdata.State;
if(obj.userdata.ToHdlPortNum > 0)
% The name of the first output port in HDL
portName = obj.userdata.ToHdlPortNames{1};
disp(['Writing output port ' portName]);
% Assign the first port value to internal state obj.userdata.State.

% Before assignment, convert decimal value to multi-valued logic.
% You can change obj.userdata.State to another other valid decimal values.
obj.portvalues.(portName) = dec2mvl(...
obj.userdata.State, ...
obj.portinfo.in.(portName).size);
% Operate on other out ports, if there are any.

% ...
7-18
end
7-19
Import HDL Code for MATLAB System Object

In this section...
“Cosimulation Type—MATLAB System Object” on page 7-20
“HDL Files—MATLAB System Object” on page 7-23
“HDL Compilation—MATLAB System Object” on page 7-25
“Simulation Options—MATLAB System Object” on page 7-26
“Input/Output Ports—MATLAB System Objects” on page 7-28
“Output Port Details—MATLAB System Object” on page 7-29
“Clock/Reset Details—MATLAB System Object” on page 7-30
“Start Time Alignment—MATLAB System Object” on page 7-31
“System Object Generation” on page 7-33
“Write System Object Test Bench” on page 7-34
“Run Cosimulation and Verify HDL Design” on page 7-36
Cosimulation Type—MATLAB System Object

7-20
1 In the Cosimulation Type pane, select MATLAB System object in the

field HDL cosimulation with.

7-21
4 Click Next.
7-22
HDL Files—MATLAB System Object
or block.

7-23

(ModelSim macro file). If you are using Incisive, you will see compilation
3 Click Next.
7-24
HDL Compilation—MATLAB System Object
7-25


any changes.
Simulation Options—MATLAB System Object
In the HDL Module pane, provide the name of the HDL module to be used
in cosimulation.
7-26

with.


started.
7-27
Input/Output Ports—MATLAB System Objects
1 In the Input/Output Ports pane, specify the type of each input and output
port (Input, Clock, Reset, or Unused).
• The Cosimulation Wizard attempts to determine the port types for you,
but you may override any setting.
• MATLAB forces clock and reset signals in the HDL simulator through
Tcl commands. You can specify clock and reset signal timing in a later
step (see “Clock/Reset Details—MATLAB System Object” on page 7-30).
2 Click Next.
7-28
Output Port Details—MATLAB System Object
1 In the Output Port Details pane, set the sample time and data type for
all output ports.
• Sample time default is 1, the data type default is Inherit and Signed.
These defaults are consistent with the way the HDL Cosimulation
block mask (Ports tab) sets default settings for output ports (Simulink
workflow).
• If you select Set all sample times and data types to ’Inherit’, the
ports inherit the times via back propagation (sample times are set to
-1). However, back propagation may fail in some circumstances; see
“Backpropagation in Sample Times”.
2 Click Next.
7-29
Clock/Reset Details—MATLAB System Object
1 In the Clock/Reset Details pane, set the clock and reset parameters.
• The time period specified here refers to time in the HDL simulator.
• The clock default settings are a rising active edge and a period of 10 ns.
• The reset default settings are an initial value of 0 and a duration of 15 ns.
7-30
The next screen provides a visual display of the simulation start time
where you can review how the clocks and resets line up.
2 Click Next.
Start Time Alignment—MATLAB System Object
1 In the Start Time Alignment pane, review the current settings for clocks
and resets. The purpose for this dialog is twofold:
7-31
• To make sure the rising or falling edge is set as expected (from the
previous step)
– Examine the start time. If it coincides with the active edge of the
clock, you need to adjust the HDL simulator start time.
– Examine the reset signal. If it is synchronous with the clock active
edge, you may have a possible race condition.
To avoid a race condition, make sure the start time does not coincide
with the active edge of any clocks. You can do this by moving the start
time or by changing clock active edges in the previous step.
• To make sure the start time is where you want it.
The HDL simulator start time is calculated from the clock and reset values
on the previous pane. If you want, you can change the HDL simulator
start time by entering a new value where you see HDL time to start
cosimulation (ns). Click Update plot to see your change applied.
2 Click Next.
7-32
System Object Generation
1 You can modify the HDL simulator sampling period before the wizard
generates the System object. Enter the new value in the box labeled HDL
Simulator sampling period (ns).
The sampling period determines the elapsed time in the HDL Simulator
separating each call to step in MATLAB. Most of the time the sampling
period is equal to the clock period.
2 If your inputs and outputs are frame based (instead of sample based), select
Frame based processing.
3 Click Finish.
After you click Finish, the wizard generates the following HDL files in the
current directory:
7-33
• compile_hdl_design_design_name.m: Script for recompiling the HDL

design
• launch_hdl_simulator_design_name.m: Script for relaunching the
MATLAB System object server and starting the HDL simulator
• hdlcosim_design_name.m: Script for creating the HdlCosimulation System
object
Write System Object Test Bench

Write the test bench for use with the newly generated HDL cosimulation
System object. The test bench you write might look similar to the example
shown next.
7-34
See “Import HDL Code for MATLAB System Object” on page 7-20 for a
demonstration of creating a HDL cosimulationSystem object and test bench.
7-35
Run Cosimulation and Verify HDL Design

1 Launch the HDL simulator by executing the launch script created by the
wizard (launch_hdl_simulator_design_name.m)
2 When the HDL simulator is ready, return to MATLAB and start the
simulation by executing the test bench.
3 Verify the results.
7-36
Import HDL Code for HDL Cosimulation Block

In this section...
“Cosimulation Type—Simulink Block” on page 7-37
“HDL Files—Simulink Block” on page 7-39
“HDL Compilation—Simulink Block” on page 7-41
“Simulation Options—Simulink Block” on page 7-43
“Input/Output Ports—Simulink Block” on page 7-45
“Output Port Details—Simulink Block” on page 7-46
“Clock/Reset Details—Simulink Block” on page 7-48
“Start Time Alignment—Simulink Block” on page 7-49
“Generate Block” on page 7-51
“Complete Simulink Model” on page 7-52
Cosimulation Type—Simulink Block

7-37
1 In the Cosimulation Type pane, select Simulink in the field HDL

cosimulation with to instruct the wizard to create aSimulink block.

7-38

4 Click Next.
HDL Files—Simulink Block
or block.

7-39

3 Click Next.
7-40
HDL Compilation—Simulink Block
7-41


any changes.
7-42
Simulation Options—Simulink Block
In the Simulation Options pane, provide the name of the HDL module
to be used in cosimulation.

with.

7-43

started.
7-44
Input/Output Ports—Simulink Block
1 In the Simulink Ports pane, specify the type of each input and output port.
• The Cosimulation Wizard attempts to determine the port types for you,
but you may override any setting.
• For input ports, select Input, Clock, Reset, or Unused.
• For output ports, select Output or Unused.
• Simulink forces clock and reset signals in the HDL simulator through
Tcl commands. You can specify clock and reset signal timing in a later
step (see “Clock/Reset Details—Simulink Block” on page 7-48).
7-45
• To drive your HDL clock and reset signals with Simulink signals, mark
them as Input.
2 Click Next to proceed to “Output Port Details—Simulink Block” on page

7-46.
Output Port Details—Simulink Block
1 In the Output Port Details pane, set the sample time and data type for
all output ports.
7-46
• Sample time default is 1, the data type default is Inherit and Signed.
These defaults are consistent with the way the HDL Cosimulation block
mask (Ports tab) sets default settings for output ports.
• If you select Set all sample times and data types to ’Inherit’, the
ports inherit the times via back propagation (sample times are set to
-1). However, back propagation may fail in some circumstances; see
“Backpropagation in Sample Times”.
2 Click Next.
7-47
Clock/Reset Details—Simulink Block
1 In the Clock/Reset Details pane, set the clock and reset parameters.
• The time period specified here refers to time in the HDL simulator.
• The clock default settings are a rising active edge and a period of 10 ns.
• The reset default settings are an initial value of 0 and a duration of 15 ns.
7-48
The next screen provides a visual display of the simulation start time
where you can review how the clocks and resets line up.
2 Click Next.
Start Time Alignment—Simulink Block
1 In the Start Time Alignment pane, review the current settings for clocks
and resets. The purpose for this dialog is twofold:
7-49
• To make sure the rising or falling edge is set as expected (from the
previous step)
– Examine the start time. If it coincides with the active edge of the
clock, you need to adjust the HDL simulator start time.
– Examine the reset signal. If it is synchronous with the clock active
edge, you may have a possible race condition.
To avoid a race condition, make sure the start time does not coincide
with the active edge of any clocks. You can do this by moving the start
time or by changing clock active edges in the previous step.
• To make sure the start time is where you want it.
The HDL simulator start time is calculated from the clock and reset values
on the previous pane. If you want, you can change the HDL simulator
start time by entering a new value where you see HDL time to start
cosimulation (ns). Click Update plot to see your change applied.
2 Click Next.
7-50
Generate Block
1 Specify if you want HDL Verifier to determine the timescale when you
start the simulation by selecting Automatically determine timescale
at start of simulation. If you prefer to determine the timescale yourself,
leave this box unchecked and enter the timescale value in the text boxes
below. The default is to automatically determine timescale.
For more about timescales, see the “Timescales Pane” section in the HDL
Cosimulation block reference.
7-51
2 Click Back to review or change your settings.
3 Click Finish to generate the HDL cosimulation block.
Complete Simulink Model

The Cosimulation Wizard creates a new, untitled mode containing the HDL
Cosimulation block and helper functions to compile HDL and launch the
HDL simulator.
1 Copy the HDL Cosimulation block and, if you wish, the helper functions,
from the newly generated model to the destination model.
2 Place the block so that the inputs and outputs to the HDL Cosimulation
block line up.
3 Connect the blocks in the destination model to the HDL Cosimulation block.
When you have completed the model, see “Performing Cosimulation” on page
7-53 for the next steps in HDL cosimulation.
7-52
Performing Cosimulation
Performing Cosimulation
When you are finished creating a function, System object, or block, select the
topic below that describes how you are planning to cosimulate your HDL code.
If you generated this Select one of these topics:

cosimulation interface:
MATLAB test bench function • With a completed test bench, you
(matlabtb) can start at the next step: “Place
Test Bench on MATLAB Search
Path” on page 1-20
• Review entire test bench function
workflow: “MATLAB as a Test
Bench” on page 1-2
MATLAB component function • With a completed component, you
(matlabcp) can start at the next step: “Place
Component Function on MATLAB
Search Path” on page 2-12
• Review entire test bench function
workflow: “MATLAB Function as
a Component” on page 2-2
MATLAB System object With a completed System object,
you are ready to use it for HDL
verification. See “Verify Viterbi
Decoder Using MATLAB System
Object and Mentor Graphics
ModelSim” on page 3-3 for an
example of using the MATLAB
System object for HDL cosimulation.
Simulink Block With a completed HDL cosimulation
block, you can continue with one of
the following topics:
• “Run a Test Bench Cosimulation

Session” on page 4-44
7-53
If you generated this Select one of these topics:

cosimulation interface:
• “Run a Component Cosimulation

Session” on page 5-43
In either workflow, you must place

your HDL cosimulation block within
a test bench or component model.
See “Create Simulink Model for
Test Bench Cosimulation” on page
4-8 or “Create Simulink Model for
Component Cosimulation” on page
5-10.
You can also view the following examples:
• “Verify Raised Cosine Filter Design Using MATLAB” on page 7-61

• “Verify Raised Cosine Filter Design Using Simulink” on page 7-77
7-54
HDL Cosimulation Wizard Tutorials

In this section...
“Cosimulation Wizard for MATLAB System Object” on page 7-55
“Verify Raised Cosine Filter Design Using MATLAB” on page 7-61
“Verify Raised Cosine Filter Design Using Simulink” on page 7-77
Cosimulation Wizard for MATLAB System Object

This example guides you through the basic steps for setting up an HDL
Verifier™ application using the Cosimulation Wizard.
This example use a MATLAB System object and ModelSim to verify a register
transfer level (RTL) design of a Fast Fourier Transform (FFT) of size 8 written
in Verilog. The FFT is commonly used in digital signal processing to produces
frequency distribution of a signal.
To verify the correctness of this FFT, a MATLAB System object testbench is

provided. This testbench generates a periodic sinusoidal input to the HDL
design under test (DUT) and plots the Fourier Coefficients in the Complex
Plane.
The Cosimulation Wizard takes the provided Verilog file of this FFT as its
input. It also collects user input required for setting up cosimulation in
each step. At the end of the example, the Cosimulation Wizard generates
a MATLAB script that instantiates a configured HdlCosimulation System
object, a MATLAB script that compiles HDL design, and a MATLAB script
that launches the HDL simulator for cosimulation.
1. Set Up Example Files
To ensure that others can access copies of the example files, set up a folder for
your own example work by following these instructions:
a. Create a folder outside the scope of your MATLAB installation folder into
which you can copy the example files. The folder must be writable. This
example assumes that you create a folder named ’MyTests’.
7-55
b. Copy all the files located in the following directory to the folder you created:
matlabroot\toolbox\edalink\foundation\hdllink\demo_src\tutorial_fft
c. You now have all the example files you need in your working directory:
• fft_tb.m
• fft_hdl.v
• fft_hdl_tc.v
2. Launch Cosimulation Wizard
a. Start MATLAB.
b. Set the directory you created in Set Up Example Files as your current
directory in MATLAB.
c. At the MATLAB command prompt, enter the following:
>>cosimWizard
The command launches the Cosimulation Wizard.
3. Specify Cosimulation Type
In the Cosimulation Type page, perform the following steps:
a. Change HDL cosimulation with option set to MATLAB System Object.
b. If you are using ModelSim, change HDL Simulator option as ModelSim.
c. Leave the default option Use HDL simulator executables on the system
path option if the HDL simulator executables appear on your system path. If
these executable do not appear on the path, specify the HDL simulator path.
d. Click Next to proceed to the HDL Files page.
7-56
4. Select HDL Files
In the HDL Files page, perform the following steps:
a. Add HDL files to file list:
• Click Add and select the Verilog files fft_hdl.v and fft_hdl_tc.v in your
example folder.
• Review the files in the file list to make sure the file type is correctly
identified.
b. Click Next to proceed to the HDL Compilation page.
5. Specify HDL Compilation Commands
The Cosimulation Wizard lists the default commands in the Compilation

Commands window. You do not need to change these commands for this
example.
Click Next. The MATLAB console displays the compilation log. If an error
occurs during compilation, that error appears in the Status area. Correct the
error before proceeding to the next step.
6. Select HDL Modules for Cosimulation
In the HDL Modules page, perform the following steps:
a. Specify the name of HDL module/entity for cosimulation. From the

drop-down list, select fft_hdl. This module is the Verilog module you use for
cosimulation. If you do not see "fft_hdl" in the drop-down list, you can enter
the file name manually.
b. In the Simulation options field, remove the -novopt option so that

ModelSim can optimize the HDL design.
7-57
c. Click Next. The Cosimulation Wizard launches the HDL simulator in the
background console using the specified HDL module and simulation options.
If the wizard launches the HDL simulator successfully, the wizard populates
the input and output ports on the Verilog model fft_hdl and displays them
in the next step.
7. Specify Input/Output Port Types
In this step, the Cosimulation Wizard displays two tables containing the input
and output ports of fft_hdl, respectively.
The Cosimulation Wizard attempts to correctly identify the port type for each
port. If the wizard incorrectly identifies a port, you can change the port type
using these tables.
• For input ports, you can select from Clock, Reset, Input, or Unused. HDL
Verifier connects only the input ports marked "Input" to MATLAB during
cosimulation.
• HDL Verifier connects output ports marked Output with MATLAB during
cosimulation. The link software and MATLAB ignore those output ports
marked "Unused during cosimulation.
• You can change the parameters for signals identified as "Clock" and "Reset"
at a later step.
Accept the default port types and click Next to proceed to the Output Port
Details page.
8. Specify Output Port Details
For this example, the HDL FFT outputs are signed, 13 bits long with 9 bits of
fraction length. In the Output Port Details page, perform the following steps:
7-58
a. Note that the Sample Time can not be changed and is always fixed to 1
with the HdlCosimulation System object .
b. Change the Data Type to Signed for both outputs
c. Change the Fraction Length to 9 for both outputs
c. Click Next to proceed to the Clock/Reset Details page.
9. Set Clock and Reset Details
Set the clock Period (ns) to 20. From the Verilog code, you know that the
reset is synchronous and the active value is 1. You can reset the entire HDL
design at time 1 ns, triggered by the rising edge of the clock. Use a duration
of 15 ns for the reset signal. In the Clock/Reset Details page, perform the
following steps:
a. Set clock period to 20.
b. Leave or set active edge to Rising.
c. Leave or set reset initial value to 1.
d. Set reset signal duration to 15.
Click Next to proceed to the Start Time Alignment page.
10. Confirm Start Time Alignment
The Start Time Alignment page displays a plot for the waveforms of clock
and reset signals. The Cosimulation Wizard shows the HDL time to start
cosimulation with a red line. The start time is also the time at which the
System object gets the first input sample from the HDL simulator. The active
edge of clock is a rising edge. Thus, at time 20 ns in the HDL simulator,
7-59
the registered output of the FFT is stable. No race condition exists, and the
default HDL time to start cosimulation (20 ns) is correct.
Click Next to proceed to System Object Generation.
11. Generate System Object
a. Before Cosimulation Wizard generates the scripts, you have the option to
modify the HDL Simulator sampling period. The sampling period determine
the elapsed time in the HDL Simulator separating each call to step in
MATLAB. Most of the time the sampling period is equal to the clock period.
You can also specify if your inputs/outputs are frame based (instead of sample
based).
b. Click Finish to complete the Cosimulation Wizard session.
12. Create Test Bench to Verify HDL Design
For this example, you do not actually create the test bench. Instead, you
can find the finished script fft_tb.m in the directory you created in Set Up
Example Files.
a. After you click Finish in the Cosimulation Wizard, the application

generates three HDL files in the current directory:
• compile_hdl_design_fft_hdl.m: To recompile the HDL design

• launch_hdl_simulator_fft_hdl.m: To relaunch the MATLAB System
object server and start the HDL simulator.
• hdlcosim_fft_hdl.m: To create the HdlCosimulation System object
b. Open the files fft_tb.m and hdlcosim_fft_hdl.m, located in the directory

you created in Set Up Example Files and observe the HdlCosimulation
System object calls. hdlcosim_fft_hdl.m contains the HdlCosimulation
7-60
instanciation and fft_tb.m contains a MATLAB System object test bench. You
will use this test bench to verify the HDL design for which you just generated
a corresponding HdlCosimulation System object .
13. Run Cosimulation and Verify HDL Design
a. Launch the HDL simulator by executing the script

launch_hdl_simulator_fft_hdl.m.
>>launch_hdl_simulator_fft_hdl.m
b. When the HDL simulator is ready, return to MATLAB and start the
simulation by executing the script fft_tb.m.
>>fft_tb.m
c. Verify the result from the plot in the test bench. The plot display the
Fourier Coefficients in the Complex Plane.
This concludes the Cosimulation Wizard for use with MATLAB System object
example.
Verify Raised Cosine Filter Design Using MATLAB

• “MATLAB and Cosimulation Wizard Tutorial Overview” on page 7-62
• “Tutorial: Set Up Tutorial Files (MATLAB)” on page 7-63
• “Tutorial: Launch Cosimulation Wizard (MATLAB)” on page 7-64
• “Tutorial: Configure the Component Function with the Cosimulation
Wizard” on page 7-64
• “Tutorial: Customize Callback Function” on page 7-72
• “Tutorial: Run Cosimulation and Verify HDL Design” on page 7-76
7-61
MATLAB and Cosimulation Wizard Tutorial Overview

This tutorial guides you through the basic steps for setting up an HDL Verifier
cosimulation that uses MATLAB and the HDL Simulator. This cosimulation
verifies an HDL design using a MATLAB component as the test bench. In
this tutorial, you perform the steps to cosimulate MATLAB with the HDL
simulator to verify the suitability of a raised cosine filter written in Verilog.
Note This tutorial requires MATLAB, the HDL Verifier software, and the
ModelSim or Incisive HDL simulator. This tutorial also assumes that you
have read “Import HDL Code for MATLAB Function” on page 7-6.
The HDL test bench instantiates two raised-cosine filter components: one is
implemented in HDL, and the other is associated with a MATLAB callback
function. The test bench also generates stimulus to both filters and compares
their outputs.
7-62
Tutorial: Set Up Tutorial Files (MATLAB)

To help others access copies of the tutorial files, set up a folder for your own
tutorial work by following these instructions:
tutorial assumes that you create a folder named MyTests.
2 Copy all the files located in the following MATLAB folder to the folder
you created:
matlabroot\toolbox\edalink\foundation\hdllink\demo_src\tutorial
where matlabroot is the MATLAB root directory on your system.
7-63
3 You now have the following files in your working folder:
• filter_tb.v
• mycallback_solution.m
• rcosflt_beh.v
• rcosflt_rtl.v
• rcosflt_tb.mdl (not used in this tutorial)
Tutorial: Launch Cosimulation Wizard (MATLAB)
1 Start MATLAB.
2 Set the folder you created in “Tutorial: Set Up Tutorial Files (MATLAB)”
on page 7-63 as your current folder in MATLAB.
3 At the MATLAB command prompt, enter:
>>cosimWizard
This command launches the Cosimulation Wizard.
Tutorial: Configure the Component Function with the

Cosimulation Wizard
This tutorial leads you through the following wizard pages, designed to assist
you in creating an HDL Verifier component function:
• “Tutorial: Specify Cosimulation Type (MATLAB)” on page 7-64

• “Tutorial: Select HDL Files (MATLAB)” on page 7-66
• “Tutorial: Specify HDL Compilation Commands (MATLAB)” on page 7-67
• “Tutorial: Select HDL Modules for Cosimulation (MATLAB)” on page 7-68
• “Tutorial: Specify Callback Schedule” on page 7-70
• “Tutorial: Generate Script” on page 7-71
Tutorial: Specify Cosimulation Type (MATLAB). In the Cosimulation

Type page, perform the following steps:
7-64
1 Change HDL cosimulation with option set to MATLAB.
2 If you are using ModelSim, leave HDL Simulator option as ModelSim.
If you are using Incisive, change HDL Simulator option to Incisive.
3 Leave the default option Use HDL simulator executables on the system
path option if the HDL simulator executables appear on your system path.
If the executables do not appear in the path, specify the HDL simulator
path as described in “Cosimulation Type—MATLAB Function” on page 7-6.
5 Click Next to proceed to the HDL Files page.
7-65
Tutorial: Select HDL Files (MATLAB). In the HDL Files page, perform the
following steps:
1 Add HDL files to file list.
a Click Add and browse to the directory you created in “Tutorial: Set Up
Tutorial Files (MATLAB)” on page 7-63.
b Select the Verilog files filter_tb.v, rcosflt_rtl.v, and
rcosflt_beh.v. You can select multiple files in the file browser by
holding down the CTRL key while selecting the files with the mouse.
c Review the file in the file list with the file type identified as you expected.
2 Click Next to proceed to the HDL Compilation page.
7-66
Tutorial: Specify HDL Compilation Commands (MATLAB). Cosimulation

Wizards lists the default commands in the Compilation Commands window.
You do not need to change these defaults for this tutorial.
1 Examine compilation commands.
a ModelSim users: Your HDL Compilation pane looks similar to the

following.
b Incisive users: Your HDL Compilation commands will look similar to

the following:
ncvlog -update "/mathworks/home/user/MyTests/filter_tb.v"
7-67
ncvlog -update "/mathworks/home/user/MyTests/rcosflt_beh.v"

ncvlog -update "/mathworks/home/user/MyTests/rcosftl_rtl.v"
2 Click Next to proceed to the HDL Modules pane.
The MATLAB console displays the compilation log. If an error occurs during
compilation, that error appears in the Status area. Change whatever
settings you can to remove the error before proceeding to the next step.
Tutorial: Select HDL Modules for Cosimulation (MATLAB). In the HDL

Modules pane, perform the following steps:
1 Specify the name of the HDL module/entity for cosimulation.
At Name of HDL module to cosimulate with, select filter_tb from the

drop-down list to specify the Verilog module you will use for cosimulation.
7-68
If you do not see filter_tb in the drop-down list, you can enter it manually.

3 Click Next to proceed to the Callback Schedule page.
Cosimulation Wizard launches the HDL simulator in the background

console using the specified HDL module and simulation options. After the
wizard launches the HDL simulator, the Callback Schedule page appears.
On Windows® systems, the console remains open. Do not close the console;
the application closes this window upon completion.
7-69
Tutorial: Specify Callback Schedule. In the Callback Schedule page,

1 Leave Callback type as matlabcp (default). This type instructs the

Cosimulation Wizard to create a MATLAB callback function as a component
for cosimulation with the HDL simulator.
2 Leave Callback function name as callback_fcn. The wizard gives this

name to the generated MATLAB callback function.
3 For HDL component, click Browse. Click the expander icon next to
filter_tb to expand the selection. Select u_rcosflt_beh, and click OK.
You have specified to the Cosimulation Wizard that the HDL simulator
associate this component with the MATLAB callback function.
4 Set Trigger mode to Rising Edge.
5 For Trigger Signal, click Browse. Click the expander icon next to
filter_tb to expand the selection. Select u_rcosflt_beh. In the ports list
on the right, select clk. Click OK.
6 Click Add. The Cosimulation Wizard generates the corresponding

matlabcp command that associates the HDL module u_rcosflt_beh with the
MATLAB function callback_fcn, as shown in the following image:
7-70
For more information on the callback parameters, see the reference page
for matlabcp.
7 Click Next to proceed to the Generate Script page.
Tutorial: Generate Script.
1 Leave Launch HDL simulator after exiting this dialog selected.
7-71
2 Click Finish to complete the Cosimulation Wizard session and generate

scripts.
Tutorial: Customize Callback Function

After you click Finish in the Cosimulation Wizard, the application generates
three HDL files in the current directory:
• compile_hdl_design.m: For recompiling the HDL design

• launch_hdl_simulator.m: To relaunch the MATLAB server and start the
HDL simulator.
• callback_fcn.m: The MATLAB callback function
7-72
In addition to launching the HDL simulator, HDL Verifier software opens the
MATLAB Editor and loads callback_fcn.m (partial image shown).
The generated template comprises four parts:
7-73
• Initialize internal state(s) of callback function

• Read signal from HDL component
• Write signal to HDL component
• Update internal state(s)
You modify this template to model a raised cosine filter in MATLAB following
the instructions as shown in the following sections.
• “Tutorial: Define Internal States” on page 7-74

• “Tutorial: Read Signal from HDL Component” on page 7-75
• “Tutorial: Write Signal to HDL Component” on page 7-75
• “Tutorial: Update Internal States” on page 7-76
Note You can find a completed modified callback function in

mycallback_solution.m. This function resides in the directory you copied the
tutorial files into. You can use this file to overwrite the one in your current
directory. Name the function "callback_fcn.m", and change the function name
to "callback_fcn".
Tutorial: Define Internal States. Define two internal states: a 49-element

vector to hold filter inputs and a vector of filter coefficients.
Edit callback_fcn.m so that the internal state section contains the following
code:
7-74
Tutorial: Read Signal from HDL Component. Read the filter input and
convert it to a decimal number in MATLAB.
Edit callback_fcn.m so that the read signal section contains the following code:
Tutorial: Write Signal to HDL Component. The input "reset" signal

controls the filter output. If reset is low, then the output is the product of
previous inputs and filter coefficients. MATLAB converts the decimal result
to a multivalued logic output of the HDL component.
Edit callback_fcn.m so that the write signal section contains the following
code:
7-75
Tutorial: Update Internal States. Use the filter input to update the
internal 49-element state.
Edit callback_fcn.m so that the update internal states section contains the
following code:
Tutorial: Run Cosimulation and Verify HDL Design

Switch to the HDL simulator and enter the following command in the HDL
simulator console:
run 200 ns
You see the following output displayed in the HDL simulator:
7-76
These messages indicate that the output of the HDL component matches the
behavioral output of the MATLAB component.
Verify Raised Cosine Filter Design Using Simulink

• “Simulink and Cosimulation Wizard Tutorial Overview” on page 7-77
• “Tutorial: Set Up Tutorial Files (Simulink)” on page 7-78
• “Tutorial: Launch Cosimulation Wizard (Simulink)” on page 7-79
• “Tutorial: Configure the HDL Cosimulation Block with the Cosimulation
• “Tutorial: Create Test Bench to Verify HDL Design” on page 7-92
• “Tutorial: Run Cosimulation and Verify HDL Design” on page 7-95
Simulink and Cosimulation Wizard Tutorial Overview

This tutorial guides you through the basic steps for setting up an HDL
Verifier application that uses Simulink and the HDL simulator to verify an
7-77
HDL design, using a Simulink model as the test bench. In this tutorial, you
perform the steps to cosimulate Simulink and the HDL simulator to verify a
simple raised cosine filter written in Verilog.
Note This tutorial requires Simulink, the HDL Verifier software, and the
ModelSim or Incisive HDL simulator. This tutorial assumes that you have
read “Import HDL Code for HDL Cosimulation Block” on page 7-37.
In this tutorial, you perform the following steps:
1 “Tutorial: Set Up Tutorial Files (Simulink)” on page 7-78
2 “Tutorial: Launch Cosimulation Wizard (Simulink)” on page 7-79
3 “Tutorial: Configure the HDL Cosimulation Block with the Cosimulation

4 “Tutorial: Create Test Bench to Verify HDL Design” on page 7-92
5 “Tutorial: Run Cosimulation and Verify HDL Design” on page 7-95
Tutorial: Set Up Tutorial Files (Simulink)

To help others access copies of the tutorial files, set up a folder for your own
tutorial work by following these instructions:
tutorial assumes that you create a folder named MyTests.
2 Copy all the files located in the following directory to the folder you created:
matlabroot\toolbox\edalink\foundation\hdllink\demo_src\tutorial
where matlabroot is the MATLAB root directory on your system.
3 You now have all the following files in your working directory, although,
for this tutorial, you will need only two of them:
• filter_tb.v (not used for this tutorial)
7-78
• mycallback_solution.m (not used for this tutorial)

• rcosflt_beh.v (not used for this tutorial)
• rcosflt_rtl.v
• rcosflt_tb.mdl
Tutorial: Launch Cosimulation Wizard (Simulink)
1 Start MATLAB.
2 Set the directory you created in “Tutorial: Set Up Tutorial Files (Simulink)”
on page 7-78 as your current directory in MATLAB.
3 At the MATLAB command prompt, enter the following:
>>cosimWizard
The command launches the Cosimulation Wizard.
Tutorial: Configure the HDL Cosimulation Block with the

Cosimulation Wizard
This tutorial leads you through the following wizard pages, designed to assist
you in creating an HDL Cosimulation block.
• “Tutorial: Specify Cosimulation Type (Simulink)” on page 7-80

• “Tutorial: Select HDL Files (Simulink)” on page 7-80
• “Tutorial: Specify HDL Compilation Commands (Simulink)” on page 7-81
• “Tutorial: Select Simulation Options for Cosimulation (Simulink)” on page
7-83
• “Tutorial: Specify Port Types” on page 7-85
• “Tutorial: Specify Output Port Details” on page 7-87
• “Tutorial: Set Clock and Reset Details” on page 7-88
• “Tutorial: Confirm Start Time Alignment” on page 7-90
• “Tutorial: Generate Block” on page 7-91
7-79
Tutorial: Specify Cosimulation Type (Simulink). In the Cosimulation

Type page, perform the following steps:
1 Leave HDL cosimulation with option set to Simulink.
2 If you are using ModelSim, leave HDL Simulator option as ModelSim.
If you are using Incisive, change HDL Simulator option to Incisive.
3 Leave the default option Use HDL simulator executables on the system
path option if the HDL simulator executables appear on your system path.
If these executable do not appear on the path, specify the HDL simulator
path as described in “Cosimulation Type—Simulink Block” on page 7-37.
4 Click Next to proceed to the HDL Files page.
Tutorial: Select HDL Files (Simulink). In the HDL Files page, perform the
following steps:
7-80
1 Add HDL files to file list.
a Click Add and browse to the directory you created in “Tutorial: Set Up
Tutorial Files (Simulink)” on page 7-78.
b Select the Verilog file rcosflt_rtl.v.
c Review the file in the file list with the file type identified as you expected.
2 Click Next to proceed to the HDL Compilation page.
Tutorial: Specify HDL Compilation Commands (Simulink). The

Cosimulation Wizard lists the default commands in the Compilation
Commands window. You do not need to change these commands for this
tutorial.
7-81
When you run the Cosimulation Wizard with your own code, you may add or
change the compilation commands in this window. For example, you can add
-vlog01compat to add the —vlog01compat switch.
ModelSim users: The HDL Compilation pane will look similar to the one
in this figure:
Incisive users: Your HDL Compilation pane will look similar to the one in
7-82
Click Next to proceed to the HDL Modules pane.
The MATLAB console displays the compilation log. If an error occurs during
compilation, that error appears in the Status area. Change whatever settings
you can to remove the error before proceeding to the next step.
Tutorial: Select Simulation Options for Cosimulation (Simulink). In the

Simulation Options pane, perform the following steps:
1 Specify the name of HDL module/entity for cosimulation.
From the drop-down list, select "rcosflt_rtl". This module is the Verilog
module you use for cosimulation.
7-83
If you do not see "rcosflt_rtl" in the drop-down list, you can enter the file
name manually.
2 ModelSim users: In the Simulation options field, remove the -novopt option
so that ModelSim can optimize the HDL design.

The simulation options now look similar to those shown in the next figure.
Incisive users: Your HDL Module options look similar to the following
figure
7-84
4 Click Next to proceed to the Simulink Ports pane.
The Cosimulation Wizard launches the HDL simulator in the background

console using the specified HDL module and simulation options. After
the wizard launches the HDL simulator, the wizard populates the input
and output ports on the Verilog model rcosflt_rtl and displays them in
the next step.
Tutorial: Specify Port Types. In this step, the Cosimulation Wizard displays
two tables containing the input and output ports of rcosflt_rtl, respectively.
7-85
The Cosimulation Wizard attempts to identify the port type for each port. If
the wizard incorrectly identifies a port, you can change the port type using
these tables.
• For input ports, you can select from Clock, Reset, Input, or Unused. HDL
Verifier connects only the input ports marked "Input" to Simulink during
cosimulation.
• HDL Verifier connects output ports marked Output with Simulink during
cosimulation. The wizard and Simulink ignore those output ports marked
"Unused during cosimulation.
• You can change the parameters for signals identified as "Clock“ and "Reset"
at a later step.
Accept the default port types and click Next to proceed to the Output Port
Details page.
7-86
Tutorial: Specify Output Port Details. In the Output Port Details page,
1 Set the sample time of filter_out to -1 to inherit via back propagation.
2 You can see from the Verilog code that the Cosimulation Wizard represents
the output in a S34,29 format. Change the following fields:
• Data Type to Fixedpoint
• Sign to Signed
• Fraction Length to 29
. Your results now look similar to the following image.
7-87
3 Click Next to proceed to the Clock/Reset Details page.
Tutorial: Set Clock and Reset Details. For this tutorial, set the clock
Period (ns) to 20. From the Verilog code, you know that the reset is
synchronous and the active value is 1. You can reset the entire HDL design
at time 1 ns, triggered by the rising edge of the clock. Use a duration of 15
ns for the reset signal.
In the Clock/Reset Details page, perform the following steps:
1 Set clock period to 20.
7-88
2 Leave or set active edge to Rising.
3 Leave or set reset initial value to 1.
4 Set reset signal duration to 15.
Your clock and reset are now the same as those same signals shown in
7-89
5 Click Next to proceed to the Start Time Alignment page.
Tutorial: Confirm Start Time Alignment. The Start Time Alignment page
displays a plot for the waveforms of clock and reset signals. The Cosimulation
Wizard shows the HDL time to start cosimulation with a red line. The start
time is also the time at which the Simulink gets the first input sample from
the HDL simulator.
1 Set or confirm Start Time Alignment
The active edge of our clock is a rising edge. Thus, at time 20 ns in the
HDL simulator, the registered output of the raised cosine filter is stable.
No race condition exists, and the default HDL time to start cosimulation
(20 ns) is what we want for this simulation. You do not need to make any
changes to the start time.
7-90
2 Click Next to proceed to Block Generation.
Tutorial: Generate Block. Before you generate the HDL Cosimulation

block, you have the option to determine the timescale before you finish
the Cosimulation Wizard. Alternately, you can instruct HDL Verifier to
calculate a timescale later. Timescale calculation by the verification software
occurs after you connect all the input/output ports of the generated HDL
Cosimulation block and start simulation.
7-91
1 Leave Automatically determine timescale at start of simulation

selected (default). Later, you will have the opportunity to view the
calculated timescale and change that value before you begin simulation.
2 Click Finish to complete the Cosimulation Wizard session.
Tutorial: Create Test Bench to Verify HDL Design

For this tutorial, you do not actually create the test bench. Instead, you
can find the finished model (rcosflt_tb.mdl) in the directory you created in
“Tutorial: Set Up Tutorial Files (Simulink)” on page 7-78.
1 After you click Finish in the Cosimulation Wizard, Simulink creates a

model and populates it with the following items:
7-92
• An HDL Cosimulation block

• A block to recompile the HDL design (contains a link to a script that is
launched by double-clicking the block)
• A block to launch the HDL simulator (contains a link to a script that is
launched by double-clicking the block)
Leave the model for the moment and proceed to the next step.
2 Open the file rcosflt_tb, located in the directory you created in “Tutorial:
Set Up Tutorial Files (Simulink)” on page 7-78.
This file contains a model of a Simulink test bench. You will use this
test bench to verify the HDL design for which you just generated a
corresponding HDL Cosimulation block.
7-93
3 Add the HDL Cosimulation block to the test bench model as follows:
a Copy the HDL Cosimulation block from the newly generated model to
this test bench model.
b Place the block so that the constant and convert blocks line up as inputs
to the HDL Cosimulation block and the bus lines up as output.
c Connect the blocks in the test bench to the HDL Cosimulation block.
4 Copy the script blocks to the area below the test bench. Your model now
looks similar to that in the following figure.
7-94
5 Save the model.
Tutorial: Run Cosimulation and Verify HDL Design
1 Launch the HDL simulator by double-clicking the block labeled Launch

HDL Simulator.
2 When the HDL simulator is ready, return to Simulink and start the
simulation.
3 Determine timescale.
Recall that you selected Automatically determine timescale at start of

simulation option on the last page of the Cosimulation Wizard. Because
you did so, HDL Verifier launches the Timescale Details GUI instead of
starting the simulation.
Both the HDL simulator and Simulink sample the filter_in and filter_out
ports at 1 second. However, their sample time in the HDL simulator should
be the same as the clock period (2 ns).
a Change the Simulink sample time of /rcosflt_rtl/filter_in to 1 (seconds),
and press Enter. The wizard then updates the table. The following
figure shows the new timescale: 1 second in Simulink corresponds to
2e-008 s in the HDL simulator.
7-95
b Click OK to exit Timescale Details.
4 Restart simulation.
5 Verify the result from the scope in the test bench model. The scope
displays both the delayed version of input to raised cosine filter and that
filter’s output. If you sample the output of this filter output directly, no
inter-symbol-interference occurs
7-96
This step concludes the Cosimulation Wizard for use with Simulink tutorial.
7-97
Help Button
In this section...
“Cosimulation Type” on page 7-98
“HDL Files” on page 7-100
“HDL Compilation” on page 7-102
“HDL Modules” on page 7-103
Cosimulation Type
1 Select your HDL Cosimulation workflow in the field HDL cosimulation

with: Simulink, MATLAB, or MATLAB System Object. This setting
instructs the wizard to create a block, function template, or System object,
respectively.
7-98
Help Button
2 Select the HDL simulator you want to use: ModelSim or Incisive.

Next Steps
• For an HDL cosimulation block, start at “Cosimulation Type—Simulink
Block” on page 7-37.
• For an HDL cosimulation function, start at “Cosimulation Type—MATLAB
Function” on page 7-6.
• For an HDL cosimulation System object, start at “Cosimulation
Type—MATLAB System Object” on page 7-20.
7-99
HDL Files
or block.
The Cosimulation Wizard attempts to determine the file type of each

If you are using ModelSim, you will see compilation scripts listed as .do files
7-100
Help Button
Next Steps
• For an HDL cosimulation block, start at “HDL Files—Simulink Block”
on page 7-39.
• For an HDL cosimulation function, start at “HDL Files—MATLAB
• For an HDL cosimulation System object, start at “HDL Files—MATLAB
System Object” on page 7-23.
7-101
HDL Compilation
7-102
Help Button


any changes.
Next Steps
• For an HDL cosimulation block, start at “HDL Compilation—Simulink
• For an HDL cosimulation function, start at “HDL Compilation—MATLAB
• For an HDL cosimulation System object, start at “HDL
Compilation—MATLAB System Object” on page 7-25.
HDL Modules
HDL Modules—Simulink Block
7-103
In the HDL Modules pane, provide the name of the HDL module to be used
in cosimulation.

with.

7-104
Help Button
3 When you proceed to the next step, the application performs the following
actions in a command window:
started.
Next Steps
• For an HDL cosimulation block, start at “Simulation Options—Simulink
• For an HDL cosimulation function, start at “HDL Modules—MATLAB
• For an HDL cosimulationSystem object, start at “Simulation
Options—MATLAB System Object” on page 7-26.
7-105
7-106
8
HDL Cosimulation
Reference
• “Startup for HDL Cosimulation” on page 8-2

• “Test Bench and Component Function Options” on page 8-35
• “Direct Feedthrough Cosimulation” on page 8-46
• “Simulation Speed Improvement Tips” on page 8-51
• “Race Conditions in HDL Simulators” on page 8-62
• “Data Type Conversions” on page 8-65
• “Simulation Timescales” on page 8-74
• “Clock, Reset, and Enable Signals” on page 8-88
• “TCP/IP Socket Ports” on page 8-95
8 HDL Cosimulation Reference
Startup for HDL Cosimulation

In this section...
“Machine Configuration Requirements” on page 8-2
“HDL Simulator Startup” on page 8-4
“HDL Verifier Libraries” on page 8-11
“Setup Diagnostics and Customization” on page 8-18
“Cross-Network Cosimulation” on page 8-27
Machine Configuration Requirements

• “Valid Configurations For Using the HDL Verifier Software with MATLAB
Applications” on page 8-2
• “Valid Configurations For Using the HDL Verifier Software with Simulink
Software” on page 8-4
Valid Configurations For Using the HDL Verifier Software with

MATLAB Applications
The following list provides samples of valid configurations for using the
HDL simulator and the HDL Verifier software with MATLAB software.
The scenarios apply whether the HDL simulator is running on the same
or different computing system as the MATLAB software. In a network
configuration, you use an Internet address in addition to a TCP/IP socket port
to identify the servers in an application environment.
• An HDL simulator session connected to a MATLAB function foo through a

single instance of the MATLAB server
• An HDL simulator session connected to multiple MATLAB functions (for
example, foo and bar) through a single instance of the MATLAB server
• An HDL simulator session connected to a MATLAB function foo through
multiple instances of the MATLAB server (each running within the scope
of a unique MATLAB session)
8-2
• Multiple HDL simulator sessions each connected to a MATLAB function

foo through multiple instances of the MATLAB server (each running
within the scope of a unique MATLAB session)
• Multiple HDL simulator sessions each connected to a different MATLAB
function (for example, foo and bar) through the same instance of the
MATLAB server
• Multiple HDL simulator sessions each connected to MATLAB function foo
through a single instance of the MATLAB server
Although multiple HDL simulator sessions can connect to the same
MATLAB function in the same instance of the MATLAB server, as this
configuration scenario suggests, such connections are not recommended.
If the MATLAB function maintains state (for example, maintains global
or persistent variables), you may experience unexpected results because
the MATLAB function does not distinguish between callers when handling
input and output data. If you must apply this configuration scenario,
consider deriving unique instances of the MATLAB function to handle
requests for each HDL entity.
Notes
• Shared memory communication is an option for configurations that require

only one communication link on a single computing system.
• TCP/IP socket communication is required for configurations that use
multiple communication links on one or more computing systems. Unique
TCP/IP socket ports distinguish the communication links.
• In any configuration, an instance of MATLAB can run only one instance of
the HDL Verifier MATLAB server (hdldaemon) at a time.
• In a TCP/IP configuration, the MATLAB server can handle multiple client
connections to one or more HDL simulator sessions.
8-3
Valid Configurations For Using the HDL Verifier Software with

Simulink Software
The following list provides samples of valid configurations for using the
HDL simulator and the HDL Verifier software with Simulink software.
The scenarios apply whether the HDL simulator is running on the same or
different computing system as the MATLAB or Simulink products. In a
network configuration, you use an Internet address in addition to a TCP/IP
socket port to identify the servers in an application environment.
• An HDL Cosimulation block in a Simulink model connected to a single

HDL simulator session
• Multiple HDL Cosimulation blocks in a Simulink model connected to the
same HDL simulator session
• An HDL Cosimulation block in a Simulink model connected to multiple
HDL simulator sessions
• Multiple HDL Cosimulation blocks in a Simulink model connected to
different HDL simulator sessions
Notes
• HDL Cosimulation blocks in a Simulink model can connect to the same or

different HDL simulator sessions.
• TCP/IP socket communication is required for configurations that use
multiple communication links on one or more computing systems. Unique
TCP/IP socket ports distinguish the communication links.
• Shared memory communication is an option for configurations that require
only one communication link on a single computing system.
HDL Simulator Startup

• “Starting the HDL Simulator from MATLAB” on page 8-5
• “Starting the HDL Simulator from a Shell” on page 8-9
8-4
Starting the HDL Simulator from MATLAB
• “Overview” on page 8-5

• “Starting the ModelSim Simulator from MATLAB” on page 8-6
• “Starting the Cadence Incisive Simulator from MATLAB” on page 8-8
Overview. For each supported HDL simulator, HDL Verifier has a

unique command to launch the HDL simulator from within MATLAB. Each
command contains a set of customized property value pairs for specifying the
HDL Verifier library to use, the design to load, the type of communication
connection, and so on.
Note If you plan to use the Cosimulation Wizard, you do not need to start
the HDL simulator separately.
The HDL simulator launch commands are as follows:,
HDL Simulator HDL Verifier Launch Command

Cadence Incisive nclaunch
Mentor Graphics vsim
ModelSim
• You issue the launch command directly from MATLAB and provide the
HDL Verifier library information and other required parameters (see
“HDL Verifier Libraries” on page 8-11). No special setup is required. This
function starts and configures the HDL simulator for use with the HDL
Verifier software. By default, the function starts the first version of the
simulator executable that it finds on the system path (defined by the path
variable), using a temporary file that is overwritten each time the HDL
simulator starts.
• You can customize the startup file and communication mode to be used
between MATLAB or Simulink and the HDL simulator by specifying the
call to the HDL simulator launch command with property name/property
value pairs. Refer to the nclaunch or vsim reference documentation for
specific information regarding the property name/property value pairs.
8-5
• If you want to start a different version of the simulator executable than the
first one found on the system path, use the setenv and getenv MATLAB
functions to set and get the environment of any sub-shells spawned by
UNIX(), DOS(), or system().
• When you specify a communication mode using any of the HDL Verifier
HDL simulator launch commands, the function applies the specified
communication mode to all MATLAB or Simulink/HDL simulator sessions.
Resources
• “Starting the ModelSim Simulator from MATLAB” on page 8-6, and
“Starting the Cadence Incisive Simulator from MATLAB” on page 8-8 for
examples of using these HDL Verifier HDL simulator launch commands
with various property/name value pairs and other parameters.
•
• “Linking with MATLAB and the HDL Simulator” for more information on
how HDL Verifier links the HDL simulator with MATLAB.
• “Verify HDL Model with MATLAB Testbench” on page 1-41 for a full
cosimulation example that demonstrates starting the HDL simulator from
MATLAB.
Diagnostic and Customization Setup Script for use with Incisive and
ModelSim If you would like some assistance in setting up your environment
for use with HDL Verifier, you can diagnose your setup (remove or fix
omissions and errors) and also customize your setup for future invocations
of nclaunch or vsim by following the process in “Setup Diagnostics and
Customization” on page 8-18.
Starting the ModelSim Simulator from MATLAB. To start the HDL

simulator from MATLAB, enter vsim at the MATLAB command prompt:
>> vsim('PropertyName', 'PropertyValue'...)
The following example changes the folder location to VHDLproj and then
calls the function vsim. Because the command line omits the 'vsimdir'
and 'startupfile' properties, vsim creates a temporary DO file. The
8-6
'tclstart' property specifies Tcl commands that load and initialize the HDL
simulator for test bench instance modsimrand.
cd VHDLproj
vsim('tclstart',...
'vsimmatlab modsimrand; matlabtb modsimrand 10 ns -socket 4449')
The following example changes the folder location to VHDLproj and then
calls the function vsim. Because the function call omits the 'vsimdir'
and 'startupfile' properties, vsim creates a temporary DO file. The
'tclstart' property specifies a Tcl command that loads the VHDL entity
parse in library work for cosimulation between vsim and Simulink. The
'socketsimulink' property specifies TCP/IP socket communication on the
same computer, using socket port 4449.
cd VHDLproj
vsim('tclstart', 'vsimulink work.parse', 'socketsimulink', '4449')
The following example has the HDL compilation and simulation commands
run when you start the ModelSim software from MATLAB.
vsim('tclstart',
{'vlib work', 'vlog +acc clocked_inverter.v hdl_top.v', 'vsim +acc hdl_top' });
This next example loads the HDL simulation just as in the previous example
but it also loads in the Link to Simulink library, uses socket number 5678
to communicate with cosimulation blocks in Simulink models, and uses an
HDL time precision of 10 ps.
vsim('tclstart',
{'vlib work', 'vlog -novopt clocked_inverter.v hdl_top.v',
'vsimulink hdl_top -socket 5678 -t 10ps'});
Or
vsim('tclstart',
{'vlib work', 'vlog -novopt clocked_inverter.v hdl_top.v',
'vsimulink hdl_top -t 10ps'},
'socketsimulink', 5678);
8-7
Starting the Cadence Incisive Simulator from MATLAB. To start the HDL
simulator from MATLAB, enter nclaunch at the MATLAB command prompt:
>> nclaunch('PropertyName', 'PropertyValue'...)
The following example changes the folder location to VHDLproj and then calls
the function nclaunch. Because the command line omits the 'hdlsimdir'
and 'startupfile' properties, nclaunch creates a temporary file. The
'tclstart' property specifies Tcl commands that load and initialize the HDL
simulator for test bench instance modsimrand.
cd VHDLproj
nclaunch('tclstart',...
'hdlsimmatlab modsimrand; matlabtb modsimrand 10 ns -socket 4449')
The following example changes the folder location to VHDLproj and then calls
the function nclaunch. Because the function call omits the 'hdlsimdir'
and 'startupfile' properties, nclaunch creates a temporary file. The
'tclstart' property specifies a Tcl command that loads the VHDL entity
parse in library work for cosimulation between nclaunch and Simulink. The
'socketsimulink' property specifies TCP/IP socket communication on the
same computer, using socket port 4449.
cd VHDLproj
nclaunch('tclstart', 'hdlsimulink work.parse', 'socketsimulink', '4449')
Another option is to bring ncsim up in the terminal instead of launching the

Simvision GUI, thereby allowing you to interact with the simulation. This
next example lists the steps for you to do this:
1 Start hdldaemon in MATLAB.
2 Start an xterm from MATLAB in the background (key point).
3 Run ncsim in the xterm shell having it call back to the hdlserver to run
your matlabcp function as usual.
4 Have the matlabcp function touch a file to signal completion while an M

script polls for completion.
The MATLAB script can then change test parameters and run more tests.
8-8
Note The nclaunch command requires the use of property name/property

value pairs. You get an error if you try to use the function without them.
Starting the HDL Simulator from a Shell
• “Starting the ModelSim Software from a Shell” on page 8-9

• “Starting the Cadence Incisive HDL Simulator from a Shell” on page 8-10
Starting the ModelSim Software from a Shell. To start the HDL

simulator from a shell and include the HDL Verifier libraries, you need to
first run the configuration script. See “Setup Diagnostics and Customization”
on page 8-18.
After you have the configuration files, you can start the ModelSim software
from the shell by typing:
% vsim design_name -f matlabconfigfile
matlabconfigfile should be the name of the MATLAB configuration file you

created with syscheckmq (Linux/UNIX) or that you created yourself using our
template (Windows). If you are connecting to Simulink, this should be the
name of the Simulink configuration file. You must also specify the path to
the configuration file even if it resides in the same folder as vsim.exe. Use
design_name if you want to also start the simulation.
The configuration file mainly defines the -foreign option to vsim which in turn
loads the HDL Verifier shared library and specifies its entry point.
You can also specify any other existing configuration files you may also be
using with this call.
If you are performing this step manually, the following use of -foreign with
vsim loads the HDL Verifier client shared library and specifies its entry point:
% vsim design_name -foreign matlabclient /path/library
8-9
where path is the path to this particular HDL Verifier library. See“HDL
Verifier Libraries” on page 8-11 to find the applicable library name for your
machine. Use design_name if you want to also start the simulation.
Note You can also issue this exact same command from inside the HDL
simulator.
Starting the Cadence Incisive HDL Simulator from a Shell. To start

the HDL simulator from a shell and include the HDL Verifier libraries, you
need to first run the configuration script. See “Using the Configuration and
Diagnostic Script for UNIX/Linux” on page 8-19.
After you have the configuration files, you can start the HDL simulator from
the shell by typing:
% ncsim -f matlabconfigfile modelname
matlabconfigfile should be the name of the MATLAB configuration file you

created with syscheckin. If you are connecting to Simulink, this should be
the name of the Simulink configuration file. For example:
% ncsim -gui -f simulinkconfigfile modelname
Either way, you must also specify the path to the configuration file if it does
not reside in the same folder as ncsim.exe.
You can also specify any other existing configuration files you may also be
using with this call.
Starting ncsim in an xtermTerminal
If you would like to bring up ncsim in an xterm terminal, instead of launching

the Simvision GUI, perform the following steps:
1 Start hdldaemon in MATLAB.
2 Start an xterm from MATLAB in the background.
8-10
3 Run ncsim in the xterm shell, having it call back to the hdlserver to run
your matlabtb function as usual.
4 Specify that the matlabtb function use the touch command on a file to
signal completion while a MATLAB script polls for completion.
The MATLAB script can then change test parameters and run more tests.
HDL Verifier Libraries

In general, you want to use the same compiler for all libraries linked into
the same executable. The verification software provides many versions of
the same library compilers that are available with the HDL simulators
(usually some version of GCC). Using the same libraries helps the software
stay compatible with other C++ libraries that may get linked into the HDL
simulator, including SystemC libraries.
If you have any of these conditions, choose the version of the HDL Verifier
library that matches the compiler used for that code:
• Link other third-party applications into your HDL simulator.

• Compile and link in SystemC code as part of your design or test bench.
• Write custom C/C++ applications and link them into your HDL simulator.
If you do not link any other code into your HDL simulator, you can use
any version of the supplied libraries. The HDL Verifier launch command
(nclaunch or vsim) chooses a default version of this library.
For examples on specifying HDL Verifier libraries when cosimulating across a

network, see “Cross-Network Cosimulation” on page 8-27.
Library Names
The HDL Verifier HDL libraries use the following naming format:
edalink/extensions/version/arch/lib{version_short_name}{client_server_tag}
_{compiler_tag).{libext}
where
8-11
Argument Incisive ModelSim Users

Users
version incisive modelsim
arch linux32 or linux32, linux64, windows32, or
linux64 windows64
version_short_name lfihdl lfmhdl
client_server_tag c (MATLAB) c (MATLAB) or s (Simulink)
or s
(Simulink)
compiler_tag gcc41, gcc44, Linux®: gcc412, gcc433, gcc450,
tmwgcc tmwgcc
Windows 32: gcc421vc9, tmwvs
Windows 64: gcc450, tmwvs
libext so dll or so
Not all combinations are supported. See “Default Libraries” on page 8-12
for valid combinations.
For more on MATLAB build compilers, see MATLAB Build Compilers.
Default Libraries
HDL Verifier scripts fully support the use of default libraries.
The following table lists all the libraries shipped with the verification software
for each supported HDL simulator. The default libraries for each platform
are in bold text.
8-12
Default Libraries for use with ModelSim
Platform MATLAB Library Simulink Library

Linux 32, liblfmhdlc_tmwgcc.so liblfmhdls_tmwgcc.so
64 liblfmhdlc_gcc412.so liblfmhdls_gcc412.so
liblfmhdlc_gcc433.so liblfmhdls_gcc433.so
Windows liblfmhdlc_tmwvs.dll liblfmhdls_tmwvs.dll
32 liblfmhdlc_gcc421.dll liblfmhdls_gcc421.dll
liblfmhdlc_gcc421vc9.dll liblfmhdls_gcc421vc9.dll
Windows liblfmhdlc_tmwvs.dll liblfmhdls_tmwvs.dll
64
Note ModelSim uses gcc412 by default; HDL Verifier uses tmwgcc or tmwvs
by default. Therefore, if you are compiling HDL code in ModelSim make
sure you are compiling with the same library that HDL Verifier is using;
either tmwgcc or twmvs by default or gcc412 if you so specified with the
vsim command.
Default Libraries for use with Incisive
Platform MATLAB Library Simulink Library

Linux32, liblfihdlc_gcc41.so liblfihdls_gcc41.so
Linux64 liblfihdlc_gcc44.so liblfihdls_gcc44.so
liblfihdlc_tmwgcc.so liblfihdls_tmwgcc.so
Using an Alternative Library

The HDL Verifier launch commands contain parameters for specifying the
HDL-side library.
• “Incisive Users: Using an Alternative Library” on page 8-14

• “ModelSim Users: Using an Alternative Library” on page 8-16
8-13
Incisive Users: Using an Alternative Library. You can use a different

HDL-side library by specifying it explicitly using the libfile parameter to the
nclaunch MATLAB command. You should choose the version of the library
that matches the compiler and system libraries you are using for any other
C/C++ libraries linked into the HDL simulator. Depending on the version of
your HDL simulator, you may need to explicitly set additional paths in the
LD_LIBRARY_PATH environment variable.
For example, if you want to use a nondefault library:
1 Copy the system libraries from the MATLAB installation (found in

matlabroot/sys/os/platform) to the machine with the HDL simulator
(where matlabroot is your MATLAB installation and platform is one of the
above architecture, for example, linux32).
2 Modify the LD_LIBRARY_PATH environment variable to add the path to

the system libraries that were copied in step 1.
Example: HDL Verifier Alternate Library Using nclaunch
In this example, you are using the 32-bit Linux version of IUS 11.10-s005
on the same 64-bit Linux machine that is running MATLAB. Because you
have your own C++ application, and you are linking into ncsim that you used
twmgcc to compile, you are using the HDL Verifier version compiled with
tmwgcc, instead of using the default library version compiled with GCC 4.1.
In MATLAB:
>> currPath = getenv('PATH');

>> currLdPath = getenv('LD_LIBRARY_PATH');
>> setenv('PATH', ['/tools/IUS-1110/bin:' currPath]);
>> nclaunch('tclstart', { 'exec ncvhdl inverter.vhd', ...
'exec ncelab -access +rwc inverter', ...
'hdlsimulink -gui inverter' }, ...
'libfile', liblfihdls_tmwgcc');
The PATH is changed so that we get the desired version of the HDL simulator
tools. Note that the nclaunch MATLAB command will detect the use of the
32-bit version of the HDL simulator and use the linux32 library folder in the
8-14
HDL Verifier installation; there is no need to specify the libdir parameter

in this case.
The library resolution can be verified using ldd from within the ncsim console
GUI.
ncsim> exec ldd /path/to/liblfihdls_tmwgcc.so

linux-gate.so.1 => (0xf7f4f000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7ed9000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7deb000)
libm.so.6 => /lib32/libm.so.6 (0xf7dc7000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7dba000)
libc.so.6 => /lib32/libc.so.6 (0xf7c67000)
/lib/ld-linux.so.2 (0xf7f50000)
Example: HDL Verifier Alternate Library Using System Shell
This example shows how to load a Cadence Incisive simulator session by

explicitly specifying the HDL Verifier library (default or not). By explicitly
using a system shell, you can execute this example on the same machine as
MATLAB, on a different machine, and even on a machine with a different
operating system.
In this example, you are running the 64-bit Linux version of Cadence Incisive
10.2-s040; it does not matter what machine MATLAB is running on. Instead
of using the default library version compiled with GCC 3.2.3 in the Cadence
Incisive distribution, you are using the version compiled with GCC 4.4.
In a csh-compatible system shell:
csh> setenv PATH /tools/ius/lnx/tools/bin/64bit:${PATH}

csh> setenv LD_LIBRARY_PATH /tools/ius/lnx/tools/systemc/gcc/4.4-x86_64
/install/lib64:${LD_LIBRARY_PATH}
csh> ncvhdl inverter.vhd
csh> ncelab -access +rwc inverter
csh> ncsim -tcl -loadvpi /tools/matlab/toolbox/edalink/extensions/incisive/linux64
/liblfihdlc_gcc44:matlabclient inverter.vhd
The PATH is changed so that we get the desired version of the Cadence
Incisive tools. Although ncsim will find any GCC libs in its installations,
8-15
the LD_LIBRARY_PATH is changed to show how you might do this with a

custom installation of GCC.
You can check the library resolution using ldd as in the previous example.
ModelSim Users: Using an Alternative Library. You can use a different

HDL-side library by specifying it explicitly using the libfile parameter to
the vsim MATLAB command. You should choose the version of the library
that matches the compiler and system libraries you are using for any other
C/C++ libraries linked into the HDL simulator. Depending on the version of
your HDL simulator, you may need to explicitly set additional paths in the
LD_LIBRARY_PATH environment variable.
For example, if you want to use a nondefault library:
1 Copy the system libraries from the MATLAB installation (found in

matlabroot/sys/os/platform) to the machine with the HDL simulator
(where matlabroot is your MATLAB installation and platform is one of the
above architecture, for example, linux32).
2 Modify the LD_LIBRARY_PATH environment variable to add the path to

the system libraries that were copied in step 1.
Example: HDL Verifier Alternative Library Using vsim
In this example, you run the 32-bit Linux version of ModelSim SE 10 software
on the same 64-bit Linux machine which is running MATLAB. Because you
want to incorporate some SystemC designs, you are using theHDL Verifier
version compiled with gcc450. You can download this version of GCC with
its associated system libraries from Mentor Graphics, instead of using the
default library version compiled with tmwgcc.
In MATLAB:
>> currPath = getenv('PATH');

>> currLdPath = getenv('LD_LIBRARY_PATH');
>> setenv('PATH', ['/tools/modelsim-10.1c/bin:' currPath]);
>> setenv('LD_LIBRARY_PATH', ['/tools/modelsim-10.1c/gcc-4.5.0-linux/lib:' currLdPath]);
>> setenv('MTI_VCO_MODE', '32');
8-16
>> vsim('tclstart', { 'vlib work', 'vcom inverter.vhd', 'vsimulink inverter' }, ...

'libfile', ' liblfmhdls_gcc412);
You change the PATH so that you get the desired version of the ModelSim
software. You change the LD_LIBRARY_PATH because the HDL simulator
does not add the path to the system libraries. The HDL Verifier function
vsim detects the use of the 32-bit version of the HDL simulator and uses the
linux32 library folder in the verification software installation; there is no
need to specify the libdir parameter in this case.
The library resolution can be verified using ldd from within the ModelSim
GUI:
exec ldd /path/to/liblfmhdls_gcc450.so

# linux-gate.so.1 => (0xf7efc000)
# libpthread.so.0 => /lib32/libpthread.so.0 (0xf7e8a000)
# libstdc++.so.6 => /mathworks/hub/share/apps/HDLTools/ModelSim/modelsim-10.1c-tmw-000/
modeltech/gcc-4.5.0-linux/lib/libstdc++.so.6 (0xf7d9c000)
# libm.so.6 => /lib32/libm.so.6 (0xf7d78000)
# libgcc_s.so.1 => /mathworks/hub/share/apps/HDLTools/ModelSim/modelsim-10.1c-tmw-000/
modeltech/gcc-4.5.0-linux/lib/libgcc_s.so.1 (0xf7d6d000)
# libc.so.6 => /lib32/libc.so.6 (0xf7c1b000)
# /lib/ld-linux.so.2 (0xf7efd000)
Example: HDL Verifier Alternate Library Using System Shell
This example shows how to load a ModelSim session by explicitly specifying

the HDL Verifier library (either the default or one of the alternatives). By
explicitly using a system shell, you can execute this example on the same
machine as MATLAB, on a different machine, and even on a machine with a
different operating system.
In this example, you are running the 64-bit Linux version of QuestaSim 10.1a.
It does not matter which machine is running MATLAB. Instead of using the
HDL Verifier default library version compiled with tmwgcc, you are using the
version compiled with GCC 4.5.0. You can download this version of GCC with
its associated system libraries from Mentor Graphics.
In a csh-compatible system shell:
csh> setenv PATH /tools/questasim/bin:${PATH}
8-17
csh> setenv LD_LIBRARY_PATH /tools/mtigcc/gcc-4.5.0-linux_x86_64/lib64:${LD_LIBRARY_PATH}

csh> setenv MTI_VCO_MODE 64
csh> vlib work
csh> vcom +acc+inverter inverter.vhd
csh> vsim +acc+inverter -foreign "matlabclient /tools/matlab/toolbox/edalink
/extensions/modelsim/linux64/liblfmhdlc_gcc450.so" work.inverter
You change the PATH so that you get the desired version of the ModelSim
software. You change the LD_LIBRARY_PATH because the HDL simulator
does not add the path to the system libraries unless you are working with
10.1+ and have placed GCC at the root of the ModelSim installation.
You can check the library resolution using ldd as in the previous example.
Setup Diagnostics and Customization

• “Overview to the HDL Verifier Configuration and Diagnostic Script” on
page 8-18
• “Using the Configuration and Diagnostic Script for UNIX/Linux” on page
8-19
• “Using the Configuration and Diagnostic Script with Windows” on page 8-26
Overview to the HDL Verifier Configuration and Diagnostic

Script
HDL Verifier software provides a guided setup script (syscheckmq for
ModelSim users and syscheckin for Incisive users) for configuring the
MATLAB and Simulink connections to your simulator. This script works
whether you have installed the verification software and MATLAB on the
same machine as the HDL simulator or installed them on different machines.
The setup script creates a configuration file containing the location of the
specified HDL Verifier MATLAB and Simulink libraries. You can then
include this configuration with any other calls you make using the command
vsim (ModelSim) or ncsim (Incisive) from the HDL simulator. You only need
to run this script once.
8-18
Note The HDL Verifier configuration and diagnostic script works only on
UNIX and Linux. Windows users: please see instructions below.
You can find the setup scripts in the following folder:
matlabroot/toolbox/edalink/foundation/hdllink/scripts
Refer to “HDL Verifier Libraries” on page 8-11 for the application library
for your platform.
For assistance in performing cross-network cosimulation, see “Cross-Network

After you have created your configuration files, see “Starting the HDL
Simulator from a Shell” on page 8-9.
Using the Configuration and Diagnostic Script for UNIX/Linux

The setup script provides an easy way to configure your simulator setup to
work with the HDL Verifier software.
The following is an example of running the setup script under the following
conditions:
• You have installed HDL Verifier on a Linux 64 machine.

• You have moved the HDL Verifier libraries to a different location than
where you first installed them (either to another folder or to another
machine).
• You want to test the TCP/IP connection.
Running the Configuration and Diagnostic Script for ModelSim

(syscheckmq)
Start the script by typing syscheckmq at a system prompt. The system

returns the following information:
% syscheckmq
********************************************************************************
8-19
Kernel name: Linux

Kernel release: 2.6.22.8-mw017
Machine: x86_64
********************************************************************************
The script first returns the location of the HDL simulator installation
(vsim.exe). If it does not find an installation, you receive an error message.
Either provide the path to the installation or quit the script and install the
HDL simulator. You are then prompted to accept this installation or provide
a path to another one, after which you receive a message confirming the HDL
simulator installation:
Found /hub/share/apps/HDLTools/ModelSim/modelsim-6.4a-tmw-000/modeltech/bin/vsim
on the path.
Press Enter to use the path we found or enter another one:
********************************************************************************
/hub/share/apps/HDLTools/ModelSim/modelsim-6.4a-tmw-000/modeltech/bin/vsim -version
Model Technology ModelSim SE-64 vsim 6.4a Simulator 2008.08 Aug 28 2008
ModelSim mode: 32 bits
********************************************************************************
Next, the script needs to know where it can find the HDL Verifier libraries.
Select method to search for HDL Verifier libraries:

1. Use libraries in a MATLAB installation.
2. Prompt me to specify the direct path to the libraries.
2
Enter the path to liblfmhdlc_tmwgcc.so and liblfmhdls_tmwgcc.so:
/tmp/extensions/modelsim/linux64
Found /tmp/extensions/modelsim/linux64/liblfmhdlc_tmwgcc.so
and /tmp/extensions/modelsim/linux64/liblfmhdls_tmwgcc.so.
The script then runs a dependency checker to check for supporting libraries.
If any of the libraries cannot be found, you probably need to append your
environment path to find them.
8-20
********************************************************************************
Running dependency checker "ldd /tmp/extensions/modelsim/linux64/liblfmhdlc_tmwgcc.so".

Dependency checker passed.
Dependency status:
librt.so.1 => /lib/librt.so.1 (0x00002acfe566e000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002acfe5778000)
libm.so.6 => /lib/libm.so.6 (0x00002acfe5976000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002acfe5af8000)
libc.so.6 => /lib/libc.so.6 (0x00002acfe5c6000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
********************************************************************************
This next step loads the HDL Verifier libraries and compiles a test module to
verify the libraries loaded as expected.
Press Enter to load HDL Verifier or enter 'n' to skip this test:
Reading /mathworks/hub/share/apps/HDLTools/ModelSim/modelsim-6.4a-tmw-000/se/modeltech/
linux_x86_64/../modelsim.ini "worklfx9019" maps to directory worklfx9019.
(Default mapping)
Model Technology ModelSim SE-64 vlog 6.4a Compiler 2008.08 Aug 28 2008
-- Compiling module d9019
Top level modules:

d9019
********************************************************************************
Reading /mathworks/hub/share/apps/HDLTools/ModelSim/modelsim-6.4a-tmw-000/se/modeltech/tcl
/vsim/pref.tcl
# 6.4a
# vsim -do exit -foreign {matlabclient /tmp/lfmconfig/linux64/liblfmhdlc_tmwgcc.so}

-noautoldlibpath -c worklfx9019.d9019
# // ModelSim SE-64 6.4a Aug 28 Linux 2.6.22.8-mw017
.
.
.
8-21
# Loading work.d9019
# Loading /tmp/lfmconfig/linux64/liblfmhdlc_tmwgcc.so
# exit
********************************************************************************
HDL Verifier libraries loaded successfully.

********************************************************************************
Next, the script checks a TCP connection. If you choose to skip this step, the
configuration file specifies use of shared memory. Both shared memory and
socket configurations are in the configuration file; depending on your choice,
one configuration or the other is commented out.
Press Enter to check for TCP connection or enter 'n' to skip this test:
Enter an available port [5001]
Enter remote host [localhost]
Press Enter to continue
ttcp_glnx -t -p5001 localhost

Connection successful
Lastly, the script creates the configuration file, unless for some reason you
choose not to do so at this time.
********************************************************************************
Press Enter to Create Configuration files or 'n' to skip this step:
********************************************************************************
Created template files simulink9675.arg and matlab8675.arg. Inspect and modify

if desired.
********************************************************************************
Diagnosis Completed
8-22
The template file names, in this example simulink24255.arg and

matlab24255.arg, have different names each time you run this script.
After the script is complete, you can leave the configuration files where they
are or move them to wherever it is convenient.
Running the Configuration and Diagnostic Script for Cadence Incisive

(syscheckin)
Start the script by typing syscheckin at a system prompt. The system

returns the following information:
% syscheckin
********************************************************************************
Kernel name: Linux

Kernel release: 2.6.22.8-mw017
Machine: x86_64
********************************************************************************
The script first returns the location of the HDL simulator installation
(ncsim.exe). If it does not find an installation, you receive an error message.
Either provide the path to the installation or quit the script and install the
HDL simulator. You are then prompted to accept this installation or provide
a path to another one, after which you receive a message confirming the HDL
simulator installation:
Found /hub/share/apps/HDLTools/IUS/IUS-61-tmw-000/lnx/tools/bin/64bit/ncsim on the path.

Press Enter to use the path we found or enter another one:
********************************************************************************
/hub/share/apps/HDLTools/IUS/IUS-61-tmw-000/lnx/tools/bin/64bit/ncsim -version
TOOL: ncsim(64) 06.11-s005
Cadence Incisive mode: 64 bits
********************************************************************************
Next, the script needs to know where it can find the HDL Verifier libraries.
Select method to search for HDL Verifier libraries:
8-23
1. Use libraries in a MATLAB installation.

2. Prompt me to specify the direct path to the libraries.
2
Enter the path to liblfihdlc_gcc323.so and liblfihdls_gcc323.so:
tmp/extensions/incisive/linux64
Found /tmp/extensions/incisive/linux64/liblfihdlc_gcc323.so
and /tmp/extensions/incisive/linux64/liblfihdls_gcc323.so.
The script then runs a dependency checker to check for supporting libraries.
If any of the libraries cannot be found, you probably need to append your
environment path to find them.
********************************************************************************
Running dependency checker "ldd /tmp/extensions/incisive/linux64/liblfihdlc_gcc323.so".

Dependency checker passed.
Dependency status:
librt.so.1 => /lib/librt.so.1 (0x00002b6119631000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00002b611973a000)
libm.so.6 => /lib/libm.so.6 (0x00002b6119916000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b6119a99000)
libc.so.6 => /lib/libc.so.6 (0x00002b6119ba6000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b6119de3000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
********************************************************************************
This next step loads the HDL Verifier libraries and compiles a test module to
verify the libraries loaded as expected.
Press Enter to load HDL Verifier or enter 'n' to skip this test:
ncvlog(64): 06.11-s005: (c) Copyright 1995-2007 Cadence Design Systems, Inc.

define linux64 /work/matlab/toolbox/incisive/linux64
.
.
.
ncsim> exit
********************************************************************************
8-24
HDL Verifier libraries loaded successfully.

********************************************************************************
Next, the script checks a TCP connection. If you choose to skip this step, the
configuration file specifies use of shared memory. Both shared memory and
socket configurations are in the configuration file; depending on your choice,
one configuration or the other is commented out.
Press Enter to check for TCP connection or enter 'n' to skip this test:
Enter an available port [5001]
Enter remote host [localhost]
Press Enter to continue
ttcp_glnx -t -p5001 localhost

Connection successful
Lastly, the script creates the configuration file, unless for some reason you
choose not to do so at this time.
********************************************************************************
Press Enter to Create Configuration files or 'n' to skip this step:
********************************************************************************
Created template files simulink9675.arg and matlab8675.arg. Inspect and modify

if desired.
********************************************************************************
Diagnosis Completed
The template file names, in this example simulink24255.arg and

matlab24255.arg, have different names each time you run this script.
After the script is complete, you can leave the configuration files where they
are or move them to wherever it is convenient.
8-25
Using the Configuration and Diagnostic Script with Windows

The setup script does not run on Windows. However, if your HDL simulator
runs on Windows, you can use the configuration script on Windows by
following these instructions:
1 Create a MATLAB configuration file. You may name it whatever you like;
there are no file-naming restrictions. Enter the following text:
//Command file for HDL Verifier Link MATLAB library

//for use with Mentor Graphics ModelSim.
//Loading of foreign Library, usage example: vsim -f matlab14455.arg entity.
//You can manually change the following line to point to the applicable library.
//The default location of the 32-bit Windows library is at
//MATLABROOT/toolbox/edalink/extensions/modelsim/windows32/liblfmhdlc_tmwvs.dll.
-foreign "matlabclient c:/path/liblfmhdlc_tmwvs.dll"
where path is the path to the particular HDL Verifier shared library you
want to invoke (in this example. See “HDL Verifier Libraries” on page 8-11).
For more information on the -foreign option, refer to the ModelSim

documentation.
The comments in the above text are optional.
2 Create a Simulink configuration file and name it. There are no file-naming
restrictions. Enter the following text:
//Command file for HDL Verifier Simulink library

//for use with Mentor Graphics ModelSim.
//Loading of foreign Library, usage example: vsim -f simulink14455.arg entity.
//You can manually change the following line to point to the applicable library.
//For example the default location of the 32-bit Windows library is at
//MATLABROOT/toolbox/edalink/extensions/modelsim/windows32/liblfmhdls_tmwvs.dll.
//For socket connection uncomment and modify the following line:

-foreign "simlinkserver c:/path/liblfmhdls_tmwvs.dll ; -socket 5001"
//For shared connection uncomment and modify the following line:

//-foreign "simlinkserver c:/path/liblfmhdls_tmwvs.dll"
8-26
Where path is the path to the particular HDL Verifier shared library you
want to invoke. See “HDL Verifier Libraries” on page 8-11.
Note If you are going to use a TCP/IP socket connection, first confirm that
you have an available port to put in this configuration file. Then, comment
out whichever type of communication you will not be using.
The comments in the above text are optional.
After you have finished creating the configuration files, you can leave the files
where they are or move them to another location that is convenient.
Cross-Network Cosimulation
• “Why Perform Cross-Network Cosimulation?” on page 8-27
• “Preparing for Cross-Network Cosimulation” on page 8-27
• “Performing Cross-Network Cosimulation Using MATLAB” on page 8-30
• “Performing Cross-Network Cosimulation Using Simulink” on page 8-32
Why Perform Cross-Network Cosimulation?

You can perform cross-network cosimulation when your setup comprises one
machine running MATLAB and Simulink software and another machine
running the HDL simulator. Typically, a Windows-platform machine runs
the MATLAB and Simulink software, while a Linux machine runs the HDL
simulator. However, these procedures apply to any combination of platforms
that HDL Verifier and the HDL simulator support.
Preparing for Cross-Network Cosimulation

Before you cosimulate between the HDL simulator and MATLAB or Simulink
across a network, perform the following steps:
1 Create your design and testing files.
8-27
ModelSim Users
• Create and compile your HDL design, and create your MATLAB
function (for MATLAB cosimulation) or Simulink model (for Simulink
cosimulation).
• If you are going to cosimulate with Simulink, use the -novopt option
when you compile so that the design is not optimized, and include the
-novopt option when you issue the vsim command (see “Performing
Cross-Network Cosimulation Using Simulink” on page 8-32). Using the
-novopt option retains some unused signals from the design which are
required by the Simulink model to run and display the results.
Incisive Users
Create, compile, and elaborate your HDL design, and create your MATLAB
function (for MATLAB cosimulation), or Simulink model (for Simulink
cosimulation).
2 Copy HDL Verifier libraries to the machine with the HDL simulator
a Go to the system where you installed MATLAB. Then, find the folder in
the MATLAB distribution where the HDL Verifier libraries reside.
You can usually find the libraries in the default installed folder:
matlabroot/toolbox/edalink/extensions/adaptor/platform/productlibraryname_
compiler_tag.ext
where the variable shown in the following table have the values
indicated.
8-28
Variable Value
matlabroot The location where you installed the
MATLAB software; default value is
"MATLAB/version" where version is the
installed release (for example, R2009a).
adaptor incisive or modelsim
platform The operating system of the machine with

the HDL simulator, for example, linux32.
(For more information, see “HDL Verifier
Libraries” on page 8-11.)
productlibraryname The name of the library files for MATLAB

and for Simulink (for example, liblfmhdlc,
liblfmhdls for ModelSim users; liblfihdlc,
liblfihdls for Incisive users).
See “HDL Verifier Libraries” on page 8-11.
8-29
Variable Value
compiler_tag The compiler used to create the library
(for example, gcc32 or spro). For more
information, see “HDL Verifier Libraries”
on page 8-11.
ext dll (dynamic link library—Windows only)
or so ( shared library extension)
For a list of all the HDL Verifier HDL shared libraries shipped, see
“Default Libraries” on page 8-12.
b From the MATLAB machine, copy the HDL Verifier libraries you
plan to use (which you determined in step 2) to the machine where
you installed the HDL simulator. Make note of the location to which
you copied the libraries; you’ll need this information when you are
actually establishing the connection to the HDL simulator. For purposes
of this example, the sample code refers to the destination folder as
"HDLSERVER_LIB_LOCATION".
If you now want to cosimulate with MATLAB, see “Performing Cross-Network

Cosimulation Using MATLAB” on page 8-30. If you want to cosimulate with
Simulink, see “Performing Cross-Network Cosimulation Using Simulink”
on page 8-32.
Performing Cross-Network Cosimulation Using MATLAB

To perform an HDL-simulator-to-MATLAB cosimulation session across a
network, follow these steps:
ModelSim Users
1 In MATLAB, get an available socket using hdldaemon:
hdldaemon('socket',0)
Or assign one (that you know is available):
8-30
2 On the machine with the HDL simulator, launch the HDL simulator from a
shell with the following command:
vsim -foreign "matlabclient /HDLSERVER_LIB_LOCATION/library_name;" design_name
where the arguments shown in the following table have the values
indicated.
Argument Value
library_name The name of the library you
copied to the machine with the
HDL simulator (in “Preparing for
Cross-Network Cosimulation” on
page 8-27).
design_name The VHDL or Verilog design you
want to load
3 In the HDL simulator, schedule the test bench or component (matlabcp or

matlabtb). Specify the socket port number from step 1 and the name of
the host machine where hdldaemon is running.
Incisive Users
1 In MATLAB, get an available socket using hdldaemon:
Or assign one:
2 Create a MATLAB configuration file (for loading the functions used in the
HDL simulator) with the following contents:
//Command file for MATLAB HDL Verifier.

//Loading of foreign Library and HDL simulator functions.
-loadcfc /HDLSERVER_LIB_LOCATION/library_name:matlabclient
//TCL wrappers for MATLAB commands
8-31
-input @proc" "nomatlabtb" "{args}" "{call" "nomatlabtb" "\$args}

-input @proc" "matlabtb" "{args}" "{call" "matlabtb" "\$args}
-input @proc" "matlabcp" "{args}" "{call" "matlabcp" "\$args}
-input @proc" "matlabtbeval" "{args}" "{call" "matlabtbeval" "\$args}
Where library_name is the name of the library you copied in “Preparing

for Cross-Network Cosimulation” on page 8-27. You may name this
configuration file anything you like.
3 On the machine with the HDL simulator, launch the HDL simulator from a
shell with the following command:
ncsim -gui -f matlab_config.file design_name
indicated.
Argument Value
matlab_config.file The name of the MATLAB
configuration file (from step 3)
want to load
4 In the HDL simulator, schedule the test bench or component (matlabcp or

matlabtb). Specify the socket port number from step 1 and the name of the
host where hdldaemon is running.
Performing Cross-Network Cosimulation Using Simulink

When you want to perform an HDL-simulator-to-Simulink cosimulation
session across a network, follow these steps:
ModelSim Users
1 Launch the HDL simulator from a shell with the following command:
vsim -foreign "simlinkserver /HDLSERVER_LIB_LOCATION/library_name;

-socket socket_num" -novopt design_name
8-32
indicated.
Argument Value
page 8-27).
socket_num The socket number you have chosen
for this connection
want to load
2 On the machine with MATLAB and Simulink, start Simulink and open
your model.
3 Double-click on the HDL Cosimulation block to open the Function Block

Parameters dialog box.
4 Click on the Connections tab.
a Clear “The HDL simulator is running on this computer.” HDL Verifier

changes the Connection method to Socket.
b In the text box labeled Host name, enter the host name of the machine
where the HDL simulator is located.
c In the text box labeled Port number or service, enter the socket
number from step 1.
d Click OK to exit block dialog box, and save your changes.
Incisive Users
1 Launch the HDL simulator from a shell with the following command:
ncsim -gui -loadvpi "/HDLSERVER_LIB_LOCATION/library_name:simlinkserver"

+socket=socket_num design_name
8-33
indicated.
Argument Value
page 8-27).
socket_num The socket number you have chosen
for this connection
want to load
2 On the machine with MATLAB and Simulink, start Simulink and open
your model.
3 Double-click on the HDL Cosimulation block to open the Function Block

Parameters dialog box.
4 Click on the Connections tab.
a Clear the check box labeled The HDL simulator is running on this
computer. HDL Verifier changes the Connection method to Socket.
b In the Host name box, enter the host name of the machine where the
HDL simulator is located.
c In the Port number or service box, enter the socket number from
step 1.
d Click OK to exit block dialog box, and save your changes.
Next, run your simulation, add more blocks, or make other desired changes.
For instructions on using Simulink and the HDL simulator for cosimulation,
see “Simulink as a Test Bench” on page 4-2 or “Component Simulation with
Simulink” on page 5-2.
8-34
Test Bench and Component Function Options

In this section...
“Writing Functions Using the HDL Instance Object” on page 8-35
“Writing Functions Using Port Information” on page 8-40
Writing Functions Using the HDL Instance Object

This section explains how you use the use_instance_obj argument for
MATLAB functions matlabcp and matlabtb. This feature replaces the
iport, oport, tnext, tnow, and portinfo arguments of the MATLAB function
definition. Instead, an HDL instance object is passed to the function as an
argument. With this feature, matlabcp and matlabtb function callbacks get
the HDL instance object passed in: to hold state, provide read/write access
protection for signals, and allow you to add state as desired.
With this feature, you gain the following advantages:
• Use of the same MATLAB function to represent behavior for different

instances of the same module in HDL without need to create one-off
wrapper functions.
• No need for special "portinfo" argument on first invocation.
• No need to use persistent or global variables.
• Better feedback and protections on reading/writing of signals.
• Use of object fields to identify the instance path and whether the call comes
from a component or test bench function.
• Use of the field argument to pass user-defined arguments from the
matlabcp or matlabtb instantiation on the HDL side to the function
callbacks.
The use_instance_obj argument is identical for both matlabcp and matlabtb.

You include the -use_instance_obj argument with matlabcp or matlabtb in
the following format:
matlabcp modelname -mfunc funcname -use_instance_obj
8-35
When you use use_instance_obj, HDL Verifier passes an HDL instance object
to the function specified with the -mfunc argument. The function called has
the following signature:
function MyFunctionName(hdl_instance_obj)
The HDL instance object (hdl_instance_obj) has the fields shown in the
following table.
Field Read/Write Description

Access
tnext Write only Used to schedule a callback during the set time value. This
field is the same as tnext in the old portinfo structure. For
example:
hdl_instance_obj.tnext = hdl_instance_obj.tnow + 5e-9
This line of code schedules a callback at time = 5 nanoseconds

from tnow.
userdata Read/Write Stores state variables of the current matlabcp instance. You
can retrieve the variables the next time the callback of this
instance is scheduled.
simstatus Read only Stores the status of the HDL simulator. The HDL Verifier
software sets this field to ’Init’ during the first callback for
this particular instance and to ’Running’ thereafter. This field
value is a read-only property.
>> hdl_instance_obj.simstatus
ans=
Init
8-36

Access
instance Read only Stores the full path of the Verilog/VHDL instance associated
with the callback. instance is a read-only property. The value
of this field equals that of the module instance specified with
the function call. For example:
In the HDL simulator:
hdlsim> matlabcp osc_top -mfunc oscfilter use_instance_obj
In MATLAB:
>> hdl_instance_obj.instance
ans=
osc_top
argument Read only Stores the argument set by the -argument option of matlabcp.
For example:
matlabtb osc_top -mfunc oscfilter -use_instance_obj -argument foo
The verification software supports the -argument option

only when you use it with -use_instance_obj, otherwise the
argument is ignored. argument is a read-only property.
>> hdl_instance_obj.argument
ans=
foo
8-37

Access
portinfo Read only Stores information about the VHDL and Verilog ports
associated with this instance. This field value is a read-only
property, which has a field structure that describes the ports
defined for the associated HDL module. For each port, the
portinfo structure passes information such as the port’s type,
direction, and size. For more information on port data, see
“Gaining Access to and Applying Port Information” on page
8-44.
hdl_instance_obj.portinfo.field1.field2.field3
Note When you use use_instance_obj, you access tscale

through the HDL instance object. If you do not use
use_instance_obj, you can still access tscale through portinfo.
tscale Read only Stores the resolution limit (tick) in seconds of the HDL
simulator. This field value is a read-only property.
>> hdl_instance_obj.tscale
ans=
1.0000e-009
Note When you use use_instance_obj, you access tscale

through the HDL instance object. If you do not use
use_instance_obj, you can still access tscale through portinfo.
tnow Read only Stores the current time. This field value is a read-only
property.
hdl_instance_obj.tnext = hld_instance_obj.tnow + fastestrate;
8-38

Access
portvalues Read/Write Stores the current values of and sets new values for the output
and input ports for a matlabcp instance. For example:
>> hdl_instance_obj.portvalues
ans =
Read Only Input ports:
clk_enable: []
clk: []
reset: []
Read/Write Output ports:
sine_out: [22x1 char]
linkmode Read only Stores the status of the callback. The HDL Verifier software
sets this field to testbench if the callback is associated with
matlabtb and component if the callback is associated with
matlabcp. This field value is a read-only property.
>> hdl_instance_obj.linkmode
ans=
component
Example: Using matlabcp and the HDL Instance Object

In this example, the HDL simulator makes repeated calls to matlabcp to bind
multiple HDL instances to the same MATLAB function. Each call contains
-argument as a constructor parameter to differentiate behavior.
> matlabcp u1_filter1x -mfunc osc_filter -use_instance_obj -argument oversample=1

The MATLAB function callback, osc_filter.m, sets up user instance-based

state using obj.userdata, queries port and simulation context using other obj
fields, and uses the passed in obj.argument to differentiate behavior.
function osc_filter(obj)
8-39
if (strcmp(obj.simstatus,'Init'))
ud = struct('Nbits', 22, 'Norder', 31, 'clockperiod', 80e-9, 'phase', 1));
eval(obj.argument);
if (~exist('oversample','var'))
error('HdlLinkDemo:UseInstanceObj:BadCtorArg', ...
'Bad constructor arg to osc_filter callback. Expecting
''oversample=value''.');
end
ud.oversample = oversample;
ud.oversampleperiod = ud.clockperiod/ud.oversample;
ud.InDelayLine = zeros(1,ud.Norder+1);
centerfreq = 70/256;
passband = [centerfreq-0.01, centerfreq+0.01];
b = fir1((ud.Norder+1)*ud.oversample-1, passband./ud.oversample);
ud.Hresp = ud.oversample .* b;
obj.userdata = ud;
end
...
Writing Functions Using Port Information

• “MATLAB Function Syntax and Function Argument Definitions” on page
8-40
• “Oscfilter Function Example” on page 8-43
• “Gaining Access to and Applying Port Information” on page 8-44
MATLAB Function Syntax and Function Argument Definitions

The syntax of a MATLAB component function is
function [oport, tnext] = MyFunctionName(iport, tnow, portinfo)
The syntax of a MATLAB test bench function is
8-40
The input/output arguments (iport and oport) for a MATLAB component

function are the reverse of the port arguments for a MATLAB test bench
function. That is, the MATLAB component function returns signal data to the
outputs and receives data from the inputs of the associated HDL module.
For more information on using tnext and tnow for simulation scheduling, see
“Schedule Component Functions Using the tnext Parameter” on page 2-21.
The following table describes each of the test bench and component function
parameters and the roles they play in each of the functions.
Parameter Test Bench Component

iport Output Input
Structure that forces (by Structure that receives signal
deposit) values onto signals values from the input ports
connected to input ports of the defined for the associated HDL
associated HDL module. module at the time specified
by tnow.
tnext Output, optional Output, optional
Specifies the time at which Same as test bench.
the HDL simulator schedules
the next callback to MATLAB.
tnext should be initialized
to an empty value ([]). If
tnext is not later updated, no
new entries are added to the
simulation schedule.
oport Input Output
Structure that receives signal Structure that forces (by
values from the output ports deposit) values onto signals
defined for the associated HDL connected to output ports of
module at the time specified the associated HDL module.
by tnow.
8-41
Parameter Test Bench Component

tnow Input Same as test bench.
Receives the simulation
time at which the MATLAB
function is called. By default,
time is represented in seconds.
For more information see
“Schedule Component
Functions Using the tnext
Parameter” on page 2-21.
portinfo Input Same as test bench.
For the first call to the
function only (at the start of
the simulation) , portinfo
receives a structure whose
fields describe the ports
defined for the associated HDL
module. For each port, the
portinfo structure passes
information such as the port’s
type, direction, and size.
If you are using matlabcp, initialize the function outputs to empty values at
the beginning of the function as in the following example:
tnext = [];
oport = struct();
Note When you import VHDL signals, signal names in iport, oport, and
portinfo are returned in all capitals.
You can use the port information to create a generic MATLAB function that
operates differently depending on the port information supplied at startup.
For more information on port data, see “Gaining Access to and Applying Port
Information” on page 8-44.
8-42
Oscfilter Function Example

The following code gives the definition of the oscfilter MATLAB component
function.
function [oport,tnext] = oscfilter(iport, tnow, portinfo)
The function name oscfilter, differs from the entity name u_osc_filter.
Therefore, the component function name must be passed in explicitly to the
matlabcp command that connects the function to the associated HDL instance
using the -mfunc parameter.
The function definition specifies all required input and output parameters, as
listed here:
oport Forces (by deposit) values onto the signals connected to the
entity’s output ports, filter1x_out, filter4x_out and
filter8x_out.
tnext Specifies a time value that indicates when the HDL simulator
will execute the next callback to the MATLAB function.
iport Receives HDL signal values from the entity’s input port,
osc_in.
tnow Receives the current simulation time.
portinfo For the first call to the function, receives a structure that
describes the ports defined for the entity.
The following figure shows the relationship between the HDL entity’s ports
and the MATLAB function’s iport and oport parameters (example shown
is for use with ModelSim).
Input Signals Output Signals
oport.filter1x_out
iport.osc_in osc_filter.vhd oport.filter4x_out
oport.filter8x_out
8-43
Gaining Access to and Applying Port Information

HDL Verifier software passes information about the entity or module under
test in the portinfo structure. The portinfo structure is passed as the third
argument to the function. It is passed only in the first call to your MATLAB
function. You can use the information passed in the portinfo structure to
validate the entity or module under simulation. Three fields supply the
information, as indicated in the next sample. . The content of these fields
depends on the type of ports defined for the VHDL entity or Verilog module.
portinfo.field1.field2.field3
The following table lists possible values for each field and identifies the port
types for which the values apply.
HDL Port Information
Field... Can Contain... Which... And Applies to...

field1 in Indicates the port is an input All port types
port
out Indicates the port is an output All port types
port
inout Indicates the port is a All port types
bidirectional port
tscale Indicates the simulator All types
resolution limit in seconds as
specified in the HDL simulator
field2 portname Is the name of the port All port types
8-44
HDL Port Information (Continued)
Field... Can Contain... Which... And Applies to...

field3 type Identifies the port type All port types
For VHDL: integer, real,
time, or enum
For Verilog:
'verilog_logic' identifies
port types reg, wire, integer
right (VHDL The VHDL RIGHT attribute VHDL integer, natural, or
only) positive port types
left (VHDL The VHDL LEFT attribute VHDL integer, natural, or
only) positive port types
size VHDL: The size of the matrix All port types
containing the data
Verilog: The size of the bit
vector containing the data
label VHDL: A character literal or VHDL: Enumerated types,
label including predefined
types BIT, STD_LOGIC,
Verilog: the string '01ZX'
STD_ULOGIC, BIT_VECTOR,
and STD_LOGIC_VECTOR
Verilog: All port types
The first call to the MATLAB function has three arguments including the
portinfo structure. Checking the number of arguments is one way you can
verify that portinfo was passed. For example:
if(nargin ==3)
tscale = portinfo.tscale;
end
8-45
Direct Feedthrough Cosimulation
Applying Direct Feedthrough to Eliminate Block

Simulation Latency
The HDL Verifier direct feedthrough feature eliminates latency in HDL
designs with pure combinational datapaths. Direct feedthrough means that
the output is controlled directly by the value of an input port. With direct
feedthrough enabled, the input value change propagates to the output ports
in zero time, thus eliminating the one output-sample delay.
You will still experience block simulation latency for pure combinational
circuits even with direct feedthrough applied if your HDL design contains any
of the following conditions:
• A different sample time between the input and output ports

• A nonuniform sampling time among the output ports
• The input/output signals are framed
When you are simulating a sequential circuit that has a register on the
datapath from input port to output port, specifying direct feedthrough does
not affect the timing of that datapath.
Read the following sections to learn more about using direct feedthrough:
• “How to Apply Direct Feedthrough” on page 8-46

• “Example of Applying Direct Feedthrough” on page 8-47
You can also examine the example “Simulate HDL Design with Pure
Combinational Datapath” to see how you might apply this feature.
How to Apply Direct Feedthrough

To apply direct feedthrough:
1 Double-click on the HDL Cosimulation block.
2 Click on the Ports pane.
8-46
3 Select Enable direct feedthrough for HDL design with pure

combinational datapath.
4 Click Apply.
Example of Applying Direct Feedthrough

In the Simulink model, the HDL cosimulation block has a path from input to
output that contains only pure combinational logic.
8-47
Without direct feedthrough applied, the HDL output has a one-sample delay
compared with the Simulink reference signal, as shown in the following Scope
window.
8-48
This delay occurs from simulating a pure combinational HDL design without
applying direct feedthrough.
With direct feedthrough applied, the change of input signal is propagated to

the output port in zero time as expected, as shown in the following Scope
window.
8-49
8-50
Simulation Speed Improvement Tips

In this section...
“Obtaining Baseline Performance Numbers” on page 8-51
“Analyzing Simulation Performance” on page 8-51
“Cosimulating Frame-Based Signals with Simulink” on page 8-53
Obtaining Baseline Performance Numbers

You can baseline the performance numbers by timing the execution of the
HDL and the Simulink model separately and adding them together; you
may not expect better performance than that. Make sure that the separate
simulations are representative: running an HDL-only simulator with
unrealistic input stimulus could be much faster than when realistic input
stimulus is provided.
Analyzing Simulation Performance

While cosimulation entails a certain amount of overhead, sometimes the HDL
simulation itself also slows performance. Ask yourself these questions when
trying to analyze and improve performance:
Consideration Suggestions for Improving

Speed
Are you are using NFS or other How fast is the file system? Consider
remote file systems? using a different type or expect that
the file system you’re using will
impact performance.
Are you using separate machines for How fast is the network? Wait until
Simulink and the HDL simulator? the network is quieter or contact
your system administrator for advice
on improving the connection.
8-51
Consideration Suggestions for Improving

Speed
Are you using the same machine for • Are you using shared pipes
Simulink and the HDL simulator? instead of sockets? Shared
memory is faster.
• Are the Simulink and HDL
processes large enough to cause
swaps to disk? Consider adding
more memory; otherwise be
aware that you’re running a huge
process and expect it to impact
performance.
Are you using optimal (that is, as For example, if you set the output
large as possible) Simulink sample sample rate to 1 but only use every
rates on the HDL Cosimulation 10th sample, you could make the rate
block? 10 and reduce the traffic between
Simulink and the HDL simulator.
Another example is if you place
a very fast clock as an input to
the HDL Cosimulation block, but
have none of the other inputs need
such a fast rate. In that case, you
should generate the clock in HDL or
(Incisive and ModelSim users only)
via the Clocks or Simulation pane
on the HDL Cosimulation block.
ModelSim users: Are you Use vopt to optimize your design for
compiling/elaborating the HDL maximum (HDL) simulator speed
using the vopt flow? (ModelSim users only).
Are you using Simulink Acceleration mode can speed
Accelerator™ mode? up the execution of your model.
See "Accelerating Models” in the
Simulink User’s Guide.
If you have the Communications Framed signals reduce the number
System Toolbox software, have you of Simulink/HDL interactions.
considered using Framed signals?
8-52
Cosimulating Frame-Based Signals with Simulink
Overview to Cosimulation with Frame-Based Signals

Frame-based processing can improve the computational time of your
Simulink models, because multiple samples can be processed at once. Use
of frame-based signals also lets you simulate the behavior of frame-based
systems more realistically. The HDL Simulator block supports processing of
single-channel frame-based signals.
A frame of data is a collection of sequential samples from a single channel or

multiple channels. One frame of a single-channel signal is represented by a
M-by-1 column vector. A signal is frame based if it is propagated through a
model one frame at a time.
Frame-based processing requires the DSP System Toolbox software. Source

blocks from the Sources library let you specify a frame-based signal by setting
the Samples per frame block parameter. Most other signal processing
blocks preserve the frame status of an input signal. You can use the Buffer
block to buffer a sequence of samples into frames.
See “Working with Signals” in the DSP System Toolbox documentation for
detailed information about frame-based processing.
Using Frame-Based Processing

You do not need to configure the HDL Simulator block in any special way for
frame-based processing. To use frame-based processing in a cosimulation,
connect one or more single-channel frame-based signals to one or more
input ports of the HDL Simulator block. All such signals must meet the
requirements described in “Frame-Based Processing Requirements and
Restrictions” on page 8-54. The HDL Simulator block configures any outputs
for frame-based operation at the suitable frame size.
Use of frame-based signals affects only the Simulink side of the cosimulation.
The behavior of the HDL code under simulation in the HDL simulator does
not change in any way. Simulink assumes that HDL simulator processing is
sample based. Simulink assembles samples acquired from the HDL simulator
into frames as required. Conversely, Simulink transmits output data to the
8-53
HDL simulator in frames, which are unpacked and processed by the HDL
simulator one sample at a time.
Frame-Based Processing Requirements and Restrictions

Observe the following restrictions and requirements when connecting
frame-based signals in to an HDL Simulator block:
• Connection of mixed frame-based and sample-based signals to the same

HDL Simulator block is not supported.
• Only single-channel frame-based signals can be connected to the HDL
Simulator block. Use of multichannel (matrix) frame-based signals is not
supported in this release.
• All frame-based signals connected to the HDL Simulator block must have
the same frame size.
Frame-based processing in the Simulink model is transparent to the operation

of the HDL model under simulation in the HDL simulator. The HDL model
is presumed to be sample-based. The following constraint also applies to the
HDL model under simulation in the HDL simulator:
Specify VHDL signals as scalars values, not vectors or arrays (with the
exception of bit vectors. VHDL and Verilog bit vectors are converted to the
suitably-sized fixed-point scalar data type by the HDL Cosimulation block).
Frame-Based Cosimulation Example

This example shows the use of the HDL Simulator block to cosimulate a
VHDL implementation of a simple lowpass filter. In the example, you
will compare the performance of the simulation using frame-based and
sample-based signals.
Note This tutorial is specific to ModelSim users; however, much of the

process will be the same for Incisive users.
The example files are (in matlabroot):
• The example model:
8-54
\toolbox\edalink\extensions\modelsim\modelsimdemos\frame_filter_cosim
• VHDL code for the filter to be cosimulated:
\toolbox\edalink\extensions\modelsim\modelsimdemos\VHDL\frame_demos\lp_fir_8k.vhd
The filter was designed with FDATool and the code was generated by the
Filter Design HDL Coder.
The example uses the data file

matlabroot\toolbox\signal\signal\mtlb.mat as an input signal. This
file contains a speech signal. The sample data is of data type double,
sampled at a rate of 8 kHz.
The next figure shows the frame_filter_cosim model.
The Audio Source Signal From Workspace block provides an input signal
from the workspace variable mtlb. The block is configured for an 8 kHz
sample rate, with a frame size of 80, as shown in this figure.
8-55
The sample rate and frame size of the input signal propagate throughout
the model.
The VHDL code file lp_fir_8k.vhd implements a simple lowpass FIR filter
with a cutoff frequency of 1500 Hz. The HDL Simulator block simulates this
HDL module. The HDL Simulator block ports and clock signal are configured
to match the corresponding signals on the VHDL entity.
For the ModelSim simulation to execute as we want it to, the clk_enable

signal of the lp_fir_8k entity must be forced high. The signal is forced
by a pre-simulation command transmitted by the HDL Simulator block.
The command has been entered into the Simulation pane of the HDL
Simulator block, as shown in the following figure (example shown for use
with ModelSim).
8-56
The HDL Simulator block returns output in the workspace variable

audiobuff1 via the Filtered Signal To Workspace block.
To run the cosimulation, perform the following steps:
1 Start MATLAB and make it your active window.
2 Set up and change to a writable working folder that is outside the context
of your MATLAB installation folder.
3 Add the example folder to the MATLAB path:
matlabroot\toolbox\edalink\extensions\modelsim\modelsimdemos\frame_cosim
4 Copy the VHDL file lp_fir_8k.vhd to your working folder.
5 Open the example model.
8-57
open frame_filter_cosim.mdl
6 Load the source speech signal, which will be filtered, into the MATLAB
workspace.
load mtlb
If you have a compatible sound card, you can play back the source signal by
typing the following commands at the MATLAB command prompt:
a = audioplayer(mtlb,8000);
play(a);
7 Start ModelSim by typing the following command at the MATLAB

command prompt:
vsim
The ModelSim window should now be active. If not, start it.
8 At the ModelSim prompt, create a design library, and compile the VHDL
filter code from the source file lp_fir_8k.vhd, by typing the following
commands:
vlib work
vmap work work
vcom lp_fir_8k.vhd
9 The lowpass filter to be simulated is defined as the entity lp_fir_8k. At the

ModelSim prompt, load the instantiated entity lp_fir_8k for cosimulation:
vsimulink lp_fir_8k
ModelSim is now set up for cosimulation.
10 Start MATLAB. Run a simulation and measure elapsed time as follows:
t = clock; sim(gcs); etime(clock,t)
ans =
8-58
2.7190
The timing in this code excerpt is typical for a run of this model given a
simulation Stop time of 1 second and a frame size of 80 samples. Timings
are system-dependent and will vary slightly from one simulation run to
the next.
Take note of the timing you obtained. For the next simulation run, you will
change the model to sample-based operation and obtain a comparative
timing.
11 MATLAB stores the filtered audio signal returned from ModelSim in the
workspace variable audiobuff1. If you have a compatible sound card, you
can play back the filtered signal to hear the effect of the lowpass filter. Play
the signal by typing the following commands at the MATLAB command
prompt:
b = audioplayer(audiobuff1,8000);
play(b);
12 Open the block parameters dialog box of the Audio Source Signal From
Workspace block and set the Samples per frame property to 1, as shown
in this figure.
8-59
13 Close the dialog box, and select the Simulink window. Select
Simulation > Update diagram.
Now the source signal (and all signals inheriting from it) is a scalar.
14 Start ModelSim. At the ModelSim prompt, type
restart
15 Start MATLAB. Run a simulation and measure elapsed time as follows:
t = clock; sim(gcs); etime(clock,t)
ans =
8-60
3.8440
Observe that the elapsed time has increased significantly with a

sample-based input signal. The timing in this code excerpt is typical for a
sample-based run of this model given a simulation Stop time of 1 second.
Timings are system-dependent and will vary slightly from one simulation
run to the next.
16 Close down the simulation in an orderly way. In ModelSim, stop the

simulation by selecting Simulate > End Simulation, and quit ModelSim.
Then, close the Simulink model window.
8-61
Race Conditions in HDL Simulators

In this section...
“Avoiding Race Conditions” on page 8-62
“Potential Race Conditions in Simulink Cosimulation Sessions” on page 8-62
“Potential Race Conditions in MATLAB Cosimulation Sessions” on page
8-64
“Further Reading” on page 8-64
Avoiding Race Conditions

A well-known issue in hardware simulation is the potential for different
results on different runs when race conditions are present. Because the HDL
simulator is a highly parallel execution environment, you must write the HDL
such that the results do not depend on the ordering of process execution.
Although there are well-known coding idioms for achieving a realistic

simulation of a design under test, you must always take special care at
the test bench/DUT interfaces for applying stimulus and reading results,
even in pure HDL environments. For an HDL/foreign language interface,
such as with a Simulink or MATLAB cosimulation session, the problem is
compounded if you do not have a common synchronization signal, such as a
clock, coordinating the flow of data.
Potential Race Conditions in Simulink Cosimulation

Sessions
All the signals on the interface of an HDL Cosimulation block in theSimulink
library have an intrinsic sample rate associated with them. This sample
rate can be thought of as an implicit clock that controls the simulation time
at which a value change can occur. Because this implicit clock is completely
unknown to the HDL engine (that is, it is not an HDL signal), the times at
which input values are driven into the HDL or output values are sampled
from the HDL are asynchronous to any clocks coded in HDL directly, even if
they are nominally at the same frequency.
8-62
Race Conditions in HDL Simulators
For Simulink value changes scheduled to occur at a specific simulation time,

the HDL simulator does not make any guarantees as to the order that value
change occurs versus some other blocking signal assignment. Thus, if the
Simulink values are driven/sampled at the same time as an active clock edge
in the HDL, there is a race condition.
For cases where your active HDL clock edge and your intrinsic Simulink
active clock edges are at the same frequency, you can promote desired data
propagation by offsetting one of those edges. Because the Simulink sample
rates are always aligned with time 0, you can accomplish this offset by shifting
the active clock edge in the HDL off of time 0. If you are coding the clock
stimulus in HDL, use a delay operator ("after" or "#") to accomplish this offset.
When using a Tcl "force" command to describe the clock waveform, you can
simply put the first active edge at some nonzero time. Using a nonzero value
allows a Simulink sample rate that is the same as the fundamental clock rate
in your HDL. This example shows a 20 ns clock (so the Simulink sample rates
will also be every 20 ns) with an active positive edge that is offset from time
0 by 2 ns (example shown for use with Incisive):
> force top.clk = 1'b0 -after 0 ns 1'b1 -after 2 ns 1'b0

-after 12 ns -repeat 20 ns
For HDL Cosimulation blocks with Clock panes, you can define the clock
period and active edge in that pane. The waveform definition places the
non-active edge at time 0 and the active edge at time T/2. This placement
sets the maximum setup and hold times for a clock with a 50% duty cycle.
If the Simulink sample rates are at a different frequency than the HDL clocks,
then you must synchronize the signals between the HDL and Simulink as you
would do with any multiple time-domain design, even one in pure HDL. For
example, you can place two synchronizing flip-flops at the interface.
If your cosimulation does not include clocks, then you must also treat the
interfacing of Simulink and the HDL code as being between asynchronous
time domains. You may need to over-sample outputs to see that all data
transitions are captured.
8-63
Potential Race Conditions in MATLAB Cosimulation

Sessions
When you use the -sensitivity, -rising_edge, or -falling_edge scheduling
options to matlabtb or matlabcp to trigger MATLAB function calls, the
propagation of values follow the same semantics as a pure HDL design; the
triggers must occur before the results can be calculated. You still can have
race conditions, but they can be analyzed within the HDL alone.
However, when you use the -time scheduling option to matlabtb or matlabcp,
or use "tnext" within the MATLAB function itself, the driving of signal values
or sampling of signal values cannot be guaranteed in relation to any HDL
signal changes. It is as if the potential race conditions in that time-based
scheduling are like an implicit clock that is unknown to the HDL engine and
not visible by just looking at the HDL code.
The remedies are the same as for the Simulink signal interfacing: make sure
that the sampling and driving of signals does not occur at the same simulation
times as the MATLAB function calls.
Further Reading
Problems interfacing designs from test benches and foreign languages,
including race conditions in pure HDL environments, are well-known and
extensively documented. Some texts that describe these issues include:
• The documentation for each vendor’s HDL simulator product

• The HDL standards specifications
• Writing Testbenches: Functional Verification of HDL Models, Janick
Bergeron, 2nd edition, © 2003
• Verilog and SystemVerilog Gotchas, Stuart Sutherland and Don Mills,
© 2007
• SystemVerilog for Verification: A Guide to Learning the Testbench
Language Features, Chris Spear, © 2007
• Principles of Verifiable RTL Design, Lionel Bening and Harry D. Foster,
© 2001
8-64
Data Type Conversions

In this section...
“Converting HDL Data to Send to MATLAB” on page 8-65
“Array Indexing Differences Between MATLAB and HDL” on page 8-68
“Converting Data for Manipulation” on page 8-69
“Converting Data for Return to the HDL Simulator” on page 8-70
Converting HDL Data to Send to MATLAB

If your HDL application needs to send HDL data to a MATLAB function,
you may first need to convert the data to a type supported by MATLAB and
the HDL Verifier software.
To program a MATLAB function for an HDL model, you must understand the
type conversions required by your application. You may also need to handle
differences between the array indexing conventions used by the HDL you are
using and MATLAB (see following section).
The data types of arguments passed in to the function determine the following:
• The types of conversions required before data is manipulated

• The types of conversions required to return data to the HDL simulator
The following table summarizes how the HDL Verifier software converts
supported VHDL data types to MATLAB types based on whether the type is
scalar or array.
8-65
VHDL-to-MATLAB Data Type Conversions
VHDL Types... As Scalar Converts to... As Array Converts to...

STD_LOGIC, STD_ULOGIC, and A character that matches
BIT the character literal for the
desired logic state.
STD_LOGIC_VECTOR, A column vector of characters (as
STD_ULOGIC_VECTOR, defined in VHDL Conversions
BIT_VECTOR, SIGNED, and for the HDL Simulator on page
UNSIGNED 8-71) with one bit per character.
Arrays of STD_LOGIC_VECTOR, An array of characters (as
STD_ULOGIC_VECTOR, defined above) with a size that
BIT_VECTOR, SIGNED, and is equivalent to the VHDL port
UNSIGNED size.
INTEGER and NATURAL Type int32. Arrays of type int32 with a size
that is equivalent to the VHDL
port size.
REAL Type double. Arrays of type double with a
size that is equivalent to the
VHDL port size.
TIME Type double for time values Arrays of type double or int64
in seconds and type int64 with a size that is equivalent to
for values representing the VHDL port size.
simulator time increments
(see the description of
the 'time' option in
hdldaemon).
8-66
VHDL-to-MATLAB Data Type Conversions (Continued)
VHDL Types... As Scalar Converts to... As Array Converts to...

Enumerated types Character array (string) Cell array of strings with each
that contains the MATLAB element equal to a label for
representation of a VHDL the defined enumerated type.
label or character literal. Each element is the MATLAB
For example, the label high representation of a VHDL
converts to 'high' and label or character literal. For
the character literal 'c' example, the vector (one, '2',
converts to '''c'''. three) converts to the column
vector ['one'; '''2''';
'three']. A user-defined
enumerated type that contains
only character literals, and then
converts to a vector or array of
characters as indicated for the
types STD_LOGIC_VECTOR,
STD_ULOGIC_VECTOR,
BIT_VECTOR, SIGNED, and
UNSIGNED.
The following table summarizes how the HDL Verifier software converts
supported Verilog data types to MATLAB types. The software supports only
scalar data types for Verilog.
Verilog-to-MATLAB Data Type Conversions
Verilog Types... Converts to...

wire, reg A character or a column vector of
characters that matches the character
literal for the desired logic states
(bits).
integer A 32-element column vector of
characters that matches the character
literal for the desired logic states
(bits).
8-67
Array Indexing Differences Between MATLAB and

HDL
In multidimensional arrays, the same underlying OS memory buffer maps to
different elements in MATLAB and the HDL simulator (this mapping only
reflects different ways the different languages offer for naming the elements
of the same array). When you use both the matlabtb and matlabcp functions,
be careful to assign and interpret values consistently in both applications.
In HDL, a multidimensional array declared as:
type matrix_2x3x4 is array (0 to 1, 4 downto 2) of std_logic_vector(8 downto 5);
has a memory layout as follows:
bit 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
-
dim1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
dim2 4 4 4 4 3 3 3 3 2 2 2 2 4 4 4 4 3 3 3 3 2 2 2 2
dim3 8 7 6 5 8 7 6 5 8 7 6 5 8 7 6 5 8 7 6 5 8 7 6 5
This same layout corresponds to the following MATLAB 4x3x2 matrix:
bit 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
-
dim1 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
dim2 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3
dim3 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2
Therefore, if H is the HDL array and M is the MATLAB matrix, the following
indexed values are the same:
b1 H(0,4,8) = M(1,1,1)
b2 H(0,4,7) = M(2,1,1)
b3 H(0,4,6) = M(3,1,1)
b4 H(0,4,5) = M(4,1,1)
b5 H(0,3,8) = M(1,2,1)
b6 H(0,3,7) = M(2,2,1)
...
b19 H(1,3,6) = M(3,2,2)
b20 H(1,3,5) = M(4,2,2)
8-68
b21 H(1,2,8) = M(1,3,2)

b22 H(1,2,7) = M(2,3,2)
b23 H(1,2,6) = M(3,3,2)
b24 H(1,2,5) = M(4,3,2)
You can extend this indexing to N-dimensions. In general, the dimensions—if

numbered from left to right—are reversed. The right-most dimension in HDL
corresponds to the left-most dimension in MATLAB.
Converting Data for Manipulation

Depending on how your simulation MATLAB function uses the data it
receives from the HDL simulator, you may need to code the function to
convert data to a different type before manipulating it. The following table
lists circumstances under which you would require such conversions.
Required Data Conversions
If You Need the Then...

Function to...
Compute numeric data Use the double function to convert the
that is received as a type data to type double before performing the
other than double computation. For example:
datas(inc+1) = double(idata);
Convert a standard Use the mvl2dec function to convert the data to

logic or bit vector to an unsigned decimal value. For example:
an unsigned integer or
positive decimal uval = mvl2dec(oport.val)
This example assumes the standard logic or bit

vector is composed of the character literals '1'
and '0' only. These are the only two values
that can be converted to an integer equivalent.
The mvl2dec function converts the binary data
that the MATLAB function receives from the
entity’s osc_in port to unsigned decimal values
that MATLAB can compute.
8-69
Required Data Conversions (Continued)
If You Need the Then...

Function to...
See mvl2dec for more information on this

function.
Convert a standard logic Use the following application of the mvl2dec
or bit vector to a negative function to convert the data to a signed decimal
decimal value. For example:
suval = mvl2dec(oport.val, true);
This example assumes the standard logic or bit

vector is composed of the character literals '1'
and '0' only. These are the only two values
that can be converted to an integer equivalent.
Examples
The following code excerpt illustrates data type conversion of data passed
in to a callback:
InDelayLine(1) = InputScale * mvl2dec(iport.osc_in',true);
This example tests port values of VHDL type STD_LOGIC and

STD_LOGIC_VECTOR by using the all function as follows:
all(oport.val == '1' | oport.val

== '0')
This example returns True if all elements are '1' or '0'.
Converting Data for Return to the HDL Simulator

If your simulation MATLAB function needs to return data to the HDL
simulator, you may first need to convert the data to a type supported by the
HDL Verifier software. The following tables list circumstances under which
such conversions are required for VHDL and Verilog.
8-70
Note When data values are returned to the HDL simulator, the char array
size must match the HDL type, including leading zeroes, if applicable. For
example:
oport.signal = dec2mvl(2)
will only work if signal is a 2-bit type in HDL. If the HDL type is anything
else, you must specify the second argument:
oport.signal = dec2mvl(2, N)
where N is the number of bits in the HDL data type.
VHDL Conversions for the HDL Simulator
To Return Data to an IN Then...

Port of Type...
STD_LOGIC, STD_ULOGIC, or Declare the data as a character that matches the character literal
BIT for the desired logic state. For STD_LOGIC and STD_ULOGIC, the
character can be 'U', 'X', '0', '1', 'Z', 'W', 'L', 'H', or '-'.
For BIT, the character can be '0' or '1'. For example:
iport.s1 = 'X'; %STD_LOGIC

iport.bit = '1'; %BIT
STD_LOGIC_VECTOR, Declare the data as a column vector or row vector of characters

STD_ULOGIC_VECTOR, (as defined above) with one bit per character. For example:
BIT_VECTOR, SIGNED, or
UNSIGNED iport.s1v = 'X10ZZ'; %STD_LOGIC_VECTOR
iport.bitv = '10100'; %BIT_VECTOR
iport.uns = dec2mvl(10,8); %UNSIGNED, 8 bits
Array of STD_LOGIC_VECTOR, Declare the data as an array of type character with a size that
STD_ULOGIC_VECTOR, is equivalent to the VHDL port size. See “Array Indexing
BIT_VECTOR, SIGNED, or Differences Between MATLAB and HDL” on page 8-68.
UNSIGNED
8-71
VHDL Conversions for the HDL Simulator (Continued)

Port of Type...
INTEGER or NATURAL Declare the data as an array of type int32 with a size that is
equivalent to the VHDL array size. Alternatively, convert the
data to an array of type int32 with the MATLAB int32 function
before returning it. Be sure to limit the data to values with the
range of the VHDL type. If you want to, check the right and
left fields of the portinfo structure. For example:
iport.int = int32(1:10)';
REAL Declare the data as an array of type double with a size that is
equivalent to the VHDL port size. For example:
iport.dbl = ones(2,2);
TIME Declare a VHDL TIME value as time in seconds, using type

double, or as an integer of simulator time increments, using type
int64. You can use the two formats interchangeably and what
you specify does not depend on the hdldaemon 'time' option (see
hdldaemon), which applies to IN ports only. Declare an array
of TIME values by using a MATLAB array of identical size and
shape. All elements of a given port are restricted to time in
seconds (type double) or simulator increments (type int64), but
otherwise you can mix the formats. For example:
iport.t1 = int64(1:10)'; %Simulator time

%increments
iport.t2 = 1e-9; %1 nsec
8-72
VHDL Conversions for the HDL Simulator (Continued)

Port of Type...
Enumerated types Declare the data as a string for scalar ports or a cell array of
strings for array ports with each element equal to a label for the
defined enumerated type. The 'label' field of the portinfo
structure lists all valid labels (see “Gaining Access to and
Applying Port Information” on page 8-44). Except for character
literals, labels are not case sensitive. In general, you should
specify character literals completely, including the single quotes,
as in the first example shown here. .
iport.char = {'''A''', '''B'''}; %Character

%literal
iport.udef = 'mylabel'; %User-defined label
Character array for standard Use the dec2mvl function to convert the integer. For example:
logic or bit representation
oport.slva =dec2mvl([23 99],8)';
This example converts two integers to a 2-element array of

standard logic vectors consisting of 8 bits.
Verilog Conversions for the HDL Simulator
To Return Data to an Then...

input Port of Type...
reg, wire Declare the data as a character or a column vector of characters
that matches the character literal for the desired logic state.
For example:
iport.bit = '1';
integer Declare the data as a 32-element column vector of characters (as

defined above) with one bit per character.
8-73
Simulation Timescales
In this section...
“Overview to the Representation of Simulation Time” on page 8-74
“Defining the Simulink and HDL Simulator Timing Relationship” on page
8-75
“Setting the Timing Mode with HDL Verifier” on page 8-76
“Relative Timing Mode” on page 8-77
“Absolute Timing Mode” on page 8-82
“Timing Mode Usage Considerations” on page 8-84
“Setting HDL Cosimulation Block Port Sample Times” on page 8-86
Overview to the Representation of Simulation Time

The representation of simulation time differs significantly between the HDL
simulator and Simulink. Each application has its own timing engine and the
verification software must synchronize the simulation times between the two.
In the HDL simulator, the unit of simulation time is referred to as a tick.

The duration of a tick is defined by the HDL simulator resolution limit. The
default resolution limit is 1 ns, but may vary depending on the simulator.
• ModelSim Users:
To determine the current ModelSim resolution limit, enter echo
$resolution or report simulator state at the ModelSim prompt. You
can override the default resolution limit by specifying the -t option on the
ModelSim command line, or by selecting a different Simulator Resolution
in the ModelSim Simulate dialog box. Available resolutions in ModelSim
are 1x, 10x, or 100x in units of fs, ps, ns, us, ms, or sec. See the ModelSim
documentation for further information.
• Incisive Users:
To determine the current HDL simulator resolution limit, enter echo
$timescale at the HDL simulator prompt. See the HDL simulator
documentation for further information.
8-74
Simulink maintains simulation time as a double-precision value scaled to

seconds. This representation accommodates modeling of both continuous
and discrete systems.
The relationship between Simulink and the HDL simulator timing affects
the following aspects of simulation:
• Total simulation time

• Input port sample times
• Output port sample times
• Clock periods
During a simulation run, Simulink communicates the current simulation

time to the HDL simulator at each intermediate step. (An intermediate step
corresponds to a Simulink sample time hit. Upon each intermediate step, new
values are applied at input ports, or output ports are sampled.)
To bring the HDL simulator up-to-date with Simulink during cosimulation,

you must convert sampled Simulink time to HDL simulator time (ticks) and
allow the HDL simulator to run for the computed number of ticks.
Defining the Simulink and HDL Simulator Timing

Relationship

When you allow the software to define the timing relationship, it attempts
to set the timescale factor between the HDL simulator and Simulink to
be as close as possible to 1 second in the HDL simulator = 1 second in
Simulink. If this setting is not possible, HDL Verifier attempts to set the
8-75
signal rate on the Simulink model port to the lowest possible number of
HDL simulator ticks.
Setting the Timing Mode with HDL Verifier

The Timescales pane of the HDL Cosimulation block parameters dialog box
defines a correspondence between one second of Simulink time and some
quantity of HDL simulator time. This quantity of HDL simulator time can be
expressed in one of the following ways:
• In relative terms (i.e., as some number of HDL simulator ticks). In this

case, the cosimulation is said to operate in relative timing mode. The HDL
Cosimulation block defaults to relative timing mode for cosimulation. For
more on relative timing mode, see “Relative Timing Mode” on page 8-77.
• In absolute units (such as milliseconds or nanoseconds). In this case, the
The Timescales pane lets you choose an optimal timing relationship between
Simulink and the HDL simulator, either by entering the HDL simulator
equivalent or by letting HDL Verifier calculate a timescale for you.
setting the parameters on the block dialog by clicking the Timescale option
then clicking Determine Timescale Now or you can have HDL Verifier
calculate the timescale when simulation begins by selecting Automatically
determine timescale at start of simulation.
The next figure shows the default settings of the Timescales pane (example
shown is for use with ModelSim).
8-76
For instructions on setting the timing mode either manually or with the
Timescales dialog box, see the Timescales pane in the HDL Cosimulation
block reference.
Relative Timing Mode

Relative timing mode defines the following one-to-one correspondence between
simulation time in Simulink and the HDL simulator:
One second in Simulink corresponds to N ticks in the HDL simulator,

where N is a scale factor.
This correspondence holds regardless of the HDL simulator timing resolution.
8-77
The following pseudocode shows how Simulink time units are converted to
HDL simulator ticks:
InTicks = N * tInSecs
where InTicks is the HDL simulator time in ticks, tInSecs is the Simulink
time in seconds, and N is a scale factor.
Operation of Relative Timing Mode

The HDL Cosimulation block defaults to relative timing mode, with a scale
factor of 1. Thus, 1 Simulink second corresponds to 1 tick in the HDL
simulator. In the default case:
• If the total simulation time in Simulink is specified as N seconds, then

the HDL simulation will run for exactly N ticks (i.e., N ns at the default
resolution limit).
• Similarly, if Simulink computes the sample time of an HDL Cosimulation
block input port as Tsi seconds, new values will be deposited on the HDL
input port at exact multiples of Tsi ticks. If an output port has an explicitly
specified sample time of Tso seconds, values will be read from the HDL
simulator at multiples of Tso ticks.
Relative Timing Mode Example

To understand how relative timing mode operates, review cosimulation
results from the following example model.
For Use with ModelSim
8-78
The model contains an HDL Cosimulation block (labeled VHDL Cosimulation

INVERTER) simulating an 8-bit inverter that is enabled by an explicit clock.
The inverter has a single input and a single output. The following sample
shows VHDL code for the inverter:
LIBRARY ieee;
ENTITY inverter IS PORT (
inport : IN std_logic_vector := "11111111";

outport: OUT std_logic_vector := "00000000";
clk:IN std_logic
);
END inverter;
LIBRARY ieee;
ARCHITECTURE behavioral OF inverter IS

BEGIN
PROCESS(clk)
BEGIN
IF (clk'EVENT AND clk = '1') THEN
outport <= NOT inport;
END IF;
END PROCESS;
END behavioral;
A cosimulation of this model might have the following settings:
• Simulation parameters in Simulink:

- Timescales parameters: default (relative timing with a scale factor of 1)
- Total simulation time: 60 s
- Input port (/inverter/inport) sample time: 24 s
- Output port (/inverter/outport ) sample time: 12 s
- Clock (inverter/clk) period: 10 s
• ModelSim resolution limit: 1 ns
8-79
The next figure shows the ModelSim wave window after a cosimulation run
of the example Simulink model for 60 ns. The wave window shows that
ModelSim simulated for 60 ticks (60 ns). The inputs change at multiples of 24
ns and the outputs are read from ModelSim at multiples of 12 ns. The clock is
driven low and high at intervals of 5 ns.
Now consider a cosimulation of the same model, this time configured with a
scale factor of 100 in the Timescales pane.
The ModelSim wave window in the next figure shows that Simulink port
and clock times were scaled by a factor of 100 during simulation. ModelSim
simulated for 6 microseconds (60 * 100 ns). The inputs change at multiples of
24 * 100 ns and outputs are read from ModelSim at multiples of 12 * 100 ns.
The clock is driven low and high at intervals of 500 ns.
8-80
For Use with Incisive
The model contains an HDL Cosimulation block (labeled HDL_Cosimulation1)

simulating an 8-bit inverter that is enabled by an explicit clock. The inverter
has a single input and a single output. The following code excerpt lists the
Verilog code for the inverter:
module inverter_clock_vl(sin, sout,clk);
8-81
input [7:0] sin;

output [7:0] sout;
input clk;
reg [7:0] sout;
always @(posedge clk)

sout <= ! (sin);
endmodule
A cosimulation of this model might have the following settings:

- Timescales parameters: 1 Simulink second = 10 HDL simulator ticks
- Total simulation time: 30 s
- Input port (inverter_clock_vl.sin) sample time: N/A
- Output port (inverter_clock_vl.sout ) sample time: 1 s
- Clock (inverter_clock_vl.clk) period: 5 s
• HDL simulator resolution limit: 1 ns
The previous example was excerpted from the HDL Verifier Inverter tutorial.
For more information, see HDL Verifier demos.
Absolute Timing Mode

Absolute timing mode lets you define the timing relationship between
Simulink and the HDL simulator in terms of absolute time units and a scale
factor:
One second in Simulink corresponds to (N * Tu) seconds in the HDL

simulator, where Tu is an absolute time unit (for example, ms, ns, etc.)
and N is a scale factor.
In absolute timing mode, all sample times and clock periods in Simulink are
quantized to HDL simulator ticks. The following pseudocode illustrates the
conversion:
8-82
tInTicks = tInSecs * (tScale / tRL)
where:
• tInTicks is the HDL simulator time in ticks.

• tInSecs is the Simulink time in seconds.
• tScale is the timescale setting (unit and scale factor) chosen in the
Timescales pane of the HDL Cosimulation block.
• tRL is the HDL simulator resolution limit.
For example, given a Timescales pane setting of 1 s and an HDL simulator

resolution limit of 1 ns, an output port sample time of 12 ns would be
converted to ticks as follows:
tInTicks = 12ns * (1s / 1ns) = 12
Operation of Absolute Timing Mode

To configure the Timescales parameters for absolute timing mode, you select
a unit of absolute time that corresponds to a Simulink second, rather than
selectingTick.
Absolute Timing Mode Example

To understand the operation of absolute timing mode, you will again consider
the example model discussed in “Operation of Relative Timing Mode” on page
8-78. Suppose that the model is reconfigured as follows:

- Timescale parameters: 1 s of Simulink time corresponds to 1 s of
HDL simulator time.
- Total simulation time: 60e-9 s (60ns)
- Input port (/inverter/inport) sample time: 24e-9 s (24 ns)
- Output port (/inverter/outport ) sample time: 12e-9 s (12 ns)
- Clock (inverter/clk) period: 10e-9 s (10 ns)
8-83
• HDL simulator resolution limit: 1 ns
Given these simulation parameters, the Simulink software will cosimulate

with the HDL simulator for 60 ns, during which Simulink will sample inputs
at a intervals of 24 ns, update outputs at intervals of 12 ns, and drive clocks
at intervals of 10 ns.
The following figure shows a ModelSim wave window after a cosimulation

run.
Timing Mode Usage Considerations

When setting a timescale mode, you may need to choose your setting based on
the following considerations.
• “Timing Mode Usage Restrictions” on page 8-85

• “Noninteger Time Periods” on page 8-85
8-84
Timing Mode Usage Restrictions

The following restrictions apply to the use of absolute and relative timing
modes:
• When multiple HDL Cosimulation blocks in a model are communicating

with a single instance of the HDL simulator, all HDL Cosimulation blocks
must have the same Timescales pane settings.
• If you change the Timescales pane settings in an HDL Cosimulation block
between consecutive cosimulation runs, you must restart the simulation in
the HDL simulator.
• If you specify a Simulink sample time that cannot be expressed as a whole
number of HDL ticks, you will get an error.
Noninteger Time Periods

When using noninteger time periods, the HDL simulator cannot represent
such an infinitely repeating value. So the simulator truncates the time period,
but it does so differently than how Simulink truncates the value, and the
two time periods no longer match up.
The following example demonstrates how to set the timing relationship in the
1
following scenario: you want to use a sample period of in Simulink,
which corresponds to a noninteger time period. 3Hz
The key idea here is that you must always be able to relate a Simulink time
with an HDL tick. The HDL tick is the finest time slice the HDL simulator
recognizes; for ModelSim, the default tick is 1 ns, but it can be made as
precise as 1 fs.
However, a 3 Hz signal actually has a period of 333.33333333333... ms, which

is not a valid tick period for the HDL simulator. The HDL simulator will
truncate such numbers. But Simulink does not make the same decision; thus,
for cosimulation where you are trying to keep two independent simulators in
synchronization, you should not assume anything. Instead you have to decide
whether it is convenient to truncate or round the number.
8-85
Therefore, the solution is to "snap" either the Simulink sample time or the
HDL sample time (via the timescale) to valid numbers. There are infinite
possibilities, but here are some possible ways to perform a snap:
• Change Simulink sample times from 1/3 sec to 0.33333 sec and set the
cosimulation block timescale to ’1 second in Simulink = 1 second in the
HDL simulator’. If you are specifying a clock in the HDL Cosimulation
block Clocks pane, its period should be 0.33333 sec.
• Keep Simulink sample times at 1/3 sec. and 1 second in Simulink = 6 ticks
in the HDL simulator.
- If you are specifying a clock in the HDL Cosimulation block Clocks
pane, its period should be 1/3. Briefly, this specification tells Simulink to
make each Simulink sample time correspond to every (1/3*6) = 2 ticks,
regardless of the HDL time resolution.
- If your default HDL simulator resolution is 1 ns, that means your HDL
sample times are every 2 ns. This sample time will work in a way so that
for every Simulink sample time there is a corresponding HDL sample
time.
- However, Simulink thinks in terms of 1/3 sec periods and the HDL in
terms of 2 ns periods. Thus, you could get confused during debug. If you
want this to match the real period (such as to 5 places, i.e. 333.33ms),
you can follow the next option listed.
• Keep Simulink sample times at 1/3 sec and 1 second in Simulink =
0.99999e9 ticks in the HDL simulator. If you are specifying a clock in the
HDL Cosimulation block Clocks pane, its period should be 1/3.
Setting HDL Cosimulation Block Port Sample Times

In general, Simulink handles the sample time for the ports of an HDL
Cosimulation block as follows:
• If an input port is connected to a signal that has an explicit sample time,

based on forward propagation, Simulink applies that rate to that input port.
• If an input port is connected to a signal that does not have an explicit sample
time, Simulink assigns a sample time that is equal to the least common
multiple (LCM) of all identified input port sample times for the model.
8-86
• After Simulink sets the input port sample periods, it applies user-specified
output sample times to all output ports. Sample times must be explicitly
defined for all output ports.
If you are developing a model for cosimulation in relative timing mode,

consider the following sample time guideline:
Specify the output sample time for an HDL Cosimulation block as an

integer multiple of the resolution limit defined in the HDL simulator. Use
the HDL simulator command report simulator state to check the
resolution limit of the loaded model. If the HDL simulator resolution
limit is 1 ns and you specify a block’s output sample time as 20, Simulink
interacts with the HDL simulator every 20 ns.
8-87
Clock, Reset, and Enable Signals

In this section...
“Driving Clocks, Resets, and Enables” on page 8-88
“Adding Signals Using Simulink Blocks” on page 8-88
“Creating Optional Clocks with the Clocks Pane of the HDL Cosimulation
Block” on page 8-89
“Driving Signals by Adding Force Commands” on page 8-92
Driving Clocks, Resets, and Enables

You can create rising-edge or falling-edge clocks, resets, or clock enable
signals that apply internal stimuli to your model under cosimulation. You can
add these signals by:
• “Adding Signals Using Simulink Blocks” on page 8-88

• “Creating Optional Clocks with the Clocks Pane of the HDL Cosimulation
Block” on page 8-89
• “Driving Signals by Adding Force Commands” on page 8-92
• Implementing these signals directly in HDL code. If your model is part of a
much larger HDL design, you (or the larger model designer) may choose
to implement these signals in the Verilog or VHDL files. However, that
implementation exceeds the scope of this documentation; see an HDL
reference for more information.
Adding Signals Using Simulink Blocks

Add rising-edge or falling-edge clocks, resets, or clock enable signals to your
Simulink model using Simulink blocks. See the Simulink User Guide and
Reference for instructions on adding blocks to a model.
In the following example excerpt, the shaded area shows a clock, a reset, and
a clock enable signal as input to a multiple HDL Cosimulation block model.
These signals are created using two Simulink data type conversion blocks and
a constant source block, which connect to the HDL Cosimulation block labeled
"Manchester Receiver Subsystem".
8-88
Creating Optional Clocks with the Clocks Pane of the

HDL Cosimulation Block
Note For ModelSim and Incisive Users Only
When you specify a clock in your block definition, Simulink creates a

rising-edge or falling-edge clock that drives the specified HDL signal.
Simulink attempts to create a clock that has a 50% duty cycle and a predefined
phase that is inverted for the falling edge case. If applicable, Simulink
degrades the duty cycle to accommodate odd Simulink sample times, with a
worst case duty cycle of 66% for a sample time of T=3.
8-89
Whether you have configured the Timescales pane for relative timing mode
or absolute timing mode, the following restrictions apply to clock periods:
• If you specify an explicit clock period, you must enter a sample time equal
to or greater than 2 resolution units (ticks).
• If the clock period (whether explicitly specified or defaulted) is not an even
integer, Simulink cannot create a 50% duty cycle, and therefore the HDL
Verifier software creates the falling edge at
clockperiod / 2
(rounded down to the nearest integer).
For more information on calculating relative and absolute timing modes,

see “Defining the Simulink and HDL Simulator Timing Relationship” on
page 8-75.
The following figure shows a timing diagram that includes rising and falling
edge clocks with a Simulink sample time of T=10 and an HDL simulator
resolution limit of 1 ns. The figure also shows that given those timing
parameters, the clock duty cycle is 50%.
Rising Edge Clock
50% Duty Cycle

Simulink Sample Period, T=10
t
1 ns
HDL Simulator Resolution Limit
Falling Edge Clock
To create clocks, perform the following steps:
1 In the HDL simulator, determine the clock signal path names you plan to
define in your block. To do so, you can use the same method explained for
8-90
determining the signal path names for ports in step 1 of “Map HDL Signals
to Block Ports” on page 4-17.
2 Select the Clocks tab of the Block Parameters dialog box. Simulink
displays the dialog box as shown in the next figure (example shown for
use with Incisive).
3 Click New to add a new clock signal.
4 Edit the clock signal path name directly in the table under the Full HDL
Name column by double-clicking the default clock signal name (/top/clk).
Then, specify your new clock using HDL simulator path name syntax. See
“Specify HDL Signal/Port and Module Paths for Cosimulation” on page
4-18.
The HDL simulator does not support vectored signals in the Clocks pane.
Signals must be logic types with 1 and 0 values.
8-91
5 To specify whether the clock generates a rising-edge or falling edge signal,

select Rising or Falling from the Active Clock Edge list.
6 The Period field specifies the clock period. Accept the default (2), or
override it by entering the desired clock period explicitly by double-clicking
in the Period field.
Specify the Period field as an even integer, with a minimum value of 2.
7 When you have finished editing clock signals, click Apply to register your
The following dialog box defines the rising-edge clock clk for the HDL
Cosimulation block, with a default period of 2 (example shown for use with
Incisive).
Driving Signals by Adding Force Commands

You can drive clocks, resets, and enable signals in either of two ways:.
8-92
• By adding force commands to the Simulation pane (ModelSim and Incisive

users only)
• By driving signals with one of the HDL Verifier HDL simulator launch
commands (vsim or nclaunch) and the force command
Examples: force Command entered in HDL Cosimulation block

Simulation Pane
The following is an example of entering force commands in the Simulation
pane of the HDL Cosimulation block for use with Incisive:
The following is an example of entering force commands in the Simulation

pane of the HDL Cosimulation block for use with ModelSim:
8-93
Examples: force Command used with HDL Verifier HDL

Simulator Launch Command
vsim function and force command (ModelSim users):
vsim('tclstart', {'force /iqconv/clk 1 0, 0 5 ns -repeat 10 ns ',

'force /iqconv/clk_enable 1', 'force /iqconv/reset 1'});
nclaunch function and force command (Incisive users):
nclaunch('tclstart',['-input "{@force osc_top.clk_enable 1 -after 0ns}"',

'-input "{@force osc_top.reset 0 -after 0ns 1 -after 40ns 0 -after 120ns}"',
'-input "{@force osc_top.clk 1 -after 0ns 0 -after 40ns -repeat 80ns}"']);
8-94
TCP/IP Socket Ports
TCP/IP Socket Ports

When you specify a TCP/IP socket port, choose an available port or
service name (alias). If you are uncertain what port is available, use
hdldaemon(`socket', 0) to get an available port. If you choose a port that
is already in use, you will get an error message.
When you set up communication between computers, you must specify the
host name as well as the port name on the client side.
Examples:
<port-num> 4449
<port-alias> matlabservice
<host>:<port-num> compa:4449
<port-alias>@<host-ia> [email protected]
Note that TCP/IP port filtering on either the client or server side can cause
the HDL Verifier interface to fail to make a connection. If you get an error,
remove filtering (see OS user guide), or try a different port.
8-95
8-96
9
System Objects
• “Create System Objects” on page 9-2

• “Set Up System Objects” on page 9-4
• “Process Data Using System Objects” on page 9-7
• “Tuning System object Properties in MATLAB” on page 9-10
• “Find Help and Examples for System Objects” on page 9-12
9 System Objects
Create System Objects

In this section...
“Create a System object” on page 9-2
“Change a System object Property” on page 9-3
“Check if a System object Property Has Changed” on page 9-3
“Run a System object” on page 9-3
“Display Available System Objects” on page 9-3
A System object is a MATLAB object-oriented implementation of an algorithm.

System objects extend MATLAB by enabling you to model dynamic systems
represented by time-varying algorithms. System objects are well integrated
into the MATLAB language, regardless of whether you are writing simple
functions, working interactively in the command window, or creating large
applications.
In contrast to MATLAB functions, System objects automatically manage

state information, data indexing, and buffering, which is particularly useful
for iterative computations or stream data processing. This enables efficient
processing of long data sets.
Note System objects predefined in the software do not support sparse

matrices. System objects you define support sparse matrices (see ).
Create a System object

To use System objects, you must first create an object. For example,
H = dsp.FFT % Create default FFT object, H
% Create input data

Fs = 1000; % Sampling frequency
T = 1/Fs; % Sample time
L = 1024; % Length of signal
t = (0:L-1)*T % Time vector
9-2
Create System Objects
% Sum of two sinusoids

X = 0.7*sin(2*pi*50*t.') + sin(2*pi*120*t.');
Change a System object Property

In general, you should set the object properties before you use the step
method to run data through the object. To change the value of a property,
use this format,
H.Normalize = true % Set the Normalize property
The property values of the FFT object, H, are displayed.
Check if a System object Property Has Changed

To check if a tunable property has changed since step was last called, use
this syntax:
flag = isChangedProperty(H,'Normalize')
flag is true if the Normalize property of object H has changed.
Run a System object

To execute a System object, use the step method.
Y = step(H,X); % Process input data, X
The output data from the step method is stored in Y, which, in this case,
is the FFT of X.
Display Available System Objects

To see a list of all the System objects for a particular package, type help
hdlverifier. To display help for specific objects, properties, or methods, see
“Find Help and Examples for System Objects” on page 9-12 .
9-3
9 System Objects
Set Up System Objects

In this section...
“Create a New System object” on page 9-4
“Retrieve System object Property Values” on page 9-4
“Set System object Property Values” on page 9-4
Create a New System object

You must create a System object before using it. You can create the object at
the MATLAB command line or within a program file. Your command-line code
and programs can pass MATLAB variables into and out of System objects.
For general information about working with MATLAB objects, see

“Object-Oriented Programming” in the MATLAB documentation.
Retrieve System object Property Values

System objects have properties that configure the object. You use the default
values or set each property to a specific value. The combination of a property
and its value is referred to as a Name-Value pair. You can display the list of
relevant property names and their current values for an object by using the
object handle only, <handleName>. Some properties are relevant only when
you set another property or properties to particular values. If a property
is not relevant, it does not display.
To display a particular property value, use the handle of the created object
followed by the property name: <handle>.<Name>.
Example
This example retrieves and displays the TransferFunction property value
for the previously created DigitalFilter object:
H.TransferFunction
Set System object Property Values

You set the property values of a System object to model the desired algorithm.
9-4
Set Up System Objects
Note When you use Name-Value pair syntax, the object sets property values
in the order you list them. If you specify a dependent property value before its
parent property, an error or warning may occur.
Set Properties for a New System object

To set a property when you first create the object, use Name-Value pair
syntax. For properties that allow a specific set of string values, you can use
tab completion to select from a list of valid values.
H1 = dsp.DigitalFilter('CoefficientsSource','Input port')
where
• H1 is the handle to the object

• dsp is the package name.
• DigitalFilter is the object name.
• CoefficientsSource is the property name.
• 'Input port' is the property value.
Set Properties for an Existing System object

To set a property after you have created an object, use either of the following
syntaxes:
H1.CoefficientsSource = 'Property'
or
set(H1,'CoefficientsSource','Property')
Use Value-Only Inputs

Some object properties have no useful default values or must be specified
every time you create an object. For these properties, you can specify only
the value without specifying the corresponding property name. If you use
value-only inputs, those inputs must be in a specific order, which is the
9-5
9 System Objects
same as the order in which the properties are displayed. Refer to the object
reference page for details.
H2 = dsp.FIRDecimator(3,[1 .5 1])
specifies the DecimationFactor as 3 and the Numerator as [1 .5 1].
9-6
Process Data Using System Objects

In this section...
“What are System object Methods?” on page 9-7
“The Step Method” on page 9-7
“Common Methods” on page 9-7
“Advantages of Using Methods” on page 9-9
What are System object Methods?

After you create a System object, you use various object methods to process
data or obtain information from or about the object. All methods that are
applicable to an object are described in the reference pages for that object.
System object method names begin with a lowercase letter and class and
property names begin with an uppercase letter. The syntax for using methods
is <method>(<handle>), such as step(H).
The Step Method

The step method is the key System object method. You use step to process
data using the algorithm defined by that object. The step method performs
other important tasks related to data processing, such as initialization and
handling object states. Every System object has its own customized step
method, which is described in detail on the step reference page for that object.
For more information about the step method and other available methods, see
the descriptions in “Common Methods” on page 9-7.
Common Methods
All System objects support the following methods, each of which is described
in a method reference page associated with the particular object. In cases
where a method is not applicable to a particular object, calling that method
has no effect on the object.
9-7
9 System Objects
Method Description
step Processes data using the algorithm defined by the
object. As part of this processing, it initializes needed
resources, returns outputs, and updates the object
states. After you call the step method, you cannot
change any input specifications (i.e., dimensions, data
type, complexity). During execution, you can change
only tunable properties. The step method returns
regular MATLAB variables.
Example: Y = step(H,X)
release Releases any special resources allocated by the object,
such as file handles and device drivers, and unlocks
the object. For System objects, use the release
method instead of a destructor. See “Understand
System object Modes” on page 9-10.
clone Creates another object with the same property values
isLocked Returns a logical value indicating whether the object
is locked. See “Understand System object Modes” on
page 9-10.
reset Resets the internal states of the object to the initial
values for that object
isDone Applies to source objects only. Returns a logical value
indicating whether the step method has reached
the end of the data file. If a particular object does
not have end-of-data capability, this method value
returns false.
isChangedProperty Returns true if the specified tunable property value
has changed since the last call to step.Example: flag
= isChangedProperty(obj,'propertyName')
info Returns a structure containing characteristic
information about the object. The fields of this
structure vary depending on the object. If a particular
object does not have characteristic information, the
structure is empty.
9-8
Method Description
getNumInputs Returns the number of inputs (excluding the object
itself) expected by the step method. This number
varies for an object depending on whether any
properties enable additional inputs.
getNumOutputs Returns the number of outputs expected from the step
method. This number varies for an object depending
on whether any properties enable additional outputs.
getDiscreteState Returns the discrete states of the object in a structure.
If the object is unlocked (when the object is first
created and before you have run the step method
on it or after you have released the object), the
states are empty. If the object has no discrete states,
getDiscreteState returns an empty structure.
Advantages of Using Methods

System objects use a minimum of two commands to process data—a
constructor to create the object and the step method to run data through the
object. This separation of declaration from execution lets you create multiple,
persistent, reusable objects, each with different settings. Using this approach
avoids repeated input validation and verification, allows for easy use within a
programming loop, and improves overall performance. In contrast, MATLAB
functions must validate parameters every time you call the function.
These advantages make System objects particularly well suited for processing
streaming data, where segments of a continuous data stream are processed
iteratively. This ability to process streaming data provides the advantage of
not having to hold large amounts of data in memory. Use of streaming data
also allows you to use simplified programs that use loops efficiently.
9-9
9 System Objects
Tuning System object Properties in MATLAB

In this section...
“Understand System object Modes” on page 9-10
“Change Properties While Running System Objects” on page 9-11
“Change System object Input Complexity or Dimensions” on page 9-11
Understand System object Modes

System objects are in one of two modes: unlocked or locked. After you create
an object and until it starts processing data, that object is in unlocked mode.
You can change any of its properties as desired.
The object initializes and locks when it begins processing data. The typical
way in which an object becomes locked is when the step method is called on
that object. To determine if an object is locked, use the isLocked method. To
unlock an object, use the release method. When the object is locked, you
cannot change any of the following:
• Number of inputs or outputs

• Data type
• Dimensions of inputs or tunable properties, except for System objects
that support variable-size data. Variable-size data is data whose size can
change at run time. By contrast, fixed-size data is data whose size is known
and locked at compile time and, therefore, cannot change at run time.
• Value of any nontunable property
Several System objects do not allow changing the complexity of inputs from
real to complex. You can, however, change the input complexity from complex
to real without unlocking the object.
These restrictions allow the object to maintain states and allocate memory
appropriately.
9-10
Tuning System object™ Properties in MATLAB®
Change Properties While Running System Objects

When an object is in locked mode, it is processing data and you can only
change the values of properties that are tunable. To determine if a particular
System object property is tunable, see the corresponding reference page or
use a command of this form:
help dsp.FFT.Normalize
where
• dsp is the package name.

• FFT is the object name.
• Normalize is the property name.
Note Unless otherwise specified, System object properties are not tunable.
For information on locked and unlocked modes, see “Understand System

object Modes” on page 9-10.
Change System object Input Complexity or

Dimensions
During simulations you can change an input’s complexity from complex to
real, but not from real to complex. You cannot change any input complexity
during code generation.
For objects that do not support variable-size input, if you change the input
dimensions while the object is in locked mode, the object produces a warning
and unlocks. The object then reinitializes the next time you call the step
method. See the object’s reference page for more information. You can change
the value of a tunable property and the input size without a warning or error
being produced. For all other changes at runtime, an error occurs.
9-11
9 System Objects
Find Help and Examples for System Objects

Refer to the following resources for more information about System objects.
• Object help – help hdlverifier.HdlCosimulation

• Documentation pages for object – doc hdlverifier.HdlCosimulation
• Property help – help hdlverifier.HdlCosimulation
•
To view examples, go to the Help contents for the associated product.Under

Examples, select Cosimulation with Cadence Incisive or Cosimulation
with Mentor Graphics ModelSim.
9-12
FPGA-in-the-Loop
• Chapter 10, “About FPGA-in-the-Loop (FIL) Simulation”

• Chapter 11, “FIL Preparation”
• Chapter 12, “FIL Interface Generation and Simulation”
• Chapter 13, “FIL Using HDL Coder HDL Workflow Advisor”
• Chapter 14, “Troubleshooting FPGA-in-the-Loop”
• Chapter 15, “FIL Examples”
• Chapter 16, “HDL Verifier FPGA Board Support Packages”
• Chapter 17, “FPGA Board Customization”
10
About FPGA-in-the-Loop
(FIL) Simulation
10 About FPGA-in-the-Loop (FIL) Simulation
FPGA-in-the-Loop (FIL) Simulation

In this section...
“What is FPGA-in-the-Loop Simulation?” on page 10-2
“What You Need To Know” on page 10-6
What is FPGA-in-the-Loop Simulation?

• “Overview” on page 10-2
• “Communication Channel” on page 10-5
• “Downstream Workflow Automation” on page 10-5
Overview
FPGA-in-the-Loop (FIL) simulation provides the capability to use Simulink or
MATLAB software for testing designs in real hardware for any existing HDL
code. The HDL code can be either manually written or software generated
from a model subsystem.
You must have HDL code to perform FIL simulation. There are two FIL
workflows:
• You have existing HDL code (FIL Wizard).
Note The FIL Wizard uses any synthesizable HDL code including code
automatically generated from Simulink models by HDL Coder software
• You have MATLAB code or a Simulink model and an HDL Coder license
(HDL workflow advisor).
Note When you use FIL in the Workflow Advisor, HDL Coder uses the
loaded design to create the HDL code.
10-2
No matter which workflow you choose, FIL performs the following processes
when it creates the block or System object:
• Generates a FIL block or FIL System object that represents the HDL code
• Provides synthesis, logical mapping, place-and-route (PAR), programming
file generation, and communications channel.
• Loads the design onto an FPGA
All these capabilities are specifically designed for a particular board and
tailored to your RTL code.
As part of FIL simulation, the block or System object and your model or
application:
• Transmits data from Simulink or MATLAB to the FPGA

• Receives data from the FPGA
• Exercises the design in a real environment
FIL Communications. The following figure demonstrates how HDL Verifier

communicates between Simulink and the FPGA board using FIL simulation.
10-3
Note When programming the FPGA, HDL Verifier assumes that there is
only one download cable connected to the Host PC and it can be automatically
recognized by the FPGA programming software. If this is not the case, use
FPGA programming software to program your FPGA with the correct options.
System-Level View. All DUT I/Os are routed to Simulink through the FIL
comm logic.
10-4
Communication Channel
FIL provides the communication channel for sending and receiving data
between Simulink and the FPGA. This channel uses a Gigabit Ethernet
connection. Because communication between Simulink and the FPGA is
strictly synchronized, the FIL simulation provides a more dependable
verification method.
Downstream Workflow Automation

To create the FIL programming file, the software performs the following tasks:
• Generates HDL code for the specified DUT and creates an ISE project.
• Along with your FPGA design software, synthesizes, maps, places and
routes, and creates a programming file for the FPGA.
• Downloads the programming file to the FPGA on the development board
through the board’s normal configuration connection. Typically, that
connection is a serial line over a USB cable (see board manufacturer’s
instructions for how to make this connection).
- For FIL simulation blocks, clicking Load on the FIL block mask initiates
the programming file download.
10-5
- For FIL simulation System objects, issuing the programFPGA method

initiates the programming file download.
What You Need To Know

For FIL simulation, you must have the following items or information ready:
• For FIL Wizard:

- Provide HDL code (either manually written or software generated) for
the design you intend to test.
- Select HDL files and specify the top-level module name.
- Review port settings and make sure the FIL Wizard identified input and
output signals and signal sizes as expected.
- If you are using Simulink, provide a Simulink model ready to receive
the generated FIL block.
• For HDL Workflow Advisor:
You can generate code and run FIL from any suitable Simulink model. Just
follow the workflow for FPGA-in-the-Loop. See “FIL with HDL Workflow
Advisor In Simulink” on page 13-2. For MATLAB code, see the workflow
described in “FIL with HDL Workflow Advisor In MATLAB” on page 13-9.
10-6
11
FIL Preparation
• “FPGA-in-the-Loop Simulation Workflows” on page 11-2

• “Prepare DUT For FIL Interface Generation” on page 11-4
• “Set Up Hardware and Hardware Tools” on page 11-18
• “FPGA Reset” on page 11-25
11 FIL Preparation
FPGA-in-the-Loop Simulation Workflows

You must have HDL code to perform FIL simulation. There are two FIL
workflows:
• You have existing HDL code (FIL Wizard).
Note The FIL Wizard uses any synthesizable HDL code including code
automatically generated from Simulink models by HDL Coder software
• You have MATLAB code or a Simulink model and an HDL Coder license
(HDL workflow advisor).
Note When you use FIL in the Workflow Advisor, HDL Coder uses the
loaded design to create the HDL code.
For either workflow, the first three steps are the same:
1 Download “FPGA Board Support Packages for FIL” on page 16-2 or

create custom board definition files for use with FIL (see “FPGA Board
Customization” on page 17-2)
2 “Prepare DUT For FIL Interface Generation” on page 11-4
3 “Set Up Hardware and Hardware Tools” on page 11-18
For the next step, click on the link for the workflow you are going to follow:
• If you have existing HDL code, select block or System object generation
using the FIL Wizard:
- “FIL Block Generation” on page 12-2
- “FIL System Object Generation” on page 12-12
• If you need the HDL workflow advisor to generate HDL code, select block
or System object generation using HDL workflow advisor:
11-2
FPGA-in-the-Loop Simulation Workflows
- “FIL with HDL Workflow Advisor In Simulink” on page 13-2

- “FIL with HDL Workflow Advisor In MATLAB” on page 13-9
Note To use the HDL Coder HDL workflow advisor for Simulink to generate
a FIL interface, you must have an HDL Coder license.
11-3
11 FIL Preparation
Prepare DUT For FIL Interface Generation

In this section...
“Prepare Files and Information Required for FIL Interface Generation”
on page 11-4
“Apply FIL System Object Requirements” on page 11-5
“Apply FIL Block Requirements” on page 11-10
Prepare Files and Information Required for FIL

Interface Generation
• “For FIL Wizard” on page 11-4
• “For HDL Workflow Advisor” on page 11-5
For FIL Wizard

Have the following items or information ready:
• Provide HDL code (either manually written or software generated) for

the design you intend to test.
• Select HDL files and specify the top-level module name.
• Review port settings and make sure the FIL Wizard identified input and
output signals and signal sizes as expected.
• If you are using Simulink, provide a Simulink model ready to receive the
generated FIL block.
Next Steps
• If you are creating a FIL System object, next go to “Apply FIL System
Object Requirements” on page 11-5.
• If you are creating a FIL block, next go to “Apply FIL Block Requirements”
on page 11-10.
11-4
For HDL Workflow Advisor

You can generate code and run FIL from any suitable Simulink model.
Next Steps
• If you are creating a FIL System object, next go to “Apply FIL System
Object Requirements” on page 11-5.
• If you are creating a FIL block, next go to “Apply FIL Block Requirements”
on page 11-10.
Apply FIL System Object Requirements

• “The FIL Process for System Objects” on page 11-5
• “HDL Code Considerations for FIL System Objects” on page 11-6
• “FIL-Specific Rules for System Objects” on page 11-9
• “MATLAB Code Considerations for FIL System Objects” on page 11-10
The FIL Process for System Objects

The FIL Wizard and HDL Coder HDL Workflow Advisor each perform the
following actions:
• Convert HDL code into System object inputs and outputs.

• Walk you through identifying: FPGA device, source files, I/O ports, and
port info.
• Add the required logic the device under test (DUT) requires to communicate
with MATLAB.
Generally, the size of the additional logic is very small and has minimal
impact on the fit of your design onto the FPGA.
• Create the programming file and a FIL System object.
11-5
11 FIL Preparation
Note If a design does not fit in the device or does not meet timing goals, the
software may not be able to create the programming file. In such situations,
you may see a warning that the design does not meet the timing goals, but
it will still generate a programming file, or you may get an error and no
programming file. Either make changes to some part of your design, or use a
different development board.
After FIL interface generation is complete, you can use the method
programFPGA to load the programming file to the FPGA board and make any
adjustments to runtime options and signal attributes.
When you are ready to begin, read through the following topics and make sure
your DUT adheres to the rules and guidelines described in each section:
• “HDL Code Considerations for FIL System Objects” on page 11-6

• “FIL-Specific Rules for System Objects” on page 11-9
• “MATLAB Code Considerations for FIL System Objects” on page 11-10
When you are finished with these sections, next go to either “FIL System
Object Generation” on page 12-12 or “FIL with HDL Workflow Advisor In
MATLAB” on page 13-9.
HDL Code Considerations for FIL System Objects

The rules you must follow when using legacy or auto-generated HDL code for
generating a FIL System object are described in the following table.
11-6
Category Considerations
HDL files All HDL names must be legal as defined in the VHDL
1993 standard.
Top-level design • The top-level design must be VHDL or Verilog.
• The top-level HDL file should contain an entity/module
with the same name as the file name.
• FIL block generation supports both combinatorial
and sequential logic. For combinatorial logic, CLK,
CLK_ENABLE, and RESET are not required.
Inputs and • Input and output ports should be of the following
outputs types:
- std_logic (VHDL)
- std_logic_vector (VHDL)
- Reg, wire (Verilog)
• Vector ports range must be:
- Descending (e.g. 9 DOWNTO 0, 9:0)
- Literal (e.g. (a DOWNTO b) is not supported)
- Descending TO syntax is not supported
• For Verilog, ports names must be lowercase. Module
name must be lowercase, also.
• All input and output ports should be included.
• There must be at least one output port.
11-7
11 FIL Preparation
Clock • Sequential HDL design must have only one clock
at the top entity. Clock and reset are required. For
combinatorial HDL design, the clock bundle is not
required.
• Clock should be named: clock or clk. Using these
names is not a requirement, but if the clock is not
named clock or clk, you must designate which signal
is the clock signal in the FIL Wizard.
• Clock port should be 1-bit. For VHDL, it must be of
type std_logic.
Reset • The HDL design must have a reset to be able to reset
the FPGA prior to simulation.
• For sequential design, there should be only one reset.
Clock and reset are required. For combinatorial HDL
design, the clock bundle is not required.
• Reset should be named: reset or rst. Using these
names is not a requirement, but if the reset is not
named reset or rst, you must designate which signal
is the reset signal in the FIL Wizard.
• Reset port should be 1-bit. For VHDL, these ports
must be of type std_logic.
Clock enable • For sequential design, if you choose a clock enable,
there should be only one.
• Clock enable port should be 1-bit. For VHDL, these
ports must be of type std_logic.
• If you have a clock enable, it should be named one
of the following: clock_enable, clock_enb, clock_en,
clk_enable, clk_enb, clk_en, ce. Using these names
is not a requirement, but if the clock enable is not
named one of these names, you must designate which
signal is the clock enable signal in the FIL Wizard.
11-8
DUT entity All the ports at DUT level should be well defined and the
bit width should be specified. Using a variable as the bit
width is not allowed.
Clock edge Clock the DUT input and output ports by positive edge.
Negative edge is not allowed.
Non-supported • Bidirectional ports
data types
• Arrays, record types
Non-supported • VHDL configuration statement
constructs
• Verilog include files
• Macros
• Escaped names
• Generics (VHDL), Parameters (Verilog)
• Duplicated port names (Verilog)
FIL-Specific Rules for System Objects
FIL input and • Total input must be less than 1467 bytes
output data set
Where total input data set equals the sum of the input
limits
size rounded up to bytes
• Output data set must also be less than 1467 bytes
Where total output data set equals the sum of the
output size rounded up to bytes * overclocking factor
Output frame The frame size is calculated by the following formula:
size output frame size = input frame size * overclocking /
downsample
11-9
11 FIL Preparation
MATLAB Code Considerations for FIL System Objects
MATLAB HDL Verifier FIL simulation supports only the following

compatibilities data types:
• Integer
• Logical
• Fixed point
Apply FIL Block Requirements

• “The FIL Process for Blocks” on page 11-10
• “HDL Code Considerations for FIL Blocks” on page 11-11
• “Simulink Model Considerations for FIL Blocks” on page 11-14
• “FIL-Specific Rules for Blocks” on page 11-15
The FIL Process for Blocks

The FIL Wizard and HDL Coder HDL Workflow Advisor each perform the
following actions:
• Convert HDL code into block signals with timing applied.

• Walk you through identifying: FPGA device, source files, I/O ports, and
port info.
• Add the required logic the device under test (DUT) requires to communicate
with Simulink.
Generally, the size of the additional logic is very small and has minimal
impact on the fit of your design onto the FPGA.
• Create the programming file and a FIL simulation block.
11-10
Note If a design does not fit in the device or does not meet timing goals, the
software may not be able to create the programming file. In such situations,
you may see a warning that the design does not meet the timing goals, but
it will still generate a programming file, or you may get an error and no
programming file. Either make changes to some part of your design, or use a
different development board.
After FIL interface generation is complete, you can use the FIL block mask to
load the programming file to the FPGA board and make any adjustments to
runtime options and signal attributes.
When you are ready to begin, read through the following topics and make sure
your DUT adheres to the rules and guidelines described in each section:
• “HDL Code Considerations for FIL Blocks” on page 11-11

• “Simulink Model Considerations for FIL Blocks” on page 11-14
• “FIL-Specific Rules for Blocks” on page 11-15
When you are finished with these sections, next go to “FIL Block Generation”
on page 12-2 or “FIL with HDL Workflow Advisor In Simulink” on page 13-2.
HDL Code Considerations for FIL Blocks

The rules you must follow when using legacy or auto-generated HDL code for
generating a FIL block are described in the following table.
HDL files All HDL names must be legal as defined in the VHDL
1993 standard.
Top-level design • The top-level design must be VHDL or Verilog.
• The top-level HDL file should contain an entity/module
with the same name as the file name.
• FIL block generation supports both combinatorial
and sequential logic. For combinatorial logic, CLK,
CLK_ENABLE, and RESET are not required.
11-11
11 FIL Preparation
Inputs and • Input and output ports should be of the following
outputs types:
- std_logic (VHDL)
- std_logic_vector (VHDL)
- Reg, wire (Verilog)
• Vector ports range must be:
- Descending (e.g. 9 DOWNTO 0, 9:0)
- Literal (e.g. (a DOWNTO b) is not supported)
- Descending TO syntax is not supported
• For Verilog, ports names must be lowercase. Module
name must be lowercase, also.
• All input and output ports should be included.
• There must be at least one output port.
Clock • Sequential HDL design must have only one clock
at the top entity. Clock and reset are required. For
combinatorial HDL design, the clock bundle is not
required.
• Clock should be named: clock or clk. Using these
names is not a requirement, but if the clock is not
named clock or clk, you must designate which signal
is the clock signal in the FIL Wizard.
• Clock port should be 1-bit. For VHDL, it must be of
type std_logic.
11-12
Reset • The HDL design must have a reset to be able to reset
the FPGA prior to simulation.
• For sequential design, there should be only one reset.
Clock and reset are required. For combinatorial HDL
design, the clock bundle is not required.
• Reset should be named: reset or rst. Using these
names is not a requirement, but if the reset is not
named reset or rst, you must designate which signal
is the reset signal in the FIL Wizard.
• Reset port should be 1-bit. For VHDL, these ports
must be of type std_logic.
Clock enable • For sequential design, if you choose a clock enable,
there should be only one.
• Clock enable port should be 1-bit. For VHDL, these
ports must be of type std_logic.
• If you have a clock enable, it should be named one
of the following: clock_enable, clock_enb, clock_en,
clk_enable, clk_enb, clk_en, ce. Using these names
is not a requirement, but if the clock enable is not
named one of these names, you must designate which
signal is the clock enable signal in the FIL Wizard.
DUT entity All the ports at DUT level should be well defined and the
bit width should be specified. Using a variable as the bit
width is not allowed.
Clock edge Clock the DUT input and output ports by positive edge.
Negative edge is not allowed.
11-13
11 FIL Preparation
Non-supported • Bidirectional ports
data types
• Arrays, record types
Non-supported • VHDL configuration statement
constructs
• Verilog include files
• Macros
• Escaped names
• Generics (VHDL), Parameters (Verilog)
• Duplicated port names (Verilog)
Simulink Model Considerations for FIL Blocks

The rules you must follow for integrating the FIL block into your Simulink
model are described in the following table.
General model • Use Single tasking solver mode (set with Configuration
rules Parameters). HDL Verifier FIL does not support
multitasking solver mode.
• Choose discrete, fixed-step solvers or variable-step
solvers. HDL Verifier FIL supports both types of
solvers.
Incompatibilities Be aware that HDL Verifier FIL simulation currently
with Simulink does not support the following:
• Instantiation of the FIL block in a triggered subsystem

• Instantiation of the FIL block in an asynchronous
function-call subsystem
• A continuous sample time
• A nonzero sample time offset
Initialization Simulink starts from time 0 every time, which means
the RAM in Simulink is initialized to zero. However,
11-14
this is not true in hardware. If you have RAM in your

design, the first simulation will match Simulink, but
any subsequent runs may not match.
The workaround is to reload the FPGA bitstream before
re-running the simulation. To do this, click Load on
the FIL block mask.
FIL-Specific Rules for Blocks
FIL block • The input frame size must be an integer multiple of

settings rules the output frame size.
• All signals must be of the same bit-width as their
corresponding port in the hardware.
• In frame mode, all inputs must have the same frame
size and all outputs must have the same frame size
(but possibly different from the inputs).
• When processing as frames, make sure all input
signals have the same sample times and all output
signals have the same sample times (that can be
different from the inputs).
• When processing as samples, only scalars are
supported. When processing as frames, only column
vectors ([Nx1]) are supported.
• Supported data types are built-in data types and
fixed-point data types.
• Split complex signals into real and imaginary signals.
FIL simulation does not support complex signals.
• The output frame size must be less than the input
frame size so that the output frame has enough data
to drive a value at time 0. You can avoid this error by
11-15
11 FIL Preparation
either decreasing the output frame size or sample time

or increasing the input frame size or sample time.
FIL byte size • Total output must be less than 1467 bytes
limit
Where total input data set equals the sum of the input
size rounded up to bytes
• Output data set must also be less than 1467 bytes
Where total output data set equals the sum of the
output size rounded up to bytes * overclocking factor
For example, a subsystem with one 9-bit input (2 bytes)

and one 16-bit input (2 bytes) would have an input data
set of 4 bytes.
The overclocking factor is calculated based on one of
these equations:
• OCF =
fastest_dut_sample_rate/fastest_input_sample_rate
Or
• OCF = input_sample_time /
fastest_dut_sample_time
Where sample_time = 1/samplerate.
The overclocking factor is greater than 1 when there is

upsampling in the DUT, which results in a smaller DUT
sample time compared to the input.
Examine the following diagram:
• The input data set is 4 bytes.

• The overclocking factor is 1500.
11-16
The input sample time equals the sample rate which

in turn equals 1. The fastest sample time equals
1/1500
(the fastest sample rate is 1500). Therefore, the

overclocking factor is 1500.
• The output data set is 1 * 1500 = 1500 bytes, exceeding
the data set limit.
11-17
11 FIL Preparation
Set Up Hardware and Hardware Tools

In this section...
“Step 1. Set Up FPGA Development Board” on page 11-18
“Step 2. Set Up Board Connection” on page 11-18
“Step 3. Set Up FPGA Design Software Tools” on page 11-24
Step 1. Set Up FPGA Development Board

Set up your FPGA development board with the following procedure:
1 Make sure that the power switch is OFF and remains OFF.
2 Connect the AC power cord to the power plug.
3 Plug the power supply adapter cable into the FPGA development board.
4 Use the JTAG download cable to connect the FPGA development board
with the computer.
5 If you plan to use an Ethernet connection for FIL simulation, connect

the Ethernet connector on the FPGA development board directly to the
Ethernet adapter on your computer using the crossover Ethernet cable.
6 Make sure that all jumpers on the FPGA development board are in the
factory default position.
Step 2. Set Up Board Connection

FIL supports Ethernet and JTAG as connection methods. Some FPGA
boards support both connection methods, while some boards support only
11-18
one method. Choose one of the following setup instructions based on the
connection method you are going to use for FIL
• “JTAG Connection” on page 11-19

• “Ethernet Connection” on page 11-19
JTAG Connection
1 If you are using Linux, make sure that the Quartus II 64-bit library
folder (for example, /usr/local/quartus/linux64) is on the path in the
LD_LIBRARY_PATH environment variable before you start MATLAB.
2 There is no further hardware or software setup that you need to do.

Proceed to the next step, “Step 3. Set Up FPGA Design Software Tools” on
page 11-24.
Ethernet Connection
Follow these instructions to set up a Gigabit Ethernet network adapter on
your computer for FIL simulation.
Windows 7 Setup
Follow this procedure to set up the Gigabit Ethernet network adapter on

your Windows 7 system:
1 Open the Control Panel and type "view network connections" in the search
bar. Select View network connections in the search results.
2 Right-click the connection icon to your FPGA development board, and select
Properties from the pop-up menu.
11-19
11 FIL Preparation
3 Under This connection uses the following items, select Internet

Protocol Version 4 (TCP/IPv4), and click Properties.
11-20
4 Select Use the following IP address and set IP address to 192.168.0.1.

If this address is in use by another computer on your network, change it
to any available IP address on this subnet, such as 192.168.0.100. This
value indicates your host computer address. Set the Subnet mask to
255.255.255.0.
Your TCP/IP properties should look similar to those shown in the following
figure:
11-21
11 FIL Preparation
5 Click OK to exit TCP/IP Properties.
6 Click Close to exit Local Area Connection Properties.
Windows Vista Setup
1 Open the Control Panel.
2 Click Network and Sharing Center, and then click Manage network
connections.

Protocol Version 4 (TCP/IPv4), and click Properties.
11-22
5 Select Use the following IP address and set IP address to 192.168.0.1. If

this address is in use by another computer on your network, change it
255.255.255.0.
Windows XP Setup
2 Open Network connections.

Protocol (TCP/IP), and click Properties.
5 Select Use the following IP address and set IP address to 192.168.0.1. If

this address is in use by another computer on your network, change it
255.255.255.0.
Linux Setup
Use the ifconfig command to set up your local address. For example:
% ifconfig eth1 192.168.0.1
In this example, eth1 is the second Ethernet adapter on the Linux computer.
Check your system to determine which Ethernet adapter is connected to the
FPGA development board. The above command sets the local IP address to
11-23
11 FIL Preparation
192.168.0.1. If this address is in use by another computer on your network,

change it to any available IP address on this subnet, such as 192.168.0.100.
Step 3. Set Up FPGA Design Software Tools

Xilinx ISE (including miniBEE)
Set up your system environment for accessing Xilinx® ISE from MATLAB with
the function hdlsetuptoolpath. This function adds the required folders to
the MATLAB search path using the Xilinx installation folder as its argument.
• Windows:
hdlsetuptoolpath('ToolName', 'Xilinx ISE', 'ToolPath', 'C:\Xilinx\14.2\ISE_DS\ISE\bin\nt64')
This example assumes that the Xilinx ISE design suite is installed at
C:\Xilinx\14.2\ISE_DS\ISE\bin\nt64.
• Linux:
hdlsetuptoolpath('ToolName', 'Xilinx ISE', 'ToolPath', /local/Xilinx/14.2/ISE_DS/ISE/bin/lin64')
/local/Xilinx/14.2/ISE_DS/ISE/bin/lin64.
Note If you are using the miniBEE® BEEcube® hardware platform, make
sure you have the latest firmware for the miniBEE BEEcube board. See the
vendor site if you need to download this firmware.
Altera
Set up your system environment for accessing from MATLAB with the
function hdlsetuptoolpath. For example:
hdlsetuptoolpath('ToolName', 'Altera Quartus II', 'ToolPath', 'C:\Altera\12.0\quartus\bin64')
This example assumes that the Altera® FPGA design software is installed
at C:\Altera\12.0\quartus\bin64.
11-24
FPGA Reset
FPGA Reset
The following table lists which push button on the FPGA board is connected
to the reset pin.
Development Schematic Board Comments

Board Name Reference/SwitchPin
Altera Arria II CPU_RESET PB3 N/A
Altera Cyclone CPU_RESET S5 N/A
III
Altera Cyclone CPU_RESETn S6 N/A
IV GX
Altera DE2–115 KEY[0] KEY0 SwitchPin also
used to adjust
volume based on
the application.
Altera Nois II CPU_RESET_N CPU_RESET N/A
XUP Atlys RESET BRST Label="RESET"
Spartan-6
Spartan-6 SP601 CPU_RESET SW9.2 N/A
Spartan-6 SP605 CPU_RESET SW6.2 N/A
Xilinx FPGA CPU SW10 N/A
Virtex-4ML401 RESET
Virtex-4ML402 RESET
Virtex-4ML403 RESET
Xilinx CPU RESET SW7 N/A
Virtex-5ML505
Virtex-5ML506
Virtex-5ML507
11-25
11 FIL Preparation
Development Schematic Board Comments

Board Name Reference/SwitchPin
Xilinx Virtex-5 CPU RESET SW7 N/A
XUPV5–LX110T
Xilinx CPU RESET SW10.2 N/A
Virtex-6ML605
11-26
12
FIL Interface Generation

and Simulation
• “FIL Interface Generation with the FIL Wizard” on page 12-2

• “Perform FPGA-in-the-Loop Simulation” on page 12-27
12 FIL Interface Generation and Simulation
FIL Interface Generation with the FIL Wizard

In this section...
“FIL Block Generation” on page 12-2
“FIL System Object Generation” on page 12-12
FIL Block Generation

• “Step 1: Start FIL Wizard” on page 12-2
• “Step 3: Set FIL Options for FIL Block” on page 12-3
• “Step 4: Add HDL Source Files for FIL Block” on page 12-6
• “Step 5: Verify DUT I/O Ports for FIL Block” on page 12-8
• “Step 6: Specify Output Types for FIL Block” on page 12-10
• “Step 7: Specify Build Options for FIL Block” on page 12-11
• “Step 8: Initiate Build” on page 12-12
Step 1: Start FIL Wizard

Launch the FPGA-in-the-Loop Wizard by selecting one of the following
invocation methods:
• In the MATLAB command window, type the following:
>> filWizard
• In the Simulink model window, select Code > Verification

Wizards > FPGA-in-the-Loop (FIL).
To restore a previous session, use this command:
filWizard('./Subsystem_fil/Subsystem_fil.mat')
12-2
Step 3: Set FIL Options for FIL Block
In the FIL Options page:
1 FIL Simulation: Select Simulink.
2 Board Name: Select an FPGA development board. If you have not yet
downloaded an HDL Verifier FPGA board support package, see “FPGA
Board Support Packages for FIL” on page 16-2. (If you do not see any
boards listed, then you have not yet downloaded a support package). If you
plan to define a custom board yourself, see “FPGA Board Customization”
on page 17-2.
12-3
3 FPGA-in-the-Loop Connection: FIL simulation connection method.
• For all Xilinx supported boards, the connection is set to Ethernet.

• For Altera boards that support only a JTAG connection, the connection
is set to JTAG
• For Altera board that support either a JTAG or an Ethernet connection,
the connection is set to Ethernet but you may change it to JTAG.
4 Advanced Options
You can customize the board IP address.
Option Instructions
Board IP address Use this option for setting the board’s IP address
if it is not the default IP address (192.168.0.2).
You may need to change your computer’s IP
address to a different subnet from 192.168.0.x
when you set up the network adapter. You would
also need to change the address if the default
board IP address 192.168.0.2 is in use by another
device.. If so, change the Board IP address
according to the following guidelines:
• The subnet address, typically the first three

bytes of board IP address, must be the same as
those of the host IP address.
• The last byte of the board IP address must be
different from that of the host IP address.
• The board IP address must not conflict with the
IP addresses of other computers.
For example, if the host IP address is
192.168.8.2, then you can use 192.168.8.3, if
available.
Board MAC Under most circumstances, you do not need to
address change the Board MAC address. You will need
to do so if you connect more than one FPGA
development board to a single computer. (You
12-4
Option Instructions
must have a separate NIC for each board.) You

must change the Board MAC address for any
additional boards so that each address is unique.
To change the Board MAC address, click in the
Board MAC address field. Specify an address
that is different from that belonging to any other
device attached to your computer. To obtain
the Board MAC address for a specific FPGA
development board, refer to the label affixed to
the board or consult the product documentation.
5 Click Next.
12-5
Step 4: Add HDL Source Files for FIL Block
In the Source Files page:
1 Specify the HDL design to be cosimulated in the FPGA. These are the HDL
design files to be verified on the FPGA board.
Indicate source files by clicking Add. Select files using the file selection
dialog.
12-6
The FIL Wizard attempts to identify the source files; if any of the file types
is not what you wanted, you can change it by selecting from the drop-down
list at File Type. Acceptable file types are:
• VHDL
• Verilog
• Netlist
• Tcl script
• Constraints
• Others
"Others" refers to the following:
– For Altera, any files specified here as Other are added to the FPGA
project, but they have no impact on the generated block. For example,
you can put some comments in a “readme” file and include it in this
file list.
– For Xilinx, any files specified here as Other may be any file accepted
by Xilinx ISE. ISE looks at the file extension to determine how to use
this file. For example, if you add foo.vhd to the list and specify it as
Other, ISE will treat the file as a VHDL file.
2 Specify which file contains the top-level HDL file.
Check the box on the row of the HDL file that contains the top-level HDL
module in the column titled Top-level. The FIL Wizard automatically fills
the Top-level module name field with the name of the selected HDL file.
If the top-level module name and file name do not match, you can manually
change the top-level module name in this dialog box. You must indicate the
top-level module before the FIL Wizard can continue.
3 (Optional) To display the full paths to the source files, check the box titled
Show full paths to source files.
4 Click Next.
12-7
Step 5: Verify DUT I/O Ports for FIL Block
In the DUT I/O Ports page:
1 Review the port listing. The FIL Wizard parses the top-level HDL module
to obtain all the I/O ports and display them in the DUT I/O Ports table.
The parser attempts to automatically determine the possible port types by
checking the port names. The wizard then displays these signals under
Port Type.
Make sure all input/output/reset ports/clocks are mapped as you expected.

If the parser assigned an incorrect port type for any given port, you can
manually change the signal. For synchronous design, specify a Clock,
12-8
Reset, or, if desired, a Clock enable signal. The port types specified in
this table must be the same as in the HDL code. There must be at least
one output port.
If you wish to manually enter port information, select Manually enter

port information to add or remove signals.
Click Regenerate to reload the table with the original port definitions
(from the HDL code).
2 Click Next.
12-9
Step 6: Specify Output Types for FIL Block
In the Output Types page:
1 Specify output data types. The wizard attempt to do this for you; if any
output data type is not what you expected, you can manually change the
type.
2 Click Next.
12-10
Step 7: Specify Build Options for FIL Block
In the Build Options page:
• Specify the folder for the output files. You can use the default option.
Usually the default is a sub-folder named after the top-level module,
located under the current directory.
• Note the Summary displays the locations of the ISE project file and the
FPGA programming file. You may need those two files for advanced
operations on the FIL block mask.
12-11
Step 8: Initiate Build

Click Build to initiate FIL block generation.
1 The FIL Wizard generates a FIL block named after the top-level module
and places it in a new model.
2 After new model generation, the FIL Wizard opens a command window.
• In this window, the FPGA design software performs synthesis, fit, PAR,
timing analysis, and FPGA programming file generation.
• When the process completes, a message in the command window
prompts you to close the window.
When these steps are completed, see “Perform FPGA-in-the-Loop Simulation”

on page 12-27.
FIL System Object Generation

• “Step 1: Set Up FPGA Design Software Tools” on page 12-13
• “Step 2: Start FIL Wizard” on page 12-13
• “Step 3: Set FIL Options for System Object” on page 12-14
• “Step 4: Add HDL Source Files for System Object” on page 12-17
• “Step 5: Verify DUT I/O Ports for System Object” on page 12-19
• “Step 6: Specify Output Types for System Object” on page 12-21
• “Step 7: Specify Build Options for System Object” on page 12-23
• “Step 8: Initiate Build” on page 12-24
12-12
Step 1: Set Up FPGA Design Software Tools
Xilinx ISE
Set up your system environment for accessing Xilinx ISE from MATLAB with
the function hdlsetuptoolpath. This function adds the required folders to
the MATLAB search path using the Xilinx installation folder as its argument.
For example:
hdlsetuptoolpath('ToolName', 'Xilinx ISE', 'ToolPath', 'C:\Xilinx\14.2\ISE_DS\ISE\bin\nt64')
C:\Xilinx\14.2\ISE_DS\ISE\bin\nt64.
Altera
Set up your system environment for accessing from MATLAB with the
function hdlsetuptoolpath. For example:
hdlsetuptoolpath('ToolName', 'Altera Quartus II', 'ToolPath', 'C:\Altera\12
This example assumes that the Altera FPGA design software is installed
at C:\Altera\12.0\quartus\bin64.
Step 2: Start FIL Wizard

Launch the FPGA-in-the-Loop Wizard by invoking the filWizard function:
In the MATLAB command window, type the following:
>> filWizard
To restore a previous session, use this command:
filWizard('./Subsystem_fil/Subsystem_fil.mat')
12-13
Step 3: Set FIL Options for System Object
(This page is for FIL System object. For Simulink block FIL options, see “Step
3: Set FIL Options for FIL Block” on page 12-3.)
In the FIL Options page:
1 FIL Simulation with: Select MATLAB System Object.
2 Board Name: Select an FPGA development board. If you have not yet
downloaded an HDL Verifier FPGA board support package, see “FPGA
Board Support Packages for FIL” on page 16-2. (If you do not see any
boards listed, then you have not yet downloaded a support package). If you
12-14
plan to define a custom board yourself, see “FPGA Board Customization”

on page 17-2.
3 Advanced Options
You can customize the board IP address.
Option Instructions
when you set up the network adapter. You would
also need to change the address if the default
board IP address 192.168.0.2 is in use by another
device.. If so, change the Board IP address

available.
must have a separate NIC for each board.) You
must change the Board MAC address for any
12-15
Option Instructions

4 Click Next.
12-16
Step 4: Add HDL Source Files for System Object
(This page is for FIL System object. For Simulink block HDL source files, see
“Step 4: Add HDL Source Files for FIL Block” on page 12-6.)
In the Source Files page:
1 Specify the HDL design to be cosimulated in the FPGA. These are the HDL
design files to be verified on the FPGA board.
12-17
Indicate source files by clicking Add. Select files using the file selection
dialog.
The FIL Wizard attempts to identify the source files; if any of the file types
is not what you wanted, you can change it by selecting from the drop-down
list at File Type. Acceptable file types are:
• VHDL
• Verilog
• Netlist
• Tcl script
• Constraints
• Others
"Others" refers to the following:
– For Altera, any files specified here as Other are added to the FPGA
project, but they have no impact on the generated System object. For
example, you can put some comments in a “readme” file and include it
in this file list.
– For Xilinx, any files specified here as Other may be any file accepted
by Xilinx ISE. ISE looks at the file extension to determine how to use
this file. For example, if you add foo.vhd to the list and specify it as
Other, ISE will treat the file as a VHDL file.
2 Specify which file contains the top-level HDL file.
Check the box on the row of the HDL file that contains the top-level HDL
module in the column titled Top-level. The FIL Wizard automatically fills
the Top-level module name field with the name of the selected HDL file.
If the top-level module name and file name do not match, you can manually
change the top-level module name in this dialog box. You must indicate the
top-level module before the FIL Wizard can continue.
3 (Optional) To display the full paths to the source files, check the box titled
Show full paths to source files.
4 Click Next.
12-18
Step 5: Verify DUT I/O Ports for System Object
(This page is for FIL System object. For Simulink block verify DUT I/O ports,
see “Step 5: Verify DUT I/O Ports for FIL Block” on page 12-8.)
In the DUT I/O Ports page:
1 Review the port listing. The FIL Wizard parses the top-level HDL module
to obtain all the I/O ports and display them in the DUT I/O Ports table.
The parser attempts to automatically determine the possible port types by
12-19
checking the port names. The wizard then displays these signals under
Port Type.
Make sure all input/output/reset ports/clocks are mapped as you expected.

If the parser assigned an incorrect port type for any given port, you can
manually change the signal. For synchronous design, specify a Clock,
Reset, or, if desired, a Clock enable signal. The port types specified in
this table must be the same as in the HDL code. There must be at least
one output port.
If you wish to manually enter port information, select Manually enter

port information to add or remove signals.
Click Regenerate to reload the table with the original port definitions
(from the HDL code).
2 Click Next.
12-20
Step 6: Specify Output Types for System Object
(This page is for FIL System object. For Simulink block output types, see
“Step 6: Specify Output Types for FIL Block” on page 12-10.)
In the Output Types page:
1 Specify output data types. The wizard attempts to do this for you; if any
output data type is not what you expected, you can manually change the
type.
12-21
Select from:
• Fixedpoint
• Integer
• Logical
The data type can depend on the specified bit width.
You can specify the output type to be Signed, Unsigned, or Fraction

Length.
2 Click Next.
12-22
Step 7: Specify Build Options for System Object
(This page is for FIL System object. For Simulink block build options, see
“Step 7: Specify Build Options for FIL Block” on page 12-11.)
In the Build Options page:
• Specify the folder for the output files. You can use the default option.
Usually the default is a sub-folder named after the top-level module,
located under the current directory.
12-23
• Note the Summary displays the locations of the ISE project file and the
FPGA programming file. You may need those two files for advanced
operations on the FIL System object.
Step 8: Initiate Build

Click Build to initiate FIL System object generation.
1 The FIL Wizard generates the following files:
• In the ./toplevel_fil/ folder, a MATLAB function named

toplevel_programFPGA.m, where toplevel is the name of the HDL top
level. This file contains the code to download the FPGA programming
file to the FPGA.
function toplevel_programFPGA
%Load the bitstream in the FPGA

filProgramFPGA('Xilinx', '/dir/mybitstream.bit', 1);
end
• A MATLAB file named toplevel_fil.m, where toplevel is the name

of the HDL top level. This file contains a class definition derived from
hdlverifier.FILSimulation and initializes the private properties. This
file is located in the current directory.
The following is a sample of a class definition file generated using the
FIL Wizard from a DUT named "fft8".
classdef fft8_fil < hdlverifier.FILSimulation

%fft8_fil is a filWizard generated class used for FPGA-In-the-Loop
% simulation with the 'fft8' DUT.
% fft8_fil connects MATLAB with a FPGA and cosimulate with it by
% writing inputs in the FPGA and reading outputs from the FPGA.
%
% MYFIL = fft8_fil
%
% Step method syntax:
%
% [out1, out2, ...] = step(MYFIL, in1, in2, ...) connect to the FPGA,
% write in1, in2, ... to the FPGA and read out1, out2, ... from
% the FPGA
12-24
%
% fft8_fil methods:
%
% step - See above description for use of this method
% release - Allow property value and input characteristics changes, and
% release connection to FPGA board
% clone - Create fft8_fil object with same property values
% isLocked - Locked status (logical)
% programFPGA - Load the programming file in the FPGA
%
% fft8_fil properties:
%
% DUTName - DUT top level name
% InputSignals - Input paths in the HDL code
% InputBitWidths - Width in bit of the inputs
% OutputSignals - Output paths in the HDL code
% OutputBitWidths - Width in bit of the outputs
% OutputDataTypes - Data type of the outputs
% OutputSigned - Sign of the outputs
% OutputFractionLengths - Fraction lengths of the outputs
% OutputDownsampling - Downsampling factor and phase of the outputs
% OverclockingFactor - Overclocking factor of the hardware
% SourceFrameSize - Frame size of the source (only for HDL source block)
% Connection - Parameters for the connection with the board
% FPGAVendor - Name of the FPGA chip vendor
% FPGABoard - Name of the FPGA board
% FPGAProgrammingFile - Path of the Programming file for the FPGA
% ScanChainPosition - Position of the FPGA in the JTAG scan chain
%
% File Name: fft8_fil.m
% Created: 26-Apr-2012 18:18:06
%
% Generated by FIL Wizard
properties (Nontunable)
DUTName = 'fft8';
end
methods
function obj = fft8_fil
12-25
%THE FOLLOWING PROTECTED PROPERTIES ARE SPECIFIC TO THE HW DUT

%AND MUST NOT BE EDITED (RERUN THE FIL WIZARD TO CHANGE THEM)
obj.InputSignals = char('Xin_re','Xin_im');
obj.InputBitWidths = [10,10];
obj.OutputSignals = char('Xout_re','Xout_im');
obj.OutputBitWidths = [13,13];
obj.Connection = char('UDP','192.168.0.2','00-0A-35-02-21-8A');
obj.FPGAVendor = 'Xilinx';
obj.FPGABoard = 'XUP Atlys Spartan-6 development board';
obj.ScanChainPosition = 1 ;
%THE FOLLOWING PUBLIC PROPERTIES ARE RELATED TO THE SIMULATION

%AND CAN BE EDITED WITHOUT RERUNING THE FIL WIZARD
obj.OutputSigned = [true,true];
obj.OutputDataTypes = char('fixedpoint','fixedpoint');
obj.OutputFractionLengths = [9,9];
obj.OutputDownsampling = [1,0];
obj.OverclockingFactor = 1;
obj.SourceFramieSize = 1;
obj.FPGAProgrammingFile = 'S:\MATLAB\demo\fft8_fil\fft8_fil.bit';
end
end
end
2 The FIL Wizard opens a command window.
• In this window, the FPGA design software performs synthesis, fit, PAR,
and FPGA programming file generation.
• When the process completes, a message in the command window
When these steps are completed, see “Perform FPGA-in-the-Loop Simulation”

on page 12-27.
12-26
Perform FPGA-in-the-Loop Simulation

In this section...
“FIL Block Setup and Simulation” on page 12-27
“FIL System Object Setup and Simulation” on page 12-30
FIL Block Setup and Simulation

• “Insert FIL Block Into Model” on page 12-27
• “Adjust FIL Block Settings” on page 12-27
• “Load Programming File onto FPGA” on page 12-27
• “Run Simulation” on page 12-30
Insert FIL Block Into Model

In your model, replace the DUT subsystem with the FIL block generated in
the new model. Save the model under a different name. You can then use the
original model as a reference model.
Adjust FIL Block Settings

If you generated your FIL block from the HDL workflow advisor, it is not
likely that you will need to adjust any settings on the FIL block. If you
generated your FIL block using the FIL Wizard, you may wish to make some
settings adjustments. See the FIL Simulation reference page for instructions
on adjusting the FIL block settings.
Load Programming File onto FPGA
Altera Board with Linux

If you are using the Altera board and a Linux distribution supported by Altera,
you should first read the “USB-Blaster Download Cable User Guide” provided
on the Altera web site: http://www.altera.com/literature/ug/ug_usb_blstr.pdf.
Specifically, to program the bit file you must be a superuser. The user guide
provides instructions for making a one-time modification to a rules file to give
you that permission.
12-27
Perform the following steps to program the FPGA:
1 Switch FPGA development board power on.
2 Double-click the FIL block in your Simulink model to open the block mask.
3 On the Main tab, click Load to download the programming file to the
FPGA.
The load process may take from a few minutes to several minutes or longer,
depending on how large the subsystem is. Sometimes, the process can take
an hour and a half or longer for large subsystems.
4 If your board is connected to the host computer through the JTAG cable,
a message window appears. It indicate that the FPGA programming file
has loaded as expected. Click OK.
If you are using an Ethernet connection, you can test if the FPGA board
is connected to your host computer through the ping test. Launch a
command-line window, and enter the following command:
> ping 192.168.0.2
If you changed the board IP address when you set up the network adapter,
replace 192.168.0.2 with your board IP address. If the Gigabit Ethernet
connection has been set up, you should see the ping reply from the FPGA
development board.
12-28
Altera Board Instructions for Linux
On Linux hosts, to program the bit file onto Altera boards, you would normally
need to be a superuser. This can impose testing restriction on these boards.
However, there is a way to avoid being a superuser to program the bit file.
The suggested solution for Altera bitstream programming under Debian 5 is

to fix the device permission issue by creating or modifying a rules file (this is
a one time file modification that requires SUPERUSER privileges):
• Option 1: Create a rules file (e.g., 92-altera.rules) under /etc/udev/rules.d/

with the following contents:
# Altera USB-Blaster
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001", GROUP="users"
12-29
• Option 2: Add the following lines to any of the rule files already existing
under /etc/udev/rules.d/
# Altera USB-Blaster
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001", GROUP="users"
Run Simulation
In Simulink, click Simulation > Run or the Run Simulation button in your
Simulink model window. The results of the FIL simulation should match
those of the Simulink reference model or of the original HDL code.
Note Regarding initialization: Simulink starts from time 0 every time, which
means the RAM in Simulink is initialized to zero. However, this is not true in
hardware. If you have RAM in your design, the first simulation will match
Simulink, but any subsequent runs may not match.
The workaround is to reload the FPGA bitstream before re-running the

simulation. To do this, click Load on the FIL block mask.
FIL System Object Setup and Simulation

• “Generate System Object” on page 12-30
• “Adjust System Object Parameters” on page 12-31
• “Load Programming Files onto FPGA” on page 12-31
• “Run Simulation” on page 12-31
Generate System Object

Create a custom FILSimulation System object from the class definition
file derived using the FIL Wizard. You can instantiate the class using the
following constructor:
MYFIL - toplevel_fil
12-30
This creates an instance of the class and initializes all properties.
Adjust System Object Parameters

You can adjust any property with write permission using one of these methods:
• Change the property with the set method:
MYFIL.set('FPGAProgrammingFile','c:\work\filfiles')
• Set the property directly:
MYFIL.FPGAProgrammingFile='c:\work\filfiles'
• Edit toplevel_fil.m directly, but then you must instantiate the object
again, if you had already done so previously.
Load Programming Files onto FPGA

You can program the FPGA using either the programFPGA function or the
programFPGA method. Reminder: if you have not yet followed “Step 1. Set
Up FPGA Development Board” on page 11-18, do so now before loading the
programming files.
• programFPGA function:
./toplevel_fil/toplevel_programFPGA
• programFPGA method:
MYFIL.programFPGA
Run Simulation
1 Write your MATLAB code to use the System object, if you haven’t already
done so.
2 Run your MATLAB code as you normally would. Make sure you have
followed“Ethernet Connection” on page 11-19 before beginning.
The first call to the step method establishes communication with the FPGA
board.
12-31
See the example FPGA-in-the-Loop simulation using MATLAB System Object

for a full demonstration.
12-32
13
FIL Using HDL Coder HDL

Workflow Advisor
• “FIL with HDL Workflow Advisor In Simulink” on page 13-2

• “FIL with HDL Workflow Advisor In MATLAB” on page 13-9
13 FIL Using HDL Coder HDL Workflow Advisor
FIL with HDL Workflow Advisor In Simulink

In this section...
“Step 1: Start HDL Workflow Advisor” on page 13-2
“Step 2: Set Target” on page 13-2
“Step 3: Prepare Model for HDL Code Generation” on page 13-3
“Step 4: HDL Code Generation” on page 13-4
“Step 5: Set FPGA-in-the-Loop Options” on page 13-4
“Step 6: Build and Run FPGA-in-the-Loop” on page 13-7
Step 1: Start HDL Workflow Advisor

Follow instructions for invoking the HDL Workflow Advisor. See “Open the
HDL Workflow Advisor”.
Note You must have an HDL Coder license to generate HDL code using
the HDL Workflow Advisor.
Step 2: Set Target

At step 1, Set Target, click 1.1 Set Target Device and Synthesis
Workflow and do the following:
1 Select FPGA-in-the-Loop from the dropdown list at Target Workflow.
2 Under Target Platform, select a development board from the dropdown

list. Family, Device, Package, and Speed are filled in by the HDL
Workflow Advisor. If you have not yet downloaded an HDL Verifier FPGA
board support package, select Get more boards. Then return to this step
after you have downloaded an FPGA board support package.
3 For Folder, enter the folder name where the project files are to be placed.
The default is hdl_prj under the current working folder.
13-2
FIL with HDL Workflow Advisor In Simulink®
Step 3: Prepare Model for HDL Code Generation

At step 2, Prepare Model for HDL Code Generation, perform steps
2.1–2.4 as described in “Prepare Model For HDL Code Generation Overview”.
In addition, perform step 2.5 Check FPGA-in-the-Loop Compatibility to

verify that the model is compatible with FIL.
13-3
Step 4: HDL Code Generation

At step 3, HDL Code Generation, perform steps 3.1 and 3.2 as described in
“HDL Code Generation Overview”.
Step 5: Set FPGA-in-the-Loop Options

At step 4.1, Set FPGA-in-the-Loop Options, change these options if
required:
• FPGA-in-the-Loop Connection:
- For all Xilinx supported boards, the connection is set to Ethernet.
- For Altera boards that support only a JTAG connection, the connection
is set to JTAG
- For Altera board that support either a JTAG or an Ethernet connection,
• Board Address:
When an Ethernet connection is selected, you can adjust the board IP and
MAC addresses, if necessary.
Address Instructions
when you set up the network adapter. You
would also need to change the address if the
default board IP address 192.168.0.2 is in use by
another device. If so, change the Board IP address

- The last byte of the board IP address must be
13-4
- The board IP address must not conflict with the

available.
must have a separate NIC for each board.)
You must change the Board MAC address for
• Specify additional source files for the HDL design:

Indicate additional source files for the DUT using Add. To (optionally)
display the full paths to the source files, check the box titled Show full
paths to source files. The HDL Workflow Advisor attempts to identify
the source file; if the file type is incorrect, you can fix it by selecting from
the dropdown list at File Type.
13-5
FIL Over Ethernet
13-6
FIL Over JTAG
Step 6: Build and Run FPGA-in-the-Loop

At step 4.2, Build FPGA-in-the-Loop, click Run this task.
During the build process, the following actions occur:
• The HDL Workflow Advisor generates a FIL block named after the top-level
module and places it in a new model. The next figure shows an example of
the new model containing the FIL block.
13-7
• After new model generation, the HDL Workflow Advisor opens a command
window:
- In this window, the FPGA design software performs synthesis, fit, PAR,
- When the process completes, a message in the command window
• The HDL Workflow Advisor builds a testbench model around the generated
FIL block.
13-8
FIL with HDL Workflow Advisor In MATLAB®
FIL with HDL Workflow Advisor In MATLAB

In this section...
“Step 1: Start HDL Workflow Advisor” on page 13-9
“Step 2: Select Target” on page 13-9
“Step 3: Select Workflow” on page 13-9
“Step 4: Select FPGA-in-the-Loop Options” on page 13-9
“Step 5: Build and Run FPGA-in-the-Loop” on page 13-13
Step 1: Start HDL Workflow Advisor

Follow instructions for invoking the HDL Workflow Advisor in MATLAB. See
“Open the HDL Workflow Advisor”.
Note You must have an HDL Coder license to generate HDL code using
Step 2: Select Target

Under Select Code Generation Target, make sure Workflow is set to
Generic ASIC/FPGA.
Step 3: Select Workflow

Under HDL Verification, select Verify with FPGA-in-the-Loop.
Step 4: Select FPGA-in-the-Loop Options

1 Generate FPGA-in-the-Loop test bench: Select this option to generate
a test bench for simulation with FPGA-in-the-Loop.
2 Log outputs for comparison plots: This optional selection lets you log
and plot the outputs of the reference design function and the FPGA.
13-9
3 Board Name: Select one of the FPGA development boards. If you have
not yet downloaded an HDL Verifier FPGA board support package, select
Get more boards. Then return to this step after you have downloaded
an FPGA board support package.
4 Connection:
• For all Xilinx supported boards, the connection is set to Ethernet.

• For Altera boards that support only a JTAG connection, the connection
is set to JTAG
• For Altera board that support either a JTAG or an Ethernet connection,
5 Board IP Address and Board MAC Address:
Adjust the board IP and MAC addresses, if necessary.
Board IP Address Use this option for setting the board’s IP address
when you set up the network adapter. You
would also need to change the address if the
default board IP address 192.168.0.2 is in use by
another device. If so, change the Board IP address

13-10

available.
Address change the Board MAC address. You will need
must have a separate NIC for each board.)
You must change the Board MAC address for
6 Additional files
Enter the names of any additional source files for the DUT. If you have
more than one additional source file, use the ... button to add more.
7 FPGA-in-the-Loop Test Bench Simulation Settings:
If you want the HDL Workflow Advisor to launch the FIL simulation, check
the box for Simulate generated FPGA-in-the-Loop test bench.
13-11
FIL Over Ethernet
13-12
FIL Over JTAG
Step 5: Build and Run FPGA-in-the-Loop

Click Run. If you have not yet run the previous tasks, right-click on Verify
with FPGA-in-the-Loop and select Run to Selected Task.
13-13
Note If you simulate the generated model a second time without

re-generating and downloading the bitstream, read this note regarding
initialization: Simulink starts from time 0 every time, which means the RAM
in Simulink is initialized to zero. However, this is not true in hardware. If
you have RAM in your design, the first simulation will match Simulink, but
any subsequent runs may not match.
The workaround is to reload the FPGA bitstream before re-running the

simulation. To do this, follow the steps in the Workflow Advisor to generate
and download a new FPGA bitstream.
13-14
14
Troubleshooting
FPGA-in-the-Loop
14 Troubleshooting FPGA-in-the-Loop
Troubleshooting FIL
If you get a message or error at any time during the FIL process (from
generating the FIL block to running the simulation), consult one of the
following tables for a possible reason and solution.
Message or Reason Fix

Error
Design does The design does not meet Change some part of your design or use a different
not meet timing goals and the development board.
timing goals software was unable to
(this message create the programming
is generated file.
from the
FPGA design
Failed to load The default libusb Consult Xilinx user documentation for Linux
software)
bitstream shipped with the Debian distribution compatibility of ISE tools.
client is not compatible
with iMPACT™.
RAM in design Simulink starts from The workaround is to reload the FPGA before
does not time 0 every time, which re-running the simulation.
match up means the RAM in
to Simulink Simulink is initialized to
RAM zero. However, this is not
after first true in hardware. If you
simulation have RAM in your design,
run the first simulation will
match Simulink, but any
subsequent runs may not
match.
14-2
Troubleshooting FIL

Error
Did not The connectivity between Check the cables and power so that connectivity
receive data the host and FPGA can be re-established.
from attached development board was
You can avoid the IP address / MAC address refresh
hardware lost during the simulation.
issue by setting a static entry in the ARP cache (the
(Ethernet This error could be caused
table that holds the address bindings). You will
connection) by a bad network interface
need to gather the IP address and MAC address by
card (NIC), bad cable, or
examining the Hardware Information section of
loss of power. It also could
the FIL block mask. The following examples will
be caused by an issue
assume the default values of 192.168.0.2 for the
with the operating system
IP address and 00-0A-35-02-21-8A for the MAC
IP stack where the IP
address.
address / MAC address
binding is being refreshed, For Windows: With system administrator
interfering with the privileges, execute the following in a command
transmission of data from shell:
the development board to
the host. cmd> arp s 192.168.0.2 00-0A-35-02-21-8A
To confirm that the operation outcome was as you

expected, examine the table and verify the output
shows a static entry type:
cmd> arp a 192.168.0.2
Interface: 192.168.0.8 --- 0x16

Internet Address Physical Address Type
192.168.0.2 00-0a-35-02-21-8a static
For Linux: As root or via "sudo" privileges, execute

the following in a command shell (note that the
MAC address delimiter is ":" instead of "-"):
sh> sudo /usr/sbin/arp -s 192.168.0.2 00:0A:35:02:21:8A
To confirm the operation outcome was as you

expected, examine the table and verify the output
14-3

Error
shows a static entry type (so noted by the PERM

string):
sh> sudo /usr/sbin/arp -a 192.168.0.2
? (192.168.0.2) at 00:0a:35:02:21:8a [ether] PERM on eth3
Failed to load The Altera Quartus II Put the Altera Quartus II executables on the
shared library executables are not on the system path. If using Linux, make sure that the
sld_hapi.dll system path. Quartus II library is on LD_LIBRARY_PATH
(JTAG before you start MATLAB
connection)
Failed to load Two possible reasons: • Make sure you are using Altera Quartus II
shared library version 13.1 or higher on the host computer.
• The version of Altera
libsld_hapi_dll_loader.so
• Make sure that the Quartus II library is on
(JTAG Quartus II on the
LD_LIBRARY_PATH before you start MATLAB
connection) host computer is not
supported.
• The Altera Quartus II
executables are not on
the system path.
Unable to find JTAG cable is not Use the JTAG download cable to connect the FPGA
the JTAG connected. It is also development board with the computer.
communication possible that the JTAG
cable attached cable is defective.
to the host
computer
(JTAG
connection)
14-4
Troubleshooting FIL

Error
Failed to The SLD hub is missing. Make sure that the FPGA is programmed with the
open SLD It is required for correct programming file, which contains the SDL
hub (JTAG FPGA-in-the-Loop hub.
connection) simulation with the
Altera JTAG cable.
Reset pin not Most likely scenario is Use the FPGA Board Manager to see if there is a
connected to that you changed the reset pin specified for the custom or built-in board.
RESET push Ethernet card but did not If there is a reset pin specified, look at the board
button re-program the FPGA, specification manual to see which push button it
(Alternate although other reasons is connected to.
message: may be also possible.
"Did not
get version"
displayed in
the cosim
block)
14-5
14-6
15
FIL Examples
• “Verify HDL Implementation of PID Controller Using FPGA-in-the-Loop”

on page 15-2
• “Verify Digital Up-Converter Using FPGA-in-the-Loop” on page 15-12
15 FIL Examples
Verify HDL Implementation of PID Controller Using

FPGA-in-the-Loop
This example shows you how to set up an FPGA-in-the-Loop (FIL)
application using HDL Verifier™. The application uses Simulink® and
an FPGA development board to verify the HDL implementation of a
proportional-integral-derivative (PID) controller. In this example, Simulink
generates the desired position of a motor and simulates the motor controlled
by this PID controller.
Requirements and Prerequisites
Products required for this example:
• MATLAB
• Simulink
• Fixed-Point Designer
• HDL Verifier
• FPGA design software (Xilinx® ISE® design suite or Altera® Quartus® II
design software)
• One of the supported FPGA development boards and accessories
• For connection using Ethernet: Gigabit Ethernet Adapter installed on host
computer, Gigabit Ethernet crossover cable
• For connection using JTAG: JTAG cable with USB Blaster I or II, USB
Blaster driver
Prerequisites:
MATLAB® and FPGA design software can either be locally installed on your
computer or on a network accessible device. If you use software from the
network you will need a second network adapter installed in your computer
to provide a private network to the FPGA development board. Consult the
hardware and networking guides for your computer to learn how to install
the network adapter.
Step 1: Set Up FPGA Development Board
15-2
Verify HDL Implementation of PID Controller Using FPGA-in-the-Loop
Use the following steps to set up your FPGA development board.
1 Make sure that the power switch remains OFF.
2 Connect the AC power cord to the power plug. Plug the power supply
adapter cable into the FPGA development board.
3 Connect the Ethernet connector on the FPGA development board directly to

the Ethernet adapter on your computer using the crossover Ethernet cable.
4 Use the JTAG download cable to connect the FPGA development board
with the computer.
5 Make sure that all jumpers on the FPGA development board are in the
factory default position.
Step 2: Set Up Host Computer-Board Connection
Skip this step if you are using JTAG connection for simulation. For connection
with Ethernet, you must have a Gigabit Ethernet network adapter on your
computer to run this example.
On Windows® 7, do the following steps:
2 Type View network connections in the search bar. Select View

network connections in the search results.
3 Right click the connection icon to your FPGA development board and select

Protocol Version 4 (TCP/IPv4) and click Properties.
5 Select Use the following IP address:. Set IP address to 192.168.0.1.

to any available IP address on this subnet, such as 192.168.0.100. This is
your host computer address. Set the Subnet mask to 255.255.255.0. Your
TCP/IP properties should now look the same as in the following figure:
15-3
15 FIL Examples
On Windows® Vista, do the following steps:
2 Click Network and Sharing Center, and then click Manage network
connections.

Protocol Version 4 (TCP/IPv4) and click Properties.

your host computer address. Set the Subnet mask to 255.255.255.0.
On Windows XP®, do the following steps:
2 Open Network connections.

Protocol (TCP/IP) and click Properties.

your host computer address. Set the Subnet mask to 255.255.255.0.
On Linux®:
Use the ifconfig command to set up your local address. For example:
15-4
% ifconfig eth1 192.168.0.1
In this example, eth1 is the second Ethernet adapter on the Linux computer.
Check your system to determine which Ethernet adapter is connected to the
FPGA development board. The above command sets the local IP address to
192.168.0.1. If this address is in use by another computer on your network,
change it to any available IP address on this subnet, such as 192.168.0.100.
Step 3: Prepare Example Resources
Set up an examples folder, copy example files, set up access to FPGA design
software, and open model.
1. Create a folder outside the scope of your MATLAB installation folder into
which you can copy the example files. The folder must be writable. This
example assumes that the folder is located at C:\MyTests.
2. Start MATLAB and set the current directory in MATLAB to the folder you
just created. For example:
cd C:\MyTests
3. Enter the following MATLAB command:
copyFILDemoFiles('pid')
This command creates the sub folder .\pid_hdlsrc in

your current folder and copies all the source files under
matlabroot\toolbox\shared\eda\fil\fildemos\fil_pid into it.
matlabroot is the MATLAB root folder on your system. You will now have the
following files in C:\MyTests\pid_hdlsrc:
• D_component.vhd
• I_component.vhd
• Controller.vhd
4. Set Up FPGA design software
15-5
15 FIL Examples
Before using FPGA-in-the-Loop, set up your system environment for accessing

FPGA design software. You can use the function hdlsetuptoolpath to add
ISE or Quartus II to the system path for the current MATLAB session.
For Xilinx FPGA boards, run:
hdlsetuptoolpath('ToolName', 'Xilinx ISE', 'ToolPath', 'C:\Xilinx\13.1\ISE_
This example assumes that the Xilinx ISE executable is

C:\Xilinx\13.1\ISE_DS\ISE\bin\nt64\ise.exe. Substitute with
your actual executable if it is different.
For Altera boards, run:
hdlsetuptoolpath('ToolName','Altera Quartus II','ToolPath','C:\altera\11.0\
This example assumes that the Altera Quartus II executable is

C:\altera\11.0\quartus\bin\quartus.exe. Substitute with your actual
executable if it is different.
5. Open the fil_pid.mdl model.
This model contains a fixed-point PID controller implemented with basic

Simulink blocks. This model also contains a DC motor model controlled by this
PID controller as well as the desired DC motor position as the input stimulus.
Run this model now and observe the desired and actual motor positions in
the scope.
Step 4: Launch FPGA-in-the-Loop (FIL) Wizard
Launch the FPGA-in-the-Loop Wizard by doing the following:
From the Code menu in the fil_pid model window, select Verification
Wizards -> FPGA-in-the-Loop (FIL)....
15-6
Alternatively, you can enter the filWizard command at the MATLAB

command prompt.
filWizard
Step 5: Specify Hardware Options in FIL Wizard
Set the FIL options for the FPGA development board.
1. Specify if the wizard will generate a FIL Simulink block or a FILSimulation

MATLAB System Object. For this example, select Simulink for FIL
simulation with Simulink.
2. For Board Name, select the FPGA development board connected to your
host computer. If your board is not on the list, select one of the following
options:
• "Get more boards..." to download the FPGA board support package(s) (this
option starts the Support Package Installer).
• "Create custom board..." to create the FPGA board definition file for your
particular FPGA board (this option starts the New FPGA Board Manager).
3. Select the connection for simulation. The available connection methods are
Ethernet and JTAG. Not all boards support both connection methods.
4. Ethernet connection only: If you changed your computer’s IP address to

a different subnet from 192.168.0.x when you set up the network adapter,
or if the default board IP address 192.168.0.2 is in use by another device,
expand Advanced Options and change the Board IP address according
to the following guidelines:
• The subnet address, typically the first three bytes of board IP address,
must be the same as those of the host IP address.
• The last byte of the board IP address must be different from that of the
host IP address.
15-7
15 FIL Examples
• The board IP address must not conflict with the IP addresses of other
computers.
For example, if the host IP address is 192.168.8.2, then you can use
192.168.8.3 if it is available. Do not change Board MAC address.
5. Click Next to continue.
Step 6: Specify HDL Files in the FIL Wizard
Specify the HDL design to be implemented in the FPGA.
1. Click Add and browse to the directory you created in Prepare Example
Resources.
2. Select these HDL files:
• Controller.vhd
• D_component.vhd
• I_component.vhd
These are the HDL design files to be verified on the FPGA board. 3. In the
Source Files table, check the checkbox on the row of file Controller.vhd to
specify that this HDL file contains the top-level HDL module.
The FIL Wizard automatically fills the Top-level module name field with
the name of the selected HDL file; in this case, Controller. In this example,
the top-level module name matches the file name so that you do not need to
change it. If the top-level module name and file name did not match, you
would manually correct the top-level module name in this dialog.
Click Next to continue.
15-8
Step 7: Review I/O Ports in FIL Wizard
The FIL Wizard parses the top-level HDL module Controller in Controller.vhd
to obtain all the I/O ports and display them in the DUT I/O Ports table. The
parser attempts to automatically determine the possible port types by looking
at the port names and displays these signals under Port Type.
1. Review the port listing. If the parser assigned an incorrect port type for
any given port, you can manually change the signal. For synchronous design,
specify a Clock, Reset, or Clock enable signal. In this example, the FIL Wizard
automatically fills the table correctly.
Step 8: Set Output Data Types in FIL Wizard
1. For the HDL output control_signal change Data Type to Fixedpoint,

Sign to Signed and Fraction Length to 28. This will makes the generated
FIL block set the output signal of the FPGA design-under-test (DUT) to the
correct data type.
Step 9: Review Build Options in FIL Wizard
1. Specify the folder for the output files. For this example, use the default
option, which is a subfolder named Controller_fil under the current
directory.
The Summary displays the locations of the ISE project file and the FPGA
programming file. You may need those two files for advanced operations.
15-9
15 FIL Examples
2. Click Build to start the build process.
During the build process, the following actions occur:
• A FIL block named Controller is generated in a new model as shown in the

following figure. Do not close this model.
• After new model generation, the FIL Wizard opens a command window
where the FPGA design software performs synthesis, fit, place-and-route,
• When the FPGA design software process is finished, a message in the

command-line window lets you know you can close the window. Close the
window and proceed to the next step.
Step 10: Set Up Model
In the fil_pid model, replace the Controller subsystem with the FIL block
generated in the new model. The modified fil_pid model now appears as
shown in the following illustration:
Step 11: Program FPGA
1. Switch FPGA development board power ON.
2. Double-click the FIL block in the fil_pid model to open the block mask.
3. In the opened block mask, click Load.
15-10
If your board is connected to the host computer through the JTAG cable
properly, a message window displays to indicate that the FPGA programming
file is loaded successfully. Click OK to dismiss this dialog.
4. Ethernet connection only: You can test if the FPGA board is connected to
your host computer properly through the ping test. Launch a command-line
window and enter the following command:
C:\MyTests> ping 192.168.0.2
If you changed the board IP address when you set up the network adapter,
replace 192.168.0.2 with your board IP address. If the Gigabit Ethernet
connection has been set up properly, you should see the ping reply from the
FPGA development board.
Step 12: Review Parameters of FIL Block
1. In the FIL block mask, click the Signal Attributes tab.
2. Verify that the Data Type of the HDL signal control_signal is

fixdt(1,32,28). If it is not, change it.
3. Click OK to close the block mask.
Step 13: Run FIL
1. Start simulation of the fil_pid model.
2. When the simulation is done, view the waveform of the desired and actual
positions of the motor in the scope. Note that the results of FIL simulation
should match those of the Simulink reference model that you simulated in
Prepare Example Resources.
15-11
15 FIL Examples
Verify Digital Up-Converter Using FPGA-in-the-Loop

This example shows you how to verify a digital up-converter design generated
with Filter Design HDL Coder™ using FPGA-in-the-Loop simulation.
Requirements
Products required for this example:
• MATLAB
• Simulink
• HDL Verifier
• Signal Processing Toolbox
• DSP System Toolbox
• Filter Design HDL Coder (optional)
• FPGA design software (Xilinx® ISE® design suite or Altera® Quartus® II
design software)
• One of the supported FPGA development boards and accessories (the
ML403 board is not supported for this example)
• For connection using Ethernet: Gigabit Ethernet Adapter installed on host
computer, Gigabit Ethernet crossover cable
• For connection using JTAG: JTAG cable with USB Blaster I or II, USB
Blaster driver
Create Cascade Filter for DUC
A digital up-converter (DUC) is a digital circuit that converts a digital

baseband signal to a passband signal. A DUC is composed of three filtering
stages; each stage filters the input signal with a lowpass interpolating filter,
followed by a sample rate change. In this example, the DUC is a cascade of
two FIR interpolation filters and a CIC interpolation filter, as described in the
example HDL Digital Up-Converter (DUC).
1. Create the two FIR and CIC filters.
15-12
pfir = [0.0007 0.0021 -0.0002 -0.0025 -0.0027 0.0013 0.0049

-0.0034 -0.0074 -0.0031 0.0060 0.0099 0.0029 -0.0089
-0.0032 0.0124 0.0177 0.0040 -0.0182 -0.0255 -0.0047
0.0390 0.0049 -0.0509 -0.0699 -0.0046 0.1349 0.2776
0.2776 0.1349 -0.0046 -0.0699 -0.0509 0.0049 0.0390
-0.0047 -0.0255 -0.0182 0.0040 0.0177 0.0124 -0.0032
-0.0089 0.0029 0.0099 0.0060 -0.0031 -0.0074 -0.0034
0.0049 0.0013 -0.0027 -0.0025 -0.0002 0.0021 0.0007
hpfir = mfilt.firinterp(2, pfir);

set(hpfir, ...
'arithmetic', 'fixed', ...
'filterinternals', 'specifyprecision', ...
'roundmode', 'nearest', ...
'inputwordlength', 16, ...
'inputfraclength', 15, ...
'coeffwordlength', 16, ...
'outputwordlength', 16, ...
'outputfraclength', 15, ...
'accumwordlength', 16, ...
'accumfraclength', 15);
cfir = [-0.0007 -0.0009 0.0039 0.0120 0.0063 -0.0267 -0.0592

0.1147 0.2895 0.3701 0.2895 0.1147 -0.0237 -0.0592
0.0063 0.0120 0.0039 -0.0009 -0.0007];
hcfir = mfilt.firinterp(2, cfir);

set(hcfir, ...
'arithmetic', 'fixed', ...
'filterinternals', 'specifyprecision', ...
'roundmode', 'nearest', ...
'inputwordlength', 16, ...
'inputfraclength', 15, ...
'coeffwordlength', 16, ...
'outputwordlength', 16, ...
'outputfraclength', 15, ...
'accumwordlength', 16, ...
'accumfraclength', 15);
hcic = mfilt.cicinterp(32, 1, 5, 16, 20);
15-13
15 FIL Examples
hcic.inputfraclength = 15;
2. Create a cascade filter using these filters.
hduc = cascade(hpfir, hcfir, hcic);
The frequency response of the cascade filter is shown in the following figure.
fvtool(hduc);
Generate HDL Code
When the cascade filter is ready, generate HDL code for the DUC using
the Filter Design HDL Coder function generatehdl, with the property
’AddPipelineRegisters’ set to ’on’.
>> generatehdl(hduc, 'Name', 'hdlduc', 'AddPipelineRegisters', 'on');
This option inserts pipeline registers between filter stages, and allows the
generated filter to be synthesized at a higher clock frequency.
If you do not have Filter Design HDL Coder, you can copy pre-generated HDL
files to the current directory using this command:
>> copyFILDemoFiles('duc');
Set Up FPGA Design Software
Before using FPGA-in-the-Loop, make sure your system environment is set

up properly for accessing FPGA design software. You can use the function
hdlsetuptoolpath to add ISE or Quartus II to the system path for the
current MATLAB session.
For Xilinx FPGA boards, run
hdlsetuptoolpath('ToolName', 'Xilinx ISE', 'ToolPath', 'C:\Xilinx\13.1\ISE_
15-14
This example assumes that the Xilinx ISE executable is

C:\Xilinx\13.1\ISE_DS\ISE\bin\nt64\ise.exe. Substitute with
your actual executable if it is different.
For Altera boards, run
hdlsetuptoolpath('ToolName','Altera Quartus II','ToolPath','C:\altera\11.0\
This example assumes that the Altera Quartus II executable is

C:\altera\11.0\quartus\bin\quartus.exe. Substitute with your actual
executable if it is different.
Configure and Build FPGA-in-the-Loop
The FIL Wizard guides you in configuring settings necessary for building
FPGA-in-the-Loop. Launch the wizard with the following command:
>> filWizard
1. In Hardware Options, select the FPGA development board connected to

your host computer. If necessary, you can also customize the Board IP and
MAC Address under Advanced Options. Click *Next" to continue.
2. In Source Files, add the following generated HDL files for the DUC to
the source file table using Browse.
hdlduc.vhd
hdlduc_stage1.vhd
hdlduc_stage2.vhd
hdlduc_stage3.vhd
Select the top-level checkbox next to hdlduc.vhd. Click *Next" to continue.
3. In DUT I/O Ports, the input and output port information, such as port
name, direction, width and port type are automatically generated from the
HDL file. Port types, such as Clock and Data, are generated based on port
names; you may change the selection as necessary. For this example, the
generated port types are correct, and you can click Next.
4. In Build Options, specify the folder for FIL output files. You can use the
default value for this example. Click Build. Clicking Build causes the FIL
15-15
15 FIL Examples
Wizard to generate all the necessary files for FPGA-in-the-Loop simulation

and perform the following actions:
• Generates a FIL block in a new Simulink® model

• Opens a command-line window to compile the FPGA project and generate
the FPGA programming file
The FPGA project compilation process takes several minutes. When the
process is finished, you are prompted to close the command-line window.
Close this window now.
Configure FIL Block
To prepare for FPGA-in-the-Loop simulation, follow the steps below to

configure the FIL block.
1. Open the test bench model fil_duc_model and copy the generated FIL
block into the model.
2. Double-click the FIL block to open the block mask. Click Load to program
the FPGA with the generated programming file.
3. Under Runtime Options, change Overclocking factor to 128. This

specifies that an input value is sampled 128 times by the FPGA clock before
the input changes value.
4. On the FIL block mask, click on the Signal Attributes tab. Change the data
type for filter_out to fixdt(1,20,-1) to match the data type of the behavioral
filter block.
5. Click OK to close the block mask.
Verify Generated Filter
In this example, the generated filter running on FPGA is compared to a

behavioral filter block. Delays are added to the output of the behavioral filter
to match the HDL latency of the generated filter.
15-16
Run simulation. Observe the output waveforms from the behavioral filter
block, the FIL block, and the error margin. Because the behavioral filter
block does not have pipeline registers, there are small differences between
the behavioral filter block output and the FIL block output. These errors
are within the error margin.
This concludes the example.
15-17
15 FIL Examples
15-18
16
HDL Verifier FPGA Board

Support Packages
• “FPGA Board Support Packages for FIL” on page 16-2

• “Support Package for BEEcube miniBEE Hardware Platform” on page 16-3
• “Open Examples for This Support Package” on page 16-6
• “Install This Support Package on Other Computers” on page 16-10
• “Support Packages and Support Package Installer” on page 16-12
16 HDL Verifier FPGA Board Support Packages
FPGA Board Support Packages for FIL

The FPGA board support packages contain the definition files for all the
supported boards for FPGA-in-the-Loop (FIL) simulation. You may download
any or all of the FPGA board support packages. Before you can use FIL, you
must either download at least one of the FPGA board support packages or
customize your own board definition file using the FPGA Board Manager.
You download FPGA board support packages using the Support Package
Installer. See “Support Packages and Support Package Installer” on page
16-12.
After you have downloaded an FPGA board support package, you can use
“FPGA-in-the-Loop (FIL) Simulation” on page 10-2.
16-2
Support Package for BEEcube® miniBEE® Hardware Platform
Support Package for BEEcube miniBEE Hardware Platform

In this section...
“BEEcube miniBEE Hardware Platform for FIL” on page 16-3
“miniBEE Hardware Platform and the FIL Wizard” on page 16-3
“miniBEE and the FIL Block Mask” on page 16-4
BEEcube miniBEE Hardware Platform for FIL

When you use the HDL Verifier FPGA board support package for BEEcube
miniBEE hardware platform for FIL verification, FIL handles some
processing differently than for other boards:
• The FIL workflow generates a Xilinx binary FPGA programming file (BIN)
for the miniBEE hardware.
• FIL uses the SelectMAP executable from BEEcube for programming the
FPGA.
• The generated FIL HDL code for miniBEE employs the BEEcube PCI
Express IP for connection.
• The FIL host uses the BEEcube PCI Express driver to communicate with
the FPGA board.
The FPGA board support package for BEEcube miniBEE hardware platform
is also supported for FIL with HDL Coder, for the following workflows:
• Simulink–to–HDL
• MATLAB–to–HDL
miniBEE Hardware Platform and the FIL Wizard

With the FIL wizard, you can create either a MATLAB System object or
a Simulink block. On the FIL Options pane, the FPGA-in-the-Loop
communication option is labeled PCI Express when you select miniBEE
LX240T.
16-3
miniBEE and the FIL Block Mask

In the block mask, the connection setting shows PCI Express as the FIL
connection for the BEEcube miniBEE board.
16-4
Support Package for BEEcube® miniBEE® Hardware Platform
16-5
Open Examples for This Support Package

In this section...
“Using the Help Browser” on page 16-6
“Using Support Package Installer” on page 16-8
Using the Help Browser

You can open support package examples from the Help browser:
1 After installing the support package, click View product documentation

(F1).
2 In Help, click Supplemental Software.
16-6
3 In Supplemental Software, double-click Examples.
16-7
4 Select the examples for your support package.
Note For other types of examples, open the Help browser and search for your
product name followed by “examples”.
Using Support Package Installer

Support Package Installer (supportPackageInstaller) automatically
displays the support package examples when you complete the process of
installing and setting up a support package.
On the last screen in Support Package Installer, leave Show support

package examples enabled and click Finish.
16-8
16-9
Install This Support Package on Other Computers

You can download a support package to one computer, and then install it on
other computers. Using this approach, you can:
• Save time when installing support packages on multiple computers.

• Install support packages on computers that are not connected to the
Internet.
Before starting, select a computer to use for downloading. This computer must
have the same base product license and platform as the computers upon which
you are installing the support package. For example, suppose you want to
install a Simulink support package on a group of computers that are running
64-bit Windows. To do so, you must first download the support package using
a computer that has a Simulink license and is running 64-bit Windows.
Download the support package to one computer:
1 In the MATLAB Command Window, enter supportPackageInstaller.
2 In Support Package Installer, on the Select an action screen, choose

Download from Internet. Click Next.
3 On the following screen, select the support package to download.
Verify the path of the Download folder. For example,

C:\MATLAB\SupportPackages\R2013b\downloads.
4 Follow the instructions provided by Support Package Installer to complete

the download process.
This action creates a subfolder within the Download folder that contains
the files required for each support package.
5 Make the new folder available to for installation on other computers. For
example, you can share the folder on the network, or copy the folder to
portable media, such as a USB flash drive.
16-10
Install This Support Package on Other Computers
Note Some support packages require you to install third-party software.

If so, also make the third-party software available for installation on the
other computers.
Install the support package on the other computers:
1 Run Support Package Installer on the other computer or computers.
2 On the Install or update support package screen, select the Folder

option.
3 Click Browse to specify the location of the support package folder on the
network or portable media.
4 Follow the instructions provided by Support Package Installer to complete

the installation process.
16-11
Support Packages and Support Package Installer
What Is a Support Package?

A support package is an add-on that enables you to use a MathWorks® product
with specific third-party hardware and software.
Support packages can include:
• Simulink block libraries

• MATLAB functions, classes, and methods
• Firmware updates for the third-party hardware
• Automatic installation of third-party software
• Examples and tutorials
A support package file has a *.zip extension. This type of file contains
MATLAB files, MEX files, and other supporting files required to install the
support package. Use Support Package Installer to install these support
package files.
A support package installation file has a *.mlpkginstall extension. You

can double click this type of file to start Support Package Installer, which
preselects a specific support package for installation. You can download these
files from MATLAB Central File Exchange and use them to share support
packages with others.
What Is Support Package Installer?

Support Package Installer is a wizard that guides you through the process of
installing support packages.
You can use Support Package Installer to:
• Display a list of available, installable, installed, or updatable support

packages
• Install, update, download, or uninstall a support package.
• Update the firmware on specific third-party hardware.
16-12
Support Packages and Support Package Installer
• Provide your MathWorks software with information about required

third-party software.
If third-party software is included, Support Package Installer displays a list of

the software and licenses for you to review before continuing.
You can start Support Package Installer in one of the following ways:
• On the MATLAB toolstrip, click Add-Ons > Get Hardware Support

Packages.
• In the MATLAB Command Window, enter supportPackageInstaller.

• Double-click a support package installation file (*.mlpkginstall).
16-13
16-14
17
• “FPGA Board Customization” on page 17-2

• “Create Custom FPGA Board Definition” on page 17-8
• “Create Xilinx KC705 Evaluation Board Definition File” on page 17-9
• “FPGA Board Manager” on page 17-23
• “New FPGA Board Wizard” on page 17-27
• “FPGA Board Editor” on page 17-39
17 FPGA Board Customization

In this section...
“Feature Description” on page 17-2
“Custom Board Management” on page 17-2
“FPGA Board Requirements” on page 17-3
Feature Description
Both HDL Coder and HDL Verifier software include a set of predefined FPGA
boards you can use with the Turnkey or FPGA-in-the-Loop (FIL) workflows
(you can view the lists of these supported boards in the HDL Workflow
Advisor or in the FIL Wizard). With the FPGA Board Manager, you can add
additional boards to use either of these workflows. All you need to add a board
is the relevant information from the board specification documentation.
The FPGA Board Manager is the hub for accessing wizards and dialog
boxes that take you through the steps necessary to create a custom board
configuration. You can also access options to import a custom board, remove a
board, make a copy of a board for further modification, and verify a new board.
Custom Board Management

You manage FPGA custom boards through the following user interfaces:
• “FPGA Board Manager” on page 17-23: portal to adding, importing,

deleting, and otherwise managing board definition files.
• “New FPGA Board Wizard” on page 17-27: This wizard guides you through
creating a custom board definition file with information you obtain from
the board specification documentation.
• “FPGA Board Editor” on page 17-39: user interface for viewing or editing
board information.
To begin, review the “FPGA Board Requirements” on page 17-3 and then
follow the steps described in “Create Custom FPGA Board Definition” on
page 17-8.
17-2
FPGA Board Requirements

• “FPGA Device” on page 17-3
• “FPGA Design Software” on page 17-3
• “General Hardware Requirements” on page 17-4
• “Ethernet Connection Requirements for FPGA-in-the-Loop” on page 17-4
• “JTAG Connection Requirements for FPGA-in-the-Loop” on page 17-6
FPGA Device
Select one of the following links to view a current list of supported FPGA
device families:
• For use with FPGA-in-the-Loop (FIL), see “Supported FPGA Device

Families for Board Customization” in the HDL Verifier documentation.
• For use with with FPGA Turnkey, see “Supported FPGA Device Families
for Board Customization” in the HDL Coder documentation.
FPGA Design Software

Altera Quartus II or Xilinx ISE is required. See product documentation for
HDL Coder or HDL Verifier for the specific software versions required.
The following MathWorks tools are required to use FIL or FPGA Turnkey.
Workflow Required Tools

FPGA-in-the-Loop • HDL Verifier
• Fixed-Point Designer™
FPGA Turnkey • HDL Coder
• Simulink
17-3
General Hardware Requirements

To use a FPGA development board, make sure that you have the following
FPGA resources:
• Clock: An external clock connected to the FPGA is required. The clock can
be differential or single-ended. The accepted clock frequency is from 5
MHz to 300 MHz. When used with FIL, there are additional requirements
to the clock frequency (see “Ethernet Connection Requirements for
FPGA-in-the-Loop” on page 17-4).
• Reset: An external reset signal connected to the FPGA is optional. When
supplied, this signal functions as the global reset to the FPGA design.
• JTAG download cable: A JTAG download cable that connects host PC
and FPGA board is required for the FPGA programming. The FPGA must
be programmable using Xilinx iMPACT or Altera Quartus II.
Ethernet Connection Requirements for FPGA-in-the-Loop
• “Supported Ethernet PHY Device” on page 17-4

• “Ethernet PHY Interface” on page 17-5
• “Special Timing considerations for RGMII” on page 17-5
• “Special Clock Frequency Requirement for GMII/RGMII/SGMII Interface”
on page 17-6
Supported Ethernet PHY Device. On the FPGA board, the Ethernet MAC
is implemented in FPGA. An Ethernet PHY chip is required to be on the
FPGA board to connect the physical medium to the Media ACcess (MAC)
layer in the FPGA.
The FIL feature is tested with the following Ethernet PHY chips and may not
work with other Ethernet PHY devices.
17-4
Ethernet PHY Chip Test

Marvell® Alaska 88E1111 For GMII, RGMII, SGMII, and 100
Base-T MII interfaces
National Semiconductor DP83848C For 100 Base-T MII interface only
Ethernet PHY Interface. The Ethernet PHY chip must be connected to the
FPGA using one of the following interfaces:
Interface Note
Gigabit Media Independent Interface Only 1000 Mbits/s speed is
(GMII) supported using this interface.
Reduced Gigabit Media Independent Only 1000 Mbits/s speed is
Interface (RGMII) supported using this interface.
Serial Gigabit Media Independent Only 1000 Mbits/s speed is
Interface (SGMII) supported using this interface.
Media Independent Interface (MII) Only 100 Mbits/s speed is supported
using this interface.
Note For GMII, the TXCLK (clock signal for 10/100 Mbits signal) signal is
not required because only 1000 Mbits/s speed is supported.
In addition to the standard GMII/RGMII/SGMII/MII interface signals,

FPGA-in-the-Loop also requires an Ethernet PHY chip reset signal
(ETH_RESET_n). This active-low reset signal performs the PHY hardware
reset by FPGA. It is active-low.
Special Timing considerations for RGMII. When the RGMII interface is

used, the MAC on the FPGA assumes that the data are aligned with the
edges of reference clock as specified in the original RGMII v1.3 standard. In
this case, PC board designs provide additional trace delay for clock signals
(RGMII v1.3).
The RGMII v2.0 standard allows the transmitter to integrate this delay so
that PC board delay is not required. Marvell Alaska 88E1111 has internal
17-5
registers to add internal delays to RX and TX clocks. The internal delays are
not added by default. This means you use the MDIO module to configure
Marvell 88E1111 to add internal delays. (See “FIL I/O” on page 17-32 for the
usage of the MDIO module.)
Special Clock Frequency Requirement for GMII/RGMII/SGMII

Interface. When GMII/RGMII/SGMII interfaces are used, an exact 125MHz
clock is required by FPGA to drive the 1000 Mbits/s communication. This
clock is derived from the user supplied external clock using the clock module
or PLL.
Not all external clock frequencies can derive an exact 125 MHz clock
frequency. The acceptable clock frequencies vary depending on the FPGA
device family. The recommended clock frequencies are 50, 100, 125, and 200
MHz.
JTAG Connection Requirements for FPGA-in-the-Loop
• “Hardware” on page 17-6

• “Software” on page 17-6
Hardware.
• Altera FPGA board

• USB Blaster I or USB Blaster II download cable
Software.
• Altera Quartus II
- Windows
Requires Quartus II version 13.0 or higher, Quartus II executable
directory must be on system path
- Linux
Requires Quartus II version 13.1 or higher, Quartus II library directory
must be on LD_LIBRARY_PATH before starting MATLAB, only 64-bit
Quartus are supported
17-6
• Installation of USB Blaster I or II cable driver
17-7
Create Custom FPGA Board Definition

1 Be ready with the following:
a Board specification document. Any format you are comfortable with is

fine, but if you have it in an electronic version, you can search for the
information as it is required.
b If you plan to validate (test) your board definition file, set up FPGA
design software tools:
For validation, you must have Xilinx or Altera on your path. Use the
function hdlsetuptoolpath to configure the tool for use with MATLAB.
For example:
>> hdlsetuptoolpath('ToolName', 'Xilinx ISE', 'ToolPath', 'C:\Xilinx\13.4\ISE_DS\ISE\bin\nt64\ise.exe'
2 Open the FPGA Board Manager by typing fpgaBoardManager in the

MATLAB command window. Alternatively, if you are using the HDL
Workflow Advisor, you can click Launch Board Manager at Step 1.1.
3 Open the New FPGA Board Wizard by clicking Create New Board. For a
description of all the tasks you can perform with the FPGA Board Manager,
see “FPGA Board Manager” on page 17-23.
4 The wizard guides you through entering all board information. At

each page, fill in the required fields. For assistance in entering board
information, see “New FPGA Board Wizard” on page 17-27.
5 Save the board definition file. This is the last step and is automatically
instigated when you click Finish in the New FPGA Board Wizard. See
“Save Board Definition File” on page 17-18.
Your custom board definition now appears in the list of available FPGA
Boards in the FPGA Board Manager. If you are using HDL Workfow Advisor,
it also shows in the Target platform list.
Follow the example “Create Xilinx KC705 Evaluation Board Definition File”
on page 17-9 for a demonstration of adding a custom FPGA board with the
New FPGA Board Manager.
17-8
Create Xilinx KC705 Evaluation Board Definition File

In this section...
“Overview” on page 17-9
“What You Need to Know Before Starting” on page 17-9
“Start New FPGA Board Wizard” on page 17-10
“Provide Basic Board Information” on page 17-11
“Specify FPGA Interface Information” on page 17-13
“Enter FPGA Pin Numbers” on page 17-14
“Run Optional Validation Tests” on page 17-16
“Save Board Definition File” on page 17-18
“Use New FPGA Board” on page 17-19
Overview
For FPGA-in-the-Loop, you can use your own qualified FPGA board even if
is not in the pre-registered FPGA board list supplied by MathWorks. Using
the New FPGA Board Wizard, you can create a board definition file that
describes your custom FPGA board.
In this example, you can follow the workflow of creating a board definition file
for the Xilinx KC705 evaluation board to use with FIL simulation.
What You Need to Know Before Starting

• You need to know the following types of information about the board:
- FPGA interface to the Ethernet PHY chip
- Clock pins names and numbers
- Reset pins names and numbers
In this example, the above information is supplied to you in this section. In
general, you can find this type of information in the board specification file.
17-9
This example uses the KC705 Evaluation Board for the Kintex-7 FPGA
User Guide, published by Xilinx.
• For validation, you must have Xilinx or Altera on your path. Use the
function hdlsetuptoolpath to configure the tool for use with MATLAB.
For example:
>> hdlsetuptoolpath('ToolName', 'Xilinx ISE', 'ToolPath', 'C:\Xilinx\13.4\ISE_DS\ISE\bin\nt64\ise.exe');
• If you want to verify programming the FPGA board after you add its
definition file, you will need to have the custom board attached to your
computer. However, having the board connected is not necessary for
creating the board definition file.
Start New FPGA Board Wizard

1 Start the FPGA Board Manager by entering the following command at
the MATLAB prompt:
>>fpgaBoardManager
2 Click Create Custom Board to open the New FPGA Board Wizard.
17-10
Provide Basic Board Information

1 In the Basic Information pane, enter the following information:
• Board Name: Enter "My Xilinx KC705 Board"
17-11
• Vendor: Select Xilinx

• Family: Select Kintex7
• Device: Select xc7k325t
• Package: Select ffg900
• Speed: Select -2
• JTAG Chain Position: Select 1
The wizard should now look like the following image.
17-12
The information you just entered can be found in the KC705 Evaluation
Board for the Kintex-7 FPGA User Guide.
2 Click Next.
Specify FPGA Interface Information

1 In the Interfaces pane, perform the following tasks.
a Select FIL Interface. This option is required for using your board with
FPGA-in-the-Loop.
b Select GMII in the PHY Interface Type. This option indicates that
the onboard FPGA is connected to the Ethernet PHY chip via a GMII
interface.
c Leave the User-defined I/O option in the FPGA Turnkey Interface
section unchecked. FPGA Turnkey workflow is not the focus of this
example.
d Clock Frequency: Enter 200. Note that this Xilinx KC705 board has
multiple clock sources. This 200 MHz clock is one of the recommended
clock frequencies for use with Ethernet interface (50, 100, 125, and
200 MHz).
e Clock Type: Select Differential.
f Clock_P Pin Number: Enter AD12.

g Clock_N Pin Number: Enter AD11.
h Resent Pin Number: Enter AB7. This will supply a global reset to
the FPGA.
i Active Level: Select Active-High.
You can obtain all necessary information from the board design
specification.
17-13
2 Click Next.
Enter FPGA Pin Numbers

1 In the FILI/O pane, enter the numbers for each FPGA pin. This information
is required.
Note that pin numbers for RXD and TXD signals are entered from the
least significant digit (LSD) to the most significant digit (MSB), separated
by a comma.
17-14
For signal name... Enter FPGA pin number...

ETH_COL W19
ETH_CRS R30
ETH_GTXCLK K30
ETH_MDC R23
ETH_MDIO J21
ETH_RESET_n L20
ETH_RXCLK U27
ETH_RXD U30,U25,T25,U28,R19,T27,T26,T28
ETH_RXDV R28
ETH_RXER V26
ETH_TXD N27,N25,M29,L28,J26,K26,L30,J28
ETH_TXEN M27
ETH_TXER N29
2 Click Advanced Options to expand the section.
3 Check the Generate MDIO module to override PHY settings option.
This option is selected for the following reasons:

• There are jumpers on the Xilinx KC705 board that configure the
Ethernet PHY device to MII, GMII, RGMII, or SGMII mode. Since this
example uses the GMII interfaces, the FPGA board will not work if the
PHY device are set to the wrong mode. When the Generate MDIO
module to override PHY settings option is selected, the FPGA uses
the Management Data Input/Output (MDIO) bus to override the jumper
settings and configure the PHY chip to the correct GMII mode.
• This option currently only applies to Marvell Alaska PHY device
88E1111 and this KC705 board is using the Marvel device.
4 PHY address (0 – 31): Enter 7.
17-15
5 Click Next.
Run Optional Validation Tests

This step provides a validation test for you to verify if the entered information
is correct by performing FPGA-in-the-Loop cosimulation. You will need Xilinx
ISE 13.4 or higher versions installed on the same computer. This step is
optional and you may skip it if you prefer.
17-16
Note For validation, you must have Xilinx or Altera on your path. Use the
function hdlsetuptoolpath to configure the tool for use with MATLAB. For
example:
>> hdlsetuptoolpath('ToolName', 'Xilinx ISE', 'ToolPath', 'C:\Xilinx\13.4\ISE_DS\ISE\bin\nt64\ise.exe');
To run this test, perform the following actions.
1 Check the Run FPGA-in-the-Loop test option.
2 If you have the board attached, check the Include FPGA board in the
test option. You will need to supply the IP address of the FPGA Board.
This example assumes the Xilinx KC705 board is attached to your host
computer and it has an IP address of 192.168.0.2.
3 Click Run Selected Test(s). The tests will take about 10 minutes to
complete.
17-17
Save Board Definition File

1 Click Finish to exit the New FPGA Board Wizard. A Save As dialog pops
up and asks for the location of the FPGA board definition file. For this
example, save as C:\boardfiles\KC705.xml.
17-18
2 Click Save to save the file and exit.
Use New FPGA Board

1 After you save the board definition file, you are returned to the FPGA
Board Manager. In the FPGA Board List you can now see the new board
you just defined.
17-19
Click OK to close the FPGA Board Manager.
2 You can view the new board in the board list from either the FIL Wizard or
a Start the FIL Wizard from the MATLAB prompt.
>>filWizard
The Xilinx KC705 board appears in the board list and you can select it
for FPGA-in-the-Loop simulation.
17-20
b Start HDL Workflow Advisor.
In step 1.1, select FPGA-in-the-Loop and click Launch Board

Manager.
The Xilinx KC705 board appears in the board list and you can select it
for FPGA-in-the-Loop simulation.
17-21
This concludes the example of adding a custom board definition file.
17-22
FPGA Board Manager
FPGA Board Manager

In this section...
“Introduction” on page 17-23
“Filter” on page 17-25
“Search” on page 17-25
“FIL Enabled/Turnkey Enabled” on page 17-25
“Create Custom Board” on page 17-25
“Add Board From File” on page 17-25
“Get More Boards” on page 17-25
“View/Edit” on page 17-26
“Remove” on page 17-26
“Clone” on page 17-26
“Validate” on page 17-26
Introduction
The FPGA Board Manager is the portal to managing custom FPGA boards.
You can create a new board definition file or edit an existing one. You can
even import a custom board from an existing board definition file.
You start the FPGA Board Manager by one of the following methods:
• By typing fpgaBoardManager in the MATLAB command window

• From the FIL Wizard by clicking Launch Board Manager on the first
page
• From the HDL Workflow Advisor (when using HDL Coder) at Step 1.1
17-23
17-24
FPGA Board Manager
Filter
Choose one of the following views:
• All boards
• Only those that were preinstalled with HDL Verifier or HDL Coder
• Only custom boards
Search
Find a specific board in the list or those boards that fully or partially match
your search string.
FIL Enabled/Turnkey Enabled

These columns indicate whether the specified board is supported for FIL or
Turnkey operations.
Create Custom Board

Start New FPGA Board Wizard. See “New FPGA Board Wizard” on page
17-27. You can find he process for creating a new board definition file in
“Create Custom FPGA Board Definition” on page 17-8.
Add Board From File

Import a board definition file (.xml).
Get More Boards

Download FPGA board support packages for use with FIL
1 Click Get more boards.
2 Follow the prompts in the Support Package Installer to download an FPGA

board support package.
3 When the download is complete, you can see the new boards in the board
list in the FPGA Board Manager.
17-25
View/Edit
View board configurations and modify the information. You may view a
read-only file but not edit it. See “FPGA Board Editor” on page 17-39.
Remove
Remove custom board from the list. This action does not delete the board
definition XML file.
Clone
Makes a copy of an existing custom board for further modification.
Validate
Runs the validation tests for FIL See “Run Optional Validation Tests” on
page 17-16.
17-26
New FPGA Board Wizard

Using the New FPGA Board Wizard, you can enter all the required
information needed to add a board to the FPGA board list. This list applies to
both FIL and Turnkey workflows. Review “FPGA Board Requirements” on
page 17-3 before adding a new FPGA board to make sure it is compatible with
the workflow for which you want to use it.
Several buttons in the New FPGA Board Wizard assist in navigation:
• Back: Go to a previous page to review or edit data already entered.

• Next: Go to next page when all requirements of current page have been
satisfied.
• Help: Open Doc Center, and display this topic.
• Cancel: Exit New FPGA Board Wizard. You have the option to exit with
or without saving the information from your session.
Adding Boards Once for Multiple Users To add new boards globally,
follow these instructions. Note that to access a board added globally, all users
must be using the same MATLAB installation.
1 Create the following folder:
matlabroot/toolbox/shared/eda/board/boardfiles
2 Copy the board description XML file to the boardfiles folder.
3 After copying the XML file, restart MATLAB. The new board appears in
the FPGA board list for either or both the FIL and Turnkey workflows.
All boards under this directory will show-up in the FPGA board list
automatically for users with the same MATLAB installation. You do not need
to use FPGA Board Manager to add these boards again.
The workflow for adding a new FPGA board contains these steps:
17-27
In this section...
“Basic Information” on page 17-29
“Interfaces” on page 17-30
“FIL I/O” on page 17-32
“Turnkey I/O” on page 17-34
“Validation” on page 17-37
“Finish” on page 17-38
17-28
Basic Information
Board Name: Enter a unique board name.
Device Information:
• Vendor: Xilinx or Altera

• Family: Family depends on the specified vendor. See the board
specification file for applicable settings.
• Device: Use the board specification file to select the correct device.
• For Xilinx boards only:
17-29
- Package: Use the board specification file to select the correct package.
- Speed: Use the board specification file to select the correct speed.
- JTAG Chain Position: Value indicates the starting position for JTAG
chain. Consult the board specification file for this information.
Interfaces
• FIL Interface: To use this board with FIL, select this option. Next, select
one of the following PHY Interface types:
- Gigabit Ethernet — GMII
17-30
- Gigabit Ethernet — RGMII

- Gigabit Ethernet — SGMII (the SGMII option appears if you select a
board from the Stratix Vor Stratix IV device families)
- Ethernet — MII
- Altera JTAG (Altera boards only)
Note Not all interfaces are available for all boards. Availability depends
on the board you selected in Basic Information.
• FPGA Turnkey Interface: If you want to use with board with the HDL
Coder FPGA Turnkey workflow, select User-defined I/O.
• FPGA Input Clock. Clock details are required for both workflows. You
can find all necessary information in the board specification file.
- Clock Frequency. Must be between 5 and 300. For an Ethernet
interface, the suggested clock frequencies are 50, 100, 125, and 200 MHz.
- Clock Pin Number . Must be specified. Example: N10.
- Clock Type : Single_Ended or Differential.
• Reset (Optional). If you want to indicate a reset, find the pin number and
active level in the board specification file, and enter that information.
- Reset Pin Number. Leave empty if you do not have one.
- Active Level : Active-Low or Active-High.
17-31
FIL I/O
Note You provide FIL I/O for an Ethernet connection only.
Signal List: You must provide all the FPGA pin numbers for the specified
signals. You can find this information in the board specification file. For
vector signals, list all pin numbers on the same line, separated by commas.
Generate MDIO module to override PHY settings: See the next section
on FPGA Board Management Data Input/Output Bus (MDIO) to determine
when to use this feature. If you do select this option, enter the PHY address.
17-32
What is the Management Data Input/Output Bus (MDIO)?
Management Data Input/Output (MDIO) is a serial bus, defined in the IEEE

802.3 standard, that connects MAC devices and Ethernet PHY devices. The
FPGA MAC uses the MDIO bus to set control registers in the Ethernet PHY
device on the board.
Currently only the Marvell 88E1111 PHY chip is supported by this MDIO
module implementation. Do not select this checkbox if you are not using
Marvell 88E1111.
The generated MDIO module is used to perform the following operations:
• GMII mode: The PHY device can start up using other modes, such as
RGMII/SGMII. The generated MDIO module sets the PHY chip in GMII
mode.
• RGMII mode: The PHY device can start up using other modes, such as
GMII/SGMII. The generated MDIO module sets the PHY device in RGMII
mode. In addition, the module sets the PHY chip to add internal delay
for RX and TX clocks.
• SGMII mode: The PHY device can start up using other modes, such as
RGMII/GMII. The generated MDIO module sets the PHY chip in SGMII
mode.
• MII mode: The generated MDIO module sets the PHY device in GMII
compatible mode. The module also sets the autonegotiation register to
remove the 1000 Base-T capability advertisement. This reset ensures that
the autonegotiation process does not select 1000 Mbits/s speed, which is
not supported in MII mode.
When To Select MDIO: Select the Generate MDIO module to override

PHY settings option when both the following conditions are met:
• The onboard Ethernet PHY device is Marvell 88E1111.

• The PHY device startup settings are not compatible with the FPGA MAC.
The MDIO modules for different PHY modes must override these settings,
as previously described.
17-33
Specifying the PHY Address: The PHY address is a 5-bit integer. The
value is determined by the CONFIG[0] and CONFIG[1] pin on Marvell
88E1111 PHY device. See the board manual for this value.
Turnkey I/O
Note You provide FIL I/O for an Ethernet connection only. You must define
at least one output port for the Turnkey I/O interface.
17-34
Signal List: You must provide all the FPGA pin numbers for the specified
signals. You can find this information in the board specification file. For
vector signals, list all pin numbers on the same line, separated by commas.
The number of pin numbers must match the bit width of the corresponding
signal.
Add New: You are prompted to enter all entries in the signal list manually.
Add Using Template: The wizard prepopulates a new signal entry for
UART, LED, GPIO, or DIP Switch signals with the following:
• A generic signal name

• Description
• Direction
• Bit width
You may change the values in any of these prepopulated fields.
Delete: Delete the selected signal from list.
The following example demonstrates using the Add Using Template feature.
1 In the Turnkey I/O dialog, click Add Using Template.
2 You can now view the template dialog.
3 Pull down the I/O list and select from the following options:
17-35
4 Click OK.
5 The wizard adds the specified signal (or signals) to the I/O list.
17-36
Validation
FPGA-in-the-Loop Test
• Run FPGA-in-the-Loop test: Select to generate an FPGA programming

file.
- Include FPGA board in the test: (Optional) This selection program
the FPGA with the generated programming file, detects the Ethernet
connection (if selected), and performs FPGA-in-the-Loop simulation.
- Board IP address: (Ethernet connection only) Use this option for
setting the board’s IP address if it is not the default IP address
(192.168.0.2).
17-37
You may need to change your computer’s IP address to a different subnet

from 192.168.0.x when you set up the network adapter. You would also
need to change the address if the default board IP address 192.168.0.2 is
in use by another device.. If so, change the Board IP address according
to the following guidelines:
• The subnet address, typically the first three bytes of board IP address,
must be the same as those of the host IP address.
• The last byte of the board IP address must be different from that of
the host IP address.
• The board IP address must not conflict with the IP addresses of other
computers.
For example, if the host IP address is 192.168.8.2, then you can use
192.168.8.3, if available.
FPGA Turnkey Test
• Run FPGA Turnkey test: Select to generate an FPGA programming

file using an HDL design that contains a counter. You must have a board
attached.
• Select output LED: The counter output is connected with the LED you
select. Skip this test if you do not have an LED output.
Finish
When you have completed validation, click Finish. See “Save Board
Definition File” on page 17-18.
17-38
FPGA Board Editor
FPGA Board Editor

To edit a board definition XML file, you must first make it writeable. If
the file is read-only, the FPGA Board Editor only lets you view the board
configuration information. You cannot modify that information.
In this section...
“General” on page 17-39
“Interface” on page 17-41
General
17-39
Board Name: Unique board name
Device Information:
• Vendor: Xilinx or Altera

• Family: Family depends on the specified vendor. See the board
• Device: Device depends on the specified vendor and family. See the board
• For Xilinx boards only:
- Package: Package depends on specified vendor, family, and device. See
the board specification file for applicable settings.
- Speed: Speed depends on package. See the board specification file for
applicable settings.
- JTAG Chain Position: Value indicates the starting position for JTAG
chain. Consult the board specification file for this information.
• FPGA Input Clock. Clock details are required for both the FIL and
Turnkey workflows. You can find all necessary information in the board
specification file.
- Clock Frequency. Must be between 5 and 300. For an Ethernet
interface, the suggested clock frequencies are 50, 100, 125, and 200 MHz.
- Clock Pin Number . Must be specified. Example: N10.
- Clock Type : Single_Ended or Differential.
• Reset (Optional). If you want to indicate a reset, find the pin number and
active level in the board specification file, and enter that information.
- Reset Pin Number. Leave empty if you do not have one.
- Active Level : Active-Low or Active-High.
17-40
FPGA Board Editor
Interface
The Interface page describes the supported FPGA I/O Interfaces. Select any
listed interface and click View to see the Signal List. If the board definition
file has write permission, you can also Add New interface or Remove an
interface.
17-41
17-42
SystemC TLM 2.0 Generation
• Chapter 18, “How TLM Component Generation Works”

• Chapter 19, “TLM Component Architecture”
• Chapter 20, “Getting Started with TLM Component Generation”
• Chapter 21, “Generate TLM Component”
• Chapter 22, “Run TLM Component Test Bench”
• Chapter 23, “Export TLM Component to SystemC Environment”
• Chapter 24, “Configuration Parameters for TLM Generator Target”
18
How TLM Component

Generation Works
• “TLM Generation Algorithms” on page 18-2

• “The TLM Generation Process” on page 18-4
• “Generated TLM Files” on page 18-7
18 How TLM Component Generation Works
TLM Generation Algorithms

The algorithm you use to generate the TLM component can be made of any
combination of Simulink blocks that can generate C code. These blocks
generally belong to a subsystem. Simulink Coder™ software generates ANSI
C code from those blocks that HDL Verifier software then customizes with
the settings specified using the TLM component generator to create the files
that make up the virtual platform model. For an example of how this process
works, see the following illustration.
18-2
TLM Generation Algorithms
18-3
The TLM Generation Process

After you obtain the TLM component files generated by HDL Verifier
software, you can compile the TLM component and the optional test bench
with OSCI SystemC 2.2. libraries and the OSCI TLM 2.0 libraries. To do so,
use the makefile supplied by HDL Verifier to create your virtual platform
executable (e.g., mysimulation.exe).
The following diagram illustrates the complete set of articles you can generate
including the TLM component, the TLM component test bench, and the set of
test vectors to be executed by the test bench. Simulink generates these vectors
while performing model execution when you verify the TLM component from
within Simulink (see “Run TLM Component Test Bench” on page 22-8).
18-4
The TLM Generation Process
The following general workflow describes the process for creating an

OCSI-compatible TLM component representing the Simulink algorithm:
1 Create Simulink model representing algorithm.
2 Select required architectural model (i.e., virtual platform model)

parameters via the Simulink Configuration Parameters dialog box. See
“TLM Component Generation Overview” on page 21-2.
18-5
3 (Optional) If you want, restore any desired configuration sets at this time.
Because the topic of configuration sets is outside the scope of this workflow
description, refer to the section "Overview of Model Referencing" in the
4 Initiate code generation.
5 Save configuration options with model for future use.
18-6
Generated TLM Files
Generated TLM Files

HDL Verifier software generates the following files:
• C/C++ code containing the Simulink model behavior (.cpp and .h files)
• Virtual platform TLM component class (.cpp and .h files)
• TLM component documentation (HTML)
• TLM component test bench (if specified) (.cpp and .h files)
• Test bench stimulus and expected response vectors (MATLAB formatted
data)
• Makefiles for building the TLM component and standalone test bench
(makefile format)
18-7
After code generation is complete, you can then use these generated files
(outputs) to create the standalone TLM executable. See “Export TLM
Component” on page 23-4.
18-8
19
TLM Component
Architecture
19 TLM Component Architecture

In this section...
“Overview of Component Features” on page 19-2
“Single or Multiple Sockets” on page 19-5
“Memory Mapping” on page 19-5
“Command and Status Register” on page 19-11
“Interrupt” on page 19-19
“Test and Set Register” on page 19-19
“Tunable Parameter Registers” on page 19-19
“Algorithm Execution” on page 19-19
“Register and Buffering” on page 19-20
“Temporal Decoupling” on page 19-22
“TLM Component Timing Values” on page 19-27
“TLM Component Naming and Packaging” on page 19-28
Overview of Component Features

The TLM generator exports a target TLM component from a Simulink
model subsystem. The target TLM component has a single TLM socket that
supports read and write transactions using the TLM generic protocol and
generic payload.
The following diagram illustrates the simplest behavior you can specify for
the generated TLM component. It contains no memory map or command and
status register and executes transactions immediately.
19-2
There are a number of options you can use to control the architecture of
the generated TLM component. Incorporating a memory map is one of the
most effective options. The following figure demonstrates the behavior of a
generated TLM component with a full complement of features enabled.
19-3
You can set options for the following TLM component features:
• “Single or Multiple Sockets” on page 19-5

• “Memory Mapping” on page 19-5
- No memory map
- Automatically generated memory map with single address
- Automatically generated memory map with individual addresses
• “Command and Status Register” on page 19-11
• “Interrupt” on page 19-19
• “Test and Set Register” on page 19-19
• “Tunable Parameter Registers” on page 19-19
• “Algorithm Execution” on page 19-19
• “Register and Buffering” on page 19-20
19-4
• “Temporal Decoupling” on page 19-22

• “TLM Component Timing Values” on page 19-27
• “TLM Component Naming and Packaging” on page 19-28
Single or Multiple Sockets

You can choose to have a single, combined TLM socket for input data, output
data, and control or you can choose three separate TLM socket for input data,
output data, and control so that you can connect the sockets to different buses.
Memory Mapping
• “No Memory Map” on page 19-5
• “Automatically Generated Memory Map with Single Address” on page 19-7
• “Automatically Generated Memory Map with Individual Addresses” on
page 19-9
No Memory Map
The no memory map option generates a TLM component with only one read
and one write register without any address. The Simulink model inputs are
represented by the write register and the outputs are represented by the
read register.
19-5
Without a memory map, the generated TLM component has the following
characteristics:
• Has a single input register and a single output register.

• Does not need—and ignores—an address in the read and write requests
during SystemC simulation to select specific registers on the device.
- Receives all input data in a single write request, and a read request
receives all output data in the return value
• Has input and output registers either sized to hold an entire data set
required or created by the TLM component when it executes the behavior
(algorithm step function) in your virtual platform environment
19-6
• When input registers are full, this condition triggers (schedules) execution
of the behavior in the SystemC simulator. Output registers are handled
the same way.
• All defaults for commands and status are applied.
When you generate the TLM component with this option, you can use it in
a virtual platform (VP) as:
• A standalone component in a verification test bench

• A direct bound co-processing unit
• A device attached to a communication channel using a protocol adapter
Automatically Generated Memory Map with Single Address

The automatically generated memory map with single address option
generates a TLM component with only one read data register and one write
data register with one address each.
19-7
The Simulink model inputs are represented by the write register, and
the outputs are represented by the read register. HDL Verifier software
automatically assigns the addresses required to access those specific registers
during code generation. Those addresses give the specific offsets required to
address each individual register via read and write operations. Definition of
the base address for the entire generated TLM component should be defined
by the virtual platform that the TLM component resides in. The offset address
definitions appear in a definition file that is generated along with the TLM
component.
With a single address memory map, the generated TLM component has the
following characteristics:
• Has a single input register and a single output register, and optional
command and status register and test and set register.
• Must have an address in the read and write requests during SystemC
simulation to select specific registers on the device.
- Receives all input data in a single write request, and a read request
receives all output data in the return value
• Has input and output registers either sized to hold an entire data set
required or created by the TLM component when it executes the behavior
(algorithm step function) in your virtual platform environment
• If a command and status register is not used or if the command and status
register is used and the default values apply, when input register is full,
content is pushed into buffer, which then triggers (schedules) execution of
the behavior in the SystemC simulator. If the command and status register
19-8
is used and the Push Input Command is set to 1, the initiator module
moves the input data set from the input register to the input buffer. Output
registers are handled the same way.
• If a command and status register is not used, all defaults for commands
and status are applied.
When you generate the TLM component with this option, you can use it in a
virtual platform (VP) as a standalone component in a test bench, or you can
attach it to a communication channel.
Automatically Generated Memory Map with Individual

Addresses
The automatically generated memory map with individual address option
generates a TLM component with one read data register per model output
and write data register per model input with individual addresses.
19-9
Each Simulink model input is represented by its corresponding write register,

and each output is represented by its corresponding read register. HDL
Verifier software automatically assigns the addresses required to access
those specific registers during code generation. Those addresses give the
specific offsets required to address each individual register via read and write
operations. Definition of the base address for the entire generated TLM
component should be defined by the virtual platform that the TLM component
resides in. The offset address definitions appear in a definition file that is
generated along with the TLM component.
With an individual address memory map, the generated TLM component has
the following characteristics:
• Each input register and each output register has its own address as well as
an optional command and status register and test and set register.
• Must have an address in the read and write requests during SystemC
simulation to select specific registers on the device.
- Each input and output register must be accessed individually.
19-10
• Initiator module can write or read each input and output register in
multiple and/or partial transactions.
• The size of each input and output register is the size of the data.
• Execution is triggered when all input has been written or when command
and set register bits are set to Automatic. If set to manual, the initiator
module moves the input data set from the input register to the input buffer.
• Output registers are refreshed when all output registers have been read
or when command and set registers bits are set to Automatic. If set to
manual, the initiator module moves the output data set from the output
buffer to the output register.
When you generate the TLM component with this option, you can use it in a
virtual platform (VP) as a standalone component in a test bench, or you can
attach it to a communication channel.
Command and Status Register

You can choose to generate a TLM component with an automatically
generated memory map with addresses. When you do so, the TLM generator
offers you the option to incorporate a Command and Status register (CSR)
in the generated TLM component. The definition for this register appears
in the table.
Write-Only Bits
Write-only (WO) bits assert mutually exclusive commands. You can assert
only one command bit in any single write operation to the CSR. If more than
one command bit is set in the write to the CSR, the command is undefined.
You activate each command by writing a 1 to a command bit in the register.
Then, each command bit is automatically cleared after the command has been
executed. You do not have to write a 0 to the register to clear a command bit.
Write-Only bits are always returned as 0 in any read of the CSR. Writing a
command does not overwrite the Read/Write or Write-Only bits.
Read-and-Write Bits
Use Read and Write (R/W) bits to obtain the current status and setting. R/W
bit are sticky, meaning that after you set them by writing a 1 to the bit in the
register, an R/W bit remains set until a 0 is written to the same bit or the
19-11
Reset command is invoked. Read-and-Write bits return their actual values to

any read of the CSR.
A single write operation to the CSR sets all Read-and-Write bits in the
register. You can choose to set only some of the bits and maintain the
previous values of others. Before you do so, you must first read the CSR and
then modify the values according to your requirements. After you complete
modifications, you can write the entire 32 bits back to the CSR.
Read-Only Bits
Read-Only (RO) bits provide status information. The generated TLM
component automatically sets and clears their values, and an initiator module
can read them to learn status. Read-Only bits do not change their actual
values during any read or write of the CSR.
Register Definition
The following table contains the entire register definition.
The following table explains how the bits are defined.
19-12
Bit Name Read/Write Description

Status
CSR<0> Reset Write Only When set to 1, the following are
Command true:
• Input register contents are

made invalid
• Output register contents are
made invalid
• All CSR bits are set to 0 except
the following:
- Input Buffer Empty bit is
set to 1
- Output Buffer Empty bit is
set to 1
- Input Auto Mode is set to
default
- Output Auto Mode is set to
default
Automatically returns to 0 after

command execution.
CSR<1> Start Write Only Manually triggers execution of
Command the TLM component behavior
using the input data set that is
currently in the input register
when there is no input buffering.
When input buffering is used,
this command is undefined.
CSR<2> Interrupt Read Only Reflects the current state of
Status the Interrupt signal. Provides
status only; sets and clears itself
automatically.
19-13

Status
CSR<3> Interrupt Read and Write When set to 0 allows interrupts
Disable to be generated on the Interrupt
signal and reflected in the
Interrupt Status bit of the CSR.
When set to 1 disables generation
of interrupts.
CSR<8> Push Write Only When buffering is used and the
Input Input Mode is equal to 0 (manual
Command mode), this command allows an
initiator module to move the
input data set from the input
register to the input buffer. It
then triggers execution of the
TLM component behavior.
When buffering is not used, this
command is undefined.
When Input Mode is 1
(automatic), this command
is undefined.
CSR<9> Input Read and Write When set to 1 (automatic),
Mode movement of the input data set
from the input register to the
input buffer and execution of
the TLM component behavior
is triggered automatically if
a complete data set has been
written to the input register.
When set to 0 (manual):
movement of the input data set
from the input register to the
input buffer and execution of
the behavior must be manually
initiated. Do so by writing the
Start Command bit to 1, if no
19-14

Status
buffering is used, or writing the

Push Input Command to 1, if
buffering is present.
By default the Input Mode
is set to 1 (automatic). The
default may be changed to 0
(manual) if you specify it in the
TLM component constructor
parameters.
CSR<12> Pull Write Only When buffering is used and the
Output Output Mode is set to 0 (manual
Command mode), this command allows an
initiator module to move the
output data set from the head of
the output buffer to the output
register.
When buffering is not used, this
command has no effect.
When Output Mode is 1
(automatic), this command is
undefined.
CSR<13> Output Read and Write When set to 1 (automatic),
Mode movement of data from the
head of the output buffer to
the output register is triggered
automatically by the execution
of the TLM component behavior.
When set to 0 (manual),
movement of data from the head
of the output buffer to the output
register must be manually
initiated. Do so by writing the
Pull Output Command to 1, if
buffering is present.
19-15

Status
By default the Output Mode

is set to 1 (automatic). The
default may be changed to 0
(manual) if you specify it in the
TLM component constructor
parameters.
CSR<16> Input Read Only When set to 1, any TLM
Buffer component behavior execution
Empty without first pushing input
data to the input buffer, either
automatically or manually,
causes the Input Buffer
Underflow status to be asserted.
This bit is set to 0 by the TLM
component when the buffer is
not empty.
CSR<17> Input Read Only When set to 1, any push of input
Buffer data to the input buffer, either
Full automatically or manually,
without first executing the TLM
component behavior, causes the
Input Buffer Overflow status to
be asserted.
not full.
19-16

Status
CSR<18> Input Read and Write This bit is set to 1 by the TLM
Buffer component when an action is
Underflow taken to initiate execution of the
TLM component behavior with
no data available in the input
buffer.
This bit is sticky and can be
cleared with a write transaction
to set it back to 0.
CSR<19> Input Read and Write This bit is set to 1 by the TLM
Buffer component when input data is
Overflow pushed to the input buffer, either
automatically or manually, and
it is already full.
CSR<20> Output Read Only When set to 1, any pull of
Buffer output data from the output
Empty buffer, either automatically
or manually, without first
executing the TLM component
behavior, causes the Output
Buffer Underflow status to be
asserted.
not empty.
19-17

Status
CSR<21> Output Read Only When set to 1, any TLM
Buffer component behavior execution
Full without first pulling output data
to the output registers, either
automatically or manually,
causes the new output data to be
lost and Output Buffer Overflow
status to be asserted.
full.
CSR<22> Output Read and Write This bit is set to 1 by the TLM
Buffer component when an action is
Underflow taken to pull data from the
output buffer to the output
register, either automatically or
manually, and there is no data
available in the output buffer.
CSR<23> Output Read and Write This bit is set to 1 by the TLM
Buffer component when the TLM
Overflow component behavior is executed
and the output buffer is already
full, causing the new output data
to be lost.
19-18
Interrupt
You can choose to have an interrupt signal added to the generated TLM
component. The TLM component will assert this signal whenever new outputs
are available in any output register. The signal is automatically cleared
whenever a value is read from any output register.
The Interrupt signal is an ordinary SystemC boolean signal active high. The
Interrupt Active bit in the Status Register reflects the state of the interrupt
signal.
Test and Set Register

HDL Verifier software optionally provides the test and set register as a
means of controlling access to a shared TLM component in your SystemC
environment. Any read of this register returns the current value and sets the
register to a new, asserted value in an atomic operation. In systems where
there are multiple initiator modules, executing this task usually requires
access to the same target. If so, then an initiator module has exclusive
access to the generated TLM component as long as a common lock protocol is
followed by all other initiator modules. The initiator modules must read the
test and set register and use the target device only when that read operation
returns a value of zero. An initiator module can be sure that any subsequent
read of the test and set register returns a value of 1, which indicates to other
initiator modules that the device is busy. After gaining exclusive access to
the TLM component, an initiator module must release it when the target
operations complete by writing a zero to the test and set register.
Tunable Parameter Registers

The tunable parameter registers allows you to make adjustments to the TLM
component before or during simulation.
Algorithm Execution
You can choose between having a SystemC thread or a callback function in
your generated TLM component.
• SystemC thread: When the input buffers are full or when you write
a specific command in the command and status register and event is
triggered that the system scheduler picks up. It then executes that
19-19
function. Results in a likely more realistic simulation but the execution

could potentially be slower.
• Callback: When the input buffers are full or when you write a specific
command in the command and status register, the function is called
directly. Results in faster execution but could be less realistic as the
callback method does not process events in the same order they would
occur in a real world scenario.
Register and Buffering

• “Introduction” on page 19-20
• “Register” on page 19-20
• “Buffering” on page 19-21
Introduction
The TLM generator allows you to enable or disable input and output
data buffering between the TLM component interface and the algorithm
processing. For the cases when you have selected temporal decoupling, see
“Temporal Decoupling” on page 19-22.
Register
When you disable buffering, the TLM Component reads and writes inputs
and outputs directly from the interface register during algorithm processing.
Do not allow an initiator to perform a read or write of the registers during
algorithm processing; this action could corrupt the processing results. After
the initiator writes all input registers (if in AUTO mode) or when the initiator
writes the START command in the CSR, the algorithm begins processing.
HDL Verifier generates all timings using a SystemC wait function.
The following image demonstrates a TLM component without buffering.
19-20
Buffering
When you enable buffering, the TLM component queues the inputs and
the outputs in FIFOs between the interface and the algorithm processing.
You define the depth of the FIFOs in the TLM generator GUI. The TLM
component pushes the content of the input registers in the input queue under
either of the following conditions:
• After the initiator writes all input registers (if in AUTO mode)
• When the initiator writes the PUSH command in the CSR
The component triggers algorithm processing as soon as there is data in the

queue. When the component completes processing, it pushes the results in
the output queue.
The component replaces the content of the output registers with new outputs
coming from the output queue (if any are available) under either of the
following conditions:
• After the initiator reads all output registers (if in AUTO mode)
• When the initiator writes the PULL command in the CSR
19-21
HDL Verifier generates all timings using a SystemC wait function.
The following image demonstrates a TLM component with buffering.
Temporal Decoupling
• “Temporal Decoupling Overview” on page 19-22
• “Temporal Decoupling and No Buffering” on page 19-24
• “Temporal Decoupling and Buffering” on page 19-25
Temporal Decoupling Overview

The TLM generator allows you to enable or disable temporal decoupling
between the TLM component interface and the algorithm processing.
Temporal decoupling improves simulation speed by reducing the number
of synchronization points and rescheduling that occur during SystemC
simulation. With temporal decoupling, the TLM component uses a quantum
and allows each process to run ahead of the simulation time inside the
boundary of its quantum. This arrangement creates a notion of local time
in each thread that represents the thread advance as compared with the
19-22
simulation time. Because the use of temporal decoupling can change the event
order and process execution order, the simulation could lose some accuracy.
The following examples represent a simulation containing three threads:
• An initiator that writes data into the TLM component every 10 ms

• A TLM component that process the data
• A second initiator that reads the results
The time to write, process, or read the data is 5 ms.
In this first diagram, the simulation does not use temporal decoupling.
Without temporal decoupling, all the threads execute in sequential order and
to exchange the three data the component requires nine context switches.
In this second diagram, the simulation uses temporal decoupling and a

quantum of 45 ms.
19-23
With temporal decoupling, the TLM component modifies the execution order.
To exchange the three data, the simulation only requires three context
switches. It only requires three context switches because each thread must
reach the end of its quantum before giving control back to the simulation.
Even with temporal decoupling, the events and data exchanged between each
thread happen at the same simulation time as without temporal decoupling.
The component does not trigger events immediately but stores them in
temporal queues with a timestamp (built using the local time converted into
simulation time). When the triggering time is due, the queue triggers the
event at the exact simulation time.
For cases when you do not select temporal decoupling, see “Register and
Buffering” on page 19-20.
Temporal Decoupling and No Buffering

When you select temporal decoupling and you do not select buffering, the TLM
component queues the inputs and the outputs in temporal queues between
the interface and the algorithm processing. When a thread writes data in
those queues, the queue sorts the data by timestamp. In order to reproduce
the behavior of a register that allows data overwriting, when a thread reads
the queue, it receives the last written data before its actual local time. The
TLM component also queues all events exchanged between the interface and
the processing parts of the component in temporal queues. HDL Verifier
generates all timings using a timing annotation to the local time.
19-24
The following image illustrates a temporal queue:
The following image demonstrates a TLM component using temporal

decoupling without buffering.
Temporal Decoupling and Buffering

When you select temporal decoupling and buffering, the TLM component
queues the inputs and outputs in FIFO temporal queues between the interface
19-25
and the algorithm processing. You define the simulated depth of the FIFOs
in the TLM generator GUI. When a thread writes data in those queues, the
queue sorts the data by timestamp. In order to reproduce the behavior of a
FIFO that allows queuing of data in the limit of its simulated depth, when a
thread reads the queue, it receives the last Nth written data before its actual
local time (where N is the FIFO depth) . Imagine the FIFO depth as a sliding
window: the data a particular thread is viewing is limited to the simulated
depth of the FIFO and its view of the data moves or "slides" forward as local
time advances. The following image illustrates a FIFO temporal queue:
The TLM component also queues all events exchanged between the interface
and the processing parts of the TLM component in temporal queues. HDL
Verifier generates all timings using a timing annotation to the local time.
The following image demonstrates a TLM component using temporal

decoupling and buffering.
19-26
TLM Component Timing Values

You can specify that timing values be stored in the TLM component and
supplied to the SystemC environment when the TLM component is used.
Those values can be used in a system simulation environment which
carries out accounting of execution times in the system, as described in
the OSCI TLM-2.0 Language Reference Manual. These values—which you
supply—represent approximations of the actual time consumed by operations
involving the target device in a real system. They also add temporal realism
to your system simulations.
At runtime, you can dynamically control the TLM component via a backdoor
interface to enable and disable the return of timing information. See the
generated test bench code for details (locate mw_backdoorcfg_IF).
You can represent the following timing values:
19-27
• Time consumed by execution of the behavior in the generated TLM

component (this delay is simulated by a wait() or a time annotation,
depending on the temporal decoupling, in the TLM component thread
executing the algorithm step function)
• Time consumed by a write transfer to the TLM component (this delay is
returned to the initiator as a wait or time annotation in transaction), with
these further qualifiers:
- Time consumed by a single write transaction or the first write operation
of a burst
- Time consumed by a subsequent write operation in a burst
• Time consumed by a read transfer from the TLM component (this delay is
returned to the initiator as a wait or time annotation in transaction), with
these further qualifiers :
- Time consumed by a single read transaction or the first read operation of
a burst
- Time consumed by a subsequent read operation in a burst
TLM Component Naming and Packaging

An option in the configuration parameters for TLM Generation allows you
to specify use of a unique tag in naming the generated TLM component. See
“Identify Generated Files” on page 23-4 to see how the user tag is applied.
19-28
20
Getting Started with TLM

Component Generation
20 Getting Started with TLM Component Generation
Getting Started with TLM Generator

This example shows how to configure a Simulink® model to generate a
SystemC™/TLM component using the tlmgenerator target for either Simulink
Coder or Embedded Coder™.
For this example, we use a Simulink model of a FIR filter as the basis of
the SystemC/TLM generation.
Requirements to run this example:
• MATLAB
• Simulink
• Simulink Coder
• HDL Verifier
• SystemC 2.3 (includes the TLM library)
Note: The example includes a code generation build procedure. Simulink

does not permit you to build programs in the MATLAB installation area.
If necessary, change to a working directory that is not in the MATLAB
installation area prior to starting any build.
1. Open Preconfigured Model
Open the FIR Filter model or, in the MATLAB command window, execute
the following:
>> openTlmgDemoModel('intro');
The following model opens in Simulink.
2. Set Simulink Coder Target to TLM Generator
a. Open the Configuration Parameters dialog box by selecting Simulation

> Model Configuration Parameters in the model window.
20-2
b. In the Configuration Parameters dialog box, select the Code

Generation view in the left-hand pane.
c. Under System target file, click Browse to select the TLM generator
target. You can choose tlmgenerator_grt.tlc to use Simulink Coder or
tlmgenerator_ert.tlc to use Embedded Coder for HDL Code generation. For
this example, select tlmgenerator_grt.tlc.
3. Open TLM Generator View
In the Configuration Parameters dialog box, select the TLM Generator

view in the left-hand pane.
The TLM Generator view has five tabs:
• TLM Mapping
• TLM Processing
• TLM Timing
• TLM Testbench
• TLM Compilation
You will need to set different generator options in each pane.
4. Select TLM Mapping Options
In the TLM Mapping tab, Socket Mapping allows you to select the number
of sockets for input data, output data, and control. Select the option, Three
separate TLM sockets for input data, output data, and control.
20-3
The TLM Socket options allow you to define three different memory maps
for your generated TLM component.
For this example, select the following for the input and output data sockets:
• Auto-generated memory map for the input and output data sockets
• Individual input and output address offsets for each data socket.
This option generates a TLM component with one read register per model
output and one write register per model input with individual addresses.
Each Simulink model input is bound to its corresponding write register and
each output is bound to its corresponding read register.
The other memory map options you may consider are:
• No memory map: This option generates a TLM component with only one
read and one write register without any address. The Simulink model
inputs are bound to the write register and the outputs are bound to the
read register.
• [Auto-generated memory map with] Single input and output address
offsets: This option generates a TLM component with only one read and
one write register with one address each. The Simulink model inputs are
bound to the write register and the outputs are bound to the read register.
When you generate the component with a memory map, you can add a
command and status register, a test and set register, and tunable parameter
registers.
For this example, select the following for the Control TLM Socket:
• Include a command and status register in the memory map. The

command and status register allows you to write command and read status
during SystemC simulation; for example, manual buffering or buffer status.
• Include tunable parameter registers in the memory map. Tunable
parameter registers allow you to read or write the tunable parameter
values.
20-4
Although not used in this example, a test and set register can be used as
a mutex when multiple initiators access the component during SystemC
simulation.
5. Select TLM Processing Options
In the TLM Generation pane, select the TLM Processing tab. The
Algorithm Processing and the Interface processing options allow you
to define different buffering and processing behaviors for your generated
TLM component.
The algorithm execution options are:
• SystemC Thread: The step function algorithm is executed in its own

independent SystemC thread.
• Callback Function: The step function algorithm is executed in a callback
function called from the interface.
The step function timing is determined by the value in the Algorithm step
function timing (ns) field. The algorithm timing is counted with a wait()
in the thread or, if temporal decoupling is enabled, the algorithm timing is
counted with a quantum and time annotation in the thread or callback.
For this example, select SystemC Thread and enter 100 in the field for
Algorithm step function timing.
Interface processing options:
• Enable temporal decoupling for loosely-timed components (ns):

This option allows time decoupling between the interface and the
processing. A quantum and time annotation replace the wait() function
in the component. The data exchanged between the interface and the
processing are stored with timestamp annotation. You must specify the
maximum quantum time allowed in the system in the field Maximum
quantum for loosely-timed components (ns).
20-5
• Enable payload buffering: This option adds fifo of definable size between
the input/output interface and the processing in the generated component.
When you select this option, you must also provide the Payload input
buffer depth and the Payload output buffer depth.
• Create an interrupt request port on the generated TLM component:
This option creates an interrupt port (type signal, bool>) that is triggered
every time a set of input has been processed.
For this example, select or enter the following choices:
• Select Enable temporal decoupling for loosely-timed components

(ns), and enter 1000 for Maximum quantum for loosely-timed
components (ns).
• Select Enable payload buffering, and enter 5 for both the Payload
input buffer depth and the Payload output buffer depth.
• Select Create an interrupt request port on the generated TLM
component.
6. Select the TLM Timing Options
Select the TLM Timing tab. The Interface Timing section allows you to
define the timing of the component input/output interface and processing
thread.
For this example, the input and output delays are counted with wait() in the
interface or, if the temporal decoupling is enabled, they are annotated to the
received transaction and sent back to the initiator. Set a time value of 5ns
for each of the transactions of Input Data Interface Timing, Output Data
Interfacing Timing, and Control Interface Timing.
7. Select TLM Testbench View
Select the TLM Testbench tab. The TLM Generator target can generate a
stand-alone SystemC/TLM test bench alongside the TLM component to verify
the generated algorithm in the context of a TLM initiator/target pair. The
20-6
TLM Testbench view provides run-time options for when the test bench code
is generated and executed.
With the TLM Testbench options, you can:
• Choose to see verbose messages echoed to the command window during the
SystemC/TLM execution including TLM transaction and synchronization
messages.
• Indicate that the test bench should execute with or without timing
annotations.
• Indicate whether the initiator controls moving input and output datasets
between the registers and the buffers or whether the component performs
the moves automatically.
For this example, select Generate testbench, With timing for Run-time
timing mode, and Automatic for both Input buffer triggering mode and
Output buffer triggering mode.
After code generation has successfully occurred for a component and test
bench, the Verify TLM Component button becomes enabled. Verify TLM
Component performs the following:
• Builds the generated code using make and generated makefiles.

• Runs Simulink to capture input stimulus and expected results.
• Converts the Simulink data to TLM vectors.
• Runs the stand-alone SystemC/TLM testbench executable.
• Converts the TLM results back to Simulink data.
• Performs a data comparison.
• Generates a Figure window for any signals that had data mis-compares.
The compilation of the generated files assumes the presence of make and a
compatible GNU-compiler, gcc, in your path on Linux®, or Visual Studio®
compiler in your path on Windows®.
20-7
8. Select TLM Compilation View
Select the TLM Compilation tab. This pane provides options to control the
generation of makefiles used to compile the generated code.
Compiler Options:
The SystemC and TLM include library path options allow you to specify
where the makefiles can find the SystemC and TLM installations. The
default values allow you to use environment variables so that updates to
your SystemC or TLM installations do not require updating your Simulink
models. You can set up the environment prior to invoking MATLAB or use
the MATLAB setenv command.
For this example, these are the environment variable values that were tested
with standard OSCI installations located in /tools:
• SYSTEMC_INC_PATH=/tools/systemc-2.3.0/include
• SYSTEMC_LIB_PATH=/tools/systemc-2.3.0/lib-linux64
• SYSTEMC_LIB_NAME=libsystemc.a (Linux) or systemc.lib (Windows)
• TLM_INC_PATH=/tools/systemc-2.3.0/include
Component Naming:
This option allows you to add your own tag to the name of the generated
component. The generated component name is built according to the following
cases:
• If a user tag is specified: modelname_usertag_tlm

• If the user tag field is empty: modelname_tlm
For this example, enter intro for user tag.
9. Select Report
20-8
Select Report in the left-hand pane. For this example, select Create code
generation report and Open report automatically. These options
generate a html report during component generation. The Code generation
report details the contents of each generated file.
10. Select Debug
Select Debug in the left-hand pane. The Debug pane allows you to choose
the verbose option during component generation. This option could be helpful
to track a problem when it occurs during component generation.
For this example, do not select any of these options.
11. Save TLM Generator Options
Click OK to apply these settings and exit the Configuration Parameters

dialog box.
12. Build Model
In the model window, right-click on the DualFilter block and select C/C++
Code > Build This Subsystem in the context menu to start TLM component
generation.
Alternatively, you can execute the following command in the MATLAB

command window:
>> buildTlmgDemoModel('intro');
During execution, you will be prompted to select the tunable parameters. The
dropdown list of each coefficient allows you to select the storage class of the
variable. The Storage Class options are:
20-9
• Inlined - The inlined parameters are not tunable.

• SimulinkGlobal - The SimulinkGlobal variables are tunable.
ExportedGlobal, ImportedExtern and ImportedExternPointer are not

supported by the TLM Generation model.
The option Simulink Global has been selected for this example. Click Build.
The TLM generation is completed when you see the following message appear
in the MATLAB command window:
### Starting Simulink Coder build procedure for model: DualFilter

### Successful completion of Simulink Coder build procedure for model: Dual
13. Open Generated Files
Open the generated files in the MATLAB web browser by clicking on the links
in the generated report or in the MATLAB Editor (the generated files and
report are located in your current working directory):
• DualFilter_VP/DualFilter_intro_tlm_doc/html/DualFilter_codegen_rpt.html
• DualFilter_VP/DualFilter_intro_tlm/include/DualFilter_intro_tlm_def.h
• DualFilter_VP/DualFilter_intro_tlm/include/DualFilter_intro_tlm.h
• DualFilter_VP/DualFilter_intro_tlm/src/DualFilter_intro_tlm.cpp
• DualFilter_VP/DualFilter_intro_tlm_tb/src/DualFilter_intro_tlm_tb.h
• DualFilter_VP/DualFilter_intro_tlm_tb/src/DualFilter_intro_tlm_tb.cpp
• DualFilter_VP/DualFilter_intro_tlm_tb/src/DualFilter_intro_tlm_tb_main.cpp
14. Verify Generated Code
a. Open the Model Configuration Parameters dialog box by selecting

Simulation > Configuration Parameters in the model window.
b. In the Configuration Parameters dialog box, select the TLM Generator

view, and then select the TLM Testbench tab.
20-10
c. In the TLM Testbench pane, click Verify TLM Component, to run the
generated testbench.
Alternatively,you can execute the following command in the MATLAB

command window:
>> verifyTlmgDemoModel('intro')
This verify step performs the following actions:
• Builds the generated code.

• Runs the stand-alone SystemC/TLM test bench executable.
15. Review Execution Log
The option to generate test bench allows you to see how the test bench initiator
threads interact and synchronize with the target. Look for the comparison
result at the end of the log and verify that there is no data miscompare.
### Starting component verification

### Checking available compiler.
### Building testbench and TLM component.
make -f makefile.gnu all-am OPT_CXXFLAGS="-O3"
make[1]: Entering directory `/mathworks/home/skondapa/temp_tlmgdemo/DualFil
cd ../DualFilter_intro_tlm; make -f makefile.gnu all-am
cd ../DualFilter; make -f makefile.gnu all-am
gcc -c -O3 -Wall -Wno-deprecated -I ./include -I ./utils -o obj/DualFilt
gcc -c -O3 -Wall -Wno-deprecated -I ./include -I ./utils -o obj/DualFilt
20-11
ar cru lib/libDualFilter.a obj/DualFilter.o obj/DualFilter_data.o

ranlib lib/libDualFilter.a
-- Build libDualFilter.a completed --
make[3]: Leaving directory `/mathworks/home/skondapa/temp_tlmgdemo/DualFilt

gcc -c -O3 -Wall -Wno-deprecated -I ./include -I '../DualFilter/include' -
src/DualFilter_intro_tlm.cpp: In member function 'void DualFilter_intro_tlm
src/DualFilter_intro_tlm.cpp:259:8: warning: unused variable 'write_ok' [-W
ar cru lib/libDualFilter_intro_tlm.a obj/DualFilter_intro_tlm.o
ranlib lib/libDualFilter_intro_tlm.a
-- Build libDualFilter_intro_tlm.a completed --

gcc -c -O3 -Wall -Wno-deprecated -I ./include -I '../DualFilter_intro_tlm/
gcc obj/mw_support_tb.o obj/DualFilter_intro_tlm_tb.o obj/DualFilter_intro_
-- Build DualFilter_intro_tlm_tb.exe completed --

### Running Simulink simulation to capture inputs and expected outputs.
### Executing TLM testbench to generate actual outputs.
SystemC 2.3.0-ASI --- Aug 15 2012 14:40:01

Copyright (c) 1996-2012 by all Contributors,
ALL RIGHTS RESERVED
[ 0 s] (readerThread) ## found input field tlmg_in1 at tlmg_tlminve

[ 0 s] (readerThread) ## found input field tlmg_in2 at tlmg_tlminve
[ 0 s] (readerThread) ## found output field tlmg_out1 at tlmg_tlmin
[ 0 s] (readerThread) ## found output field tlmg_out2 at tlmg_tlmin
[ 0 s] (readerThread) ## setup 2 input data fields, 2 output data f
## STARTING SIMULATION
[ 0 s] (writerThread) ## Start of vectors from MAT file. Will displa
[ 12110 ns] (writerThread) .
[ 60655 ns] (readerThread) ## end of output data...Terminating readerThr
20-12
[ 60655 ns] (readerThread)

#############################################
## END OF VECTORS. PLAYED 501 VECTORS. ##
## DATA MISCOMPARES : 0 ##
## TRANSPORT ERRORS : NO ##
## MAT FILE WRITE ERRORS: NO ##
#############################################
[ 60655 ns] (readerThread) ## Wrote results MAT file.
[ 61040 ns] (writerThread) ## end of data...Terminating initiator thread.
## SIMULATION HAS ENDED
### Comparing expected vs. actual results.
Data successfully compared for signal tlmg_out1.
Data successfully compared for signal tlmg_out2.
### Component verification completed
This concludes the Getting Started with TLM Generator example.
20-13
20-14
21
Generate TLM Component
• “TLM Component Generation Overview” on page 21-2

• “Select TLM Generator System Target” on page 21-4
• “Select TLM Mapping Options” on page 21-6
• “Select TLM Processing Options” on page 21-10
• “Select TLM Timing Options” on page 21-11
• “Select TLM Testbench Options” on page 21-13
• “Select TLM Compilation Options” on page 21-15
• “Generate Component and Test Bench” on page 21-16
21 Generate TLM Component
TLM Component Generation Overview

In this section...
“TLM Component Generation Workflow” on page 21-2
“Subsystem Guidelines and Limitations” on page 21-2
TLM Component Generation Workflow

The following workflow shows the steps required to generate a TLM
component using HDL Verifier software:
1 Develop algorithm in Simulink. See “Subsystem Guidelines and

Limitations” on page 21-2.
2 “Select TLM Generator System Target” on page 21-4
3 “Select TLM Mapping Options” on page 21-6
4 “Select TLM Processing Options” on page 21-10
5 “Select TLM Timing Options” on page 21-11
6 “Select TLM Testbench Options” on page 21-13
7 “Select TLM Compilation Options” on page 21-15
8 “Generate Component and Test Bench” on page 21-16
9 (Optional) “Run TLM Component Test Bench” on page 22-8 (verify TLM
component)
10 “Export TLM Component” on page 23-4
Subsystem Guidelines and Limitations

Most subsystems that can be converted to C code are suitable for generating a
TLM component. When you are considering a subsystem for TLM generation,
keep in mind the following limitations:
• Simulink subsystem limitations for TLM generation:
21-2
TLM Component Generation Overview
- Same limitations as the Embedded Coder® target if you are using

Embedded Coder. If you are using Simulink Coder license, then
Simulink Coder limitations are the ones that apply.
- Bus data type not supported
• Simulink subsystem limitations tor TLM test bench generation:
- Composite Simulink signal types not supported (e.g., buses,
no-contiguous memory mux block outputs)
- Multi-rate subsystems are not supported (however, constants are
supported)
- Complex signals are not supported
- Subsystems with “action” ports are not supported (e.g., triggered,
enabled, if Action, switch case Action)
• SystemC/TLM generated component limitations:
- TLM simple target socket (with blocking and debug interfaces) using
Generic Payload
- TLM target only (no TLM initiator generation)
- 32-bits bus width only (address align on 4 bytes)
- No byte enable
- No endianess option
- No streaming
- No DMI
- Generic Payload extensions ignored
21-3
Select TLM Generator System Target

Select the system target file to activate TLM Component Generation option
tabs.
1 Select subsystem. See “Subsystem Guidelines and Limitations” on page

21-2 for help on selecting a suitable subsystem.
2 Select Simulation > Model Configuration Parameters in Simulink.
3 Select Code Generation
4 Select Browse on System Target File. Then, select follow these

guidelines for selecting the correct system target file:
• With Simulink Coder license, select: tlmgenerator_grt.tlc
• With Embedded Coder license (Simulink Coder license is also required),
select: tlmgenerator_ert.tlc or tlmgenerator_grt.tlc.
5 Click OK to see the new TLM Generator option under Code Generation.
21-4
Select TLM Generator System Target
6 Click TLM Generator to display the TLM Generation options panes.
21-5
Select TLM Mapping Options

1 Click on the TLM Mapping tab.
2 Socket Mapping
Select either One combined TLM socket for input data, output data,
and control or Three separate TLM sockets for input data, output
data, and control. (“Single or Multiple Sockets” on page 19-5)
3 For each socket, choose the socket mapping type. For a description of the
options available under Memory Map Type, see “Memory Mapping” on
page 19-5.
• No memory map
• Auto-generated memory map
If you choose Auto-generated memory map, the options expand to

include the Auto-Generated Memory Map Type section, as shown in
the following figures:
21-6
Auto-Generated memory map for single TLM socket
21-7
Auto-Generated memory map for separate TLM sockets
a Select the Auto-generated memory map type for each TLM socket:
• Single input and output address offsets (“Automatically Generated

Memory Map with Single Address” on page 19-7)
• Individual input and output address offsets (“Automatically Generated
Memory Map with Individual Addresses” on page 19-9)
b For the control socket (either separate or combined), select any of the
following options:
• Include a command and status register in the memory map (see
“Register and Buffering” on page 19-20)
21-8
• Include a test and set register in the memory map (“Test and Set
Register” on page 19-19)
• Include tunable parameter registers in the memory map (“Tunable
Parameter Registers” on page 19-19).
21-9
Select TLM Processing Options

1 Click on the TLM Processing tab.
2 Algorithm Step Function Execution. Select one of:
• SystemC Thread: the step function algorithm executes in its own

independent SystemC thread.
• Callback Function: the step function algorithm executes in a callback
function called from the interface.
See “Algorithm Execution” on page 19-19.
3 Algorithm step function timing (ns): Enter time in nanoseconds.
4 Interface Processing
a Enable temporal decoupling for loosely-timed simulation: Select

to enable temporal decoupling (see “Temporal Decoupling” on page
19-22).
If you selectEnable temporal decoupling for loosely-timed

simulation, enter the Maximum quantity for loosely-timed
components (ns).
b Enable payload buffering: Select to enable payload buffering.
If you select Enable payload buffering, enter the Payload input

buffer depth and the Payload output buffer depth.
c Create an interrupt request port on the generated TLM
component: Select to create interrupt request port.
21-10
Select TLM Timing Options
Select TLM Timing Options

1 Click on the TLM Timing tab.
2 Combined Interface Timing (one combined TLM socket for input data,
output data, and control)
For all timing options, specify the desired time in nanoseconds.
3 Input Data Interface Timing (separate TLM socket for input data)
For each timing option, specify the desired time in nanoseconds.

• Single write transfer or the first write transfer in a burst
transaction (ns)
• Subsequent write transfers in a burst transaction (ns)
See “TLM Component Timing Values” on page 19-27.
4 Output Data Interface Timing (separate TLM socket for output data)

• Single read transaction or the first read transfer in a burst
transaction (in ns)
21-11
• Subsequent read transfers in a burst transaction (ns)
5 Control Interface Timing (separate TLM socket for control)

• Single write transfer or the first write transfer in a burst
transaction (ns)
• Subsequent write transfers in a burst transaction (ns)
• Single read transaction or the first read transfer in a burst
transaction (in ns)
• Subsequent read transfers in a burst transaction (ns)
21-12
Select TLM Testbench Options
Select TLM Testbench Options

Use the test bench options to specify the following:
• Whether the test bench should execute with or without timing annotations
(Run-time timing mode)
• Whether the initiator controls moving input and output datasets between
the registers and the buffers or if the component moves the datasets
automatically.
See “TLM Component Test Bench Generation Options” on page 22-6.
1 Click on the TLM Testbench tab.
2 Generate testbench: select to generate a test bench for the generated

TLM component.
3 Generate verbose messages during testbench execution: select if

you want the test bench to generate verbose messages during test bench
execution. See “Verbose Messaging” on page 22-6.
4 Run-time timing mode
• With timing
• Without timing
See “Run-Time Timing Mode” on page 22-6.
5 Input buffer triggering mode
• Automatic
• Manual
See “Input Buffer Triggering Mode” on page 22-6.
Note You must select Include a command and status register in the
memory map in the TLM Generation tab for this field to be enabled.
21-13
6 Output buffer triggering mode
• Automatic
• Manual
See “Output Buffer Triggering Mode” on page 22-7.
Note You must select Include a command and status register in the
memory map in the TLM Generation tab for this field to be enabled.
7 Component Verification
After code generation is successfully completed, you can use Verify TLM
Component to perform the following actions:
• Build the generated code using make and generated makefiles.
• Run Simulink to capture input stimulus and expected results.
• Covert the Simulink data to TLM vectors.
• Run the standalone SystemC/TLM test bench executable.
• Convert the TLM results back to Simulink data.
• Perform a data comparison.
• Generate a Figure window for any signals that had data mis-compares.
21-14
Select TLM Compilation Options
Select TLM Compilation Options

1 Click on the TLM Compilation tab.
2 Compilation Options
As part of using the generated TLM component, you must compile the
generated files using a generated makefile provided by HDL Verifier
software. Use the options on the TLM Compilation tab to specify certain
makefile attributes before you generate code.
a Enter path to include SystemC
b Enter path to SystemC libraries
c Enter name of SystemC libraries
d Enter path to TLM component files
See “TLM Component Compiler Options” on page 23-2.
3 Component Naming
User-defined tag for TLM component names: Add additional text to

your TLM component class name identifier.
See “TLM Component Naming and Packaging” on page 19-28.
21-15
Generate Component and Test Bench

1 If you have not yet done so, finish selecting the TLM generation options and
click OK to save your changes and exit the TLM Generation options panes.
2 Generate code. Select one of the following ways:
• Press Ctrl-B (full model).

• Right-click on the subsystem and select C/C++ Code > Build This
Subsystem.
• Select Code > C/C++ Code > Build Model (this option builds the full
model).
• In Model Configuration Parameters dialog box, select the Code
Generation tab, and then click the Generate code button (the option
builds the full model).
Note You must generate the component and test bench on the architecture
you plan to use when running the SystemC simulation.
3 Go to “Run TLM Component Test Bench” on page 22-8 (optional).
For more about using the generated TLM component, see “Export TLM
21-16
22
Run TLM Component Test

Bench
• “Testing TLM Components” on page 22-2

• “TLM Component Test Bench Generation Options” on page 22-6
• “Run TLM Component Test Bench” on page 22-8
22 Run TLM Component Test Bench
Testing TLM Components

In this section...
“TLM Component Test Bench Overview” on page 22-2
“TLM Component Compilation” on page 22-2
“Automatic Verification of the Generated Component” on page 22-3
“Report Generation” on page 22-3
“Working with Configurations” on page 22-3
“Considerations When Creating a TLM Component Test Bench” on page
22-4
TLM Component Test Bench Overview

The test bench generation option is controlled by the TLM Testbench tab of
the Configuration Parameters dialog box. This option creates a standalone
SystemC test bench for the generated component. The test bench works by
applying test vectors against the generated TLM component and checking the
results of each transaction. When you click the Verify TLM Component
button on the TLM Testbench tab, the test vectors are automatically
captured from a Simulink simulation of your model .
You can configure the generated test bench to specify the timing mode and
the triggering modes for input and output buffering. The latter choice
allows you to indicate whether the initiator module controls moving input
and output data sets between the registers and the buffers or whether the
component performs the moves automatically. Optionally, the test bench can
also produce verbose messages at runtime to help you see the status of the
SystemC simulation.
TLM Component Compilation

The TLM Compilation tab in the Configuration Parameters dialog box
provides SystemC and TLM library location information. You can use
environment variables to specify these locations.
22-2
The information you provide is used to construct makefile. You can use
these makefiles to build the component and test bench. You can also use
this makefile to build an executable of the TLM component and test bench
outside of the MATLAB environment.
Automatic Verification of the Generated Component

The TLM Testbench tab of the configuration parameters provides a Verify
TLM Component button that:
• Automatically generates input stimulus and expected output data

• Builds and executes the component and the test bench together
• Automatically checks the outputs of the component
It performs the checking by capturing the outputs from the SystemC
simulation, converting them to Simulink data, and comparing them in
Simulink to the results of the Simulink simulation.
Report Generation
The tlmgenerator target supplies an HTML document containing details
about the generated component. The document contains links to the
generated source code files. Report generation can be configured via the
Simulink Coder Report pane in the configuration parameters. Report
generation is not strictly a test bench feature, but the process does include
use of test bench files.
Working with Configurations

After you select configuration options, you can save them with your Simulink
model. You can also restore saved configurations made in a previous session.
In addition, you can save and choose from multiple configurations for a given
model. See the section "Overview of Model Referencing" in the Simulink
documentation. for information on working with configurations.
22-3
Considerations When Creating a TLM Component

Test Bench
For optimizing your generated TLM code and achieving the desired test
bench, you should keep the following considerations in mind when developing
your Simulink model:
• Your model can use only a single rate.

• The composite signals on your model must be contiguous in memory.
You can make mux and bus output signals contiguous with the Signal
Conversion block.
• If your model contains complex signals, you must split them first. Split
complex signals with the Simulink Complex to Real-Imag block. You can
then combine the signals again with the Real-Imag to Complex block on
the other side of your design.
• Your design can contain a Triggered or Enabled subsystem, but the design
you generate cannot itself be a Triggered or Enabled subsystem.
• HDL Verifier can generate a Simulink design that involves continuous time
signals. When the Simulink simulation and the captured vector replay
in SystemC, they may not yield exactly the same results. The plot of the
difference reveals essentially the same curve with numerical differences
that are more pronounced at signal transitions, as shown in the following
MATLAB Figure windows.
22-4
This difference occurs because the Simulink signal capture necessarily

makes the signals discrete and thus the same exact data is not used in
both the Simulink and stand-alone SystemC simulations. You can improve
the fidelity of the discrete signal simulation in SystemC by choosing a
smaller fundamental step size in Simulink before clicking Verify TLM
Component.
22-5
TLM Component Test Bench Generation Options

In this section...
“Verbose Messaging” on page 22-6
“Run-Time Timing Mode” on page 22-6
“Input and Output Buffer Triggering Modes” on page 22-6
Verbose Messaging
This option generates verbose messages during test bench execution. The
default is not to generate these messages.
Run-Time Timing Mode

This mode allows you to specify which timing mode the generated test bench
and TLM component uses. With timing mode selected, the target annotates
TLM component transactions with delays, and the initiator module honors
them. When a quantum keeper is not used (see “Temporal Decoupling” on
page 19-22), the initiator module synchronizes immediately following the
transaction execution. When a quantum keeper is used, the initiator module
uses temporal decoupling and does not synchronize to the annotated delays
until the quantum is reached.
With timing mode not selected, the target does not annotate TLM component
transaction with any delays. The initiator module and target only perform
synchronization using zero-time wait calls.
Input and Output Buffer Triggering Modes

Input and output buffer triggering modes specify when data is moved from
registers to buffers and back. In your TLM environment, these specifications
are performed via a runtime configuration command. You can change them
dynamically throughout simulation.
Input Buffer Triggering Mode

This option allows you to specify when data moves from the input register to
the execution buffer.
22-6
TLM Component Test Bench Generation Options
The default is automatic mode. In this mode, the TLM component

automatically moves input data sets from the input registers to the input
buffer. If you instead choose manual mode, the initiator module must
explicitly write a command to the command and status register to move the
input data set from the register to the input buffer.
Manual mode enables an initiator module to re-use a complete or partial

input data set for a subsequent execution of the algorithm, thereby saving
simulation time by avoiding data TLM component transactions don’t need.
For example, if the target uses a full memory map and the initiator module
detects that only one of the inputs is changing, the initiator module may
execute TLM component transactions only for the changing input. The
initiator module then writes a push command to execute the algorithm.
Output Buffer Triggering Mode

Specify when data is moved from the results buffer to the output register.
The default is automatic mode. In this mode, the TLM component

automatically moves output data sets from the output buffer to the output
registers. If you choose manual mode instead, the initiator module must
explicitly write a command to the command and status register to move the
output data set from the output buffer to the output registers.
Manual mode enables an initiator module to read only partial output data
sets, saving simulation time by avoiding TLM component transactions that
are not wanted. For example, if the target uses a full memory map and the
initiator module is only interested in the data for one of the outputs, the
initiator module can manually move the algorithm results to the register.
The initiator module can then execute TLM component transactions only for
the output of interest.
22-7
Run TLM Component Test Bench

After the TLM component and test bench have been generated, you can verify
the generated TLM component using the test bench that was just created:
1 Open Model Configuration Parameters. Click on TLM Generation.
2 Select the TLM Testbench pane.
3 Click Verify TLM Component. The software performs the following

actions:
• Builds the generated code using make and generated makefiles.
• Runs the standalone SystemC/TLM test bench executable.
Note You must generate the component and test bench before you can select
Verify TLM Component. See “Generate Component and Test Bench” on
page 21-16.
22-8
23
Export TLM Component to

SystemC Environment
• “TLM Component Compiler Options” on page 23-2

• “Export TLM Component” on page 23-4
• “TLM Component Constructor and Default Parameters” on page 23-10
23 Export TLM Component to SystemC Environment
TLM Component Compiler Options

In this section...
“About the TLM Component Compiler Options” on page 23-2
“SystemC Include Path” on page 23-2
“SystemC Library Path” on page 23-2
“SystemC Library Name” on page 23-3
“TLM Include Path” on page 23-3
About the TLM Component Compiler Options

The SystemC and TLM include and library path options allow you to specify
where the makefiles can find the SystemC and TLM installations. HDL
Verifier software writes these strings directly into the generated makefiles.
The default values are environment variables (for example,

$SYSTEMC_INC_PATH, $SYSTEMC_LIB_PATH, and $TLM_INC_PATH). If you choose
to use the default and define the environment variables in your system, you
can usually update your SystemC/TLM installation without having to update
your Simulink models.
SystemC Include Path

Specify the location of the include folder in your SystemC installation. For
example:
/systemc-2.2.0/include
Alternately, you can use the default and define

$SYSTEMC_INC_PATH=/tools/systemc-2.2.0/include in your system.
SystemC Library Path

Specify the location of the library folder in your SystemC installation. For
example:
/systemc-2.2.0/lib
23-2
TLM Component Compiler Options

$SYSTEMC_LIB_PATH=/systemc-2.2.0/lib in your system.
SystemC Library Name

Specify the name of the SystemC library in your SystemC installation. For
example:
• Windows: systemc.lib
• Linux: libsystemc.a
Alternately, you can use the default and define $SYSTEMC_LIB_NAME in your
system.
TLM Include Path

Specify the location of the include folder in your TLM installation. For
example:
/tlm-2.0.1/include

$TLM_INC_PATH=/tlm-2.0.1/include in your system.
23-3
Export TLM Component

In this section...
“Identify Generated Files” on page 23-4
“Create Static Library with TLM Component” on page 23-6
“Create Standalone Executable with TLM Component” on page 23-8
Identify Generated Files

After code generation completes, go to your working folder. There you can
find the following folder: model_name_VP/. This folder contains the files
generated for the TLM component. The files appear under the subfolders
described in the following table.
Directory Name Files Description

Files relative to the behavior of the
model_name include/model_name*.h model. These files are independent
src/model_name.cpp of the TLM options. HDL Verifier
provides a makefile for you to build a
static library from these source files.
If another TLM component is generated
from the same model, these files are
regenerated (if the model has not
changed, the files will be identical). If
you generate a second TLM version of
the same model with a different tag
the TLM files are added to the _VP
folder with the new tag. It is possible
for the _VP folder to contain multiple
TLM variations of the same model all
using the same behavior files.
These files contain the TLM interface

model_name_usertag_tlm include/model_name_usertag_tlm.h to wrap the core behavior.
src/model_name_usertag_tlm.cpp
23-4
include/model_name_usertag_tlm_def.h
This file contains addresses and
definitions to communicate with the
component through the TLM target
port using a TLM generic payload.
The files are sorted in subdirectories
by source and header.
HDL Verifier provides a makefile for
you to build a static library from these
source files.
These files contain the core behavior
model_name_usertag_tlm_tb include/model_name_usertag _tlm_tb.h of the test bench.
src/model_name_usertag_
tlm_tb.cpp
src/model_name_usertag_
tlm_tb_main.cpp
This file instantiates and binds the
component and the test bench together.
The files are sorted in subdirectories
by source and header.
HDL Verifier software provides
a makefile for you to build an
executable from these source file and
the component static library. This
executable requires the following:
• Certain MATLAB libraries the

executable needs to be built and
run. These MATLAB libraries
are the static libraries libmat.a
and libmx.a and their dynamic
counterparts.
23-5
• The vector .mat files generated

when you click the Verify TLM
Component button. Before
building the component and test
bench on the virtual platform, verify
that the TLM component includes
these files.
This file is the entry point of the HTML
model_name_usertag_tlm_doc/ html/model_name_codegen_rpt.html documentation.
Create Static Library with TLM Component

Create a static library that contains the generated TLM component by
following the steps described for Linux or Windows.
Linux Users
1 Open a Linux console window.
2 Navigate to the model_name_VP/model_name_usertag_tlm/ folder.
3 Execute the following command to start the library compilation:
make -f makefile.gnu all
If you want to obtain symbols for source code debugging, use the all-debug
target instead of all.
4 When the system finishes compiling, locate a library

file named libmodel_name_usertag_tlm.a in the
model_name_VP/model_name_usertag_tlm/lib/ folder.
Windows Users
If you have not already, make sure that MATLAB\version\bin\win32 or
MATLAB\version\bin\win64 has been added to your user path.
You can choose one of the following ways to compile your project:
23-6
• Compile in Visual Studio® (open the model_name_usertag_tlm.vcproj

project in Visual Studio and follow the application instructions for
compiling your project).
• Compile in a console window.
1 Open a system console window.
2 Load the compilation tool chain by entering the following at the system
prompt:
Win32 users:
X:\>"%VS80COMNTOOLS%\..\..\VC\vcvarsall" x86
Win64 users:
If you have a later version of Visual Studio, you may need

to enter "%VS100COMNTOOLS%...", "%VS90COMNTOOLS%..." or
"%VS80COMNTOOLS%..." instead. Type set at the system prompt for a
list of environment variables; in that list you can find the environment
variable pointing to where the tool chain is installed.
3 In the same system console, navigate to the
model_name_VP/model_name_usertag_tlm/ folder.
X:\>nmake /f makefile.mk all
If you want to obtain symbols for source code debugging, use the
all-debug target instead of all.
5 When the system finishes compiling, locate a library
file named model_name_usertag_tlm.lib in the
model_name_VP/model_name_usertag_tlm/lib/ folder.
Note The temporary object files reside in the

model_name_VP/model_name_usertag_tlm/obj/ folder.
23-7
Create Standalone Executable with TLM Component

You can create a standalone TLM executable in the command shell by
following the steps for Linux or Windows.
Linux Users
1 Open a Linux console window.
2 Navigate to the model_name_VP/model_name_usertag_tlm_tb/ folder.
make -f makefile_tb.gnu all
If you want to obtain symbols for source code debugging, use the all-debug
target instead of all.
Note Executing this command also automatically builds a static library

with the TLM component source files.
4 When the system finishes compiling, locate an executable

file named model_name_usertag_tlm_tb.exe in the
model_name_VP/model_name_usertag_tlm_tb/ folder.
Windows Users
If you have not already, make sure that MATLAB\version\bin\win32 or
MATLAB\version\bin\win64 has been added to your user path.
You can choose one of the following ways to compile your project:
• Compile in Visual Studio (open the model_name_usertag_tlm.vcproj

project in Visual Studio and follow the application instructions for
compiling your project).
• Compile in a console window.
1 Open a system console window.
23-8
2 Load the compilation tool chain by entering the following at the system
prompt:
Win32 users:
Win64 users:
If you have a later version of Visual Studio, you may need

to enter "%VS100COMNTOOLS%...", "%VS90COMNTOOLS%..." or
"%VS80COMNTOOL%..." instead. Type set at the system prompt for a
list of environment variables; in that list you can find the environment
variable pointing to where the tool chain is installed.
3 In the same system console, navigate to the
X:\>nmake /f makefile.mk all
If you want to obtain symbols for source code debugging, use the
all-debug target instead of all.
Note Executing this command also automatically builds a static library

with the TLM component source files.
5 When the system finishes compiling, locate an executable

file named model_name_usertag_tlm_tb.exe in the
23-9
TLM Component Constructor and Default Parameters

The generated TLM component has the following constructor function
prototype:
model_name_usertag_tlm(sc_core::sc_module_name module_name, ...

eTimingType DefaultTiming = TIMED,
eModeType InputDefaultMode = AUTO, eModeType OutputDefaultMode = AUTO);
Where:
• module_name is a sc_core::sc_module_name type. It is a string that contains

the instance name.
• DefaultTiming is an eTimingType {TIMED, UNTIMED}. It determines
whether the TLM component is timed or untimed at the beginning of the
SystemC simulation. By default, the component initializes DefaultTiming
to TIMED, but you can change it to UNTIMED. Also during the simulation,
you can change the TLM component timing by calling the function
SetTimingParam (eTimingType Type).
• InputDefaultMode is an eModeType { MANUAL,AUTO}. It determines
whether the TLM component input mode is manual or auto at the beginning
of the SystemC simulation (and also after SystemC resets the component).
By default, the TLM component initializes InputDefaultMode to AUTO,
but you can change it to MANUAL.
• OutputDefaultMode is an eModeType { MANUAL,AUTO}. It determines
whether the TLM component output mode is manual or auto at
the beginning of the SystemC simulation (and also after SystemC
resets the component). By default, the TLM component intitializes
OutputDefaultMode to AUTO, but you can change it to MANUAL.
23-10
24
Configuration Parameters
for TLM Generator Target
24 Configuration Parameters for TLM Generator Target
TLM Component Generation

In this section...
“TLM Mapping” on page 24-2
“TLM Processing” on page 24-9
“TLM Timing” on page 24-17
“TLM Testbench” on page 24-21
“TLM Compilation” on page 24-26
TLM Mapping
TLM Generator Overview

The following user interface tabs contain the parameters for setting options
on the generated TLM component:
• TLM Mapping: Specify options for socket and memory mapping. See
Select TLM Mapping Options.
• TLM Processing: Specify options for algorithm and interface processing.
See Select TLM Processing Options.
• TLM Timing: Specify options for combined interface timing, or for
individual timing for input data, output data, and control sockets. See.
Select TLM Timing Options.
• TLM Testbench: Specify options for the generation and runtime behavior
of a standalone SystemC/TLM component test bench. See Select TLM
Testbench Options.
• TLM Compilation: Specify generated TLM component compilation
options. See Select TLM Compilation Options.
24-2
Socket Mapping
Choose the type of TLM socket for input data, output data, and control.
Settings. Default: One combined TLM socket for input data, output data,
and control
• One combined TLM socket for input data, output data, and control:
Create one combined TLM socket in the generated TLM component.
• Three separate TLM socket for input data, output data, and
control: Create three separate TLM sockets. Generate each data socket
with the following options:
- Auto-generated memory map (or without memory map)
- Command and status registers
- Test and set registers
- Tunable parameter registers
Dependencies. This parameter enables Combined TLM Socket or TLM

Socket for Input Data, TLM Socket for Output Data, and TLM Socket
for Control with Memory Map.
Setting this parameter to One combined TLM socket for input data,
output data, and control opens the Combined TLM Socket options
selection.
Setting this parameter to Three separate TLM socket for input data,
output data, and control opens the TLM Socket for Input Data, TLM
Socket for Output Data, and TLM Socket for Control with Memory
Map options selection.
Command-Line Information.
Parameter: tlmgComponentSocketMapping
Type: string
Value: |
Default:
24-3
Memory Map Type

Choose the type of addressing scheme for the combined TLM socket or the
separate TLM input data and output data sockets.
Settings. Default: No memory map
• No memory map: Create a single input register and a single output

register in the generated TLM component
• Auto-generate memory map: Create a single input address and a single
output address for all inputs and outputs or create a separate input register
for every input signal and a separate output register for every output signal
Dependencies. This parameter enables Auto-Generated memory map

Type.
Setting this parameter to Auto-generate memory map opens the

Auto-Generated Memory Map Type options selection.
Parameter: tlmgComponentAddressing (for combined TLM socket)|

tlmgComponentAddressingInput | tlmgComponentAddressingOutput
Type: string
Value: 'No memory map' | 'Auto-generated memory map'
Default: 'No memory map'
See Also. Memory Mapping
24-4
Auto-Generated Memory Map Type

Choose the type of addressing scheme to be automatically generated.
Settings. Default: Single input and output address offsets
• Single input and output address offsets: Create a single address offset
for the inputs and a single address offset for the outputs
• Individual input and output address offsets: Generate an address for
each input and each output
Dependencies. Auto-Generated memory map enables this parameter.
Parameter: tlmgAutoAddressSpecType (for combined TLM socket) |

tlmgAutoAddressSpecTypeInput | tlmgAutoAddressSpecTypeOutput
Type: string
Value: 'Single input and output address offsets' | 'Individual
input and output address offsets'
Default: 'Single input and output address offsets'
See Also. Memory Mapping
24-5
Include a command and status register in the memory map

Allows an initiator to send the TLM component commands such as "reset" and
"start", as well as read status bits such as "interrupt active", "output buffer
overflowed", and "input buffer empty".
Settings. Default: On
On
Include a command and status register in the memory map
Off
Do not include a command and status register in the memory map
Dependencies. If you selected a combined TLM socket, Auto-Generated

Memory Map enables this parameter.
If you selected Separate TLM sockets, this parameter is automatically

enabled for the control TLM socket.
Parameter:tlmgCommandStatusRegOnOff
Type: string
Value: 'on' | 'off'
Default: 'on'
See Also. Command and Status Registers
24-6
Include a test and set register in the memory map

Provides a means of controlling access to a shared TLM target device in your
SystemC environment.
Settings. Default: Off
On
Include a test and set register in the memory map. Any read of this
register will return the current value and set the register to a new,
asserted value in an atomic operation.
Off
Do not include a test and set register in the memory map

If you selected separate TLM sockets, this parameter is automatically enabled

for the control TLM socket.
Parameter: tlmgTestAndSetRegOnOff
Type: string
Value: 'on' | 'off'
Default: 'off'
See Also. Test and Set Register
24-7
Include tunable parameter registers in the memory map

The read/write tunable parameter registers are used by the initiator to change
the values of the algorithm tunable parameters.
On
Include tunable parameter registers in the memory map
Off
Do not include tunable parameter registers in the memory map

If you selected separate TLM sockets, this parameter is automatically enabled

for the control TLM socket.
Parameter: tlmgTunableParamRegOnOff
Type: string
Value: 'on' | 'off'
Default: 'on'
See Also. Tunable Parameters Register
24-8
TLM Processing
Algorithm Step Function Execution

Choose the type of function execution trigger you want to use in the generated
TLM component.
Settings. Default: SystemC Thread
• SystemC Thread: Event triggers system scheduler to execute function

• Callback: Function is executes as soon as input buffer is full or command
is written to command register
Parameter: tlmgAlgorithmProcessingType
Type: string
Value: 'SystemC Thread' | 'Callback'
Default: 'SystemC Thread'
See Also. Algorithm Execution
24-9
Algorithm step function timing (ns)

Specify the time in nanoseconds for modeling the algorithm execution time in
the TLM environment.
Settings. Default: 100
Parameter: tlmgAlgorithmProcessingTime
Type: int
Value:
Default: 100
See Also. TLM Component Timing
24-10
Enable temporal decoupling for loosely-timed simulation

Quantum allows loosely-timed simulation.
On
Enable quantum for loosely-timed simulation. Allows you to specify
the duration of the time quantum allocated to the generated TLM
component in your system simulation.
Off
Do not enable quantum
Dependencies. This parameter enables Maximum quantum for

loosely-timed components (ns).
Parameter: tlmgTempDecouplOnOff
Type: string
Value: 'on' | 'off'
Default: 'off'
See Also. Temporal Decoupling
24-11
Maximum quantum for loosely-timed components (ns)

Specify the time at which point temporally-decoupled components are forced
to synchronize.
Dependencies. Enable quantum for loosely-timed simulation enables

this parameter.
Parameter: tlmgQuantumTime
Type: int
Value:
Default: 1000
See Also. Temporal Decoupling
24-12
Enable payload buffering

Payload buffering allows for initiators to write multiple input data sets for the
algorithm step function and for the storage of multiple output data sets.
On
Enable payload buffering. Enabling payload buffering allows for a
different sample rate than was used in the original Simulink model.
Off
Do not enable payload buffering
Dependencies. This parameter enables Payload input buffer depth and

Payload output buffer depth.
Parameter: tlmgPayloadBufferingOnOff
Type: string
Value: 'on' | 'off'
Default: 'off'
See Also. Buffering
24-13
Payload input buffer depth

Choose the maximum number of possible outstanding input data sets before
triggering algorithm execution.
Dependencies. Enable payload buffering enables this parameter.
Parameter: tlmgPayloadInBufferDepth
Type: int
Value:
Default: 1
See Also. Buffering
24-14
Payload output buffer depth

Choose the maximum number of possible outstanding output data sets after
triggering algorithm execution.
Dependencies. Enable payload buffering enables this parameter.
Parameter: tlmgPayloadOutBufferDepth
Type: int
Value:
Default: 1
See Also. Buffering
24-15
Create an interrupt request port on the generated TLM

component
Specify that an interrupt signal be added to the generated TLM component.
On
Create an interrupt request port on the generated TLM component.
This signal will be asserted whenever new outputs are available in the
output register(s) and will be automatically cleared whenever any value
is read from the output register(s).
Off
Do not create an interrupt request port on the generated TLM
component
Parameter: tlmgIrqPortOnOff
Type: string
Value: 'on' | 'off'
Default: 'on'
See Also. Interrupt
24-16
TLM Timing
Single write transfer or the first write transfer in a burst

transaction (ns)
Specify the time in nanoseconds for the TLM component to execute a single
write transfer or the first write transfer in a burst transaction.
Parameter: tlmgFirstWriteTime (for combined TLM socket) |

tlmgFirstWriteTimeInput | tlmgFirstWriteTimeCtrl
Type: int
Value:
Default: 10
24-17
Subsequent write transfers in a burst transaction (ns)

Specify the time in nanoseconds for the TLM component to execute a
subsequent write transfer in a burst transaction.
Parameter: tlmgSubsequentWritesInBurstTime (for combined

TLM socket) | tlmgSubsequentWritesInBurstTimeInput |
tlmgSubsequentWritesInBurstTimeCtrl
Type: int
Value:
Default: 10
24-18
Single read transaction or the first read transfer in a burst

transaction (ns)
Specify the time in nanoseconds for the TLM component to execute a single
read transaction or the first read transaction in a burst transaction.
Parameter: tlmgFirstReadTime (for combined TLM socket) |

tlmgFirstReadTimeOutput | tlmgFirstReadTimeCtrl
Type: int
Value:
Default: 10
24-19
Subsequent read transfers in a burst transaction (in ns)

Specify the time in nanoseconds for the TLM component to execute a
subsequent read transfer in a burst transaction.
Parameter: tlmgSubsequentReadsInBurstTime (for combined

TLM socket) | tlmgSubsequentReadsInBurstTimeOutput |
tlmgSubsequentReadsInBurstTimeCtrl
Type: int
Value:
Default: 10
24-20
TLM Testbench
Generate testbench
Generate a standalone SystemC test bench in order to verify the generated
TLM component using the same input stimulus as used in Simulink.
On
Generate test bench for TLM component
Off
Do not generate test bench
Dependencies. This parameter enables all other parameters on this tab.
Parameter: tlmgGenerateTestbench
Type: string
Value: 'on' | 'off'
Default: 'on'
See Also. Testing TLM Components
24-21
Generate verbose messages during testbench execution

Generate verbose messages during test bench execution.
On
Test bench generates verbose runtime messages
Off
Test bench does not generate verbose messages
Dependencies. Generate testbench enables this parameter.
Parameter: tlmgVerboseTbMessagesOnOff
Type: string
Value: 'on' | 'off'
Default: 'off'
See Also. Verbose Messaging
24-22
Run-time timing mode

Specify the timing mode to be used by the generated test bench and TLM
component.
Settings. Default: With timing
• With timing: The target annotates TLM component transactions with

delays and the initiator will honor them. When a quantum keeper is not
used (see Temporal Decoupling), the initiator synchronizes immediately
following the transaction execution. When a quantum keeper is used, the
initiator utilizes temporal decoupling and does not synchronize to the
annotated delays until the quantum is reached.
• Without timing: The target does not annotate TLM component
transaction with any delays. The initiator and target only perform
synchronization using zero-time wait calls.
Dependencies. Generate testbench enables this parameter.
Parameter: tlmgRuntimeTimingMode
Type: string
Value: 'With timing' | 'Without timing'
Default: 'With timing'
See Also. Run-Time Timing Mode
24-23
Input buffer triggering mode

Specify when data is moved from the input register to the execution buffer. In
your TLM environment, this specification is done via a runtime configuration
command and can be changed dynamically throughout simulation.
Settings. Default: Automatic
• Automatic: The TLM component automatically moves input data sets

from the input registers to the input buffer.
• Manual: The initiator must explicitly write a command to the command
and status register in order to move the input data set from the register to
the input buffer.
Dependencies. The following parameters must each be selected to enable

the Input buffer triggering mode parameter:
• Include a command and status register in the memory map: Must

be selected.
• Generate testbench: Must be selected.
Parameter: tlmgInputBufferTriggerMode
Type: string
Value: 'Automatic' | 'Manual'
Default: 'Automatic'
See Also. Input and Output Buffer Triggering Modes
24-24
Output buffer triggering mode

Specify when data is moved from the results buffer to the output register. In
your TLM environment, this specification is done via a runtime configuration
command and can be changed dynamically throughout simulation.
Settings. Default: Automatic
• Automatic: The TLM component automatically moves output data sets

from the output buffer to the output registers.
• Manual: The initiator must explicitly write a command to the command
and status register in order to move the output data set from the output
buffer to the output registers.
Dependencies. The following parameters must each be selected to enable

the Input buffer triggering mode parameter:
• Include a command and status register in the memory map: Must

be selected.
• Generate testbench: Must be selected.
Parameter: tlmgOutputBufferTriggerMode
Type: string
Value: 'Automatic' | 'Manual'
Default: 'Automatic'
See Also. Input and Output Buffer Triggering Modes
24-25
TLM Compilation
24-26
SystemC include path

Specify the SystemC include path. This string is written directly into the
generated makefiles. The default is chosen such that if your define the
environment variable you should be able to update your SystemC/TLM
installation without having to update your Simulink models.
Settings. Default: $(SYSTEMC_INC_PATH)
Parameter: tlmgSystemCIncludePath
Type: string
Value:
Default: '$(SYSTEMC_INC_PATH)'
See Also. TLM Component Compiler Options
24-27
SystemC library path

Specify the location of the library directory in your SystemC installation.
This string is written directly into the generated makefiles. The default is
chosen such that if your define the environment variable you should be able
to update your SystemC/TLM installation without having to update your
Simulink models.
Settings. Default: $(SYSTEMC_LIB_PATH)
Parameter: tlmgSystemCLibPath
Type: string
Value:
Default: '$(SYSTEMC_LIB_PATH)'
24-28
SystemC library name

Specify the name of the SystemC library in your SystemC installation. This
string is written directly into the generated makefiles. The default is chosen
such that if your define the environment variable you should be able to update
your SystemC/TLM installation without having to update your Simulink
models.
Settings. Default: $SYSTEMC_LIB_NAME)
Parameter: tlmgSystemCLibName
Type: string
Value:
Default: '$(SYSTEMC_LIB_NAME)'
24-29
TLM include path

Specify the location of the TLM include directory in your TLM installation.
This string is written directly into the generated makefiles. The default is
chosen such that if your define the environment variable you should be able
to update your SystemC/TLM installation without having to update your
Simulink models.
Settings. Default: $(TLM_INC_PATH)
Parameter: tlmgTLMIncludePath
Type: string
Value:
Default: '$(TLM_INC_PATH)'
24-30
User-defined tag for TLM component names

Add additional text to your TLM component class name identifier, the input
and output data structures, and the directory to place the generated code.
Settings. No Default
Parameter: tlmgUserTagForNaming
Type: string
Value:
Default:
See Also. TLM Component Naming and Packaging
24-31
24-32
SystemVerilog DPI Component
Generation
• Chapter 25, “SystemVerilog DPI Component Generation”

• Chapter 26, “Context-Sensitive Help for Generated SystemVerilog
DPI Component”
25
SystemVerilog DPI
Component Generation
• “SystemVerilog DPI Component Generation” on page 25-2

• “Generate SystemVerilog DPI Component and Test Bench” on page 25-9
• “Customize Generated SystemVerilog Code” on page 25-14
• “Export SystemVerilog DPI Component to SystemVerilog Environment” on
page 25-20
• “Tune Gain Parameter During Simulation” on page 25-21
25 SystemVerilog DPI Component Generation

In this section...
“Overview” on page 25-2
“Data Types” on page 25-3
“Generated Test Bench” on page 25-4
“Generated SystemVerilog Wrapper” on page 25-4
“Customization” on page 25-7
“Limitations” on page 25-8
Overview
You can export a Simulink subsystem with DPI interface for Verilog® or
SystemVerilog Simulation. To do so, you must wrap generated C code with a
DPI wrapper that communicates with a SystemVerilog thin interface function
in a SystemVerilog simulation.
If you have a license for the Embedded Coder, you can access this feature
through the Model Configuration Parameters dialog box.
The topics in this introductory section contain information you need to know
before you begin:
• “Data Types” on page 25-3

• “Generated Test Bench” on page 25-4
• “Generated SystemVerilog Wrapper” on page 25-4
• “Customization” on page 25-7
• “Limitations” on page 25-8
When you understand how the SystemVerilog DPI component generator

works, you can choose to generate a component using the default template, or
you can choose to customize a template for your design.
• “Generate SystemVerilog DPI Component and Test Bench” on page 25-9
25-2
• “Customize Generated SystemVerilog Code” on page 25-14
When you have finished generating a component, see “Export SystemVerilog

DPI Component to SystemVerilog Environment” on page 25-20.
Data Types
Supported Simulink data types are converted to SystemVerilog data types, as
shown in the following table.
Simulink SystemVerilog
uint8 byte unsigned
uint16 shortint unsigned
uint32 int unsigned
uint64 longint unsigned
int8 byte
int16 shortint
int32 int
int64 longint
single shortreal
double real
boolean bit
vectors, matrices arrays
For example, a 4 by 2 matrix in
Simulink will be converted to a
one-dimensional array of 8 elements
in SystemVerilog.
Embedded Coder converts fixed data types to one of the supported Simulink
data types.
25-3
Generated Test Bench

The SystemVerilog DPI component generator creates a test bench that you
can use to verify that the generated SystemVerilog component is functionally
equivalent to the original Simulink subsystem. This is not intended as a
replacement for a system testbench for your own application, although you
can use the generated test bench as a starting example.
Note HDL Verifier does not support test bench generation for custom
generated SystemVerilog code. See “Customization” on page 25-7.
Generated SystemVerilog Wrapper

• “Generated Control Signals” on page 25-4
• “Generated Functions” on page 25-4
• “Parameter Tuning” on page 25-6
• “Extra Sample Delay” on page 25-6
Generated Control Signals

All SystemVerilog code generated by the SystemVerilog DPI generator
contains these control signals:
• clk: synchronization clock

• clk_enable: clock enable
• reset: asynchronous reset
Generated Functions
All SystemVerilog code generated by the SystemVerilog DPI generator
contains these functions:
• Initialize function
The Initialize function is called at the beginning of the simulation. If
the asynchronous reset signal is high (goes from 0 to 1), Initialize is
called again.
25-4
For example:
import "DPI-C" function void DPI_Subsystem_initialize();
• Output function
At the positive edge of clock, if clk_enable is high, the output function is
called first, and then the update function is called.
For example:
import "DPI-C" function void

DPI_Subsystem_output(input real
Subsystem_U_In1,output real Subsystem_Y_Out1
[]);
• Update function
At the positive edge of clock, if clk_enable is high, the update function
is called after the output function.
For example:
import "DPI-C" function void DPI_Subsystem_update();
• Setparam function
If your system has tunable parameters, the generated SystemVerilog code
also contains a setparam function.
import "DPI-C" function void

DPI_Subsystem_setparam(input P_Subsystem_T Subsystem_P);
The generated SystemVerilog code does not call this function. Instead,
the default parameters are used. To change those parameters during
simulation, you must explicitly call this function.
The function details in the SystemVerilog code generated from your system
vary. You can examine the generated code for specifics. For an example of
the generated functions in context, see the example "Getting Started with
Customizing Generated SystemVerilog Code".
25-5
Parameter Tuning
You may want to run various simulations with various values for the
parameters in your Simulink model. If your system has tunable parameters,
the generated SystemVerilog code also contains a setparam function. The
generated SystemVerilog code does not call this function. Instead, the default
parameters are used. To change those parameters during simulation, you
must explicitly call this function.
To create a tunable parameter, you create a data object from your subsystem
before generating the SystemVerilog code using the DPI component generator.
For a full examples, see “Tune Gain Parameter During Simulation” on page
25-21.
Extra Sample Delay

Compared with the original Simulink model, the generated SystemVerilog
module introduces one extra sample delay at the output. For example, in
the following Simulink model, the output is one-sample delayed version of
the input signal.
The generated C code preserves this behavior, and the output comprises one
sampled delayed version of the input signal. However, in the SystemVerilog
wrapper file, the clock signal is used to synchronize the input and output
signals:
always @(posedge clk) begin

DPI_blk2_output(blk2_U_In1, blk2_Y_Out1);
DPI_blk2_update();
end
The output of the SystemVerilog module can only be updated on the rising
edge of the clock. This requirement introduces an extra sample delay, as
the next figure shows.
25-6
Customization
You can customize the generated SystemVerilog wrapper by modifying
the template shipped with HDL Verifier (svdpi_ert_template.vgt).
Alternatively, you can create your own custom template. You must provide
anchors for the generated code in your template and to verify that the
template generates valid SystemVerilog code.
The default SystemVerilog template, provided by HDL Verifier, is

svdpi_ert_template.vgt. In this template, special clken_in and clken_out
control signals are added to the SystemVerilog module interface.
You can generate SystemVerilog DPI components from multiple subsystems

and connect them together in an HDL Simulator. When you do so, these
control signals determine the execution order of those components. They
also minimize the delay between the Simulink signal and the SystemVerilog
signal.
You can also specify your own template file with the following conditions:
• The file must be on the MATLAB path and searchable.

• The file must have a .vgt extension.
You can use these optional tokens to customize the generated code by
inserting them inside comment statements throughout the template:
• %<FileName>
• %<PortList>
• %<ImportInitFunction>
• %<ImportOutputFunction>
• %<ImportUpdateFunction>
• %<ImportSetParamFunction>
25-7
• %<CallInitFunction>
• %<CallUpdateFunction>
• %<CallOutputFunction>
See “Customize Generated SystemVerilog Code” on page 25-14 for step-by-step

instructions on customizing your code.
Note The SystemVerilog DPI component generator does not generate a test
bench for a component that has been customized.
Limitations
• There is no support for complex data types.
• If you have matrices or vectors, HDL Verifier limits them to
one–dimensional array in SystemVerilog. For example, a 4-by-2 matrix
in Simulink is converted to a one-dimensional array of 8 elements in
SystemVerilog.
• SystemVerilog DPI Component Generation supports the following
subsystems for code generation only:
- Multirate
- Triggered subsystem
- Enabled subsystem
- Subsystem with action port
There is no test bench support for these subsystems.
For best results, avoid exporting multiple subsystems separately because

it can be difficult to achieve the correct execution order. Instead, combine
multiple subsystems into one and generate code from the newly created,
single subsystem.
25-8
Generate SystemVerilog DPI Component and Test Bench

In this section...
“Set Up Model for Code Generation” on page 25-9
“Generate SystemVerilog DPI Component” on page 25-11
“Build Shared Library” on page 25-12
“Run Generated Test Bench” on page 25-13
Set Up Model for Code Generation

1 Open your model, and select Simulation > Model Configuration
Parameters.
2 Select the Code Generation pane.
3 At System target file, click Browse and select

systemverilog_dpi_ert.tlc from the list.
4 Expand the Code Generation pane to display additional dialogs. Select

Custom Code. In the text box under Include directories, enter the
folder that contains svdpi.h. This file is the header file for SystemVerilog
DPI, usually available with your HDL simulator installation.
25-9
5 In the Code Generation pane, select SystemVerilog DPI.
6 Select Generate test bench.
25-10
7 Click OK to accept these settings and to close the Configuration Parameters

dialog box. Go to “Generate SystemVerilog DPI Component” on page 25-11.
Generate SystemVerilog DPI Component

1 In your model, right click the block containing the subsystem you want to
generate the component from and set the subsystem as atomic.
select C/C++ Code > Build this subsystem.
2 Click Build.
25-11
The SystemVerilog component is generated as

subsystem_build/subsystem_dpi.sv, where subsystem is the name of
the subsystem from which you generated the DPI component.
3 Go to “Build Shared Library” on page 25-12.
Build Shared Library
Note When you build the shared libraries, make sure that you use the correct
bit version of the tools. For example, if you are using 64-bit ModelSim on
Windows, use the 64-bit version of Visual Studio to build the shared libraries.
On Windows
1 Start Visual Studio x64 Win64 Command Prompt if you are using
64-bit ModelSim, or Visual Studio Command Prompt if you are using
32-bit ModelSim. You can find them under your Visual Studio installation
menu.
2 At the prompt, change directory to subsystem_build under the current

directory, where subsystem is the name of the subsystem from which you
generated the DPI component.
3 Enter the following command:
nmake -f makefile_dpi_vc.mk
When it is completed, you will see the libsubsystem_dpi.dll file that the
command generated, where subsystem is the name of the subsystem from
which you generated the DPI component. Next, go to “Run Generated Test
Bench” on page 25-13.
On Linux
1 Start a terminal shell.
2 Change directory to the code generation directory.
25-12
make -f makefile_dpi_gcc.mk
When it is completed, you will see the libsubsystem_dpi.so file that the
command generated, where subsystem is the name of the subsystem from
which you generated the DPI component. Next, go to “Run Generated Test
Bench” on page 25-13.
Run Generated Test Bench

For ModelSim and Questa Sim
1 Start ModelSim or Questa® Sim in GUI mode.
2 Change your current directory to the dpi_tb folder under the code
generation directory in your HDL simulator installation.
3 Enter the following command to start your simulation:
do run_tb_mq.do
4 When the simulation finishes, you should see the following text printed
in your console:
**************TEST COMPLETED (PASSED)**************
For the Incisive Simulator
1 Start your terminal shell.
2 Change the current directory to "dpi_tb" under the code generation

directory.
3 Enter the following command in your shell.
sh run_tb_ncsim.sh
4 When the simulation finishes, you should see the following text printed
in your console:
**************TEST COMPLETED (PASSED)**************
25-13
Customize Generated SystemVerilog Code

In this section...
“Set Up Model for Customized Code Generation” on page 25-14
“Generate Customized SystemVerilog DPI Component” on page 25-18
“Build Shared Library” on page 25-18
Set Up Model for Customized Code Generation

1 Open your model and select Simulation > Model Configuration
Parameters.
2 Select the Code Generation pane.

4 Expand Code Generation to display additional dialogs. Select Custom

Code. At the option Include directories, enter the folder that contains
svdpi.h. This file is the header file for SystemVeilog DPI. Your HDL
simulator installation should have this file.
25-14
5 Expand Code Generation and select SystemVerilog DPI.
6 Select option Customize generated SystemVerilog code.
7 Specify the SystemVerilog template you want to use.
25-15
You can select Edit to see the contents of the template. The following
example shows the content of the template file svdpi_ert_template.vgt:
25-16
For more about the customized template, see “Customization” on page 25-7.
8 Click OK to accept these options and close the Configuration Parameters

dialog box. Next, go to “Generate Customized SystemVerilog DPI
25-17
Generate Customized SystemVerilog DPI Component

1 In your model, generate C code for subsystem.
You can generate C code from the command-line by using the MATLAB
command rtwbuild.
2 Go to “Build Shared Library” on page 25-18.
Build Shared Library
Note When you build the shared libraries, make sure that you use the correct
bit version of the tools. For example, if you are using 64-bit ModelSim on
Windows, use the 64-bit version of Visual Studio to build the shared libraries.
On Windows
1 Start Visual Studio x64 Win64 Command Prompt if you are using
64-bit ModelSim, or Visual Studio Command Prompt if you are using
32-bit ModelSim. You can find them under your Visual Studio installation
menu.
2 At the prompt, change directory to subsystem_build under the current

directory, where subsystem is the name of the subsystem from which you
generated the DPI component.
nmake -f makefile_dpi_vc.mk
After the shared library build completes, you see the libsubsystem_dpi.dll
file that the command generated, where subsystem is the name of the
subsystem from which you generated the DPI component.
On Linux
1 Start a terminal shell.
2 Change directory to the code generation directory.
25-18
make -f makefile_dpi_gcc.mk
After the shared library build completes, you see the libsubsystem_dpi.so
file that the command generated, where subsystem is the name of the
subsystem from which you generated the DPI component.
25-19
Export SystemVerilog DPI Component to SystemVerilog

Environment
Follow these instructions for using the generated SystemVerilog code.
1 Begin by including generated SystemVerilog code:
'include "blk1_inc.sv"
2 Next, call the Initialize function.
DPI_blk1_initialize();
3 Schedule the output and update function calls:
DPI_blk1_output( blk1_Y_Out1);
DPI_blk1_update( blk1_U_In1);
Example
'include "blk1_inc.sv"
module test_twoblock_tb;
initial begin
DPI_blk1_initialization();
end
always@(posedge clk) begin

#1
DPI_blk1_output(blk1_Y_Out1);
DPI_blk1_update(blk1_U_In1);
end
always@(posedge clk)
begin
blk1_U_In1 = blk1_U_In1 + 1.0;
end
25-20
Tune Gain Parameter During Simulation

In this section...
“Example Setup” on page 25-21
“Create a Simple Gain Model” on page 25-21
“Create Data Object for Gain Parameter” on page 25-22
“Generate SystemVerilog DPI Component” on page 25-24
“Add Parameter Tuning Code to SystemVerilog File” on page 25-25
“Run Simulation With Parameter Change” on page 25-26
Example Setup
This example walks you through an example of how you can generate a
tunable parameter from a Simulink model and tune that parameter when you
run the generated SystemVerilog code.
1 “Create a Simple Gain Model” on page 25-21
2 “Create Data Object for Gain Parameter” on page 25-22.
3 “Generate SystemVerilog DPI Component” on page 25-24.
4 “Add Parameter Tuning Code to SystemVerilog File” on page 25-25.
5 “Run Simulation With Parameter Change” on page 25-26.
Create a Simple Gain Model

If you would like to perform the example steps yourself, you must first create
an example model.
The example model has a single gain block with a gain parameter that will
be tuned during simulation.
25-21
1 Open the Simulink Block Library and click Commonly Used Blocks.
2 Add an Inport block.
3 Add a Delay. Double-click top open the block mask and set the Delay
length parameter to 2
4 Add a Gain block. Double-click to open the block mask and change the
value in the Gain parameter to gain.
5 Add an Outport block.
6 Connect all blocks as shown in the diagram above.
7 Continue to “Create Data Object for Gain Parameter” on page 25-22.
Create Data Object for Gain Parameter

1 Create a data object for the gain parameter using the data object wizard:
At the MATLAB command prompt, type:
gain = Simulink.Parameter
2 Next, type:
open('gain')
This command opens the Data Object Wizard.
3 Enter or select the following values:
• Value: 2
• Data type: double
25-22
• Storage class: SimulinkGlobal
4 Click OK.
5 Continue to “Generate SystemVerilog DPI Component” on page 25-24.
25-23
Generate SystemVerilog DPI Component

1 With the gain model open, select Simulation > Model Configuration
Parameters.
2 Click Code Generation.

4 Expand the Code Generation navigation pane to display additional dialogs.

Click Custom Code.
5 In the text box under Include directories, enter the folder that contains
svdpi.h; for example, c:\questa_sim_10.2a\include.
6 In the Code Generation navigation pane, click SystemVerilog DPI.
7 Leave both Generate test bench and Customize generated

SystemVerilog code unselected (because this example modifies the
generated SystemVerilog code, any test bench generated at the same time
will not have the correct results).
8 Click OK to accept these settings and to close the Configuration Parameters

dialog box.
9 In the example model, right click the gain and delay blocks and select
Create Subsystem from Selection. For this example, rename the
subsystem GainSS.
10 Right click GainSS and select C/C++ Code > Build this subsystem.
11 In the Build code for subsystem dialog box, click Build.
The SystemVerilog component is generated as

GainSS_build/GainSS_dpi.sv in your current working folder.
In the generated SystemVerilog module code, a function for the parameter

setting has been added.
25-24
The DPI parameter type definition that is generated is shown here:
// Definition of parameter structure

typedef struct {
real gain;
}P_GainSS_T;
12 Continue to “Add Parameter Tuning Code to SystemVerilog File” on page

25-25
Add Parameter Tuning Code to SystemVerilog File

Modify the generated SystemVerilog file for parameter tuning during
simulation:
1 Declare a variable of the parameter structure data type.
2 Assign the desired parameter value to this variable.
3 Call the parameter setting function with this variable as input.
In the following completed example of the SystemVerilog code, the gain

parameter is changed from 2 (the original value) to 6 after 100 ns of
simulation time:
// File: GainSS_dpi.sv
// Created: 2013-07-09 14:31:34
// Generated by MATLAB 8.2 and HDL Verifier 4.3
`timescale 1ns / 1ns

// Definition of parameter structure
typedef struct {
real gain;
}P_GainSS_T;
25-25
module GainSS_dpi(
input clk,
input clk_enable,
input reset,
input real GainSS_U_In1,
output real GainSS_Y_Out1
);
// Declare imported C functions

import "DPI-C" function void DPI_GainSS_initialize();
import "DPI-C" function void DPI_GainSS_output(input real GainSS_U_In1,output real GainSS_Y_Out1);
import "DPI-C" function void DPI_GainSS_update();
import "DPI-C" function void DPI_GainSS_setparam(input P_GainSS_T GainSS_P);
P_GainSS_T param;
initial begin
DPI_GainSS_initialize();
#100 param.gain = 6;
DPI_GainSS_setparam(param);
end
always @(posedge clk or posedge reset) begin

if(reset == 1'b1) begin
DPI_GainSS_initialize();
end
else if(clk_enable) begin
DPI_GainSS_output(GainSS_U_In1,GainSS_Y_Out1);
DPI_GainSS_update();
end
end
endmodule
Run Simulation With Parameter Change

To run your simulation, build the shared library and export the component,
as explained in the following topics:
• “Build Shared Library” on page 25-12
25-26
• “Export SystemVerilog DPI Component to SystemVerilog Environment” on

page 25-20
25-27
25-28
26
Context-Sensitive Help for

Generated SystemVerilog
DPI Component
26 Context-Sensitive Help for Generated SystemVerilog DPI Component
SystemVerilog DPI Pane
In this section...
“SystemVerilog DPI Overview” on page 26-3
“Customize SystemVerilog generated code” on page 26-4
“Source file template:” on page 26-5
“Generate test bench” on page 26-6
26-2
SystemVerilog DPI Overview

Specify options for exporting a Simulink algorithm (model or subsystem)
with a DPI interface for Verilog or SystemVerilog Simulation. You can
wrap generated C code with a DPI wrapper that communicates with a
SystemVerilog thin interface function in a SystemVerilog simulation.
This feature is available in the Model Configuration Parameters dialog. You

must have an Embedded Coder license to use this feature.
26-3
Customize SystemVerilog generated code

Indicate that you want to customize the generated SystemVerilog code.
Settings
Default: Off
On
Customize generated SystemVerilog code
Off
Do not customize generated SystemVerilog code
Dependencies
You must enter a template file in Source file template: if you want the
generator to include customized code.
26-4
Source file template:

Specify the file name and location of the template you want to use for
customizing the generated SystemVerilog code. You may use the template
supplied by HDL Verifier (svdpi_ert_template.vgt) or you may specify your
own template file with the following conditions:
• The file must be on MATLAB path and be searchable.

• The file must have a .vgt extension.
26-5
Generate test bench

Indicate that you want to generate a test bench for the DPI component.
Settings
Default: Off
On
Create a test bench for the generated DPI component
Off
Do not create a test bench for the generated DPI component
26-6

HDL Verifier™ User's Guide

Uploaded by

Copyright:

Available Formats

HDL Verifier™ User's Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HDL Verifier™ User's Guide

Uploaded by

Copyright:

Available Formats

What are the different ways to contact MathWorks for support or other inquiries?

What are the different ways to contact MathWorks for support or other inquiries?

What are the copyright and licensing terms for the HDL Verifier user guide?

What are the copyright and licensing terms for the HDL Verifier user guide?

HDL Verifier™

[email protected] Product enhancement suggestions

The MathWorks, Inc.

HDL Verification with Cosimulation

Create a MATLAB Test Bench ...................... 1-4

Code HDL Modules for Verification Using MATLAB . . 1-5

Code an HDL Verifier Test Bench Function . . . . . . . . . . 1-11

Place Test Bench on MATLAB Search Path . . . . . . . . . . 1-20

Start Server for MATLAB—HDL Simulator

Start HDL Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

Bind Test Bench Function Calls With matlabtb . . . . . . . 1-24

Schedule Options for a Test Bench Session . . . . . . . . . . . 1-28

Run MATLAB Test Bench Simulation . . . . . . . . . . . . . . . . 1-32

Stop Test Bench Simulation . . . . . . . . . . . . . . . . . . . . . . . . 1-40

Verify HDL Model with MATLAB Testbench . . . . . . . . . 1-41

HDL Cosimulation Using MATLAB Component

Create a MATLAB Component Function . . . . . . . . . . . . . 2-4

Code HDL Modules for Visualization Using MATLAB . . 2-5

Create an HDL Verifier MATLAB Component

Place Component Function on MATLAB Search

Start Connection to HDL Simulator . . . . . . . . . . . . . . . . . 2-13

Bind Component Function Calls With matlabcp . . . . . . 2-16

Schedule Options for a Component Session . . . . . . . . . . 2-20

Run MATLAB Component Function Simulation . . . . . . 2-24

Stop Component Simulation . . . . . . . . . . . . . . . . . . . . . . . . 2-32

HDL Cosimulation Using MATLAB System

Verify Viterbi Decoder Using MATLAB System Object

Simulink Test Bench Cosimulation . . . . . . . . . . . . . . . . . . 4-7

Create Simulink Model for Test Bench Cosimulation . . 4-8

Code an HDL Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9

Start HDL Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

Add HDL Cosimulation Block to Model . . . . . . . . . . . . . . 4-14

Define HDL Cosimulation Block Interface . . . . . . . . . . . 4-16

Run a Test Bench Cosimulation Session . . . . . . . . . . . . . 4-44

Verify HDL Model with Simulink Test Bench . . . . . . . . . 4-51

Test Bench Automatic Verification with Simulink . . . . 4-70

Replace HDL Component with Simulink

Code an HDL Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

Create Simulink Model for Component Cosimulation . . 5-10

Start HDL Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11

Add HDL Cosimulation Block to Model . . . . . . . . . . . . . . 5-13

Define HDL Cosimulation Block Interface . . . . . . . . . . . 5-15

Run a Component Cosimulation Session . . . . . . . . . . . . . 5-43

Record Simulink Signal State Transitions for

Visually Compare Simulink Signals with HDL

HDL Code Import for Cosimulation

Invoking the Cosimulation Wizard . . . . . . . . . . . . . . . . . . 7-5

Import HDL Code for MATLAB Function . . . . . . . . . . . . 7-6

Import HDL Code for MATLAB System Object . . . . . . . . 7-20

Import HDL Code for HDL Cosimulation Block . . . . . . . 7-37

Performing Cosimulation .......................... 7-53

HDL Cosimulation Wizard Tutorials . . . . . . . . . . . . . . . . . 7-55

Help Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-98

HDL Cosimulation Reference

Test Bench and Component Function Options . . . . . . . . 8-35