[Fixed Point Converter] 1000 bit fraction length at 2^x if x is loaded from .mat file?

I got a problem with code like this in the fixed-point converter:

dut_tb.m

dut(8);

dut.m

function out = dut(in)
    S = coder.load('constants.mat');
    out = in+2^S.exponent;
end

storeConstants.m

function [] = storeConstants()
    exponent = 8;
    save('constants.mat');
end

convert.m

exArgs = {8};
fc = coder.config('fixpt');
fc.TestBenchName = 'dut_tb';
codegen -float2fixed fc -args exArgs dut

Reproduction steps:

run storeConstants and then convert.

The fixed-point converter automatically uses a fraction length of 1000 for the power of two operation.

As this is just a simple bitshift in hardware, I cannot see the purpose of this high precision. How can

I disable this huge fraction length?

Answer 1

[Jan Siegmund]

A temporary fix is using bitsll as recommended here:

For efficient HDL code generation, use the Fixed-Point Designer functions bitsll, bitsrl, or bitsra instead of bitshift.

So i exchanged

out = in+2^S.exponent;

to

out = in+bitsll(uint8(1),S.exponent);

Uint8 being used, because I want the result to be unsigned, because it needs to be used in a divider.

[Kiran Kintali]

Thank you for the inputs. We will see if we can generate this recommendation during the automatic conversion process in a future release.

Answer 2

[zhang zheng]

i also sometimes find fixedpoint-tool is not easy to understand. i often first convert m-code from float point to fixed point, and then convert them to hdl code or c code.

[Jan Siegmund]

So you mean converting to fixed-point, then editing the bad parts of the fixed-point code by hand and then converting to code?

But this 1000 fraction length only occurs, if the exponent is loaded from a .mat file, so I expect it to be a bug.

[Jan Siegmund]

Ok I got a temporary fix. See my answer for details.