Can We Replace Intel x86 With an Open Source Chip? (zdnet.com)

An anonymous reader quotes Jason Perlow, the senior technology editor at ZDNet: Perhaps the Meltdown and Spectre bugs are the impetus for making long-overdue changes to the core DNA of the semiconductor industry and how chip architectures are designed... Linux (and other related FOSS tech that forms the overall stack) is now a mainstream operating system that forms the basis of public cloud infrastructure and the foundational software technology in mobile and Internet of Things (IoT)... We need to develop a modern equivalent of an OpenSPARC that any processor foundry can build upon without licensing of IP, in order to drive down the costs of building microprocessors at immense scale for the cloud, for mobile and the IoT. It makes the $200 smartphone as well as hyperscale datacenter lifecycle management that much more viable and cost-effective.

Just as Linux and open source transformed how we view operating systems and application software, we need the equivalent for microprocessors in order to move out of the private datacenter rife with these legacy issues and into the green field of the cloud... The fact that we have these software technologies that now enable us to easily abstract from the chip hardware enables us to correct and improve the chips through community efforts as needs arise... We need to stop thinking about microprocessor systems' architectures as these licensed things that are developed in secrecy by mega-companies like Intel or AMD or even ARM... The reality is that we now need to create something new, free from any legacy entities and baggage that has been driving the industry and dragging it down the past 40 years. Just as was done with Linux.
The bigger question is which chip should take its place. "I don't see ARM donating its IP to this effort, and I think OpenSPARC may not be it either. Perhaps IBM OpenPOWER? It would certainly be a nice gesture of Big Blue to open their specification up further without any additional licensing, and it would help to maintain and establish the company's relevancy in the cloud going forward.

"RISC-V, which is being developed by UC Berkeley, is completely Open Source."

Comments

No

[Anonymous Coward]

No

Re:No

[DontBeAMoran]

The same people who paid to develop Linux, Red Hat, etc?

Re:No

[swamp_ig]

IC design isn't something you can do in your spare time. You need a full-scale industrial process.

Re:No

[K. S. Kyosuke]

IC design isn't something you can do in your spare time. You need a full-scale industrial process.

You mean IC manufacturing? I'm pretty sure design is largely independent. If it weren't, ARM wouldn't be able to sell synthesizable CPU cores.

Re:No

[Rick Schumann]

Exactly. Also good luck with trying to 'open source' 10nm die fabrication.

Re:No

[toonces33]

Just 3-d print the things.

Re:No

[K. S. Kyosuke]

That's technically what the fabs are doing, though.

Re:No

[sanf780]

ARM does sell synthesizable cores. What synthesizable means is that you can convert that code into logic gates. So you need at least a standard cell library with the fine detail of those logic gates. Memories are not included, as memories are not synthesizable code if you really want a high bit density and low power usage. In order to get data in and out of the chip, you will also need a DDR interface (this is not synthesizable) with also a DDR memory controller (this one is). Add to this one that you need to generate internal clocks, so you might also want to get a few phase locked loop blocks. Recent CPUs also include some sort of dynamic voltage scaling, frequency scaling, thermal protection, etc. You also want to have peripherals connected through SPI, I2C, maybe UART, and maybe you want an interconnect fabric so that the CPU can talk to them. I am sure I am missing a lot of these things.

So, it is not just the CPU core, you need a lot more of things in order to get some product. FPGA manufacturers give you both the hardware and the software to translate the code into something you can upload to that FPGA, and usually give you some freebies like DDR and PLLs. However, there are limitations on what you can get from an FPGA. ICs are the way to go if you want to be on the bleeding edge on either performance, price or power efficiency. And as far as I know, the tools to do ICs in advanced processes like 10nm are not either free to use or open source. They are probably also a patent field. At the end of the day, you do not want to spend over one million dollars with tools that tell you "USE AT YOUR OWN RISK".

Re:No

[phantomfive]

I know a guy whose entire job is to build clocks in CPUs. That's all he does. He's really good at it.
I mention that to give you an idea of the specialization that has taken place in the hardware industry. In Software, you can still be a full-stack developer. In Hardware, those days are past.

