Tradeoffs Of Enabling & Disabling Source Encryption in Encrypt.tcl

Question

Hey everyone,  
  
I've recently bumped to a newer AMI which brings in Vivado 2020.2, I was previously on 2018.4. I've noticed that Vivado has gotten much more strict about hiding the names of cells in reports and checkpoints. This makes timing reports for designs that fail to meet timing unusable as debugging tools.  
  
Since we can't afford to rerun the flow on timing failures, to work around this i've removed the calls that encrypt sources in encrypt.tcl. The uploaded DCP is still encrypted, so AGFI generation seems to work OK.   
  
Given this, why is it suggested that we encrypt RTL sources? Does this change if we are not sharing AGFIs outside of our institution?

Answer

Dear customer  
  
Thank you so much for contacting AWS. The "source encrypt.tcl" which encrypts RTL source files is only a recommended step and not required for AWS F1 work flow. This is enabled by default so that all the intermediate dcp files in the build process (for example, post-synth dcp, post place dcp etc) are also encrypted to enable any sharing with others. But this is totally optional and can be removed from the flow, if not required, and is not required for the aws f1 build flow. Please feel free to contact aws if you have further questions on this.   
  
Thanks

Answer

So to confirm if i'm not sharing DCPs outside my organization there's no downside to turning this off? If i do need to share checkpoints with support (for instance) i can always re-enable it.  
  
Thanks!

Answer

correct, if you do not need your intermediate DCPs encrypted you do not need this

Tradeoffs Of Enabling &amp; Disabling Source Encryption in Encrypt.tcl

関連するコンテンツ

Tradeoffs Of Enabling & Disabling Source Encryption in Encrypt.tcl