| Products & Services | Solutions | Academia | Support | User Community | Company |
| Download Product Updates | | | Get Pricing | | | Trial Software |
| Documentation → Simulink HDL Coder |
| Contents | Index |
This table summarizes what's new in V1.3 (R2008a):
| New Features and Changes | Version Compatibility Considerations | Fixed Bugs and Known Problems | Related Documentation at Web Site |
|---|---|---|---|
| Yes Details below | Yes—Details labeled as Compatibility
Considerations, below. See also Summary. | Bug
Reports | No |
New features and changes introduced in this version are:
Optional Suppression of Reset Logic Generation for Selected Delay Blocks
hdlnewcontrolfile Function Generates Control Files Automatically
Enhanced modelscope Syntax Increases Portability of Control Files
"What's This?" Context-Sensitive Help Available for Simulink Configuration Parameters Dialog
The coder now supports use of signals of complex data type.
You can use complex signals in the test bench without restriction.
In the device under test (DUT) selected for HDL code generation, support for complex signals is limited to a subset of the blocks supported by the coder. Some restrictions apply for some of these blocks. These blocks are listed in Blocks That Support Complex Data.
Two new code generation options have been added to help you customize naming conventions for the real and imaginary components of complex signals in generated HDL code. These options are available to the Global Settings / General pane in the HDL Coder pane of the Configuration Parameters dialog box, as shown in the following figure.

The Complex real part postfix option (and the corresponding ComplexRealPostfix CLI property) specifies a string to be appended to the names generated for the real part of complex signals. The default postfix is '_re'. See also Complex real part postfix.
The Complex imaginary part postfix option (and the corresponding ComplexImagPostfix CLI property) specifies a string to be appended to the names generated for the imaginary part of complex signals. The default postfix is '_im'. See also Complex imaginary part postfix.
This release includes significant enhancements to test bench generation.
You can use complex signals in the test bench without restriction. Use of complex signals within the DUT is limited to a subset of supported blocks. See also Complex Data Type Support.
A number of options have been added to the HDL Coder / Test Bench pane of the Configuration Parameters dialog box, as shown in the following figure.

Most of the new options have a corresponding command-line property. The following table lists the new options and their corresponding CLI properties, and provides hyperlinks to the relevant documentation.
| GUI Option | Command-line Property |
|---|---|
| Setup time: See Setup time (ns) | This is a display-only field. It does not have a corresponding user-settable command-line property. |
| Clock enable delay (in clock cycles): See Clock enable delay (in clock cycles) | TestBenchClockEnableDelay |
| Reset length : See Reset length (in clock cycles) | ResetLength |
| Hold input data between samples: See Hold input data between samples | HoldInputDataBetweenSamples |
| Initialize test bench inputs: See Initialize test bench inputs | InitializeTestBenchInputs |
| Multi-file test bench : See Multi-file test bench | MultifileTestBench |
| Test bench data file name postfix : See Test bench data file name postfix | TestBenchDataPostFix |
| Ignore test bench data checking: See Ignore output data checking (number of samples) | IgnoreDataChecking |
| Generate cosimulation blocks: See Cosimulation blocks | GenerateCoSimBlock |
The coder now supports the following blocks for HDL code generation:
Communications Blockset/Comm Sources/Sequence Generators/PN Sequence Generator
(This block requires Communications Blockset™.)
Signal Processing Blockset/Multirate Filters/CIC Decimation
Signal Processing Blockset/Multirate Filters/FIR Decimation
Signal Processing Blockset/Signal Operations/NCO
Signal Processing Blockset/Signal Processing Sources/Sine Wave
Simulink/Discontinuities/Saturation
Simulink/Discrete/Discrete-Time Integrator
Simulink/Math Operations/Real-Imag to Complex
Simulink/Math Operations/Complex to Real-Imag
Simple Dual Port RAM (see also Additional RAM Blocks.)
Single Port RAM (see also Additional RAM Blocks.)
SeeSummary of Block Implementations for a complete listing of blocks that are currently supported for HDL code generation.
In the previous release, the coder introduced output pipelining support for many block implementations (see OutputPipeline). In this release, pipelining support has been significantly expanded and enhanced. The following sections discuss new pipelining features.
You can now specify generation of input pipeline registers for selected blocks. To do this, invoke the new block implementation parameter {'InputPipeline', nStages} in a control file. The parameter value (nStages) specifies the number of input pipeline stages (pipeline depth) in the generated code. See InputPipeline for further information.
Most HDL block implementations support InputPipeline. See Summary of Block Implementations for a complete list of block implemenations and their parameters.
In this release, the coder introduces automatic pipeline insertion, a special optimization for HDL code generated from Embedded MATLAB Function blocks or Stateflow charts. Automatic pipeline insertion is performed when the {'OutputPipeline', nStages} parameter is specified for these blocks. When you specify OutputPipeline, the coder inserts internal pipeline stages into the HDL code generated for these blocks (rather than at the output of the HDL code) whenever possible. The nStages argument defines the number of pipeline stages to be inserted.
Automatic pipeline insertion lets you achieve higher clock rates in your HDL applications, at the cost of some latency caused by the introduction of pipeline registers.
See Distributed Pipeline Insertion for a detailed description of this feature.
When generating code for pipeline registers, the coder appends a postfix string to names of input or output pipeline registers. The default postfix string is _pipe. You can now customize the postfix string. To specify the postfix, use the Pipeline postfix option in the Global Settings / General pane in the HDL Coder pane of the Configuration Parameters dialog box (see the following figure). Alternatively, you can pass the desired postfix string in the makehdl property PipelinePostfix. See Pipeline postfix for an example.