Re:No

[Pulzar]

Clock guys are like driver guys... the stuff they write and develop is quite a bit different from everything else.

The guys who work on caches, decode, fetch, etc. are all fairly interchangeable, if you've got a good architect to direct and oversee the work.

Re:No

[TooManyNames]

Yeah, no. That's very, very wrong.

Much of a processor can be designed in RTL (the type of code you could open source), but there are critical components (as in, CPUs do not function without them -- at all) that require detailed knowledge of the underlying process. Any sort of clock distribution, selection, skewing, or balancing, for example, pretty much requires not only detailed knowledge of the types of gates available in process libraries, but also exhaustive simulations across all kinds of different timing scenarios to ensure that designs work as intended. Additionally, these types of circuits are not trivial to design, and they're often tightly integrated into the rest of a design in a way that isn't exactly modular (as in, even if there are separate clocking modules, design assumptions make removal or modifications of those clocking modules quite difficult).

Maybe you could get away with an open core on an FPGA, but if you do that, you're going to sacrifice a lot in terms of performance -- as in getting at best into the 100s of MHz range compared to GHz for an ASIC. Moreover, you're not going to squeeze multiple cores and huge caches onto a single FPGA, so you'll need some sort of stitching to get anything even remotely close to your most basic Intel off-the-shelf processor.

Basically the best you'll be able to say with a purely open source CPU is, "buy this for 10x the cost and at 1/10th the performance... but you can feel good that it's open source." At that point, all I can say is, "good luck with that."

Re:No

[NicknameUnavailable]

You mean IC manufacturing? I'm pretty sure design is largely independent.

Well, I'm pretty sure you're an idiot. I also know only one of us is right in our certainty. Chips average about a million dollars per prototype run. You can simulate things and have them work flawlessly, but you still have to manufacture a masks, run through the steps of chip fabrication, then do your tests to see if it even remotely works. On the scale of GHz with nanometers of precision things happen like inductive and capacitive effects you can't properly simulate but will utterly fuck over your design. All of hardware development is like that, and there is very little open source hardware (depending on your quality standards you might even argue there is none.) IC design is the apex of painfully-expensive-hardware-design.

Re:No

[malditaenvidia]

What are the odds of IBM giving away POWER? Is the architecture susceptible to the same vulnerabilities?

Re:No

[Anonymous Coward]

I knew a guy who's entire job for over a year at HP was to *route* the clock signal across a single chip (this was on the Superdome chipset).

Yes, anyone can design the basic ISA logic of a chip. But it takes *huge* teams of people to design a *good* chip with all the modern features that we seem to take for granted such as variable clock and power states, or even more complicated letting them vary across different portions of the same chip. Not to mention coordinating the design and validating the DRC against the manufacturing process.

There's a really good reason that CPU chip design is only done these days by a very small handful of billion dollar companies with billion dollar budgets. These designs are very complicated and it's no wonder that they keep the IP--they've invested a *lot* to develop it.

Trivializing it by suggesting that an open source development model could equal or best these products is a tad naive. Unless we were living in a Star Trek economy and there were a few thousand contributors working on it full-time (the same size workforce as these big vendors), I don't see any chance of a competitive result.

Re:No

[thegreatbob]

As I don't think it has been mentioned in this thread, AMD has been fabless for the better part of a decade.

Re:No

[lkcl]

You mean IC manufacturing? I'm pretty sure design is largely independent. If it weren't, ARM wouldn't be able to sell synthesizable CPU cores.

in a traditional environment it takes around 18 man-months to design (and formally test) around 3,000 gates. it's pretty insane. 3,000 gates is about the size of a RISC Core. look up the numbers for an Intel processor (number of transistors - yes many of those are in the cache) - and you get an idea of just how much work is involved.

also, the actual layout (like a PCB only for transistors and tracks etc.) by automated tools tend to be... well... rubbish, basically. which means that much of the design has to be done by hand, with assistance from tools to assess things like parasitic capacitance (so that you can minimise it... by hand).

it's not a straightforward process, basically.

Re:No

[religionofpeas]

It's certainly possible to design a CPU in your spare time. I've designed a couple myself.

