Large setup timing violations when higher capacitive load is configured for output

[Syndace]

Hi!

For our next tapeout, I would like to set realistic timing constraints, including the capacitive loads that needs to be driven by outputs. From a bit of research I found the following rough guidelines:

output pad -> short PCB trace -> target: ~2-5 pF
output pad -> PCB trace -> pin header -> cable -> ... -> target: ~20-50pF

So I went ahead and used set_load 50.0 [get_ports {...}] for all output ports that I expect to be routed to a pin header and then connected to another device via cables, for example the JTAG TDO output.

This, however, causes severe setup timing violations, which makes me think that I am misunderstanding something. The violations look like this:

Everything looks normal until the signal reaches the I/O padcell, at which point a delay of a whopping 22ns is added.

I have prepared a little example design that builds in just a few minutes with ORFS, based on the i2c-gpio-expander example: i2c-gpio-expander.tar.gz. Replace flow/designs/ihp-sg13g2/i2c-gpio-expander with this and use make DESIGN_CONFIG=./designs/ihp-sg13g2/i2c-gpio-expander/config.mk to build the design. Note that you need to run the OpenROAD master branch, since this needs a fix that was merged just a few hours ago.

Is that normal/expected? Am I doing something wrong?

Thank you for this amazing toolset and all of the other work you do for open-source hardware design!!

[QuantamHD]

If I'm understanding your situation correct that seems about right. 22ns is about 45Mhz. In my experience gpio cells can only really achieve speeds in the 50mhz range.

If you need faster IO you have to use speciality IO like serdes or LVDS

[Syndace]

Thanks! Unfortunately I might be lacking the background knowledge to understand how this relates to capacitive load.

The 22ns are not the clock period, but the amount of time STA thinks it takes the cell to achieve the target logic level given the load of 50pF, right? If I change the load to 100pF, the delay value changes to 44ns. With 5pF it's only 3ns.

[QuantamHD]

I think you have it right. Just imagine that the capacitative load on the IO cell is like a battery. It has to be charged and discharged in before other transistors recognize it as a 1 or a 0. The speed at which the IO cell can fully drain or fully charge this capacitive load is fixed, it can only move so much charge per unit time so the larger the capacitance the slower the signal will drain.

This is a general problem of chip IO, and why memory access off chip is so much slower than SRAM on chip. There's whole classes of physical IO techniques to try to get over these problems, like the ones I mentioned above. These limitations drove a lot of early computing, namely why the parallel port exists (easiest way to get more data off the chip is to mux N bits of data into N GPIO pins). Which then runs into synchronization issues across all the parallel pins, and signal integrity issues from noise induced long parallel wires.

Which then drove people back to serial lines like USB, which are essentially parallel ports over single physical lines. Serializer/Deserializer (SerDes)

[Syndace]

Thank you very much!

My use-case felt so "everyday" to me that seeing the flow struggle to match the timing requirements made me think that I must have done something wrong. I wouldn't have thought that a few pF of capacitance can already make "slow" frequencies like 50 MHz hard to reach, thanks for giving me perspective on that!

[rovinski]

There's a lot to unpack here.

The first thing you should note is that off-chip wires need to be driven by some kind of off-chip driver. The most basic one for digital designers to access is a GPIO cell. I think you are using one here, but it's not 100% clear.

From a circuit perspective, GPIOs just look like very large buffers (buffers with a very high drive strength). The drive strength is hundreds to thousands times stronger than what you will find for any standard cell. This is because the off chip wire is hundreds to thousands times larger than on-chip wires and has proportionally larger parasitics as well. GPIOs also have things like electrostatic discharge (ESD) protection, level shifters, and some control logic, but those aren't particularly important.

The second thing to note is that unlike on-chip wires which are almost always modeled as RC circuits, off-chip wires have to usually be modeled as transmission lines or distributed RLC circuits because the inductance from wires and of this scale is no longer negligible. At this point, the signals can no longer be analyzed by STA because STA is RC-only analysis. You would need to use other analysis tools to verify the integrity of the signal.

The rule of thumb of when you switch from RC analysis to T-line analysis is if line length (total wire distance between transmitter and receiver) is greater than 10% of the wavelength of the signal ($L>0.1\lambda$), and $\lambda=c/\epsilon_rf$. If we assume the dielectric coefficient $\epsilon$ is about 4 for FR4 material on PCBs, then that gives us the inequality $L>1.5e7/f$ where $f$ is the signal frequency. So for example, if you have a PCB trace of 6 cm, the highest frequency you could use RC analysis for it would be 250 Mhz. If the frequency is higher than that, then RC analysis will not provide accurate results.

This is also not to say that RC analysis can't be done, however it could be overly pessimistic. It could also be overly optimistic if the model does not account for coupling capacitance between wire on the package and PCB, as this is often a significant factor in off-chip interconnects.

Now obviously, higher speed off-chip signals exist. The DDR5 spec goes up to 4.4 GHz, for example. The interfaces for these are not just drop-in GPIOs that designers can use. These are full-on analog/mixed-signal interfaces that are very carefully designed in combination with the package and PCB to achieve those data rates before being converted back into digital signals. The IP for these interfaces costs usually 100 thousands to millions of USD.

TL;DR

