A question about the delay of unblocking-assignment,tks!

[janova]

Any problem if combining a module that use DELAY before unblocking-assignment with another module which do not?

Should the delayed one be one cycle after the un-delayed one, then result in timing dismatch in the combined logic?

thanks any way |-)

 

[Thomson]

Any problem if combining a module that use DELAY before unblocking-assignment with another module which do not?

Should the delayed one be one cycle after the un-delayed one, then result in timing dismatch in the combined logic?

|-)

Hi, i'm not sure what you expect to do with such modules exactly. However some basic guidelines may be useful if you coding you design and test cases.

(1) it's not necessary to include the delay before the unblocking assignments within the RTL codes. even with the sdf backannotation, it's the job of the tool not yours. If you really want to mimic the behavior of the RTL, then the intra-delay is better and accurate to modle the delaying behavior of register and combinatorial logic in Verilog. ( in VHDL, it's similar)
(2) if you want to describe the stimulus behavior, then the outcome of what you described above may be necessary to include the delay when using explicit # or @ or wait, then the result is dependent on your description( for example, whether these two modules handshake or not). for this topic, i'd recommend you refer to the Verilog's scheduling scheme and the tool's behavior about the Race.


Thomson

 

[vale]

Any problem if combining a module that use DELAY before unblocking-assignment with another module which do not?

Should the delayed one be one cycle after the un-delayed one, then result in timing dismatch in the combined logic?

thanks any way |-)

The only usage of DELAY before unblocking-assignment I can see, is that someone want to see some gap between clock edge and register output in waveform. It's a very bad habit without any benifit. You should follow Thomson's advices.

 

[janova]

Thanks very much to Thomson and vale, your suggestions helped me a lot ;p

I have two more questions:

1) two modules, one is DELAY coded, I mean, use #1(ns) for example, before each unblocking-assignment, the other one, however, no #1 used. There are some handshakes between the two synchronized modules.
I know it's not necessary to use DELAY if sdf back-annotated, but in functional simulation with no intra-delay, if I remove all the DELAY from the first module, any problem with the original timing of the handshake? Hope I have clearly expressed ;p

2) how many of you use #DLY before unblocking-assignment in your design and how many not? I know that many guides suggest to use #DLY in the behavior RTL code. What is the essential of using #DLY?

tks!

 

[vale]

Thanks very much to Thomson and vale, your suggestions helped me a lot ;p

I have two more questions:

1) two modules, one is DELAY coded, I mean, use #1(ns) for example, before each unblocking-assignment, the other one, however, no #1 used. There are some handshakes between the two synchronized modules.
I know it's not necessary to use DELAY if sdf back-annotated, but in functional simulation with no intra-delay, if I remove all the DELAY from the first module, any problem with the original timing of the handshake? Hope I have clearly expressed ;p

2) how many of you use #DLY before unblocking-assignment in your design and how many not? I know that many guides suggest to use #DLY in the behavior RTL code. What is the essential of using #DLY?

tks!

1) if both modules are syncronized by a same clock edge, then you can remove all delays safely. It's your case. remeber that delays will not affect synthesis result.
2)I never use any delay in my design, except codes ONLY for verification, such as testbench and stimuli.

 

[Thomson]

1) two modules, one is DELAY coded, I mean, use #1(ns) for example, before each unblocking-assignment, the other one, however, no #1 used. There are some handshakes between the two synchronized modules.
I know it's not necessary to use DELAY if sdf back-annotated, but in functional simulation with no intra-delay, if I remove all the DELAY from the first module, any problem with the original timing of the handshake? Hope I have clearly expressed ;p

The most issue that may exist in your codes is that maybe you code or describe your design behavior with some errors. If these two modules are both for RTL implementation, then only @(posedge clk or negedge rst) can be contained and other @ shall be excluded. If you have #delay before the NBA triggered by the @(posedge clk), then much attention shall be paid to this assignment. See the following
always @(posedge clk)
begin
#5 aout<=bin;
end

the bin is sampled at the time 5 ns(if the timeunit is ns) after the event posedge clk, while the description without #delay aout<=bin, the bin is sampled at the event posedge clk. At these two times, the value of bin may be different. Note: here assue that the clock cycle is larger than the #delay. So if you want to model the behavior of the clk-to-q delay of the register, the intra-delay shall be used as follows:
always @(posedge clk)
begin
aout<=#5 bin; //the sample values of bin is at time event posedge clk
end

2) how many of you use #DLY before unblocking-assignment in your design and how many not? I know that many guides suggest to use #DLY in the behavior RTL code. What is the essential of using #DLY?

tks![/quote]
I've never used #delay before NBA except using intra-delay to better matcher the simulation behaviro of RTL and netlist.

better Recommendation: not use #DElay, only @ (posedge clk) or @(negedge clk) or wait(signal_level) shall be used to model the behavior of your signals.

Thomson