can anyone explain this verilog code?

put a delay in ns in verilog

Here is the code:

module siro(rst, osc);
output reg osc;
input rst;
always @ (rst)
begin
if (!rst)
osc = 1;
else
osc = ~osc;
end
endmodule

I simulated this code on xilinx ise 6.103i through modelsim 5.7g simulator. But surprisingly to me, functional and post-place and route results are quite different. could anyone of u explain why ?

Hi,

Firstly, ur code is incorrect. I've corrected the code for you.

module siro(rst, osc);

output osc;
input rst;

reg osc;

always @ (rst)
begin
if (!rst)
osc <= 1; // u must use non-blocking in "always" block
else
osc <= ~osc;
end

endmodule

After u synthesized this verilog code, the tools will give u a "transparent latch". A mux where the output is connected to an inverted input, I1.

Why ur functional sim and after P&R give a diff results. I think it is due to blocking n non-blocking.

Attached is the document about blocking n non-blocking presented by Stuart Sutherland during International Cadence, User Group Conference.

Hope this helps,
no_mad ;-)

thanks for the reply

as far as i know, non-blocking statements are used to represent synchronous logic (or parllelism), right? but here i dont intend asynchronous logic. the simple block diagram i want to represent in the verilog code would be of a 2 input NAND gate with one input reset (working active low) and the other one is NAND gate's own output fed/looped back in.

the functional simulation doesnt conform to my block diagram . and i guess it shouldnt do neway coz in my opinion, the verilog code doesnt represent the thing i want to implement. but doing post place and route gives me exactly what i want!

nonetheless, going by ur code, i tried to do functional and post layout simulations and the results havent changed a bit from what i described in the first post. could u/anyone explain?

I'm no expert in asynchronous simulation, but I think I understand the problem.

The synthesizer will generate a latch/oscillator, probably like this: osc = ~(rst & osc).

To make your pre-route simulation more closely match the post-route simulation, make these changes:
1. Insert time delays that approximate the latch's propagation delay. I'm guessing 1.0 ns.
2. Put osc into the sensitivity list.
3. Use non-blocking assignments because overlapping events are occurring.

Try this. It oscillates while rst is high, similar to the post-route simulation. I use ModelSim 6.0c and ISE 7.1.03.
Or more compactly:
Comments and corrections welcome, because I want to learn too.

thanks echo47 the code worked now in pre layout simulation what u sent i had tried before with only difference that i used blocking statement. could u explain how the choice of blocking and non-blocking statement could make such a huge difference in the output?

secondly, can anyone explain why the code that i posted earlier worked perfectly as intended (i.e. osc toggles when rst is 1) in post layout simulation? remember that sensitivity list of always block only contains rst (i.e. no osc) and blocking statements were used instead of non-blocking.

I haven't fully absorbed the nuances of Verilog simulator timing. It follows precise rules (IEEE Standard 1364-2001). Some of those rules seem a bit strange to me, but probably exist for a good reason.

A blocking assignment with a delay (#1.0 out = in freezes the "always" block execution until the delay finishes, and then copies "in" to "out". During that delay, no other statements in the block can execute, even if other signals in your sensitivity list are wiggling. I don't know why many folks encourage using blocking assignments. Maybe because it makes Verilog look more like a software programming language. Seems unwise to me.

A non-blocking assignment with a future event (out <= #1.0 in immediately reads "in" and then schedules "out" to change at a future time. Simulation continues without hesitation, and without distrubing the other "always" block statements.

When you compiled your original post-route simulation netlist, the compiler generated code that approximates the actual behavior of the hardware gates and routes. That code contains delays and probably non-blocking assignments.

I understand your confusion. When you wrote your original code, you were predicting how the hardware would behave (propagation delays). In fact, you were depending on it. However, your pre-route simulation code didn't describe those hardware characteristics, so the simulator simply executed the code in strict Verilog fashion, and gave you unexpected results. Perhaps you could grab a copy of the IEEE standard and read section 5 "Scheduling Semantics".

You may want to try writing a tiny test module that feeds two or three very short overlapping pulses into an combinatorial "always" block, and then watch what happens when you insert delays and blocking or non-blocking statements. Beware that your simulator may or may not be 100% compliant with the Verilog standard.