Re: [myhdl-list] fxintbv dependency on dspsim

[Jan L. <jan...@et...>]

Hello Christopher,

Am 10.12.2009 um 03:57 schrieb Christopher L. Felton:
> Jan Langer wrote:
>> Somehow, I dont really understand it. The return type of the  
>> fxintbv operators is just plain intbv, so I cannot write a - b*c  
>> for three fxintbv variables. If fxintbv does not take care of the  
>> point in operations and I need to remember and adjust it by hand, I  
>> dont see the advantages of fxintbv. fxint seems to do what I need,  
>> except the two questions I wrote yesterday. I am a little confused  
>> but maybe I just want the wrong things :-)
>>
> Correct, with the fxintbv a little more work needs to be done.  But  
> not as much as doing it all manually.  Keeping within the design  
> goals of MyHDL nothing will try to evaluate the expression x= a-b*c  
> and adjust the result.  But given the design of MyHDL and the  
> elaborate phase there are some options.  The fxintbv doesn't do the  
> auto promotion (adjusting the number of bits for the word) but there  
> are helper functions to determine the size of the word based on the  
> operations.
> These helper functions/methods help during design and analysis but  
> also can make the modules modular.  If an input size is adjusted the  
> module will automatically adjust.   The example in the  PDF (ooppps,  
> just notice didn't include everything in the PDF, my bad) or the  
> example in examples/sos/sos_hdl.py there is a function that gets the  
> types needed.  The function uses the fxintbv methods to determine  
> this.  This essentially auto-promotes.
>
> def getFxTypes(Q,N):
>   # Different fixed-point types (sizes) used
>   fx_t    = fxintbv(0, min=-1, max=1, res=2**-Q)
>   fxmul_t = fx_t.ProductRep(fx_t)
>   fxsum_t = fxmul_t.SummationRep(N)
>
>   return fx_t, fxmul_t, fxsum_t
>
> Right now there are a bunch of public functions to assist in auto- 
> promotion and alignment.  The ProductRep, AdditionRep, SummationRep  
> will determine the correct "type" given the inputs.   For the  
> specific example x = a-b*c something like the following could be done
>
> def fxCalc(clk, x, a, b, c):
>     i_t  = fxintbv.ProductRep(b,c)
>   x_t  = fxintbv.AdditionRep(a, i_t)
>   x.NewRep(x_t.iwl, x_t.fwl)
>
>   @always(clk.posedge)
>   def rtl_result():
>       x.next = a-b*c
>
>  return instances()
>
> In this scenario all the promotion and alignment etc will be  
> handled.  "x" will be adjusted in the elaboration phase based on the  
> a,b,c inputs.  It assumes that x, a, b, c are all of type fxintbv.   
> The benefit of doing this is you will get the auto promotion of "x"  
> when the inputs change and you get some additional functions for  
> fixed point analysis.  I think this is a good balance between design  
> flexibility and automation.  The fxint does a lot more under the  
> hood (auto promotion, bit alignment) but it is not convertible.  I  
> don't think it makes sense for something like fxint to be  
> convertible.  You want a little more control when mapping to  
> hardware.  I think the fxintbv has the balance between right amount  
> of abstraction and design guidance.

Okay, I understand how its done. I will try it later. But I can't  
follow your argumentation that something like fxint should not be  
convertible. In my opinion, there is no semantic difference between  
the above code, which explicitly promotes the type, and implicit auto- 
promotion. The manual promotion will be used as a pattern and I dont  
see any additional control of the mapping process. I mean if there is  
a fixed and documented definition like

a.b + c.d -> (max(a,c)+1).max(b,d)
a.b * c.d -> (a+c).(b+d)

a mapping is easy to understand.

I see that current myhdl might not be able to support a convertible  
auto-promotable fxint type, but somehow I think that would be  
desirable. :-)
Jan

-- 
Jan Langer
(Telefon) +49-371-531-33158 / (PGP) F1B8C1CC
Schaltkreis- und Systementwurf / TU Chemnitz