Reply by Mike Treseler January 15, 20042004-01-15
Allan Herriman wrote:

> (including a broken ASIC). This seems to be more of a problem in > testbenches, because designers typically don't introduce delta delays > to clocks in synthesisable code.
Yes, and this is one good reason to use a synchronous style in vhdl sim models and testbenches. -- Mike Treseler
Reply by Allan Herriman January 14, 20042004-01-14
On Wed, 14 Jan 2004 12:19:46 -0500, Ray Andraka <ray@andraka.com>
wrote:

Hi Ray,

>Which is a big problem if you are structurally instantiating inside a generate. VHDL lets you >use a generate to plunk down multiple instances, and you can use a function in the RLOC string >so that the instances are not placed atop one another. As far as I can tell, you still can't >do that with verilog2001.
Yes, that's right. Martin Euredjian did have a ugly hack that works under certain conditions though: http://groups.google.com/groups?selm=mO8gb.12043%24iG.9361%40newssvr25.news.prodigy.com Regards, Allan.
Reply by Andy Peters January 14, 20042004-01-14
Jim Lewis <Jim@SynthWorks.com> wrote in message news:<40032827.3070501@SynthWorks.com>...

> My brain just blew a fuse when with the ironic statement: > "Verilog is a very simple language so it's easier for > the tools guys to get it right."
...and even simpler for lazy/inexperienced/"clever" coders to create heinous "designs."
> VHDL never had race conditions and never will.
As Janick points out in his book: Shared Variables. Not that anyone in his/her right mind would ever use them, of course :) -a
Reply by Ray Andraka January 14, 20042004-01-14
Which is a big problem if you are structurally instantiating inside a generate.  VHDL lets you
use a generate to plunk down multiple instances, and you can use a function in the RLOC string
so that the instances are not placed atop one another.  As far as I can tell, you still can't
do that with verilog2001.

Allan Herriman wrote:

> Verilog 2001 supports attributes. However, even in this latest > version of the language, it still isn't possible to have an attribute > whose value is a string that is a function of e.g. a genvar.
-- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
Reply by Allan Herriman January 14, 20042004-01-14
On Tue, 13 Jan 2004 19:37:31 -0800, Jim Lewis <Jim@SynthWorks.com>
wrote:

> >>>>Experience indicates that even simple examples >>>>may produce different results on different >>>>LRM compliant simulators. >>> >>>My read on the LRM and simulation cycle says that >>>if two simulators execute your example differently, >>>one of them is not compliant. >>>Have you seen different results for a delta >>>cycle situation like this that was not a >>>simulator bug? >> >> >> I didn't think the VHDL LRM defined the order in which processes are >> executed. Can you point to the particular part of the LRM that says >> this? Without a defined order, different simulators may produce >> different results. > >It does not specify an order between processes >running. It does specify when signals get >updated vs. when processes get run. For any >given execution cycle, first all signals that >are scheduled to change on that cycle are >updated and then processes are run. > >Hence in your example, both clk2 and sig1 >get updated and then the process is run. >As a result, as modified, the two processes >simulate as if there is only one register.
The na&#2013265935;ve user would have expected two registers. I don't recall the exact code which simulated differently (it was three jobs ago, and wasn't my code), but the simulator vendors both assured us that their simulators were correct, and that this was the problem of the LRM. (Now that I think about it, Modelsim could have been doing some non-LRM compliant speedup (despite what was claimed), which hid the race. I'm fairly sure the other simulator was doing the right thing.) Regards, Allan.
Reply by Allan Herriman January 14, 20042004-01-14
On Wed, 14 Jan 2004 03:54:16 -0000, hmurray@suespammers.org (Hal
Murray) wrote:

