type computation

Tue Aug 10, 2010 1:26 pm   

Hi,

I'm porting a fixed point simulink (SL) model to vhdl. The SL type is
fixdt(..., WORDLENGTH, FRACLENGTH) where sfixed does have a different
notation.

For convience I wrote a VHDL function to convert the type in a package:

package body ...

function fixdt_to_sfixed(
constant WordLength : integer;
constant FractionLength : integer)
return UNRESOLVED_sfixed
is
constant left : integer := WordLength - FractionLength - 1;
constant right : integer := -FractionLength;
variable result : UNRESOLVED_sfixed(left downto right);
begin
return result;
end;

end ...

to avoid type computations ans signal like:

architecture ....
constant COEFFICIENT_LEFT : integer := COEFFICIENT_WORDLENGTH -
COEFFICIENT_FRACTIONLENGTH - 1;
constant COEFFICIENT_RIGHT : integer := -COEFFICIENT_FRACTIONLENGTH;
subtype coeefficient_type is sfixed(COEFFICIENT_LEFT downto
COEFFICIENT_RIGHT);


constant COEEFFICIENT_SIZER : coeefficient_type := (others => '0');

signal b0_coeff_s : coeefficient_type;

begin
b0_coeff_s <= to_sfixed( input_b0, COEEFFICIENT_SIZER);

But this approach won't work:

architecture behave OF df1tsos_tester is

signal coeff_a0 : fixdt_to_sfixed(COEFFICIENT_WORDLENGTH,
COEFFICIENT_FRACTIONLENGTH);

is there such a way? How to?

Thanks,
Olaf

Tue Aug 10, 2010 3:55 pm   

On Aug 10, 8:26 am, Paul <P...@noreply.com> wrote:

You need functions to compute the sfixed array bounds. What you've
shown is declaring a signal that is of a type computed by a
function...which is illegal. Once you get your two functions, the
signal declarations will be something like this...

signal coeff_a0 : sfixed(fixdt_to_sfixed_left(COEFFICIENT_WORDLENGTH,
COEFFICIENT_FRACTIONLENGTH) downto
fixdt_to_sfixed_right(COEFFICIENT_WORDLENGTH,
COEFFICIENT_FRACTIONLENGTH));

KJ

Tue Aug 10, 2010 5:01 pm   

On 10 Aug, 13:26, Paul <P...@noreply.com> wrote:

I am currently in the process of getting simulink algorithms working
in VHDL, and doing a lot of co-simulation.
I think the approach you have may be the wrong way round. When we
started, we looked at the limitations the FPGA was going to impose on
the algorithm, rather than letting simulink run the show completly.
Things like multiplier widths (normally 18 bits) and available memory
at given points. This all fed back and put fixed limits on the word
widths at the start (after some testing was done on the algorithm to
ensure it didnt degrade performance).

So I have a "setup package" that defines all of the word widths
throughout the algorithm via sub types. I have the following:

subtype filter_word_t is sfixed(11 downto -4); --16 bits because the
memories are 18 bits and we need to store a couple of status bits with
each word
subtype coeff_t is sfixed(1 downto -16); --18 bit multiplers.

then you can start doing all the stuff VHDL is good for:

type coeff_array_t is array(-1 to 1, -1 to 1) of coeff_t;
type filter_array_t is array(natural range <>) of coeff_array_t; --
Will co-simulation support 3+D arrays any time soon?

The good thing about this is, if we really need to change the widths,
all I need to do is change the setup package manually and the whole
thing still works - make sure you use the 'length/'high/'low
attributes all over the place. Whether it will still fit, and whether
the algorithm guys will understand this is another question!

Mon Aug 16, 2010 6:51 am   

Bitwidth is 16bit due to the DSP48 macro. BTW, why are there 18 bits? I
would expect 17 for overflow calculation.


This is my tb_pkg at this time, the entity is parametrized by this. I
only perform some type/width calculation.

At this time I have the problem that in the TB's tester fixed points
calculations are correct, inside the dut isn't ....

Thanks,
Olaf