Answers Database
M1.4/M1.3 NGDBUILD, FOUNDATION. M1.4 COREGEN: ERRORS: basnu - logical net...has multiple drivers, illegal connection, no legal driver, no driver...
Record #2870
Product Family: Software
Product Line: FPGA Implementation
Product Part: ngdbuild
Problem Title:
M1.4/M1.3 NGDBUILD, FOUNDATION. M1.4 COREGEN: ERRORS: basnu - logical net...has multiple
drivers, illegal connection, no legal driver, no driver...
Problem Description:
Urgency: standard
General Description:
When Translating a design from a Foundation Project in M1.3.7,
Logical Design DRC gives messages about 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
ouput symbol
WARNING:basnu - output pad net '$Net00052_" has no legal driver
Solution 1:
Another cause of this problem has been seen when
merging XNF files from the Xilinx CORE Generator into a
Foundation F1.4 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". Subsequently at the "Export
Netlist" step, it writes out an invalid EDIF file which
generates the "multiple driver" error in NGDBUILD.
The workaround is to manually force regeneration of the .ALR
and symbol for the Coregen block using a different route. To
do this, you must 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 shoul
d not merge the XNF
into the .ALR. Verify that the generated symbol has the
required "$EXPORT=NO" property attached to it to prevent the
associated XNF file from being merged into the output EDIF
file when you run "Export Netlist".
This problem is fixed in F1.5.
Solution 2:
Multiple Project (.pdf) files and/or multiple top-level EDIF
(.edn) files may exist within the project directories.
Exit Foundation and open up Windows Explorer 95/NT.
Verify that the Project file 'project_name.pdf' is in the
project's root directory (e.g. c:\active\projects).
Then check in the project's sub-directory
(e.g. c:\active\projects\project_name)
for another 'project_name.pdf' file. If found, delete this second .pdf file.
Also, delete the top-level EDIF file (project_name.edn) from
this sub-directory, if found. If there is a copy of the top-level EDIF file in the root directory,
delete it as well.
Now, delete the xproj directory (c:\active\projects\project_name\xproj)
to allow M1 to update it. Re-start Foundation, then re-invoke
M1 Design Manager.
Solution 3:
Solution 4:
This error may be caused by a macro sheet that is
inadvertently included as a top-level sheet in the Foundation
Project Manager.
In the Foundation Project Manager, the top-level schematics
are listed with .sch extensions in the Hierarchy Browser.
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-l
evel object, select each
sheet (one at a time) and go to Document -> Remove, to remove
them.
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 the Foundation Project
Manager.
The above scenario of accidentally specifying a lower level
sheet as a top-level one presents a problem because it 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 since the design is hierarchical, the full name of the macro net will be qual
ified 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.
End of Record #2870 - Last Modified: 01/29/99 18:43 |
