Verilog Coding styles

Status
Not open for further replies.

mail4idle2

Full Member level 4
Joined
Oct 20, 2012
Messages
200
Helped
20
Reputation
40
Reaction score
19
Trophy points
1,298
Visit site
Activity points
2,173
Does the below two codes gives you the same result in simulation ?
If yes how ?

############################################
module nbex2 (q, a, b, clk, rst_n);
output q;
input clk, rst_n;
input a, b;
reg q;

always @(posedge clk or negedge rst_n)
if (!rst_n) q <= 1'b0;
else q <= a ^ b;

endmodule

#############################################

module nbex1 (q, a, b, clk, rst_n);
output q;
input clk, rst_n;
input a, b;
reg q, y;

always @(a or b)
y = a ^ b;

always @(posedge clk or negedge rst_n)
if (!rst_n) q <= 1'b0;
else q <= y;

endmodule
 

that should give you the same result, because y is just the output of logic combinational (or) which is save in flop q.
 

Don't you think clk and a change at the same time there you would be a mismatch in the result ?
 

These are both standard coding styles and will produce the same result. And unless A and B are synchronous to the clock, you will get issues if they change state near the clock edge - that is called metastability.

But why don't you simulate these two pieces of code to convince yourself they are the same? It would be a trivial exercise.

r.b.
 

why we are talking about meta stability in RTL simulation.
What would be the result if a b and clk change at the same time.
 

I suppose my answer was not very clear. Your original question was whether or not the two pieces of code will simulate the same. If synthesized, they will produce the same RTL. Therefore they will (or at least should) simulate the same.

Then you mention the situation where the inputs are not synchronous to the clock. In real hardware, this will be a metastability issue.

In simulation, where A and B are asynchronous with the clock and each other, the results will be unpredictable. It would be very difficult, if not impossible, to create a self-checking testcase to test this. When you are designing a large ASIC or FPGA and forget to metastability harden something, you can often catch this in simulation due to random failures in regression.

For the situation where A and B and the clock change at the same time, why don't you write a testcase and simulate it to see what happens? You can then play around and answer all your questions yourself.

r.b.
 

I have done my home work. I wrote here to understand others perspective.
If you do not have answer please follow this chain and get the answer. Let others answer.

My question was whether simulation will be same or not. Not about synthesis output.
 

mail4idle2,

If you are only interested in differences in simulation results, you will have to show the stimulus to the inputs of these modules. There are no simulation results with out stimulus.


In the first example module, a and b are evaluated in the current time slot after the @(posedge clk). So as long as a and b change before the current time slot, there is no race.

In the second example module, y is evaluated in the current time slot after @(posedge clk). y will change in the the same time slot as a and b change. So as long as a and b change before the current time slot, there is no race.


Therefore, if the stimulus has no race conditions, the results are guaranteed to be the same.
 

what if clk, a, and b change at the same time, then we can have different results right ?
 

Yes, that is a race condition, and it won't matter which style you use, there is no guarantee of results.

But in Verilog, "at the same time" has a specific meaning, not just the value of $time is the same. We mean "within the same active time slot" there can be many time slots (or delta times) where $time is the same. Remember that Verilog has an active queue of events, and non-blocking assignments make their assignments in the next active event queue. So if a and b are assigned using non-blocking assignments, there will be no race condition because a and b are guaranteed to have their old values.
 

Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…