FEDEVEL
Platform forum

sam , 04-30-2025, 04:06 PM

@QDrives (Recalling a message from above with Robert). So "stubs" are taken as part of delays in relevant groups, for example, in 500 ps (this is path from controller to 1st memory). Its application note (UG933) also specifies recommended length between first and last memory but nothing about stubs specifically. I am using zynq7010 SoC

"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) "

sam , 04-30-2025, 04:07 PM

let me know if there is anything I can clarify

QDrives , 04-30-2025, 08:20 PM

A stub of 13mm will cause reflection with a delay of ~170ps (@Dk=4.0).
What is the risetime of your signal?

sam , 04-30-2025, 11:56 PM

@QDrives Definition of stub is a length of a copper trace that is unintentionally connected to a signal trace or via but not actively used for signal transmission.

But this is connected to DDR3..? What is the issue here? Sorry I am not understanding well. Okay, you can have 170ps delay with 13mm at that Dk value. But that trace is controlled impedance and its delay is taken in the total delay I have from Controller to the 1st memory. Please see below screenshot. This is trace connected between via and 1st DDR3 with ~10mm and results ~60ps. 60 ps is included as a part of total delay in this case 500ps. Let's say this is part of A1 signal. Total delay from Controller (A1) to 1st DDR3 is 500 ps including that 60ps delay. Does this make sense? Robert also confirmed above. I am not sure why this is an issue? I never had someone to bring this to my attention but I just can't seem to understand your point. Yes, if it's a stub that are not connected or not part of my delay calculation, this is an issue. But this is not my case. I thought you were referring to via stub which I agree about potential SI issue but now I am starting to get confused about your point . I hope I can clarify more if you don't get my point.

I am not sure how to locate exact rise of this clock signal. Not sure if that is explicitly mentioned somewhere.. However below are parts that I am using

SoC : XC7Z010-2CLG400I
DDR3 : MT41K256M16TW-107IT:P

*This DDR3 is backward compatible with 1066 speedbin which is maximum speed that Zynq7010 can support (533MHz)
*DDR3 is being used Processing System with dedicated pins
Hopefully this helps

sam , 05-01-2025, 12:04 AM

sam , 05-01-2025, 12:37 AM

This is manufacturer application note. (UG933). I don't see anything mentioned about stub but as long as I keep my trace between controller to the first memory less than ~ 5 inches then I am safe. I assumed they already have taken account of their chips capability (risetime and etc) ?

sam , 05-01-2025, 02:46 AM

Also another note that I found

sam , 05-01-2025, 03:03 AM

@Robert Feranec Hi Robert, sorry to bring you this thread again. Do you agree with this statement? @QDrives is saying that stub of 13mm (or trace between via and 1st memory) will cause significant reflections? What I saw from Phils video, he had longer or similar length of traces than I have. Also I am not sure how this will cause reflections as it is still part of controlled impedance trace and matched delay properly.

Robert Feranec , 05-01-2025, 12:20 PM

I don't know. You would need to simulate. In important nets I try everything to keep the stubs as short as possible. If you are not sure and can't simulate, you can download DDR module designs, they are free and available from JEDEC website and you can have a look how big stubs they have.

sam , 05-01-2025, 07:15 PM

What I don’t understand is that this is a stub that is part of propagation of signal from controller. Not sure why this would be an issue?

Also do you have any suggestion how to run these simulation on Altium? I have seen your other videos on different tool but wondering if there is any other free or Altium usage.. thank you

QDrives , 05-01-2025, 09:59 PM

1) Again, for the stub is not about the delay calculation.
2) "*Definition of stub is a length of a copper trace that is unintentionally connected to a signal trace or via but not actively used for signal transmission.*" -- No, a stub is an **unterminated** conductor. Being actively used or not, does not matter.
3) In the application note UG933 they mention the balanced T. With the stub, you are (partly) doing a T, but not balanced in this case as TL1 is 13mm for DDR1 and >>13mm for DDR2. Also note the the termination then should be near the junction TL0 to TL1.

QDrives , 05-01-2025, 10:02 PM

Below screenshot is a QSpice simulation with result.
I took 50ps rise time as taken from the Tftx from the GTP transceiver which is 50ps.
You should be able to determine the rise time from the IBIS model. I could not find an IBIS model, but AMD is terrible.
As you can see, the signals look ok.

QDrives , 05-01-2025, 10:02 PM

Now with 60 ps stub. Different color and different scale.

sam , 05-02-2025, 12:01 AM

@QDrives Thank you very much for the simulation data. I think I know where I was confused.
You are saying that stub of 60ps on the path from via to DDR1 will cause reflection seen by the path from controller to DDR2 therefore it gets added on total delay of 700ps . Is this correct? 500ps was total delay from CPU to 1st memory and 700ps is total delay from CPU to 2nd memory. I think you might have put wrong number but that's fine..

