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
ISE/EDK12.2 Translate fails with "NgdBuild:467 - output pad net 'Ddr_Ck_N_0_OBUF' has an illegal buffer" and similar messages.
Started by ●October 13, 2010
Reply by ●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
Reply by ●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 ●October 14, 20102010-10-14
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.htmI 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 ●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 ●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 ●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 ●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 ●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 ●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 :( > > /MikhailYeah, 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
