verilog help - register causing delay

verilog help - FIFO delay

let us say module1 calls module2 by passing an input i1.
now within module 2, i say
1st case
wire test
assign test=i1

2nd case
reg test
always@(posedge clk)
test=i1

In case2, i find that test is offset by one clock period from i1. Whereas, in case1, it follows i1 exactly (clearly since it is an assign statement and works all the time)
Could someone explain the problem? I would like to have case2 to follow i1 exactly as well.

PS: i1 is obtained from a FIFO output that works on the posedge of the same clk. Any help would be greatly appreciated

Synchronous logic designs are comprised of registers and combinational logic in-between. Saying the registers are causing a delay is only half of the story. Registering signals is up to the decision of the designer. Delay is however caused by the combinational logic and signal routing. Registers are the means to regenerate the delayed signals with defined timing.

From this viewpoint, registers are unavoidable. What's your particular problem with registered delays?

FvM said:

Synchronous logic designs are comprised of registers and combinational logic in-between. Saying the registers are causing a delay is only half of the story. Registering signals is up to the decision of the designer. Delay is however caused by the combinational logic and signal routing. Registers are the means to regenerate the delayed signals with defined timing.

From this viewpoint, registers are unavoidable. What's your particular problem with registered delays?

Click to expand...

To be specific, my problem is as folllows:
I have module1 that consists of a FIFO and module2.
The inputs to module1 are written to the FIFO at the posedge. The data in the FIFO is also read at the posedge and given as inputs to module2.

consider an always@(posedge clk) block in module2. For some reason, the data that is read from the FIFO at a particular posedge is not reflected within module2 at the same posedge.

say at t=10ns we have a posedge and data d1 comes out from the fifo.

at t=10ns, when i try to operate on the data d1 in module2 (through the always block). What happens is that instead of operating on d1, i operate on the previous value.

Please note that there is no combinational delay anywhere in between. The output of the FIFO is directly connected to the input of module2 and this is checked at the posedge

PS: I am working on Altera Quartus

Hi Sabkumar,
The way i do understand your problem is there is nothing wrong if in case2 u get one cycle delayed i1. Here in case 2 test is declared as reg, implemented using dff, it will have it's hold time. now this thold must follow thold<=tcomb+tclktoq. In your case since tcomb=0ns (as said), tclktoq is inadequate to avoid violation. Hence 1 cycle delayed value gets latched in test. I assume there is no clock skew present.

My conclusion is that you are awaiting the new data at the wrong clock edge. You should be prepared to receive it one clock cycle later. It might be necessary to delay accompanying handshake or address signals by one clock cycle to achieve what you want.

FvM said:

My conclusion is that you are awaiting the new data at the wrong clock edge. You should be prepared to receive it one clock cycle later. It might be necessary to delay accompanying handshake or address signals by one clock cycle to achieve what you want.

Click to expand...

So you are saying that it is not possible to get the data at the same posedge that it was read out?
I could delay the control signals of course, but I want to make sure that it is the last resort as it decreases the throughput

- - - Updated - - -

babaduredi said:

Hi Sabkumar,
The way i do understand your problem is there is nothing wrong if in case2 u get one cycle delayed i1. Here in case 2 test is declared as reg, implemented using dff, it will have it's hold time. now this thold must follow thold<=tcomb+tclktoq. In your case since tcomb=0ns (as said), tclktoq is inadequate to avoid violation. Hence 1 cycle delayed value gets latched in test. I assume there is no clock skew present.

Click to expand...

I think the problem is with setup violation rather than hold. The data is stable after the clock edge.it is before the clock edge that it is not stable.

So you are saying that it is not possible to get the data at the same posedge that it was read out?

Click to expand...

I don't know if it's possible in your application. It's not possible if the signal is registered on input to the second module. But is it necessary to register the signal?

A module designed for different appplications might register the signal to increase the timing margin, although registerung isn't required for all applications.

I could delay the control signals of course, but I want to make sure that it is the last resort as it decreases the throughput

Click to expand...

In most cases, the delay doesn't affect throughput because you can still process a new data value each clock cycle. That's called pipelining,

sabkumar.r said:

- - - Updated - - -

I think the problem is with setup violation rather than hold. The data is stable after the clock edge.it is before the clock edge that it is not stable.

Click to expand...

What's more important here is data of previous cycle on receiving flop which will be overwritten by incoming data in present cycle causing hold violation.

babaduredi said:

What's more important here is data of previous cycle on receiving flop which will be overwritten by incoming data in present cycle causing hold violation.

Click to expand...

I see your point. Thanks!

- - - Updated - - -

FvM said:

I don't know if it's possible in your application. It's not possible if the signal is registered on input to the second module. But is it necessary to register the signal?

A module designed for different appplications might register the signal to increase the timing margin, although registerung isn't required for all applications.

In most cases, the delay doesn't affect throughput because you can still process a new data value each clock cycle. That's called pipelining,

Click to expand...

Sorry I meant latency. that will be affected. And yes it is necessary to register the signal unfortunately. So, I plan to skew the clock to module2 so that timing violations are avoided. I intend to use the intra-statement delay for the same. But for some reason quartus does not support intra statement delay. Or am I going wrong somewhere?

Used the following code:
timescale 1ns/1ps
clock_skew = #1 clock;

Seriously, I don't know what "interstatement delay" is in terms of HDL design?

I doubt, that "skewing" a clock will involve any advantage for your design. I suggest to refer to a synchronous standard scheme instead, using a single design-wide clock.

FvM said:

Seriously, I don't know what "interstatement delay" is in terms of HDL design?

I doubt, that "skewing" a clock will involve any advantage for your design. I suggest to refer to a synchronous standard scheme instead, using a single design-wide clock.

Click to expand...

Let me just try just in case. Thanks for your help

- - - Updated - - -

Clock skewing worked!! I think I got the problem.
say at t=10ns, a posedge occurs and data is pumped out by the fifo
Now, inside module2, I am trying to access the data at the same instant i.e t=10ns.
Clearly, this is a timing violation. The data in module2 (being declared as a reg) needs to be stable for some time before 10ns.
I skewed the clock to module2 by 2ns. Meaning I check the data at 12ns, which was pumped out by the FIFO at 10ns. This satisfies setup time and works perfectly.
Cheers!

Clock skewing worked!! I think I got the problem.

Click to expand...

I believe that it can be an appropriate solution for special cases. I don't hear yet any indications that your application is of this kind, but this may be due to lack of information. In most cases, skewing a clock inside a chip would bring up timing problems in a different place because data pathes are mostly two-way.

Adjusting the timing of external interfaces is a different thing and quite often requires phase shifted clocks, at least if your approaching device speed limits.