Recalling my delay match,
"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) "

sam , 05-02-2025, 12:03 AM

Btw your simulation schematic seems to be identical.. maybe it's a mistake?

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

@Phil Phil, your course dose not address about what is being discussed here. maybe this dose not have huge impact on board functionalities. Can you confirm that you have taken account of these? You mentioned that this is not important in the course. I also saw these stubs on near 1st and 2nd memory from your gerber file and they seemed to be well above 13mm. I wasn't understanding why this was considered as fly by routing. What you described in the course was fly by routing but it was partially T-branch, which I ended up following it and have those lengthy stubs

sam , 05-02-2025, 01:21 AM

@QDrives Just to avoid misunderstanding, this is what I have for A1 signal and this is what we are discussing. Not sure if these have impact on your simulation.. maybe voltage level dose
1. VTT in my case is 0.65V (half of VDDR voltage)
2. CPU -> DDR3_2 is 700 ps (not taking account of 60ps delay)
3. CPU -> DDR3_1 is 500 ps
4. Parallel resistors terminated at the end of chain (DDR3_2)

Not sure why you have 500p at T1, T2 in your simulation setup?

QDrives , 05-02-2025, 02:12 AM

It is 1 schematic with a ".step". The result is important. The first plots are with 10ps stub, the second step with 60ps stub.

QDrives , 05-02-2025, 02:18 AM

You should not add reflection to delay. Reflection malforms the signal.
Below is a zoomed in bit with the 60ps stub. Notice the 'plateaus' on the rising and falling edges of DDR2?
What is the logical level during that period?
Do note that this still is an ideal simulation, no noise, no crosstalk, consistent voltage, termination, delays and trace impedance.
What if, when considering the real board, one signal is consider high in that period and the other is still 'low'?

QDrives , 05-02-2025, 02:26 AM

There is really only 1 thing that matters: the relation between the stub delay and rise time of the signal.
If the stub delay is low compared to the rise time, there is not so much a problem.
This capture is with a 250ps rise time and 60ps stub. Notice that the rising and falling edges do not show anot plateau.

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

I started understanding more about this.. do you suggest re-route this? or I found other PCB manufacturer that provides via-in pad for free on BGA packages. I think then I can remove these stubs completely

sam , 05-02-2025, 02:31 AM

Sorry let me ask this again. Why do you have T4 to be 60p? I don't think I understood fully on this simulation setup. T2, T3 looks fair to me

sam , 05-02-2025, 02:33 AM

Also, as described below (let me grab is again..), 500ps should represent a total delay (summation) of T1 and T3 delay

QDrives , 05-02-2025, 02:33 AM

First try to find out what the rise time is.
Also note that I only did the CPU -> mem simulation. Your memory also sends data back.
Both have rise times.

sam , 05-02-2025, 02:35 AM

I will find it out.. thank you so much. If you could tell me why you have T1 and T4 to be 500p and 60p, that would be my last question for today until I find the actual rise time.. thank you!

sam , 05-02-2025, 02:37 AM

But these are address, control and clock signals so I think they are unidirecitonal signals? I don't have issue data groups signals. They are directly point to point connection so I didn't have any issue there

sam , 05-02-2025, 02:38 AM

Also V2 is should be a half of VDDR voltage which is 0.675V

QDrives , 05-02-2025, 02:47 AM

I just picked some numbers for the delays.
Here a adjusted timing:
440p+60p=500ps for DDR1
440p+260p = 700p for DDR2
Estimated 40p between DDR and termination.
The .step is now on rise time, 50ps, 100p and 150p are plotted.
This (**ideal**) simulation shows that if the stub delay < 25% of of the rise time, that the stub would not be a problem.

QDrives , 05-02-2025, 02:50 AM

I have shown you the schematic, done in QSpice, so nothing is stopping you from recreating it and filling in your own values.
Just 2 voltage sources, 3 resistors, 4 transmission lines and 6 Gnd.

Sniper2 , 05-02-2025, 04:08 AM

@QDrives where did u learn qspice? Any resources u recommend?

sam , 05-02-2025, 07:20 AM

@QDrives Thanks for all your comments. I understand everything now. I will come back later with an update!

Phil , 05-02-2025, 01:00 PM

As both Robert and QDrives have stated, that is what you should pay attention to (avoid longer stubs if possible, simulate, etc.). I agree in the course that section is not fully explained and I should've gone more in depth when it is 'okay' to have stubs and if so, how long they can be. With this particular board, despite some longer stubs I have not had issues running at the Zynq's max. DDR3 data rates. All memory tests passed with good, open eye diagrams and no write/read errors.

sam , 05-02-2025, 05:33 PM

