Re: [myhdl-list] fxintbv dependency on dspsim

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

Jan Langer wrote:
> 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
>
It would require changes to the base MyHDL to evaluate the expressions 
and generate the code.  I think this would be a fairly large project.  
MyHDL, for the most part, isn't that active in the conversion.  There is 
a one to one mapping of expressions to the converted code. 

Arbitrarily complex expressions would have to handled.  Things like 
having a "summation" embedded in a expression changes the rules that you 
might want to apply.  The expression has to be decomposed such that it 
would be an optimal synthesis of the expression.  Example If you a take 
an expression like
(a + b + c) * d
You can apply the basic rules but if a,b and c are the same type (same 
number bits and point alignment) more bits will be assigned to the 
result than needed.  In general the addition result will require another 
bit but a summation (multiple additions same type) only requires log2(N) 
bits, where N is the number of additions.  This is a general rule as 
well but it requires more advanced parsing of the expressions which 
would have to be built into MyHDL.   Not saying it cannot be done, just 
would take more effort than I would currently have time for.

At this point I don't think it is something that should be built into 
the MyHDL language.  The fxint and fxintbv are simple libraries/objects 
that can be used with MyHDL.  What might be possible in the future (time 
is the limiting resource) is that MyHDL can be modified slightly so that 
"plugins" can be added.  When an expression is evaluate and unknown 
(non-convertible) types are present it can search for a plugin with 
rules to guide the conversion.  This way the base language doesn't 
explode with all kinds features but something like you suggestion can be 
added.  Some serious thought would have to be given to such an 
endeavor.  It is more complicated that single expressions, could apply 
to blocks of expressions (like loops).  And it would be changing the 
types on the fly, might require a two-pass approach.  It would be a nice 
feature and a fun project but currently not feasible.

.chris