cancel
Showing results for 
Search instead for 
Did you mean: 
Observer
Observer
3,705 Views
Registered: ‎08-10-2009

Inconsistent phys_opt_design behavior

Jump to solution

Hi,

 

We've got two builds of the same source code with different results that we are trying to understand.

 

Target: UltraScale Kintex xcku115

Vivado version: 2016.3

 

On one build, we push our design through the tools "as is" and meet timing. For the second build, we run an obfuscation utility on our source code, which basically replaces all VHDL names, variables, parameters, etc. with an encrypted alphanumeric code. But when we push this obfuscated code through the tools, it fails timing by a significant margin (TNS > 300 nsec).

 

We have been running these two types of builds for months on this project and haven't noticed this type of disparity until now.

 

When we analyzed the log files during implementation, we see an interesting difference in the post-place phys_top_design phase.

 

In the non-obfuscated build, the tool seems to spend on the various stages of this phys_top_design, addressing fanout, DSP regs, BRAM, etc. It spends a total of almost 21 minutes during this stage. As I mentioned, this build meets timing.

 

But in the obfuscated build, the log file indicates for some strange reason that the tool skips over most of these post-place phys_opt_design phases, except for 49 seconds in the very high fanout stage and 7 seconds in the critical path stage. Instead of spending 21 minutes like the non-obfuscated build, it spends only 57 seconds. The result is that this build fails timing significantly.

 

It's as if the phys_top_design tool for some reason isn't able to perform as it should with the obfuscated code. As I mentioned, the obfuscated code is simply replacing all the names. The rest of the VHDL is the same.

 

Are there any "quirks" or requirements of the phys_top_design that come to mind that could explain my this might be happening?

 

BTW, the implementation settings are identical for both builds (Performance_Explore* strategy).

 

Thanks for any insight.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
6,203 Views
Registered: ‎08-10-2009

Re: Inconsistent phys_opt_design behavior

Jump to solution

Despite both builds using default (optimistic?) wire delays going into placement, it appears that a WNS of -79 psec was just enough to trigger all the post-place phys_opt_design activity for the passing (non-obfuscated) design, whereas in the failing (obfuscated) build), looks like WNS was -3 psec, perhaps not enough to trigger all that placement optimization which in the end saved the non-obfuscated build while dooming the obfuscated one.

 

For now, it appears that the near term solution is to use the ExtraNetDelay option for the post-place phys_opt_design effort. But of course, we'll also address still trying to improve our margins in the source code.

 

I'll leave this open for a bit in case anyone else has any more comments about the phys_opt_design behavior (always nice to get more insight, especially for any 'tendencies' that are undocumented, like at what threshold does the phys_opt_design trigger?).

View solution in original post

0 Kudos
6 Replies
Highlighted
Xilinx Employee
Xilinx Employee
3,688 Views
Registered: ‎09-20-2012

Re: Inconsistent phys_opt_design behavior

Jump to solution

Hi @jcappello

 

Can you upload the implementation log files of both the designs?

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Highlighted
Moderator
Moderator
3,671 Views
Registered: ‎11-09-2015

Re: Inconsistent phys_opt_design behavior

Jump to solution

Hi @jcappello,

 

If you are changing the name in the VHDL, could it be possible that you forget to change names in the constraints files (.xdc) and so that some constraint are not applied (a false path for example)?

 

Regards,

 

Florent


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Highlighted
Observer
Observer
3,656 Views
Registered: ‎08-10-2009

Re: Inconsistent phys_opt_design behavior

Jump to solution

Thanks for the replies! I have to check (for confidentiality reasons) whether I can upload the complete logs, but below I have inserted excerpts below.

 

The utilization numbers are practically identical (the slice/clb/regs are within < 0.5%, the BRAM and DSP48 usage is identical).

 

The constraint files were deemed identical. The few obfuscated names mentioned (our top wrappers on the designs are not obfuscated) were cross-checked for accuracy.

 

What would make the tool skip over most of the phases of the phys_opt_design for a design that's going to fail timing miserably?

 

Here is a summary of the post-place phys_top_design successful non-obfuscated build (as you can see it addresses several issues here, spending almost 20 minutes in this phase):

 


