ARTY-A7-100 MIG Clock & Reset Requirement

[binry]

I know there are multiple threads talk about MIG in Arty A7 boards before this new threads. I just hope someone here can help me asnwer my questions.

In my understanding, the A7 board only has 100MHz crystal oscillator while the DDR3L component is designed to run at 667MHz (Require 166.667MHz input clock period)

Question 1) In this case, does it mean i need to use the additional MMCM to generate a 166.667MHz output before feeding the clock into "clk_ref_i" ddr_memory block?

According to the ARTY_MIG_DDR3 resource file, the reference clock and the system clock is configured to the "No Buffer" settings.

Question 2) I believe the reference clock above is referring to the 166.667MHz reference clock input pin? Just need double confirm from you guys.  

Question 3) May I know what is the frequency requirement for the system clock --> sys_clk_i? Can i direct connect the 100MHz on-board clock into this system clock?

According to the ARTY_MIG_DDR3 resource file, the system reset --> sys_rst is not defined / No connect.

Question 4) May I know why this reset is not required to bring up the DDR3L in Arty board? 

Question 5) Lastly, May i know if the example_top project (Controller + Traffic Generator) that direct generated from the Vivado, can direct used for Arty A7 board? Or it is not so straight forward?

Thanks,
Binry

[D@n]

@binry,

1. I usually feed the MIG controller with the 100MHz clock as the system reference clock if possible.  The MIG will handle dividing this as appropriate.
2. The reference clock must be at 200MHz.  This is to support the IO delay controller within the chip, which only accepts a 200MHz clock
3. Yes, you can connect the 100MHz system clock into the MIG.
4. The MIG will generate a reset that you can use--based off of both when the PLLs settle and when it's internal calibration is complete
5. I'm not familiar with the example project you cite.  My own example Arty A7 project doesn't use the traffic generator at all.

Dan

[binry]

2 hours ago, D@n said:

@binry,

1. I usually feed the MIG controller with the 100MHz clock as the system reference clock if possible.  The MIG will handle dividing this as appropriate.
2. The reference clock must be at 200MHz.  This is to support the IO delay controller within the chip, which only accepts a 200MHz clock
3. Yes, you can connect the 100MHz system clock into the MIG.
4. The MIG will generate a reset that you can use--based off of both when the PLLs settle and when it's internal calibration is complete
5. I'm not familiar with the example project you cite.  My own example Arty A7 project doesn't use the traffic generator at all.

Dan

Thanks D@n for the reply... seek for some clarifications....

1. I thought specific to the Arty A7 board, MIG will need 166.677? So when you say you feed the 100MHz instead, does it mean in your IP catalog setting, the input reference clock setting you set to 100MHz?

2. I'm confuse about your reply in #2 points. In fact, i'm referring to the system clock & reference clock as shown in below. My interpretation is when both set to no buffer, it means only derived clock from MMCM / PLL can be connect to them. right? So in your case,  what about for your case?

binry

[D@n]

@binry,

You can see all the settings I used here.  Do take note, though, that most of those who use the Arty platform tend to use the Vivado schematic editor.  I'm one of the few that does not.

Yes, I choose not to use buffers for the clocks specifically because they come from internal MMCM/PLLs.  The other option is for clocks coming directly from pins into the MIG core.  In those cases, the MIG will attach I/O buffers to the clock pins--something that can only be done to input pins before any other logic is applied.  Since I needed the 200MHz clock, I went with the PLL first--forcing the MIG clocks to avoid instantiating I/O buffers lest the design not be able to match to the Xilinx hardware.

I also use the 100MHz incoming clock, after passing through a PLL, directly into the MIG--so the incoming system clock rate is 100MHz rather than 166.67MHz.  This is the value in the IP catalog setting, as linked above.  This is separate from what the core wants as a "reference clock"--that needs to be 200MHz.  The MIG then produces it's own clock, which I then use as the system clock throughout my design.

Dan

[asmi]

I wonder if there is a single post by @D@n which doesn't include shameless plugs to his projects...?

Now, directly to OP's questions:

8 hours ago, binry said:

Question 1) In this case, does it mean i need to use the additional MMCM to generate a 166.667MHz output before feeding the clock into "clk_ref_i" ddr_memory block?

Yes you do. This is why "Clocking wizard" IP is being used (it instantiates MCMM internally).

8 hours ago, binry said:

Question 2) I believe the reference clock above is referring to the 166.667MHz reference clock input pin? Just need double confirm from you guys.  

No, reference clock (clk_ref_i) is ALWAYS 200 MHz no matter what.It's fed into IDELAYCTRL blocks which control delay elements used inside MIG.

8 hours ago, binry said:

Question 3) May I know what is the frequency requirement for the system clock --> sys_clk_i? Can i direct connect the 100MHz on-board clock into this system clock?

