Continue to Site

Welcome to EDAboard.com

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.

RTL Coding HELP - Race Condition

Status
Not open for further replies.

kocchop

Newbie level 3
Joined
Mar 14, 2018
Messages
4
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
41
I am using the following coding pattern to latch a data:

To latch a data in a particular register, I have to set a latch_enable signal high. And I am enabling this latch_enable signal at clock cycle n because I want the data to be latched at clock cycle n+1. And at clock cycle n+1, I am disabling the latch_enable signal under the assumption that the data is already latched at the posedge clk.

But the thing is, my data is being latched at same posedge clk at which the latch_enable (responsible for the data storage) signal is being driven low.

So, I think I am facing a kind of race condition in my RTL design. Under the normal conditions, there may be some parasitic delay added while driving the latch_enable signal low. But would that be enough?

I have seen the above mentioned practice in some other RTL codes. That's why, I just want to clarify if my thoughts are ok or not.

And if really such race condition occurs, then what practice should I follow to avert this problem?

Thanks in advance.
 

I don't find any problem in your explanation. It's completely fine to do that.

Even you can simulate once and check, it will definitely work.
 
Thank you for your answer. Actually, I was simulating my RTL verilog and found discrepancies between two simulators ModelSIM and Incisive. I simulated the same RTL verilog code on those two.

In ModelSim, it ran as it was supposed to. The above logic worked fine. However, in Incisive, it did not work. After manually inserting a #delay to the latch_enable while it was being driven low, I was able achieve my desired behavior. And that is why I found it strange. FYI, I am using irun in Incisive.

Could you please enlighten this fact? Why would two simulators treat the same phenomena differently?

Thank you once again.
 

It is a known fact that simulators behave differently.

For e.g. - xsim (Xilinx simulator) and ActiveHDL behave differently for certain cases. You have most probably hit upon one such.
Advice is to stick to one, rather than adapt or compare.
 

ok.. then if you have read my very first query, I want to ask if I need to take any other approach in the RTL design other than the current one? I want to stick to Incisive and it is not giving me the desired result.

And lastly, I have another question that although the simulators work differently, what would likely happen after synthesis?

Thank you :)
 

Just make your testbench operate on the opposite edge and the problem should go away.
 

Yes I if I trigger the latch_enable signal at negative edge, the problem goes away. But the part I am verifying right now is a small part of my whole my design. In actual design the latch_enable signal is driven in a state of the synchronous state machine which works on posedge clk.
So what I am actually asking is if I am good to go with the above mentioned design in real synthesis. Thank you all once again for your kind reply.
 

Yes I if I trigger the latch_enable signal at negative edge, the problem goes away. But the part I am verifying right now is a small part of my whole my design. In actual design the latch_enable signal is driven in a state of the synchronous state machine which works on posedge clk.
So what I am actually asking is if I am good to go with the above mentioned design in real synthesis. Thank you all once again for your kind reply.

Yes, your final implementation will respect hold timing and this 'race' condition will never occur.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top