TimeQuest Invalid Path / Mis-analysis

[Altera_Forum]

Hello, 

 I am running into a situation where TimeQuest reports a recovery violation between two nodes. I cannot figure out how those two nodes could be related. I tracked the nodes in TQ with extra path details and the paths do not make sense - by that I mean that the data path reported by TQ makes a jump from one section of the design to another unrelated section.  I tracked the path in the RTL Viewer and do not see how the two sections could be related.  My question: Is this a plausible mis-analysis by TQ or the path is valid and I am just not seeing the connection?  Thank you so much!

[Altera_Forum]

It's not a mistake by TimeQuest, as it's just looking at the physical layout.  

The one place I see stuff like this is with merged registers, i.e. two might have the same behavior and Quartus merges them, but only keeps one name. It also merges shift registers when making altshift_taps blocks. That all being said, it's only synchronous signals I've seen this confusion occur. A recovery violation involves the asynchronous reset, which has to be common between the two nodes. Actually, thinking about it more, maybe there are two identical circuits that make identical resets, and those got merged? Maybe try Assignmetns -> Settings -> Anaalysis & Synthesis -> Remove Duplicate Registers = Off. I'm not saying that should remain off, but if the problem goes away you'll understand why.

[Altera_Forum]

Rysc, 

 You were correct (of course) - by disabling the removal of duplicate registers, all of the timing violations make sense now.  That being the case, my assumption is that the weird violations I was seeing with that option enabled, are truly false and can be safely ignored. If the register that was combined (and is now hidden) caused a violation, that would then show up as a valid violated path. Is that a safe assumption?  Thank you!

[Altera_Forum]

Did you have a false path on one of the registers and it was merged with a register that didn't have it? Quartus shouldn't be doing that. Or is it a case where neither register had a false path, and they were merged, but when you went in the path didn't make sense? I would just add a false path from the original reset node, and this should cause synthesis to preserve it and not merge it. (If the second register has a similar false path, it might merge them, which would be fine)

[Altera_Forum]

I believe it was the second case. I did not have any false paths on either register. When Quartus did the merge, I guess it thought the two registers were related and flagged the violation. I can see that from the data path it is reporting - QT makes a jump in the middle of the path that does not make any sense. 

 I just created a false path as you suggested in your post and everything is compiling fine. I put a note on the sdc to remind me later that removing the false path exposes the anomaly in case I encounter issues later.  Thank you so much for your help!

[Altera_Forum]

Note that it's not considered wrong, just what Quartus does by default(along with other synthesis tools). If you look at: 

http://www.alterawiki.com/wiki/register_duplication_for_timing_closure Page 11 talks about ways to stop Quartus from removing duplicate registers. (The document is where the user is explicitly duplicating them, where in your case you didn't realize they were duplicates, or at least weren't doing it on purpose. Adding a dont_merge or disabling remove duplicate registers on that particular register might make sense.

[Altera_Forum]

I read your full document. The register in my case is part of my reset sync IP that is stamped out many times throughout the design. While the "(* dont_merge *)" directive seems attractive, it will cause pretty much all of my resets in the design not to be optimized - which would probably be overkill and would ignore registers that can safely be combined. 

What I will do later is disable the merge in Assignment Editor for that register only and see what happens. I am kind of not too comfortable with Quartus making that false analysis, but would like to make sure that I don't actually have an issue that is mis-reported. Too bad this is a big project and can't safely be shared - I would otherwise send it to Altera Support to see what they think.