wafer.space Community
ℹ️ - Information / general
Welcome to wafer.space - documentation at wafer.space github - buy at buy.wafer.space - archives at discord.wafer.space
Between 2026-06-30 11:59 p.m. and 2026-08-01 12:00 a.m.
2
1
2
2
1
2
2
.nodeset's to cover all multistable/regenerative-feedback node voltages,
conparam entry that happens after the mosfet:gainscale and mosfet:nltermscale entries, which will be essentially the output conductance of the current-type B-source which hard-forces the stateful digital logic cell's internal node voltage to the reference DC static voltage of the desired internal state of that particular cell, and is ramped from a very high conductance (strong but still sufficciently numerically behaved especially when it comes to transitioning out of the forced state; I'd probably just start with 1 siemens for any vaguely normal CMOS SCL internal nodes) down to literally 0 (which will have it be open-circuit at transient sim runtime). The parameter names legal to put into conparam are the same ones that are also legal to .STEP (the docs for how to casually do .STEP are far far easier to approach/read/understand than the fancy continuation stuffs).
.options loca stepper=1 predictor=1 stepcontrol=1 could be semi-necessary to (properly/reliably) handle the effects of combinatorial loops through the (non-transparent at the time of the continuation solving!) flip-flops; if the continuation DC OP point solve ahead of the transient sim itself takes too long it'd be worth testing whether it's sufficciently robust with the tangent predictor 0 and thus the downgrade from the arc-length continuation stepper=1 to stepper=0.
Though I guess maybe it has to do continuation over the output resistance and push that out to near-infinity in the continuation solve process (default is like 100 exa); the specified parameter constant value applicable outside of the special circumstances in which the LOCA does continuation on it, will need to be a sentinel (I'd suggest exact 0 or "anything negative"), as it shall be as non-interacting and as sparsified-away by the linear solver and all as possible (it's not a problem because the discintinuity doesn't happen while a non-linear solver tries to solve the system of equations and could have called the behavioral function with node voltages/branch currents far from anythign physical, because that's just discintinuos in a parameter, and that parameter doesn't change during any transient time integration...).
Overall the idea I'm proposing is to use gate-level digital sim (post-techmapping (and any retiming and other such intrusive changes to the logic) verilog-sim basically 
) to fast-forward to an interesting moment, snapshot all stateful state, map that against pre-computed DC op points of the cell library, use the LVS matching provisions to match that state to post-PEX SPICE node identifiers, emit a spice file to-be-.include'd full of those continuation-capable cell's-internal-node-forcing B-sources (test if things are faster when forcing combinatorial nets as well, or if the additional effort expended negates the faster convergence; .nodeset is likely cheaper for those though it's just not reliable), and start the .tran sim..nodeset's to cover all multistable/regenerative-feedback node voltages,
conparam entry that happens after the mosfet:gainscale and mosfet:nltermscale entries, which will be essentially the output conductance of the current-type B-source which hard-forces the stateful digital logic cell's internal node voltage to the reference DC static voltage of the desired internal state of that particular cell, and is ramped from a very high conductance (strong but still sufficciently numerically behaved especially when it comes to transitioning out of the forced state; I'd probably just start with 1 siemens for any vaguely normal CMOS SCL internal nodes) down to literally 0 (which will have it be open-circuit at transient sim runtime). The parameter names legal to put into conparam are the same ones that are also legal to .STEP (the docs for how to casually do .STEP are far far easier to approach/read/understand than the fancy continuation stuffs).
.options loca stepper=1 predictor=1 stepcontrol=1 could be semi-necessary to (properly/reliably) handle the effects of combinatorial loops through the (non-transparent at the time of the continuation solving!) flip-flops; if the continuation DC OP point solve ahead of the transient sim itself takes too long it'd be worth testing whether it's sufficciently robust with the tangent predictor 0 and thus the downgrade from the arc-length continuation stepper=1 to stepper=0.
Though I guess maybe it has to do continuation over the output resistance and push that out to near-infinity in the continuation solve process (default is like 100 exa); the specified parameter constant value applicable outside of the special circumstances in which the LOCA does continuation on it, will need to be a sentinel (I'd suggest exact 0 or "anything negative"), as it shall be as non-interacting and as sparsified-away by the linear solver and all as possible (it's not a problem because the discintinuity doesn't happen while a non-linear solver tries to solve the system of equations and could have called the behavioral function with node voltages/branch currents far from anythign physical, because that's just discintinuos in a parameter, and that parameter doesn't change during any transient time integration...).
Overall the idea I'm proposing is to use gate-level digital sim (post-techmapping (and any retiming and other such intrusive changes to the logic) verilog-sim basically ) to fast-forward to an interesting moment, snapshot all stateful state, map that against pre-computed DC op points of the cell library, use the LVS matching provisions to match that state to post-PEX SPICE node identifiers, emit a spice file to-be-.include'd full of those continuation-capable cell's-internal-node-forcing B-sources (test if things are faster when forcing combinatorial nets as well, or if the additional effort expended negates the faster convergence; .nodeset is likely cheaper for those though it's just not reliable), and start the .tran sim. 
1
1 1
1
1
1
1
1
1 1
1 1 1 2
1
1
NAT.4/NAT.5 minimum 1.8,
3. Un-salicided poly resistors narrower than the (I can only presume matching/process-control related) existing coded minimum widths: PRES.1 (0.8), LRES.1 (0.8), HRES.2 (1.0),
4. Y.PL.2 mentions 0.13 drawn channel length on thin oxide; I assume the short channel effects (possibly HCI) are generally considered too severe for other usage, but it's vendor lock to Yield Microelectronics Corporation is similarly restrictive to open source EEPROM on gf18mcuD as the proprietary-core-only tiny transistors on sky130 are to dense open source SRAM.
Like I wish I understood better what's keeping us from being allowed marking layers to not have to bother their engineers about structures that land between electrically recommended sizing and what the lithography can manufacture without risking damage to equipment or the rest of the wafer.
Could it be that some of this is from "Google-sponsored-runs" open PDK philosophy where the DRC co-writer (Google) had incentive to keep designers from submitting chips that don't work? 1 1
Please dig in and report any issues! 3 2 1
1
2 1
1
3
1
2
1
.gds, of which I expect to have to delete all labels but the pad labels myself, followed by fully flattening it. If you have any conventions on pad labeling, I'd prefer those to be applied already and this includes separating the VDD and the VSS pads individually.) PEX http://www.opencircuitdesign.com/magic//howto.html
One with just capacitances and one with resistors and capacitances. 1PEX http://www.opencircuitdesign.com/magic//howto.html
One with just capacitances and one with resistors and capacitances. .subckt fl_mcpu32 VSS VDD le clk rst_n rst_override_n din[0] clk_n din[11] din[10]
+ din[9] din[8] din[7] din[6] din[5] din[4] din[3] din[2] din[1] din[12] din[13] din[15]
+ din[14] address[0] address[1] address[11] address[7] address[8] address[6] address[4]
+ address[3] address[13] address[14] address[12] address[9] address[2] address[15]
+ address[10] address[5] dout[1] dout[2] dout[3] dout[4] dout[5] dout[6] dout[7] dout[15]
+ dout[14] dout[13] dout[12] dout[11] dout[10] dout[9] dout[8] dout[0] oeb bus_enable
+ web unused[0] unused[1] unused[2] unused[3] unused[4] unused[5] unused[6]
1
1
1
1
8
4 2 1
libs.ref and libs.tech directories from inside pdk and copy them. Go to your project template and paste them to gf180mcu/gf180mcuD/, merging with the existing two directories of the same names. Overwrite existing files. Re-run your flows. 5 2
1libs.ref and libs.tech directories from inside pdk and copy them. Go to your project template and paste them to gf180mcu/gf180mcuD/, merging with the existing two directories of the same names. Overwrite existing files. Re-run your flows. 5
1 1 1
1
2
1
1 1 1
1 4 3 1 Should have spent some cycles making little macros to put in corners as space allowed. i'll double check when I get home though! 1
) coming in from the short side.
I unfortunately don't expect to have much time to instantiate your full library and kekvin-connect it to those 18 wires, but I do expect to have shit 20~40 DUT slots spare that would love to take thin oxide standard cells.
I'll see to get the interface definition to that drawn up by about 3~4 hours from now and while not promising I can finish the wrapper and MUX in the deadline, I'll do my best. ) coming in from the short side.
I unfortunately don't expect to have much time to instantiate your full library and kekvin-connect it to those 18 wires, but I do expect to have shit 20~40 DUT slots spare that would love to take thin oxide standard cells.
I'll see to get the interface definition to that drawn up by about 3~4 hours from now and while not promising I can finish the wrapper and MUX in the deadline, I'll do my best. 1
1 2
1 1 1 6
1
1gf180mcuD/libs.tech/klayout/tech/scripts/fill_all.rb
klayout -b -zz -r path/to/script -rd input=input.gds -rd output=input.gds
1 1
1
1
2
4 5-wedge as it's not for wedge bonding (but flip chip); and it might need that corner marker stuff if that would trip the platform check.
Oh, and fill, per the defaults; also with fill in case that's easier:
(I think the without-fill is also not zeroes to the origin; that's fixed in the try2 which also has the fill.) 3
1
️ 2 1
1
3 2 5
I'm just seeing it being highly stalling on memory with also sadly substantial lacks in reasonable prefetching behavior (it's nowhere near 30% bandwidth utilization and hovers around 0.02~0.05 IPC... Yeah it's bad.)
1
1 1 1 1 1 1 1 1 1 1 1 1 1.SENS to compute gradients of the bias current choices w.r.t. the resulting output eye (locally for each channel that's already open), and for-subsequent-aggregated-summing the gradients of the instantiation parameters which are shared across all tested channels and therefore have to be basically just added up (iirc differentiation rules correctly) over those channels, to get the global shared desire of how the parameters should evolve to enable better eyes. 1
1
1
1 9
1 18 1 2 1
8 2 1
3 9 1 1 1 1
.s3p in the sequence given by the .res a sweep of the primary design-time peaking control tunable; essentially the header and footer are only present once, and then it's the touchstone lines/frequency-sweep from the "operating bias points" listed in the .res file, just concatenated together, in the order they are called out in the .res file.clk_buf_in_out_ratio
clk_buf_load_r
clk_buf_neg_ratio
clk_buf_tail_current
input_cm
with clk_buf_neg_tail_adjust being a minor tunable.
clk_buf_in_out_ratio says how much weaker the input stage is vs. the output stage
clk_buf_load_r is the pull-up/load resistance at the output stage
clk_buf_neg_ratio says how much weaker the negative feedback onto the output node[pair] of the input stage should be, relative to the strength of the output stage. Thus divide it by clk_buf_in_out_ratio to understand how strong the negative feedback is relative to the input.
clk_buf_tail_current adjusts about anti-proportionally with clk_buf_load_r and gives the tail current reference fed to a current mirror (with infinite decoupling capacitance) for driving the actual tail current sources for the 3 diff pairs here. The input and output pair share a bias voltage and only adjust their tail current through adjusting the size of the tail transistor.
input_cm is the common mode voltage of the input signal, very relevant for determining the bias conditions the input diff pair are subjected to. In hindsight I guess there should be little harm from just setting that very high as the tail current source ought to take up any necessary slack.... I think... but probably it's not nearly as clear-cut as that hindsight idea hoped.
clk_buf_neg_tail_adjust multiplies the tail current fed to the negative feedback diffpair's current mirror from what the naive clk_buf_neg_ratio * clk_buf_tail_current would otherwise give.
clk_buf_tail_current even if adjusted anti-proportionally with clk_buf_load_r is relevant because the capacitances (and in that case, also the output-side voltages) remain the same, even as the resistances change, which adjusts the RC time constants.
1
25G..... hope unlocks extra motivation levels...... 1 1
deltaHz/V slope has.
It might be quite ticklish to initial conditions especially if not sufficiently frequency detector and too much phase detector based, but it's not like one couldn't "just" use exisitng cycle counting based frequncy measurments for the VCO in SPICE while stepping through some control voltages over a few transient runs, to figure out a reasonable approximation for at least the typical corner and nominal voltage&temperature, from where quality higher order continuation solvers ought to be able to "pull in and lock the PLL", and once there is a consistent set of harmonic balance phasors for all the nodes, those very same quality continuation solvers should have an easy time dragging the parameters of concern from those values of the typical corner to those values of the target corner that the solver is supposed to find a solution for.
Because those are specifically about dealing with flaky behavior and breakage-levels of "there exist multiple solutions/bias points for this new corner, good luck not getting them confused as you transition from your exisitng solution to one for the new corner".....
(from the Xyce docs; Figure 8-8; attached Figure 8-9:)
It initializes Vtest to 0 and sweeps it between 0 and 2.0 with initial step size 0.01, max step size 0.1, and minimum step size of 1e-8; it relies on a secant predictor to round the corners of where multiple currents are solutions to an individual voltage.)
Test for turning points using arclength continuation
* polynomial coefficients:
.param A=3.0
.param B=-2.0
.param C=1.0
.param I=1.0
Vtest 1 0 5.0
Btest 1 0 V=A*(I(Vtest)-I)**3 + B*(I(Vtest)-I) + C
.DC Vtest 1 1 1
* natural parameter continuation options (via loca)
.options nonlin continuation=1
* stepper sets what order of continuation this is.
* stepper=0 or stepper=NAT is natural continuation
* stepper=1 or stepper=ARC is arclength continuation
*
* predictor must be set to secant to see turning points
* predictor=0 tangent
* predictor=1 secant
* predictor=2 random
* predictor=3 constant
.options loca stepper=1
+ predictor=1 stepcontrol=1
+ conparam=Vtest
+ initialvalue=0.0 minvalue=0.0 maxvalue=2.0
+ initialstepsize=0.01 minstepsize=1.0e-8 maxstepsize=0.1
+ aggressiveness=0.1
.print homotopy I(Vtest)
1 1 1 1
️ 
3
1 w
More seriously, have you been able to figure out what the issue was ?
More seriously, have you been able to figure out what the issue was ? 1
10000 ) BSIM6 version 6.1.1 or level=103/level=1031 PSP version 103.4 (it's probably hard to calibrate the self-heating aspect of level=77 and level=1031) with data from the muxed e-test, but more data won't hurt, especially on the subject of floating gate stuff....