-1
\$\begingroup\$

Do I need to be aware of races while writing code for sequential circuits in VHDL ( I use ISE Design Suite ) ? If I do not, what is the matter that solves the races issue instead of me ?

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Of course you need to be aware of race conditions. A few seconds with Google would have told you so! \$\endgroup\$ Nov 29, 2014 at 12:33

2 Answers 2

1
\$\begingroup\$

The mainstream design tools are very much oriented toward synchronous design practices, in which all state information is kept in master-slave flip-flops, and all asynchronous logic is purely combinatorial (no feedback).

On those rare occasions when you absolutely need to have an asynchronous sequential cirucit (e.g., handshake logic that crosses clock domains), the tools will fight you over it, and you'll need to take pains to deal carefully with race conditions, and you'll also need to make sure that the tools don't optimize away your redundant paths.

For this reason, you'll want to reduce any required asynchronous sequential logic to the absolute minimum necessary.

\$\endgroup\$
-1
\$\begingroup\$

Race conditions as in multi-thread programming (e.g. shared variables) don't exist in VHDL.

This is because you have to specify the value that goes into a register at each clock. You can't write the same register from two different processes. You are forced to resolve any race condition explicitly in the write process. Of course you can still produce race-conditions at a higher level (e.g. data arrives one clock before your state machine is in the ready state) but you will not be caught completely off-guard.

The closest thing to race-conditions (as known from multi-threading) with clocked logic is during RAM access (read-during-write behaviour). But even there you will, at some point, be forced to make an explicit choice about what should happen in this case.

On the other hand, there is plenty of opportunity for race-conditions when you try to move data across asynchronous clock domains. It's possible that some bits are transfered, but not others. You have to be very careful with clock domain crossing: if you have a bug there, it may happen in 5% of the cases in one synthesis result, and not at all in another synthesis result, or only above a certain temperature. But that's not really sequential logic any more.

\$\endgroup\$
2
  • \$\begingroup\$ I don't know why you keep referring to multi-thread programming. The subject at hand is race conditions in asynchronous sequential logic. Also, it's definitely possbile to describe such logic in VHDL (or any other HDL), which means that you DO need to worry about race conditions and how to deal with them. \$\endgroup\$
    – Dave Tweed
    Nov 30, 2014 at 1:15
  • \$\begingroup\$ Are you sure the question was about asynchronous logic? I assume it wouldn't have been asked that way if the OP was already familiar with HDL. I'm talking about multi-thread programming because this is the most likely association of "race conditions" for someone with a CS background (my best guess for the background of someone asking this question). \$\endgroup\$
    – maxy
    Nov 30, 2014 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.