"Implement Design" Error on ISE 6.3 webpack

Apr 23, 2005 1 Replies

I'm getting an error during the translate portion of the implement design section and I have no clue what it is about:



ERROR:NgdBuild:455 - logical net 'blt_blitter_o_memAddr_cyo' has multiple drivers. The possible drivers causing this are: pin G on block XST_GND with type GND, pin PAD on block blt_blitter_o_memAddr_cyo with type PAD ERROR:NgdBuild:462 - input pad net 'blt_blitter_o_memAddr_cyo' drives multiple buffers. Possible pins causing this are: : pin I on block dll_rstpad with type IBUF, pin I on block w_extCe_OBUF with type OBUF, pin I on block w_fbce0_OBUF with type OBUF, pin I on block w_fbce1_OBUF with type OBUF ERROR:NgdBuild:466 - input pad net 'blt_blitter_o_memAddr_cyo' has illegal connection. Possible pins causing this are: pin G on block XST_GND with type GND, pin DI on block blt_blitter_o_xAddrcy with type MUXCY, pin DI on block blt_blitter_o_xAddrcy with type MUXCY, pin DI on block tv_tvs_hcount_LPM_COUNTER_2__n0000cy with type MUXCY, pin CI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin CI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY ERROR:NgdBuild:466 - input pad net 'blt_blitter_o_memAddr_cyo' has illegal connection. Possible pins causing this are: pin G on block XST_GND with type GND, pin DI on block blt_blitter_o_xAddrcy with type MUXCY, pin DI on block blt_blitter_o_xAddrcy with type MUXCY, pin DI on block tv_tvs_hcount_LPM_COUNTER_2__n0000cy with type MUXCY, pin CI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin DI on block blt_blitter_o_memAddrcy with type MUXCY, pin CI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY, pin DI on block blt_blitter__n0000cy with type MUXCY



I've looked at the xilinx web reference, but I don't have multiple drivers on this signal. The system passes simulation without any warnings, so what might cause this?



I was getting this on other signals, but I changed how they were worded at it went away. For example I had something like this



wire [7:0] gfxinput; wire [3:0] xout; wire [3:0] yout;



gfxmod gfx( .input(gfxinput) );



gfxgen gfxg( .xout(xout), .yout(yout) );



assign gfxinput = {xout,yout};



and that would fail with gfxinput being the error node (gfxgen was driving xout and yout and gfxmod takes them concatenated as input).



I got the error to go away (go to another net anyway) by changing the code to this: wire [3:0] xout; wire [3:0] yout;



gfxmod gfx( .input({xout,yout}) );



gfxgen gfxg( .xout(xout), .yout(yout) );



Does this make sense to anybody? Has this happened to anybody else before?



Thanks for the help, Arlen



type

type

worded

This looks suspiciously like you have a module that was built with IO pads when it was intended to be internal. If for example you infer an IFD (D flip-flop with an IBUF at its D input and IOB=TRUE) instead of an FD (basic CLB D flip-flop), the IBUF forces the place-and-route to instantiate a pad which will also drive the IBUF input in addition to the net you attached to the IFD's D.

If you build a module as a black-box and include it in a top-level design, you need to synthesize with "Add I/O Buffers" unchecked in the Synthesis properties.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required