- Libresilicon-developers - libresilicon.com

Design rules...
by David Lanzendörfer 30 May '19

30 May '19

Hi We need some design rules, otherwise this will never work. Those rules aren't just there for fun, or to make the life of the layout designer more difficult, they actually have a purpose. I've got to introduce two important design rules now, which are needed, because otherwise it's virtually impossible for me to guarantee working devices. Rules: 1) n-well/p-well have to be at least 5 microns apart from each other. Reason: The isolation trench between the wells is around 2.5~3.5 microns deep (variation due to CMP variation) Wet etching has a 45 degree angle and dry etching isn't a perfect 90 degree angle either, so in order to make sure, that the individual pull-up/pull-down paths or whatever are properly isolated to each other, the wells have to have a spacing of at least 5-7 microns (do the geometry/math) 2) holes within the contact,via1,via2,via3 layer all have to have the *exact* same size and dimensions. I had good results with the 2um x 2um holes. Reason: Depending on the area, the etching rate of HF acid as well as the dry etcher is varying. While in the smaller contact holes, there was still residue of LTO visible under the microscope, in the big holes nearly all of the silicide was already gone. In the future I will add export filter back into cifoutput, which turns all contact holes, which are bigger than 2u x 2u into an array of 2u x 2u holes, and anything smaller will give you a DRC error. -lev

1 0

CCC camp Mildenberg, Aug. 21st – 25th, 2019
by Hagen SANKOWSKI 29 May '19

29 May '19

Hello List! Well, it's time again for the well-know CCC camp in Summer in Mildenberg (North of Berlin/Germany) this year! https://events.ccc.de/ I am convinced that working together sometimes in in real-live make it better to communicate onnline. So how about meet, hack, teach and talk with each other? How about socializing in our project? If we like, we can organize work shops, eg. about our technologies, how to play with the tools or about the basic like how to make chips in general.. The CCC camp happens every 4 years only and was always a great, overwhelming, very intensive event in the past. Tickets are available https://tickets.events.ccc.de/camp2019 CU in summer, Hagen.

2 1

CCC camp Mildenberg, Aug. 21st – 25th, 2019
by Hagen SANKOWSKI 28 May '19

28 May '19

Hello List! Well, it's time again for the well-know CCC camp in Summer in Mildenberg (North of Berlin/Germany) this year! https://events.ccc.de/ I am convinced that working together sometimes get better in real-live. So how about meet, hack, teach and talk with each other? How about socializing in our project? If we like we can organize work shops, eg. about our technologies, how to play with the tools or about the basic like how to make chips in general. The CCC camp happens every 4 years only and was always a great, overwhelming, very intensive event in the past. Tickets are available https://tickets.events.ccc.de/camp2019 :-) CU in summer, Hagen.

1 0

Implant stop, silicide block
by David Lanzendörfer 28 May '19

28 May '19

Hi folks So, after implanting the pjunction and the njunction I've put the wafer into H3PO4 at 155 degrees Celsius. 15 minutes were enough to remove all the nitride residue within the smaller holes, as I had expected. I've now driven in the junction implants for 30 minutes at 900 degrees Celsius and then covered the wafer with 30nm nitride, which will become the silicide block and the nitride spacers. Unfortunately, the NFF RIE had problems again today, which means I can only etch the nitride tomorrow, given Bao manages to get the NFF RIE working again by then. Both machines which could dry etch the nitride are essentially broken ATM, with the NFF RIE at least having a good chance of getting operable again tomorrow. -lev

1 0

Analog design toolchain for 555
by Éger Ferenc 27 May '19

27 May '19

