Answers Database EDIF2XNF error 6, "module.eds" not found in directory: possible causes Record #762 Product Family: Software Product Line: Mentor Product Part: edif2xnf Problem Title: EDIF2XNF error 6, "module.eds" not found in directory: possible causes Problem Description: 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: 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 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: 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 4: 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. Solution 5: 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 6: 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 7: 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 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 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 10: 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. End of Record #762 - Last Modified: 05/19/99 15:02

For the latest news, design tips, and patch information on the Xilinx design environment, check out the Technical Tips!