We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!


ML605 MIG Reference Design

Posts: 8
Registered: ‎03-13-2011

ML605 MIG Reference Design

[ Edited ]



I am trying to use a memory controller to communicate my design with the DDR3 memory on the ML605 board.


I downloaded the MIG reference design found under ML605 Documentation but I have problems to run it error free. The reference design was missing the ddr3_model.v and parameters files so I copied those files from a MIG project I created using core generator.


When I run the simulation I see the following error all over my simulation log file even though I didn't change anything in the reference design other than some lines causing compilation error (for signals sda and sca).


ERROR: tCK(avg) maximum violation by 1700.000000 ps.


When I upload the overbuilt bit file on my board I can see the heartbeat but the simulation doesn't seem to work and I don't want to start editing parts of it before I get a working simulation. I let the simulation run until it stopped saying : "TEST FAILED: CALIBRATION DID NOT COMPLETE ".


Also my simulation takes a lot of time. I read the new MIG has some extra options to reduce simulation time but the MIG given for ML605 is version 3.4. Do you advise me to start an MIG design using the core generator from scratch? I found the PDF file explaining the modifications for MIG to run it on ML605. I was hoping the given design would be sufficient though.


Any advice?




EDIT: I am using Xilinx 12.4 and Modelsim 10.0

Posts: 426
Registered: ‎05-21-2008

Re: ML605 MIG Reference Design

I think you can generate MIG design based on your SODIMM and actual frequency. Also choose pin-out of ML601. Then, use user design in your project. This will generate correct simulation file.

I think you simulation command is not consistent with example design. You can check it.
Posts: 2
Registered: ‎04-24-2011

Re: ML605 MIG Reference Design

I'm deeply dissapointed with the quality of MIG core. I guess how many ML605 boards already sold and how many man-hours of your customers spent to find out and fix induvidually bad work of MIG team.

The simulation problem for ML605 MIG is resolved by changing one symbol: DIVCLK_DIVIDER = 1 (default 2) in sim_tb_top.v

No magic. No extraordinary efforts. Actually I don't understand why MIG ML605 configuration hasn't been included in coregen yet and especially I don't understand why such elementary simulation update wasn't include in deducated 'ml605_MIG_rdf0011' reference desing (there is /sim, but doesn't work! Funny?)

Moreover, I'd like to see the author of 'sim.do' file in MIG reference /sim who written "vlog ../sim/sim_tb_top.* ". Just FYI: modelsim creates .v.bak files. What do you think happens when you edit DIVCLK_DIVIDER = 1 in msim editor and recompile your design? Right - updated file overwrites during compilation by old version. Welcome to infinity debug.

I understand example is example, free of garantee, etc - but just write it with elementary common sense - it makes impression about whole product.

Xilinx Employee
Posts: 174
Registered: ‎09-22-2008

Re: ML605 MIG Reference Design

The following AR http://www.xilinx.com/support/answers/33376.htm may help in relation to your case.
Posts: 2
Registered: ‎05-31-2011

Re: ML605 MIG Reference Design

The error still there in MIG 3.7 (ISE 13.1.)


Posts: 2
Registered: ‎05-31-2011

Re: ML605 MIG Reference Design

thanks for your tip on changing sim_tb_top.v file. Did you also manage to get past 'TEST FAILED: DATA ERROR' failure cause by asserted 'error' wire?
Posts: 2
Registered: ‎01-11-2012

Re: ML605 MIG Reference Design

I agree with you.

I think they want to share verilog and VHDL simulation with the same .do script....

Posts: 2
Registered: ‎01-11-2012

Re: ML605 MIG Reference Design

When I changed DIVCLK_DIVIDER = 1 (default 2) in sim_tb_top.v, the simulation passed. Maybe something in the RTL script needs to modify according to ML605 MIG demo.
Posts: 95
Registered: ‎08-05-2012

Re: ML605 MIG Reference Design

Mahesh, can you please explain the relationship between rounding error and the DIVCLK_DIVIDE needing to be changed from 2 to 1 for the ML605 XTP047 simulation to work?  I saw all the errors that others talked about on ISE 13.4 (which should have fixed the problem according to your post), so I am even more confused.  It would be quite refreshing to see an "solution" which explains thoroughly and clearly why the problem was there in the first place, what the proposed fix was, and why that fixes the problem.


IMHO, MIG falls short in the similar way that the PCIe example XAPP1052 did: you just throw some huge, complicated example at the user with cursory explanation and expect the user to figure out everything.  I've written a lot of tutorials and design documents in the past, and were always dissatisfied with (smart) engineers who hate explaining their work.  I understand DDR3 is complicated, so it would be quite a project to to start with a "Hello DDR3" type of example, and increase the sophistication with each iteration.  Maybe it's Xilinx strategy to de-emphasize that kind of rational step-by-step introduction to a complicated technology; I suppose there is no incentive to do a better job with documentation if the technology sells itself--because the poor engineers using Xilinx have no choice but to bloody their head against the wall debugging the example.  Now that I've gotten the phy_init_done to assert (at simulation time 51.725 ns), I am going to have to stare at all the rest of the code in the example, trying to change the traffic pattern to better fit my scenario.  Wouldn't it have been nice if instead XTP047 started with writing and reading 1 byte (or a whole data width), and tackle bursting later?


In my experience, sometimes the relunctance to explain one's work in an accessible manner is motivated by the need to hide one's poor understanding of his own work.  Whoever created the MIG example_design gets a C for documentation.


A minor point, but I think there is little value in providing the "user_design" next to the "example_design", because once I figure out how example_design works, why would I waste my time debugging something that is not quite the same?  Wouldn't it have been more logical to use the same core in the example design?


As mstsvetk pointed out, this whole experience is enourmously frustrating and infuriating.

Posts: 8,355
Registered: ‎07-21-2009

Re: ML605 MIG Reference Design

Mahesh, can you please explain the relationship between rounding error and the DIVCLK_DIVIDE needing to be changed from 2 to 1 for the ML605 XTP047 simulation to work?


Are you referring to the Answer Record 33376 dated June 2011 which addresses a problem which was (supposedly) solved in ISE 11.4 (we're currently at 14.2)?


Based on personal experience, complaining about the overall structure of the example design may feel good for a few hours or so, but it isn't a long-term answer to your (or my) frustration. Some suggestions to consider...


1.  Update to a current SW release, ISE13.4 or later.

2.  Accept the (likely) need to slog through the debugging task, one small (and specific) problem at a time.


-- Bob Elkind

README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.