Recovery Removal and multiclock IP

I have had this issue as well in certain places, mainly the DDR2HP cores and the DCFIFO cores.

I wanted to reconfigure reset sequences on the DDR2HP cores when i shared multiple cores on a single IC. I just went into the files that handled them and routed certain signals to the top level and certain signals back into the core to be used as the reset.

For the DCFIFO core, i went into the medafunctions/dcfifo.tdf file and modified all of the aclr signals to include both a wr_aclr and a rd_aclr, mapped those to the top level, and then i can provide both a write reset and a read reset signal. Then i wrapped a library around them that looks just like the altera_mf_components library so i can choose which instance to use based on the included library. It has worked out well so far.

Usually the reset circuitry is not in an encrypted section of code, so it should be easy to modify the files you need. Just copy the library file into a new directory, make the changes, then include that file into your project so it gets used before the original library file does.

Good questions, and hope this helps a little slash shows incite into how i have been dealing with it. It would be nice if altera was better at bringing signals like resets and enabled to the top level and letting the user decide how to hook them up, but they also try to make the easiest to use cores. Give and take...

Kevin

Actually ignore what i said in the previous post. I spoke too early. It is still true of the DDR2HP core, but what i talked about with the DCFIFO cores does not appear to be true as of yet.

I looked into dcfifo.tdf and saw where it used the aclr signals, but what i was looking at was not the general use functions but some specific implementations when not using EAB blocks i believe. After further investigation it looks to call some function to generate the fifo files, and it passes the arst signal into that function. I haven't dug deeper, but it looks to be a little more complicated that i first believed. I'll update here if i have any new breakthroughs with the DCFIFO.

Time to wipe the egg off my face,

Kevin

I asked this same question in an Altera service request and my answer from them was "Customer can synchronize it in rx_refclk or tx_refclk domain. Even the rst input doesn't synchronized to other clock domain inside ASI core, I am afraid this will not lead to timing violations." Yeah right, still had timing violations up the wazoo. I ended up cutting the path with a set_false_path constraint (not something I like doing).

Make sure you use the 9.1 SP1 version of the core as there is a synchronization bug in the 9.0 SP2 version.

A SR I opened with altera a month ago or so about DCFIFO arst and what you can ignore. Thought it may be helpful.

request title: DCFIFO arst for seperate clock domains.

Description: When using a DCFIFO, i only have one option for an arst input. Outside of the dcfifo i have a reset sequencer circuit which takes a reset signal in and synchronizes it to the different clock domains, going into reset asynchronously and coming out of reset synchronous with the clock. It would be helpful to have those reset inputs into the dcfifo. Any thoughts? I am having problems with meeting timing on recovery as well as timing analysis for the outputs because they are on different reset domains. I also fail timing on the recovery analysis of a reset signal that is latched on the negative edge of a clock in the fifo. I don't write to the fifo on the few clocks emmidiately after coming out of reset. I do have some fifo's with the read signal equal to not(rd_empty). Is there any timing analysis's that I can break to help with timing?

In dealing with this kind of issue with other cores, I have been able to get into the design files and make the modifications I needed. But, because the DCFIFO is generated in a dll it appears as opposed to with tcl scripts, it is a little bit harder to modify.

Thanks for your time.

Kevin

to customer

Hello Kevin,

Thanks for using mySupport. DCFIFO supports asynchronous clear and asynchronous clear that synchronize with the write clock. The wrreq signal must be low when the DCFIFO comes out of reset (the instant when the aclr signal is de-asserted) at the rising edge of the write clock to avoid a race condition between write and reset. If this condition cannot be guaranteed in your design, the aclr signal needs to be synchronized with the write clock. This can be done by setting the Add circuit to synchronize 'aclr' input with 'wrclk' option from the FIFO MegaWizard plug-in.

Usually we suggest customers set the Add circuit to synchronize 'aclr' input with 'wrclk' option from the FIFO MegaWizard plug-in. If you find the reset timing issue in the writing timing domain, please send me your project in order that I can look into it further. And if you find the reset timing issue between writing and reading or just in reading timing domain, you could make this a false path or just ignore it.

Hope it is helpful to you. Please let me know if you have further question on this issue. Thanks.

