Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