Designing a modern Intel CPU replacement is something else though. That's a lot of man years of work, and most of it is in tedious work like testing and validating that very few people find joyful.

Re:No

[AmiMoJo]

Maybe we don't need to replace the main CPU, just add a second one that handles secure stuff for us. Performance doesn't need to be as good if it is only managing secrets and does some crypto, i.e. the stuff we are worried about being stolen.

That's basically what a lot of these CPUs do anyway, with things like TrustZone and Intel's management engine stuff. The difference will be that it's under our control.

Re:No

[K. S. Kyosuke]

I've commented on it above. Yes, as you go down, you need process details. A nasty part of that is that unlike in the past, fewer and fewer details of the physical processes are openly available to begin with. That's the one obvious obstacle to any kind of independent design. I'm not sure how far one can go with independent design rules these days.

Re:No

[TechyImmigrant]

>And yet, this whole guy might have been avoided by employing something like asynchronous logic.

No, no and no again.
Asynchronous logic looks great on paper. It is not great in silicon. It's been tried many times and everyone who tries concludes it's not just the lack of tools - It's that async logic is not a tractable solution. It will always be slower and bigger than synchronous. It's impossible to validate.

Modern CPUs are synchronous islands in an async fabric. This is normal and is a good engineering tradeoff.

Not sure what you mean by that

[squiggleslash]

OpenSPARC is open source, the entire reason for the existence of that word was to brand Sun's open-source SPARC project. So, given it's a relatively mature and respected design, you could definitely use OpenSPARC as the basis of an open source CPU design.

The question is really whether the OS hardware community is actually likely to produce something comparable to Intel or AMD, even given a start with the SPARC design. I... don't want to say it's impossible, but it certainly seems somewhat more difficult than producing a better operating system than Microsoft can.

Re:Not sure what you mean by that

[therealspacebug]

How is OpenSPARC vs RISC-V?

I really hope we get one open hardware taking off.

It does not have to replace the existing arcitechtures but could act as a suppliment.

Many people would like something more open now after all ME bugs etc.
Specially in the INFOSEC community and like.

Re:Not sure what you mean by that

[OrangeTide]

RISC-V's specification is a lot more flexible and permits a wider range of variants on capabilities in implementations than OpenSPARC. I've worked on 32-bit RISC-V based microcontrollers embedded in ASICs, and theoretically you can put together a multiprocessor 64-bit RISC-V with advanced features such as speculative execution.

I think that RISC-V has a pretty good future because it is a specification rather than a single implementation. There are multiple implementations, some of them are open source. And it can cover a broad enough range of needs to suit multiple industries. For research RISC-V is interesting because how to add extension instructions to it is well defined and the toolchain is easy to set up with your custom extensions.

Re:Not sure what you mean by that

[TheRaven64]

You can't compare OpenSPARC and RISC-V. OpenSPARC is an implementation of the SPARCv9 ISA. RISC-V is a specification. There are about a dozen open source RISC-V designs now, ranging from simple in-order 32-bit cores to out-of-order superscalar 64-bit cores.

OpenSPARC is the full Verilog implementation of T1 (Niagara) and T2. Unfortunately, both are written in the traditional disposable style of commercial CPU implementations: there are some reusable building blocks, but the general idea is that each CPU design is a complete from-scratch rewrite. Unlike software designs, there's no thought to long-term maintenance or making the designs easier to refactor. Such concerns are often at odds with getting the best possible performance from the current process (the next generation process may have completely different constraints).

In contrast, the reference RISC-V design, Rocket, is written in Chisel, a high-level Scala-derived HDL that can generate Verilog. It is designed to be used to be reusable and this was shown by the Berkeley Out-of-Order Machine (BOOM), which is an out-of-order superscalar design that reuses most of the Rocket core's execution units.

If you just want to send something to a fab now, the OpenSPARC cores are probably better, but if you want to make significant modifications then Rocket or BOOM is orders of magnitude easier to work with. In addition, the RISC-V ecosystem is growing, whereas the SPARC ecosystem is contracting or dead.

Of course we can!

[cheesyweasel]

What version of DOS would you like to run on it?

