1. Home
  2. Field-Programmable Gate Arrays
  3. UCF-File problem

UCF-File problem

While compliling my VHDL design with XILINX ISE, I received the following error concerning a IO-constraint:

Annotating constraints to design from file "noc_top.ucf" ... ERROR:NgdBuild:755 - Line 7 in 'noc_top.ucf': Could not find net(s) 'lclk' in the design. To suppress this error specify the correct net name or remove the constraint. The 'Ignore I\O constraints on Invalid Object Names' property can also be set ( -aul switch for command line users). ERROR:Parsers:11 - Encountered unrecognized constraint while parsing. ERROR:NgdBuild:19 - Errors found while parsing constraint file "noc_top.ucf".

In the design top level file, lclk is an input port.

Entity of TOP-LEVEL-VHDL-File: entity noc_top is port( lclk : in std_logic; boardout : out std_logic_vector(6 downto 0); anode : out std_logic); end noc_top;

Corresponding UCF-File ########################################################## NET "lclk" LOC=3D"T9"; NET "boardout" LOC=3D"E13"; NET "boardout"

If I change the port name simultaneously in the design file and in the ucf, the error is still indicated.

Does is depend on the port direction (all output port are mapped correctly) ?

Any ideas ??? J=FCrgen

Reply to
foag
Loading thread data ...

[snip]

if your input port is optimized away then it comes non-existant and UCF mapper will fail

--
Antti Lukats
http://www.xilant.com
Reply to
Antti Lukats

Hi Antti, if I have a look into the generated "View RTL Schematic" (*.ngr), I can see the input port "lclk"

Reply to
foag

schrieb im Newsbeitrag news: snipped-for-privacy@g43g2000cwa.googlegroups.com...

well if the lclk is retained after that then it isnt the problem, but RTL view doesnt mean that the lclk do not get optimiued away later so check if it is really used and not optimized, for testing uncomment the ucf and check if lclk is mapped to some pin or not, if it is then the UCF should work as well

--
Antti Lukats
http://www.xilant.com
Reply to
Antti Lukats

Just try anode

Reply to
Brad Smallridge

snipped-for-privacy@iti.uni-luebeck.de schrieb am 11.01.2006 17:49:

Removal of signals due to optimization happens at later stages in the flow, so what you see in the schematic view is not really representative.

If "lclk" is not used anywhere in your design, it is optimized away. The tools can backtrace something like that several stages, so it doesn't have to be really obvious. As an example: if you clock a single flipflop with "lckl", but the asynchronous reset for the FF is permanently active, some tools may recognize that the clock is not really relevant and remove it. You should check your design for things like this, or maybe post a code snippet here so we can have a look.

There's a configuration switch you can set to "Allow unmatched LOC"-attributes which would allow you to finish the flow despite of the error, but that's not what you want since obviously there's something wrong with your design which you otherwise wouldn't notice.

cu, Sean

Reply to
Sean Durkin

Sean Durkin wrote: [snip]

Actually this can be quite useful, since you'll have the reports that follow the "translate" process. This can show you whether your clock has actually been removed from the design or somehow got re-named so it didn't match the LOC constraint. A look at the pad report can show this problem.

Godd luck, Gabor

Reply to
Gabor

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.