The following error occurs in NGDBuild:
"ERROR:NgdBuild:455 - %s net '%s' has multiple drivers. Xvendor=%s Xleid=%d Xhiername=%s"
This error indicates that a pin on an element has either more than one signal driving it, or it has more than one source. The following are reasons why this error occurs and possible solutions to remedy this issue:
- Multiple IBUF (and OBUF) type components are connected in series. Examples of IBUF-type components that should not be connected together include the following: IBUFx; IFDDRx; and BUFGP.
Solution: check for macros (similar to IFDDRx) in the Libraries Guide and ensure that they are not being driven by an IBUF in your design.
- Design contains an IBUF with no loads.
Solution: remove this IBUF to eliminate the error.
- Multiple IP core signals drive the same signal without tristate code.
Solution: to help in debugging multi-source, use the XST hierarchical separator "/" instead of the default "_". Now the "/" is used to traverse the design hierarchy instead of "_", which minimizes confusion caused by using "_" in signal names.
- These errors typically show up when the netlists created were synthesized with the option to include I/O buffers. The default for XST is to have "Add IO buffers" checked. If all of the I/O signals for this block already have IBUFs and OBUFs, when you try to include this in an EDK design, PlatGen places additional I/O buffers. Consequently, these errors occur since there are two sets of buffers (multiple drivers).
Solution: to work around this issue, uncheck the option and re-synthesize the design.
- There are likely IP core ports in the EDK system that instantiate input I/O buffers (such as IBUF) that are not connected to top-level ports. The EDK Platform Generator ties off this port to ground with the GND primitive and the net_gnd net. Then NGDBuild infers a port (pad) for this buffer, which creates an illegal connection between a pad, GND, and input buffer.
Solution: to resolve this error, check the MHS against the MPD files for each core to verify that all ports with instantiated I/O buffers (indicated with a IOB_STATE of BUF or REG) are connected to the top of the MHS. Alternatively, the I/O buffers can be removed from the core.
- IBUFG between cascaded DCM/DLL components
Solution: make sure that there is not an IBUFG between the output of the first DCM and the input of the second DCM.