Hello All, As we discussed in the last mumble session, here is some status on the analog toolchain I intend to use for the 555. First, some note on the general approach: Many of the tools here are typical Unix-style (invoked in terminal, file goes in, file comes out). This is good from an integration and modularity perspective, and it is a tempting thought to strip all "unnecessary" intermediate steps (gnetlist, gspiceui) and write the SPICE deck and invoke tools manually (as suggested). However, I think this shall be a last resort in case when everything else goes FUBAR, because of two things: first, manual processing is error-prone and we need to really firm regarding what we layout is what we simulate (it is easy to just forget or mistype something and then overlook it) and second, if someone sees in the repo that doing a single .OP requires 6-10 hand-crafted terminal commands (not to mention parameter sweeps or monte carlo), it may be a huge deterrent in adoption (engineers are humans too, and humans in general love the convenience of a big green button). The tools so far (RFC if you think there's a better option): gschem 1.8.2 (schematic capture) gnetlist 1.8.2 (netlist extractor, alleged source is at https://packages.ubuntu.com/source/xenial/geda-gaf) gspiceui 1.1.00 or 1.2.36 (orchestrates netlist extraction, deck generation, simulator invocation, waveform viewer invocation, like ADE, source: https://sourceforge.net/projects/gspiceui/) ngspice 26 (simulator) gaw (waveform viewer) Problems discovered so far: 1. In gschem, components automatically get '?' refdes on place or copy. Refdes must be unique, therefore it is beneficial to insert some lines (see https://ashwith.wordpress.com/2010/09/10/circuit-simulation-in-gnulinux-let…) into gschemrc (and not gafrc, that doesn't work). 2. gnetlist makes use of the gschemrc configuration to establish mapping between symbols and sub-schematics (subsch is not recorded in the schematic, but in the symbol file). However, gspiceui invokes gnetlist not in the current working directory, but where the schematic is loaded from, so local gschemrc is not parsed. Possible solutions: - Adapt a flat directory structure (no sources, tbench, ...). Ugly but works. - Place a link to the local gschemrc everywhere - Set libraries in the global gschemrc (not good because necessary config no longer contained in the project dir) - Patch gspiceui (PrcGNetList.cpp 396) - Invoke gnetlist manually outside gspiceui and import complete netlist 3. In case of hierarchical designs flattened into a single circuit, gnetlist places '/' into net names and component names ("X1/R1 11 7 100k"). This breaks ngspice (interpreted like "X1 R1 11 7 100k"). Blind replacement does not help, as if we use parametric models, we may need expressions containing division. 4. Nets in lower levels and nets at higher levels connected to them are treated as separate entities and not connected, for example: MX1/M26 X1/OUTPUT 18 X1/GND X1/GND nmos4 l=0.5u w=20u R3 1 5 100 (shall be R3 1 X1/OUTPUT 100) Maybe the wrong port symbol is used in the lower level, this needs to be checked first. 5. When flattening hierarchical designs, component designators sometimes have wrong first letter (first letter denotes component type). Particularly, MOS works but resistors are not: MX1/M11 X1/GND 13 13 X1/GND nmos4 l=0.5u w=10u X1/R4 12 X1/GND 40k Output from console: --- checking package = X1/M12 device = NMOS_TRANSISTOR Found NMOS transistor. Refdes = X1/M12 Checking prefix. Package prefix =X correct prefix =M nomunge mode = #f different-prefix=#t --- checking package = X1/M11 device = NMOS_TRANSISTOR Found NMOS transistor. Refdes = X1/M11 Checking prefix. Package prefix =X correct prefix =M nomunge mode = #f different-prefix=#t --- checking package = X1/R4 device = RESISTOR Found resistor. Refdes = X1/R4 --- checking package = X1/R2 device = RESISTOR Found resistor. Refdes = X1/R2 Most of the errors can be reproduced by invoking gnetlist on the current testbench (before that, V? needs to be changed into V1). Command line: /usr/bin/gnetlist -v -g spice-sdb -o /home/kiseferi/IC/github/CMOS-555/TBench/geda/Use-Case_astable-mode.ckt /home/kiseferi/IC/github/CMOS-555/TBench/geda/Use-Case_astable-mode.sch The resulting netlist of course makes no sense (no .MODEL for MOSFETs, etc...), but what is already there should be structurally correct. Maybe a solution is to use either a .SUBCKT instead of flattening (good only if internal nodes remain query-able), or to use a single schematic page (ugly). Regards, Ferenc

