Why no recovery paths were found?

[Altera_Forum]

In TimeQuest Clock Transfer folder, I can see that there are 720 RR paths from CLKA to CLKB. But when I try to make timing report about these paths, it told me that no recovery paths were found. WHY??

[Altera_Forum]

There are probably no synchronized reset paths that originate in the CLKA domain but reset registers in the CLKB domain…which is most likely a good thing :-) I would guess there are 720 setup (data) paths between these domains.

[Altera_Forum]

Are you sure you're looking at Recovery Paths? RR usually means Rising to Rising transfers, which would show up in setup/hold analysis.

[Altera_Forum]

I don't think that my system has 720 RR paths from CLKA to CLKB, but timequest reports that. So I just to confirm whose are these paths, but it tells me no recovery paths found as well as removal paths, setup paths and hold paths.

[Altera_Forum]

I can't do much more without the design(perhaps some screenshots, but not sure if that will show what's going on or not.) I would trust the report_timing reports more than the Clock Transfer reports, but you may want to file an SR or something if you don't get to the bottom of it.

[Altera_Forum]

The screenshots shows below, hope it could help: 

http://blogimg.chinaunix.net/blog/upfile2/080114111512.jpg

[Altera_Forum]

You just have a single report_timing with the -recovery option shown. What happens if you run the same command(up arrow) and change this to -setup?

[Altera_Forum]

Yes, if change it to -setup, it will report setup paths timing. 

But I am confused that TimeQuest report there exist 720 recovery path but not setup paths.

[Altera_Forum]

Yeah, I missed that it was a Recovery Transfer report. Strange. You probably want to file an SR, as it doesn't make sense to me. (You could try making an .sdc file without any set_false_path or set_clock_group assignmnets and run the same commands with that. Maybe the Clock Transfers report is looking at false paths while the report_timing definitely does not.)

[Altera_Forum]

Yeah, you are correct. 

set_false_path is the root reason.  Sorry for the stupid question. Thanks!

[Altera_Forum]

That still seems odd. As you can see in your screenshot, even false-path transfers get listed. They just have "false path" instead of a number in the table.

[Altera_Forum]

I thought of a possible explanation for what bothered me in my previous post, but I didn't test it to see whether TimeQuest works this way. 

 Maybe for the transfer table to say "false path", the false-path has to be done from clock domain to clock domain instead of another way like from a particular source register to a particular destination register. If that's the case and paths that are false because of "set_false_path -from src_reg -to dst_reg" get listed in the transfer table with a number (even if all paths on the row of the table are actually false), then it would make sense that you could have all 720 paths in question cut with a register-to-register false-path exception, keeping report_timing from listing anything even though the transfer table doesn't say "false".

[Altera_Forum]

Yes, based on my study, your description is quite precise. :)