XMM (RAM Initialization) File

The XMM file defines the initial contents of the RAMs in the design for the simulator. An XMM file is only created if the design contains RAMs. Some simulators require an XMM file; other simulators can read the RAM initialization directly from the output EDIF file and do not need a separate XMM file. The way you use the file depends on the simulator vendor you specify with the -v option to NGD2EDIF.

• If you are using a Viewlogic simulator (-v viewlog), an XMM file is created in LOADM format for use by ViewSim. See the “Timing Simulation” chapter in the Viewlogic Interface Guide for information on loading the XMM file into ViewSim.
  
  
• If you are using a Mentor Graphics simulator (-v mentor), no XMM file is created. QuickSim takes the RAM initialization information directly from the EDIF netlist.
  
  
• If you are using another simulator (no -v option), an XMM file is generated in a generic format, which is described in the next section. Your simulator may or may not need this separate file; consult your vendor's documentation for details.
  
  

Note: RAM initialization data is not created for the Virtex Block RAM.

Generic File Format for XMM File

This section describes the format of the generic XMM file, which is created when the vendor (-v) option is not specified for NGD2EDIF. Consult you simulator vendor's documentation to determine how to use this generic XMM file.

In most cases you do not need to understand the format of the generic XMM file. The following information is provided for reference.

For ease of processing by scripting languages, the generic initialization file consists of newline-separated records. Each record has the following three tokens, separated by white space, with the position of each token denoting its meaning.

primitive_type instance_name init_value

The tokens are defined as follows.

Primitive_type is the name of a RAM primitive in the SimPrims library. It is a string value.

Instance_name is a hierarchically-qualified instance name for a particular RAM SimPrim in the design. It is a string value. Hierarchical names are separated by the forward slash (/) character.

The instance_name is expressed in terms of the names in the original design, not in terms of the EDIF identifiers. The original names are more likely to correlate to the original design, but are not checked for uniqueness and may not be legal for the simulation interface. The simulation interface must read the generic initialization file to resolve these problems.

Init_value represents the contents of the specified RAM instance. The init_value is a hexadecimal number with a 0x prefix. The most significant bit of this number should be loaded into the highest address of the RAM, continuing so that the least-significant bit is loaded into the lowest address of the RAM. As with the INIT property value, a one-bit-wide RAM is assumed. The number is padded with zeroes so that the number of bits exactly matches the number of addressable locations in the RAM primitive.

Example: Generic Initialization File

An example generic initialization file is shown following.

X_RAMS16 $1I32/$1I47/FIFO/BANK03 0x6A47
X_RAM32 TOP/IFC/DATA/O7 0x003F097D
X_RAMD16 TOP/$3I107/$7I100 0x0000

The generic initialization file also contains several comment lines that document when and how the file was made and describe the file format. Each comment line begins with a pound (#) character; these lines can be ignored by programs using the initialization file.