Toward An FSF-Endorsable Embedded Processor

lkcl writes about his effort to go further than others have, and actually have a processor designed for Free Software manufactured: "A new processor is being put together — one that is FSF Endorseable, contains no proprietary hardware engines, yet an 800MHz 8-core version would, at 38 GFLOPS, be powerful enough on raw GFLOPS performance figures to take on the 3ghz AMD Phenom II x4 940, the 3GHz Intel i7 920 and other respectable mid-range 100 Watt CPUs. The difference is: power consumption in 40nm for an 8-core version would be under 3 watts. The core design has been proven in 65nm, and is based on a hybrid approach, with its general-purpose instruction set being designed from the ground up to help accelerate 3D Graphics and Video Encode and Decode, an 8-core 800mhz version would be capable of 1080p30 H.264 decode, and have peak 3D rates of 320 million triangles/sec and a peak fill rate of 1600 million pixels/sec. The unusual step in the processor world is being taken to solicit input from the Free Software Community at large before going ahead with putting the chip together. So have at it: if given carte blanche, what interfaces and what features would you like an FSF-Endorseable mass-volume processor to have? (Please don't say 'DRM' or 'built-in spyware')." There's some discussion on arm-netbook. This is the guy behind the first EOMA-68 card (currently nearing production). As a heads ups, we'll be interviewing him in a live style similarly to Woz (although intentionally this time) next Tuesday.

Comments

Scientific Computing

[simonbp]

IMHO, they really need to push this for scientific computing initially, as they tend to buy in bulk and are not very binary dependant. They are claiming it is so low power (2.7 W) that it would be easy to put an array, say, eight of them on a 1U motherboard for 64 cores.

just a little skeptical of those numbers

[dywolf]

ok more than a little.

Re:x86 - NOT!!!!!

[fnj]

I couldn't care less if it is x86 compatible (I assume it is emphatically not). I'm sure the FSF does not care, either. I would use this in a heartbeat for my main desktop, and since I haven't had any significant dealings with Windows in at least 8 years, all I need is a free Posix OS (probably linux) and a C/C++ compiler.

Those performance numbers are BS

[CajunArson]

Those performance numbers are pure fantasy. First off, the 38 GFlops is undoubtedly referring to single precision operations while the x86 processors mentioned in TFS are doing that much in *double* precision mode. Second off, the 38 GFlop number is a simple arithmetic estimate of what the magic chip could do IFF every functional unit on the chip operated at 100% perfect efficiency. Guess what: a real memory controller that could keep the chip fed with data at that rate will use > 3 watts all by itself. This chip won't have a real memory controller though, so you can bet the 38 GFlop performance will remain a nice fairytale instead of a real product.

Re:Those performance numbers are BS

[AdamHaun]

Forget the performance numbers, the whole thing is bullshit:

* The proposal is dated December 2, 2012 for an advanced kitchen sink SoC with silicon in July 2013? Really?

* Their never released to market CPU design that beats an ARM on one video decoding benchmark is ready to go, except they need to move it to a new process, double the number of cores, and speed it up by 30%. Trivial, I'm sure.

* This bit here:

What's the next step?

Find investors! We need to move quickly: there's an opportunity to hit
Christmas sales if the processor is ready by July 2013. This should be
possible to achieve if the engineers start NOW (because the design's
already done and proven: it's a matter of bolting on the modern interfaces,
compiling for FPGA to make sure it works, then running verification etc.
No actual "design" work is needed).

The design is done! They just have to, you know, grab their perfectly-working peripheral IPs from unstated sources, "bolt them on" to their heavily-modified CPU, and then compile for FPGA. And maybe some timing simulations for their new 40nm process, but I'm sure that won't turn up any problems. And "verification, etc." (aka the part where you actually make it work). And fixing any problems found in silicon. But no *actual* design work is needed.

I have spent the last three months in my day job on a team of a dozen people writing design verification test cases for a new SoC. Fuck you for talking like that's nothing.

