FEDEVEL
Platform forum

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.

sam , 05-15-2025, 08:06 AM

@QDrives Hello.. I ended up re-routing all addr/ctrl/clock signals as I don't have other simulation tools and validate signal integrity. In that case, I thought it would make sense to follow every single guideline just like you suggested about stubs. Finally it seems good to me but I wanted to get some advices in general how this looks to you. I was not able to route all signals in the same layer due to spacing issue but I tried to kept them as short as possible. I did contact with manufacturer and got their Dk value. I will have to adjust trace or spacing depending on their processed thickens. Most likely I will keep trace width and space as I designed but may have impact on controlled impedance. It should not change more than 10% according to manufacturer. Delay in different layer has been taken account so all delay are matched for addr/ctrl/clck signals. Delay difference due to impedance changes less than 10% will not have much impact on delays according to my calculations.

My main question here is about traces between last memeory (M2) and terminating resistors. UG933 recommended to have these terminating resistors for better signal integrity purpose. I did not include these in the delay matching as it was not mentioned in their app note and also I found some comments that I do not have to match delays as long as I keep them in short (app note says < 1 inch so fine for my signals).
Controller -> M1 -> M2 -> terminating resistors (either top or bottom layer)

Some terminating resistors on top and some are on bottom. All signals are terminated with resistors after signals reach to M2. But there is one signal (one of address signal) located on top that is connected to terminating resistor spitted between M2 and terminating resistor(see top layer image). Does this really matter? Please see below for better understanding and let me know if you have any recommendation or need any clarifications. Thank you

sam , 05-15-2025, 08:07 AM

Layer 8

sam , 05-15-2025, 08:07 AM

Layer 6

sam , 05-15-2025, 08:08 AM

Layer 10 (Bottom)
MaybeI can bring these caps and resistors closer to the M2 pins but then I have to have long traces to connect ground vias. I put them all so it dose not overlap signals below. (I am using through hole vias 😦 )

sam , 05-15-2025, 08:13 AM

Layer 1 (Top)

sam , 05-15-2025, 08:20 AM

Addr/ctrl/clock signals goes from Top -> L8 -> some are brought back to top due to spacing issue (short traces) then continue to L6 or just routed all in L6 -> Top or bottom (terminating resistors)

sam , 05-15-2025, 08:24 AM

Also, I do have qutie of accordions or meanders for delay tuning.. I have some of them really big as you can see in L8 and L6. Is this normal to have? I tried to keep space between each traces at least 0.45mm or 0.4mm minimum. Shorted distance from its trace and rerference ground plane is 0.15 mm so I tried to use 3H rule if applicable.. I also tried to use crosstalk calculator to approximate crosstalk and I don't think it really had much impact on my signals here as I am using 1.35V and there are enough margins in both high/low threshold voltages of these signals.