The names of the top level spice files are currently;

./models
./models/ngspice
./models/ngspice/design.ngspice
./models/ngspice/sm141064.ngspice
./models/ngspice/smbb000149.ngspice
./models/xyce
./models/xyce/design.xyce
./models/xyce/sm141064.xyce
./models/xyce/smbb000149.xyce

The names design / sm141064 / smbb000149 don't really have useful meanings. I believe that @mkkassem has better names that should be used instead.

Looking at the current pcells, it seems that drawing the LVPWELL for nfet:

Are those two always tied together? looking at the design manual there seems to be a valid use case for using LVPWELL outside of DNWELL:
https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_07_04.html

If this layer is used without DNWELL (outside DNWELL), the body of all those transistors will by default be connected to P-substrate potential.

@atorkmabrains @RTimothyEdwards

Expected Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/rules/klayout/drc/testing README should describe each of the tests cases and the rules they cover.

Actual Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/rules/klayout/drc/testing assume developers/contributors are familiar with the naming scheme of the directories and files to be able to identify which rules are covered.

Expected Behavior

Tests should be using python testing best practices.

One popular framework is pytest: https://docs.pytest.org/en/7.2.x/ as it comes with:

• automated test discovery
• and a rich ecosystem of plugins: https://docs.pytest.org/en/7.2.x/reference/plugin_list.html#plugin-list (including things like https://pypi.org/project/pytest-xdist/ that allow multiple tests to be run concurrently).

Actual Behavior

Tests uses monolytics python scripts with manual exit() invocation, see https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/drc/testing/run_regression.py#L243

There is a typo in the script https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/lvs/run_lvs.py, in line 96. The check should be:
if args["--net"]: ... , not if args["--design"]

once the existence of GDS file was already performed, and it is now necessary to check for the existence of the netlist to compare against.

Expected Behavior

ppolyf_u_2k_6p0 has a sheet resistance of 2k/square.

Actual Behavior

The resistance is much lower than this (68 ohm).
This is also true for the other ppolyf resistors. Also the modelling of the parasitic capacitance
is not compatible with ngspice.

Steps to Reproduce the Problem

* Netlist

Vin top GND 1
XR1 GND top GND ppolyf_u_2k_6p0 r_length=1e-6 r_width=1e-6 m=1

.control
op
let ires=-1*vin#branch
let res=1/ires
print res
.endc

.inc design.ngspice
.lib sm141064.ngspice res_typical

.GLOBAL GND
.end

It is general best practice to have lots of small units which only test one thing at a time. At the moment, the testing in #11 are more like integration tests.

The testing for the DRC rules should look like this -- for each DRC rule, there should be a directory which contains;

• A human readable description of the rule
• A set of GDS files which demonstrate different violations which should be caught by the DRC rule. These should also be rendered as examples into the human readable description of the rule.
• A set of GDS files which should not have any violations in them.
• These GDS test cases should be run with only the individual DRC rule being enabled.

There should still be DRC integration tests, but they should only be run after all the individual unit tests are successful.

Expected Behavior

multiplier m should represent the number of devices connected in parallel, hence changing the effective total width of transistors

Actual Behavior

but changing multiplier m has completely no effect on the circuit behavior

Current Solution

To simulate a device with large width (ex: a power transistor with wdith > 10mm), we currently have two solutions:

1. manually connect more than 100 MOS in the schematic to achieve the same effect as using the multiplier, since the maximum width of a single MOS is 100um
2. use the provided ideal device nmos4 .sym from Xschem standard library, but still unsure whether the simulation result would be largely different from using nfet_03v3 from the GF180 pdk
   

FYR if anyone is facing the same problem

I need a straightforward mapping of layer names to GDS types/subtypes. I believe this information is captured by various tool configuration files, like gf180mcu.lyp for klayout, but it would be helpful to have the source in order to produce another tool-specific configuration file instead.

For sky130 such a file was available in non-public versions, so I'm curious if there's a similar situation for this PDK.

I think I could parse the magic gf180mcuA-GDS.tech for this too, but it also isn't straightforward.

@mohanad0mohamed - Looks like merging this pull request broke the CI - see https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/actions - can you please investigate.

Originally posted by @mithro in #17 (comment)

Expected Behavior

See https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/actions

