5 ms·
Libre-SoC 180nm Power ISA v3.0 ASIC Submitted to IMEC MPW
- marcodiego 5y agoThis is a very important step. I don't understand how this is not on the first page. Maybe a more click-baity title is needed?
- swiley 5y agoCommenting on articles early in their life weights them down significantly, if you want something on the front page you should absolutely not comment on it until it gets there.
- marcodiego 5y agoThanks for the advice. Didn't know that. Actually, I'm answering only because because it finally got to the first page. Off topic: where did you get this rule?
- UncleOxidant 5y agoThat seems counterintuitive. Do you have any data to support this?
- cdcarter 5y agoWho 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.
- swiley 5y agoIMO: 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 what kinds of secret back doors people can build that we didn't have before.
- lkcl 5y agoultimately 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/formal/proof_main_stage.py;hb=HEAD 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"
- programmerjake 5y agoRust 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;a=summary https://git.libre-soc.org/?p=power-instruction-analyzer.git;...
- swiley 5y agoI was talking about new architectures in general, not just powerpc.
- addaon 5y agoThe POWER/PowerPC ISA is still widely used in safety-critical avionics, where a mature tool-chain exists for supporting DO-178 objectives. In my opinion, an area of interest going forward into the next decade of more safety-critical software written by smaller and smaller orgs (e.g. eVTOL companies, sensor companies, etc) is continuing to push forward which objectives can be accomplished by formal means instead of primarily through testing. An NXP or IBM processor might be great, and might be mature, and might be very well tested -- but I, as a safety-critical software developer, have little way of demonstrating that to certification authorities. The availability of open-source processor designs and, in the future, traceable and accountable conversion from those HDL designs to RTL, to masks, and then to silicon, gives a path to showing that portions of a processor are correct-by-design, and thus a path to the goal of showing that my machine-code-as-authored(-by-an-assembler) and machine-code-as-executed(-by-a-processor) semantics match.
- cruunchMuncher 5y agoDO-178 objectives? You mean the same one used in 737 Max?
- addaon 5y agoI'm not familiar with whether the 737 Max development used DO-178B or DO-178C; the latter is a successor to the former, but frames the development process significantly differently. Any process can be used well or poorly, and DO-178C isn't really a process, it's a set of objectives that a process must accomplish. When used in good faith, I believe it can lead to software of higher quality than almost any other approach (although, to be fair, at higher software development cost than almost any other approach). That doesn't mean that chanting the document name and using hand-me-down rituals is sufficient to achieve high quality software, of course :-).
- lkcl 5y ago> The POWER/PowerPC ISA is still widely used in safety-critical avionics and in the Mars Rover, which is a radiation-hardened 133mhz 32-bit Power ISA system.
- marcodiego 5y agoAFAIK this is a libre soc developed using libre software tools, some of which were developed by the group members themselves, free from royalties and independent from any for-profit institution. This is probably "librier" than RISCV. The fact that the POWER architecture may be niche is not a problem since so much software can be compiled for it. See the thalos workstations: https://www.raptorcs.com/TALOSII/ https://www.raptorcs.com/TALOSII/ and the powerpc notebook: https://www.powerpc-notebook.org/en/ https://www.powerpc-notebook.org/en/ For people who are willing to use niche hardware for more control on what is running, this is seems like a very important step.
- zozbot234 5y agoRISCV is an ISA, not a core design much less a complete SoC. The closest comparison would be something like Rocket, or BOOM.
- Seirdy 5y agoMany hyperscalar server setups use POWER8/POWER9 CPUs. 4 logical processes per core (and 8 with the upcoming 15-core POWER10 configurations) are pretty useful when measuring perf-per-watt. The Talos is currently the only fully libre computer available for high-perf computing, and it uses POWER9 CPUs. If you want a fully free CPU, your choices are either very dated CPUs or POWER. Many distros (inc. Debian, and most source-based ones) support ppc64/POWER officially quite well and go out of their way to ensure a high degree of portability.
- gnufx 5y agoActually, SMT8 P8 and P9 is documented, though it seems rare. Our HPC systems are only SMT4, anyhow. Yes, you can just install most of at least Debian, Fedora, RHEL, at least, though it needs an "alt" kernel on RHEL7 P9. There are a few things which haven't been ported, mainly due to assembler, I guess. (PRoot and DMTCP are two I know.) Even x86 SIMD intrinsics will largely work, if not necessarily very efficiently.
- kilodeca 5y agoBy Libre computer do you mean the entire system, hardware and firmware?
- phendrenad2 5y agoMany things were ported to power over the last ~3 decades, and that code is still valuable today.
- KirillPanov 5y agoBecause it isn't really open source. https://news.ycombinator.com/item?id=27777223 https://news.ycombinator.com/item?id=27777223
- fithisux 5y agoCongratulations.
- lkcl 5y agothanks :)
- vfclists 5y agoWhat does this mean to noobs like me?
- insulanus 5y agoHere are a few implications: * In a few years (maybe 5?), it might be possible to build a computer that you can trust has no intentional back doors in the CPU, but is modern enough to run software from within the last decade. * If this catches on, and is used by enough people, economies of scale might kick in, and bring costs for advanced custom chips down by an order of magnitude (if the cpu is small enough, and if more fab capacity is built). Not Intel/AMD/ARM parts - those prices will remain stable, at first. * Maybe we can have another decent consumer-grade router? No, this is a pipe-dream. * Our Amiga accelerator boards will become SMOKING fast.
- Narishma 5y agoI didn't see any specs for this SoC in the article, did I miss it?
- lkcl 5y agono, 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 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/issuer.py;hb=HEAD 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?
- KirillPanov 5y ago> Symbolic (ghost) versions of FlexLib allowed Libre-SOC developers to not have to sign a Foundry NDA during the development of the ASIC Layout In other words, this chip isn't even remotely open-source. What they sent to the foundry isn't the "ghost cells" (which don't have transistors in them and therefore don't work). This fails the most basic requirements of being open source.
- test_epsilon 5y agoWhat is the problem if they could be translated to a working chip? A C program contains no instructions the machine can use and yet you can compile an open source program with a closed source compiler.
- lkcl 5y agowe used an entirely Libre-licensed VLSI "compiler", which takes HDL as input and spits out fully-completed GDS-II Files. the problem with this particular irate individual is that he's assumed that because TSMC's DRC rules are only accessible under NDA that automatically absof*** everything was also "fake open source". idiot. sigh. clearly didn't read the article. whilst both Staf Verhaegen and LIP6.fr signed the TSMC Foundry NDA, we in the Libre-SOC team did not. we therefore worked entirely in the Libre world, honoured our committment to full transparency, whilst Staf and Jean-Paul and the rest of the team from LIP6 worked extremely hard "in parallel". the ASIC can therefore be compiled with three different Cell Libraries: * LIP6.fr's 180nm "nsxlib" - this is a silicon-proven 180nm Cell Library * Staf's FreePDK45 "symbolic" cell library using FlexLib (as the name says, it uses the Academic FreePDK45 DRC) * the NDA'd TSMC 180nm "real" variant of Staf's FlexLib i was therefore able to "prepare" work for Jean-Paul, via the parallel track, commit it to the PUBLIC REPOSITORY (the one that's open, that our resident idiot didn't bother to check existed or even ask where it is), which saved Jean-Paul time whilst he focussed on fixing issues in coriolis2. it was a LOT of work.
- lkcl 5y agoHDL source code: https://git.libre-soc.org/?p=soc.git;a=summary https://git.libre-soc.org/?p=soc.git;a=summary Coriolis2 source code: http://coriolis.lip6.fr/ http://coriolis.lip6.fr/ Chips4Makers FlexLib Cell Library based on FreePDK45: https://gitlab.com/Chips4Makers/c4m-pdk-freepdk45/-/releases https://gitlab.com/Chips4Makers/c4m-pdk-freepdk45/-/releases Automated Layout scripts for generation of GDS-II Files: https://git.libre-soc.org/?p=soclayout.git;a=summary https://git.libre-soc.org/?p=soclayout.git;a=summary please do try to get your facts right and not mislead people by making false claims, eh?
- dragontamer 5y agoA fully open source chip, from Verilog to Fabrication is cool! It may be 180nm (1999-era technology), but that's still hugely important. The world of semiconductor design is incredibly closed source and secretive.
- throwawaysea 5y agoWhat 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?
- marktangotango 5y agoOr any other options for "small" batch sizes?
- wallacoloo 5y agoI'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 pre-assembled kits. Once the 3d printing community got there, that's when things took off -- before kits or at least build guides with proper BoMs, it was just disparate individuals doing their own thing. Connect me with anyone who's got a good approach to building some sort of replicable open-source fab though, and I'll quit my job and join the project full-time (that's not a joke: I'm serious). [1] http://sam.zeloof.xyz/category/semiconductor/ http://sam.zeloof.xyz/category/semiconductor/ [2] https://libresilicon.com/ https://libresilicon.com/
- KirillPanov 5y agoHey, 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...
- cjsplat 5y agoFor 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 5y agoI'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 5y agoyou'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/ieee754/part/formal/proof_partition.py;hb=HEAD 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/ieee754/part/partsig.py;hb=HEAD 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.
- gnufx 5y agoInteresting as this is, I'll look forward to version two, to see how the vector processing works.
- lkcl 5y agoyou can get a pretty good idea right now, the simulator is functional and the unit tests include explanations in english: https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/... i'm currently in the middle of a rabbit-hole exploration of being able to do in-place RADIX-2 FFT, DCT and DFT butterflys, the target is a general purpose function to cover each of those, in around 25 Vector instructions. not 2,000 optimised loop-unrolled instructions specifically crafted for RADIX-8, another for RADIX-16, another for RADIX-32 ..... RADIX-4096 (as is the case in ffmpeg): 25 instructions FOR ANY 2^N FFT. btw if you're interested in "real-world" SVP64 Vector Assembler we have the beginnings of an ffmpeg MP3 CODEC inner loop: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/audio/mp3/mp3_0_apply_window_float_basicsv.s;hb=HEAD https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=medi... that's under 100 instructions, more than 4x less assembler for the same job in PPC64. and 6.5 times less assembler than ffmpeg's optimised x86 apply_window_float.S you will no doubt be aware of the huge power savings that brings due to reduced L1 cache usage.
- phendrenad2 5y agoI can't wait to see the Vulkan implementation for this. Apparently it should be somewhat hardware-accelerated due to the vector capabilities of the core?
- lkcl 5y agoyes, so the "normal" way that GPUs work is: the architecture and the ISA are so staggeringly optimised they're completely incompatible and incapable of running standard (general-purpose) workloads. no MMU, vast wide SIMD engines, massive numbers of parallel memory interfaces that run really slowly but can handle (when added up) vast bandwidth far in excess of "normal" processor memory, and so on. on top of that, because it's an entirely separate processor, to get it to do anything you actually have to have a Remote Procedure Call system, operating over Shared Memory! oink. so the process for running a GPU shader binary is as follows: step 1: fire up a compiler (in userspace) step 2: compiler takes the shader IR and turns it into GPU assembler step 3: the userspace program (game, blender, whatever) triggers the linux kernel (or windows kernel) to upload that GPU binary to the GPU step 4: the kernel copies that GPU binary over Shared Memory Bus (usually PCIe) step 5: now we unwind back to userspace (with a context-switch) and want to actually run something (OpenGL call) step 6: the OpenGL call (or Vulkan) gets some function call parameters and some data step 7: the userspace library (MESA) "packs" (marshalls) those function call parameters into serialised data step 8: the userspace library triggers the linux (windows) kernel to "upload" the serialised function call parameters - again over Shared Memory Bus step 9: the kernel waits for that to happen step 10: the userspace proceeds (after a context-switch) and waits for notification that the function call has completed... ... i'm not going to bother filling in the rest of the details, you get the general idea that this is completely insane and goes a long way towards explaining why GPU Cards are so expensive and why it takes YEARS to reverse-engineer GPU drivers. in the Libre-SOC architecture - which is termed a "Hybrid" one, the following happens: step 1: the compiler is fired up (in userspace, just like above) step 2: compiler takes the shader IR and turns it into *NATIVE* (Power ISA with Cray-style Vectors and some custom opcodes) assembler step 3: userspace program JIT EXECUTES THAT BINARY NATIVELY RIGHT THERE RIGHT THEN done. did you see any kernel context-switches in that simple 3-step process? that's because there aren't any needed. now, the thing is - answering your question a bit more - that "just having vector capabilities" is nowhere near enough. the lesson has been learned from Nyuzi, Larrabee, and others: if you simply create a high-performance general-purpoes Vector ISA, you have successfully created something that absolutely sucks at GPU workloads: about TWENTY FIVE PERCENT (one quarter) of the capability of a modern GPU for the same power consumption. therefore, you need to add SIN, COS, ATAN2, LOG2, and other opcodes, but you need to add them with "reduced accuracy" (like, only 12 bit or so) because that's all that's needed for 3D. you need to add Texture caches, and Texture interpolation opcodes (takes 4 pixels @ 00 01 10 11 square coordinates, plus two FP XY numbers between 0.0 and 1.0, and interpolates the pixels in 2D). you need to add YUV2RGB and other pixel-format-conversion opcodes that are in the Vulkan Specification... and many more. but, we first had to actually, like, y'know, have a core that can actually execute instructions at all? :) and that's what this first Test ASIC is: a first step.