-----------------------------------------------------------------------------------------------------------------------------------------------------------------
|  Optimization       |  WNS Gain (ns)  |  TNS Gain (ns)  |  Added Cells  |  Removed Cells  |  Optimized Cells/Nets  |  Dont Touch  |  Iterations  |  Elapsed   |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
|  Fanout             |          0.000  |          0.000  |          154  |              0  |                    50  |         141  |           3  |  00:09:59  |
|  Placement Based    |          0.000  |          0.000  |            0  |              0  |                    46  |      119289  |           3  |  00:06:21  |
|  Rewire             |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           3  |  00:00:00  |
|  Critical Cell      |          0.000  |          0.000  |            0  |              0  |                     0  |         774  |           3  |  00:00:06  |
|  DSP Register       |          0.000  |          0.000  |          176  |              0  |                     5  |        7584  |           1  |  00:00:49  |
|  BRAM Register      |          0.012  |          0.010  |          181  |              0  |                    12  |           0  |           1  |  00:01:34  |
|  Shift Register     |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  Very High Fanout   |          0.000  |          0.000  |           11  |              0  |                     7  |           0  |           1  |  00:00:47  |
|  Critical Pin       |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  Critical Path      |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:04  |
|  Total              |          0.012  |          0.010  |          522  |              0  |                   120  |      127788  |          16  |  00:19:39  |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------

 

 

Here is a summary of the post-place phys_opt_design failing obfuscated build (as you can see it skips most of these steps, spending just 47seconds in this phase):

 


-----------------------------------------------------------------------------------------------------------------------------------------------------------------
|  Optimization       |  WNS Gain (ns)  |  TNS Gain (ns)  |  Added Cells  |  Removed Cells  |  Optimized Cells/Nets  |  Dont Touch  |  Iterations  |  Elapsed   |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
|  Fanout             |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  Placement Based    |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  Rewire             |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  Critical Cell      |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  DSP Register       |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  BRAM Register      |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  Shift Register     |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  Very High Fanout   |          0.000  |          0.000  |           11  |              0  |                     7  |           0  |           1  |  00:00:43  |
|  Critical Pin       |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:00  |
|  Critical Path      |          0.000  |          0.000  |            0  |              0  |                     0  |           0  |           0  |  00:00:04  |
|  Total              |          0.000  |          0.000  |           11  |              0  |                     7  |           0  |           2  |  00:00:47  |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------

 

BTW, just to add more clues: I did another run for my failing obfuscated database where I actually addressed some of the timing violations known in the design by modifying the source code. The result was that it failed timing. But interestingly, this same phys_opt_design phase looked about the same as in the failing case, where the tool spent just 48 seconds on it. So it's as if the tool enters the post-place phys_opt_design phase in the obfuscated failing case thinking it is in good shape when it is not.

 

0 Kudos
Highlighted
Observer
Observer
3,652 Views
Registered: ‎08-10-2009

Re: Inconsistent phys_opt_design behavior

Jump to solution

CORRECTION: In my last "BTW," I stated that the result was that it failed timing. It had in fact passed timing. That was the point. I modified some source code to improve timing margins, it passed timing, and the phys_opt_design phase went along very similarly to the failed build. Sorry for the confusion.

0 Kudos
Highlighted
Observer
Observer
3,647 Views
Registered: ‎08-10-2009

Re: Inconsistent phys_opt_design behavior

Jump to solution

I think we're getting close. When we apply "ExtraNetDelay" to the failing OBF placement, the tool does go through that post-route phys_opt_design task similarly as it does in the passing case. It greatly improves the timing down to < 300 psec TNS after route, which we presume will probably get eliminated during post-route optimization.

 

So the theory is that the post-placement delays between the two routes are just slightly different enough that for one build this kicks in a lot of post-place phys_opt_design, whereas for the other build it just skips through. And for that latter case, the post-route delays are just too much to overcome. So the moral of the story would be to apply more negative estimate on placement wire delays.

 

Still investigating...

0 Kudos
Highlighted
Observer
Observer
6,204 Views
Registered: ‎08-10-2009

Re: Inconsistent phys_opt_design behavior

Jump to solution

Despite both builds using default (optimistic?) wire delays going into placement, it appears that a WNS of -79 psec was just enough to trigger all the post-place phys_opt_design activity for the passing (non-obfuscated) design, whereas in the failing (obfuscated) build), looks like WNS was -3 psec, perhaps not enough to trigger all that placement optimization which in the end saved the non-obfuscated build while dooming the obfuscated one.

 

For now, it appears that the near term solution is to use the ExtraNetDelay option for the post-place phys_opt_design effort. But of course, we'll also address still trying to improve our margins in the source code.

 

I'll leave this open for a bit in case anyone else has any more comments about the phys_opt_design behavior (always nice to get more insight, especially for any 'tendencies' that are undocumented, like at what threshold does the phys_opt_design trigger?).

View solution in original post

0 Kudos