[cjsplat]

For SW type people ...

GCC's impact was possible because it was (with GAS - the assembler) 100% feasible to have an open source toolchain. Yes more software was necessary for a complete system (linker, libc, etc), but GCC made it possible to build from the ground floor up.

Also, yes, the initial GCC was worse than any proprietary decent tool chain at the time, but it got better and better because each improvement built on all the earlier open sourced efforts.

Think about how hard Linux kernel development would have been if it had to rely on different proprietary tool chains for every target architecture (and possibly chip version).

Hardware definition languages (Verilog/VHDL, etc) enable high level chip design like high level programming languages, but making the physical chip requires a PDK (process design kit) that encodes how each critical silicon feature is built.

So a chip built for TSMC 28nm contains TSMC proprietary material and is essentially unportable. It can take several years to move a major chip from one foundry to another (or even a shrink at the same foundry), and the proprietary tool chains preclude a development process that can incrementally improve portability.

This announcement is a a major step toward a similar foundation being available for silicon design. It is very important that it is a large complex chip, rather than just a research development vehicle.

[disclaimer - past life as OpenPOWER participant]

[Taniwha]

I've worked on big chips designed to be taped out to multiple (3) fabs - you have to either build your own libraries that have some minimum performance on all processes, or recompile with a new fab's libraries - my experience is that if you plan for it it's more a matter of a few months than years

[lkcl]

you'll be fascinated to know that we picked a python-based (Object-Orientated) HDL - nmigen - for exactly this reason.

we've developed a dynamically SIMD-partitionable-maskable set of "base primitives" for example, so you set a "mask" and it automatically subdivides the 64-bit adder into two halves. but we didn't leave it there, we did shift, multiply, less-than, greater-than - everything.

https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/iee... https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/iee...

can you imagine doing that in VHDL or Verilog? tens of engineers needed, or some sort of macro-auto-generated code (treating VHDL / Verilog as a machine-code compiler target).

the reason for doing this - planning it well in advance - is because we're doing Cray-style Vectors (Draft SVP64) with polymorphic element-width over-rides. yes, really. the "base" operation is 64-bit, but you can over-ride the source and destination operation width.

the reason why we're using our own Cell Library is actually down to transparency. we want customers to be able to compile the GDS-II files themselves, fully automated, no involvement from us, no manual intervention.

ironically, as an aside: Staf's Cells are 30% smaller (by area) than the Foundry equivalents.

[nickik]

Google has done a lot of effort in that direction. The first ever chips have already been produced that are fully open source from the tools used to make to the complete tool chain need to manufacture them.

There is a huge amount of great stuff going on this this area.

Tim Ansell - Skywater PDK: Fully open source manufacturable PDK for a 130nm process

https://www.youtube.com/watch?v=EczW2IWdnOM

[lkcl]

interestingly, Libre-SOC and NLnet's funding pre-dates the google-sponsored Skywater 130nm process. also, because it's funded by NLnet we're not dependent on google, don't have to pass "conditions", and in particular were not forced to use OpenLane and were not limited to 48 pins controlled by a "Management Engine".

Staf actually developed actual IOpad Cells (from scratch), actual Standard Cells and a 4k SRAM block: we did not use the NDA'd TSMC Cell Libraries, here.

if we had used Skywater 130nm we would have been forced to ditch LIP6.fr (i cannot express enough how hard Jean-Paul Chaput has worked on coriolis2 for the past 18 months), we would not have been able to test the IOpads that Staf developed... yeah.

bottom line is we used a complete independent VLSI toolchain - fully automated - that has nothing to do with the USA or DARPA Military funding - and was developed with European expertise.

[KirillPanov]

> and in particular were not forced to use OpenLane and were not limited to 48 pins controlled by a "Management Engine".

That's because they used TSMC, not SkyWater.

I think you're deliberately creating confusion here.

Also, as the webpage states, they signed TSMC's NDA:

> LIP6 were able to create the GDS-II tape-out under NDA

Sure, if you sign the NDAs, you can use whatever toolflow you want.

