Re: gEDA: Need help resolving a scheduling contradiction

[geda-at-NOSPAMgrfx_dot_com]

> From - Thu Jun 30 15:59:19 PDT 2005
> Z-Region: grfx.com = commercial
> Z-Reflector: seul.org
> Delivered-To: geda-dev-outgoing@seul.org
> X-Original-To: geda-dev@seul.org
> Delivered-To: geda-dev@seul.org
> Date: Fri, 1 Jul 2005 07:14:56 +1000
> From: Hamish Moffatt <hamish@debian.org>
> To: geda-dev@seul.org
> Subject: Re: gEDA: Need help resolving a scheduling contradiction
> Message-ID: <20050630211456.GA29927@cloud.net.au>
> Mail-Followup-To: geda-dev@seul.org
> Content-Disposition: inline
> X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe geda-dev
> Z-EndOfHeader: 31, Strikes = 0, Save = 2
> 
> On Wed, Jun 29, 2005 at 10:10:34PM -0700, geda@grfx.com wrote:
> > There is (IMO) a slight problem with the view that it's OK to treat
> > a continous assign the same way as a gate: while it makes sense for
> > the case of "wire x = y & z", the degenerate case of "wire x = w" is
> > perfectly realizable in hardware as a short-circuit and as such it
> > shouldn't incur ANY scheduling delay (and thereby race conditions).
> 
> If the specs says there's a delay, it's a bug not to model a delay.
> 
> I actually know nothing about Verilog but the same behaviour exists in
> VHDL.

The case in point is when no delay is specified. VHDL doesn't do blocking
assigns to signals so the issue does not arise (which is not necessarily
a good thing).

I agree with John's earlier point that when a race condition exists the
LRM should not attempt to order the results, and simulators can execute
the processes in any order. I just think for this particular case in
Verilog there is no good reason to go with the race-generating semantics.

Kev.

PS: If you want to start a Verilog vs VHDL thread I'll be happy to chip in.


> 
> x <= y and z;
> x <= z;
> 
> Both of these result in a 1 delta-cycle delay (as it's known in VHDL).
> 
> Thus race conditions are possible. In particular you have to be VERY
> careful when doing any assignments like this with the clock.
> 
> clk_delayed <= clk; -- 1 delta-cycle
> 
> process (clk)
> begin
>   if rising_edge(clk) then
>     b <= a;
>   end if;
> end process;
> 
> process (clk_delayed)
> begin
>   if rising_edge(clk_delayed) then
>     c <= a;
>   end if;
> end process;
> 
> In the simulator, this will NOT result in a 2-cycle delay.
> In hardware it will.
> 
> 
> Hamish
> -- 
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
>