Store 
| Products & Services | Solutions | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → Real-Time Workshop |
| Products & Services | Solutions | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → Real-Time Workshop |
| Contents | Index |
| Learn more about Real-Time Workshop |
With respect to Real-Time Workshop 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 Real-Time Workshop 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 Real-Time Workshop 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 Real-Time Workshop 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 appropriate 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 Real-Time Workshop 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 Real-Time Workshop® 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 Real-Time Workshop 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 | |
Real-Time Workshop | Makefile specific to your model that is derived from the template makefile | |
Real-Time Workshop | Intermediate compilation (model.rtw) of a .mdl file used in generating C or C++ code | |
The MathWorks and Real-Time Workshop users | Target Language Compiler script files that the Real-Time Workshop build process uses to generate code for targets and blocks | |
Supplied with Real-Time Workshop | Template makefiles | |
Real-Time Workshop | Project marker file inside a build directory 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 Real-Time Workshop 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 Real-Time Workshop 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 Real-Time Workshop 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 Real-Time Workshop 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 Real-Time Workshop 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 Real-Time Workshop build process for a standard or custom target, specified by a Real-Time Workshop 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 the appropriate 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 M-code. The Real-Time Workshop 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 Real-Time Workshop 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 directory in the working directory. Also an executable library compiled from these codes that implements a Model block. See also Real-Time Workshop 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 Real-Time Workshop 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 Real-Time Workshop 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 appropriate 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 Real-Time Workshop 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-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
