Recovery - DCFIFO issue

Altera_Forum · ‎07-03-2009

Hi,

I have a design where a block of logic writes data to a DCFIFO at 66MHz and a seperate block reads the FIFO at 0.576MHz and sends the data through a RS232 interface. Also received data from the RS232 interface is written to a sepaerate FIFo at 0.576MHz and then read at 66MHz.

Anyway the problem I had was that timequest gave me some errors regarding removal analysis so what I done was reset both FIFO´s with a reset signal double flopped using the write clock of the respective FIFO´s. I then cut the path between the 2 clocks as follows.


set_false_path -from }] -to }]
set_false_path -from }] -to }]

Timequest now does not produce any warnings regarding recovery analysis but I would be grateful if someone could verify if what I have done would be a normal approach or correct? Is it nessesery to cut the paths betwen the 2 clocks or is there another method that can be employed?

Is recovery analysis always going to be a problem when implementing DCFIFO´s with 2 clocks that bear no relationship?

I would be interested to know what others have done in their experience with this type of issue.

Many thanks

Altera_Forum · ‎07-03-2009

I simply use the following set_false_path entries in my SDC which covers all instances of dcfifo :


set_false_path -from }] -to  
set_false_path -from }] -to

This was taken from following solution on Altera website - what set_false_path assignments should i apply to the dcfifo megafunction when using the timequest timing analyzer? (http://www.altera.com/support/kdb/solutions/rd12032007_130.html)

Altera_Forum · ‎07-03-2009

Thanks avemo for the reponse.

I placed the cosntraints that you suggested instead of the ones I had in place cutting the paths between both clocks, but it gave me the same warnings as before with the recovery.

From reading the link you provided, I understand that the registers in the constraint are the internal registers of the FIFO? I don´t understand what the terms specifically refer to. for example what does rdptr_g and the others specifically refer to?

Anyway it seems that this constraint is nessesery and should be in my .sdc file. Any other information regarding other contraints nessesery to solve the recovery issue would be most welcome.

Many Thanks

Altera_Forum · ‎07-03-2009

Since one clk is slow and one is fast then there is a simple trick to synchronise reset on both clks as follows:


Process
begin
wait until fast_clk = '1';
 
   reset_1d <= reset;
   reset_2d <= reset_1d;
 
   slow_clk_1d <= slow_clk;
   slow_clk_2d <= slow_clk_1d;
   slow_clk_3d <= slow_clk_2d;
 
   if slow_clk_2d = '0' and slow_clk_3d = '1' then
       reset_3d <= reset_2d;
   end if;
 
end process;

As such reset_3d is synchronised to edge of fast clk and occurs shortly after falling edge of slow clk. so violation on slow clk is impossible since reset transition is well ahead of next slow edge.

Note that reset doesn't trigger the slow flips so no double stage registers needed on slow clk.