- Libresilicon-developers - libresilicon.com

NLNet grant approved
by Christoph Maier 22 Dec '19

22 Dec '19

Hi, I just got notified that my NLNet proposal "Langsec in pectore" got approved. What about your proposals? tatzelbrumm

5 11

Reminder - Next Mumble session on Sunday, 22/12/2019, 21.00 HKT
by reminder＠libresilicon.com 21 Dec '19

21 Dec '19

Hello List! Just a small reminder for our next Mumble Sessions on this Sunday, 22/12/2019, 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

cell/mask editor updates and questions
by Martin Geisse 19 Dec '19

19 Dec '19

Hi all, some updates and questions regarding my cell/mask editor: - The pixel-based editor works quite well now. With some practice, a few hours were enough for me to draw 15+ simple cells (inverter, buffer, nand, nor, and, or, tri-state inverter; each with different drive strengths). Especially since many of those are simple variants of each other. - I defined the standard cell height to be 140 lambda, which is way too much, even when you are inexperienced and use a very conservative DRC. Much space is wasted. I will eventually restart at 100 or 70 lambda. - The DRC I'm using is *very* conservative, even more so than MOSIS SCMOS. I will mostly keep it that way unless/until you know more about the actual constraints of your process. The most constraining open questions regarding the process are about wells. I will post them here in case you already have some information in this regard. Note that I am thinking of purely digital circuits for now, ignoring analog and clock network related stuff. - Should I assume n-wells only, p-wells only, or both? If both, Do I have to keep a minimum spacing between them? (MOSIS SCMOS says "no spacing, just don't make them overlap", probably because in digital if they touch they make a reverse-biased diode). The spacing is the crucial point here since it affects the cell layout. - Can the n-wells (or p-wells) of different cells be merged without getting issues with electrical noise? Some cell libraries seem to do this, i.e. they use a single long well across a whole row of cells instead of one well per cell (or even one well per transistor). This is super important because separate wells means spacing between wells and even more spacing between source/drain and well boundaries, so it constrains the layout a lot. Greetings, Martin

1 0

Transcript: Meeting in Taiwan
by David Lanzendörfer 15 Dec '19

15 Dec '19

Hello everyone Here is the transcript of the meeting Hernani and I had in Taiwan with Audry Tang, Cyber Minister of the Taiwanese government. https://sayit.pdis.nat.gov.tw/2019-11-27-hern%C3%A2ni-marques-and-david-lan… I'll be staying in touch with her a bit more now in order to maybe get this ball rolling for having their gov financing and performing the rest of the heavy lifting in the R&D part of the LibreSilicon stack. Would give me more mobility (as mentioned in the transcript), for having finally some holidays and having a trip, getting lots of pastéis de nata (and Porto) :D Cheers -lev

4 7

Re: [Libre-silicon-devel] Fwd: Reminder - Next Mumble session on Sunday, 24/11/2019, 21.00 HKT
by Christoph Maier 01 Dec '19

01 Dec '19

RTFM. https://www.smcelectronics.com/DOWNLOADS/1976-TTL%20DATABOOK.PDF http://www.ti.com/lit/sl/scyd013b/scyd013b.pdf http://www.huergo.edu.ar/tcweb/pdf/DS.pdf http://bitsavers.trailing-edge.com/components/fairchild/_dataBooks/1987_Fai… http://bitsavers.trailing-edge.com/components/motorola/_dataBooks/1993_Moto… https://www.ti.com/lit/ug/scbd152b/scbd152b.pdf http://ae6pm.com/Semidata_books/Motorola/DL131-D.pdf http://www.introni.it/pdf/RCA%20-%20CMOS%20Ic%20Databook%20SSD%20250C%20197… The early data books in particular (e.g., RCA 1973, Figures 2, 3) should have very useful information about CMOS internals that were taken for granted and no longer documented later on. On Sun, Dec 1, 2019 at 5:58 AM Hagen SANKOWSKI <hsank(a)posteo.de> wrote: > > > > > -------- Forwarded Message -------- > Subject: Fwd: [Libre-silicon-devel] Reminder - Next Mumble session on > Sunday, 24/11/2019, 21.00 HKT > Date: Mon, 25 Nov 2019 06:38:36 +0100 > From: Hagen SANKOWSKI <hsank(a)posteo.de> > To: Éger Ferenc <eegerferenc(a)gmail.com> > > > Hello Ference! > > Seems, that the attachement was to big for the mailing list. Hence I > forward this directly to you. > > Hagen. > > -------- Forwarded Message -------- > Subject: Re: [Libre-silicon-devel] Reminder - Next Mumble session on > Sunday, 24/11/2019, 21.00 HKT > Date: Sun, 24 Nov 2019 17:31:19 +0100 > From: Hagen SANKOWSKI <hsank(a)posteo.de> > To: libresilicon-developers(a)list.libresilicon.com > > Hello List, Hello Ference! > > Regarding the topics we had today in the Mumble session: > > 1. > here is a small discussion about the Schmitt-Trigger I had in mind, > which points also to *both* sources I am aware of > > https://electronics.stackexchange.com/questions/301158/cmos-schmitt-trigger… > > 2. > attached a data book scan regarding TTL input current (I_iL, I_iH) - > sorry in German only - for some TTL families. While nobody is using 74xx > anymore, I guess we should be comparable to a 74LSxx standard input-load > with our TTL Input Pad. > > > Best Regards, > Hagen. > -- > support LibreSilicon to get back into the Clean Room > https://www.gofundme.com/f/libresilicon-cleanroom-rent > >

1 0

Reminder - Next Mumble session on Sunday, 01/12/2019, 21.00 HKT
by reminder＠libresilicon.com 30 Nov '19

30 Nov '19

Hello List! Just a small reminder for our next Mumble Sessions on this Sunday, 01/12/2019, 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

Reminder - Next Mumble session on Sunday, 24/11/2019, 21.00 HKT
by reminder＠libresilicon.com 24 Nov '19

24 Nov '19

Hello List! Just a small reminder for our next Mumble Sessions on this Sunday, 24/11/2019, 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!

2 1

unable to connect to mumble 3 hours ago
by Christoph Maier 24 Nov '19

24 Nov '19

What did I miss? tatzelbrumm

1 0

mask editor
by Martin Geisse 23 Nov '19

23 Nov '19

Hi all, in case anybody is interested in this: I started working on a mask editor that is similar in principle to Magic, but with a few notable differences: - totally different, more "Paintbrush-like" approach to its user interface - not build in C around a TCL interpreter, but written in Java and extensible by writing Java code - design is done using a "virtual" technology (in Magic terms) that is as minimal as possible, hoping to derive the actual masks from this in a mostly-automated way Current results so far look promising. I was able to draw a NAND gate, export it to Magic, export it from there to SPICE and simulate it as a circuit. Screenshots: https://github.com/MartinGeisse/chipdraw/blob/master/resource/test/nand/des… Code: https://github.com/MartinGeisse/chipdraw I'm working on the DRC only now, so the NAND from above will likely have some DRC violations I didn't notice. Greetings, Martin

1 0

Hard show stopper for tools
by Christoph Maier 17 Nov '19

17 Nov '19

>From https://en.wikipedia.org/wiki/Scheme_(programming_language): "Scheme has a diverse user base due to its compactness and elegance, but its minimalist philosophy has also caused wide divergence between practical implementations, so much that the Scheme Steering Committee calls it "the world's most unportable programming language" and "a family of dialects" rather than a single language." Any programming language is only as compact and elegant as its installation procedure on different computers and operating systems.

3 3