"Implement Design" Error on ISE 6.3 webpack

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

Reply to
gallen
Loading thread data ...

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.

Reply to
Gabor

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.