Re: [myhdl-list] arithmetic trouble

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

Christopher Felton wrote:
> 
> 
> On Sat, May 16, 2009 at 2:16 AM, Jan Decaluwe <ja...@ja... 
> <mailto:ja...@ja...>> wrote:
> 
>     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
> 
> 
> Should we add this to the open task list 
> (http://www.myhdl.org/doku.php/dev:tasks) 
> <http://www.myhdl.org/doku.php/dev:tasks>?  As mentioned this is 
> considered a bug because of the simulation mismatch.  Think we have 
> captured information on the issue.  
> 
> Verilog will only use the largest "size" that exists in a expression. 
>  Intermediate results will only be as large as the largest declared reg 
> / wire.  This doesn't match how python handles the operations.  
> 
> Since I have been following this issue, some, I can volunteer for this 
> task.  I just can't promise any fast results. 

Thanks for volunteering! However, after thinking further about it
I believe the problem points to a more fundamental flaw in the
way signedness and sizes are inferred in the Verilog convertor.
I think the VHDL convertor does it right, and it is also more
complex than the Verilog case. I think I need to put something
similar into the Verilog convertor to get it right for the
future. In short, this is not a local change but a major
rewrite - I guess I should clean up my own mess :-)

I think I jumped the original conclusions a little.
If Verilog doesn't have a resize, we can write one or even put
in sign extensions and castings directly. In this way, we can
solve the issues without temporary variables in the same way
as for VHDL conversion. Otherwise, the functionality of
VHDL and Verilog conversion would diverge.

This will take some time. Currently I'm working on solving
the most important remaining flaw in MyHDL: the fact that
sliced signals are not signals, and the problems this creates
occasionally. I think I have a good solution but I need to
work further on it and document it - stay tuned.

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