Old LOC constraint stuck somewhere

[MM]

Another mistery in ISE12.3. I am getting a bunch of errors during MAP phase,
which all look like this:

------------------
ERRORack:2811 - Directed packing was unable to obey the user design
constraints (LOC=R29) which requires the combination of the symbols
listed
below to be packed into a single IOB component.

The directed pack was not possible because: More than one pad symbol.
The symbols involved are:
BUF symbol "Ddr_A_11_OBUF" (Output Signal = Ddr_A<11&gt
PAD symbol "Ddr_A<11>" (Pad Signal = Ddr_A<11&gt
PAD symbol "Phy2_Mdio" (Pad Signal = Phy2_Mdio)


The problem is that R29 was indeed in the past assigned to Phy2_Mdio, but it
is commented out in the .ucf file I searched through the whole project and I
can't find where it is getting this from... I deleted all files I could
imagine could have this information. I cleaned the project several times...
All to no avail...

Where else can Xilinx store pad location constraints?

Thanks,
/Mikhail

 

[MM]

"Gabor" <gabor@alacron.com> wrote in message
news:cdfbe883-cd35-4406-be45-f6434ef6fe74@c10g2000yqh.googlegroups.com...

The standard answer to all of this kind of horse-s**t is to "cleanup
project files"
which forces the tools to re-run everything. I found in some versions
that
"cleanup project files" did not clean enough and I had to remove the
projectname>_xdb folder in the project directory to really clean out
everything.

Well I did all of that and I am still getting the same errors!

/Mikhail

 

[Rob Gaddi]

On 10/15/2010 3:43 PM, MM wrote:

"Gabor"<gabor@alacron.com> wrote in message
news:cdfbe883-cd35-4406-be45-f6434ef6fe74@c10g2000yqh.googlegroups.com...

The standard answer to all of this kind of horse-s**t is to "cleanup
project files"
which forces the tools to re-run everything. I found in some versions
that
"cleanup project files" did not clean enough and I had to remove the
projectname>_xdb folder in the project directory to really clean out
everything.

Well I did all of that and I am still getting the same errors!

/Mikhail

Possibly it's in one of your source files? Recursive grep the whole
damn project looking for "R29", see if anything turns up.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

 

[steve ravet]

http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ise_c_implement_fpga_design.htm

"The Translate process merges all of the input netlists and design
constraints and outputs a Xilinx Native Generic Database (NGD) file,
which describes the logical design reduced to Xilinx primitives. See
the following table for details. "

translate=ngdbuild

ie ngdbuild reads the UCF file and outputs the constraints in the .ngd
file. You need to rerun ngdbuild.

--steve



On Oct 15, 4:13 pm, "MM" <mb...@yahoo.com> wrote:

Another mistery in ISE12.3. I am getting a bunch of errors during MAP phase,
which all look like this:

------------------
ERRORack:2811 - Directed packing was unable to obey the user design
   constraints (LOC=R29) which requires the combination of the symbols
listed
   below to be packed into a single IOB component.

   The directed pack was not possible because: More than one pad symbol.
   The symbols involved are:
    BUF symbol "Ddr_A_11_OBUF" (Output Signal = Ddr_A<11&gt
    PAD symbol "Ddr_A<11>" (Pad Signal = Ddr_A<11&gt
    PAD symbol "Phy2_Mdio" (Pad Signal = Phy2_Mdio)

The problem is that R29 was indeed in the past assigned to Phy2_Mdio, but it
is commented out in the .ucf file I searched through the whole project and I
can't find where it is getting this from... I deleted all files I could
imagine could have this information. I cleaned the project several times....
All to no avail...

Where else can Xilinx store pad location constraints?

Thanks,
/Mikhail

 

[Gabor]

On Oct 15, 5:35 pm, steve ravet <steve.ra...@gmail.com> wrote:

http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ise_c...

"The Translate process merges all of the input netlists and design
constraints and outputs a Xilinx Native Generic Database (NGD) file,
which describes the logical design reduced to Xilinx primitives. See
the following table for details. "

translate=ngdbuild

ie ngdbuild reads the UCF file and outputs the constraints in the .ngd
file.  You need to rerun ngdbuild.

--steve

On Oct 15, 4:13 pm, "MM" <mb...@yahoo.com> wrote:

Another mistery in ISE12.3. I am getting a bunch of errors during MAP phase,
which all look like this:

------------------
ERRORack:2811 - Directed packing was unable to obey the user design
   constraints (LOC=R29) which requires the combination of the symbols
listed
   below to be packed into a single IOB component.

   The directed pack was not possible because: More than one pad symbol.
   The symbols involved are:
    BUF symbol "Ddr_A_11_OBUF" (Output Signal = Ddr_A<11&gt
    PAD symbol "Ddr_A<11>" (Pad Signal = Ddr_A<11&gt
    PAD symbol "Phy2_Mdio" (Pad Signal = Phy2_Mdio)

The problem is that R29 was indeed in the past assigned to Phy2_Mdio, but it
is commented out in the .ucf file I searched through the whole project and I
can't find where it is getting this from... I deleted all files I could
imagine could have this information. I cleaned the project several times...
All to no avail...

Where else can Xilinx store pad location constraints?

Thanks,
/Mikhail

The standard answer to all of this kind of horse-s**t is to "cleanup
project files"
which forces the tools to re-run everything. I found in some versions
that
"cleanup project files" did not clean enough and I had to remove the
<projectname>_xdb folder in the project directory to really clean out
everything. I think 12.2 does a better job of cleanup, but I wish
Xilinx
could just figure out that trying to save us a few seconds on every
run
by not compiling EVERYTHING ends up costing hours of debugging the
tools.

Regards,
Gabor

 

[MM]

Well, it turned out ISE was picking up either system.ncf or system.ucf
created originally by the EDK wizard I believe. They were not explicitly
included in the project as far as I could tell.

/Mikhail





"Ed McGettigan" <ed.mcgettigan@xilinx.com> wrote in message
news:e11fa579-3812-4793-899d-d8c9e9390361@w38g2000pri.googlegroups.com...
On Oct 19, 12:48 pm, d_s_klein <d_s_kl...@yahoo.com> wrote:

On Oct 15, 2:13 pm, "MM" <mb...@yahoo.com> wrote:



Where else can Xilinx store pad location constraints?

Thanks,
/Mikhail

There are constraint files created by the Memory Interface Generator.

RK

There are too possibilities that come to mind:
1) The LOC constraint is embedded in the NGC file from synthesis
2) The LOC is inferred from the connectivity and placement of the
other elements

Ed McGettigan
--
Xilinx Inc.

 

[d_s_klein]

On Oct 15, 2:13 pm, "MM" <mb...@yahoo.com> wrote:

Where else can Xilinx store pad location constraints?

Thanks,
/Mikhail

There are constraint files created by the Memory Interface Generator.

RK

 

[Ed McGettigan]

On Oct 19, 12:48 pm, d_s_klein <d_s_kl...@yahoo.com> wrote:

On Oct 15, 2:13 pm, "MM" <mb...@yahoo.com> wrote:



Where else can Xilinx store pad location constraints?

Thanks,
/Mikhail

There are constraint files created by the Memory Interface Generator.

RK

There are too possibilities that come to mind:
1) The LOC constraint is embedded in the NGC file from synthesis
2) The LOC is inferred from the connectivity and placement of the
other elements

Ed McGettigan
--
Xilinx Inc.

 

[d_s_klein]

On Oct 19, 2:18 pm, "MM" <mb...@yahoo.com> wrote:

Well, it turned out ISE was picking up either system.ncf or system.ucf
created originally by the EDK wizard I believe. They were not explicitly
included in the project as far as I could tell.

/Mikhail

If you read the fine print in the command-line documentation, it
mentions files that are scanned if they exist and are not specifically
excluded with a command-line option. No warning/error message if they
don't exist, no log message if they do.

Be wary of any file that has the same name as your top level module.

RK

 

[MM]

"d_s_klein" <d_s_klein@yahoo.com> wrote

If you read the fine print in the command-line documentation, it
mentions files that are scanned if they exist and are not specifically
excluded with a command-line option.

I've read the fine print and I couldn't find why it is doing what it is
doing. I think it is just yet another bug...

No warning/error message if they don't exist, no log message if they do.

For some bizzare reason I am not surprized....

/Mikhail

 

[Ed McGettigan]

On Oct 20, 2:04 pm, "MM" <mb...@yahoo.com> wrote:

"d_s_klein" <d_s_kl...@yahoo.com> wrote



If you read the fine print in the command-line documentation, it
mentions files that are scanned if they exist and are not specifically
excluded with a command-line option.

I've read the fine print and I couldn't find why it is doing what it is
doing. I think it is just yet another bug...

No warning/error message if they don't exist, no log message if they do..

For some bizzare reason I am not surprized....

/Mikhail

I'm not sure where it is documentated, but the ISE software tools have
always picked up the NCF, UCF and PCF file extensions that match the
base name of the file that is being processed (NGC, EDIF, or NGD).

Ed McGettigan
--
Xilinx Inc.