Re: [myhdl-list] arithmetic trouble

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

Christopher L. Felton wrote:

> 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? 

It could potentially do this, just as it now does resizes in VHDL.
Of course it may not worth the trouble.

> 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.

Implementing the restriction is probably easy to do: the right operand
of certain operations (>>>, -) should be a plain name.

I'm inclined to start with this solution. I guess most designers will
find it acceptable.

A fundamental solution would be easiest with a resize like in VHDL.
Absent that, we would have to infer intermediate variables etc.,
which would add all kinds of complexities. Probably not worth the
effort at this point.

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