>>I disagree with the "forget about it" part. Races in VHDL do cause >>problems in real-world designs. I have seen plenty of examples >>(including a broken ASIC). This seems to be more of a problem in >>testbenches, because designers typically don't introduce delta delays >>to clocks in synthesisable code. > >Why doesn't the compiler/simulator catch that case and give a >warning/error message?
It's not mentioned explicitly in the LRM, and it's not something that is encountered often. Regards, Allan.
Reply by Hal Murray January 13, 20042004-01-13
>I disagree with the "forget about it" part. Races in VHDL do cause >problems in real-world designs. I have seen plenty of examples >(including a broken ASIC). This seems to be more of a problem in >testbenches, because designers typically don't introduce delta delays >to clocks in synthesisable code.
Why doesn't the compiler/simulator catch that case and give a warning/error message? Compile time checking is good. I remember when I was first learning about type checking. I didn't understand what was going on yet, just thrashing around until the compiler stopped complaining. Then one night the compiler slapped my wrist because I used an XXX rather than a pointer to an XXX and I figured out what was going on. That's the sort of thing that takes ages to debug the hard way. That error message had just saved me a lot of work. The really great thing about strong type checking is that you can make massive changes to your code, and the parts that don't get checked often (error handling) will still work. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
Reply by Jim Lewis January 13, 20042004-01-13
>>>Experience indicates that even simple examples >>>may produce different results on different >>>LRM compliant simulators. >> >>My read on the LRM and simulation cycle says that >>if two simulators execute your example differently, >>one of them is not compliant. >>Have you seen different results for a delta >>cycle situation like this that was not a >>simulator bug? > > > I didn't think the VHDL LRM defined the order in which processes are > executed. Can you point to the particular part of the LRM that says > this? Without a defined order, different simulators may produce > different results.
It does not specify an order between processes running. It does specify when signals get updated vs. when processes get run. For any given execution cycle, first all signals that are scheduled to change on that cycle are updated and then processes are run. Hence in your example, both clk2 and sig1 get updated and then the process is run. As a result, as modified, the two processes simulate as if there is only one register. signal clk1, clk2 : std_logic; signal sig1 : std_logic; clk2 <= clk1; -- clk2 lags clk1 by 1 delta process (clk1) begin if rising_edge(clk1) then sig1 <= foo; end if ; end process ; process (clk2) begin if rising_edge(clk2) then bar <= sig1; end if ; end process ; In VHDL, (for the most part), order of execution of processes does not matter since we primarily use signals (which incur the delta cycle assignment delay). In Verilog, blocking assignments are similar to shared variables without restrictions. Hence, always block execution order comes into play.
>>Oops, it was not intentional. >>Verilog does have a large, common problem in this area. >>With VHDL it is minor enough to easily forget about it. > > > I disagree with the "forget about it" part. Races in VHDL do cause > problems in real-world designs. I have seen plenty of examples > (including a broken ASIC). This seems to be more of a problem in > testbenches, because designers typically don't introduce delta delays > to clocks in synthesisable code.
This will only happen when it is the same clock (and you should have not touched it) or it is a derived clock and the two clocks are delta cycle aligned (or close enough so that clk-q propagation delay is bigger than the clock skew). So if your designs are a single clock or multiple unrelated clocks, no problem. I would argue that we remember what caused us or our colleagues the most problems. So the things that I remember best are: Model timing in memory when timing is > 1 clock period. Made a design non-functional because the designer got data immediately. Respin of an ACTEL 1280 FPGA at $$$/piece (if I recall it was $500 US in 1992). I am guilty of writing the memory model. By the time we found the bug in the lab, the designer had gone to another project so I got to redesign his chip. Drive busses to "XXX" when they are idle. The external IP testbench model drove cycle type lines of an X86 processor to the same given cycle during idle. The cpu interface had a bug. It was fixed with a $.50 board part (which cost $50K year due to board volume). Be aware of inertial delay: I hardly remember this one, but I had some mysterious cancellations of signal waveforms (testbench) in my first project. Rather than figure out if it was an understanding issue or a bug, I replaced the after statement with a wait statement and went on. These may mean nothing to you as you may have never encountered them. I think you also remember things as to how you classify them. I never thought of this as clk-data race. I always thought of lumped with aligned derived clocks and file it under, "keep related clocks delta cycle aligned." Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reply by Allan Herriman January 13, 20042004-01-13
On Tue, 13 Jan 2004 15:17:18 -0800, Jim Lewis <Jim@SynthWorks.com>
wrote:

