wafer.space Community
ℹ️ - Information / ⁉️-questions / Is magic PEX extraction expected broken for `gf180mcu_fd_sc_mcu7t5v0__fillcap_64`?
Between 2026-04-30 11:59 p.m. and 2026-06-01 12:00 a.m.
Error in extracting node gf180mcu_fd_sc_mcu7t5v0__fillcap_64_40578/a_3260_375#
Bad Device Location at 585660,629620
Couldn't find device at 585660 629620
.tar.zst if you want, including the script that did that and the git commits involved in it happening.
.t0 .t1 and kill the original with the # suffix) and compute the resistance between them.
1O(n) than naive O(n^2) (to a worst case of O(n^1.5) aka O(n^(3/2))) by:
1. As resistors are undirected edges, roughly presume we just want each resistor in both directions in any index structures (minor improvements can later be made).
2. Create an index giving us a list of target nodes for each source node (the resistor metadata is carried as auxiliary data with each list entry).
3. If needed for some access efficiency use a separate index (otherwise use the same and keep a tuple of (list((target_node, resistor_identity_metadata)), length(that_very_list))) to quickly look up how much fan-out happens from grabbing that list from a given key into the first index.
4. Iterate through the list of edges.
5. For each edge, look up both the first and the second node of that edge in the length-index (the second index, from 3.) and decide which one has less fan-out.
6. Look up the one with less fan-out in the first index (from 2.) to get the worst-case-optimal choice of what the second edge is and what the third edge will be for specifically the current iteration (first edge) of (4.).
7. Screen each such-fetched triangle node-triple, specifically the two nodes still dangling (i.e., the non-chosen one from the first edge and the target node of each entry of the second edge), against a hash table or similar set membership test data structure to spend only constant time on each candidate of the third edge (this I think is currently being done since the upgrade to O(n^2); the major trick is just to dynamically choose the less-costly vertex aka join-order for each first edge).
8. You have successfully completed the task of enumerating all triangles in at most O(n^1.5) time.
I'll see to get profiling up so I can hopefully run PEX against a similarly edited GDS of the TinyQV quarter cell submission that "only" has 4 VSS and 4 VDD bond pads and is, well, a quarter the die area (usable area not just filled with power rings/IO cells is smaller), in hopes of that GDS being large enough to exercise poor scaling but small enough to not take as many hours to even just load (such that we could reasonably use it for full profiling runs in the coming performance/throughout enhancement updates I hope to contribute greatly to).
1
1
1
malloc-spam goes, KDE's heaptrack (from the same author as KDAB's hotspot) has done wonders for me when I used it on some photogrammetry/structure-from-motion toolchain TU Darmstadt's MVE.
Small commits like https://github.com/namibj/mapmap_cpu/commit/54076e35bc99ae882672e91b28b8308d681898e7 (heaptrack), https://github.com/namibj/mve/commit/09c252dea56d2e4d78993ee6e0fc5663821d8509 (hotspot), or https://github.com/namibj/mapmap_cpu/commit/fc6ea70ddccfc08f0768cf6f530fe13d179f88ad (iirc this one was highlighted by heaptrack for suspicious allocation intensity, then hotspot was used to get a quantified understanding of how bad it seemed to be to try and estimate how much whole-program speedup could be reasonably expected to be attained, before I looked for a suitable (smol, easy, compatible licence) concurrent union-find library to "easily" vendor into the project and swap out the BFS implementation of the connected-components task for a union-find one. See below for excerpt of the changed file that should make obvious how this kind of problem could be surfaced by heaptrack.), are representative of the impact I managed with those 7 years ago.
/**
* A complet contains a partial component: a list of node, its temporary
* component ID and the ID of seen other complets
*/
using complet = std::tuple<std::vector<luint_t>, luint_t, std::set<luint_t>>;
tbb::concurrent_vector<complet> accrued_complets;
I ended up building a mini-datacenter to deal with the heat and stuff....
1
1
nfet_03v3_nvt and hit approximately as (in-)accurately as the regular process corners (ff/fs/sf/ss) already are?
I'd try to make it for this tt experimental shuttle at least to get the MCML VCO + NRZ serialiser completed drawn, and I'd quite like to use them in the upper level of the D-latch DIV2; bias current is externally supplied anyways and should cover a lot of potential variation, it's only really the strength of the memory pair vs. the input pair that really matters due to the tail current source so yeah...
Honestly I am severely surprised they just left it out? Completely?
I'd think we should at least get some etest data, that has to exist, right?
nfet_03v3_nvt should not have parameters s_sab and d_sab. Those parameters exist only for the "drain-side (un)salicided" devices which have the suffix _dss. The dss devices are very different and the nvt device should not be derived from them. nfet_03v3_nvt? It did not exist in the original GF PDK. It probably exists in other GF180 processes, where the model might even be similar enough to use as a placeholder until we can characterize the device ourselves. Getting GF to open source that model is a separate question, though. NAT mask layer on the upcoming runs, but I guess it's easier than modifying the PDK tooling to get rid of it and change what exdact process is run at glofo.) 
NAT GDS layer just tells the mask generation to not put implants on that transistor ... 05v0_nvt device in sky130 works quite well as a cascode on top of a normal 3.3V nFET, and the gates of both devices can be driven with the same voltage, avoiding the need to set up a cascode voltage on the n side.