|
|
|
| R2012a Documentation → Simulink Coder | |
Learn more about Simulink Coder |
|
| Contents | Index |
With respect to Simulink Coder program architecture, these are collections of programs that implement functions carried out by the system-dependent, system-independent, and application components.
Subsystem whose blocks are executed as a unit before moving on. Conditionally executed subsystems are atomic, and atomic subsystems are nonvirtual. Unconditionally executed subsystems are virtual by default, but can be designated as atomic. The Simulink Coder build process can generate reusable code only for nonvirtual subsystems.
Fundamental sample time of a model; in practice, limited by the fastest rate at which a processor's timer can generate interrupts. All sample times must be integer multiples of the base rate.
Global data structure for storing block output signals. The number of block output signals is the sum of the widths of the data output ports of all nonvirtual blocks in your model. By default, Simulink and the Simulink Coder build process try to reduce the size of the model_B structure by reusing the entries in the model_B structure and making other entries local variables.
File that describes how a specific Simulink block is to be transformed to a language such as C, based on the block's description in the Simulink Coder file (model.rtw). Typically, there is one block target file for each Simulink block.
Optimization whereby code generated for identical nonvirtual subsystems is collapsed into one function that is called for each subsystem instance with specified parameters. Code reuse, along with expression folding, can dramatically reduce the amount of generated code.
Set of attributes for a model which defines parameters governing how a model simulates and generates code. A model can have one or more such configuration sets, and users can switch between them to change code generation targets or to modify the behavior of models in other ways.
Named element of a configuration set. Configuration components encapsulate settings associated with the Solver, Data Import/Export, Optimization, Diagnostics, Hardware Implementation, Model Referencing, and Code Generation panes in the Configuration Parameters dialog box. A component may contain subcomponents.
Target configuration that generates model code for execution on an independent embedded real-time system. Requires a Embedded Coder™ license.
Code optimization technique that minimizes the computation of intermediate results at block outputs and the storage of such results in temporary buffers or variables. It can dramatically improve the efficiency of generated code, achieving results that compare favorably with hand-optimized code.
The table below lists the Simulink, Target Language Compiler, and Simulink Coder file extensions.
Extension | Created by | Description |
|---|---|---|
Target Language Compiler | The generated C or C++ code | |
Target Language Compiler | C/C++ include header file used by the .c or .cpp program | |
Simulink | Contains structures associated with Simulink block diagrams | |
Simulink Coder | Makefile specific to your model that is derived from the template makefile | |
Simulink Coder | Intermediate compilation (model.rtw) of a .mdl file used in generating C or C++ code | |
MathWorks and Simulink Coder users | Target Language Compiler script files that the Simulink Coder build process uses to generate code for targets and blocks | |
Supplied with Simulink Coder | Template makefiles | |
Simulink Coder | Project marker file inside a build folder that identifies the date and product version of generated code |
Target configuration that generates model code for a real-time system, with the resulting code executed on your workstation. (Execution is not tied to a real-time clock.) You can use GRT as a starting point for targeting custom hardware.
Computer system on which you create and may compile your real-time application. Also referred to as emulation hardware.
Generally, this means to place something directly in the generated source code. You can inline parameters and S-functions using the Simulink Coder software and the Target Language Compiler.
(Target Language Compiler Boolean global variable: InlineParameters) The numerical values of the block parameters are hard-coded into the generated code. Advantages include faster execution and less memory use, but you lose the ability to change the block parameter values at run time.
An S-function can be inlined into the generated code by implementing it as a .tlc file. The code for this S-function is placed in the generated model code itself. In contrast, noninlined S-functions require a function call to an S-function residing in an external MEX-file.
Piece of code that your processor executes when an external event, such as a timer, occurs.
(Target Language Compiler global variable: RollThreshold) Depending on the block's operation and the width of the input/output ports, the generated code uses a for statement (rolled code) instead of repeating identical lines of code (flat code) over the signal width.
Utility to maintain, update, and regenerate related programs and files. The commands to be executed are placed in a makefile.
Files that contain a collection of commands that allow groups of programs, object files, libraries, and so on, to interact. Makefiles are executed by your development system's make utility.
Intermediate record file into which the Simulink Coder build process compiles the blocks, signals, states, and parameters a model, which the Target Language Compiler reads to generate code to represent the model.
Process by which a microprocessor schedules the handling of multiple tasks. In generated code, the number of tasks is equal to the number of sample times in your model. See also pseudo multitasking.
In the context of the Simulink Coder build process, this is any C MEX S-function that is not implemented using a customized .tlc file. If you create a C MEX S-function as part of a Simulink model, it is by default noninlined unless you write your own .tlc file that inlines it.
Simulation environment of a block diagram provided for high-speed simulation of your model. Execution is not tied to a real-time clock.
Any block that performs some algorithm, such as a Gain block. The Simulink Coder build process generates code for all nonvirtual blocks, either inline or as separate functions and files, as directed by users.
On processors that do not offer multitasking support, you can perform pseudo multitasking by scheduling events on a fixed time sharing basis.
The Simulink Coder build process encapsulates information about the root model in the real-time model data structure, often abbreviated as rtM. rtM contains global information related to timing, solvers, and logging, and model data such as inputs, outputs, states, and parameters.
Computer that processes real-world events as they happen, under the constraint of a real-time clock, and that can implement algorithms in dedicated hardware. Examples include mobile telephones, test and measurement devices, and avionic and automotive control systems.
Set of code files generated by the Simulink Coder build process for a standard or custom target, specified by a Simulink Coder configuration component. These source files can be built into an executable program that will run independently of Simulink. See also simulation target, configuration.
Wrapper around the generated code that can be built into a stand-alone executable. The run-time interface consists of routines to move the time forward, save logged variables at specified time steps, and so on. The run-time interface is responsible for managing the execution of the real-time program created from your Simulink block diagram.
Customized Simulink block written in C, Fortran, or MATLAB® code. The Simulink Coder build process can target C code S-functions as is or users can inline C code S-functions by preparing TLC scripts for them.
Simulink data structure and associated application program interface (API) that enables S-functions to communicate with other entities in models. Simstructs are included in code generated by the Simulink Coder build process for noninlined S-functions.
Set of code files generated for a model which is referenced by a Model block. Simulation target code is generated into /slprj/sim project folder in the working folder. Also an executable library compiled from these codes that implements a Model block. See also Simulink Coder target.
Mode in which a model runs in one task, regardless of the number of sample rates it contains.
Property of a problem that forces a numerical method, in one or more intervals of integration, to use a step length that is excessively small in relation to the smoothness of the exact solution in that interval.
Entry point to the Target Language Compiler program, used to transform the Simulink Coder file into target-specific code.
File that is compiled and executed by the Target Language Compiler. The block and system target TLC files used specify how to transform the Simulink Coder file (model.rtw) into target-specific code.
Program that compiles and executes system and target files by translating a model.rtw file into a target language by means of TLC scripts and template makefiles.
One or more TLC script files that describe how to convert a model.rtw file into generated code. There is one TLC file for the target, plus one for each built-in block. Users can provide their own TLC files to inline S-functions or to wrap existing user code.
Specific or generic computer system on which your real-time application is intended to execute. Also referred to as embedded hardware.
Process of creating software modules for execution on your target system.
In generated code, each sample rate in a multirate model is assigned a task identifier (tid). The tid is used by the model output and update routines to control the portion of your model that should execute at a given time step. Single-rate systems ignore the tid. See also base sample rate.
Line-for-line makefile used by a make utility. The Simulink Coder build process converts the template makefile to a makefile by copying the contents of the template makefile (usually system.tmf) to a makefile (usually system.mk) replacing tokens describing your model's configuration.
Connection or graphical block, for example a Mux block, that has no algorithmic functionality. Virtual blocks incur no real-time overhead as no code is generated for them.
Data structures for saving internal states or similar information, accessible to blocks that may require such work areas. These include state work (rtDWork), real work (rtRWork), integer work (rtIWork), and pointer work (rtPWork) structures. For example, the Memory block uses a real work element for each signal.
 | Product Limitations Summary | Function Reference |  |
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 |