@Phil Thank you so much for confirmation. It's all good. At the end of the day, I learned a lot from your courses and I clarified some of knowledge from here as well! just one question, do you know what the true rise time of Zynq7010 DDR3 clock signals?
I see GTP Transceiver Reference clock information from DC and AC Switching Characteristic application note (DS187). Is this the corresponding risetime for address, control and clock signals of its pins? I think this will help me to run simulation properly. Otherwise I think I will reroute everything.

QDrives , 05-02-2025, 06:57 PM

Learn by doing.
Searching on internet.
Started with LTSpice and many years later with QSpice.
Here are quite a few interesting LTSpice videos: https://www.youtube.com/@FesZElectronics

Sniper2 , 05-02-2025, 07:54 PM

i know him

Sniper2 , 05-02-2025, 07:55 PM

my problem is that i am used to LTspice and often when i need to do something i use it out of habiito so transitioning to Qspice is sort of hard sin ce GUI is not the best and i am not so used to it

QDrives , 05-02-2025, 08:52 PM

There is only one important reason to go to QSpice: the ability to use C code blocks.
Sure, there are some more reasons, but they are not as 'big'.
So if LTSpice works for you, there is no direct reason to switch to QSpice.

Sniper2 , 05-03-2025, 08:05 PM

well that is why i am trying to get into Qspice more , it also suports veriloog

QDrives , 05-04-2025, 03:24 PM

Start with this video: https://www.youtube.com/watch?v=__ycmI0cdws

sam , 05-04-2025, 08:04 PM

@QDrives Going back to my original question.. I ended up re-route all signals again. Just quick question, I find it difficult to route all address/control signals on the same layer. For example. I planned to route address/ctrl/clock signals from Top -> Layer8 -> Layer6 -> Top. I routed clock signals consistently on the same layer and terminate on Top layer. However, it was hard to breakout some address/control signals from the top right away due to the space, so I ended up having some accordions(delay match) starting from Top then Layer8 -> Layer6. In Layer6, It was again hard to route all of them on the same layer then switch layer to Top layer. So I have some signals that are switched to Top layer early then goes straight to DDR3. I am aware to route all relevant groups on the same layer and I don't have issue doing it for data groups but not so easy for address/control signals

I am using via-in pad this time and I do eventually have all same number vias accounted for all groups. It's just that I wasn't sure If it is okay to split some address/control signals in different layer.. Please see below screenshot for more details

sam , 05-04-2025, 08:05 PM

This is top layer where I had to route some address/control on top

sam , 05-04-2025, 08:05 PM

This is Layer8 that I kept all address/control/clock signals then goes to first DDR3 memory (bottom IC)

sam , 05-04-2025, 08:08 PM

This is Layer6 that connects 1st DDR3 memory (bottom) to 2nd DDR3 memory. Some address/control signals are switched to Top layer due to spacing (see red circled) but clock goes directly to 2nd memory through via-in pad.

sam , 05-04-2025, 08:09 PM

Now finally back to Top layer and goes to 2nd DDR3 memory. This is not completed yet. I am planning to use that left side space for better signal integrity so I can shift these signals that are going to 2nd DDR3 memory away from break out signals on the top intially from the controller

sam , 05-04-2025, 08:10 PM

Now that I have removed stubs in 1st DDR3 memory by using via-in pad, now I wanna make sure everything seems okay so I can proceed :(. Have been working on this just a month (part time) and I really want to finish this! I would appreciate if you can give me any advices. Thank you

sam , 05-05-2025, 12:26 AM

*3D view

sam , 05-05-2025, 12:35 AM

Again, im not looking for designing something that will pass EMI.. just wanted to get the prototype..! But I also wanted to make sure that I am following all guidelines properly with some margins

QDrives , 05-05-2025, 02:41 PM

Different layers have different Dk values (and loss tangent) and therefor different propagation delays.
Using the same layer for groups helps you to not make delay calculation more difficult.
Do not "length" match signals, match the "delay". Add the delay to the vias to make it possible.
It requires 'correct' Dk values, so ask your fabricator what they are.

The stub is not so much for EMI, but for signal integrity. Though the 'ringing will increase EMI too.

sam , 05-05-2025, 02:47 PM

The tool that I am using (Altium) takes account of Dk values when calculating delays depending on whether signal is microstrip or stripline. And all these delays are well tracked in the software. I did input Dk value from manufacturer. Other than this, dose this look okay in general?

QDrives , 05-05-2025, 11:23 PM

When a board is produced, the layers are pressed together. You have cores and prepreg.
The resin on the prepreg also needs to get between the traces. So after pressing, the thickness of the dielectric layer gets a little thinner compared to the original prepreg.
When the thickness changes, so does the Dk.
Besides this, there are multiple thicknesses of seemingly the same prepreg. I know that Isola has 3 different 1080 prepreg thicknesses.
That is why I said that you should consult with the fabricator to get an accurate Dk value.