[LVS | switch](https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/actions/runs/4115332888/jobs/7103904216#step:4:11)
The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Pull requests #12 and #11 added a whole bunch of GitHub Actions for checking various things.

The workflow files currently have large amount of duplicate in them. Instead we should be using "matrix" for this stuff. See the documentation at #11

Expected Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/drc/testing/run_regression.py and https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/lvs/testing/run_regression.py should populate an error status that represents the aggregated failure and success state of the test cases.

Actual Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/drc/testing/run_regression.py and https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/lvs/testing/run_regression.py never seems to exit with a status != 0.

Expected Behavior

W=0.22um, L=0.28um (the minimal PCell Size) shouldn't fail DRC

Actual Behavior

Steps to Reproduce the Problem

• Version: 11770e5

1. Instantiate a PCell with the default parameters
2. Run Klayout DRC

Possible Cause

Rule PL.2_3.3V in gf180mcu.drc doesn't seem to check width and length separately (i.e. it assumes device width is always larger than length)

References

gf180mcu PDK Physical Verification

@msaligane

Expected Behavior

You shouldn't use os.system in Python scripts.

Examples;

Should use python internal functionality;

Should use subprocess module;

Actual Behavior

You should use inbuilt Python functions or the subprocess module like check_call or check_output.

Instead of using rm you should use something like Path.unlink or os.unlink or shutil.rmtree.

A lot of the Python scripts are not complying with standard python formatting rules. We should enable tools which check the files are complaint.

Some tools which we should look at are;

• pep8
• black
• pylint
• Something which checks for trailing whitespace.
• Something which checks for license headers.

Setting these up can be showing by looking at the F4PGA repositories.

There is a spreadsheet @ GF180MCU (GlobalFoundries 180nm PDK) -- Primitive Model Naming which is tracking what the new naming scheme should be.

Expected Behavior

When starting xschem the proper schematic view should appear.

Actual Behavior

An error message is displayed about a file not found, see iic-jku/IIC-OSIC-TOOLS#9

Steps to Reproduce the Problem

See iic-jku/IIC-OSIC-TOOLS#9

Proposed Fix

Is also described here: iic-jku/IIC-OSIC-TOOLS#9

We have seen that klayout DRC/LVS runs slow with Caravel layout. There is a need to optimize the DRC code to make it run faster and consume less memory.

The files that are used to test model cards for ngspice/Xyce are missing. See:
ngspice_testing_files.txt
Xyce_testing_files.txt

Expected Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/cells/klayout/pymacros README should document how to generate gds using klayout and how to regenerate the tests in https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/cells/klayout/pymacros/testing.

Actual Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/cells/klayout/pymacros assume developers/contributors are familiar with the process to generate pcells using klayout and update testcases gds.

The KLayout LVS tests found at https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/rules/klayout/lvs should be run using GitHub Actions.

By default xschem extract netlist with the .spice extension and include modeling equation as part of the parameters (which klayout can't parse).

It would be nice if the lvs script was trying multiple extension and simplifying the netlist prior to parsing.

These files are:

• 0.0.DM000013_13_1P6M_11kA_MIMA_Gold_Bump.gds (Modified for regression)
• 0.0.DM000013_13_1P6M_30kA_MIMB_BALL.gds
• 0.0.DM000013_13_1P6M_6kA_MIMA_SOLDER_BUMP.gds
• 0.0.DM000013_13_1P6M_9kA_MIMB_WEDGE.gds

As soon as these files are added, GitHub Actions for DRC testing will pass successfully.

SPICE Model refactoring

Is there any intent to refactor the PDK? I suggest to make this a priority before tinkering more with the PDK itself because I observed the following issues.

• The delta between the ngspice and xyce model is very big, even though it turns out there is only small differences.
• There is extensive whitespace in the xyce model for no appearant reason.
• There is inconsistency between the two models, where it seems like it should not.

I tried to refactor both xyce and ngspice models in the fork that created from this repository (link)

We have xschem related files in https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/cells/xschem -- we should be checking that these work with CI in some way.

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/cells currently only seem to contains klayout and xschem pcells.

In comparison the sky130 repo has a lot more:
https://github.com/google/skywater-pdk-libs-sky130_fd_pr/tree/main/cells

🍉 find skywater-pdk-libs-sky130_fd_pr/cells/ -type f | xargs -n1 basename | cut -f 2- -d '.'  | sort | uniq -c
     23 bins.csv
    270 cdl
    261 corner.spice
    261 data
    289 gds
    346 json
    289 magic.lef
     99 model.spice
    270 netlist.tsv
      1 out
     88 pm3.spice
    637 spice
    802 svg

should we have the equivalent for gf180mcu?

Layer Mapping of 5th metal for IO and other devices to Top metal or Metal 5 is not clear for DC implementation and other items.

Steps to Reproduce the Problem

Multiple sources of documentation:
Based on GF tapeout configuration document (attached), the BEOL mask layer numbers are:
80 --> Metal1
85 --> Via1
88 --> Metal2
91 --> Via2
93 --> Metal3
94 --> Via3
96 --> Metal4
97 --> Via4
98 --> Metaltop

The mapping was done using the following table 4.3 from the DRM:

On the other hand, the DRM states the following:

We are not sure of which GDS number to use for Metal5 either:
53 (MetalTop Mask Layer)
81 (M5 Mask Layer)
Could you please clarify?

Specifications

Expected Behavior

ngspice needs to run with no errors

Actual Behavior

error:

##NETLIST
** sch_path: /usr/local/google/home/nigelcoburn/MixedSignal/Designs/TopLevel_oscillator.sch
**.subckt TopLevel_oscillator
X1 VDD GND Vout Vin Buffer
Vdd VDD GND 1.8
.save i(vdd)
Vin Vin GND pulse(0 1.8 1ns 1ns 1ns 4ns 10ns)
.save i(vin)
**** begin user architecture code

blabla

.tran 0.01n 1u
.saveall

name=TT_MODELS1 only_toplevel=false
.include /usr/local/google/home/nigelcoburn/MixedSignal/silicon-env/share/pdk/gf180mcuC/libs.tech/ngspice/design.ngspice
.lib /usr/local/google/home/nigelcoburn/MixedSignal/silicon-env/share/pdk/gf180mcuC/libs.tech/ngspice/sm141064.ngspice typical

**** end user architecture code
**.ends

• expanding symbol: Designs/Buffer.sym # of pins=4
  ** sym_path: /usr/local/google/home/nigelcoburn/MixedSignal/Designs/Buffer.sym
  ** sch_path: /usr/local/google/home/nigelcoburn/MixedSignal/Designs/Buffer.sch
  .subckt Buffer VP VN Y A
  *.iopin VP
  *.iopin VN
  *.ipin A
  *.opin Y
  X1 VP VN net1 A Inverter
  X2 VP VN Y net1 Inverter
  .ends

• expanding symbol: Designs/Inverter.sym # of pins=4
  ** sym_path: /usr/local/google/home/nigelcoburn/MixedSignal/Designs/Inverter.sym
  ** sch_path: /usr/local/google/home/nigelcoburn/MixedSignal/Designs/Inverter.sch
  .subckt Inverter VP VN Y A
  *.ipin A
  *.iopin VP
  *.iopin VN
  *.opin Y
  XM3 Y A VP VP pfet_03v3 L=0.28u W=0.22u nf=1 ad='int((nf+1)/2) * W/nf * 0.18u' as='int((nf+2)/2) * W/nf * 0.18u'

• pd='2int((nf+1)/2) * (W/nf + 0.18u)' ps='2int((nf+2)/2) * (W/nf + 0.18u)' nrd='0.18u / W' nrs='0.18u / W'
• sa=0 sb=0 sd=0 m=1
  XM4 Y A VN VN nfet_03v3 L=0.28u W=0.22u nf=1 ad='int((nf+1)/2) * W/nf * 0.18u' as='int((nf+2)/2) * W/nf * 0.18u'
• pd='2int((nf+1)/2) * (W/nf + 0.18u)' ps='2int((nf+2)/2) * (W/nf + 0.18u)' nrd='0.18u / W' nrs='0.18u / W'
• sa=0 sb=0 sd=0 m=1
  .ends

.GLOBAL GND
.GLOBAL VDD
.end

Steps to Reproduce the Problem

Specifications

• Version:
• Platform:

Google repo has been outdated from the latest updates. I would recommend taking all the updates from Efabless and merging it to Google.

Expected Behavior

Scripts shouldn't use time.sleep to wait for things.

Examples @

Actual Behavior

Instead the script should check for what is being waited on. Examples could be;

• Checking if the output file exists.
• Check if a process has completed.
• Something else?

Expected Behavior

The simulation of transient including the noise

Actual Behavior

I am able to run the noise simulation to see the noise spectral density in Ngspice. But I can't run the transient noise simulation. According to the Ngspice manual, the transient noise simulation should be done by running the transient simulation with independent noise voltage/current sources manually added in the circuits. Below is the screenshot from the manual

Are those noise source parameters like NA, NT, NALPHA, etc. provided in the GF180mcu PDK? Or where can I find those parameters?

Expected Behavior

IP is drawn with 5V device and has 5V .libs and device modesl were expected to hav 5V devices.

Actual Behavior

Actual device models present are:

• Models included in this release :

•  ModelName          Description
  

•  ---------          -----------
  

•  nmos_3p3           Subcircuit model for 3.3V NMOS
  

•  pmos_3p3           Subcircuit model for 3.3V PMOS
  

•  nmos_6p0           Subcircuit model for 6.0V NMOS
  

•  pmos_6p0           Subcircuit model for 6.0V PMOS
  

•  nmos_3p3_sab       Subcircuit model for 3.3V NMOS with Drain side SAB
  

•  pmos_3p3_sab       Subcircuit model for 3.3V PMOS with Drain side SAB
  

•  nmos_6p0_sab       Subcircuit model for 6.0V NMOS with Drain side SAB
  

•  pmos_6p0_sab       Subcircuit model for 6.0V PMOS with Drain side SAB
  

•  nmos_6p0_nat       Subcircuit model for 6.0V native NMOS
  

Steps to Reproduce the Problem

Open file:
https://raw.githubusercontent.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/main/models/ngspice/sm141064.ngspice
Read header.

Need to have a custom ubuntu image to avoid the need to re-install klayout version 0.27.8 every time.

@umarcor Is is possible to help us and create a custom image that we could use it for our CI instead of installing klayout every time?

Actually, you could install all the tools needed using the script here:
https://github.com/mabrains/OpenAnalogDesign/blob/main/docker_build/Makefile

Also, you will need to get the file below next to that Makefile for the installation to complete:
https://github.com/mabrains/OpenAnalogDesign/blob/main/docker_build/cmake_init.sh

You will need to change klayout version in that file to 0.27.8 instead of 0.27.10.

cc @proppy @mithro

Expected Behavior

Typical simulations using the spice header
.include "../../../gf180mcuC/libs.tech/ngspice/design.ngspice"
.lib "../../../gf180mcuC/libs.tech/ngspice/sm141064.ngspice" typical

should, as default, result in the same results each time the simulation is run.

Actual Behavior

It uses mismatch parameters, so the simulation has random results (such as offset)

Steps to Reproduce the Problem

1. Include the additional .param commands so the mismatch parameter flag is overwritten.

.param

• sw_stat_global = 0
• sw_stat_mismatch = 0

2. Change the local design.ngspice file manually.

Specifications

• Version:
• Platform: Linux

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/actions/runs/3904358547/jobs/6670037402

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
Successfully setup CPython (3.9.16)
/opt/hostedtoolcache/Python/3.9.16/x64/bin/pip cache dir
/home/runner/.cache/pip
Warning: The `save-state` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
Warning: The `save-state` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
pip cache is not found
Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Is this repo the right place for the DRC and LVS rules?

I find it hard to discover and feels more general than closely tied to the "primitive cells".

/cc @mithro @QuantamHD

Expected Behavior

The repository has DRC rules for both KLayout and Magic. This allows us to verify them against each other and less likely to miss things.

This should also run on CI -- see some previous work for SKY130 @ https://github.com/google/skywater-pdk-actions/tree/main/run-drc-for-cell-gds-using-magic

Actual Behavior

Currently only KLayout is supported.

The pull request at #20 added a whole bunch of data files in xlsx format. This format is hard to work with using only open source tooling.

We should convert the files to;

• .ods if they require formatting and other information to be preserved.
• .csv if they are just raw data points or similar.

Expected Behavior

In the ngspice device list under/share/pdk/ngspice/libs.tech/sm141064.ngspice we need to see seperate devices for nfets with and without DNWELL namely nfet03v3_dw and nfet_03v3 as shown in the device listing from GF. adding DNWELL needs to change the model of the nfet and point to a different model param in sm14064.ngspice

Actual Behavior

Steps to Reproduce the Problem

However, sm14064.ngspice does not seem to have seperate models for nfet_03v3_dw as expected. I only see nfet_03v3 in my pdk files

There are 2 issues here:

1. the names for the devices dont match with GF -so it is making it difficult to compare across platforms and tools. For instance magic would have issues reading these names- RTimothyEdwards/magic#239
2. Some devices and its models are missing in this PDK - specifically the DNWELL nfet device. As a result the extraction of a DNWELL device seems to be mapping to a typical nfet which yields incorrect results

Specifications

• Version:
• Platform: proppy/conda

Expected Behavior

Creating a NMOS/PMOS pcell using the provided klayout Pcell generator I expect to get a symmetrical device.

Actual Behavior

The device is non symetrical on Metal1 layer with a 1um offset.

Steps to Reproduce the Problem

Insert a NMOS/PMOS device. Choose which type 3.3/5/6 any one of them has the issue. Choose the desired width and length. So far all tested width/length combinations have the issue.

It seems that https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/24e721bd13601c1ff9983beec095e72dc333ab97/cells/xschem/tests/0_top.sch currently expect test symbols to be in a directory named gf180mcu_tests.

That directory doesn't exist in https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/24e721bd13601c1ff9983beec095e72dc333ab97/cells/xschem/tests.

There are a bunch of SRAM files used as tests for the LVS and DRC checks found in #11 / #12 and under https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/rules/klayout/drc/testing/sc_testcases

I'm wondering if they should be moved to a directory called something like "ip_testcases" instead?

Expected Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/lvs/gf180mcu.lvs doesn't seem to be able to parse X subcircuit in the following netlist:

.subckt TOP VP VN Y A
X1 Y A VP VP pfet_03v3 L=0.28u W=0.22u nf=1 
X2 Y A VN VN nfet_03v3 L=0.28u W=0.22u nf=1 
.ends

Actual Behavior

klayout shows an empty circuit:

Implementation suggestion / workaround

https://klayout.de/doc-qt4/manual/lvs_io.html#h2-146 mentions that:

Only a subset of elements is implemented by default. These are "M" (gives "MOS4" device classes), "Q" (gives BJT3 or BJT4 device classes), "R" (gives Resistor device classes), "C" (gives Capacitor device classes) and "D" (gives diode device classes).

and provide a NetlistSpiceReaderDelegate to implement subcircuit parsing:

# Provides a SPICE netlist reader delegate which turns
# some subcircuit models (for subcircuits NMOS and PMOS)
# into devices

class SubcircuitModelsReader < RBA::NetlistSpiceReaderDelegate

  # implements the delegate interface:
  # says we want to catch these subcircuits as devices
  def wants_subcircuit(name)
    name == "NMOS" || name == "PMOS"
  end

  # implements the delegate interface: 
  # take and translate the element
  def element(circuit, el, name, model, value, nets, params)

    if el != "X"
      # all other elements are left to the standard implementation
      return super
    end

    if nets.size != 4
      error("Subcircuit #{model} needs four nodes")
    end

    # provide a device class
    cls = circuit.netlist.device_class_by_name(model)
    if ! cls
      cls = RBA::DeviceClassMOS4Transistor::new
      cls.name = model
      circuit.netlist.add(cls)
    end

    # create a device
    device = circuit.create_device(cls, name)

    # and configure the device
    [ "S", "G", "D", "B" ].each_with_index do |t,index|
      device.connect_terminal(t, nets[index])
    end

    # parameters in the model are given in micrometer units, so 
    # we need to translate the parameter values from SI to um values:
    device.set_parameter("W", (params["W"] || 0.0) * 1e6)
    device.set_parameter("L", (params["L"] || 0.0) * 1e6)

    return true

  end

end

We should consider integrate it with the existing NetlistSpiceReaderDelegate https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/lvs/gf180mcu.lvs#L151-L248

Diff attached:

diff --git a/cells/xschem/symbols/vnpn_10x10.sym b/cells/xschem/symbols/vnpn_10x10.sym
index e679a98..54ceaec 100644
--- a/cells/xschem/symbols/vnpn_10x10.sym
+++ b/cells/xschem/symbols/vnpn_10x10.sym
@@ -33,7 +33,7 @@ L 4 0 -10 20 -30 {}
 B 5 17.5 -32.5 22.5 -27.5 {name=C dir=inout pinnumber=3}
 B 5 -22.5 -2.5 -17.5 2.5 {name=B dir=in pinnumber=1}
 B 5 17.5 27.5 22.5 32.5 {name=E dir=inout pinnumber=2}
-B 5 17.5 -2.5 22.5 2.5 {name=B dir=in pinnumber=1}
+B 5 17.5 -2.5 22.5 2.5 {name=S dir=in pinnumber=4}
 P 4 4 20 30 13.75 13.75 3.75 23.75 20 30 {fill=true}
 T {m=@m} 22.5 11.25 0 0 0.2 0.2 {layer=13}
 T {@model} 22.5 -15 0 0 0.2 0.2 {}

Expected Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/models/ngspice/testing and https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/models/xyce/testing READMEs should document how to interpret simulation result.

Actual Behavior

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/models/ngspice/testing and https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/models/xyce/testing READMEs assume developers/contributors are familiar with the simulation output to be able to interpret if there is failure or regression.

Currently Klayout LVS script extracts pmos_5p0 and nmos_5p0 models for 5V transistors (see here for example). This is inconsistent with SPICE deck which uses *mos_6p0 for both 5V and 6V transistors. Probably LVS script should be changed a bit to extract 6p0 models always.

If this change is OK (no 5p0 models planed in the future), I'll create a pull request.

The KLayout DRC rule tests found at https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/rules/klayout/drc should be run using GitHub Actions.