Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

DCFIFO recovery and removal problems

Hi,

I am having issues with meeting timing on DCFIFOs on a straix II device. I get some failures on the recovery summary for the slow model. I have read a tutorial posted by Rysc here: http://www.alteraforum.com/forum/showthread.php?p=21048 I have a reasonably clear idea of what causes the failure but am unable to remove the failures from my timing report using the suggestions.

Anyway basically I have 4 DCFIFO where data can be written and read at different frequencies up to 150MHz in each case, therefore I am doing my timing analysis at 150MHz which should be the worst case.

I have a reset signal which enters the chip and is registered in different partitions of the design as recommended here on page 26 http://www.altera.com/literature/hb/qts/qts_qii51017.pdf This however does not help too much.

From studying on the web I understand that:

Recovery Slack Time = Data Required Time – Data Arrival Time

and that

Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtCO+ Register to Register Delay

I dont understand why the clock network delay to the source register plays a role. In my timequest timing report I have a clock network delay of 3.579ns before the reset signal is registered. I was thinking that the data arival time should start at the point where the reset signal is registered and then add the delay after. I must be wrong in my thinking, can someone please explain why this is not the case?

I have attached jpeg to illustrate my problem. The signal dac_fifo_clr_flopped is assigned after 3.5 ns but I was thinking that the analysis should start from this point thus allowing me to make timing comfortably?

I had a similar issue some time back with a cyclone III. What I done on that occasion was to cut the clocks and this removed the warings. I am wondering if there is any risk in doing the same again here? Is it an issue if certain registers in the DCFIFO come out of or enter reset on different clock edges? If not then I can just cut the clocks safely? Would this be a recommened approach or is there another way to deal with this?

One final thing. Quartus 9.0 placed by default the following constraints in thye .sdc file

set_false_path -from [get_keepers {*rdptr_g*}] -to [get_keepers {*ws_dgrp|dffpipe_id9:dffpipe18|dffe19a*}]

set_false_path -from [get_keepers {*delayed_wrptr_g*}] -to [get_keepers {*rs_dgwp|dffpipe_hd9:dffpipe14|dffe15a*}]

However when compiling the design, Quartus tells me that the constraints were ignored as "[get_keepers {*ws_dgrp|dffpipe_id9:dffpipe18|dffe19a*}] contains zero elements".

I don´t understand why Quartus places these constraints and then decides to ignore them. Should this constraint be modified or has anyone seen this before? I was reading on the web and found the following constraints on the altera website which are recommended to be used:

set_false_path -from [get_registers {*dcfifo*delayed_wrptr_g

[*]}] -to [get_registers {*dcfifo*rs_dgwp*}]

set_false_path -from [get_registers {*dcfifo*rdptr_g

[*]}] -to [get_registers {*dcfifo*ws_dgrp*}]

I´m not sure if they are included by default but I put them in the .sdc anyway.

I don´t have too much experience with DCFIFO´s but on both occasions that I have used them I have had problems with recovery and/or removal. I would be grateful if someone could let me know what I am doing wrong.

Many thanks for any help.

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Why does the clock to your source register go through a long delay and the clock to your destination register go through such a short delay? Run report_timing with the -detail full_path, but my guess is that you're driving the source register with a clock that doesn't go through a PLL, but the destination is driven by the PLL. I would move the source register to also be driven by the PLL output. The clock delay is valid.

    Finally, if you have the write signal disabled out of power-up, then the DCFIFO doesn't care about the reset signal timing, as nothing is happening out of power-up(I'm assuming you didn't disable the checks that disallow overflow/underflow). So if that's the case, you could make this a false path.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thanks for the reply Rysc.

    Yes you are right, I am driving the source register with a clcok that doesn´t come from the PLL, and I am driving the destination with a clock that is derived from a PLL.

    I don´t understand very well the reason for the long delay between the clock and the source register. I have attached a jpeg showing the full path of the clock. I don´t understand well why timequest is concerned with this long delay? Why doesn´t timequest start its timing analysis when the dac_fifo_clr_flopped signal is assinged? I´m sure there is a perfectly good explanation for this but I am having a little trouble getting my head around it.

    Anyway out of reset the write enable lines are disabled, so I am going to cut the paths between both clocks. This should solve the problem, but for interest sake, I would like to get a better understanding of the reason for the long delay above.

    Many thanks for the help
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    The global clock trees are all long. (Note that >3ns is that long for something that fans out to every register in the device.) The PLL phase-shifts the clock it sends out back in time to compensate for this, so it still has the long delay, it just starts earlier.

    If it started at dac_fifo_clr_flopped, then it's not really doing a correct analysis. Let's say you had two designs, one where the clock delay to that flip-flop is 3ns, and one where it's 23ns. Wouldn't those two designs behave differently? The latter would fail timing analysis because the signal sent out by dac_fifo_clr_flopped wouldn't get to its destination in one clock cycle. It needs to trace the clocks back to their source(which is usually common) so it can calculate how much they deviate(skew) from each other going to the source and destination register. This is identical to clock skew when feeding the source and destination registers of setup analysis(synchronous, register to register analysis)