3 7

Reminder - Next Mumble session on Sunday, 21.00 HKT
by reminder＠libresilicon.com 25 May '19

25 May '19

Hello List! Just a small reminder for our next Mumble Sessions on this Sunday, at 21.00 Hong Kong Time. Please join us as usual at our Mumble Server murmur.libresilicon.com at Port 64738, the Channel is IC. Thanks for the attention!

1 0

Switching PMOS
by David Lanzendörfer 25 May '19

25 May '19

Hi Michael and I managed today to etch Nickel wires with a precision, which allows to make actual measurements of the devices on the wafer. I made some pictures of the current results and make a Tweet about it: https://twitter.com/LibreSilicon/status/1131542403796488192[1] https://twitter.com/LibreSilicon/status/1131543365894324232[2] So I've got a diode curve and switching transistors. Of course I haven't compensated for the thermal budget, but that's what the three wafers in my cassette in the locker are for. -lev -------- [1] https://twitter.com/LibreSilicon/status/1131542403796488192 [2] https://twitter.com/LibreSilicon/status/1131543365894324232

3 2

F.Y.I - the back-side of the current license policy
by Hagen SANKOWSKI 22 May '19

22 May '19

https://www.techpowerup.com/255715/u-s-tech-industry-including-google-micro… As I know now, there are involved at least - Intel / Qualcomm with LTE / 5G modems - Xilinx with FPGAs - Infineon with power electronics and many, many others. The worst case IMHO would be, when there are rising up two branches of technology (one for the Americans in their cheese dome and the other one with Chinese vendors) which are completely incompatible..

5 6

Status update, nickel etching
by David Lanzendörfer 22 May '19

22 May '19

Hi all So, because the MFC for the Cl2 has been erratic and the MFC replacement is very time consuming and a new MFC is pretty expensive, we just decided to manually turn off the Cl2 valve and run it with Argon only. Turns out, that ion bombardment was even too slow, when using a pure Argon plasma for etching. I've spent the entire day working with the Cirie200 today and at the end I asked for giving it More Power! *Tim Taylor grunt* With 500W instead of 400W I actually had a usable reaction rate and the nickel film became so thin, that the underlying oxide became visible. Tomorrow I prepare 3 more samples and test the etching with the new recipe. I keep you informed David

2 1

Status update
by David Lanzendörfer 20 May '19

20 May '19

Hi So today I finally got access to the Cirie200 metal dry etcher. I was running my test sample for measuring the nickel etch rate, when I noticed, that it wasn't etching at all and that the Cl2 flow rate was totally off in respect to the recipe, and the Cirie200 was giving me errors. I consulted with the technician who admitted to me, that the Main Flow Control (MFC) had broken a while ago but they didn't replace it, because apparently no one was noticing, that they were not etching according to the recipe, but had in fact random Aluminum etch rates, basically, because of random variation of the Cl2 flow... -.-' Anyway... Now he has to purge the entire Cl2 line with N2 and then he can replace the main flow control for the Cl2, so that I've got the proper Cl2+Argon mix for dry etching the Nickel. I also isolated the issue, why I haven't managed to produce switching transistors until now. And mia culpa, I right now wanna beat myself... really hard into the face. The Titanium etched nice. But when you only sputter 100nm aluminum and wet etch it without the Titanium coverage, you see, that it's over etching the exact same way, as Nickel does with the wet etching. So, as soon as Bao gets the valve fixed interconnect to the devices should actually work quiet fine. Cheers -lev

1 0

2024

2023

2022

2021

2020

2019

2018

Libresilicon-developers