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

[Christopher F. <chr...@gm...>]

On 8/28/2013 8:34 AM, Martin Strubel wrote:
> Hi Chris,
>
> I'd like to see 'fixbv' as a sophisticated standard inside MyHDL.

Me too :)

> 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:

Yes, part II I will be discussing operations including
rounding and overflow.

>
> 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.

Definition by properties (min,max,res) or by explicit
bit widths is intended (proposed):

     # construction by properties
     x = fixbv(0,min=-1,max=1,res=2**-15)

     # construction by explicit bit-widths
     x = fixbv(0)[16,0,15]  # form [wl,iwl,fwl]

Although "si.ffff" is readable and explicit I don't
think it is modular enough.

>
> 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)?

Via a "resize" function.  This is similar to other
packages and I think this makes the most sense.  I
will cover this in part II (working out some of the
details).  The "resize" will handle the rounding
and generate the required logic.

     z = resize(x+y,format,
                round_mode='convergent',
                overflow_mode='saturate')

I will get into the details in part II.  Note, in
the above example /x/ and /y/ need to be aligned!

>
> 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.

Similiar to /intbv/, /fixbv/ will provide a useful
building block.  Many of the design issues the user
will still need to deal with (how to analyze SNR, etc).

Many of these high-level tools we can collect as well
but a separate pkg/repo would be a more appropriate home.

>
> 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...).
>

Thanks for the feedback and comments!
Chris