cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
7,423 Views
Registered: ‎07-17-2012

Constraints 18-5 critical warning on PlanAhead 14.4

Jump to solution

Hi,

I've just downloaded and installed PlanAhead 14.4 and tried to run a project i ran at PA 14.3. In this project I have a LOC on some signals (I manually routed them in FPGA editor and have the constraints on the UCF file and never have I had problems in implementation in earlier versions).

I'm getting the following critical warnings on all manually routed signals:

[Constraints 18-5] Cannot loc instance 'dd/dd/lk[15].l4' at site SLICE_X17Y63, On Instance dd/dd/lk[15].l4 cannot find the input pin ALL and cannot find a proper input pin location while parsing the LOCK_PINS constraint portion ALL [".../TOP.runs/synth_7/top.ngc":684]

And eventually all these signals aren't routed.

Any idea? because I tried looking into it but couldn't find any solution to this problem...

Thanks.

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
9,324 Views
Registered: ‎07-17-2012
Ok, I found the problem, my mistake...

I have 24 instansiation and I use only inst. number 0,1,22 and 23. My 24 inst. are declared in a generic SIZE. Since this generic is defined as 24 there are 20 other inst. which are not used and the critical warnings refer to those.
In 14.3 I didn't have such warning.

I hope these warnings do refer to the 20 which I don't use, so I still can check only the 4 which I'm using (only 4 to save time, for debug only).
Otherwise I can't implelment only 4 in this way, and must implement all 24 which will take alot of time.

Anyway, thanks all for your help!

View solution in original post

0 Kudos
7 Replies
Highlighted
Xilinx Employee
Xilinx Employee
7,422 Views
Registered: ‎06-20-2008

Appears that the tools are confused about the LOCK_PINS ALL constraint. 

Are you using a LOCK_PINS ALL in your UCF?

If so this is not required since the Directed Route LOCKS the pins.

 

Are you using a LOCK PINs in your HDL.  I generally put a LOCK PINs in my HDL when I am creating DIRECTED Routes just to be over cautsious though it should not be needed unless you have a specific pin requirement. This would be an example of LOCK PINs can be used in your HDL.

 

(* LOCK_PINS="ALL" *)
LUT6   #(.INIT(64'hFFFF00FFFF000000))
   mux  ( .I0(1'b1),
          .I1(1'b1),

 

0 Kudos
Highlighted
Scholar
Scholar
7,411 Views
Registered: ‎07-01-2008

What are you trying to constrain and what constraint are you using? A LOC on a net would be valid only to constraint IO. A LOCK_PINS constraint is used to disable pin swapping on LUTs.

 

It's possible that PlanAhead is running some shared Vivado code which handles LOCK_PINS constraints differently than ISE. Vivado has only recently supported ALL as a valid value for LOCK_PINS. Do the constraints work in the standard ISE flow?

0 Kudos
Highlighted
Adventurer
Adventurer
7,401 Views
Registered: ‎07-17-2012

Hi guys,

thanks for answering.

I'm using LOCK PINS and ALL in my vhdl code due to directed routed net I'm using.

 

I'm getting now a bit different critical warning:

[Constraints 18-5] Cannot loc instance 'dd/dd/lk[15].l4' at site SLICE_X17Y63, On Instance dd/dd/lk[15].l4 cannot find the input pin ALL and cannot find a proper input pin location while parsing the LOCK_PINS constraint portion ALL [".../TOP/TOP.runs/synth_7/top.ngc":684]

[Constraints 18-617] Could not create 'LOCK_PINS' constraint because 'invalid pin pair 'ALL''. [".../TOP/TOP.runs/synth_7/top.ngc":686]

 

In my vhdl code I have the following:

attribute lock_pins of l0:label is "all";
attribute lock_pins of l1:label is "all";
attribute lock_pins of l2:label is "all";
attribute lock_pins of l3:label is "all";
attribute lock_pins of l7:label is "all";
attribute lock_pins of l6:label is "all";
attribute lock_pins of l5:label is "all";
attribute lock_pins of l4:label is "all";

 

What does it mean it cannot find a proper input pin location? 

I don't understand these remarks...

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
7,390 Views
Registered: ‎08-14-2012

hi,

 

If the constraint is locked to a NET, then you should check the hierarchy to ensure that there are no other objects between the net and the I/O port. 

PlanAhead tool does not propagate the constraint through the nets as ISE/NGDBuild did, so the Critical Warning occurs.

as an example, the correct pin (xx) is used even though PlanAhead tool removes the constraint because the site being used is for a dedicated feature that requires this pin to be used.  In most cases, when the Critical Warning is issued for a constraint, the site indicated in the constraint will not be used because the UCF file sent to NGDBUILD (written to the runs directory) will not include the constraint.

A possible solution is to assign the constraint to INST on the I/O port instead of using NET.

Another option is to remove the UCF from the PlanAhead project, and instead pass the UCF file through the -uc switch in the NGDBuild options. With this option, the GUI will not show the I/O ports that are fixed, as the project does not have an associated UCF to determine which sites are "fixed," but the implementation tools will see the original UCF constraints and process them as it would when using Project Navigator or ISE command line flow.

 

regards,

saurav

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
7,387 Views
Registered: ‎06-20-2008

LOCK_PINS ALL should be apllied to the COMP not the individual nets.

 

or

LOCK_PINS individually to insrtuct the tool on which pins of the COMP require to be LOCKed.

The commented lins LOCKs ALL of the pins but the next line I specifying which LUT6 pin gets LOCKed to a LUT.

I am not locking the net NAME but locking pins to the LUT

 

// (* LOCK_PINS= "ALL" *)
(* LOCK_PINS = "I5:A6 I4:A5 I3:A4" *)
LUT6   #(.INIT(64'hFFFF00FFFF000000))
              ( .I0(1'b1),
                .I1(1'b1),

                .I2(1'b1),
                .I3(select),
                .I4(tx_clk),
               .I5(rx_clk),
               .O(clock));

0 Kudos
Highlighted
Adventurer
Adventurer
9,325 Views
Registered: ‎07-17-2012
Ok, I found the problem, my mistake...

I have 24 instansiation and I use only inst. number 0,1,22 and 23. My 24 inst. are declared in a generic SIZE. Since this generic is defined as 24 there are 20 other inst. which are not used and the critical warnings refer to those.
In 14.3 I didn't have such warning.

I hope these warnings do refer to the 20 which I don't use, so I still can check only the 4 which I'm using (only 4 to save time, for debug only).
Otherwise I can't implelment only 4 in this way, and must implement all 24 which will take alot of time.

Anyway, thanks all for your help!

View solution in original post

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
7,378 Views
Registered: ‎06-20-2008

Also if you are using these for the Direcected Routes it should not be needed.  LOCK PINS is part of the Directed Route constraint.  The required information for the PINS is encrypted in the Directed Route string.  You just have to LOC the BEL/COMP to the appropriate site and the Directed Route will make sure the same pin is used.

0 Kudos