MIG (Memory Interface Generator)

[jim.mer.clay@gmail.com]

I created a DDR2 design using MIG 3.91.  The design has the following ports:

c3_sys_clk (in)

c3_sys_rst_i (in)

c3_clk0 (out)

c3_rst0 (out)

As far as I can tell there are no matching signals described in UG388.  I figure c3_sys_rst_i is probably a new name for "async_rst" (UG388 table 2-4), and c3_sys_clk is probably related to "sysclk_2x" somehow, but it is far from clear.  Can someone please point me to a newer revision of UG388, or some kind of information on the new interface?  Thanks.

[eteam00 · Accepted solution]

I created a DDR2 design using MIG 3.91.  The design has the following ports:

c3_sys_clk (in)

c3_sys_rst_i (in)

c3_clk0 (out)

c3_rst0 (out)

These are inputs and outputs from the memory controller design generated by MIG.

As far as I can tell there are no matching signals described in UG388.  I figure c3_sys_rst_i is probably a new name for "async_rst" (UG388 table 2-4), and c3_sys_clk is probably related to "sysclk_2x" somehow, but it is far from clear.  Can someone please point me to a newer revision of UG388, or some kind of information on the new interface?  Thanks.

UG388 describes the Spartan-6 MCB.  MCB is not the whole memory controller, it is a hard macro core.  MIG generates additional logic and wrapper code, including instantiation of the MCB.  If you look in the MIG-generated files you will see the MCB port connections which match the signal names in UG388 Table 2-4.

The design file hierarchy generated by MIG is described in UG416.  In UG416 version 1.6, the file hierarchy description begins on page 31.

Between UG416 and UG388, you should be able to figure out most (perhaps all) of what you need.  It takes persistence and patience, and there is indeed a fair bit of inconsistency in the documentation.

-- Bob Elkind

[eteam00 · Accepted solution]

I created a DDR2 design using MIG 3.91.  The design has the following ports:

c3_sys_clk (in)

c3_sys_rst_i (in)

c3_clk0 (out)

c3_rst0 (out)

These are inputs and outputs from the memory controller design generated by MIG.

As far as I can tell there are no matching signals described in UG388.  I figure c3_sys_rst_i is probably a new name for "async_rst" (UG388 table 2-4), and c3_sys_clk is probably related to "sysclk_2x" somehow, but it is far from clear.  Can someone please point me to a newer revision of UG388, or some kind of information on the new interface?  Thanks.

UG388 describes the Spartan-6 MCB.  MCB is not the whole memory controller, it is a hard macro core.  MIG generates additional logic and wrapper code, including instantiation of the MCB.  If you look in the MIG-generated files you will see the MCB port connections which match the signal names in UG388 Table 2-4.

The design file hierarchy generated by MIG is described in UG416.  In UG416 version 1.6, the file hierarchy description begins on page 31.

Between UG416 and UG388, you should be able to figure out most (perhaps all) of what you need.  It takes persistence and patience, and there is indeed a fair bit of inconsistency in the documentation.

-- Bob Elkind

[jim.mer.clay@gmail.com]

Thanks.

Why do I get the feeling that documentation is far from Xilinx's top priority?

[jim.mer.clay@gmail.com]

Point taken, but let's not kid ourselves that they are anywhere near the "95%" level.  The plain and simple truth is that there should be something that has a brief description of what each port in the top level generated module does, and as far as I can tell that bare minimum documentation does not exist.  I would have even accepted a one line comment in the generated VHDL next to the port.  Again, that does not exist.  I am reduced to tracing through the VHDL to figure out what the ports do.

I honestly am still not 100% confident that I know what frequency the clk input should be, because figuring out what the PLL_ADV block is doing is non-trivial.  I decided it would be easier to hook it up and simulate it and see what happens.  So please, with all due respect, do not tell me that they are at the 95% level, and that I am some esoteric outlier.

As an engineer of course I get that documentation is a pain.  But I also get that if no one knows how to use your stuff it doesn't matter how cool it is.

Again, though, I greatly appreciate your help.  It is obvious that you do quite a bit to help others in these forums.

[eteam00]

I honestly am still not 100% confident that I know what frequency the clk input should be, because figuring out what the PLL_ADV block is doing is non-trivial.

It's not that difficult.  Well actually it is, and I once went on a posting rampage on this subject.  My last rampage was 17 months ago.  You can read it here.  The executive summary is as follows:

• Let MIG instantiate the "standard" clock and PLL_MCB.

• The "standard" input clock frequency will be the memory clock frequency.  DDR2-800 will use a 400MHz memory (DRAM) clock, with 400MHz input clock.

• Edit the MIG code and pin assignments to use the *real* input clock, and move the clock input and reset input pins to the correct IO banks.  A 50MHz single-ended clock input to the PLL can generate the 200MHz and 400MHz clocks needed by MIG and the MCB, for example).

• Then edit the MIG code (and PLL_MCB attributes) to generate the other fabric clocks you might need or want for the rest of your design.  Most of the PPLL_MCB outputs are otherwise unused, waiting for you to configure them.

I decided it would be easier to hook it up and simulate it and see what happens.  So please, with all due respect, do not tell me that they are at the 95% level, and that I am some esoteric outlier.

I understand the feeling of vendor abuse, but wounds will heal and you will get past these details, successfully.  I am satisfied with at least 95% of the documentation, at least 95% of the time.

Webcase support does a good job of helping me past the rough spots so that I do not wallow in the depths of documentation frustration for too long.  Don't be shy or hesitant about giving the webcase folks a chance to help you.

-- Bob Elkind