There are two kind of race.
One with the digital hardware(i.e. in flip flop ) and
second is with the verilog simulation.
Both situations are considered as a race condition.
Race condition in Verilog context refers to a condition wherein the results are unpredictable. For e.g. consider:
Code:
always @(a)
b = ~a;
always @(a)
$display ("a %b b %b ",a,b);
Without going into why one would write such a code, this is one kind of behavior that's termed as race in Verilog. Problem is that Verilog LRM has several loose ends such as order of execution of blocks etc. that lead to such cases. Lint tools help in isolating, checking them for RTL. A good RTL coder will avoid such styles. However when it comes to Testbench/Verification, people tend to take it lightly and go fancy about it thereby ending up with so many issues that result in loss of productivity. I touch upon this very topic in my recently launched training
Comprehensive Functional Verification (CFV)
See: www.noveldv.com for details. We offer this in Bangalore for now.