UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
1,319 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
Historian
Historian
1,775 Views
Registered: ‎01-23-2009

Re: report methodology errors and warnings

Jump to solution

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

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

Re: report methodology errors and warnings

Jump to solution

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.

 

Historian
Historian
1,776 Views
Registered: ‎01-23-2009

Re: report methodology errors and warnings

Jump to solution

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