Hello. The precheck on the platform has been updated this morning to support analog projects based on Caravan.

@User @User: I can't remember which of you two brought this up, but you are right: The MiM capacitor plate value is 2fF/um^2, not 1fF/um^2 as I said, and as I have plugged into magic's device generator script. Of course, ultimately the simulation is done by passing width and length, not by value, so the value shown in magic is for reference only. Nevertheless it should not be off by a factor of 2! I would probably have noticed the discrepancy when designing the POR circuit, except that I was targeting a value for the time to charge, and just sized the caps to adjust to the desired simulated time rather than computing the value. I will fix the error in the device generator now.

Thanks!

@User Just wondering if you've been able to find out about the substrate type from SkyWater (non-epi versus epi)? Thanks!

@User I just pulled in an update for open_pdks. Are there scripts I have to run to truly update my version of open_pdks?

@User: You would want to re-run installation starting at

configure

and

make

/`[sudo] make install`. Depending on what you're installing, you can get away with less than a full install; for example, to update the magic techfile,

cd sky130 ; make tools-a ; [sudo] make install

will suffice and takes only a few seconds to run.

@User Hi Tim, I have been using the commercial tool to do the synthesis and PnR. The generated GDS file is then extracted in magic. However, there are missing vias if I open the GDS in magic. Have you encounter this problem before? I was able to see the via in DEF file if I load the rtk-tech and stdcells.lef. Pictures are attached below. Thanks!

Screenshot from 2021-05-17 14-49-52.png,Screenshot from 2021-05-17 14-53-40.png,Screenshot from 2021-05-17 15-03-36.png

In this case, the via from metal2(pink in magic) to metal1(purple in magic) is missing in the magic read gds. (Magic revision 164 and sky130A version 1.0.160)

Netgen question here. Is there a way I can pass in the

ignore shorted

command before using the scripted

lvs

procedure?

My LVS fails due to dummies that are shorted together (all tied to ground). I think netgen combined these shorted dummies into 1 overall resistors and that was causing me issues with LVS.

My test for this was to remove the dummies from the extracted schematic and proper schematic - this fixes the LVS issues.

Resolved. Added the

ignore shorted

command to the overall setup script I was using.

@User: This is often a problem with tools that put contact cuts into their own cell, which is incompatible with the way magic represents contacts. Try running the command "gds flatten true" before "gds read ...". That automatically flattens trivially small cells like contacts while leaving everything else as-is. Ultimately, if you have validated the layout on commercial tools, what you want to do is use "gds readonly true" before "gds read", which tells magic to record the extents of data of each cell in the GDS file, so it can use the cell without altering the GDS mask data.

I'm currently running into some issues with netgen matching a MiM cap component. Netgen correctly detects the number of devices and nets for both my layout and schematic (and gives an LVS clean for netlist and circuit matching), but it detects property errors with the MiM caps, namely with matching length and width. I've manually gone through both the layout netlist and my schematic netlist and have verified that both have the correct number of capacitors of each length/width and that these are connected to the correct respective nets, but for some reason, netgen fails to match the two. In fact, it lists the two caps it can't match properties for (lines 83-88 in comp.out), but just by swapping the two, it should be able to. I'll post both SPICE files and the comp.out file in the comments here. Any input would be appreciated, thanks!

Anyone know if

ngspice

has an option to ignore devices when their width/length/area parameters are zero? Or, should I manually filter the devices (with something like

sed

)

I'd like to run a post-layout simulation on a design including PNPs. The current netlist extraction produces a PNP subcircuit entry ending with 

sky130_fd_pr__pnp_05v5 area=4.79548e+14p

. The area of the parallel devices is absorbed into this single subcircuit. Multiplicity is not extracted. The

sky130_fd_pr__pnp_05v5

device is itself a subcircuit which wraps around

sky130_fd_pr__pnp_05v5_W3p40L3p40

