Questions about Coupling Cap in openSTA
Summary
In openSTA, we found three data structures about coupling cap.
There are ConcreteCouplingCapInt,ConcreteCouplingCapExtNode and ConcreteCouplingCapExtPin.
And the ConcreteCouplingCapInt is Node to Node, the remaining ones are Node to Ground.
But if we want to construct a ConcreteCouplingCapInt, we need to check whether the two nets isConnect.
The question is, isn't the coupling cap supposed to appear between two different (unconnected) nets? Does the function isConnect have a semantic error?
Detail
We test on a small case, like:
The coupling cap is between b0z(*11:1) and b1z(*14:1), like:
We are using GDB to trace debug the
findParasiticNode within makeCouplingCap:
We found that
node1 is nullptr:
And in the function
findParasiticNode,we found there is a function isConnect:
The
net and net_'s value is below:
OpenSTA checks if
net and net_ are connected. If it's true, then give a node return.
We think if two nets aren't connected, it should give a node return to construct a ConcreteCouplingCapInt.
So we are confused about the meaning of the function isConnect.
Data
The test case is below: example.tar.gz
First of all, your example cannot be run in OpenSTA because it uses a DEF netlist. I needs to use verilog, which you can get in openroad with the write_verilog command.
There is no function isConnect. The function you are referring to is Network::isConnected. In your example the coupling capacitor is between two different nets, which are NOT connected. So isConnected returns false, as it should and creates a ConcreteCouplingCapExtNode device which is correct.
ConcreteCouplingCapIntNode represents a coupling capacitor between two subnodes in the same net, which is not the case in your SPEF.
This repository is a fork of the OpenSTA repo that is not monitored by the author of OpenSTA. Use https://github.com/parallaxsw/OpenSTA.git to post issues in the future.
Issues or PRs should be filed with https://github.com/parallaxsw/OpenSTA if still relevant. This is effectively a fork (though not strictly for historical reasons).