You can select it in MIG wizard, but the choice is limited based on your memory's frequency. For DDR3(L) 333 MHz MIG wizard doesn't allow you to select 100 MHz as allowed input frequency due to the way MCMM is used inside MIG, as well some of its' limitations (only single fractional divider per MCMM). Since you always need to feed 200 MHz into MIG no matter what and there is only single clock source on Arty board, you will have no choice but to use MCMM, so you might as well use it to also generate input system clock.

8 hours ago, binry said:

Question 4) May I know why this reset is not required to bring up the DDR3L in Arty board? 

sys_rst signal is an active-low asynchronous reset, you can connect it to board's reset signal (again if polarity is right). It isn't required unless your design is supposed to withstand and properly handle system resets. It's used to bring everything to a known initial state so that memory initialization can be performed and functionality is restored if due to some bugs your HW is not working properly.

8 hours ago, binry said:

Question 5) Lastly, May i know if the example_top project (Controller + Traffic Generator) that direct generated from the Vivado, can direct used for Arty A7 board? Or it is not so straight forward?

I never actually tried using it, but I think it won't work out-of-box because of clocks needed to be provided - example design assumes they come directly from IO CC pins. But you can modify it to get it to work, and that shouldn't be that difficult. Same goes for status signals tg_compare_error, init_calib_complete - you can connect them to onboard LEDs provided that polarity is right (might need to inverse depending on how LEDs are wired on a board).

[D@n]

2 hours ago, asmi said:

I wonder if there is a single post by @D@n which doesn't include shameless plugs to his projects...?

 

Seriously?  You didn't look at the material I offered then.

Allow me to post it here, at the expense of any readability, since the following pictures were taking from the documentation I referenced above:

Once you fire up the Memory Interface Generator IP product guide, it will lead you through a series of dialog boxes used to configure the core.  Step one is to create a new design.  I like to use the AXI interface for my designs.  There is another interface available that I have yet to find sufficient documentation for.

Step two: skip picking any pin-compatible FPGA's--you'll only need to support the one that was already selected when you created your project

Step three, specify that you want a DDR3 SDRAM configuration

Step four: Identify your chip, clock rate, voltage, data width, and any number of bank machines that you want.  Do note that you cannot go faster than about 325MHz with this board--the chip won't allow it.  Likewise, you can't go slower than about 300MHz since the DDR3 SDRAM spec doesn't allow that.  Since this is rather high speed, and do to limitations of the Xilinx chip on the Arty, you'll need to use a 4:1 controller.  Note that this is grayed out because the chip won't support the alternative 2:1 controller at this speed.  The MIG controller will generate this 325MHz clock from the incoming clock you give it (100MHz), and give you an output clock which you can use for your design at 325/4 = 81.25MHz.  Depending on whether or not your controller can handle out-of-order returns, you may wish to select "Normal" or "STRICT" ordering.  I used Normal when this was written.  I've since rewritten my AXI controller for strict ordering--it's just simpler and easier to deal with.

You can then choose what data width you want for your AXI bus.  128-bits is the natural data width for this memory.  Anything else will bloat the logic used for your memory controller with a data width converter.  Depending on how you choose to generate your AXI requests, you may or may not want narrow burst support.  (Xilinx's AXI example doesn't support Narrow Bursts, although it is part of the AXI spec.)  This would also bloat your design, and I'm not sure it's really necessary.  I have written an article on how to handle narrow burst support.  Moving on, AXI allows out of order transactions.  My original design used out-of-order support and allowed every transaction to have a different AXI ID and thus to get returned in a different order.  It was a pain to deal with.  If you want to do this though, an ID width of 5 with unique request IDs per beat will allow the controller unconstrained freedom to reorder your requests.  If you choose to use strict ordering, you don't need to support any more ID widths than the rest of your system requires.

Step six, where you were asking your question, is spelled out here as well: a 100MHz input clock period works just fine.  It will be multiplied up to 1.3GHz and then divided back down to 325MHz to support the clock rate we selected earlier.  Read burst type really depends upon how your CPUs cache wishes to access memory.  If you don't care, just pick sequential--it's easier to optimize for.  Output driver and RTT impedence come straight from the Digilent documentation.  This board has a Chip Select pin on it's DDR3 interface, so you'll need to enable that here.  I also like Row-Bank-Column ordering, since it's easier to guarantee 100% throughput, although I have no idea if the MIG controller will guarantee non-stop throughput across banks.  Perhaps I'm just superstitious that way.

