Re: [myhdl-list] intbv return types and a fixed-point Object

[Jan D. <ja...@ja...>]

Felton Christopher wrote:
>>>
>>
>> No, I think it would be straighforward. I expect that everything that
>> works now would continue working, except that you could do some
>> additional things. In particular, you could index and slice an
>> arithmetic expression.
>>
>> The only price would be simulation performance hit. The question is
>> whether this is worthwhile for a feature that is seldom (?) used.
>> Someone would have to analyze this in detail to make a good
>> decision. Perhaps the performance hit is irrelevant - I don't know.
>>
>> Jan
>>
> 
> 
> I took some time to profile this change.  I used the python built-in 
> cProfile.   Below are some numbers (warning lots of stuff below).  The 
> results are a little interesting.  The total time for the math ops 
> (__add__) effectively doubled.  But the overall simulation time 
> increased slightly.  From this limited test case (more needs to be done) 
> I would conclude that having the intbv math ops return and intbv type is 
> little effect on overall simulation performance.
> 
> The change was to the _intbv.py.  All math operations were changed to 
> return a intbv type versus an int type.

Thanks for the work, that really helps.

In your example, the peformance hit is around 7%. Not dramatic perhaps,
but not negligible either.

On the other hand, we would probably get this back easily (and more) if
_intbv.py is redone in C, which may make a lot of sense just like Signal.

I still hesitate. If the reason is purely esthetics, that doesn't seem
enough for the change. But if there is a valid technical reason, I have
nothing against it either. What does the community think?

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com