"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:tpegb654veim0lpmar5aut1bgus5v9cfb3@4ax.com...
>
> I strongly recommend going back to the Answer Record you found, giving
> feedback
> that it no longer works with ISE12, and outlining what worked instead.
>
It turns out I was wrong and it does work. Shame on me... I was adding
search path to ngbuild instead of XST...
/Mikhail
Reply by Gabor●October 15, 20102010-10-15
On Oct 14, 6:07=A0pm, "MM" <mb...@yahoo.com> wrote:
> > I don't have the exact answer, but after looking at
> >http://www.xilinx.com/support/answers/37204.htm
> > my next move would be to find the 12.x Constraints Guide (cgd.pdf) and
> > look up
> > the =A0"buffer_type" attribute - is there a "none" value for it?
>
> > Then try adding
>
> > attribute buffer_type: string;
> > attribute buffer_type of my_sig: signal is "none";
>
> > to all the relevant signals - if you can suppress XST's desire to inser=
t
> > buffers
> > on these specific signals you should be good.
>
> I tried this:
>
> attribute =A0iob: =A0 =A0string;
>
> attribute =A0iob =A0of Ddr_Ck_N =A0: signal =A0is =A0"FALSE";
> attribute =A0iob =A0of Ddr_Ck_P =A0: signal =A0is =A0"FALSE";
> attribute =A0iob =A0of Ddr_A =A0 =A0: signal =A0is =A0"FALSE";
> attribute =A0iob =A0of Ddr_D =A0 =A0: signal =A0is =A0"FALSE";
>
> It results in an internal error in XST :(
>
> /Mikhail
Yeah, the iob attribute just says whether or not to place an instance
in the IOB block vs. using some fabric resource. Generally this is
applied
to flip-flops only.
So telling it not to place a pad net in an IOB would not have good
results.
Regards,
Gabor
Reply by Brian Drummond●October 15, 20102010-10-15
On Thu, 14 Oct 2010 18:41:07 -0400, "MM" <mbmsv@yahoo.com> wrote:
>I had not realized that iob attribute I used was a different attribute.
>Apparently, the buffer_type set to none seems to be working!
>
>Thanks a lot, Brian!!!
I strongly recommend going back to the Answer Record you found, giving feedback
that it no longer works with ISE12, and outlining what worked instead.
Despite the warnings the feedback system gives you, sometimes Xilinx do listen,
and if they update the Answer Record, the information will be useful to others.
- Brian
Reply by Brian Drummond●October 15, 20102010-10-15
On Thu, 14 Oct 2010 18:41:07 -0400, "MM" <mbmsv@yahoo.com> wrote:
>I had not realized that iob attribute I used was a different attribute.
>Apparently, the buffer_type set to none seems to be working!
>
>Thanks a lot, Brian!!!
>
Lost in a maze of twisty little attributes, all alike.
At least you weren't trying to fight all the optimisation stages,and trying to
find the appropriate combination of attributes "keep", "preserve_signal",
"don't_optimise", and "equivalent_register_removal=no"...
- Brian
(whose longer-lived code sometimes looks like a graveyard of dead
attributes....)
Reply by MM●October 14, 20102010-10-14
I had not realized that iob attribute I used was a different attribute.
Apparently, the buffer_type set to none seems to be working!
Thanks a lot, Brian!!!
Reply by MM●October 14, 20102010-10-14
> Alternatively, have there been changes to 12.x's way of handling
> precompiled
> cores?
I guess there have, because it doesn't copy anymore all the ngc files from
the EDK implementation directory to the main project folder, only the
system.ngc....
/Mikhail
Reply by MM●October 14, 20102010-10-14
> I don't have the exact answer, but after looking at
> http://www.xilinx.com/support/answers/37204.htm
> my next move would be to find the 12.x Constraints Guide (cgd.pdf) and
> look up
> the "buffer_type" attribute - is there a "none" value for it?
>
> Then try adding
>
> attribute buffer_type: string;
> attribute buffer_type of my_sig: signal is "none";
>
> to all the relevant signals - if you can suppress XST's desire to insert
> buffers
> on these specific signals you should be good.
>
I tried this:
attribute iob: string;
attribute iob of Ddr_Ck_N : signal is "FALSE";
attribute iob of Ddr_Ck_P : signal is "FALSE";
attribute iob of Ddr_A : signal is "FALSE";
attribute iob of Ddr_D : signal is "FALSE";
It results in an internal error in XST :(
/Mikhail
Reply by Brian Drummond●October 14, 20102010-10-14
On Thu, 14 Oct 2010 10:54:12 -0400, "MM" <mbmsv@yahoo.com> wrote:
I don't have the exact answer, but after looking at
http://www.xilinx.com/support/answers/37204.htm
my next move would be to find the 12.x Constraints Guide (cgd.pdf) and look up
the "buffer_type" attribute - is there a "none" value for it?
Then try adding
attribute buffer_type: string;
attribute buffer_type of my_sig: signal is "none";
to all the relevant signals - if you can suppress XST's desire to insert buffers
on these specific signals you should be good.
Alternatively, have there been changes to 12.x's way of handling precompiled
cores? If so, there may be messages in the synthesis report hinting why it can't
find the precompiled MPMC core, and that it is "black boxing" the core for
NGDbuild to deal with. Making XST see the cores is the best answer, but failing
that, the "buffer_type" constraints ought to work.
This is all the more frustrating because the EDK cores like MPMC are supplied as
source, and the only reason they have to be precompiled (thus hiding the buffers
from XST) is because the Xilinx tools can't handle VHDL libraries.
(versions 6.x to 11, I haven't tested 12 yet)
- Brian
Reply by MM●October 14, 20102010-10-14
Yes, sorry, it's here:
http://www.xilinx.com/support/answers/32847.htm
/Mikhail
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:g3mdb6t8pcvphccc7av2roq1icb1u383a6@4ax.com...
> On Wed, 13 Oct 2010 19:38:35 -0400, "MM" <mbmsv@yahoo.com> wrote:
>
>>The project has top level in ISE and it includes a PPC subsystem. The
>>problem seems to be with the latest MPMC core, which, at least in DDR2
>>mode,
>>instantiates IOs in the source code. There is a Xilinx Answer Record for
>>this exact problem, but with regards to ISE11. However, the proposed
>>solution doesn't work. Has anyone experienced this and found a workaround?
>
> It might be useful to mention which Answer Record.
>
> - Brian
>
Reply by Brian Drummond●October 14, 20102010-10-14
On Wed, 13 Oct 2010 19:38:35 -0400, "MM" <mbmsv@yahoo.com> wrote:
>The project has top level in ISE and it includes a PPC subsystem. The
>problem seems to be with the latest MPMC core, which, at least in DDR2 mode,
>instantiates IOs in the source code. There is a Xilinx Answer Record for
>this exact problem, but with regards to ISE11. However, the proposed
>solution doesn't work. Has anyone experienced this and found a workaround?
It might be useful to mention which Answer Record.
- Brian