(thanks @User for making the wrapper, since the actual

sky130_fd_pr__pnp_05v5

doesn't seem to exist in the pdk). I don't think that this area parameter does anything to the

sky130_fd_pr__pnp_05v5_W3p40L3p40

SPICE model. Please tell me if I'm wrong. Since the real

sky130_fd_pr__pnp_05v5

doesn't seem to exist I can't tell if area is used as a parameter (additionally, the pdk only provides 2 fixed area devices, so I'm not sure how extracting area instead of multiplicity is useful). I'm thinking I have to convert from area to device multiplicity in order for my extracted design to properly simulate, i.e. use the existing PNP SPICE models. Has anyone run into this? Or have any suggestions on what to do? Another detail I should add is that I've flattened my layout. If I extract from a hierarchical layout then each PNP is extracted w/ endings like:

sky130_fd_pr__pnp_05v5_W3p40L3p40 m=1

tldr; when using the PNPs as of now should I avoid flattening the design?

Hello all, I am designing Miller OTA but there is a problem in the design always the transistor M5 off although in my calculation I ensure it is in sat could anyone help me what is the problem in these design steps?

Is it correct to assume that the drain/source area and perimeter of a two (or more) devices connected, as shown in the attached figure, are associated to only one of those devices? Below are some examples of the extracted devices from the figure. Extracted Spice without Flattening:

X0 a_63_n45# a_15_67# a_n33_n45# w_n263_n255# sky130_fd_pr__nfet_01v8 ad=1.395e+11p pd=1.52e+06u as=1.485e+11p ps=1.56e+06u w=450000u l=150000u
X1 a_n33_n45# a_n81_n133# a_n125_n45# w_n263_n255# sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=1.395e+11p ps=1.52e+06u w=450000u l=150000u

Extracted Spice with Flattening:

X0 vss B out vss sky130_fd_pr__nfet_01v8 ad=2.79e+11p pd=3.04e+06u as=1.485e+11p ps=1.56e+06u w=450000u l=150000u
X1 out A vss vss sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=450000u l=150000u

Hello everyone! Could you help me to find more information about SONOS cell (i.e. how to use or to model it for SKY130)? I know there was some information earlier about it, but I cannot access it due to searchable messages restriction in Slack.

The only real information I have on the SONOS is from the design rules. There is a little information in the section of the documentation about devices, but nothing like instructions on how to set up a circuit for non-volatile memory read/write/program/erase. I have access to a complete but proprietary IP of an entire NVM block with programming and everything, but I only have a layout for it, which I cannot publish, and how it works will have to be completely reverse-engineered.

@User: At least one SONOS design taped out on the first shuttle run, so we'll be able to get some device measurements out of that.

Hi everyone, in the spice simulation for the design I'm working on, I found the design instanciates this cell "sky130_fd_pr__res_generic_po" which I found it commented in the model file: https://github.com/google/skywater-pdk-libs-sky130_fd_pr/blob/f62031a1be9aefe902d6d54cddd6f59b57627436/models/sky130_fd_pr__model__r%2Bc.model.spice#L134 , and this gives me error in the simulation. So, if someone knows how to solve this and what I can do.

I am seeing some interesting behavior with ngspice (I think) where it is really reducing the time-stepping for some of my transistions but not others. I have a deadtime circuit that generates ~2ns of deadtime and it seems that ngspice is completely skipping that on some transitions. Anyone else seen similar behavior?

Screenshot from 2021-05-20 12-41-38.png,Screenshot from 2021-05-20 12-40-21.png

@User: Where are you getting your current density limit numbers from? I have not found any electromigration rules for this process. You're using some reference with standard values/constants/equations for aluminum interconnect?

How do you go about printing the dc parameters (gm, gds, etc) of transistors in ngspice?

Has anyone been able to overlap the mim capacitors? I am getting weird drc errors. Is it possible in theory, but not with the devices made through the device generator?

I made a test structure in magic with just the cap1, cap2, cap contacts, and M3, M4, M5. Still getting a MiM2 cap spacing to via violation.