Answers Database

EDIF2XNF error 6, "module.eds" not found in directory: possible causes


Record #762

Product Family:  Software

Product Line:  Mentor

Problem Title:
EDIF2XNF error 6, "module.eds" not found in directory: possible causes


Problem Description:
Keywords: edif2xnf, error 6, contents, men2xnf8

Urgency: Standard

General Description:

While running Men2XNF8, you may encounter the following error during
EDIF2XNF:

   Error: 6 EDIF data "bad.eds" not found in directory
      "/usr/xact/data/unified/edif4000"
   Cell BAD_MODULE is not a recognized Xilinx primitive component;
   This means that there is no CONTENTS record found in this cell.
   Consult the EDIF2XNF documentation to find out how to map foreign
   primitives to Xilinx components or fix the EDIF input file.
   Make sure the EDIF data files are installed in the XACT directory.

This indicates that the module in question is either a primitive for which
the resulting component description is missing, or a macro which was somehow
written to the EDIF file as a primitive.  There are several causes for this.


Solution 1:

You may have mistyped the device number on the Men2XNF8 command line.  For
example, you typed:

   men2xnf8 -p 4013pq208-4 my_chip

when you really meant to type:

   men2xnf8 -p 4013epq208-4 my_chip

In this case, EDIF2XNF would have looked in the $LCA/data/unified/edif4000
directory for primitive description files, instead of the correct
$LCA/data/unified/edif4000e.  Out of this arises a similar situation as in
Item 9:

   Error: 6 EDIF data "ofdx.eds" not found in directory
      "/usr/xact/data/unified/edif4000"

The OFDX primitive (which is exclusively an XC4000E component) in this
example does not exist at all (much less as a primitive) in the XC4000
library.



Solution 2:

The design has a mixture of components from different families.  The
component in question exists in one library but not the other.	All
Xilinx components in a design must come from the library of a
single
device family.



Solution 3:

A bug in MEN2XNF8 version 5.2.1 may cause EDIF2XNF error 6 when targeting
an XC4000L device.  This will occur if your design contains synchronous
RAMs (e.g., RAM16X1S) or clock-enabled I/O flip-flops (e.g., IFDX):

   Error: 6 EDIF data "ifdx.eds" not found in directory
      "/usr/xact/data/unified/edif4000"

If you look at your men2xnf8.log file, you will see a line that starts like
this:

   edif2xnf .../design.edif -l /usr/xact/data/unified/edif4000 ...

Men2XNF8 is telling EDIF2XNF to look in the edif4000 directory for EDIF
descriptions.  However, it SHOULD be looking at the edif4000e directory,
since the XC4000L is functionally equivalent to an XC4000E.  The EDIF file
in question (e.g., ram16x1s.eds) is in edif4000e, but NOT in edif4000;
therefore EDIF2XNF says the EDIF data file does not exist because it is
looking for it in the wrong area.  Men2XNF8 only specifies edif4000e to
EDIF2XNF if the device suffix is "E"; it does not do the same if the suffix
is "L".

A patch is available on the Xilinx FTP site that fixes Men2XNF8 by allowing
it to recognize XC4000L parts as devices which use the XC4000E library
components.  (It also fixes Fncsim8 and Timsim8, which suffer from similar
problems.)  The patch can be downloaded from:

   ftp://ftp.xilinx.com/pub/swhelp/mentor/men_4kl.tar.Z

A README file is included.  Once the patch is installed, delete the "xnf"
translation viewpoint underneath the top-level component directory, then
rerun Men2XNF8.  For more information on deleting viewpoints, see (Xilinx
Solution 766).



Solution 4:

You have attempted to retarget a design to a device family different from
the one associated with the library used to build the design.  One example
where this may happen is if you have built a design using XC4000
components, but specify and XC4000E part on the men2xnf8 command line:

   Error: 6 EDIF data "ofd.eds" not found in directory
      "/usr/xact/data/unified/edif4000e"

The problem is that certain parts are primitives in the schematic library
with which the design was built, but are macros in the library associated
with the device you are trying to target.  In this example, OFD is a
primitive in the XC4000 library but is a macro in the XC4000E library
(since it has underneath it the clock-enabled OFDX).

