or what is it for?

The simulated gm/gds versus gate bias (for various L) for an lv_nmos looks quite odd for short channels (see plot below). Does the measured data support this? I found only plots of gds versus drain bias in the documentation. The netlist to duplicate this plot is below.

** sch_path: /foss/designs/gds_n.sch
**.subckt gds_n
Xm1 d g GND b sg13_lv_nmos W={Wx} L={Lx} ng=1 m=1
Vgs g GND 0.6
Vds d GND 1.2
Vsb GND b 0
**** begin user architecture code
.lib /foss/pdks/ihp-sg13g2/libs.tech/ngspice/models/cornerMOSlv.lib mos_tt

.param temp=27
.param Wx=5u
.param Lx=0.13u
.dc Vgs 0 1.2 0.01
.save @n.xm1.nsg13_lv_nmos[gm]
.save @n.xm1.nsg13_lv_nmos[gds]

.control
*pre_osdi ./psp103_nqs.osdi

foreach L_val 0.13u 0.14u 0.15u 0.16u 0.17u 0.18u 0.19u 0.2u 0.3u 0.4u 0.5u 1u 2u 3u
alterparam Lx = $L_val
reset
run
let [email protected]_lv_nmos[gm]/@n.xm1.nsg13_lv_nmos[gds]
end

plot all.av

.endc

**** end user architecture code
**.ends
.GLOBAL GND
.end

In SG13G2_os_layout_rules.pdf the layout grid is specified as 5 nm, while in sg13g2.lyt it is set to 1 nm. Is this an intentional scale factor or is there some other reason for this difference?

The pin order of these diodes in spice netlists is alphabetical, and currently gives the pin order cathode, anode. This is incompatible with standard spice, where diodes are instantiated as anode, cathode.

This problem has trickled down into the LVS, which now expects the wrong cathode, anode order. The existing netlist for the IO cells uses the proper spice ordering and therefore does not pass LVS.

I strongly recommend going with the spice standard; anything else will be extremely confusing.

The attached ngspice script cg_glitch.txt shows Cgb, Cg_ds and Cg_dsb capacitances over Vg of a 400/0.5 lv_nmos transistor.
The strong glitch around -0.9V is in my opinion fatal and follows in time step problems for transient simulation.

The observed behaviour is for psp103 version 6.0 and actual version 8.2 va-models and can also be seen for the hv-nmos device.

Would be fine to see same curves from same va-code with other simulators.

Additional open question is the y-axis scale of the documented curves in report_nmos_lv page 401. Are this 400 pF? Because e-12 is shown.

1. I don't understand why you would define epsilon twice:

    self.epsilon = techparams['epsilon1']
    Cell = self.__class__.__name__
    typ = 'N'
    hv = False
    
    epsilon = techparams['epsilon1']
   

2. epsilon is defined as "epsilon1": 0.001, in json file. What is the purpose of this code:
   ng = math.floor(Numeric(ng)+epsilon)
   As far as I see, it has no effect.

After routing an example design the results from *.spef file list all the node capacitor as zeros and the resistor either 40-ohm or 20-ohm.

... to be able to fit a spice pnp-model to it. because it seems, that it will need long time until the real models are ready.

this would be very helpful.

i would like to know how wirebond-pads and ESD-protection should be done in iHPs and skywaters 130nm BiCMOS processes. is there some documentation? i didnt found anything in the PDKs

In sg13g2_dfrbp_2 clk-pin (Metal1, red) is masked by reset_B (Metal2, blue) :

Hi experts,

Sorry if this is the wrong place to comment, I didn't find any other portal for this issue.

I am currently doing my mmWave PA design and wanna using IHP PDK for ADS, however, I tried a lot to load the models in ADS and failed. every time loading the netlist/spectre file sg13g2_moslv_psp_parm.scs in libs.tech throws an error of syntax error. I am wondering if this is the problem of open PDK or from keysight ADS.

Hoping to receive your reply. I really appreciate any help you can provide.

Best,
Yuhan

