Continue to Site

# Verilog Coding styles

Status
Not open for further replies.

#### mail4idle2

##### Full Member level 4
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

#### rca

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

#### mail4idle2

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

#### rberek

##### Full Member level 6
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.

#### mail4idle2

##### Full Member level 4
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.

#### rberek

##### Full Member level 6
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.

#### mail4idle2

##### Full Member level 4
I have done my home work. I wrote here to understand others perspective.

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

#### dave_59

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.

#### mail4idle2

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

#### dave_59

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.