In this example, here is what happens.	ENWrite (Mentor's EDIF netlister)
looks at the XC4000 version of OFD in the schematic.  This component has
attached to it a COMP=OFD property, which tells ENWrite that this component
is a primitive and should be written as such in the EDIF file.	EDIF2XNF
then takes this primitive description and looks for the corresponding
ofd.eds file in the $LCA/data/unified/edif4000e directory, which contains
EDIF descriptions for primitives.  Since OFD is not a primitive in the
XC4000E family, the ofd.eds file does not exist in the directory, which
brings about error 6.

The correct OFD from the XC4000E library has no COMP=OFD property on it,
since the COMP property in XACT is reserved for primitives.  Therefore, if
the correct XC4000E component had been used, ENWrite would have written out
the hierarchy below OFD.  Then, EDIF2XNF would have never seen the OFD
"primitive" and would have never tried to look for a non-existent ofd.eds
file in the XC4000E data directory.

The proper way to retarget a design to a new device family is to first use
the Convert Design utility in PLD_DA before running the implementation
flow.  Convert Design replaces the library components in a schematic or set
of schematics so that they come from the proper library.  For instructions
on how to use Convert Design, see Solution 798, "Retargeting a design in
Mentor Design Architect (Convert Design)."



Solution 5:

The design has a mixture of obsolete and Unified library components.  The
component in question exists in one library but not the other.	All Xilinx
components in a design must use one library or the other.



Solution 6:

The design uses Unified libraries, and the -l option has not been specified
on the EDIF2XNF command line.  This typically happens when you write your
own Mentor-to-Xilinx translation script, instead of running Men2XNF8.

EDIF2XNF, by default, tries to get .eds EDIF descriptions from the
obsolete-library area, $LCA/data/edif____, as opposed to the Unified area,
$LCA/data/unified/edif____.  Therefore, if you are using Unified components
and omit the -l option in EDIF2XNF, you will may get an error similar to
the following:

Error: 6 EDIF data "fdce.eds" not found in directory "/usr/xact/data/edif4000"

Note that the "unified" subdirectory is missing.

To fix this problem, simply add the -l option to the EDIF2XNF command line,
specifying the entire path to the Unified area.  For example, with XC4000
designs, the option would read:

   edif2xnf -l $LCA/data/unified/edif4000 ...



Solution 7:

The top-level XNF viewpoint has been corrupted.  (This viewpoint, called
"xnf", can be found in the component directory.)  Delete the XNF viewpoint
(see (Xilinx Solution 766) for instructions) and try again.



Solution 8:

The component is indeed a primitive (e.g., AND2), but the corresponding
and2.eds file is missing from the $LCA/data/unified/edif4000 directory.
(There are also directories edif2000, edif3000, etc.)  Reinstall the Mentor
Interface (DS344) to correct this.



Solution 9:

The schematic registration for the component has been lost.  This usually
happens in situations where a component has been copied to a new component
name.  To correct this, go into the Component Interface Browser:

   % cib bad_module

At the CIB prompt:

   bad_module::bad_module > view

You will see a listing structured like the following:

   ** view
      COMPONENT  bad_module	DEFAULT INTERFACE IS:  bad_module

	 INTERFACE:  bad_module
	    PINS:
	       (list of pins)
	    BODY PROPERTIES:  (list)
	    INTERFACE MODEL ENTRIES:
	    Model Entry     Type     Model Info
	       (list)

Note that there may be more than one INTERFACE line; the interface we care
about is the one named in the DEFAULT INTERFACE field.

A registration model entry looks like this:

      0 mgc_symbol     Path: $my_design/bad_module/bad_module
			 Labels: 'default_sym'
			 Status: Valid for interface; Valid for property

In a correct component interface, there should also be an entry of type
"mgc_schematic"; if this does not exist, then the component does not know
what schematic represents it, so it is written out as a primitive.

To correct the component interface in this example:

   > register_model $my_design/bad_module/schematic mgc_schematic

(The "register_model" command may be abbreviated "rm".)

If you type "view" again in CIB, you should see the following new model
entry:

      1 mgc_schematic  Path: $my_design/bad_module/schematic
		       Labels: '$schematic' 'schematic' 'default'
		       Status: NOT valid for interface; NOT valid for property

(The "NOT valid" status is not important.)

Save this interface, then exit CIB:

   > save
   > quit

Reprocess the schematic through Men2XNF8.



Solution 10:

The component has been described as a primitive by the addition of a COMP
property on the symbol.  (You can do a Report Object or Properties Modify
in Design Architect to verify this.)  Remove the COMP property from the
symbol, then reprocess the design.



End of Record #762