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.

State of a rising edge

Status
Not open for further replies.

tbyeoh

Newbie level 5
Joined
Nov 28, 2009
Messages
10
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,345
In behavioral verilog code below, what happens if signals a,b rises at the SAME time?

always@(posedge a)
begin
if (b==1) do this
else do that
end

In modelsim: b takes value 0 and 'do that' occurs. In iverilog, b=1 and 'do this' occurs. So, looks like it is not standardized across compilers.
Any thoughts?
 

Yes, its a race condition and you are right that it is not standard across simulators. So make sure b does not change at the clock edge
 
  • Like
Reactions: tbyeoh

    tbyeoh

    Points: 2
    Helpful Answer Positive Rating
>So make sure b does not change at the clock edge
Its not so simple to do that when you actually implement in RTL.

tbyeoh,
They're right about that its a compiler specific thing. The thing to remember is that your situation is essentially a setup/hold violation in hardware.

You cannot simply not change signals on edges at will as recommended. Imagine b is coming from a flop just before the flop given in your code (and this is not in your hand, its just what the design requirement is). You just have to hope timing will be closed b/w the 'b' generating flop and your flop. Also in this case, I think modelsim's behaviour is the way to go, since the propagation delay of the source flop will make the destination flop see a 0 till 'b' actually arrives at its input. In that sense, I think modelsim's and similar professional simulator's algorithms have complex delta scheduling algorithms (change of multiple signals at same edge) to take care of such exigencies.

'b' if it is an external signal is another matter - you have to double-synchronize it if it is asynchronous. If timing of 'b' is known (say it is coming from a memory device whose timing characteristics are known), then appropriate constraints can be applied.

Hope this makes sense even if you're a pure verification guy.
 
The general rule is not to read a signal from one process and write to the same signal in another process where both are sensitive to the same clock edge. For pure RTL, use a non-blocking assignment to update b.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top