How does an open source chip solve the problem?

[JoeyRox]

Being open source doesn't magically prevent bugs from reaching the silicon stage of a chip's design, nor does it make it any easier to fix bugs baked into a completed design. There are only so many people in the world smart enough to even fully understand modern superscalar designs let alone contribute usefully to it.

Re:How does an open source chip solve the problem?

[Nemyst]

Itanium handles speculation so differently that it's unlikely to be vulnerable. IBM has released an advisory indicating that Power7+/8/9 are vulnerable to some extent (they don't distinguish between Meltdown and Spectre) and that patches would be rolling out soon.

Re:How does an open source chip solve the problem?

[lkcl]

Being open source doesn't magically prevent bugs from reaching the silicon stage of a chip's design, nor does it make it any easier to fix bugs baked into a completed design. There are only so many people in the world smart enough to even fully understand modern superscalar designs let alone contribute usefully to it.

interestingly the head of the shakti team, madhu, is an advocate of something called "bluespec". it's similar to Berkeley's "chisel" except that, because bluespec is writteen in Haskell it's possible to do *formal mathematical proofs on the designs*.

there was a talk at ccc just last week about doing mathematical proofs on designs, but it's much harder to do if the underlying programming language for the ASIC doesn't really support formal proofs.

anyway, this is extremely interesting timing as i am, puzzlingly, in a position to be the go-between to actually get this done http://rhombus-tech.net/riscv/...

Power9 is a pretty good candidate

[Anonymous Coward]

Yes, look at IBM's Power9-based Talos Workstation. It has open firmware, open microcode, open BMC firmware so pretty much all of it is auditable. Is it secure? Who knows...

The downside is obviously the price.

Repositories:
https://git.raptorcs.com/git/
https://github.com/open-power
https://github.com/openbmc

No

[Anonymous Coward]

Figure out some way to fund the billions in development costs, legal/IP issues and marshal the necessary talent then maybe... Of course, there is no reason to believe the result would be any better: RISC-V memory model has severe problems due to underspecified memory ordering that were revealed by formal testing and are still being resolved. Perhaps this is an example of an open process working well, but just throwing out RISC-V doesn't guarantee a bug free design.

To what end?

[Anonymous Coward]

OpenSSL being open source didnâ(TM)t find or prevent Heartbleed.

