cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ssampath
Voyager
Voyager
974 Views
Registered: ‎10-12-2016

Incremental implementation PAR issue and ERROR duing bitstream generation ?

Jump to solution

Hi Friends,

Am using VCU118 and vivado 2019.1.

when i am using  incremental implementation am getting the following WARNING during PLACE AND ROUTE and then ERROR during the bit file generation.

Phase 13.3 Additional Hold Fix
CRITICAL WARNING: [Designutils 20-756] Invalid physical equation for the G6LUT bel in site SLICE_X120Y205. The original INIT is '2'. The logical cell is 'u_garnet_top/O_hier_hold_fix'. Reason: The bit width of the INIT value does not match the number of used input pins '0'. Please verify that all required logical pins are used for this cell.
Bel 33: element name: 'G6LUT'
Attr: 'EQN' Value: 2'h2
Pin : index 5: A6 : VCC Physical-only net
Inst: 'O_hier_hold_fix'
CellType: 'LUT1'
Pin Swappable:
Not assigned -> Bel pin 'A1'
Not assigned -> Bel pin 'A2'
Not assigned -> Bel pin 'A3'
Not assigned -> Bel pin 'A4'
Not assigned -> Bel pin 'A5'
Not assigned -> Bel pin 'A6'

 

Any help or suggestions are highly appreciated.

ERROR: [DRC PDIL-1] Invalid Site Configuration: Invalid configuration for site SLICE_X156Y206. Reason: illegal pin placement

 

-Sampath

-Sampath
Tags (1)
0 Kudos
1 Solution

Accepted Solutions
syedz
Moderator
Moderator
709 Views
Registered: ‎01-16-2013

@ssampath 

 

Thanks for the update. This is a known issue with Vivado Incremental which will be fixed in 2020.2 release. 

We have a patch for 2019.2 and 2020.1 release which will fix this bug. If you are willing to upgrade to any of these two versions then please do let us know so that I can share the patch file with you.

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
6 Replies
chinmays
Xilinx Employee
Xilinx Employee
942 Views
Registered: ‎06-27-2018

Hi @ssampath,

Can you test your design in Vivado 2019.2 once ? If possible, please provide a testcase so that we can reproduce the issue at our end. Send me your email id in private message, I will send your our ftp link (ezmove). For now, please provide implementation runme.log generated after you encounter the error.

~Chinmay

0 Kudos
ssampath
Voyager
Voyager
907 Views
Registered: ‎10-12-2016

Please find the attached log file.

-Sampath
0 Kudos
syedz
Moderator
Moderator
844 Views
Registered: ‎01-16-2013

@ssampath 

 

I have sent you a private message. Please check and respond back. We need the design files to debug the issue and provide you a workaround.

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
ssampath
Voyager
Voyager
717 Views
Registered: ‎10-12-2016

Hi @syedz , 

As design in developement stage my manager not willing to send data to outside{Company confidential}. Currently am proceeding with skipping Incremental Impl. 

1) i don't to why tool throwing error like mentioned above even though the changes are less than 5%. 

2) if tool unable to do Incremental then it should able to switch to normal mode. this is not happening simply it throwing error during bit stream.

 

Thank You for spending time. 

-Sam

-Sampath
0 Kudos
syedz
Moderator
Moderator
710 Views
Registered: ‎01-16-2013

@ssampath 

 

Thanks for the update. This is a known issue with Vivado Incremental which will be fixed in 2020.2 release. 

We have a patch for 2019.2 and 2020.1 release which will fix this bug. If you are willing to upgrade to any of these two versions then please do let us know so that I can share the patch file with you.

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
surajc
Moderator
Moderator
700 Views
Registered: ‎01-30-2019

Hi @ssampath ,

Can you share the schematic of this LUT? Check if the LUT is present after synthesis if present share its post synth schematic and its properties, if it is not present after synthesis hold fix is possible reason for the existence of this LUT

Can you check if any input of the LUT was optimized during the implementation flow? 
I would suggest you check this in the log, any property like opt_modified, phys_opt_modified on the primitives at the input and output of the LUT's, and also the LUT

Also, a LUT1 with init property of 2 is a simply a dummy LUT used to fix hold violations ( Added by post place Phys opt design while aggressive hold fixing ) and the Inst: 'O_hier_hold_fix' tells that it was indeed added to fix hold violation.