Synthesis in VHDL vs. 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.

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

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 to
Allan Herriman
Loading thread data ...

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 >Verilog does have a large, common problem in this area.

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
 Click to see the full signature
Reply to
Jim Lewis

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
 Click to see the full signature
Reply to
Hal Murray

It's not mentioned explicitly in the LRM, and it's not something that is encountered often.

Regards, Allan.

Reply to
Allan Herriman

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.

Reply to
Allan Herriman

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

...and even simpler for lazy/inexperienced/"clever" coders to create heinous "designs."

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 to
Andy Peters

Hi Ray,

VHDL lets you

the RLOC string

you still can't

Yes, that's right.

Martin Euredjian did have a ugly hack that works under certain conditions though:

formatting link

Regards, Allan.

Reply to
Allan Herriman

Yes, and this is one good reason to use a synchronous style in vhdl sim models and testbenches.

-- Mike Treseler

Reply to
Mike Treseler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.