Re: gEDA: Need help resolving a scheduling contradiction

[geda-at-NOSPAMgrfx_dot_com]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> geda@grfx.com wrote:
> 
> |> Since the tests seem to be using blocking rather than non-blocking assigns
> |> there really shouldn't be a scheduling issue - i.e. blocking assigns
> |> should just be executed immediately rather than scheduled, so the Verilog-XL
> |> looks like the right behavior to me. The comment in sched2.v about the
> |> "& gate" is bogus because there is no and gate only a logical operation
> |> (with no delay), and the LRM says the LHS is assigned when the RHS changes
> |> for a continuous assign.
> 
> There is a sublety here, in that the expression of a continuous assign
> is interpreted at least as a single gate. It must be, in order to give
> it a driver. Notice that continuous assignments can have strength and
> propagation times.

IMO it seems like a bad idea to introduce any kind of delay if none is specified.

> | From a performance perspective you don't want to schedule anything if you
> |> don't have to since that's extra overhead - so the XL behavior is preferable.
> |> Also, spliting the assignment over delta cycles (or at least making it
> |> non-atomic) is more likely to cause race conditions.
> 
> It doesn't necessarily turn out to be so. For example, if the thread is
> writing all the inputs to a complex expression and netlist of gates, it
> could save many evaluation steps overall to schedule them instead of
> push them. John S. experienced that to be so, and given what I'm seeing
> in my fiddling, I also believe it to be likely so.

There's more than one way to do that kind of calculation, and the extra
memory required for scheduling will probably impact your overall speed
cache performance more than the extra evaluations of an expression in
general.
 
> |> Actually it's pretty unreasonable that there is such a disparity on
> |> these simple cases.
> 
> It is *reasonable*, because these cases have races and are therefore by
> some measures not reasonable Verilog in the first place. They remain in
> the ivtest suite because they do reflect the marginal behavior of certain
> tools.

You're right that the case is not realizable in hardware, but the lack of
consistent results impacts the ability of synthesis tools to analyze the
description.  
 
> |> I think there is a problem in that there is no official "reference"
> |> simulator to defer to for the "correct" result - an exercise for someone
> |> in academia perhaps.
> 
> XL is, theoretically, that reference, although that's for IEEE1364-1995
> and not the -2001 standard. That said, XL seems to be alone on the
> particular scheduling issue that these tests bring up, and at this
> point I doubt even Cadence cares.

I still prefer the XL behavior - it's semantically cleaner.

The problem with using a commercial tool as the reference is that it has
other goals than faithfully implementing the LRM (e.g. speed). A reference
simulator would ideally be an open-source tool that exists purely to 
verify the LRM's syntax and semantic rules. 

Kev.

> - --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com           But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFCwZSErPt1Sc2b3ikRAhZFAKDbpcBQwKFQCnP+56bKYW4Ia8gC+gCgzBj5
> /maLwrtGUXGVWAZ3L6v8cEM=
> =iC+Y
> -----END PGP SIGNATURE-----
>