in the file IHP-Open-PDK-dev/ihp-sg13g2/libs.tech/ngspice/models/sg13g2_hbt_mod.lib there is a model:

.subckt pnpMPA e b c
.param a=2p p=6u ac=13.33p pc=14.64u
+ dev_a=a*1e12 dev_p=p*1e6 sub_a=ac*1e12 sub_p=pc*1e6

QpnpMPA e b c pnpMPA_mod area=dev_a
...

but if i run the netlist-generation of Xschem for IHP-Open-PDK-dev/ihp-sg13g2/libs.tech/xschem/sg13g2_tests/dc_pnpMPA.sch it generates:

** sch_path: IHP-Open-PDK-dev/ihp-sg13g2/libs.tech/xschem/sg13g2_tests/dc_pnpMPA.sch
**.subckt dc_pnpMPA
XQ1 net3 net1 E1 pnpMPA
Ve net2 E1 0
.save i(ve)
Vb net1 GND 0
.save i(vb)
Vc net3 GND 0
.save i(vc)
I0 GND net2 1u
...

it seems to me that c and e are interchanged somewhere.

is it possible to do ngspice-simulations with SOA-checks? i didnt found anything about it in the documentation.

It looks like mimcaps don't get recognized when there is a poly resistor or transistor with the required heat layers underneath. I am am not sure I understand this long list of exclusions for a component high up in the stack. I think this is a bug (but it needs confirmation).

cap_exc = nsd_drw.join(heattrans_drw).join(trans_drw)
.join(emwind_drw).join(emwihv_drw).join(heatres_drw)
.join(salblock_drw).join(polyres_drw).join(extblock_drw)
.join(res_drw).join(activ_mask).join(recog_diode)
.join(recog_esd).join(ind_drw).join(ind_pin)
.join(substrate_drw)

I have a test case of an IO cell I am working on: hightemp_sim.zip
You can run the simulations with the ./sim.sh and that generates the included sim25c.out and sim70c.out files. As you can see the simulation works for 25℃ but not for 70℃. For 70℃ the reporter error is:

doAnalyses: TRAN:  Timestep too small; initial timepoint: trouble with darea-instance d.xtop.xnclamp.xdgate.d1

I try to reproduce the LF noise results from document Low_Frequency_Noise_SG13G2.pdf, page 3 with latest ngspice and IHP-Open-PDK.

My setup (see attachment) is as follows: Using an 8 emitter stripe (NX=8) as DUT, biasing the base over bias T with DC (0.7...0.9V) and AC voltage sources, DC Vce=1V on collector, grep the power spectral density of ic with a H controlled source and divided by Beta²

The result has a large difference to the shown diagram on p.3

vbic_noise_Vc_Vb.sp.txt

Is there a flaw in my method or did we have a problem with the model in ngspice? Can you describe your method in principle, please. Which simulator you have used for the documentation?

I tried to update ORFS's copy of the IHP pdk to resolve #92 . However sg13g2_stdcell_typ_1p20V_25C.lib is using wire_load_table which abc does not support and gives:

Error: Cannot find wire load model "1k".

abc does support wire_load which is what I see in the ORFS. @KrzysztofHerman did you change this when importing to ORFS?

In the "IHP Pycells", For Gate The PMOS has "GatPloy.lbl" while NMOS has "Gatpoly.drw" as shown:

Also, I've noticed a discrepancy in dimension input between NMOS and PMOS transistors within the tool. Specifically, while "1u" notation is accepted for PMOS, it's not permitted for NMOS. Instead, we're required to use scientific notation such as "1e-6".

