Re: [myhdl-list] arithmetic trouble

[Christopher F. <chr...@gm...>]

On Sat, May 16, 2009 at 2:16 AM, Jan Decaluwe <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.

Chris