MIG (Memory Interface Generator)

[bsutin]

I am trying to re-create and document an existing core. The DDR2 memory is flakey in my new version, and the major difference between the two is that the old .UCF file has a bunch of timing constraints from MIG.  I have all of the original MIG project files.  Is there some way to figure out what the original inputs to MIG were so that I can repeat the steps?

Secondly, I tried using the old MIG project to verify the new core's .UCF file. The tool was happy with the data, strobe, mask, clock, address, and bankaddress lines, but stopped with, "ERROR: All the dqs signal(s)/pin(s) are missing."  Any idea what that means? The core with this .UCF file works for 3 of every 4 bytes.

Brian

[rcingham]

"Is there some way to figure out what the original inputs to MIG were so that I can repeat the steps?"

There should be a .XCO file, which is human-readable. As it is an old project, unfortunately the .ISE file is not really human-readable.

You will need DQS signals. Exactly where in the tool chain did that error message occur? If you want useful help, post the message verbatim (HINT: copy+paste), with more context.

[jschmitz_dup2]

Do you have the 'mig.prj' file?  That should have all the settings used.

What version of MIG are you using?  What device family?

[bsutin]

I am using MIG 2.3 for a Spartan-3A DSP with MT47H128M16HG-3 DDR2.  The .xco file only has information about the device.  The .prj file does appear to have all the inputs in .xml format.  There is also a file called datasheet.txt that has most of the input as well.

The original MIG project was used to choose the nets that go to the DDR2, and the custom board was built to that.  When I run that original project in "verify .ucf" mode, I get the error in the original post. The DQS nets are clearly in the .ucf file.

What is bizarre is that if I run "verify UCF" against the original working core's UCF file, I get an error about duplication on almost every net in the system.

[bsutin]

Update:  I took the old MIG output file, removed all of the NET statements referring to specific pins, and tucked it into the folder with the .XBD file.  When I rebuilt the core, it worked perfectly.  I take this to mean that there is nothing wrong with my .UCF file.  MIG v2.3 just can't read it correctly.

[jschmitz_dup2]

Note that MIG is very picky about the format of the UCF file.  You must have exactly the same syntax and format of the nets and pins for it to recognize them.  It's best to take the UCF output of MIG directly and edit only the pins and then feed that back into the Verify function.  But you may already be doing that.

Also, you are using a fairly old version of MIG.  The most current version might be 3.61 if I'm not mistaken.

I suspect that you could recreate your design with the information in the .prj and the datasheet.txt file.

The S3 design is very stringent about the DQ and DQS placement.  It is using a template router that cannot tolerate random changes.  there is a very fixed pattern that it can use.  I believe this is explained in the User Guide, UG086.

[bsutin]

Thanks. The UCF file is written by the BSB, and I don't hand edit it afterwards, so there isn't anything special about the DQS nets. Hopefully by the time I need to run the MIG again, we will have upgrades to a newer version.