FEDEVEL
Platform forum

sam , 04-18-2025, 07:40 PM

@Phil Hi Phill,

In your DDR3 routing video from advanced hardware design course, you mentioned that there are two options for delay matching. You mentioned that either of these two will work the same but I don't understand how.
I understood #Option1 method and that is what I've implemented. Buw now that I revisited video, then I got confused.

#Option1
1) Create xSignals from controller to 1st Memory and have them delay matching
2) Create xSignals from controller to 2nd Memory and have them delay matching

#Option2
1) Create xSignals from controller to 1st Memory and have them delay matching (same as #Option1)
2) Create xSignals from 1st Memory to 2nd Memory and have them delay matching

Below are my questions,
1) Can you confirm that you are not taking account of stubs created between its vias and 1st Memory when you match delay in step 2) for #Option1? so signals from controller are "touching vias (not going through)" then straight to 2st memory?
2) How dose step 2) in #Option2 work? Signals from controller to the vias (connections or stubs just before hitting 1st Memory's pads) are different and also these stubs created between its vias and 1st memory are also different as total delays from controller to 1st memory is what matters.
So doesn't this mean that delay seen by the controller to 2nd Memory will be different even though you have matching delays from 1st memory to 2nd memory? Address, clk, control signals are coming from controller right? I guess it won't matter if via-in pad are used but example you had was dog-bone fan out and I followed that as well.

I finished routing by following #Option1 🙂, hoping that I didn't scerw up as it took so much time haha.. If somehting is not clear, please let me know as well. I will provide images of routing or anything if it helps.

Thank you

Regards,
Sam

Robert Feranec , 04-22-2025, 01:47 PM

stubs don't influence the length between pins ... length between pins is the shortest path

sam , 04-25-2025, 02:14 AM

@Robert Feranec Hi Robert.. I am still confused what you mean by stubs don't influence. I guess my question is, if I have delay matching between controller to each memoires, for example, Controller to DDR3_#1, Controller to DDR3_#2 .. to DDR3_#n, I don't have to worry about delay match between DDR3 memories itself right? It is really clear if I routed by using via-in pad manufacturing, but I am doing dog bone fan out (I think i saw one of your videos as well) so I have stubs created between these vias to the DDR 3 memories. Mabye using word "stub" is wrong in this context.. Let me share part of my DDR3 routing below. It's one of control signals from controller to each memories. One path is going to 1st memory, other path is going to 2nd memory splitted by via (indiacted as point B in below image)

That trace created between point B (via) and point C (1st DDR3 memory) is not something that I have to worry about right? This trace is about 13mm and this is due to the way I routed all signals and I couldn't create vias more closer to DDR3_1 pin. I did make sure that address, clock and control signals have delay match on each path from A -> B -> C and A -> B -> D. I just got confused when Phil mentioned in his advanced hardware design course that either I can do what I did below (matching delays individually from controller to each memories) , or match delays from C -> B-> D after making sure that I have match delays on A -> B-> C.

sam , 04-25-2025, 02:33 AM

In below case, I was able to create vias right neraby the destination pad of 1st memory. In this case, I agree with what Phill mentioned about having delay match from A -> B, then just B-> C because stub created between B and 1st memory is very short. However, most of my signals are transferred through vias with a distance of maximum 13mm from its destination of 1st memory. I think that I have similar length of what Phil has shown as an example in his course. His example in the course looked like around 10mm or less between visa and 1st memory pad. So that's why I was confused. I hope this clarifies my question..

sam , 04-25-2025, 02:42 AM

These are all signals that are transferred through vias then connect to 1st memory from the controller. Same for 2nd memory signals. As you can see, it has quite of length and Phil's design also had similar trace length as well. So then, my question is, should I just follow #Option1 delay matching? It just makes more sense to me unless I am mistaken something really bad..

Robert Feranec , 04-25-2025, 05:02 AM

if we are talking about fly by topology, the result will be the same. if you length match CPU to MEM1 and if you length match CPU to MEM2 then distance between MEM1 and MEM2 will be automatically the same length for all the signals between the memories. In the other option if you length match CPU to MEM1 and MEM1 to MEM2 than automatically CPU to MEM2 will be length matched.

For example:
if A1 length between CPU to MEM1 is 10mm then A2 length needs to be 10mm too:
- A1:CPU-MEM1=10mm, A2:CPU-MEM1=10mm

next when we have A1 length between CPU to MEM2 15mm then A2 length needs to be also 15mm:
- A1:CPU-MEM2=15mm, A2:CPU-MEM2=15mm

now, when you calculate distance between MEM1 and MEM2 you will find out, that it will be 5mm for all the signals, so the segment between MEM1 and MEM2 will be automatically lenght matched.