The coder now supports two new RAM blocks, supplementing the previously supported Dual Port RAM block:
Simple Dual Port RAM: This block is identical to the Dual Port RAM , but does not have a data output at the write port. If data output at the write port is not required, you can achieve better RAM inferring with synthesis tools by using the Simple Dual Port RAM block rather than the Dual Port RAM block.
Single Port RAM: This block provides data input, write address and write enable, and data output ports. The block GUI includes a Output data during write drop-down menu, providing options that control how the generated RAM handles data that is read into the RAM during a write operation.
See RAM Blocks for detailed information on RAM blocks.
The coder now supports a wider range of functions and algorithms for the Math Function and Divide blocks, as follows:
The Math Function block reciprocal operation is now supported. Implementations using either hardware divide (HDL / operator) or iterative Newton algorithm are available.
The Math Function block conj function is now supported.
The Math Function block sqrt function implementations now support a choice of multiply/add, bitset shift/addition, or iterative Newton algorithms.
The Math Operations/Divide block reciprocal operation now supports implementations using either hardware divide (HDL / operator) or the iterative Newton algorithm.
See Math Function Block Implementations and Divide Block Implementations for further information.
The new {'ResetType','None'} block implementation parameter lets you suppress generation of reset logic for selected delay blocks. The following blocks support this parameter:
Integer Delay
Tapped Delay
Unit Delay
Unit Delay Enabled
The following control file specifies suppression of reset logic for a specific unit delay block within the subsystem resetnone_examp/HDLSubsystem.
function c = resetnone_examp
% Control file for resetnone_examp
c = hdlnewcontrol(mfilename);
c.generateHDLFor('resetnone_examp/HDLSubsystem');
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Suppress reset logic for Unit Delay block
c.forEach('resetnone_examp/HDLSubsystem/Unit Delay',...
'built-in/UnitDelay', {},...
'hdldefaults.UnitDelayHDLEmission', {'ResetType','none'});
See ResetType for further information.
HDL code generation support for the Embedded MATLAB Function block has been enhanced in Release 2008a, as discussed in the following sections.
In this release, the coder provides the M-function hdlfimath.m, a utility that defines a FIMATH specification that is optimized for HDL code generation. When you configure an Embedded MATLAB Function Block for HDL code generation, it is strongly recommended that you replace the default FIMATH for fixed-point signals specification with a call to the hdlfimath function, as shown in the following figure.

