Live data from Hacker News

Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

openpowerfoundation.org

41–50 of 68 posts

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#41

I didn't see any specs for this SoC in the article, did I miss it?

no, it's pretty basic, and implicit: it's the (newly-created) "Scalar Fixed-Point Compliancy Subset) - i added a bit to the wikipedia page last month about them https://en.wikipedia.org/wiki/Power_ISA#Compliancy

it's 64-bit, LE/BE, and it's implementing a "Finite State Machine" (similar technique to picorv32, if you know that design). this because we wanted to keep it REALLY basic, and also very clear as a Reference Design, none of the "optimised pipelined decoders and issuers" that you normally find, which make it really, really difficult to see what the hell is going on.

bear in mind this includes SVP64: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple...

if you go back several revisions, the non-Vectorised version is like... 400 lines?

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#43
post #8
post #5

Earlier quoted context omitted.

Who is this important for? Is there a lot of software still being developed for POWER? It seems niche to me, but maybe I'm the one in a niche.

IMO: the underlying architecture is mostly relevant to kernel/compiler authors and people doing aggressive optimization. For most application devs it's about as irrelevant as you can get (unless your language has a very hard to port compiler cough rust. ) What's good about this is that the source is available and can be verified to some degree against the hardware (by decapping it.) That puts a log of constraints on…

ultimately what we'd like to see is entirely NDA-free PDKs even for 12nm and below, and you can run the VLSI tools and generate the EXACT GDS-II yourself, then yes, de-cap the processor and do a digital comparison.

before you even get to that stage, you run the Formal Correctness Proofs and unit tests on the HDL, so that YOU have confidence that the HDL which you're about to generate the GDS-II files from is actually correct and does the damn job.

example of a Formal Correctness Proof for the fixed arithmetic Power ISA pipeline:

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

runs with symbiyosys, so you end up running SAT Solvers like yices2 and z3.

basically we absolutely do not want to be the people you come to and say, "can we trust your ASIC?" and like Intel they lie to you and say "of course!", we want to say, "don't bloody well ask us, go run the damn tools yourself! oh, btw, if you want help with that we charge USD 5k per hour"

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#44
post #40
post #33

Earlier quoted context omitted.

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:…

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…

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.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#45
post #24
post #16

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 bui…

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

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.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#46

Earlier quoted context omitted.

Yes, and they still do. They've got a Management-Engine type layer that you are forbidden to remove or modify in any way, even if you pay the full $10k and do not accept any subsidies. So many people asked about this that the foundry had to make a FAQ about it: https://www.skywatertechnology.com/ufaqs/can-i-customize-the...

This impacts the fab itself, but the design rules can still be usable elsewhere since they've been released openly.

Use them where, exactly?

Your comment glosses over a ton of critical details.

The most important of them being that even on such an old technology generation (180nm-110nm) no two fabs are so compatible that you can send a GDS designed for one of them to the other unless (a) one of them licensed their process from the other, like IBM/GloFo/Samsung back in the 2010s or (b) you planned for this in advance and designed a custom "least common denominator" process (like MOSIS SCMOS) to target which means making very large performance sacrifices. The (b) approach is much harder than it looks; I know of no examples other than MOSIS SCMOS, and in spite of being the pioneer experts at doing this they had a hard time at 180nm and failed on the following (90nm) generation.

The other, lesser, problem is that no foundry will let you even submit a GDS without signing their NDA. Even if you swear to them that you don't need their design rules for some reason. They don't care. NDA or no chips, not up for discussion. In fact, technically SkyWater still works this way -- to avoid the NDA you must submit through eFabless, not directly to the foundry (maybe this will change someday) and eFabless signed their NDA, then (obviously) negotiated a waiver. So saying "you can work around this problem that the only no-NDA foundry has by just going to another foundry" because there are no other no-NDA foundries, nor are there any on the horizon.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#47
post #33
post #32

Earlier quoted context omitted.

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

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:…

> 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.

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#48
post #8
post #5

Earlier quoted context omitted.

Who is this important for? Is there a lot of software still being developed for POWER? It seems niche to me, but maybe I'm the one in a niche.

IMO: the underlying architecture is mostly relevant to kernel/compiler authors and people doing aggressive optimization. For most application devs it's about as irrelevant as you can get (unless your language has a very hard to port compiler cough rust. ) What's good about this is that the source is available and can be verified to some degree against the hardware (by decapping it.) That puts a log of constraints on…

Rust supports powerpc64le-unknown-linux-gnu, it is in-fact what we used to test a lot of POWER9's instructions to replicate the exact results that POWER9 gives, since the ISA spec doesn't specify the results for a lot of cases.

https://git.libre-soc.org/?p=power-instruction-analyzer.git;...

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#49

Earlier quoted context omitted.

What about the tools and processes to manufacture this? Are those open source or broadly available? For instance, is it possible to have a small scale "community" fab for 1999-era chip technology?

I've been keeping an eye out for anything like this. There's Sam Zeloof, doing one-offs in his home lab [1], and there's Libre Silicon [2] putting together their fab too, but the info there's more scarce. Neither one has published an easily-replicable process, meaning I can't really repeat what they've done. IMO what this space needs is an open source build plan/BoM, with a cottage industry of people selling DiY and…

Hey, I admire your spirit and enthusiasm.

However, one thing to keep in mind is that below 500nm a lot of the chemicals are extremely toxic and not the kind of thing that garage hackers are qualified to handle in an environmentally safe manner.

Arsenic, phosphene gas, hydrogen fluoride, nasty solvents. I build a lot of crazy stuff in my shop, but I don't even trust myself to dispose of these correctly. If makers like myself get involved in this we're going to end up with a lot of new superfund sites. In residential neighborhoods.

And then of course there's the ion implanter, which none of the fab employees want to spend much time around...

Re: Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW

#50
post #33

Earlier quoted context omitted.

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:…

> 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 i…

> 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.
Post reply on HN