what is the difference between #1 a<=b and a<=#1 b

[tigerajs]

plz help me

 

[aravind]

it is thumb rule u should not use a = #5 b;
u can use #5 a= b;
because it is blocking statement.
1.it blocks b value for 5 secs and give it to a
2.a=b value happen after 5 secs .

simillary for non-blocking statement its vice versa
u must follow a <= #5b
because it wont block corresponding statements

 

[jarodz]

A. #5 a = b, after 5 time unit, simulator execute assign value of b to a.
B. a = #5 b, when simulator execute this statement,
keep the current value of b, and then assign this keeped value to a after 5 time unit.
It is same with "<=".



Sincerely,
Jarod

 

[nand_gates]

These are the ways one model transport delay and inertial delay in verilog simulator.
If ur are familiar with VHDL you will get it!
I am assuming timescale as 1ns
#1 a<=b // This models transport delay b will appear at 'a' after 1 ns
a<=#1 b // This models inertial delay 'a' follows 'b' after 1 ns delay in additin to this
any pulse < 1ns will get filter out at 'a'

Plaese refer the link below for VHDL!
**broken link removed**

 

[novise]

when #1a<=b is used b(t) is assigned a at time t+1 ,on the other hand when a<=#1b is used b(t+1) is assigned to a at time t+1

 

[rsjgs]

the difference is that in the first case the evaluation of the RHS takes place immediately but assigment after 1 ns. In the second case evaluation itself done after 1 ns

 

[darylz]

that nand_gates said is extract!

 

[bracketx]

hehe,there's several explanation.

 

[positive_edge]

1)

#1 a <= b

Evaluation of the assignment is delayed by the timing control.
RHS expression evaluated.
Assignment is scheduled ie a <--- b(t + 1 )

2)a <= #1 b

RHS expression evaluated .
Assignment is delayed by the timing control and is scheduled at the end of the queue.
Flow continues on.
a<-- b at simulation time t + 1

 

[AlexWan]

1 #N a<=b
Adding delays to the left-hand-side (LHS) of nonblocking assignments to model combinational logic is flawed.

module adder_t2 (co, sum, a, b, ci);
   output co;
   output [3:0] sum;
   input [3:0] a, b;
   input ci;

   reg co;
   reg [3:0] sum;

   always @(a or b or ci)
       #12 {co, sum} <= a + b + ci;
endmodule

If the a input changes at time 15, then if the a, b and ci inputs all change during the next 9ns, the outputs will be updated with the latest values of a, b and ci. This modeling style permitted the ci input to propagate a value to the sum and carry outputs after only 3ns instead of the required 12ns propagation delay.

So do not place delays on the LHS of nonblocking assignments to model combinational logic. This is a bad coding style.

Any guys may get the more detail inforamtion from Clifford E. Cummings papers.[/code]

 

[weng]

Do these blocking and nonblocking assignment reflect the actual circuit?

Can anyone code an example?

 

[Vonn]

sure it does ... here is an example :

if you write in your process :

a = 1;
b = a;
c = b;
these are Blocking assignment a = b = c = 1 and the generated circuit will be a 3 buffers connected to each others

1 ---[buffer]--->a---[buffer]--->b---[buffer]--->c

while if you write it using non-blocking

a <= 1;
b <= a;
c <= b;

this is Nonblocking assignment that means :
a = 1
b = old value of a
c = old value of b

and the actual circuit will be f/f instead of buffers

1 ---[f/f]--->a---[f/f]--->b---[f/f]--->c

 

[yuenkit]

transportation delay and inertial delay

 

[weng]

Do these blocking and nonblocking assignment reflect the actual circuit?

Can anyone code an example?

I am sorry that I didn't make my question clear.

What I wanted to ask is whether these blocking and nonblocking assignments with delays reflect the actual circuit. How do the delays in both assignments synthesize to circuit?

 

[shiv_emf]

Vonn has given nice example !! can i use it for designing shift register ?/

 

[archillios]

AlexWan is right, that is a bad coding style when used in combinational logic modeling. Thanks for Alex!
see the code below:

/*
bad coding style example
*/
module adder_t2 (co, sum, a, b, ci);
output co;
output [3:0] sum;
input [3:0] a, b;
input ci;

reg co;
reg [3:0] sum;

always @(a or b or ci)
#12 {co, sum} <= a + b + ci; // bad non-block assignment delay coding style
endmodule
module tb;
reg [3:0] a, b;
reg ci;
wire [3:0] sum;
wire co;
adder_t2 dut (.co(co),.sum(sum),.a(a),.b(b),.ci(ci));
initial
begin
#0 {a,b,ci} = {4'h1,4'h1,1'h0};
#50;
#11 {a,b,ci} = {4'h2,4'h5,1'h1};
#5 {a,b,ci} = {4'he,4'h0,1'h1};
#9 {a,b,ci} = {4'h5,4'h1,1'h0};
#50;
$display("good night");
$stop;

end
endmodule
/////////////////////////////////////////
unexpected behavior will be seen.

after the a/b/ci is changed, the {co, sum} <= a + b + ci; is scheduled at 12 time unit later, before the time is come, any change of a/b/ci will effect the {co, sum}, so the delay is not #12.

 

[foster_cn]

does the #1 in a <= #1 b means the flipflop transition time?

 

[darylz]

the assignment sequence is different!