sam , 04-25-2025, 06:44 AM

@Robert Feranec Yes Robert, I agree and I understand that part. But isn't that only applicable when fly by topology is routed through vias with short stubs or via-in pad? I did fly by topology but dog bone fanouts (this is also what Phil showed us in the course; dog bone fanouts). So I have inconsistent or unmatched length between vias and MEM1 lengh for each signals. This makes distance between MEM1 and MEM2 different. For example, below is A1 signal from CPU to MEM1 through via. So A -> B-> C. But distance between B -> C is never consistent for all other signals like A2,A3, and etc because vias are terminated at different distances.

sam , 04-25-2025, 06:47 AM

Below is A2. I was able to terminate via right nearby the pad of MEM1 so distance between via and MEM1 is really short whereas above A1 signal has already length of 13mm

sam , 04-25-2025, 06:47 AM

I really don't get how distances between each memories are automatically mathced in this case

sam , 04-25-2025, 06:48 AM

This seems to be only applicable when routed fly by topology with vias terminated right neraby MEM1 (Short stubs) or via in pads.

sam , 04-25-2025, 06:50 AM

Another example for A5 and A10 signals, I have all length matched between CPU and MEM1. However this is summation of A5 -> A5_Via -> A5_END. Same for A10. A10 -> A10_Via -> A10_END.

So A5_Via -> A5_END and A10 -> A10_END are not necessarily matched length(or delays). A5 -> A5_Via and A10 -> A10_Via are also not necessarily matched. It's the summation of total path from CPU to MEM1 pad that are matched.

In this case then, MEM1 to MEM2 cannot be automatically same distance.. I have delay match between CPU to MEM2. But this dose not automatically make distance between MEM1 and MEM2 are the same. I hope that I did not mistakes here.. I thought distance between CPU and each memories are important

sam , 04-25-2025, 07:06 AM

Basically I have two xSignals created to math delays for all relevant group signals

1) CPU to MEM1 (Grouped as ADD_PR1)
2) CPU to MEM2 (Grouped as ADD_PR2)

Below images are example of A5 signal. First is signal from CPU to MEM1. Second is signal from CPU to MEM2.

Because ADD_PR2 is not taking account of distance between via nearby MEM1 and MEM1 (B -> C on the first image), there is no way that distance between two memoires are matched. Instead they are all matched from A -> B -> D -> E by skpping the path between B -> C (for ADD_PR2)

Am I missing something? This is exactly how Phil showed in his course and other application notes refer the same as well.. Maybe I still misunderstood

Robert Feranec , 04-25-2025, 07:12 AM

yes, in case you are doing MEM1-MEM2 length matching the stabs would need to be the same.

If you are not sure what to do, then match CPU to each individual MEM chip - that is our ultimate goal.

sam , 04-25-2025, 07:15 AM

@Robert Feranec okay so as long as I have match delays from CPU to each memories for all relevant groups , I am safe right? 😅 My understanding was that only delay to calculate is that which is along the propagation path..

For example,
my average delay between CPU to MEM1 for addr, clk, ctrl signals are 500ps
my average delay between CPU to MEM2 or addr, clk, ctrl signals are 700ps (not taking account of stubs created between via and MEM1)

So I don't need to worry about distance between each memories in my case... I really hope that I don't have to start over all signals again 😦

QDrives , 04-28-2025, 02:26 PM

Not that I have any experience with DDR memory...
Why do we do backdrilling? The via stub influences the signal.
So a stub of 13mm will have a massive effect on the signal.

sam , 04-29-2025, 05:02 AM

@QDrives what do you mean by back drilling? This is fly by topology that I matched delays between a controller and each memories. No delay match between memoires. This is using dog bone vias and I couldn't terminate vias right nearby the pads of DDR3 memory chips. This is what Robert mentioned too. match delays betewen CPU to each memories. So I understood this as it is okay as long as I have delay match on the path from controller to each memory. Therefore 13mm is not an issue as it is already taken account in the delay match 13 mm is included in delay match from controller to the memory as it is part of routing. For example, I mentioned that avg delay is 500ps between a controller and MEM1. 13mm is not a via stub. It is a trace between via and DDR3 chip pinout. My question is that if I had to delay match between memories as well. I don't think altium tool tracks of via lenght as part of delay match but I did keep same number of vias used for each group of signals

sam , 04-29-2025, 05:22 AM

@Robert Feranec Hi Robert, would you be able to confirm what I did is correct? matched delays between a controller and each memories so delays between memories are not important?

Robert Feranec , 04-29-2025, 09:38 AM

correct