Real-Time Workshop Release Notes

Block-level Enhancements

New Rate Transition Block

In previous releases, Zero-Order Hold and Unit Delay blocks were required to handle problems of data integrity and deterministic data transfer between blocks having different sample rates.

The new Rate Transition block lets you handle sample rate transitions in multi-rate applications with greater ease and flexibility than the Zero-Order Hold and Unit Delay blocks.

The Rate Transition block handles both types of rate transitions (fast to slow, and slow to fast). When inserted between two blocks of differing sample rates, the Rate Transition block detects the two rates and automatically configures its input and output sample rates for the appropriate type of transition.

The Rate Transition block supports the following modes of operation:

• Protected/Deterministic: By default, the Rate Transition block operates exactly like a Zero-Order Hold (for fast to slow transitions) or a Unit Delay (for slow to fast transitions), and can replace these blocks in existing models without any change in model performance. (There is one exception: in a transition between a continuous block and a discrete block, a Zero-Order Hold must be used.)

• In its default mode of operation, the Rate Transition block guarantees the integrity of data transfers and guarantees that data transfers are deterministic.

• Protected/Non-Deterministic: In this mode, data integrity is protected by double-buffering data transferred between rates. The blocks downstream from the Rate Transition block always use the latest available data from the block that drives the Rate Transition block. Maximum latency is less than or equal to 1 sample period of the faster task.

• The drawbacks of this mode are its non-deterministic timing and its use of extra memory buffers. The advantage of this mode is its low latency.

• Unprotected/Non-Deterministic: This mode is the least safe, and is not recommended for mission-critical applications. The latency of this mode is the same as for Protected/Non-Deterministic mode, but memory requirements are reduced since there is no double-buffering.

For further information on the use of the Rate Transition block with the Real-Time Workshop, see Models With Multiple Sample Rates in the Real-Time Workshop User's Guide. For information on the use of the Rate Transition block GUI and its use in simulation, see Using Simulink.

S-Function API Extended to Permit Users to Define DWork Properties

The S-Function API has been extended to permit specification of an Real-Time Workshop identifier, storage class, and type qualifier for each DWork that an S-Function creates. The extensions consist of the following macros:

• ssGetDWorkRTWIdentifier(S,idx)
• ssSetDWorkRTWIdentifier(S,idx,val)
• ssGetDWorkRTWStorageClass(S,idx)
• ssSetDWorkRTWStorageClass(S,idx,val)
• ssGetDWorkRTWTypeQualifier(S,idx)
• ssSetDWorkRTWTypeQualifier(S,idx,val)

As is the case with data store memory or discrete block states, the Real-Time Workshop identifier may resolve against a Simulink.Signal object. An example has been added to sfundemos, in the miscellaneous category.

Lookup Table Blocks Use New Run-time Library for Smaller Code

Lookup Table (2-D), Lookup Table (3-D), PreLook-Up Using Index Search, and Interpolation using PreLook-Up blocks now generate C code that targets one of the many new specific, optimized look-up table operations in the Real-Time Workshop run-time library. This results in dramatically smaller code size. The library look-up functions themselves incorporate further enhancements to the actual look-up algorithms for speed improvements for most option settings, especially for linear interpolations.

Relay Block Now Supports Frame-based Processing

Relay blocks can now handle frame-based input signals. Each row in a frame-based input signal is a separate set of samples in frames and each column represents a different signal channel. The block parameters should be scalars or row vectors whose length is equal to the number of signal channels. The block does not allow continuous frame-based input signals.

Transport Delay and Variable Transport Delay Improvements

Code generation for models containing the Transport Delay and Variable Transport Delay is now more space-efficient.

Storage Classes for Data Store Memory Blocks

You can now control how Data Store Memory blocks in your model are stored and represented in the generated code, by assigning storage classes and type qualifiers. You do this in almost exactly the same way you assign storage classes and type qualifiers for block states. You can also associate a Data Store Memory block with a signal object, and control code generation for the block through the signal object.

See Storage Classes for Data Store Memory Blocks in the Real-Time Workshop User's Guide for further information.

Code Generation Configuration Features

Target and Mode Enhancements