Best Regards,

Altera

from customer

So i just created a project with a basic fifo implemented. A few questions to help clarify:

If i can ensure that a write request does not occur on the first three clock after the reset signal is high, can I break the path between the reset input and the write_clk for all recovery paths inside the fifo?

With the read requests setup the way it is, can I break all paths from the reset on the rd_clk domain?

Can you suggest some SDC commands to break paths that do not need to be analysed?

Thanks.

Kevin

to customer

Hello Kevin,

Thanks for your feedback. Here you the answers to your further questions.

1. If i can ensure that a write request does not occur on the first three clock after the reset signal is high, can I break the path between the reset input and the write_clk for all recovery paths inside the fifo?

--Yes.

2. With the read requests setup the way it is, can I break all paths from the reset on the rd_clk domain?

--Yes.

3. Can you suggest some SDC commands to break paths that do not need to be analysed?

-- When using the Quartus® II TimeQuest Timing Analyzer and your design contains a DCFIFO megafunction, you must apply the following false paths to avoid timing failures in the synchronization registers.

http://www.altera.com/support/kdb/solutions/rd12032007_130.html?gsa_pos=2&wt.oss_r=1&wt.oss=dcfifo solution

I have checked you SDC files and find the above false paths have been added in it.

Hope it is helpful to you. Please let me know if you have further question on this issue. Thanks.

Best Regards,

Altera

And attached is the archive of a test project i provided to them just for reference.

Thanks Kevin, the example makes it very easy to discuss. I know this is an old thread, but can you post the changes that support mentions making to the .sdc? (Or any alternative solution you've found?)

Neither the kdb link nor the .sdc in the .qar seem to address the aclr reset input paths that you are talking about. (& that I care about :) )

The easiest way to reproduce the violation I'm concerned about is to use your fifo_test qar, but change the timing.sdc file to have a 49MHz clk_out (rd_clk) instead of 50MHz.

When I run that thru Quartus 10.1, I get -0.7ns recover violation to wr_clk.

If I also change aclr to use wr_rstn instead of rd_rstn, I get -1ns recovery violation to rd_clk.

So, what SDC commands do you use to avoid these?

**note: according to http://www.altera.com/literature/ug/ug_fifo.pdf, Quartus 8.1 and newer TimeQuest will automatically add the false paths mentioned in the kdb.**

-Brian

In the sdc file i have two constraints commented out :

# set_false_path -from  -to 
# set_false_path -from  -to 

These can be used to break the reset paths between certain clock domains. With your change, if you used :

set_false_path -from  -to 

You might be able to cut the paths you need. Note that you have to be very cautious when using general constraints like these because it might cut more than you need.

Hope that helps, let me know if it doesn't solve your problem.

**I made that changes you described and compiled in 9.0sp2. Without the new constraint it had recovery failures on the rd_clk domain from wr_rstn to many different paths. With the constraint in there it had no failures.

edited for : spelling errors...

Thanks Kevin. I will have to figure out the SDC commands to narrow the path down, ideally something that just cuts thru the *dcfifo*aclr ports. My trouble is that I'm using SOPC to generate code. SOPC generates resets sync'd to each clock domain, and uses dcfifos in the clock-crossing bridge modules. So even if I find the generated reset signal for each clock domain, I don't want to ignore from clk_A_reset to ALL of the clk_B destinations, otherwise I risk becoming blind to any incorrect usage of clk_A_reset. (Not to mention having to remember to update the constraints everytime I change the SOPC connections.)

Since it's SOPC generated, I had hoped it would just generate something timing clean, and with the type of constraints you asked for in the altera support request (cut thru aclr, at least to rdclk domain). (eg: perhaps cut wherever they sync aclr internal to the module). I'd even prefer the solution in your previous post, to simply use separate clr inputs.

Anyway, it's reassuring to hear that adding false path constraints seems to be required in this situation.

I need to brush up on my SDC anyway (eg: how to make timing analysis catch the recovery violations even if we leave the read clk at 50MHz instead of 49MHz. It's scary that it reports the 50MHz version is timing clean when there's no expressed phase relationship between 50 & 100MHz clks.)