[Fixed-point converter] Passing constant struct to entry point

I have passed a constant struct to the input of MATLAB HDL Coder.Lets say param.a = 'red'

In the code, it is responsible for choosing a certain code path:

if param.a == 'red'
    % do HDL Coder supported stuff
else
    % do only MATLAB supported stuff
    linspace(foo);
    % etc. etc.
end

However the fixed-point converter still wants me to define a replacement function for linspace, even if it is not in the active code path. Somehow it does not understand, that param is constant.

As this thread suggests, I tried defining param as coder.Constant input, which did not help and I also used a System Object to wrap the code and put param in the nontunable properties

properties (Nontunable)
    param
end

,to explicitly tell the fixed-point converter that param is constant, which is replied by

Property 'param' of class 'ExampleClass' is a structure type. Classes with structure properties are not supported.

Is there any possibility to let also the fixed-point converter know, that param is indeed compile time constant?

Then the feature of excluding unused paths of the coder should work for this scenario.

Answer 1

[Kiran Kintali]

I have used coder.Const as shown in the example mlhdlc_tutorial_image_hdr.m on the first option.

exArgs = {int16(1), int16(100),coder.Constant(struct('hdl', true))};
fc = coder.config('fixpt');
fc.TestBenchName = 'dut_tb';
hc = coder.config('hdl');
codegen -float2fixed fc -config hc -args exArgs dut

I was able to generate fixed-point code and HDL code with the command.

>> runme
===================================================
Design Name: dut
Test Bench Name: dut_tb
===================================================


============= Step1: Analyze floating-point code ==============


============= Step1a: Verify Floating Point ==============

### Analyzing the design 'dut'
### Analyzing the test bench(es) 'dut_tb'
### Begin Floating Point Simulation (Instrumented)
### Floating Point Simulation Completed in   1.1713 sec(s)
### Elapsed Time:             1.6844 sec(s)

============= Step2: Propose Types based on Range Information ==============


============= Step3: Generate Fixed Point Code ==============

### Generating Fixed Point MATLAB Code dut_fixpt using Proposed Types
### Generating Fixed Point MATLAB Design Wrapper dut_wrapper_fixpt
### Generating messages during fixed-point conversion: dut_fixpt_log.txt
### Generating Mex file for ' dut_wrapper_fixpt '
Code generation successful: View report
Warning: Function 'linspace' not supported for fixed-point conversion. 
Warning: The expression 'tmp = linspace(a,b);' was not executed during simulation. Consider using
a more thorough testbench. 
Warning: The expression 'out = a + tmp(50);' was not executed during simulation. Consider using a
more thorough testbench. 
Found some unsupported constructs during float to fixed point conversion. Please see the above error messages for details.
### Generating Type Proposal Report for 'dut' dut_report.html

===================================================

### Begin VHDL Code Generation
### Generating HDL Conformance Report dut_fixpt_hdl_conformance_report.html.
### HDL Conformance check complete with 0 errors, 0 warnings, and 0 messages.
### Working on dut_fixpt as dut_fixpt.vhd.
### Generating Resource Utilization Report resource_report.html.
>> 

[Jan Siegmund]

The real problem arose because the GUI of the fixed point converter was still complaining about functions being in the non-executed path:

it states

Replacement is required to use fixed-point.

So I thought I could not continue until these functions would have all been replaced, even if they are in unexecuted or constant paths.

I think this could need a fix. The "Function Replacements" tab should just list functions, which actually need to be replaced, not the ones in constant and unexecuted paths.

Answer 2

[Kiran Kintali]

please share dut.m and dut_tb.m with the sample code and data types. if you have project or input types to compile the code it would be benificial to debug the fixed-point issue. Thanks

[Jan Siegmund]

Here you go:

dut_tb.m

param.hdl = true;
dut(1, 100, param);

First option

Inputs:

dut.m

function [out] = dut(a, b, param)
    if param.hdl
        out = a + b;
    else
        tmp = linspace(a,b);
        out = a + tmp(50);
    end
end

Second option

dut.m

function [out] = dut(a, b, param)
    %using a System object here for its nontunable properties
    persistent system;
           
    if isempty(system) 
        system = dutSystem(b, param);
    end
           
    out = system.step(a);
end

dutSystem.m

classdef dutSystem < matlab.System
    properties (Nontunable)
        param
    end
    
    properties
        b
    end
    
    methods (Access = public)
        function obj = dutSystem(b, param)
            obj.b = b;
            obj.param = param;
        end
    end
        
    methods (Access = protected)
        function out = stepImpl(obj, a)
            if obj.param.hdl
                out = a + obj.b;
            else
                tmp = linspace(a,obj.b);
                out = a + tmp(50);
            end
        end        
    end                 
end

[Jan Siegmund]

As already said, in the first option i have to define linspace in fixed-point converter, even though param is constant and linspace will never be in th executed code path.

The second option already fails at the coder stage with

Property 'param' of class 'dutSystem' is a structure type. Classes with structure properties are not supported.