| Fixed-Point Blockset | Search Help Desk |
Overview
The Fixed-Point Blockset provides
several fixed-point filter and system realizations. These realizations
are intended to be used as design templates so you can easily see how to
build filters and systems that suit your particular needs. Realizations
are provided for state-space, integrator, derivative, and lead or lag systems. For
each filter or system realization, you can:
Realizations and Data Types
In an ideal world where numbers, calculations,
and storage of states have infinite precision and range, there are virtually
an infinite number of realizations for the same system. In theory, these
realizations are all identical to each other.In the
more realistic world of double-precision numbers, calculations, and storage
of states, small nonlinearities are introduced due to the finite precision
and range of floating-point data types. Therefore, each realization of
a given system will produce different results. In most cases however, these
differences are small.In the world of fixed-point numbers
where precision and range are limited, the differences in the realization
results can be very large. Therefore, you must carefully select the data
type, word size, and scaling for each realization element such that results
are accurately represented. To assist you with this selection, design rules
for modeling dynamic systems with fixed-point math are provided in "Targeting
an Embedded Processor".
Realizations and Scaling
As with all Fixed-Point Blockset models, you must
select a scaling that gives the best precision, range, and performance
for your specific fixed-point design.The scaling for
each filter and system demo is based on the default parameters. If these
parameters are changed (e.g., the magnitude of the input signal is increased),
or if you are creating a new realization, you must define an appropriate
scaling. For each system or filter, the scaling can be adjusted manually
with the dialog box, or automatically as illustrated in "Simulation Results"
in the manual.
Targeting an Embedded Processor
This section describes issues that often arise
in targeting a fixed-point design for use on an embedded processor. Rather
than describe a specific microprocessor (micro) or digital signal processor
(DSP), this section describes some general assumptions about integer sizes
and operations available on embedded processors. These assumptions lead
to design issues and design rules that may be useful for your specific
fixed-point design.
Size Assumptions
Embedded processors are typically characterized
by a particular bit size. For example, the terms "8-bit micro," "32-bit
micro," or "16-bit DSP" are common. It is generally safe to assume that
the processor is predominantly geared to processing integers of the specified
bit size. Integers of the specified bit size are referred to as the base
data type. Additionally, the processor typically provides some support
for integers that are twice as wide as the base data type. Integers consisting
of double bits are referred to as the accumulator data type. For
example a 16-bit micro has a 16-bit base data type and a 32-bit accumulator
data type.Although other data types may be supported
by the embedded processor, this section describes only the base and accumulator
data types.
Operation Assumptions
The embedded processor operations discussed in
this section are limited to the needs of a basic simulation diagram. Basic
simulations use multiplication, addition, subtraction, and delays. Fixed-point
models also need shifts to do scaling conversions. For all these operations,
the embedded processor should have native instructions that allow the base
data type as inputs. For accumulator-type inputs, the processor typically
supports addition, subtraction, and delay (storage/retrieval from memory),
but not multiplication.Multiplication is typically
not supported for accumulator-type inputs due to complexity and size issues.
A difficulty with multiplication is that the output needs to be twice as
big as the inputs for full precision. For example, multiplying two 16-bit
numbers requires a 32-bit output for full precision. The need to handle
the outputs from a multiply operation is one of the reasons embedded processors
include accumulator-type support. However, if multiplication of accumulator-type
inputs is also supported, then there is a need to support a data type that
is twice as big as the accumulator type. To restrict this additional complexity,
multiplication is typically not supported for inputs of the accumulator
type.
Design Rules
The important design rules that you need to be
aware of when modeling dynamic systems with fixed-point math are given
below.
Design Rule 1: Only Multiply Base Data Types
It is best to multiply only inputs of the base
data type. Embedded processors typically provide an instruction for the
multiplication of base-type inputs but not for the multiplication of accumulator-type
inputs. If necessary, a multiplication of accumulator-type inputs could
be handled by combining several instructions. However, this can lead to
large, slow embedded code.Blocks to convert inputs
from the accumulator-type to the base-type can be inserted prior to multiply
or gain blocks if needed.
Design Rule 2: Delays Should Use the Base Data Type
There are two general reasons that a unit delay
should use only base-type numbers. First, the unit delay essentially stores
a variable's value to RAM, and one time step later, retrieves that value
from RAM. Because the value must be in memory from one time step to the
next, the RAM must be exclusively dedicated to the variable and can't be
shared or used for another purpose. Using accumulator-type numbers instead
of the base data type doubles the RAM requirements, which can significantly
increase the cost of the embedded system. The second reason is that the
unit delay typically feeds into a gain block. The multiplication design
rule requires that the input (the unit delay signal) use the base data
type.
Design Rule 3: Temporary Variables Can Use the Accumulator
Data Type
Except for unit delay signals, most signals are
not needed from one time step to the next. This means that the signal values
can be temporarily stored in memory that is shared and reused. This shared
and reused memory can be RAM or it can simply be registers in the CPU.
In either case, storing the value as an accumulator data type is not much
more costly than storing it as a base data type.
Design Rule 4: Summation Can Use the Accumulator Data
Type
Addition and subtraction can use the accumulator
data type if there is justification. The typical justification is reducing
the buildup of errors due to round-off or overflow. For example, a common
filter operation is a weighted sum of several variables. Multiplying a
variable by a weight will naturally produce a product of the accumulator
type. Before summing, each product could be converted back to the base
data type. This approach introduces round-off error into each part of the
sum. Alternatively, the products can be summed using the accumulator data
type, and the final sum can be converted to the base data type. Round-off
error is introduced in just one point and the precision will generally
be better. The cost of doing an addition or subtraction using accumulator-type
numbers is slightly more expensive, but if there is justification, it is
usually worth the cost.