Step seven, clock inputs: Since you will need a 200MHz reference clock (this isn't optional, nor is the frequency up to the user), and the only place you can get that on this board is from the 100MHz input clock, your only option is to select "No Buffer" for both of these clocks and to run your 100MHz through a PLL.  You can then send the outputs of that PLL to the MIG.  Picking 100MHz gives you greater flexibility for the rest of the clocks coming from that PLL.  Reset type is up to you, I'm using Active Low.  You won't need the debugging signals--if everything works well.  (I have had problems before, but solved them without the debugging signals.)  The board also provides you with an incoming voltage reference.  I/O power reduction is the default, but not something I've experimented with, and unless you want to feed the core with the local temperature yourself, you'll need to enable the on-board XADC and give the MIG control over it.

Step eight: You'll want to select the internal termination impedance of 50 Ohms.

Step nine: Since Digilent already built this board, you'll want to select a "fixed pin out"--the pins are already laid out and selected for you

Step 10: This one's a real pain if you don't want to reference my design as a place to start from, but ... you'll need to identify each of the external wires to the MIG for layout.  You can reference my design and the UCF file within it to make this part easy, or you can painstakingly dig for that information.  As I recall, I found this information from the Arty project file.

Step 11: The final step I took was to make the system reset, calibration complete, and error signals "No connect"--that keeps them from being assigned I/O buffers if they aren't directly connected to pins.  You can still use these signals within your design if you want.

Do be aware that the latency of the MIG controller is around 20+ clocks.  It works ideal for high throughput designs of 128-bits per beat, such as a cache might generate, but it's going to be a speed bump in any more random memory access pattern.

Now, that's an awful long post to answer a basic question which would likely have followups, but it does show in gory detail how you can set up the MIG.  If you want more detail, the project itself is an example design which you can reference--or not.  Take your pick.

Oh, and Yes, this information was in the project's documentation which I referenced in my first response.

Dan

 

[asmi]

41 minutes ago, D@n said:

Step four: Identify your chip, clock rate, voltage, data width, and any number of bank machines that you want.  Do note that you cannot go faster than about 325MHz with this board--the chip won't allow it.

Yes it does. You can go full 333 MHz:

And I can confirm that it works in hardware just fine

48 minutes ago, D@n said:

Step 10: This one's a real pain if you don't want to reference my design as a place to start from, but ... you'll need to identify each of the external wires to the MIG for layout.  You can reference my design and the UCF file within it to make this part easy, or you can painstakingly dig for that information. 

There is nothing to dig - just read schematics. If you can't read schematics, you'd better not get into FPGAs at all. There is a UCF file in Digilent's repository as well if you can't be bothered to type this stuff in.

53 minutes ago, D@n said:

Do be aware that the latency of the MIG controller is around 20+ clocks.  It works ideal for high throughput designs of 128-bits per beat, such as a cache might generate, but it's going to be a speed bump in any more random memory access pattern.

All DDR memories are designed for burst accesses, and so they don't perform well in true random access - and things get worse with each DDR iteration. For DDR3 at 333 MHz, the minimal CL is 5 cycles followed by 4 cycles of data (due to 8n prefetch architecture), so ~10 clocks in total (as DQS can be up to ±0.5 clock either way) just for the raw interface part. You can get a bit better latency by talking to MIG's user interface block directly (not through AXI4 adapter), but unless your design is going to push the limits of attached memory module in terms of bandwidth and latency, benefits from AXI4 are more important than the little better latency they get out of direct use of UI.

1 hour ago, D@n said:

Seriously?  You didn't look at the material I offered then.

I wasn't talking about this exact post - as I made clear in the post. Now, even few years down the road, you're still shilling for ZipCPU, which is just as useless now as it was few years ago. Infact I'd argue it's even more useless now as we now have free access to ARM CM1 and 3 cores, as well a a ton of RV cores out there - all for free and without the cancer of a license that is GPL.

[sneha]

On 11/20/2019 at 2:46 AM, D@n said:

go faster than about 325MHz

I referred to this doc to understand to verify if its 325MHz plus to know what would it be for my part xc7a100tcsg324, speed grade -2.. But I dnt see a clear answer to it.  Is there a way to read it ? Also -2 speed grade of the device should be responsible for this right!?

https://www.xilinx.com/support/documentation/data_sheets/ds181_Artix_7_Data_Sheet.pdf

[sneha]

On 11/20/2019 at 2:46 AM, D@n said:

internal termination impedance of 50 Ohms.

how do we get this? 40 Ohms or 50 Ohms? please tell something more about how these values are choosen to be so that it gives a proper understanding and we can then manage with any part we want..

thank you!

 

[sneha]

On 11/20/2019 at 2:46 AM, D@n said:

project's documentation which I referenced in my first response.

Can access the project on github! is the page removed or what??

[D@n]

@sneha,

The project is still there, I just merged the autoarty branch into the mainline.  You can find my example project here.

Dan