Look, I don't mean to in any way denigrate your techinical achievement here, and I have no beef with your project. But the absence of no-NDA foundry access is a huge, massive obstacle to a truly public and free open-source ecosystem, and lately there have been a lot of people and organizations papering over that problem and bamboozling software folk who aren't aware of the issue and its details. Hiding the problem isn't going to get it fixed.

[lkcl]

> Also, as your webpage states, you signed TSMC's NDA:

FALSE. again. i do not work for LIP6. i do not work for Chips4Makers. i am an independent *LIBRE* Developer. i have NEVVERRRR signed a Foundry NDA and, having a background involving security analysis and Reverse-Engineering, it would be suicidally and monumentally stupid and counter-productive for me, personally, to do so.

please try to not conflate matters (twice in succession) that you haven't checked or read properly. the best thing to do is to ask questions, such as:

"You're a Libre Project. that has significant implications that everything is entirely Libre. I notice however that you say that someone signed a Foundry NDA? what impact did this have for you? did it stop you from releasing any source code as per obligations of LIBRE Licenses?"

and then i can answer positively and in a friendly way rather than having to publicly waste both my time and that of readers in first unpicking the mistakes, embarrassing you in the process (which risks a public confrontation that annoys everybody even more), and it all goes to hell pretty quickly after that.

answering the question above that you didn't ask: as you know there are about five layers of NDAs in the Silicon Industry.

we've managed to bust through three of those, and so have managed - as a LIBRE Team - to fulfil our obligations both to our funding body, NLnet, under their Privacy and Enhanced Trust Programme, and to Libre/Open Hardware developers by releasing all HDL under LGPLv3 Licenses

     https://git.libre-soc.org

and using Libre-Licensed VLSI tools

and using Libre-Licensed Cell Libraries

now, the TEAM THAT DEVELOPED the VLSI tool - signed a TSMC NDA.

      NOBODY ON THE LIBRE-SOC TEAM SIGNED THAT NDA.

also, Chips4Makers - the developers of FlexLib - signed a TSMC NDA

      CHIPS4MAKERS != Libre-SOC

we are three separate and INDEPENDENT teams, working together, to tackle an insane situation, at different levels. i'll say it again:

      LIBRE-SOC HAS NOT SIGNED AAAANNNYYYYY FOUNDRY NDAs.

are we clear about that, now?

there happens also to be another team, Libre-Silicon, also funded by NLnet, who are developing an actual Libre VLSI process and actually developing a mini home-grown Fab.

then there is another NLnet-sponsored project, working with the Libre Silicon team, to develop another Libre-Licensed Standard Cell Library, that is targetted at Libre-Silicon's PDK (when it's available)

  https://nlnet.nl/project/LibreSiliconStandardCellLibrary/

however neither of these are ready, so we went with the pragmatic route, after exhausting all other options: the parallel track.

[ploxiln]

These details are fascinating and non-obvious. Every little tool or part you have to use to work with even 15-year old chip fab processes is under NDA.

It's hard to come up with a good analogy ... it's like you need to write your own serial driver for your new open-source programming language to do any I/O, because you can't call any libraries or OS syscalls because they're all NDA, even on a 15+ year old computer/OS.

[lkcl]

yehyeh, or you bought a winmodem over 15 years ago, someone told you "hey you have to upgrade to windows 10", it downloads over your 56k Dialup winmodem, reboots... and... no drivers. yes this really happens: ThinkPenguin stock TTYACM USB modems and their biggest customers are Rural people in the USA who are too far out to get broadband!

LIP6 does actually have a fully NDA-free silicon-proven Cell Library, called nsxlib, it's been used in 360nm and 180nm, the 180nm was done by a Japanese University. i think i may have mentioned this already, it's a small town with a 2(?) micron foundry, they make it available to people anywhere in the world entirely for free, it's for training the employees of the town, because it's so old and basic it's hard to mess it up. so they want people to submit designs that the trainees can learn how to fab, before they move on to the more expensive equipment.

but, really, use Chips4Makers, he has 360nm available, EUR 1750 for 20 MPW chips in QFP, i believe.