01-23-2013 07:09 AM
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.l4' at site SLICE_X17Y63, On Instance dd/dd/lk.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...
01-24-2013 06:44 AM
01-23-2013 07:27 AM
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" *)
mux ( .I0(1'b1),
01-23-2013 12:54 PM
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?
01-24-2013 04:34 AM
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.l4' at site SLICE_X17Y63, On Instance dd/dd/lk.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...
01-24-2013 06:07 AM
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.
01-24-2013 06:15 AM
LOCK_PINS ALL should be apllied to the COMP not the individual nets.
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" *)
01-24-2013 06:44 AM
01-24-2013 06:47 AM
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.