See Use the hdlfimath Utility for Optimized FIMATH Settings for further information.
Embedded MATLAB Function block now supports use of complex data type for HDL code generation. All operators that support complex data types can be used in a Embedded MATLAB Function block code, subject to some restrictions. See the eml_hdl_design_patterns library for numerous examples showing applications of complex arithmetic in Embedded MATLAB Function blocks.
You can now generate HDL code from Embedded MATLAB Function blocks that include compiled external M-functions. This feature lets you write reusable M-code that can be called from multiple Embedded MATLAB Function blocks.
Such functions must be defined in M-files that are on the Embedded MATLAB path, and must include the %#eml compilation directive. See Adding the Compilation Directive %#eml in the Embedded MATLAB documentation for complete details.
An Embedded MATLAB function argument can be declared as a parameter argument by setting its Scope to Parameter in the Ports and Data Manager GUI.
Parameter arguments for Embedded MATLAB Function blocks do not appear as signal ports on the block. Parameter arguments do not take their values from signals in the Simulink model. Instead, their values come from parameters defined in a parent Simulink masked subsystem or variables defined in the MATLAB base workspace.
Only nontunable parameter arguments are supported for HDL code generation. If you declare parameter arguments in Embedded MATLAB function code that is intended for HDL code generation, be sure to clear the Tunable option for each parameter argument.
See also Parameter Arguments in Embedded MATLAB Functions in the Simulink documentation.
Rounding Functions. The Embedded MATLAB Function block now supports the following Fixed-Point Toolbox™ rounding functions for HDL code generation:
ceil
fix
floor
nearest
See also Supported Functions and Limitations of the Fixed-Point Embedded MATLAB Subset in the Fixed-Point Toolboxdocumentation.
Other Functions. The Embedded MATLAB Function block now supports the following for HDL code generation:
The bitreplicate function
The bitconcat function now supports:
single-vector argument:
bitconcat([a_vector]);
variable argument list:
bitconcat(a,b,c,...);
For general information on these functions, see Supported Functions and Limitations of the Fixed-Point Embedded MATLAB Subset in the Fixed-Point Toolboxdocumentation.
Stateflow charts now support the use of complex data types for HDL code generation. All operators that support complex data types can be used in a chart, without restriction.
See also Stateflow HDL Code Generation Support.
The coder provides the new hdlnewcontrolfile utility to help you construct code generation control files. Given a selection of one or more blocks from your model, hdlnewcontrolfile generates a control file containing forEach statements and comments providing information about all supported implementations and parameters, for all selected blocks. The generated control file is automatically opened in the MATLAB Editor for further customization. See hdlnewcontrolfile for details.
You can now integrate Simulink HDL Coder with third-party FPGA vendor tools for HDL code generation. For detailed information on how to do this, see the Simulink HDL Coder Technical literature page: http://www.mathworks.com/products/slhdlcoder/technicalliterature.html.
The new Optimize timing controller option (and the corresponding OptimizeTimingController CLI property) optimizes generated TimingController entities for speed and code size by generating multiple counters (one counter for each rate in the model) in the timing controller code. The benefit of this optimization is that it generates faster logic, and reduces generated code size.
By default, the Optimize timing controller option is selected, as shown in the following figure.

See Optimize timing controller for further details.
The modelscope argument to the forEach and forAll control file methods has been enhanced to allow use of the period (.) to represent the root-level model. This lets you represent the current model as an abstraction, instead of explicitly coding the model name, as in the following example:
cfg.forEach( './Subsystem/MinMax', ...
'built-in/MinMax', {}, ...
'hdldefaults.MinMaxCascadeHDLEmission');If you represent the model in this way, and then save the model under a different name, the control file does not require any change. Using the period to represent the root-level model makes the modelscope independent of the model name, and therefore more portable.
See also Representation of the Root Model in modelscopes in the Simulink HDL Coder User's Guide.
When you save HDL code generation settings to a control file, the control file contains a generateHDLFor statement that specifies the path to the DUT specified in the Generate HDL for field. In previous releases, the root-level model in this path was represented by an explicit model name reference. In release 2008a, by default, the root-level model is represented by the period, as described above.
If you resave model settings to an existing control file, be aware that such explicit references to root-level model name will be changed to the period syntax, in accordance with this new default. This will not affect the operation of your existing control files in any way.
R2008a introduces "What's This?" context-sensitive help for parameters that appear in the Simulink Configuration Parameters dialog. This feature provides quick access to a detailed description of the parameters, saving you the time it would take to find the information in the Help browser.
To use the "What's This?" help, do the following:
Place your cursor over the label of a parameter.
Right-click. A What's This? context menu appears.
For example, the following figure shows the What's This? context menu appearing after a right-click on the Start time parameter in the Solver pane.

Click What's This? A context-sensitive help window appears showing a description of the parameter.
In previous releases, only fixed-step solvers were supported for HDL code generation. In the current release, you can select a variable-step Solver type for your model, under the following limited conditions:
The device under test (DUT) is single-rate.
The sample times of all signals driving the DUT are greater than 0.
![]() | Version 1.4 (R2008b) Simulink HDL Coder Software | Version 1.2 (R2007b) Simulink HDL Coder Software | ![]() |

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |