@User i am setting up an xschemrc in xschem_sky130 that uses the

PDK_ROOT

variable if existing (or do some reasonable assumption if it does not). Assuming the

PDK_ROOT

points one directory above

sky130A

or

sky130B

process variants, should I build by default the paths to

sky130A

? users will need to change the

xschemrc

file if they want to use

sky130B

, if this is correct i will put comments in the

xschemrc

so they will know what to change for that (the reram process variant, correct?).

Within open_pdks, I've been using the tactic of applying keyword replacement with a preprocessor script, so I'll put

TECHNAME

in the source file, and give a switch

-DTECHNAME=sky130A

to the preprocessor (

common/preproc.py

in open_pdks, because all the normal preprocessors like m4 and cpp have issues). For repositories outside open_pdks, I can just create the sky130B version by search-and-replace in the files, along with any other adjustments that need to be made between sky130A and sky130B. The way that the open_pdks installation works, it will generate two directories

sky130A/libs.tech/xschem

and

sky130B/libs.tech/xschem

and copy information from the xschem-sky130 repository into both. If the files are the same in both cases (which generally they will be, since the difference between A and B is largely in parasitics and doesn't have anything to do with low-level devices or schematics), then after

make install

, most of the files in the

sky130B/libs.tech/xschem

path will be symbolic links to the equivalent files in

sky130A/libs.tech/xschem

. Given that the differences between A and B variants have almost no impact on xschem, I would suggest just leaving all your setup files referencing

sky130A

, and then I'll do a search-and-replace on any such references when I install into the

sky130B

path.

Out of curiosity: What is

sky130B

?

@User: When Google announced that ReRAM would be available on all Open MPW runs starting with MPW-four, I realized that the metal stack changes required for the ReRAM implementation would make a lot of the setup files incompatible with the non-ReRAM version of the process (all metal layers from metal2 and up get lifted by the insertion of the ReRAM layers between metal1 and metal2, so all the parasitics change). So I split the PDK into

sky130A

(original) and

sky130B

(ReRAM support).

@User Uff, good to know 🙂 Will MPW-5 still use

sky130A

or already

sky130B

? Last time I checked the

A

PDK has been installed with the recommended settings.

@User: We're doing some work over the next few days to get the repositories correct for

sky130B

, which is mainly to change the technology name in the layout files, but also to check the timing of all the digital blocks with the modified parasitics. When we're comfortable that the chip still works, we'll make the switch and post an announcement. BTW, MPW-four is taking the approach that SkyWater will split the wafer lot, so that there will be several wafers from which we can pull dice for projects (the ones without ReRAM, which is most of them) that are manufactured to the

sky130A

specs, so that we don't have to worry about projects not working because the timing changed. Understand, though, that my expectation is that there is not a whole lot of difference in the parasitics and probably a project that works in

sky130A

will work just fine in

sky130B

. For the most part, from the designer's perspectice, the only real difference is that all the .mag files need to have one line at the top changed from "sky130A" to "sky130B". Timing with parasitics should be checked for good measure (but probably won't show any significant change). We will provide some script and probably a Makefile recipe to go along with it that will do the basic step of search-and-replace on the database files.

@User Makes sense, I would also expect not much impact if the IMD changes a bit. So the M1-M2 via still connects the two if no ReRAM layers in between? BTW, is there a picture for the

B

stack, like the one for the

A

stack?

@User: I guess I'm responsible for drawing the stackup diagrams, so I should make one.