Re: [myhdl-list] fixed-point thoughts : part one

[Martin S. <ha...@se...>]

Hi Chris,

I'd like to see 'fixbv' as a sophisticated standard inside MyHDL. I
presume many people are cooking their own soup (including me).

A few things are still unclear to me though, in particular WRT rounding
options and conversion to synthesizable code. I wouldn't want to
anticipate too much from your announced "part 2" of the proposal, but
let me throw in a few comments/questions anyhow:

1. I'd personally prefer the strict bit definition for the initializer.
   Why not just allow
     a = fixbv("si.ffffff")
   Might only make an automated width generation a little quirky, but so
far I always stuck to a fixed bit size.

2. Internally, for example a typical DSP like multiplication of two 1.15
values would yield a 2.30, and the accumulator depth would be kinda up
to the expected value range of the algo. Slicing to an output format
seems kinda straightforward, I guess a conversion function (including
standard rounding options) could come in handy, but apart from that, are
there any thoughts on how such an assignment and rounding is translated
into VHDL/Verilog? Or would you leave the rounding to the user (via his
own rounding convertors)?

3. I guess a fixbv should make handling easier for beginners. But for a
standard rounding option set, quite some documentation needs to be made
(and read). I am a bit unsure, where the effort would be paying off.
Eventually, one needs to dig into the hard matter on the bit level when
it comes to minimize 'binarithmetic' noise, etc.
Maybe it's best to not discuss it too much and just implement a solution
that works well for a standard filter bank.

Just as example, I had been following the concept of a well documented
DSP (the Blackin). See
http://www.analog.com/static/imported-files/processor_manuals/Blackfin_pgr_rev2.2.pdf,
in particular the MAC command section with all the rounding options.

Assuming the fixbv is simply a derived intbv, I guess it's just a matter
of discussing what other exceptions than overflow would make sense (like
rounding issues) in order to help with tracking down numerical
weaknesses (unstable IIRs...).

Cheers,

- Martin