How necessary is DDR trace length matching at low clock speeds?

[Boscoe]

I'm a little puzzled on the necessity of length matching for high speed buses such as those on DDR memories. I'm using some DDR3 in a design with a clock speed of 300MHz when the part is rated to 1066Mhz clock.

I have been googling for information regarding the reason for matched lengths in traces and so far I have found two:

1. (timing) edge alignment, and;
2. impedance matching.

However the articles I read so far just claim the necessity for length matching for the purposes of timing but do not use and theory or maths to justify it. The second reason given (for impedance matching) seems more like good practice rather than need as it simplifies impedance matching between signals if they take similar routes.

Now I know my design is not high performance due to the relatively low clock speed but I'll still use it as an example.

A DDR clock at 300MHz has a period of ~1.667ns, the length of my DDR IC is 14mm and PCB trace transmission speed is around 163mm/ns (according to multiple online sources). So assuming a very large delta in trace length of 14mm (distance between furthest most pads) with get a timing delta of ~86ps - nearly twenty times smaller than the clock period. This doesn't seem like a problem to me even considering a large length delta assuming timing is kept equal across the signals in the FPGA.

Is there something I'm not understanding here? Could someone shed some light on this or link me to a good article / paper about it?

Many thanks!

[tggzzz]

The clock speed is irrelevant. https://entertaininghacks.wordpress.com/2018/05/08/digital-signal-integrity-and-bandwidth-signals-risetime-is-important-period-is-irrelevant/
Important points are edge transition time, setup and hold times, signal integrity.

A useful introduction to all that is Bogotin's rules of thumb on EDN. https://www.edn.com/category/blog/bogatins-rules-of-thumb/page/4/

[PeteH]

Timing relaxation is fine for DDR at lower speeds.

Xilinx (AMD) has this derating in their data sheets/user guides when using higher grade FPGAs and/or faster memory parts vs. desired speeed.

86ps doesn't sound like an issue here.

Controlled impedances are required regardless of clock speed of the routing lengths approach a ratio of the rise/fall times... Which is likely the case.

[BrianHG]

https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3608794/#msg3608794

[Boscoe]

Thank you for the information, all. I've come across a case though that doesn't seem to make sense. Xilinx recommends to use flyby routing with multiple DDR3 ICs with termination at the end. No matter which way you position the ICs there's no way to match all the lengths. As the data bus is split between the two ICs they are at distance x from the FPGA. Then the control signals must 'flyby' through the first or second IC making their length x + y (distance between the DDR3 ICs) but the data signals are at x. No matter which way you swing it there'll always be a y or x offset between the signals. These can be as large as 15mm. How does one deal with this?

[Someone]

Attached below is the best example I have come across simplifying the timing constraints of DDR3. (https://welldoneblog.fedevel.com/2014/06/30/ddr3-length-matching-rules/)

[amyk]

Thank you for the information, all. I've come across a case though that doesn't seem to make sense. Xilinx recommends to use flyby routing with multiple DDR3 ICs with termination at the end. No matter which way you position the ICs there's no way to match all the lengths. As the data bus is split between the two ICs they are at distance x from the FPGA. Then the control signals must 'flyby' through the first or second IC making their length x + y (distance between the DDR3 ICs) but the data signals are at x. No matter which way you swing it there'll always be a y or x offset between the signals. These can be as large as 15mm. How does one deal with this?

https://electronics.stackexchange.com/questions/49192/question-about-trace-length-matching-patterns-for-high-speed-signals