ISE/EDK12.2 Translate fails with "NgdBuild:467 - output pa

[MM]

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?

The project was originally designed in 8.2 for V4FX (albeit it used much
older MPMC with DDR1, not DDR2), then upgraded to version 10.x and now I am
trying to move it to V5 platform. This is to say that there shouldn't be
anything fundamentally wrong with the project itself. In fact it originally
compiled in 12.2 after the upgrade, even after I had upgraded all the EDK
cores, but then stopped compiling after I had cleaned all the generated
files in ISE...

And I've just tried the same project in ISE/EDK12.3 and got the same result.

Thanks,
/Mikhail

 

[Brian Drummond]

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

 

[MM]

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

 

[Brian Drummond]

On Thu, 14 Oct 2010 10:54:12 -0400, "MM" <mbmsv@yahoo.com> wrote:

Yes, sorry, it's here:
http://www.xilinx.com/support/answers/32847.htm

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

 

[MM]

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

 

[MM]

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

 

[MM]

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!!!

 

[Brian Drummond]

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....)

 

[Brian Drummond]

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

 

[Gabor]

On Oct 14, 6:07 pm, "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  "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

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

 

[MM]

"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