Synthesis in VHDL vs. Verilog

[Allan Herriman]

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.

 

[Jim Lewis]

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Hal Murray]

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.

 

[Allan Herriman]

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.

 

[Allan Herriman]

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ď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.

 

[Ray Andraka]

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

 

[Andy Peters]

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

 

[Allan Herriman]

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.

 

[Mike Treseler]

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