STM32MP257 DDR4 (2133MT/s): Cross-layer skew (L3/L6), empty IBIS RLC, and Pin Delay compensation

[martincuber]

Hi everyone,

I'm currently validating a custom board featuring the STM32MP257 interfacing a single 16-bit DDR4 at 2133MT/s (Point-to-Point topology). I am using the ST-provided Excel tool ("Examples of DDR memory routing on STM32MP2 MPUs") to extract the Die-to-Ball Package Trace Lengths (mm).

I’ve run into a few specific SI conflicts regarding the hardware guidelines, primarily driven by my PCB stackup. Due to routing density, my Address/Command (A/C) signals are split across two different layers:

• L6 (Bottom Layer): Microstrip. Outer solder mask is 0.6mil (Dk 4.85) over a 3.91mil 3313 Prepreg (Dk 4.4). Effective Dk is much lower due to air exposure.

• L3 (Inner Layer): Stripline. Sandwiched between a Core (Dk 4.6) and Prepreg (Dk 4.5). Effective Dk is approx 4.5.

This leads to the following questions:

1. Balancing Physical Length (mm) vs. Electrical Delay (ps): The ST guideline dictates an A/C to CLK_P/N equalization of +/- 140 mils (3.55 mm). However, if I strictly match the physical length (mm) in Altium, I get a ~21ps time skew in HyperLynx simply because signals on L6 propagate noticeably faster than on L3. For cross-layer routing, should I completely ignore the mm-based tolerance in the ST Excel sheet and tune my traces strictly by Time Delay (Total ps)?

2. Missing RLC Parameters in the IBIS Model: While investigating this skew, I checked the official IBIS model (stm32mp251_253_255_257_tfbga436.ibs). I noticed that the global [Package] parasitics are zero, and the per-pin R_pin, L_pin, and C_pin fields are completely empty. Given the lack of package parasitics in the .ibs file, does a standard timing simulation in HyperLynx still hold reference value, or is the simulator fundamentally blind to the internal package skew?

3. Strictness of the +/- 3.55 mm Tolerance: Is the +/- 3.55 mm (approx. +/- 21ps) limit a hard, absolute boundary that will cause DDR4 training or boot failures if slightly exceeded, or is there a built-in safety margin assuming standard Tx/Rx jitter budgets?

4. Validating the 6 ps/mm Conversion: If the correct approach is to route by Time Delay (ps), I need to convert the Package Trace Length (mm) from the Excel sheet into a Pin Delay (ps) value for my EDA tool. Is it an acceptable industry practice to use ~6.0 ps/mm as the propagation speed for the STM32MP2's internal BT resin substrate to calculate this compensation?

Any insights from ST staff or anyone who has successfully validated an MP2 DDR4 design would be highly appreciated.

Thanks in advance.

[martincuber]

Quick clarification on my tuning methodology:

I realized my original post might have been slightly misleading regarding how I actually routed the board. I am not blindly matching the physical PCB trace lengths.

Here is my actual workflow:

1. I took the Package Trace Lengths (mm) from the ST Excel tool and converted them to Pin Delay (ps) using roughly 6.0 ps/mm.

2. I inputted these ps values into my EDA tool (Altium) as internal Pin Delays.

3. I then tuned my A/C signals to match the Total Delay (ps) (Pin Delay + PCB Trace Delay).

Because my signals run across layers with different effective Dk (L6 Microstrip vs. L3 Stripline), the resulting physical PCB traces are intentionally unequal in length to achieve this perfect time-domain alignment at the die.

The core issue: Even after perfectly matching the Total Delay (ps) in my CAD tool, HyperLynx still reports a ~21ps skew.

Given that the official ST IBIS model (stm32mp251_253_255_257_tfbga436.ibs) has completely empty [Package] and [Pin] RLC parameters, my strong hypothesis is that HyperLynx is entirely blind to the internal package delays. Therefore, the simulator is simply measuring the intentional time mismatch of my raw PCB traces, flagging my compensation as an "error."

My revised questions for the community/ST staff:

1. Is my workflow (converting ST's mm to ps and tuning by Total Delay) the officially recommended approach for cross-layer DDR4 routing?

2. Since the IBIS model lacks package parasitics, should I simply ignore the timing skew reported by HyperLynx BoardSim?

3. Does ST provide a high-frequency package model (e.g., S-parameters / .sNp / .pkg) for the MP257 so I can run accurate End-to-End timing simulations?