Measuring full trace length - preferably on the fly

[ilia.vitsnudel]

Hello,

I am trying to make similar trace length on several signals (not a differential line). Where can I find the trace length indication to help with this task? The traces are curved. Preferably, I would like to see the trace length on the fly as I layout the line.

I have tried to Google it and looked in forums but couldn't find something useful until now.

Thank you,

Ilia Vitsnudel

[Evert_2N3055]

Have a look at the length-freq-ri ulp, maybe this will meat your requirements. Not exactly what you want, but .....

[ilia.vitsnudel]

Thanks,

Indeed using this ulp command reports the trace lengths. Like you said, not
exactly what I want but one step further. I will have to lay out the lines
and then check it until I get more or less the same line lengths.

Ilia

[jorge_garcia · Accepted solution]

Hello @ilia.vitsnudel ,

For length matching and measuring the length of traces I find the meander command to be much easier to use. You don't have to meander , you can just grab the measurement.

Let me know if there's anything else I can do for you.

Best Regards,

[harrison_raynerG2JSL]

This tool is awful. How do I find trace lengths between 5 sets of diff pair signals as in a 4-land MIPI connection. Meander balances between the pairs; to do any real high speed design, it takes a bit more - I'd die if I had to route a ddr interface with it (and actually need it to work). 

[jorge_garcia]

Hello @harrison_raynerG2JSL ,

I hope you're doing well. See above, the meander command can give you the length of the selected pair. Find out which one is the longest then you can equalize all of the pairs to that length. There are a few users doing ddr with the meander tool. I agree it could be better and would be easier if it could handle multiple pairs but it's possible. If memory serves Quicktune let's you tune multiple signals and not just one pair.

Let me know if there's anything else I can do for you.

Best Regards,

[pal.szabo]

Hi @harrison_raynerG2JSL , @ilia.vitsnudel,

Back in the Eagle days I modified length.ulp to aid me with DDR and high-speed matching, see attached. The trick is that you actually want to match the propagation delay (not the length) inside a signal group to meet the timing requirements of high-speed interfaces. The signal propagation speed is not the same on the outer layers as on the inner layers (see also effective Dk in e.g. Saturn PCB Toolkit). The attached ULP computes the propagation delay for a list of signals. It's also possible to combine signals and measure total delay (e.g. when you have one net before a series resistor and one after). It also can show the delay impact per layer. I don't recall handling curved lines, so the computation part must be updated for that use case, but that should be fairly simple.

Feel free to share any bugfixes/updates 😀

Best regards,

Paul

[chuck_toddN7PTC]

@jorge_garcia 

I have a 4 lane CSI bus that I am routing.

Since I moved to Fusion Electronics,

I have been getting my signal lengths from the design manager by grouping my signals in a net class. As shown below.

    

The results from delay.ulp on the same signals.

The results from length-freq-ri.ulp on same signals.

Comparing the length from all three.

The ULP length results corollate, but not with the length results from the design manager.

For example:

Signal          delay.ulp           length-freq-ri.ulp                     Design Manager   

S0_D3_P     15.127mm          15.127mm                                    16.782mm

What could be causing this discrepancy? Which result is the correct one?

BR -Chuck

[pal.szabo]

Hi @chuck_toddN7PTC,

I checked a couple of signals and the difference was 1.655mm for all of them. Just checked it on a layout and it appears that Fusion takes vias into account. It even seems to compute how much of a via is used, i.e. if the signal goes from top layer to inner1, it only adds the distance between these layers, even if the via goes all the way through.

ULPs cannot do that automatically, because they don't have access to the layer stack information. It could (should?) be added of course for more precise delay/length calculations, but then this information would need to be an input parameter to the ULPs.

Best regards,

Paul