>Allan, > > It's actually quite easy to make races in VHDL. >I agree this is a clock to data race condition, >however, it is also easy to avoid and easy to >even forget the rule exists. > >Are you suggesting that Verilog race conditions >are as simple to solve as this? :) After reading >Cliff's papers, I would conclude that it is not >an insignificant issue in Verilog.
Races in Verilog can also be avoided by following a coding standard. I agree they are easier to make, though. I have never been bitten by a race in Verilog, whereas I have been bitten by races in VHDL on several occasions! This has always in other people's code though. This may be a reflection of the relative amount of time I've spent with the two languages, rather than any property of the languages themselves.
> > Experience indicates that even simple examples > > may produce different results on different > > LRM compliant simulators. > >My read on the LRM and simulation cycle says that >if two simulators execute your example differently, >one of them is not compliant. >Have you seen different results for a delta >cycle situation like this that was not a >simulator bug?
I didn't think the VHDL LRM defined the order in which processes are executed. Can you point to the particular part of the LRM that says this? Without a defined order, different simulators may produce different results. Yes, I have seen differences between VHDL simulators that weren't considered to be bugs (Simili vs Modelsim, using the delta delayed clock example from an earlier post).
> > Jim, when discussing the relative merits of Verilog > > and VHDL it is important not to make false claims > > about either language. >Oops, it was not intentional. >Verilog does have a large, common problem in this area. >With VHDL it is minor enough to easily forget about it.
I disagree with the "forget about it" part. Races in VHDL do cause problems in real-world designs. I have seen plenty of examples (including a broken ASIC). This seems to be more of a problem in testbenches, because designers typically don't introduce delta delays to clocks in synthesisable code. Regards, Allan.
Reply by Jim Lewis January 13, 20042004-01-13
Allan,
 > It's actually quite easy to make races in VHDL.
I agree this is a clock to data race condition,
however, it is also easy to avoid and easy to
even forget the rule exists.

Are you suggesting that Verilog race conditions
are as simple to solve as this?  :)  After reading
Cliff's papers, I would conclude that it is not
an insignificant issue in Verilog.


 > Experience indicates that even simple examples
 > may produce different results on different
 > LRM compliant simulators.

My read on the LRM and simulation cycle says that
if two simulators execute your example differently,
one of them is not compliant.
Have you seen different results for a delta
cycle situation like this that was not a
simulator bug?


Regards,
Jim

 > Jim, when discussing the relative merits of Verilog
 > and VHDL it is important not to make false claims
 > about either language.
Oops, it was not intentional.
Verilog does have a large, common problem in this area.
With VHDL it is minor enough to easily forget about it.



Allan Herriman wrote:

> On Mon, 12 Jan 2004 15:05:11 -0800, Jim Lewis <Jim@SynthWorks.com> > wrote: > > >>VHDL never had race conditions and never will. > > > It's actually quite easy to make races in VHDL. Experience indicates > that even simple examples may produce different results on different > LRM compliant simulators. > > > signal clk1, clk2 : std_logic; > signal sig1 : std_logic; > > ... > > clk2 <= clk1; -- clk2 lags clk1 by 1 delta > > process (clk1) > ... > sig1 <= foo; > ... > > process (clk2) > ... > bar <= sig1; > ... > > > Astute designers will modify their coding standards to disallow clock > assignments such as the one above. > > Jim, when discussing the relative merits of Verilog and VHDL it is > important not to make false claims about either language. > > Regards, > Allan.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~