• 0
boyerkg

DDR3 mig 7 traffic control example on nexys video board

Question

H All,

So, I am trying to get a DDR3 test running on the Nexys Video board was to have one of the example designs that had a mig 7 controller for this board generate an example project.  The example project creates a memory traffic controller.  This is a Xilinx generated module/example.

I used that project to update the pin list for the Nexys Video board pins, for everything from the system clock and reset to the compare error output and init calibration complete and of course the DDR3 pins.

I checked the pin list, and everything seems to be hooked up according to the video board schematic.

However, I am not getting the init calibration complete to go high?

Any ideas?

Keith

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

I suggest adding a chipscope to see what is going wrong.

There are some simple issues that can occur -- incorrect frequency for design, incorrect frequency for idelays, incorrect reset polarity, driving user signals before init is done, incorrect DCI configuration -- but it sounds like you have accounted for that.

There are several reasons why init might not finish.  the single IO on the component isn't enough to know what exactly is wrong.

Share this post


Link to post
Share on other sites
  • 0

Question. Are you using VHDL or Verilog? It's been a while since I went down the road you are on.... but I definitely recommend that you choose Verilog when using the MIG tool.

Share this post


Link to post
Share on other sites
  • 0

Thanks All,

The design is a combination of vhdl and verilog.  I have a simulation running that works.  I have confirmed that I have the DDR3 p and n clocks running and responding to the resetn.

I am not getting the DDR3_resetn to go inactive.  The DDR3 clock is at 200Mhz, with the ref clock coming in from "sysclk" at 100Mhz.

The MIG 7 design states 400Mhz.  I don't know how it would know the difference, but I'm pretty sure one needs the reset to go away.

I just checked the pin list for the reset, and it matches the digilent nexys video schematic.

Keith

Share this post


Link to post
Share on other sites
  • 0

@boyerkg,

So ... I have the MIG core up and running with a Verilog interface.  Is this what you are trying to do?

I'm attaching the UCF file that you can use to set up the core.  You should be able to find the parameters necessary to configure the core from reading the board-support XML files.

The big thing I see different form your description above is the comment about the MIG memory running with a 200MHz clock.  That is the input clock rate to the core.  You can give it the 100MHz clock directly from the board if you'd like.  The MIG will adjust the input clock 'til it's something useful for it.  The actual clock that you are going to need to use to interface with the memory is a 100MHz clock.  You'll pass the memory requests, and receive responses, all on a 100MHz clock.

Hopefully this helps,

Dan

migmem.ucf

Share this post


Link to post
Share on other sites
  • 0

Thanks Dan.

Like I said, the first issue was that I wasn't getting the DDR reset to the memory part to go out of reset.  I was seeing the PLL change to the 200Mhz after I released the sys_reset.

I was thinking that I didn't have something constrained correctly.  So, I added a 100Mhz constraint to the input sys_clk.   That made the MMCM Pll VCO unhappy in Vivado.

Vivado MIG IP only lets you select from 330Mhz to 400Mhz.  If I select the input clock to be 200Mhz, it is unhappy with the constraint for the sys_clk??

I will look at your ucf.

Have a good weekend,

Keith

Share this post


Link to post
Share on other sites
  • 0

@boyerkg,

On the 330-400MH clock request, set it to 400.  On the input clock frequency, you can give it either 100 or 200.  Then use the output for your file.

Try comparing the .prj file the MIG generates and places into your projname.srcs/sources_1/(component_name)/mig_a.prj with the one I've attached.  Perhaps you can see a difference,

Dan

mig_b.prj

Share this post


Link to post
Share on other sites
  • 0

Dan,

I used 100Mhz as the input clock and I used nobuffer for both the input and reference clock.  I got the following error in bitstream generation:

ERROR: [DRC REQP-79] connects_REFCLK: u_mig_7series_0/u_mig_7series_0_mig/u_iodelay_ctrl/u_idelayctrl_200: The IDELAYCTRL REFCLK pin should be connected

It is not hooking put he refclk.  If I use a 200Mhz clock selection, the refclk gui lets me select 'use system clock'.

I compared my mig_a.prj file to yours, and they are identicle?

Keith

Share this post


Link to post
Share on other sites
  • 0

@boyerkg,

The MIG does require a REFCLK which must be at 200MHz.  This is separate and distinct from the clock you give it, or the clock you get back.  I don't think there's a phase requirement between the REFCLK and the input clock, but you might wish to check me on that.

