cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
1,699 Views
Registered: ‎01-22-2015

report methodology errors and warnings

Jump to solution

I recommend that summary-results for report_methodology be shown on the “Project Summary” page of the Vivado GUI in the same way that summary-results for report_drc are shown.

 

Today, when looking at report_methodology results (which I almost never do – bad me), I found that one of my synchronizers was reported broken by warning PDRC-190 (both registers were not in the same slice).   So, the report_methodology results are important and deserve a prominent place on the “Project Summary” page.

  

-and please elevate “methodology warning PDRC-190” to a critical warning!

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
2,155 Views
Registered: ‎01-23-2009

The fact that the tool flags this as a CDC warning is a "false positive". The structure you show here is perfectly legal. However, I understand why the tools flag it as an error...

 

The CDC warnings are basically a set of heuristics that check for specific structures. From the tools point of view it sees a string of cascaded flip-flops all with the ASYNC_REG property set - this is the rule it uses to identify synchronizer chains. However, they are on different domains, and hence this is a failure.

 

Xilinx could change the rule to recognize that synchronizer chains on different domains are cascaded synchronizers (and not part of the same synchronizer), but this is a very specific case, and generally, it probably makes sense to keep the rule as is (to catch the real mistakes) rather than eliminating this false positive.

 

I know that Xilinx is planning a mechanism of creating waivers for CDC failures - it recognizes that the heuristic for identifying CDC circuits is not perfect (and pretty much can never be perfect) and hence a mechanism for adding waivers is needed. I don't know if the waivers are "mainstream" yet. If so, then you could look at adding a waiver, but the fix that you implemented is a good one - it costs 2 FFs and adds more latency to the deassertion of the later domains, but neither of these are significant issues...

 

Avrum

View solution in original post

2 Replies
Highlighted
1,669 Views
Registered: ‎01-22-2015

My comments about broken synchronizers may have some of you worried – perhaps bringing back memories of old versions of Vivado that had trouble with the ASYNC_REG=TRUE property. Rest assured that Vivado v2017.3 is handling this property correctly … and that I was doing some weird stuff.

 

Specifically, I was cascading reset-bridges as described by the following figure from a paper <here> by Cummings & Mills.  The reason for cascading reset-bridges is that it makes the resets in each clock-domain come off sequentially – rather than all-at-once.

Cummings_Fig13_B.jpg

 

The two registers of the reset-bridge act as a two-register synchronizer.  -and I dutifully set ASYNC_REG=TRUE for these registers. The result being that every register shown in the above figure has the property, ASYNC_REG=TRUE.  Hence, Vivado thinks that the cascaded reset-bridges are one big multi-register synchronizer and tries to put all the registers into one SLICE – and couldn’t – hence the PDRC-190 warning. 

 

My solution was to add an extra register to the output of each reset-bridge and to set ASYNC=REG=FALSE for this extra register.  Now, for each reset-bridge, Vivado places the synchronizer registers into the same slice and does not issue the PDRC-190 warnings.

 

Highlighted
Guide
Guide
2,156 Views
Registered: ‎01-23-2009

The fact that the tool flags this as a CDC warning is a "false positive". The structure you show here is perfectly legal. However, I understand why the tools flag it as an error...

 

The CDC warnings are basically a set of heuristics that check for specific structures. From the tools point of view it sees a string of cascaded flip-flops all with the ASYNC_REG property set - this is the rule it uses to identify synchronizer chains. However, they are on different domains, and hence this is a failure.

 

Xilinx could change the rule to recognize that synchronizer chains on different domains are cascaded synchronizers (and not part of the same synchronizer), but this is a very specific case, and generally, it probably makes sense to keep the rule as is (to catch the real mistakes) rather than eliminating this false positive.

 

I know that Xilinx is planning a mechanism of creating waivers for CDC failures - it recognizes that the heuristic for identifying CDC circuits is not perfect (and pretty much can never be perfect) and hence a mechanism for adding waivers is needed. I don't know if the waivers are "mainstream" yet. If so, then you could look at adding a waiver, but the fix that you implemented is a good one - it costs 2 FFs and adds more latency to the deassertion of the later domains, but neither of these are significant issues...

 

Avrum

View solution in original post