Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎04-05-2018

How to hook up mig content

I've been having a devil of a time getting mig generated content to work.  I'm a super-noob so I think this is a very general process goof on my part, but I need a hand learning how to get over the hump.   I guess I am coming from programming and I expect MIG to generate libraries that should compile by themselves.  However, I'm finding that this is not the case.  You definately just can't just use the instance template.  It appears that you have to have a working source/sink for the mig wires and if you don't it dies.  I would characterize it as if a single hair is out of place, the project won't compile, I get 3,000 warnings (typical for mig) and the errors are super cryptic.  


I'm using an atlys board and ISE 14.7.  


Um so, I'm going to upload a project that doesn't have a source/sink for the mig files.  It's a derivative of Joel's MIG tutorial from this location:



the error is:

ConstraintSystem:58 - Constraint <NET
"*/memc3_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/selfrefresh_mcb_mode" TIG;> [atlys.ucf(153)]: NET
de" does not match any design objects.


I know WHAT is wrong, but I don't know how a reasonable person would DEBUG this problem.  I don't know WHY its wrong.  Can you guys guide me into the right way to use MIG and how to debug it when something is amiss?


Thanks very much



0 Kudos
1 Reply
Registered: ‎04-05-2018

I figured out how to negotiate the warnings after sleeping on it for awhile.  It was really basic stuff.

The mig tutorial doesn't put much emphasis on basic ipcore use processes, such as editing the generated ucf file so the net and inst addresses match your project structure.  IE in order to overcome the "XXX does not match any design objects." I just had to prepend memory_demo_top/memory_wrapper/ddr2/ to those entries that had long addresses, since that's the order I instantiate the modules.  

After doing that, I ran into an issue where one of the ucf insts was not connected to the top, so it was being optimized out of the design during the mapping stage. Instead of writing a driver for this net, I discovered using the "keep" attribute, which worked really well. 

Finally, I was getting a similar problem where the clock connections were throwing errors ultimately because some of the clock modules were getting optimized out of the project.  The keep trick didn't work here, but I was able to fix it by using the schematic view and seeing that some of the ports weren't being fed correctly between all the hierarchial module layers.  So i just had to futz around and make sure the net names were right.

Overall this was a great learning experience and I'm a lot less pessimistic about the whole thing.