Have you looked at the code where I did this for the Arty?  The Arty is really close to the Nexys Video, save that the Nexys Video runs at a higher speed, has (IIRC?) a bigger memory, and no CS pin.  Still, there's a migsdram.v component, a wb2axisp wishbone to AXI slave(pipelined) component, and the top level component containing the clocking infrastructure.  The Arty code, though, runs the memory at 82MHz, whereas on the Nexys Video you should be able to run it at 100MHz.  (Remember the clock frequency that had to be between 330 and 400MHz?  That's the actual memory frequency.  The user frequency will be 1/4 of that rate.)

Dan

Share this post


Link to post
Share on other sites
  • 0

As D@n said earlier ref_clk must be 200MHz. This is clearly stated in UG586. If the system clock was in range, it could be used a reference clock too. However, on the Nexys Video this is not the case so the only other option is generating it internally ("No Buffer"), as allowed by UG586. You have three options:

The easiest is to use block design and instantiate MIG with AXI, which will allow you to specify additional clocks to be generated, set one of them to 200MHz and loop it back to the clk_ref pin.

The other two options require manual changes. In a project where you instantiate MIG (either yours or the example design) you mark the MIG as "User-managed IP": https://www.xilinx.com/support/answers/57546.html. Then, you are free to edit the MIG-generated files. You need to go down two levels and look for the instantiation of mig_7series_v2_1_infrastructure. You need to set the following addition parameters:

UI_EXTRA_CLOCKS    => "TRUE",
MMCM_CLKOUT0_EN    => "TRUE",
MMCM_CLKOUT0_DIVIDE=> 4

CLKOUT0_DIVIDE needs to be calculated though. CLKOUT0_DIVIDE = Fsys_clk / DIVCLK_DIVIDE * CLKFBOUT_MULT / 200M. Then the port ui_addn_clk_0 will have your 200MHz reference clock that you need to wire to clk_ref. I attached a MIG example project done in 2014.4 that has the modifications. No guarantees that it actually works, use it as reference only.

The third option leaves the MIG IP alone and modifies the hosting project instantiating another MMCM sharing sys_clk as an input with MIG. Set the extra MMCM to generate 200MHz and wire it to clk_ref.

mig_800_example.xpr.zip

Share this post


Link to post
Share on other sites
  • 0

Thanks Dan and ELODG,

I took the third option, which made the most sense moving forward.  I implemented a 2x MMCM, to get the 200Mhz.  I recompiled the MIG to 400Mhz and 200Mhz input, with no buffer sys clock and use system clock for the ref.  The MIG PLL must not have been locking.

It works fine now.  Thanks again.  It is nice that you all have been responsive to my questions. 

Regards,

Keith

Share this post


Link to post
Share on other sites
  • 0

Keep in mind that: "The input system clock cannot be generated internally." -quote from ug586. In other words, you should not be cascading MMCM/PLL for MIG purposes.

So sys_clk must come from a CCIO pin, either in the memory controller bank, or in this case from another bank in the column through the clock backbone (SYSCLK is in bank 34, just below DDR3 bank 35. MIG will instantiate a PLL and an MMCM in the clock region of bank 35. If you do not want to re-use that MMCM to generate the 200MHz clock, you need to instantiate another MMCM in the clock region of bank 34, getting input from the same SYSCLK routed on the backbone.

Configure MIG for 100MHz sysclk, No Buffer. In the example project, configure a new Clocking Wizard for 100MHz input, No Buffer, synthesizing 200Mhz. Add to example_top:

   IBUFG_inst : IBUFG
   generic map (
      IBUF_LOW_PWR => FALSE, -- Low power (TRUE) vs. performance (FALSE) setting for referenced I/O standards
      IOSTANDARD => "DEFAULT")
   port map (
      O => sys_clk_ibufg,     -- Buffer output
      I => sys_clk_i      -- Buffer input (connect directly to top-level port)
   );

RefClkGen: clk_wiz_0
   port map ( 

   -- Clock in ports
   clk_in1 => sys_clk_ibufg,
  -- Clock out ports  
   clk_out1 => clk_ref,
  -- Status and control signals                
   reset => '0',
   locked => open            
 );

 Then, wire the clocks to the mig core instance in example_top:

-- System Clock Ports
       sys_clk_i                       => sys_clk_ibufg,
-- Reference Clock Ports
       clk_ref_i                      => clk_ref,

-- System Clock Ports
       sys_clk_i                       => sys_clk_ibufg,
-- Reference Clock Ports
       clk_ref_i                      => clk_ref,

Also add the following to your XDC file:

set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets -of_objects [get_ports sys_clk_i]]

 

Edited by elodg
Added example

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now