|
|
|
| R2011b Documentation → Simulink HDL Coder | |
Learn more about Simulink HDL Coder |
|
| Contents | Index |
| On this page… |
|---|
Code generation control objects are instances of the class slhdlcoder.ConfigurationContainer. This section describes the public methods of that class that you can use in your control files. All other methods of this class are for MathWorks internal development use only. The methods are described in the following sections:
The hdlnewcontrol function constructs a code generation control object. The syntax is
object = hdlnewcontrol(mfilename);
The argument to hdlnewcontrol is the name of the control file itself. Use the mfilename function to pass in the file name string.
This method establishes an implementation mapping between an HDL block implementation and a selected block or set of blocks within the model. The syntax is
object.forEach({'modelscopes'}, ...
'blocktype', {'block_parms'}, ...
'implementation', {'implementation_parms'})
The forEach method selects a set of blocks (modelscopes) that is searched, during code generation, for instances of a specified type of block (blocktype). Code generation for each block instance encountered uses the HDL block implementation specified by the implementation parameter.
Note You can use the hdlnewforeach function to generate forEach method calls for insertion into your control files. See Generating Selection/Action Statements with the hdlnewforeach Function for more information. |
The following table summarizes the arguments to the forEach method.
| Argument | Type | Description |
|---|---|---|
| block_parms | Cell array of strings | Reserved for future use. Pass in an empty cell array ({}) as a placeholder. |
| blocktype | String | Block specification that identifies the type of block that
is to be mapped to the HDL block implementation. Block specification
syntax is the same as that used in the add-block command.
For built-in blocks, the blocktype is of the form'built-in/blockname' For other blocks, blocktype must include the full path to the library containing the block, for example: 'dsparch4/Digital Filter' |
| implementation | String | The implementation string represents an
HDL block implementation to be used in code generation for all blocks
that meet the modelscope and blocktype search
criteria. Every block has at least one implementation. Summary of Block Implementations provides guidelines for specifying implementations, and lists supported blocks and their implementations. |
| implementation_parms | Cell array of p/v pairs | Cell array of property/value pairs that set code generation
parameters for the block implementation specified by the implementation argument.
Specify parameters as: 'Property', value where 'Property' is the name of the property and value is the value applied to the property.If the implementation has no parameters, or you want to use default parameters, pass in an empty cell array ({}) . Summary of Block Implementations describes the syntax of each parameter, and describes how the parameter affects generated code. Summary of Block Implementations lists supported blocks and their implementations and parameters. You can use the hdlnewforeach function to obtain the parameter names for selected block(s) in a model. See Specifying Block Implementations and Parameters in the Control File. |
| modelscopes | String or cell array of strings | Strings defining one or more Simulink paths: {'path1' 'path2'...'pathN'} Each path defines a modelscope: a set of blocks that participate in an implementation mapping. The set of blocks in a modelscope could include the entire model, all blocks at a specified level of the model, or a specific block or subsystem. A path terminating in a wildcard ('*') includes all blocks at or below the model level specified by the path. You can use the period (.) to represent the root-level model at the top of a modelscope, instead of explicitly coding the model name. For example: './subsyslevel/block'. See also Representation of the Root Model in modelscopes and Resolution of modelscopes.Syntax for modelscope paths is
|
You can represent the root-level model at the top of a modelscope as:
The full model name, as in the following listing:
cfg.forEach( 'aModel/Subsystem/MinMax', ...
'built-in/MinMax', {}, ...
'default');If you explicitly code the model name in a modelscope, and then save the model under a different name, the control file becomes invalid because it references the previous model name. It is then necessary to edit the control file and change all such modelscopes to reference the new model.
The period (.) character, representing the current model as an abstraction, as in the following listing:
cfg.forEach( './Subsystem/MinMax', ...
'built-in/MinMax', {}, ...
'Cascade');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.
When you save HDL code generation settings to a control file, the period is used to represent the root-level model.
A possible conflict exists in the forEach specifications in the following example:
% 1. Use default (multipliers) Gain block implementation
% for one specific Gain block within OneD_DCT8 subsystem
c.forEach('./OneD_DCT8/Gain14',...
'built-in/Gain', {},...
'default', {});
% 2. Use factored CSD Gain optimization
% for all Gain blocks at or below level of OneD_DCT8 subsystem.
c.forEach('./OneD_DCT8/*',...
'built-in/Gain', {},...
'default', {'ConstMultiplierOptimization','FCSD'});
The first forEach call defines an implementation mapping for a specific block within the subsystem OneD_DCT8. The second forEach call specifies a non-default implementation parameter ('ConstMultiplierOptimization') for all blocks within or below the subsystem OneD_DCT8.
The coder resolves such ambiguities by always giving higher priority to the more specific modelscope. In the example, the first modelscope is the more specific.
Five levels of modelscope priority from most specific (1) to least specific (5) are defined:
A/B/C/block
A/B/C/*
A/B/*
*
Unspecified. Use the default implementation.
This method is a shorthand form of forEach. Only one modelscope path is specified. The modelscope argument is specified as a string (not a cell array) and it is implicitly terminated with'/*'. The syntax is
object.forAll('modelscope', ...
'blocktype', {'block_parms'}, ...
'implementation', {'implementation_parms'})
All other arguments are the same as those described for forEach.
The set method sets one or more code generation properties. The syntax is
object.set('PropertyName', PropertyValue,...)
The argument list specifies one or more code generation options as property/value pairs. You can set any of the code generation properties documented in Properties — Alphabetical List, except the HDLControlFiles property.
Note If you specify the same property in both your control file and your makehdl command, the property will be set to the value specified in the control file. Likewise, when generating code via the GUI, if you specify the same property in both your control file and the HDL Coder options panes, the property will be set to the value specified in the control file. |
This method selects the model or subsystem from which code is to be generated. The syntax is
object.generateHDLFor('simulinkpath')
The argument is a string specifying the full path to the model or subsystem from which code is to be generated.
To make your control files more portable, you can represent the root-level model in the path as an abstraction, as in the following example:
function c = newforeachexamp
c = hdlnewcontrol(mfilename);
% Set top-level subsystem from which code is generated.
c.generateHDLFor('./symmetric_fir');
...
The above generateHDLFor call is valid for any model containing a subsystem named symmetric_fir at the root level.
Use of this method is optional. You can specify the same parameter in the Generate HDL for menu in the HDL Coder pane of the Configuration Parameters dialog box, or in a makehdl command.
The coder provides the 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 the hdlnewcontrolfile function reference page for details.
 | Structure of a Control File | Using Control Files in the Code Generation Process |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
