Re: [myhdl-list] arithmetic trouble

[Christopher L. F. <chr...@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?
>
>
>   
I don't think this would be a desired solution, because
  1.  Open-Source simulators (cver and icarus) will not support it.  As 
well as many of the synthesis tools.
  2.  In general, I think the converters try to use the lowest common 
denominator.  Meaning it uses the simplest, straight forward constructs 
of the underlying HDL (converting to).

But the questions can be asked, since the operation is broken into 
intermediate steps, could the converter do this?  Could it automagically 
break a complex operation into multiple steps? To enforce (match) the 
expected results of the MyHDL simulation.  I believe MyHDL (Python) has 
no limit on the intermediate value, the value isn't checked, verified 
till the assignment.  This would have to be implemented or restricted.  
Designers would have to realize large intermediate bit value could exist.

I believe you would have to be careful here though.  You do not want 
complication or too much inference from the converter.  You would want a 
very simple rule for Verilog that could be implemented.  There are many 
scenarios where an intermediate result requires a larger bit-value.  
Basically anytime a complex operation (equation) has an increasing and 
decreasing component you can run into this simulation mismatch.  If we 
prevent the operations we would have to prevent all combinations of 
increasing and decreasing, such as:
  (a + b)  - c
  (a + b)  >> c
  (a * b)  - c
  (a * b)  >> c
  (a << b) - c
  (a << b) >> c
etc, etc.

Some of these may not make sense (rarely used) but they are all (BOMK) 
valid statements.  The verilog converter would have to restrict all of 
these or handle all of them.  I don't know which is the best answer, yet.