An open chip likely wouldnâ(TM)t have affected meltdown or spectre. This wasnâ(TM)t negligence by Intel (as evidenced that some of the recent vulnerabilities were shared by AMD chips on a completely different architecture.

The problem isnâ(TM)t that Intel failed to secure something obvious. Itâ(TM)s that there was a mechanism that everyone knew about, but which all experts thought couldnâ(TM)t be used to extract data. Then someone found a clever technique nobody thought of before that made everyone realize it WAS vulnerable.

Being open wouldnâ(TM)t have prevented the issue. Indeed, the issue was found by third-party researchers who didnâ(TM)t have access to the low level details of the architecture.

Open Source is not a panacea.

Re:To what end?

[Bing Tsher E]

We don't want Slashdot to fix that. It's a stupid-shit issue, an example of Apple arrogance. The people spilling those characters into their comments are like the dude with the hunk of toilet paper dragging along on the back of his shoe. It's good to know who he is, so you can avoid shaking his hand, unless you're wearing rubber gloves.

What a dumb idea!

[GerryGilmore]

Is it technically possible? Sure, there are already open-source core designs available. All you have to do is come up with the hundreds of thousands of engineers, designers, and manufacturing experts, replicate about 40 years of legacy toolchains from basic compilers to OSes, languages and frameworks, add in a smidgen of semi-conductor factories, testing facilities and packaging support. Oh! Did I mention sales and marketing? Go right-da-fuck ahead!

Funny you should ask

[fustakrakich]

I was just asking about that in a previous thread. So, if MIPS is really unchained by patents etc, then we might have a chance.

Re:Simpler solution would be

[darthsilun]

AMD chips have their own security flaw[1].

Surprising that it hasn't been reported here yet.

It's apparently easier to fix than Intel's.

[1] http://www.theregister.co.uk/2...

uninformed

[sdinfoserv]

A fairly unthoughtful, knee jerk reaction from someone who is clearly no more involved in technology than being a writer.
Bugs happen. Everywhere on every layer. Save your outrage for true malfeasance. Get angry at Feds for storing FS86 forms (the questionnaire for top secret clearance) on OPM servers unencrypted. Get angry at Equifax management for making the conscious, criminally liable decision, of storing PIN of pretty much every US tax payer “in the clear” at rest.
But for bugs that take years or generational development and understanding to discover, it’s unavoidable.
And certainly don’t suggest replacing it with a questionably supportable ecosystem. Linux, despite global usage, outside of a few niche hardcore users has completely failed on the desktop. (I know he didn’t specifically say Linux, but it’s an example of an attempt at global open source) Not a tolerable trajectory for hardware manufacture, let alone one that already represents market majority.

Just one way to get everything you want

[Bruce Perens]

If you really want an Open Source, after-market bug fixes, and security, the best way to do that is to use not a CPU at all but a programmable gate-array. This also gives you the ability to have evolution in purchased hardware, for example improvement of the instruction set. The problem is finding a gate-array that is fast enough, dense enough, and power-conserving enough.

It would be cool to code your own special-purpose algorithm accelerators in VHDL or Verilog, etc.

This is sort of on the edge of practical, if you have the money to spend. Not as fast, not as powerful, uses more electricity, infinitely flexible. Certainly there would be some good research papers, etc., in building one.

Oh Really

[Bruce Perens]

Thank you for this vast work of erudition, anonymous moron.

Someday, perhaps, when you are a pre-adolescent, you may aquire somewhat more knowledge of computers, though probably not enough to make you top-heavy. At that time, you may hear of a miraculous device called a gate-array which makes it possible to craft a running CPU similarly to the way that programmers write software. With this device, someone of greater skill than you will put together a computer that might not be as fast as you like, and might not have as many transistors as you like, and might use more power than you like, but will be capable of running an Open Source CPU with a known-bitstream so that the chance of there being nasties that we're not told about that spy on us built into the CPU die is reduced from today's horrible state (gate-arrays can still have them, but the people who make these nasties don't know in advance where we put the CPU implementation).

The instruction set and currently-fixed hardware features like the MMU and the translation look-aside buffer (a feature implicated today) will be repairable by changing the bitstream.

This will never be as efficient as a fully-custom chip, but it can be good enough. Many of us will be happier using it. And for those of us who require algorithm acceleration (hopefully for better reasons than mining cryptocoins, but that is one example) it will be possible to code it into the system and get the advantages of a hardware implementation without it being so hard.

Re:Oh Really

[phantomfive]

This will never be as efficient as a fully-custom chip, but it can be good enough. Many of us will be happier using it.

This is a good point: people who care about security (like AWS) have different requirements, and may be willing to forgo some performance in exchange for security.

Re:Oh Really

[Bruce Perens]

Unfortunately, as you well know, this approach means goodbye to virtually very computing-type device most of us have become accustomed-to.

Maybe you haven't been following gate-array development. There are mobile ones now. They use FLASH to store the program bits. And the rest is CMOS which we know how to power-manage. The gate-arrays of yore were more power-thirsty because nobody cared back then.

Re: Oh Really

[Bruce Perens]

I doubt that open source hardware would prevent hardware bugs, but it would provide a way of avoiding backdoors that are intentionally placed. You're absolutely right in that respect.

Use of gate-arrays would make the bugs reprogrammable. And now that we have mobile gate-arrays, performance is actually getting pretty good.

Re:Oh Really

[Bruce Perens]

t Raspberry Pi, while not exactly open source, is pretty close, and it's available now. Feel free to trick that out and use it as your primary workstation.

I do have some issues with documentation. Have they now documented the GPU (or whatever it is) that first has control at boot time, before the main CPU is enabled? I'd also like to use the LVDS for an SDR rather than the camera and display, and that was not documented either the last time I looked. There was also some chat about additional entirely undocumented coprocessors on the die.

Re:Oh Really

[Bruce Perens]

Sorry, Bruce, sarcasm is in our DNA here, and that goes for numbered users as well as ACs.

Actually, you are perpetuating the naive assumption that Anonymous Cowards are human beings who have feelings. Not so. Anonymous Cowards are actually alien beings from a planet orbiting the star Beta Anonyma. They emigrated to Middle America and have been posing as real people, having destroyed their own planet through bad political policy. Although they have developed a society nearly as intelligent as ours (not quite as intelligent, they are actually the cause of the Red States Mystery), they do not have feelings, they are thoughtless automations who have been programmed to believe that they are alive and have feelings, which they volubly protest while in fact being entirely without consciousness. Also, no matter how many Anonymous Cowards you meet, they are all one individual.

Re: Oh Really

[Bing Tsher E]

That is something really worth championing, but it's also a dragon den of proprietary technology. The FPGA vendors are cut-throat competitive about this stuff. The tool-sets to program FPGAs are always behind restrictive walls. I have a tool-chain I downloaded and a Mojo board to go with the new O'Reilly Learning FPGAbook I bought, but so far I've been standoffish about getting into it, because it's one of those 'keyed software' things.

I have never been keen to install software on my machine that requires me to 'phone home' to unlock it. What if I grow dependent on it and they decide I haven't kissed the proper ring?

Uh, ZDNet? Really?

[asackett]

It's not surprising that someone who doesn't seem to know that "the cloud" *is* private data centers also knows nothing of IC fab.

Re:Not unless the FPGA/Fab process is also Open...

[willy_me]

What is heck "Distributed Memory"?

Distributed memory is just that - memory distributed along side the LUT/FF elements. Using this memory "consumes" some LUTs but it is far more efficient then 1 bit per LUT. See the following quote from the MachXO3 datasheet - note that a Slice has 2 LUTs and 2 FFs, 4 Slices per PFU block.

RAM Mode

In this mode, a 16x4-bit distributed single port RAM (SPR) can be constructed by using each LUT block in Slice 0 and Slice 1 as a 16x1-bit memory. Slice 2 is used to provide memory address and control signals.

All from 1 PFU block. And this is why a device with 640 LUTs can provide 5K of memory.

MachXO3 Family Data Sheet

Re: No?

[VernonNemitz]

Before you design a core, you need to specify an assembly-language instruction set. Here is one, with main features of 64-bit addressing and 128-bit data-processing registers (and 128 bits of data at every single address, instead of 8), which was declared Public Domain (last paragraph) back in 2001. Ahead of its time, it is now easily possible to build, and perhaps, because of progress in inventing new instructions since that time, should be upgraded to 256-bit data-processing (while still using 64-bit addressing, because we can expect to not need more than that for a couple more decades). Enjoy!

Re:Look at the introduction date for CPUs

[TheRaven64]

It's also more difficult for an open source design. CPU makers generally don't bother too much patenting microarchitectural features, because it's very expensive to stick a competitor's chip under an electron microscope and get enough evidence to convince a court that it's actually infringing. For an open source design, you have access at least to the RTL and so can see very easily and cheaply whether it's infringing. If you wait until your competitor has taped out before sending your C&D, you can maximise their costs.

Re:Nice

[TheRaven64]

Proof of correctness is elusive, because it first requires that you specify what 'correctness' means. Processors vulnerable to this would have passed formal verification until recently, because processor vendors explicitly did not consider side channels to be easily exploitable. Now people are scrambling to add things like 'speculative execution must not change any observable aspects of microarchitectural state' to their specs. That's easy to write in English, but defining what 'observable aspects of microarchitectural state' are in a formal specification is really hard (particularly given that temporal aspects are really hard to talk about at all in most existing specification languages). That said, I'm collaborating with a group that is working on some of this.

seL4 (not L4) is actually a really good example. It was about 6 hours between the release of the formally verified microkernel and the first exploit being released. The implementation was correct with regard to the specification, but the specification didn't account for everything. It's worth remembering that Goedel's Incompleteness Theorem basically tells you that this kind of verification is impossible: a sufficiently detailed specification of what 'correct' means will, for any nontrivial system, be more complex than the implementation and must itself be correct for the proof to be useful.