Neighborhood Processing Subsystem
Libraries:
Simulink /
Matrix Operations
Description
The Neighborhood Processing Subsystem block is a Subsystem block preconfigured as a starting point for creating a subsystem that follows the neighborhood pattern. At each simulation time step, the subsystem iterates over each element of an input array. For each element, the subsystem processes a neighborhood of values surrounding that element. Use the subsystem for image processing. Certain image processing algorithms involve processing images in sections rather than processing the entire image at once.
Configuring Subsystem
The Neighborhood Processing Subsystem contains a Neighborhood block that acts as a control block for the subsystem. Specify the parameters of the Neighborhood block to configure the behavior of the subsystem.
The Neighborhood size parameter controls the dimensions of the
neighborhood. For elements near the edges of the input matrix, the neighborhood can extend
beyond the input matrix. The Padding option parameter controls how the
subsystem treats values from outside the input matrix. You can configure the subsystem to
pad these values with a constant or by reusing values from inside the matrix. If you use the
Constant
padding option, use the Padding
constant parameter to set the constant value.
You can configure the Neighborhood Processing Subsystem block to process only certain elements of an input matrix. Use the Stride parameter to configure the Neighborhood Processing Subsystem block to skip a certain number of elements at each iteration. Use the Processing offset and Processing width parameters to define the top left and bottom right boundaries, respectively, of a region of interest (ROI) within the image. The Neighborhood Processing Subsystem block iterates over only that region.
The Output size parameter controls the size of the output matrix.
The Same
value configures the output matrix to be the same size
as the ROI. The Full
value produces a larger output matrix by
calculating values for elements outside the ROI whose neighborhoods include at least one
element from the ROI. The Valid
value creates a smaller output
matrix by calculating values for only the elements whose neighborhoods do not extend beyond
the ROI. When you use this setting, the Padding constant parameter is
disabled.
Example
Consider this model.
In this example, the Neighborhood Processing Subsystem block takes a
5-by-5 matrix and outputs a matrix of the same dimensions by using the
Same
output size option. The subsystem contains these
blocks.
Inside the Neighborhood Processing Subsystem block, the inport does not
receive the full 5-by-5 matrix. Instead, because the Neighborhood size
parameter value is [3 3]
, the inport receives a smaller, 3-by-3 window of
elements. The subsystem iterates over the elements of the input matrix, passing the
neighborhood of each element to the inport at each iteration.
The model uses the Constant
padding option with a padding value of
0
. For neighborhoods that extend beyond the input matrix, the subsystem
treats the external values as 0
.
The outport of the Neighborhood Processing Subsystem block receives a
scalar which represents the derived value for the element at the center of the window. In
this case, a Sum of Elements block with the Sum over
parameter set to All dimensions
produces a scalar for each
window, representing the sum of the values in that window.
Run the model to populate the Display block.
Each value of the output matrix is the sum of the corresponding element and its eight
direct neighbors in the input matrix. The inner elements are surrounded by values of
1
, and so have the value 9
. The outer elements have
lower values because the selected padding method uses the value 0
for
elements outside the input matrix.
Examples
Calculate Optical Flow by Using Neighborhood Processing Subsystem Blocks
Use Neighborhood Processing Subsystem blocks to calculate the apparent motion of objects in a video.
Perform Edge Detection by Using a Neighborhood Processing Subsystem Block
Use a Neighborhood Processing Subsystem block to detect edges in an image.
Perform Corner Detection by Using Neighborhood Processing Subsystem Blocks
Use Neighborhood Processing Subsystem blocks to detect corners in an image.
Perform Fog Rectification by Using Neighborhood Processing Subsystem Blocks
Use Neighborhood Processing Subsystem blocks to remove fog from an image.
Limitations
The Neighborhood Processing Subsystem block does not support Switch blocks when you use normal simulation mode. To use a Switch block inside a Neighborhood Processing Subsystem block, use the accelerator or rapid accelerator simulation mode. For a workaround in normal simulation mode, see the Tips section.
The Neighborhood Processing Subsystem block does not support row-major layout.
Ports
Input
In — Signal input to a subsystem
matrix | vector
Use Inport blocks to get signals from the local environment.
Placing an Inport block in a Neighborhood Processing Subsystem block adds an external input port to the subsystem. The port label matches the name of the Inport block. Use the Neighborhood control block to configure which input signals to process using the neighborhood pattern.
Data Types: single
| double
| int8
| int16
| int32
| int64
| uint8
| uint16
| uint32
| uint64
| fixed point
Output
Out — Signal output from a subsystem
matrix | vector
Use Outport blocks to send signals to the local environment.
Placing an Outport block in a Neighborhood Processing Subsystem block adds an external output port from the subsystem. The port label matches the name of the Outport block.
Data Types: single
| double
| int8
| int16
| int32
| int64
| uint8
| uint16
| uint32
| uint64
| fixed point
Parameters
To edit block parameters interactively, use the Property Inspector. From the Simulink® Toolstrip, on the Simulation tab, in the Prepare gallery, select Property Inspector.
Main
Show port labels — Display options for port labels
FromPortIcon
(default) | FromPortBlockName
| SignalName
| none
Select how to display port labels on the Subsystem block icon.
none
— Do not display port labels.FromPortIcon
— If the corresponding port icon displays a signal name, display the signal name on the Subsystem block. Otherwise, display the port block name or the port number if the block name is a default name.FromPortBlockName
— Display the name of the corresponding port block on the Subsystem block.SignalName
— If the signal connected to the port is named, display the name of the signal on the Subsystem block. Otherwise, display the name of the corresponding port block.
For port label editing on Subsystem blocks, see Edit Port Labels on Subsystem Blocks.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | ShowPortLabels |
Values: | 'FromPortIcon' (default) | 'FromPortBlockName' | 'SignalName' | 'none' |
Read/Write permissions — Levels of access to contents of subsystem
ReadWrite
(default) | ReadOnly
| NoReadOrWrite
Control user access to the contents of the subsystem.
ReadWrite
— Enable opening and modification of subsystem contents.ReadOnly
— Enable opening but not modification of the subsystem. If the subsystem resides in a block library, you can create and open links to the subsystem and can make and modify local copies of the subsystem but cannot change the permissions or modify the contents of the original library instance.NoReadOrWrite
— Disable opening or modification of subsystem. If the subsystem resides in a library, you can create links to the subsystem in a model but cannot open, modify, change permissions, or create local copies of the subsystem.
You do not receive a response if you attempt to view the contents of a subsystem whose Read/Write permissions parameter is set to NoReadOrWrite
. For example, when double-clicking such a subsystem, the software does not open the subsystem and does not display any messages.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | Permissions |
Values: | 'ReadWrite' (default) | 'ReadOnly' | 'NoReadOrWrite' |
Name of error callback function — Name of function to be called if error occurs
no default
Enter the name of a function to be called if an error occurs while the software executes the subsystem.
The software passes two arguments to the function: the handle of the subsystem and a character vector that specifies the error type. If no function is specified, the software displays a generic error message if executing the subsystem causes an error.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | ErrorFcn |
Values: | '' (default) | function name in quotes |
Data Types: | char | string |
Permit hierarchical resolution — Resolution for workspace variable names
All
(default) | ExplicitOnly
| None
Select whether to resolve names of workspace variables referenced by this subsystem.
For more information, see Symbol Resolution and Symbol Resolution Process.
All
— Resolve all names of workspace variables used by this subsystem, including those used to specify block parameter values and Simulink data objects (for example,Simulink.Signal
objects).ExplicitOnly
— Resolve only names of workspace variables used to specify block parameter values, data store memory (where no block exists), signals, and states marked as “must resolve”.None
— Do not resolve any workspace variable names.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | PermitHierarchicalResolution |
Values: | 'All' (default) | 'ExplicitOnly' | 'None' |
Show subsystem reinitialize ports — Option to display reinitialize event ports
off
(default) | on
Select this parameter to display the reinitialize event ports. Clear this parameter to remove the ports.
Dependencies
To enable this parameter, select Treat as atomic unit.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | ShowSubsystemReinitializePorts |
Values: | 'off' (default) | 'on' |
Code Generation
Parameters on the Code Generation tab require a Simulink Coder™ or Embedded Coder® license.
Function packaging — Code format
Auto
| Inline
| Nonreusable function
| Reusable function
Select the code format to be generated for an atomic (nonvirtual) subsystem.
Auto
— The software chooses the optimal format for you based on the type and number of instances of the subsystem that exist in the model.Inline
— The software inlines the subsystem unconditionally.Nonreusable function
— If Filename options is set toAuto
, the software packages separate functions in the model file. If File name options is set toUse subsystem name
,Use function name
, orUser specified
using different filenames, the software packages separate functions in separate files.Subsystems with this setting generate functions that might have arguments depending on the Function interface parameter setting. You can name the generated function and file using parameters Function name and File name (no extension), respectively. These functions are not reentrant.
Reusable function
— The software generates a function with arguments that allows reuse of subsystem code when a model includes multiple instances of the subsystem.This option also generates a function with arguments that allows subsystem code to be reused in the generated code of a model reference hierarchy that includes multiple instances of a subsystem across referenced models. In this case, the subsystem must be in a library.
For more information, see:
Generate Code and Executables for Individual Subsystems (Simulink Coder)
Generate Inlined Subsystem Code (Simulink Coder)
Generate Subsystem Code as Separate Function and Files (Simulink Coder)
Generate Reusable Code from Library Subsystems Shared Across Models (Simulink Coder)
The default value depends on the block configuration. For example, the default
value for the Subsystem block is Auto
.
The default value for the CodeReuseSubsystem block is
Reusable function
.
Tips
When you want multiple instances of a subsystem to be represented as one reusable function, you can designate each one of them as
Auto
or asReusable function
. Using one or the other is best, as using both creates two reusable functions, one for each designation. The outcomes of these choices differ only when reuse is not possible. SelectingAuto
does not allow control of the function or filename for the subsystem code.The
Reusable function
andAuto
options both try to determine if multiple instances of a subsystem exist and if the code can be reused. The difference between the behavior of each option is that when reuse is not possible:Auto
yields inlined code, or if circumstances prohibit inlining, separate functions for each subsystem instance.Reusable function
yields a separate function with arguments for each subsystem instance in the model.
If you select
Reusable function
while your generated code is under source control, set File name options toUse subsystem name
,Use function name
, orUser specified
. Otherwise, the names of your code files change whenever you modify your model, which prevents source control on your files.If you select an option other than
Auto
orInline
and the model configuration parameter States, the code generator produces separate output and update methods. The code generator does not take into account the Combine output and update methods for code generation and simulation specification.
Dependencies
This parameter requires a Simulink Coder license for code generation.
To enable this parameter, select Treat as atomic unit.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWSystemCode |
Values: | 'Auto' | 'Inline' | 'Nonreusable function' | 'Reusable function' |
Function name options — How to name generated function
Auto
| Use subsystem name
| User specified
Select how the software names the function it generates for the subsystem.
If you have an Embedded Coder license, you can control function names with options on the Configuration Parameter Code Generation > Identifiers pane.
Auto
— Assign a unique function name using the default naming convention,
, wheremodel
_subsystem
()model
is the name of the model andsubsystem
is the name of the subsystem, or that of an identical one when code is being reused.If you select
Reusable function
for the Function packaging parameter and a model reference hierarchy contains multiple instances of the reusable subsystem, in order to generate reusable code for the subsystem, Function name options must be set toAuto
.Use subsystem name
— Use the subsystem name as the function name. By default, the function name uses the naming convention
.model
_subsystem
When a subsystem is in a library block and the subsystem parameter Function packaging is set to
Reusable function
, if you set theUse subsystem name
option, the code generator uses the name of the library block for the subsystem function name and filename.User specified
— Enable the Function name field. Enter any legal C or C++ function name, which must be unique.
For more information, see Generate Subsystem Code as Separate Function and Files (Simulink Coder).
The default value depends on the block configuration. For example, the default
value for the Subsystem block is Auto
.
The default value for the CodeReuseSubsystem block is
Use subsystem name
.
Dependencies
This parameter requires a Simulink Coder license.
To enable this parameter, set Function packaging to
Nonreusable function
orReusable function
.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWFcnNameOpts |
Values: | 'Auto' | 'Use subsystem name' | 'User specified' |
Function name — Name of function for subsystem code
no default
Specify a unique, valid C or C++ function name for subsystem code.
Use this parameter if you want to give the function a specific name instead of allowing the Simulink Coder code generator to assign its own autogenerated name or use the subsystem name. For more information, see Generate Subsystem Code as Separate Function and Files (Simulink Coder).
Dependencies
This parameter requires a Simulink Coder license.
To enable this parameter, set Function name options to
User specified
.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWFcnName |
Values: | '' (default) | function name in quotes |
Data Types: | char | string |
File name options — How to name generated file
Auto
| Use subsystem name
| Use function name
| User specified
Select how the software names the separate file for the function it generates for the subsystem.
Auto
— Depending on the configuration of the subsystem and how many instances are in the model,Auto
yields different results.If the code generator does not generate a separate file for the subsystem, the subsystem code is generated within the code module generated from the subsystem parent system. If the subsystem parent is the model itself, the subsystem code is generated within
ormodel
.c
.model
.cppIf you select
Reusable function
for the Function packaging parameter and your generated code is under source control, consider specifying a File name options value other thanAuto
. This prevents the generated filename from changing due to unrelated model modifications, which is problematic for using source control to manage configurations.If you select
Reusable function
for the Function packaging parameter and a model reference hierarchy contains multiple instances of the reusable subsystem, in order to generate reusable code for the subsystem, File name options must be set toAuto
.
Use subsystem name
— The code generator generates a separate file, using the subsystem (or library block) name as the filename.When File name options is set to
Use subsystem name
, the subsystem filename is mangled if the model contains Model blocks, or if a model reference target is being generated for the model. In these situations, the filename for the subsystem consists of the subsystem name prefixed by the model name.Use function name
— The code generator uses the function name specified by Function name options as the filename.User specified
— This option enables the File name (no extension) text entry field. The code generator uses the name you enter as the filename. Enter any filename, but do not include the.c
or.cpp
(or any other) extension. This filename need not be unique.While a subsystem source filename need not be unique, you must avoid giving nonunique names that result in cyclic dependencies. For example,
sys_a.h
includessys_b.h
,sys_b.h
includessys_c.h
, andsys_c.h
includessys_a.h
.
The default value depends on the block configuration. For example, the default
value for the Subsystem block is Auto
.
The default value for the CodeReuseSubsystem block is
Use function name
.
Dependencies
This parameter requires a Simulink Coder license.
To enable this parameter, set Function packaging to
Nonreusable function
orReusable function
.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWFileNameOpts |
Values: | 'Auto' | 'Use subsystem name' | 'Use function name' | 'User specified' |
File name (no extension) — Name of generated file
no default
The filename that you specify does not have to be unique. However, avoid giving
non-unique names that result in cyclic dependencies. For example,
sys_a.h
includes sys_b.h
,
sys_b.h
includes sys_c.h
, and
sys_c.h
includes sys_a.h
.
For more information, see Generate Subsystem Code as Separate Function and Files (Simulink Coder).
Dependencies
This parameter requires a Simulink Coder license.
To enable this parameter, set File name options to
User specified
.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWFileName |
Values: | '' (default) | filename in quotes |
Data Types: | char | string |
Function interface — How to use arguments with generated function
void_void
(default) | Allow arguments (Optimized)
| Allow arguments (Match graphical interface)
Select how to use arguments with the generated function.
void_void
— Generate a function without arguments and pass data as global variables. For example:void subsystem_function(void)
Allow arguments (Optimized)
— Generate a function that uses arguments instead of passing data as global variables. This specification reduces global RAM. This option might reduce code size and improve execution speed and enable the code generator to apply additional optimizations. For example:void subsystem_function(real_T rtu_In1, real_T rtu_In2, real_T *rty_Out1)
In some cases, when generating optimized code, the code generator might not generate a function that has arguments.
Allow arguments (Match graphical interface)
— Generate a function interface that uses arguments that match the Subsystem graphical block interface. The generated function interface is predictable and does not change. A predictable interface can be useful for debugging and testing your code and integrating with external applications. For example, if a model has two Inport blocks and two Outport blocks, then the generated function interface is:void subsystem_function(real_T rtu_In1, real_T rtu_In2, real_T *rty_Out1, real_T *rty_Out2)
For more information, see:
Reduce Global Variables in Nonreusable Subsystem Functions (Embedded Coder)
Generate Predictable Function Interface to Match Graphical Block Interface (Embedded Coder)
Generate Modular Function Code for Nonvirtual Subsystems (Embedded Coder)
Dependencies
This parameter requires an Embedded Coder license and an ERT-based system target file.
To enable this parameter, set Function packaging to
Nonreusable function
.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | FunctionInterfaceSpec |
Values: | 'void_void' (default) | 'Allow arguments (Optimized)' | 'Allow arguments (Match graphical interface)' |
Function with separate data — Control code generation for subsystem
off
(default) | on
Generate subsystem function code in which the internal data for an atomic subsystem is separated from its parent model and is owned by the subsystem.
off
— Do not generate subsystem function code in which the internal data for an atomic subsystem is separated from its parent model and is owned by the subsystem.on
— Generate subsystem function code in which the internal data for an atomic subsystem is separated from its parent model and is owned by the subsystem. The subsystem data structure is declared independently from the parent model data structures. A subsystem with separate data has its own block I/O andDWork
data structure. As a result, the generated code for the subsystem is easier to trace and test. The data separation also tends to reduce the maximum size of global data structures throughout the model, because they are split into multiple data structures.
For details on how to generate modular function code for an atomic subsystem, see Generate Modular Function Code for Nonvirtual Subsystems (Embedded Coder).
For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).
Dependencies
This parameter requires an Embedded Coder license and an ERT-based system target file.
To enable this parameter, set Function packaging to
Nonreusable function
.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | FunctionWithSeparateData |
Values: | 'off' (default) | 'on' |
Memory section for initialize/terminate functions — How to apply memory sections
Inherit from model
(default) | Default
| model memory
section
Select how the software applies memory sections to the subsystem initialization and termination functions.
Inherit from model
— Apply the root model memory sections to the subsystem function code.Default
— Do not apply memory sections to the subsystem system code, overriding any model-level specification.Apply one of the model memory sections to the subsystem.
Tips
The possible values vary depending on what, if any, package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder) and Model Configuration Parameters: Code Generation (Simulink Coder).
If you have not configured the model with a package,
Inherit from model
is the only available value. Otherwise, the list includesDefault
and all memory sections the model package contains.These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).
Dependencies
This parameter requires an Embedded Coder license and an ERT-based system target file.
To enable this parameter, set Function packaging to
Nonreusable function
orReusable function
.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWMemSecFuncInitTerm |
Values: | 'Inherit from model' (default) | 'Default' | model memory section in quotes |
Memory section for execution functions — How to apply memory sections
Inherit from model
(default) | Default
| model memory section
Select how Embedded Coder applies memory sections to the subsystem execution functions.
Inherit from model
— Apply the root model memory sections to the subsystem function code.Default
— Do not apply memory sections to the subsystem system code, overriding any model-level specification.Apply one of the model memory sections to the subsystem.
Tips
The possible values vary depending on what, if any, package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder) and Model Configuration Parameters: Code Generation (Simulink Coder).
If you have not configured the model with a package,
Inherit from model
is the only available value. Otherwise, the list includesDefault
and all memory sections the model package contains.These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).
Dependencies
This parameter requires an Embedded Coder license and an ERT-based system target file.
To enable this parameter, set Function packaging to
Nonreusable function
orReusable function
.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWMemSecFuncExecute |
Values: | 'Inherit from model' (default) | 'Default' | model memory section in quotes |
Memory section for constants — How to apply memory sections
Inherit from model
(default) | Default
| model memory section
Select how the software applies memory sections to the subsystem constants.
Inherit from model
— Apply the root model memory sections to the subsystem data.Default
— Do not apply memory sections to the subsystem data, overriding any model-level specification.Apply one of the model memory sections to the subsystem.
Tips
The memory section that you specify applies to the corresponding global data structures in the generated code. For basic information about the global data structures generated for atomic subsystems, see Standard Data Structures (Simulink Coder).
The possible values vary depending on what, if any, package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder).
If you have not configured the model with a package,
Inherit from model
is the only available value. Otherwise, the list includesDefault
and all memory sections the model package contains.These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).
Dependencies
This parameter requires an Embedded Coder license and an ERT-based system target file.
To enable this parameter, set Function packaging to
Nonreusable function
and select the Function with separate data parameter.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWMemSecDataConstants |
Values: | 'Inherit from model' (default) | 'Default' | model memory section in quotes |
Memory section for internal data — How to apply memory sections
Inherit from model
(default) | Default
| model memory section
Select how the software applies memory sections to the subsystem internal data.
Inherit from model
— Apply the root model memory sections to the subsystem data.Default
— Do not apply memory sections to the subsystem data, overriding any model-level specification.Apply one of the model memory sections to the subsystem.
Tips
The memory section that you specify applies to the corresponding global data structures in the generated code. For basic information about the global data structures generated for atomic subsystems, see Standard Data Structures (Simulink Coder).
The possible values vary depending on what, if any, package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder).
If you have not configured the model with a package,
Inherit from model
is the only available value. Otherwise, the list includesDefault
and all memory sections the model package contains.These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).
Dependencies
This parameter requires an Embedded Coder license and an ERT-based system target file.
To enable this parameter, set Function packaging to
Nonreusable function
and select the Function with separate data parameter.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWMemSecDataInternal |
Values: | 'Inherit from model' (default) | 'Default' | model memory section in quotes |
Memory section for parameters — How to apply memory sections
Inherit from model
(default) | Default
| model memory section
Select how the software applies memory sections to the subsystem parameters.
Inherit from model
— Apply the root model memory sections to the subsystem function code.Default
— Do not apply memory sections to the subsystem system code, overriding any model-level specification.Apply one of the model memory sections to the subsystem.
Tips
The memory section that you specify applies to the corresponding global data structure in the generated code. For basic information about the global data structures generated for atomic subsystems, see Standard Data Structures (Simulink Coder).
The possible values vary depending on what, if any, package of memory sections you have set for the model configuration. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder).
If you have not configured the model with a package,
Inherit from model
is the only available value. Otherwise, the list includesDefault
and all memory sections the model package contains.These options can be useful for overriding the model memory section settings for the given subsystem. For details on how to apply memory sections to atomic subsystems, see Override Default Memory Placement for Subsystem Functions and Data (Embedded Coder).
Dependencies
This parameter requires an Embedded Coder license and an ERT-based system target file.
To enable this parameter, set Function packaging to
Nonreusable function
and select the Function with separate data parameter.
Programmatic Use
To set the block parameter value programmatically, use
the set_param
function.
Parameter: | RTWMemSecDataParameters |
Values: | 'Inherit from model' (default) | 'Default' | model memory section in quotes |
Block Characteristics
Data Types |
|
Direct Feedthrough |
|
Multidimensional Signals |
|
Variable-Size Signals |
|
Zero-Crossing Detection |
|
Tips
To improve performance, consider setting the Measure function execution times (Embedded Coder) configuration parameter to
Coarse (referenced models and subsystems only)
when you run software-in-the-loop (SIL) or processor-in-the-loop (PIL) profiling on a model that contains a Neighborhood Processing Subsystem block. Neighborhood Processing Subsystem blocks process large amounts of data, which can cause poor performance when you use theDetailed (all function call sites)
option. For more information, see Create Execution-Time Profile for Generated Code (Embedded Coder).Switch blocks are useful in Neighborhood Processing Subsystem blocks for image processing tasks such as thresholding. Thresholding can convert an image to black and white by converting every pixel value to
255
or0
, depending on whether the input pixel value is greater than a given threshold value. For example, this Neighborhood Processing Subsystem block performs thresholding by using a Switch block with a threshold value of110
.To perform thresholding in normal simulation mode, consider using a Relational Operator block that uses the
>
operator to recreate the Switch block behavior.The Relational Operator block returns a value of
1
if the input value is greater than the threshold and otherwise returns0
. By sending this value to a Gain block with a value of255
, the subsystem returns255
or0
.
Extended Capabilities
C/C++ Code Generation
Generate C and C++ code using Simulink® Coder™.
You can generate Halide code if you have Embedded Coder license. For more information, see Speed Up Generated Code Execution with Halide Code (Embedded Coder).
HDL Code Generation
Generate VHDL, Verilog and SystemVerilog code for FPGA and ASIC designs using HDL Coder™.
HDL Coder™ provides additional configuration options that affect HDL implementation and synthesized logic.
Architecture | Description |
---|---|
Module (default) | Generate code for the subsystem and the blocks within the subsystem. |
BlackBox | Generate a black box interface. The generated HDL code includes only the input/output port definitions for the subsystem. Therefore, you can use a subsystem in your model to generate an interface to existing, manually written HDL code. The black-box interface generation for subsystems is similar to the Model block interface generation without the clock signals. |
| Remove the subsystem from the generated code. You can use the subsystem in simulation, however, treat it as a “no-op” in the HDL code. |
For the BlackBox
architecture, you
can customize port names and set attributes of the external component
interface. See Customize Black Box or HDL Cosimulation Interface (HDL Coder).
General | |
---|---|
AdaptivePipelining | Automatic pipeline insertion based on the synthesis tool, target frequency, and
multiplier word-lengths. The default is |
ClockRatePipelining | Insert pipeline registers at a faster clock rate instead of the slower data rate. The
default is |
ConstrainedOutputPipeline | Number of registers to place at
the outputs by moving existing delays within your design. Distributed
pipelining does not redistribute these registers. The default is
|
DistributedPipelining | Pipeline register distribution,
or register retiming. The default is |
DSPStyle | Synthesis attributes for multiplier mapping. The default is |
FlattenHierarchy | Remove subsystem hierarchy from generated HDL code. The default
is |
InputPipeline | Number of input pipeline stages
to insert in the generated code. Distributed pipelining and constrained
output pipelining can move these registers. The default is
|
OutputPipeline | Number of output pipeline stages
to insert in the generated code. Distributed pipelining and constrained
output pipelining can move these registers. The default is
|
SharingFactor | Number of functionally equivalent resources to map to a single shared resource. The default is 0. See also Resource Sharing (HDL Coder). |
StreamingFactor | Number of parallel data paths, or vectors, that are time multiplexed to transform into serial, scalar data paths. The default is 0, which implements fully parallel data paths. See also Streaming (HDL Coder). |
If this block is not the DUT, the block property settings in the Target
Specification tab are ignored. In the HDL Workflow Advisor, if you use the
IP Core Generation workflow, these target specification block
property values are saved with the model. If you specify these target specification block
property values using hdlset_param
, when you open HDL Workflow Advisor,
the fields are populated with the corresponding values.
Target Specification | |
---|---|
AdditionalTargetInterfaces |
Additional target interfaces, specified as a character vector. To save this block property on the model, in the Set Target Interface task of the IP Core Generation workflow, corresponding to the DUT ports that you want to add more interfaces, select Add more.... You can then add more interfaces in the Add New Target Interfaces dialog box. Specify the type of interface, number of additional interfaces, and a unique name for each additional interface. Values: Example:
|
ProcessorFPGASynchronization | Processor/FPGA synchronization mode, specified as a character vector. To save this block property on the model, specify the Processor/FPGA Synchronization in the Set Target Interface task of the IP Core Generation workflow. Values: Example: |
TestPointMapping | To save this block property on the model, specify the mapping of test point ports to target platform interfaces in the Set Target Interface task of the IP Core Generation workflow. Values: Example: |
TunableParameterMapping | To save this block property on the model, specify the mapping of tunable parameter ports to target platform interfaces in the Set Target Interface task of the IP Core Generation workflow. Values: Example: |
AXI4RegisterReadback | To save this block property on the model, specify whether you want to enable readback on AXI4 subordinate write registers in the Generate RTL Code and IP Core task of the IP Core Generation workflow. To learn more, see Model Design for AXI4 Slave Interface Generation (HDL Coder). Values: |
AXI4SlaveIDWidth |
To save this block property on the model, specify the number of AXI manager interfaces that you want to connect the DUT IP core to by using the AXI4 Slave ID Width setting in the Generate RTL Code and IP Core task of the IP Core Generation workflow. To learn more, see Define Multiple AXI Master Interfaces in Reference Designs to Access DUT AXI4 Slave Interface (HDL Coder). Values: |
RegisterInterfaceReadPipeline |
To save this block property on the model, Specify the number of pipeline stages to insert in the read address decoder path by using the Register interface read pipeline setting in the Generate RTL Code and IP Core task of the IP Core Generation workflow. To learn more, see Model Design for AXI4 Slave Interface Generation (HDL Coder). Values: |
GenerateDefaultAXI4Slave | To save this block property on the model, specify whether you want to disable generation of default AXI4 subordinate interfaces in the Generate RTL Code and IP Core task of the IP Core Generation workflow. Values: |
IPCoreAdditionalFiles | Verilog®, SystemVerilog, or VHDL® files for black boxes in your design. Specify the full path to each file, and separate file names with a semicolon (;). You can set this property in the HDL Workflow Advisor, in the Additional source files field. Values: Example: |
IPCoreName | IP core name, specified as a character vector. You can set this property in the HDL Workflow Advisor, in the IP core name field. If this property is set to the default value, the HDL Workflow Advisor constructs the IP core name based on the name of the DUT. Values: Example: |
IPCoreVersion | IP core version number, specified as a character vector. You can set this property in the HDL Workflow Advisor, in the IP core version field. If this property is set to the default value, the HDL Workflow Advisor sets the IP core version. Values: Example: |
IPDataCaptureBufferSize |
FPGA Data Capture buffer size, specified as a character vector. Use FPGA Data Capture to observe signals in a design when running on an FPGA. The buffer size uses values that are 128*2^n, where n is an integer. By default, the buffer size is 128 (n=0). The maximum value of n is 13, which means that the maximum value for buffer size is 1048576 (=128*2^13). Values: Example: |
If your DUT is a masked subsystem, you can generate code only if it is at the top level of the model.
For more information, see:
External Component Interfaces (HDL Coder)
Generate Black Box Interface for Subsystem (HDL Coder)
Version History
Introduced in R2022b
MATLAB Command
You clicked a link that corresponds to this MATLAB command:
Run the command by entering it in the MATLAB Command Window. Web browsers do not support MATLAB commands.
Select a Web Site
Choose a web site to get translated content where available and see local events and offers. Based on your location, we recommend that you select: .
You can also select a web site from the following list:
How to Get Best Site Performance
Select the China site (in Chinese or English) for best site performance. Other MathWorks country sites are not optimized for visits from your location.
Americas
- América Latina (Español)
- Canada (English)
- United States (English)
Europe
- Belgium (English)
- Denmark (English)
- Deutschland (Deutsch)
- España (Español)
- Finland (English)
- France (Français)
- Ireland (English)
- Italia (Italiano)
- Luxembourg (English)
- Netherlands (English)
- Norway (English)
- Österreich (Deutsch)
- Portugal (English)
- Sweden (English)
- Switzerland
- United Kingdom (English)