* They're going to hit "Christmas sales"? So despite being a real honest for-profit multi-million-selling product, we swear, they're still targeting a consumer shopping season. Hint: you want your chip to go into other products. Products sold at Christmas time are designed long before Christmas. Probably more than six months before, i.e. July 2013. Oops.

* No mention of post-silicon testing, reliability studies, or even whether they've got a test facility lined up, or what kind of resources they need for long-term support. I said it when OpenCores pulled this crap, and I'll say it again. Hardware is not software. You have to think about this stuff. Yield and reliability are what determine whether other companies buy your stuff and whether you make money from it.

Let me offer some advice to anyone who wants to change the semiconductor world overnight with the magic of open source: start small. Really small. Even Linus Torvalds didn't start out planning to conquer the world. Maybe you could start by trying to get open source IP blocks into commercial products. Once there's a bench of solid, field-tested designs, *then* we can talk about funding an attempt to put it all together. But coming out of nowhere and asking for $10 million is not the way to start. Just ask OpenCores -- their big donation drive got them a grand total of $20 thousand.

Re:Those performance numbers are BS

[AdamHaun]

pay attention 007: we're aiming for mid-2013

Yes, that's what I said:

* The proposal is dated December 2, 2012 for an advanced kitchen sink SoC with silicon in July 2013? Really?

Perhaps my phrasing was unclear. I am skeptical of a six-month development process.

also, bear in mind: the core design's already proven.

By who? To what specs (temperature, voltage, operating life)? Using what methodology?

mid-2013, whilst pretty aggressive, is doable *SO LONG AS* we *DO NOT* do any "design" work. just building-blocks, stack them together, run the verification tools, run it in FPGAs to check it works, run the verification tools again... etc. etc.

You know you can't go straight from RTL to silicon, right? You need timing sims and physical layout. Those are not trivial and they cannot be totally automated.

the teams we're working with know what they're doing. me? i have no clue, and am quite happy not knowing: this is waaay beyond my expertise level and time to learn.

Okay, here's the part that confuses me. You came up with an idea, talked to other people with expertise about doing it, and it sounds like you know who's working on it. All of that is fine. What I don't understand is why you are acting as the leader/spokesman for a project you know almost nothing about. Who are these other groups? The link at the bottom of your proposal is to a no-name Chinese semiconductor company that formed last year and has no products listed. Are they doing the RTL, layout, and verification? Who's doing the silicon testing? What foundry will you use?

The reason I'm being so harsh here is because you're asking for a lot of money with very little credibility. There is nothing in your proposal, your CV, or your comments to suggest that you are competent to work on a project like this. So who's doing the work? Why aren't their names on the proposal? Who has the experience and leadership to make sure the project actually gets done? Why are you "quite happy not knowing" what they're doing when you're the one trying to secure funding?

If you come back here in 2013 with a working chip I'll be the first to apologize, but right now I see very little reason to take this seriously.

Re:Feature Requests, Now that you asked

[lkcl]

"So have at it: if given carte blanche, what interfaces and what features would you like an FSF-Endorseable mass-volume processor to have?"

thank you for taking me literally! really appreciated!

Standard size chip socket, with adapter springs and guides for using off the shelf cooling implements (like zalman fans, and watercooling), for other CPUs.

ah. this is going to be a 15mm x 15mm BGA with only around 320 pins. it's tiny. ok, that might have to be revisited now that i thought about doing an 8-core monster - 3 watts in a 15 x 15mm package is hellishly hot.
i'm still debating whether it should have dual 32-bit DDR3 lanes. even so, that only adds an extra... 75 or so pins, bringing it up maybe to 19 x 19 mm.

need PCI and PCI express, prefrably at least 24 lanes, hopefully as many as 48 lanes.

ahhh... PCI express is a bug-bear. that many lanes would, on their own, turn this into a 12 to 30 watt part: right now we're aiming for a different market. i'm happy to be steered in a different direction if it can be shown that it's a genuinely good idea, with a high chance of return on investment.

