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

------------------
ERROR:Pack: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>)
    PAD symbol "Ddr_A<11>" (Pad Signal = Ddr_A<11>)
    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 

http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ise_c_imple=
ment_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=3Dngdbuild

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=A0pm, "MM" <mb...@yahoo.com> wrote:
> Another mistery in ISE12.3. I am getting a bunch of errors during MAP pha=
se,
> which all look like this:
>
> ------------------
> ERROR:Pack:2811 - Directed packing was unable to obey the user design
> =A0 =A0constraints (LOC=3DR29) which requires the combination of the symb=
ols
> listed
> =A0 =A0below to be packed into a single IOB component.
>
> =A0 =A0The directed pack was not possible because: More than one pad symb=
ol.
> =A0 =A0The symbols involved are:
> =A0 =A0 BUF symbol "Ddr_A_11_OBUF" (Output Signal =3D Ddr_A<11>)
> =A0 =A0 PAD symbol "Ddr_A<11>" (Pad Signal =3D Ddr_A<11>)
> =A0 =A0 PAD symbol "Phy2_Mdio" (Pad Signal =3D 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 an=
d 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

On Oct 15, 5:35=A0pm, 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=3Dngdbuild
>
> ie ngdbuild reads the UCF file and outputs the constraints in the .ngd
> file. =A0You need to rerun ngdbuild.
>
> --steve
>
> On Oct 15, 4:13=A0pm, "MM" <mb...@yahoo.com> wrote:
>
> > Another mistery in ISE12.3. I am getting a bunch of errors during MAP p=
hase,
> > which all look like this:
>
> > ------------------
> > ERROR:Pack:2811 - Directed packing was unable to obey the user design
> > =A0 =A0constraints (LOC=3DR29) which requires the combination of the sy=
mbols
> > listed
> > =A0 =A0below to be packed into a single IOB component.
>
> > =A0 =A0The directed pack was not possible because: More than one pad sy=
mbol.
> > =A0 =A0The symbols involved are:
> > =A0 =A0 BUF symbol "Ddr_A_11_OBUF" (Output Signal =3D Ddr_A<11>)
> > =A0 =A0 PAD symbol "Ddr_A<11>" (Pad Signal =3D Ddr_A<11>)
> > =A0 =A0 PAD symbol "Phy2_Mdio" (Pad Signal =3D Phy2_Mdio)
>
> > The problem is that R29 was indeed in the past assigned to Phy2_Mdio, b=
ut 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 time=
s...
> > 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

"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 

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

On Oct 15, 2:13=A0pm, "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

On Oct 19, 12:48=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
> On Oct 15, 2:13=A0pm, "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.

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. 

On Oct 19, 2:18=A0pm, "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

"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 

On Oct 20, 2:04=A0pm, "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.