We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome,
Internet Explorer 11,
Safari. Thank you!
General Description: As I translate a design, the Logical Design DRC reports the following messages regarding multiple drivers and illegal connections:
ERROR:basnu - logical net "$Net00014_" has multiple drivers ERROR:basnu - input pad net "$Net00014_" has illegal connection
WARNING:basnu - logical net "$Net00051_" has no driver WARNING:basnu - output pad net $Net00051_" is not driven by an output symbol WARNING:basnu - output pad net '$Net00052_" has no legal driver
These messages may be caused by a macro sheet that is inadvertently included as a top-level sheet in Foundation Project Manager.
In Foundation Project Manager, the top-level schematics are listed in the hierarchy browser with .sch extensions. Verify that each schematic listed in the browser is a top-level sheet. If there are any macros or other sheets that are not actually supposed to be top-level objects, select each sheet (one at a time) and remove it by going to Document -> Remove.
Doing this does not delete the schematic -- it only removes it from the top-level project view. Now, re-run M1 Design Manager by clicking on the M1 icon within Foundation Project Manager.
This scenario of the accidental specification of a lower-level sheet as top-level presents a problem, as this may cause signal name collisions. Ordinarily, a macro net may be given the same net name (by the software) as a top-level net; because the design is hierarchical, the full name of the macro net will be qualified by its position in the design hierarchy.
If a macro is incorrectly referred to as a top-level module, the hierarchical path part of the name is lost, and the macro and top-level nets end up with the same names, causing the multiple driver errors.
Multiple Project (.pdf) files and/or multiple top-level EDIF (.edn) files may also exist within the project directories.
- Exit Foundation and open up Windows Explorer (Windows 95/NT_.
- Verify that the project file "project_name.pdf" is in the project's root directory (e.g., c:\active\projects).
- Look in the project's sub-directory (e.g., c:\active\projects\project_name) for another "project_name.pdf" file. If it exists there, delete this second .pdf file.
- Also, if the top-level EDIF file (project_name.edn) exists in this sub-directory, delete it. If there is a copy of the top-level EDIF file in the root directory, delete it from this location as well.
- Now, delete the "xproj" directory (c:\active\projects\project_name\xproj) so that M1 can update it. To do this, re-start Foundation, then re-invoke M1 Design Manager.
This problem can also occur when XNF files are merged from CORE Generator into a Foundation F3.1i schematic.
COREGen uses the Foundation program "NET2SYM" to generate a Foundation symbol for an IP core function. In F1.4, this program appears to also merge the XNF file for the core into the Foundation .alr file (when it should actually be treating it as a "black box"). Then, at the "Export Netlist" step, it writes out an invalid EDIF file, which generates the "multiple driver" error in NGDBuild.
The work-around is to manually force the regeneration of the .alr and symbol for the COREGen block using a different route. To do this, copy the .xsf and .xnf files generated by COREGen to a new project directory. Then, run "Create Macro Symbol from Netlist" on the Core XNF file.
In F1.4, running "Create Macro symbol from Netlist should not merge the XNF into the .alr file. Verify that the generated symbol has the required "$EXPORT=NO" property attached to it, as this prevents the associated XNF file from being merged into the output EDIF file when you run "Export Netlist."