Re: [myhdl-list] arithmetic trouble

[Neal B. <ndb...@gm...>]

Jan Decaluwe wrote:

> Christopher Felton wrote:
>> 
>> 
>>     It works correctly if I break into 2 steps, where I use a tmp
>>     variable of
>>     _the correct bit width_ before shifting.
>> 
>>     Is this a common issue with verilog simulators, or is mine just
>>     broken?
>> 
>>     Should my_hdl try to workaround this?
>> 
>> 
>> 
>> I don't recall the exact rules off the top of my head, either.  But I
>> think this is correct.  The language doesn't presume to know what the
>> intermediate bit representation of the operator is (Verilog language).
>>  If you want full precision for the multiply you have to do it in two
>> steps as you indicated or have your output be the full range.
>> 
>> BOMK everything is working correctly.  What you notice is a simulation
>> mismatch?  The MyHDL simulates fine because the * uses full precision
>> (infinite bits) and the bounds are not checked until the left hand side
>> is assigned and that is after the shift.   Hmmmm, don't know if this
>> would be a bug or not.  Not all aspects are convertible and this would
>> fit that scenario.
> 
> My rule is crystal-clear: if MyHDL code simulates fine and converts fine,
> simulations should match. Otherwise, there is a bug - either in the
> convertor or in the HDL simulator. For this it is not relevant whether
> MyHDL does the "right" thing or not.
> 
> So it looks like we have a bug here and now we have to find out
> what it is. Of course, it may be that something cannot be reliably
> converted, in which case the convertor should issue an error.
> 
> Jan
> 

I suppose (not tested) that using systemverilog cast on the operands before 
the operation to cast to the wider result type would fix it?