The main takeaway from all of this is that if you are doing low-speed design (where low-speed is again defined as $L<\frac{c\epsilon}{10f}$) then you could use the STA results on the I/O as good analysis. If you are operating outside of the low-speed regime, you should ignore the STA results and use a more appropriate analysis tool.

What @QuantamHD says is correct from GPIOs, you shouldn't expect more than ~100-250 MHz signals to be transmitted. In one of my previous chips, we were able to get GPIOs to run at 500 MHz by doing some very careful design on the PCB side. But that's kind of near the absolute limit before you need to switch to different interfaces.

[Syndace]

Wow. Thank you SO much for taking the time and effort to write this extensive explanation and share your knowledge with me!

I had a bit of trouble reproducing your numbers: just plugging in $c = 3e8 \text{ m/s}$, $\epsilon = 4$ and $\mathit{f} = 250 \text{ MHz}$ gives me a maximum length of ~48cm, not the 3cm you ended up with. So I tried to look up the relevant formulas instead and ended up with a slightly different inequality:

$(1) v_p = \lambda \mathit{f}$
$(2) \epsilon_r = (\frac{c}{v_p})^2$
$(3) L < \frac{c}{10 \mathit{f} \sqrt{\epsilon_r}}$

This gives roughly 6cm for the values above.

Either way, even the more conservative inequality gives me at least 15cm to work with at 50MHz (even more in cables with PVC/Polyethylene insulation), which means that per the rule-of-thumb, I should be able to stick with RC-only analysis for now!

This gives me confidence that I am on the right path and simply underestimated how much of an influence just a few pF of capacitive load can have on timings. I will trust the timing analysis and fix the setup violations by using a slower clock and/or requiring shorter cables :)

Thank you again, this has been super interesting and made my day.

[rovinski]

Yep, shame on me for trying to do math off the top of my head. The formula was written wrong because of trying to write it in latex format, but I did indeed forget to square root $\epsilon_r$, which is why $L$ should be 6 cm and not 3 cm. I have fixed the comment.

This gives me confidence that I am on the right path and simply underestimated how much of an influence just a few pF of capacitive load can have on timings.

Something else to mention is that GPIO cells are also usually rated by the maximum current that they can supply. Sometimes this is listed in a data sheet, but sometimes it's not and the easiest way to measure it would be to run a SPICE simulation. I guess maybe you could also loosely estimate it by using $\Delta Q = C\Delta V$, where $\Delta V$ is the voltage swing and $C$ is a fairly large cap. Then $\Delta Q / t = I$ gives you your estimated current. So as an arbitrary example, if the

1. Load cap is 1e-9 F
2. I/O voltage is 1 V
3. Transition time is measured as 30% to 70% of VDD
4. Transition time (not delay) is 1e-9 s

Then

1. Voltage swing $=(70\% - 30\%) * 1 V = 0.4 V$
2. $\Delta Q = (10^{-9} F)(0.4 V) = 4*10^{-10} C$
3. $I = 4*10^{-10} C / 10^{-9} s = 0.4 A$

So the max current is roughly 0.4 Amps.

It could very well be that the GPIO cell you are using has a low max current, which will limit the speed you can get out of it. This is generally true in the low-speed regime, but confusingly, sometimes a lower current is better in the high-speed regime because it reduces noise.

Another hangup to consider is that the GPIO Liberty files are only characterized to a certain maximum capacitance. If your load capacitance is outside of that range, the STA tools are at best making an educated guess about what the timing should be, rather than rigorously calculating it. I don't actually know how OpenSTA handles this.

Anyways, the whole thing can be unfortunately complicated. I wish you all the best and hope that the GPIO cells meet your needs.

[Syndace]

Yep, shame on me for trying to do math off the top of my head.

Please, no shame! This is incredible information that I couldn't find by myself, the formulas are just details :)

Something else to mention is that GPIO cells are also usually rated by the maximum current that they can supply.

Right. In my case it's well documented, I have access to output I/O cells for maximum currents between 4mA and 30mA. That was actually the first thing I tried: I intuitively thought a higher current should overcome the capacitive load more quickly, so I tried using the 30mA cell, but the difference in timing was unfortunately negligible, so I switched back to the 4mA one to keep requirements on the power supply/PDN etc. low.

Another hangup to consider is that the GPIO Liberty files are only characterized to a certain maximum capacitance.

Thanks for this important pointer too! It seems the I/O cells I'm using only provide accurate timing models up to a few pF of capacitive load, nowhere near the 30-50pF I'm targeting. I have raised an issue about that with the providers of the PDK and will in the meantime try to simulate the timings with SPICE (though I'm not too confident in the accuracy of the SPICE models either ^^).

I wish you all the best and hope that the GPIO cells meet your needs.

Thanks!

[maliberty]

 cell (sg13g2_IOPadOut4mA) {
    pin (pad) {
      direction : "output";
      max_capacitance : 1.1116;

The .lib table is characterized up to 10pF. A load of 50 is way above the max cap and table values so no accuracy is expected.

[Syndace]

Is that even 10pF and not just 1? The unit definition looks like this:

capacitive_load_unit (1,pf);

Either way, this seems way too low for an I/O cell and I've raised an issue about it here: IHP-GmbH/IHP-Open-PDK#676

Thank you for checking :)