Behind this, fast northside/southside busses to keepup with the following, I think AMD open sourced hypertransport, so front side bussing should not be an issue.

ah this is an embedded processor: they don't have northbridge/southbridge buses [at all]. those are reserved for CPUs at the 10+ watt market.

If your still mulling over instruction set, a built in crypto proccessing chip would ROCK. implement intels AES-NI or something similar, plus more for twofish, serpent, and other fairly mainstream modern, unbroken Free/Open encryption algorythms. Then add hash instructions for the entire SHA family of hashes, MD6, whirlpool, tiger, RIPMED, and GOST

ok - this is a general-purpose processor that *happens* to have been designed to be capable of doing a GPU and a VPU's job. hmmm... i wonder whether their instruction set can do crypto primitives.. hmmm.... yeah, that's a great question to ask. i'll get back to you on that.

GOOD USB 3 support, with legacy suppoequivsrt for 1 and 2. Not only do I want some ports on the back, I want at least 3-4 banks of header pins on a theorhetical motherboard for front panel devices and ports. They shtheorheticalould be USB 1,2,3. Solid high speed memory controller at a preimium.

definitely going to have 1x USB-OTG, probably 2x USB2-HOST, and at least one USB-3.

Universial SATA support for revisions 1,2 and 3 (1.5GB/s 3.0 GB/s and 6.0 GBs respectively), built in RAID controller. eSATA would help too.

i'm reluctant to push this IC towards 6gb/sec - it'd be by far and above the fastest bit of I/O on the chip. RAID i'd be concerned about pushing up the cost for the mass-volume uses [which wouldn't use it]. eSATA is _great_. i'd forgotten about that.

scalable audio chipset capable of up to 8.1 surround, Stereo input, SPID/F and all the other great audio features.

SPDIF - i'd not *entirely* forgotten about that - will remember to make a mental note. audio i would like to rely on the processor itself for that sort of thing (for basic audio - headphones and the like), otherwise handing off to a standard I2S/AC97 audio IC for cases where people really want more complex audio. there are 3 I2S interfaces i think.

so, yeah - i want audio to be done more like the TI McBSP. DMA-driven, but use the main processor for audio handling. keep it simple.

DDR3 RAM, or something comparable.

already done. 1333mhz. bit concerned personally about the power consumption of 1333mhz, i know that 800mhz is about 0.3 watts for example: 1333mhz is starting to get to 1 maybe 1.5 watts all on its own!

Unlocked bootloader with firmware m

Re:No thanks

[Anonymous Coward]

Yes, we can move away from x86.
No, it isn't a good idea.

It's time to put this one to rest.
It's been a few decades and we've seen the argument from theory, practice, and to conclusion today.

x86(and it's er.. extension/evolutions) IS the better general purpose arch. But not for the reasons anyone conceived of. I think it's best put this way.

1. RISC(for example) very good at running good code.
2. Most code is bad. (No really, it's awful. Ask any programmer)
3. x86 processors, it turns out, are very good at running bad code.

Many other arches were created under the premise that good code could be created for them automatically. Turns out that compilers that can do this are like unicorns. They don't exist. It's an np-hard problem.

It's what killed itanium. The magic compilers never turned up. The amount of developer effort required to write good software isn't worth it.

*Why is most code bad you ask? Easy. Programming, put crudely, is a bullshit art.
Just ask Dijkstra (Well not anymore. He's dead now) Programs are math. Few programs, however, are proven to be "correct" mathmatically. - It's impractical for most applications. Sure, you have rules you call "Practices" that tend to generate better code.. But everyone knows how code is really developed nowadays. Lay it down, slap it around until the show stoppers are reduced to a bearable frequency, and patch up anything you missed after it ships.

I'm not saying this approach is necessarily bad. It has advantages. It's very fast! It's fast, and you can get a lot of useful work out of it. If your idea or application is good or novel or productive enough you can put up with some bugs and at the end of the day you'll end up ahead. - If you set out to write a program that's mathematically prove-able from start to finish.. Your competitors will have buried you years before your first release.