Public

Thread: Slew and Cap Violations

13 Discord messages from ℹ️ - Information/⁉️-questions/threads/slew-and-cap-violations.md.

Category: ℹ️ - Information Parent channel: #⁉️-questions Thread ID: 1448681884409266308

Messages: 13

message-1448681884409266308

2025-12-11T14:24:36.451+00:00 — Trevor Peyton (@trev5514)

Content

LibreLane says (https://librelane.readthedocs.io/en/stable/usage/timing_closure/index.html):

"Violating maximum capacitance and maximum transition constraints are OK if you don’t have setup/hold vios. It is always good to check them as they are indicators of design issues. For example, a high capacitance on a net means high fanout and/or long interconnect. Also, high transition time means a high capacitive load and leads to a higher short circuit power and delays."

My design is passing timing, however I have massive slew and capacitance violations from:

bidir_PAD[13] (inout)
Fanout: 1
Cap: 3.530755
Slew: 99.174812
Delay: 54.912
Time 72.9128

This is roughly the same for every bidir_PAD.

I've been trying to make the pad capacitance more realistic to the .lib files with no luck. Any ideas?
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/2-ADBB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1448685620598673644

2025-12-11T14:39:27.228+00:00 — tnt (@246tnt)

Content

That's unreadable ...
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1448685801327296605

2025-12-11T14:40:10.317+00:00 — tnt (@246tnt)

Content

put the full timing report as a .txt not pasted like that because with discord reformating it's impossible to read it unless you already knows what it says.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1448685943631384739

2025-12-11T14:40:44.245+00:00 — tnt (@246tnt)

Content

Also post a link to your repo so we can refer to the code and config.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1448686623309959280

2025-12-11T14:43:26.293+00:00 — Trevor Peyton (@trev5514)

Content

@tnt It was tab delimited, so I thought it was semi-redable sorry about that. Updated with a cleaner version.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/2-ADBB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2025-12_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
        "color": null,
        "discriminator": "0000",
        "id": "596068704471482370",
        "isBot": false,
        "name": "246tnt",
        "nickname": "tnt",
        "roles": []
      }
    ]
  }
}
</details>

message-1448686766675722291

2025-12-11T14:44:00.474+00:00 — Trevor Peyton (@trev5514)

Content

My code is not open source, I'm using the default project-template sdc and config. The exception is a 90ns clock.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/2-ADBB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1448703684291854446

2025-12-11T15:51:13.948+00:00 — Lofty (@ravenslofty)

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1448681884409266308",
  "guildId": "1361349522684510449",
  "messageId": "1448681884409266308"
}
</details>

Content

(my understanding is that this advice was intended for sky130; I do not know how well it applies to gf180mcu)
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/dd665ae27be32531af89aeb08fd05e04-1D5A4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2025-12_media/2-ADBB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "805909190333038612",
        "isBot": false,
        "name": "trev5514",
        "nickname": "Trevor Peyton",
        "roles": []
      }
    ]
  }
}
</details>

message-1448799177835413534

2025-12-11T22:10:41.383+00:00 — Meinhard Kissich (@meinhard)

Content

`DESIGN_REPAIR_MAX_SLEW_PCT`, `DESIGN_REPAIR_MAX_CAP_PCT`, `GRT_DESIGN_REPAIR_MAX_SLEW_PCT`,
`GRT_DESIGN_REPAIR_MAX_CAP_PCT` (edit: and also limiting the max wire length)
helped on my design to get better slew/cap. But that slew seems to be very large. Which corner are you looking at?
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/5-E9BDB.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1448839133522034860

2025-12-12T00:49:27.561+00:00 — Trevor Peyton (@trev5514)

Content

All of them!
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/2-ADBB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1448839442801627400

2025-12-12T00:50:41.299+00:00 — Trevor Peyton (@trev5514)

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1448681884409266308",
  "guildId": "1361349522684510449",
  "messageId": "1448799177835413534"
}
</details>

Content

Awesome, didn't know about those, I'll give them a try.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/2-ADBB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2025-12_media/5-E9BDB.png",
        "color": null,
        "discriminator": "0000",
        "id": "270286460668739587",
        "isBot": false,
        "name": "meinhard",
        "nickname": "Meinhard Kissich",
        "roles": []
      }
    ]
  }
}
</details>

message-1448839817772269768

2025-12-12T00:52:10.699+00:00 — Trevor Peyton (@trev5514)

Content

So an update (still in progress):

I removed the max_capacitance from the project template SDC and that seemed to help significantly, looks like things are falling back to the .lib files. Is there a major downside to doing this?
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/2-ADBB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1448841297304748042

2025-12-12T00:58:03.447+00:00 — Trevor Peyton (@trev5514)

Content

Also, this line is from the 7t std cell:

```tcl
# update these
set ::env(OUTPUT_CAP_LOAD) "72.91" ; # femtofarad from pin I in liberty file
```

But this is being applied / 1000 to all outputs in the project-template:

```tcl
set cap_load [expr $::env(OUTPUT_CAP_LOAD) / 1000.0]
puts "\[INFO] Setting load to: $cap_load"
set_load $cap_load [all_outputs]
```

This seems very low to me for output cells. I upped it to 25000  to have a cap of 25 and it removes most cap violations. Again can anyone inform me if this is a very bad idea and I'm missing something?
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/2-ADBB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1449008065323204791

2025-12-12T12:00:44.041+00:00 — Leo Moser (mole99) (@mole99)

Content

Hi @Trevor Peyton!

The default setting of `OUTPUT_CAP_LOAD` is intended to be used for macros, i.e., circuits that you integrate into a larger circuit.
When we implement the macro, we want to consider the external capacitance, which, in the case of standard cells, could be a large buffer e.g. `mcu7t5v0__buf_16`.
From what I see, the input capacitance of the `mcu7t5v0__buf_16` is ~0.03683 pF = 36.83 fF, so I'm not sure where the exact number here comes from, but it's close enough.

Now, for a chip top-level design we should set `OUTPUT_CAP_LOAD` to the capacitance that is actually outside of your chip, i.e., whatever your chip will drive.
However, if we think about it, from the point of view of the implementation it doesn't really matter what we set `OUTPUT_CAP_LOAD` to because OpenROAD can't resize that path anyway.

The reason is the following:

```
core -> pad -> port -> external capacitance
```

OpenROAD can resize all of the paths inside the core. However, once a signal goes to the pad, that's it. The output of the pad is the bondpad, so nothing can be changed in that path.

Given that we set a very low output cap with 72.91 fF, and that the pad is a very strong driver (max cap of 30pF in the libs), I'm surprised that you see violations in this path. Also, increasing `OUTPUT_CAP_LOAD` should make it harder to meet the maximum capacitance limit.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2025-12_media/3c7c17f3225f6e56f4dccd83f14383f2-73F83.png",
    "discriminator": "0000",
    "isBot": false,
    "roles": [
      {
        "color": null,
        "id": "1423020172595298314",
        "name": "Mod",
        "position": 4
      }
    ]
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2025-12_media/2-ADBB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "805909190333038612",
        "isBot": false,
        "name": "trev5514",
        "nickname": "Trevor Peyton",
        "roles": []
      }
    ]
  }
}
</details>