03-13-2011 06:33 PM - edited 03-13-2011 06:35 PM
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.
EDIT: I am using Xilinx 12.4 and Modelsim 10.0
03-20-2011 08:22 PM
04-24-2011 02:55 PM
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.
08-05-2012 12:47 PM
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.
08-05-2012 01:23 PM
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