Hello. I have an issue related with the precission loss.

My goal is to generate c code from a Simulink model. I have a mpt.parameter with a value equal to 3.3 and with data type fixdt(0,16,2^-6,0). This signal is used as a constat in Simulink, But when I try to compile I get "Precision loss occurred for Value (3.3) of Simulink.Parameter object "xxxxx". The value cannot be represented exactly using the run-time data type 'ufix16_En6'. A small quantization error has occurred. To disable this warning or error, in the Configuration Parameters > Diagnostics > Data Validity pane, set the 'Detect precision loss' option in the Parameters group to 'none'."

Solution tried so far: 1. I've hacked the value directly in Simulink. Simulation works but I can not generate code due to an error related to float numbers. 2. I've selected "detect precision loss" from config. param. to none. It works and I was able to generate code but I'm worried about this because I also get a warning "Warning: The data type "ufix48_En6" uses a word size that is not available on the intended target. Fixed-point signals using this data type will be put inside a larger word or multi words. When used, extra software will be generated to force this larger word or multi words to emulate a smaller word. This emulation is helpful when your prototype target and your final production target are not the same. If the smaller word size does NOT exist on the final production target, then consider increasing the word size to one that is supported."

Answer 1

[Andy Bartlett]

I realized this is an old question, but I see there are multiple recent views, so providing a very late answer :-( is still likely to have some value.

When working with fixed-point parameters or even single precision floating point parameters, precision loss will be extremely common unless you are only dealing with a special set of of values such as modest sized integers.

Given that, I generally recommend setting Configuration Parameters > Diagnostics > Data Validity pane > 'Detect precision loss' option to 'none'

There is a new capability as of R2016b to suppress individual warnings that you've reviewed and determine to be benign. When reviewing a warning in the Diagnostic Viewer, you'll see a "button" you can click to permanently suppress warnings you've evaluated to be benign. That specific warning for that particular item will not show up in future simulations, etc.

This begs the question how do you review if a precision loss is OK. As the expert on the application your solving, you'll need to judge what is acceptable precision for your system. I'll show code below that will allow you to gather some metric that can assist with that judgment.

Note: one of the metrics shown below is bits of error. How big a bit is depends on the data type used of the parameter. If the data type is an integer then, a bit has real world value 1. If the data type has fraction length 3, then a bit has real world value 2^-(3) = 0.125 If the data type has fraction length -5, then a bit has real world value 2^-(-5) = 32 Unless the original parameter value is beyond the representable range of the data type, the quantization will always be 1/2 bit or less. But, keep in mind, that half a bit of error may be "huge" or "tiny" real world value depending on the data type used.

------------------------------ Example code ------------------------------ origDoubleValue = 3.3

dataType = fixdt(0,16,2^-6,0) dataTypeAltEntry = fixdt('ufix16_En6')

quantizedParam = fi(3.3,dataTypeAltEntry) quantizedParam.Value

% metrics quantError = double(quantizedParam) - origDoubleValue quantErrorBits = quantError / dataType.Slope relativeQuantError = quantError / origDoubleValue

--------------------------------- Example output --------------------------------- origDoubleValue = 3.3000 dataType = NumericType with properties:

    DataTypeMode: 'Fixed-point: slope and bias scaling'
      Signedness: 'Unsigned'
      WordLength: 16
           Slope: 0.0156
            Bias: 0
         IsAlias: 0
       DataScope: 'Auto'
      HeaderFile: ''
     Description: ''
dataTypeAltEntry = 
  NumericType with properties:

      DataTypeMode: 'Fixed-point: binary point scaling'
        Signedness: 'Unsigned'
        WordLength: 16
    FractionLength: 6
           IsAlias: 0
         DataScope: 'Auto'
        HeaderFile: ''
       Description: ''
quantizedParam = 
    3.2969

          DataTypeMode: Fixed-point: binary point scaling
            Signedness: Unsigned
            WordLength: 16
        FractionLength: 6
ans =
    '3.296875'
quantError =
   -0.0031
quantErrorBits =
   -0.2000
relativeQuantError =
  -9.4697e-04

Answer 2

[Andy Bartlett]

The code generation warning about using emulated types is not directly related to the primary question about parameter precision loss.

A key reason to use fixed-point is to achieve highly efficient implementations. The purpose of that warning is to make you aware that you have an opportunity to make the generated code more efficient. The warning is effectively saying the generated code is doing extra work to make a native integer type (probably 64 bits in this case) waddle and quack like a 48 bit type. It's all numerically correct and gives bit true agreement with simulation, but there is an efficiency cost. The the warning is suggesting to jump from 48 bits up to a target native integer size. Assuming 64 bits is a target native size, you would change the 48 bit type to 64 bits and stick the extra 16 bits on the range end or precision end or some mixture. This should give "richer" numerics and more efficient generated code. Win-win