In some situations (like in our IIC-OSIC-TOOLS image, see https://github.com/iic-jku/IIC-OSIC-TOOLS) the PDK sits in a read-only location, and even the user home directory is almost read-only.

How should one setup KLayout and respective environment variables properly for this to work? E.g., accessing the right .lyt and .lyp files, and especially finding and binding all the Python stuff? I am not sure that the current setup (if I look into the .lyt for example) supports such a usage model, and if it does, how to set up the user environment accordingly.

The OpenROAD flow scripts (ORFS) do not insert the sg13g2_decap_[4|8] cells, only sg13g2_fill_[1|2|4|8]. This should be changed in the default configuration.

Title should be self-explanatory. The derivation file for RPPD excludes n-well as a valid region for RPPD (which I don't think is correct).

I am not sure of this was brought up here already. The spice pin order between these two stdcell representations do not match up:

libs.tech/xschem/sg13g2_stdcells
libs.ref/sg13g2_stdcell/spice/sg13g2_stdcell.spice

The spice file pins are in alphabetical order, but the xschem pins are not.

The following sed applied to the xschem symbols fixes the problem (courtesy Mitch Bailey):
sed -i .bak
-e 's/@vgnd @vnb @vpb @VPWR/@VDD @VSS/'
-e 's/VGND=VGND VNB=VNB VPB=VPB VPWR=VPWR/VDD=VDD VSS=VSS/'
-e 's/VGND VNB VPB VPWR/VDD VSS/'
-e 's/@VDD @vss @@q @@Q_N/@@q @@Q_N @VDD @VSS/'
-e 's/(@@reset.*)@@q @@Q_N /@@q @@Q_N \1/' *.sym

⚠️ IMPORTANT
There is functional inconsistency between physical design/transistor-level schematic and Liberty/Verilog description of the a22oi_1 cell, if the cell is used in the design this will lead to a chip not functioning as expected. Other cells could be affected as well..
Thanks to ETH Zurich team that found this critical issue!

This is related to this reported issue in the ORFS: The-OpenROAD-Project/OpenROAD-flow-scripts#1981 (comment)

In short, we need the definition of an antenna diode cell in the LEF, so that OpenROAD can use it to repair antenna fails.

Trying to run the following ngspice simulation:

.title sg13g2_inv_1
.lib /content/IHP-Open-PDK/ihp-sg13g2/libs.tech/ngspice/models/SG13G2_hbt_woStatistics.hsp.lib
.include /content/IHP-Open-PDK/ihp-sg13g2/libs.ref/sg13g2_stdcell/spice/sg13g2_stdcell.spice

X1 GATE DRAIN VPWR 0 0 VGND sg13g2_inv_1

Vgnd  VGND  0     0
Vdd   VPWR  VGND  5.0
R     VPWR  DRAIN 50k
Vin   GATE  VGND  DC    0V
.op
.option post nomod
.end

.control
save all GATE DRAIN
dc Vin 0 5.0 0.01
display
wrdata output.txt GATE DRAIN
.endc

will result in the following error:

Error: unknown subckt: x1.xx1 vpwr gate 0 vpwr x1.sg13_lv_nmos x1.w=740.00n x1.l=130.00n x1.ng=1 x1.ad=0 x1.as=0 x1.pd=0 x1.ps=0 m=1
    Simulation interrupted due to error!

See the following notebook which reproduce the issue:
https://colab.research.google.com/gist/proppy/5582eeae8d2e2eccb48cd591b904185f/ihp-pdk-playground.ipynb

In a typical IC design, different VSS nets are used in different areas for blocks requiring isolation (e.g., digital blocks vs. analog blocks), leading to p-taps shorting these VSS nets via the (common) substrate node if no measures are taken.

A common method is to split the substrate into local VSS islands using a marking layer to circumvent these problems.

In SG13G2 this marking layer is called DigiSub. Please support this layer in LVS and PEX.

It seems "cni.dlo" file is missing in pycell directory. Any information on this?

1. The gate overlap capacitances seem to be very large. An op analysis for a 5/0.13 NMOS (sg13_lv_nmos) gives cgsol = 3.19575e-15 fF. This corresponds to 0.64 fF/um, about twice as large as in other 0.13 um CMOS processes. Are these realistic models?
2. A likely non-physical kink is seen when running a VGS DC sweep and plotting fT = gm/Cgg/2/pi for the NMOS device (sg13_lv_nmos).
   
   For reference, here is my Jupyter notebook that produces these data:
   https://github.com/bmurmann/Ngspice-on-Colab/blob/main/notebooks/IHP_SG13G2_VGS_sweep.ipynb

In situations where the VerilogA models are located in a central location (not in various simulation directories, but e.g. in .../ngspice/lib/ngspice) the pre_osdi directive leads to an error when starting ngspice.

As a consequence, this directive should not be part of the "standard" examples. Alternatively, it should be wrapped into a check whether this file exists in this local directory.

Hi!

It would be nice to have the metal layers, vias etc. annotated in the picture of the layer stack in the file
ihp-sg13g2/libs.doc/doc/SG13G2_os_process_spec.pdf

Thanks!
Michael

In the layout rules manual there is mention of a Recog.diode layer and this layer is also used in the sg13g2_pr.gds in for example the dpantenna cell.
No devices for diodes using this layer are present in the layout rules or the process specification manual. Neither could I find models for diodes.

DCO should only be enforced in CI if it is defined in README, contribution guide or other documentation what the actual signed-off-by means.

For statistical simulations, what are the correct values for "MC_OK"

• for across different runs
• for across the same wafer

Thanks

""Device recognition: Pad = (Passiv + Passiv:sbump + Passiv:pillar) + dfpad""

Shouldn't this be

""Device recognition: Pad = (Passiv OR Passiv:sbump OR Passiv:pillar) + dfpad""

?

I found a weird behavior when doing a LVS test with resistors. The first case (left in the image) pass LVS with any problem when the last resistors is at the same level (red line), but if I move the last resistor just a little bit to the south (right in the image) then the LVS fails. Does anyone know why is this happening?

Slack Message

The resistor models in resistors.lib currently lack parasitic capacitors, which are important for analog and RF. Therefore, two asks:

1. Please add a substrate node to the model subcircuits to account already now for parasitic caps added later.
2. Add parasitic caps.

Trying to port the IHP Open PDK to the OpenRoad-flow-scripts I got some issues with detailed routing. The exact bug is the following [ERROR DRT-0307] Net 000 of signal type SIGNAL cannot be connected to iterm 318/Y with signal type POWER Error: detail_route.tcl, 59 DRT-0307 The instance 318 is a sg13g2_o21ai_1 cell and its output is assigned to USE POWER; signal class in the LEF file.

Hello,
I made few check with the vbic's in ngspice. Most things are plausible, but invers operation seems a bit strange. That's said without knowledge of the npn13G2 structure/crossview.
Can you comment the attached picture made with Vce=-1V and Vbc=0.3 ... 1V.
Thank you for the Open-PDK activity.

The change in VTH when sweeping W seems to be excessive (especially going from 5um to 10um).
Please see the attached plots (the device used for this analysis is the SG13 LV nmos)

The xschem's file and the matlab's file I used to generate the analysis are provided at this link

I found the following warning in OpenROAD and it looks like the stdcell lib has a type included: https://github.com/IHP-GmbH/IHP-Open-PDK/blob/dceb7e6bd1a877182c3ba32c2e238be08368fa3f/ihp-sg13g2/libs.ref/sg13g2_stdcell/lib/sg13g2_stdcell_typ_1p50V_25C.lib#L27289

Warning: Found unsupported expression 'SCE*SCD+SCE'*D' in pin attribute of cell 'sg13g2_sdfbbp_1' - skipping.

I can send a fix but can someone confirm this is a typo?

Can you explain to me what does this piece of pycell code is doing? As far as I see, it is just redrawing the same box (rectangle) at the same location as many times as there are gate fingers:

    for i in range(int(ng)) :
        # draw the poly line
        xpoly_beg = xcont_end+gatpoly_cont_dist
        ypoly_beg = ydiff_beg-gatpoly_Activ_over
        xpoly_end = xpoly_beg+l
        ypoly_end = ydiff_end+gatpoly_Activ_over
        dbCreateRect(self, poly_layer, Box(xpoly_beg, ypoly_beg+diffoffset, xpoly_end, ypoly_end+diffoffset))

I am trying to port this pycell code to Revolution EDA, and I am a bit perplexed.

I'm reviewing page 20 of "SG13G2 Process Specification Rev. 1.1" and noticed that the tables for "npn13g2" and "npn13g2l" are very similar. Could anyone clarify the purpose of having "npn13g2l" listed separately? It seems like "npn13g2" might be able to replace it. Any insights on this would be appreciated.

Thanks!

... the models also use lower-case, and even if ngspice isnt case-sensitve, TCL is, and also the symbol-text of Xschem. and thus mixing cases in Xschem should be avoided if possible.

the m in the MOSFETs isnt working yet (should be mentioned), and the non-transistor parameters arent indicated generally. the resistor models as example have an b parameter, thats not described. could it be number of bends?

sg13g2_stdcell.cdl has the wrong supply pin order for inv_4, inv_8 and inv_16. The order should be VDD, VSS.

• Library Name: sg13g2_stdcell
• Cell Name: sg13g2_inv_2
• View Name: schematic

.SUBCKT sg13g2_inv_2 A VDD VSS Y
*.PININFO A:I Y:O VDD:B VSS:B
MX1 Y A VSS VSS sg13_lv_nmos m=2 w=740.00n l=130.00n ng=1
MX0 Y A VDD VDD sg13_lv_pmos m=2 w=1.12u l=130.00n ng=1
.ENDS

• Library Name: sg13g2_stdcell
• Cell Name: sg13g2_inv_4
• View Name: schematic

.SUBCKT sg13g2_inv_4 A VSS VDD Y
*.PININFO A:I Y:O VDD:B VSS:B
MP0 Y A VDD VDD sg13_lv_pmos m=4 w=1.12u l=130.00n ng=1
MN0 Y A VSS VSS sg13_lv_nmos m=4 w=740.00n l=130.00n ng=1
.ENDS

• Library Name: sg13g2_stdcell
• Cell Name: sg13g2_inv_8
• View Name: schematic

.SUBCKT sg13g2_inv_8 A VSS VDD Y
*.PININFO A:I Y:O VDD:B VSS:B
MX1 Y A VSS VSS sg13_lv_nmos m=8 w=740.00n l=130.00n ng=1
MX0 Y A VDD VDD sg13_lv_pmos m=8 w=1.12u l=130.00n ng=1
.ENDS

I am having some trouble getting the options from the GUI to be correctly reflected in the LVS run. I see that the yml file gets updated when I click an option, but when I click "load pdk options" the sync between the menu buttons and the yml is lost until all options are manually toggled into alignment again.

Furthermore, when I start KLayout, the yml file has schematic_simplify: true, but the GUI menu has Netlist simplify enabled (and not netlist simplify).

Why is there a "tile" run option for LVS?

Also, just a suggestion for the documentation of the options, I found this to be a useful explanation from the KLayout manual:
Netlist simplify is a wrapper for "make_top_level_pins", "purge", "combine_devices" and "purge_nets" in this recommended order.

I work on the open source pdks at Google, and just want to say congratulations from Google to IHP.

the sg13_lv_nmos model should accept an m parameter in spice-simulation. at least the Xschem-symbol has this parameter and any MOS-device should, because its a spice-standard. but i ngspice-simulations this multiplier is ignored. actual i would expect something like multiplying the parameter W.
in the file IHP-Open-PDK-main/ihp-sg13g2/libs.tech/ngspice/models/sg13g2_moslv_mod.lib there is a parameter mfact=1. may be thats the m?
but XM1 net3 net1 GND VSS sg13_lv_nmos W=2.0u L=0.45u ng=1 mfact=100 also dosnt work...

... or i simply didnt found it :)

but in the section 4 Attachment A: Measurement Conditions there are descriptions of:
Transistor Matching Coefficient k
MOS Transistor Matching Coefficient k
and so i would expect this parameters in 2.1 NMOS and so on like in 2.7 Rsil

there are GDS but bo models