DDR3 clock limits for Arty A7-100 board

[Allan Flippin]

     I went through the process of running MIG7 (Vivado 18.3) to generate a DDR3 controller for the Arty A7-100.  I copied the digilent board files into the Vivado 18.3 board_files directory and chose arty-a7-100 when opening my project.

     When MIG7 starts, the first thing it wants is clock period.  That's where I'm having the problem.  MIG7 allows numbers between 2500 and 3300ps.  But with my board, MIG7 won't allow any period less than 3225ps.  That's a very narrow range of frequencies!  I need to consider my FPGA general system clock speed in connection with making a high-speed UART for PC communication.  Between 3225ps (310.7Mhz) and 3300ps (303Mhz), there are no useful frequencies I can find in common with baud rates that are multiples of 1,000,000.  If the tool allowed 3333ps, I'd end up with an FPGA clock of 150Mhz (with 2:1 ratio).  I could make that work easily.

     After looking at the "stub" Verilog file and reading in UG586, I see that sys_clk_i is a user input.  Could I not feed 300Mhz in there?  I don't care that memory would be a tiny amount slower.  Would the DDR controller not work?  Is there any reason the tool could not directly allow a slower clock specification?  Thanks for all your help.  Let me know if any file I have would be helpful to you on this.

Allan

[D@n]

As I recall, you are stuck with the 4:1 mode.  That puts your system clock rate somewhere between 80 and 83MHz.  The best choice you have for a system clock frequency that will support (naturally and natively) a 1MBaud UART would be 80MHz.

On the other hand, UARTs--even at 1MBaud--are slow.  You could easily use a second clock with your UART, and use a proper clock domain crossing to get just about any frequency.

Dan

[Allan Flippin]

The tool is allowing 2:1 mode.  I was surprised by that too.  The problem I have with a "second clock" is that I just have the single 100Mhz oscillator on this board.  No matter what I come up with frequency wise, the DDR clocks and the UART clock are coming from the same source.  Synchronizer theory works only for clock domains that have totally independent sources.

With upper and lower bounds of 303Mhz and 310.7Mhz, I don't have any useful frequency multiples to work with.

Allan

[xc6lx45]

if it helps, UARTs are extremely robust towards frequency error, in the order of percent (the protocol effectively wastes ~10% throughput on synchronization).

The closest integer UART divider will probably work just fine.

>> Synchronizer theory works only for clock domains that have totally independent sources.

Not sure what you mean with that. A CDC needs to function at any possible phase delta between two clocks. If the two clocks are from the same source and co-periodic in some length, the random distribution of the phase looks different but it's just a special case and should still work.

[Allan Flippin]

xc6lx45,

     Yes, I'm expecting my UART design will be a bit unusual to adapt to the clocks I have available.  I don't have my books with me at the office, but I found an article that discusses my point about synchronizers.  https://www.edn.com/electronics-news/4356211/Keep-metastability-from-killing-your-digital-desig

     Check towards the end of the article starting with this:  "Before trying to handle an asynchronous signal properly, make sure that it actually is asynchronous. The metastability equations assume that the input data transition is equally likely to occur at any time during the clock period."

Allan