×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Toward An FSF-Endorsable Embedded Processor

Unknown Lamer posted about a year ago | from the building-rms-a-new-computer dept.

Hardware Hacking 258

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

258 comments

built-in TDSSkiller detection and removal (-1)

Anonymous Coward | about a year ago | (#42181927)

Never again deal with the Google redirect virus.......ever

x86 (0)

Kraeloc (869412) | about a year ago | (#42181939)

x86 compatible, that's what I'd like to see! Oh how I love to be able to pickup such a processor and build my main desktop rig with such a beast.

No thanks (4, Interesting)

betterunixthanunix (980855) | about a year ago | (#42182005)

Can we please move away from x86? That architecture is horribly outdated, loaded down with things that sort-of made sense in the 1970s. Today's x86 CPUs are just dressed up RISC machines; let's free up some of that chip space and just use RISC.

If you want to run x86 binaries, use a dynamic translation tool.

Re:No thanks (3, Insightful)

CajunArson (465943) | about a year ago | (#42182073)

Today's ARM architecture is just a dressed up CISC architecture, let's move away from ARM's lame attempts at copying AVX with neon and just use the real thing!

(You see how the door swings both ways there? Trust me, if any architecture designer from the early 1990's were frozen in a block of ice, thawed out today and then shown the ARMv8 ISA, he would never in a million years call it "RISC")

Re:No thanks (-1)

Anonymous Coward | about a year ago | (#42182335)

Today's ARM architecture is just a dressed up CISC architecture, let's move away from ARM's lame attempts at copying AVX with neon and just use the real thing!

(You see how the door swings both ways there? Trust me, if any architecture designer from the early 1990's were frozen in a block of ice, thawed out today and then shown the ARMv8 ISA, he would never in a million years call it "RISC")

ONly a nigger tries to turn the tables like that.

Re:No thanks (2)

K. S. Kyosuke (729550) | about a year ago | (#42182561)

Trust me, if any architecture designer from the early 1990's were frozen in a block of ice, thawed out today and then shown the ARMv8 ISA, he would never in a million years call it "RISC"

That still doesn't make it any less true that it's much more preferable to hang yourself rather than to try to write a performing x86 compiler backend. With ARM? I'm not so sure.

Re:No thanks (2)

VortexCortex (1117377) | about a year ago | (#42182767)

if any architecture designer from the early 1990's were frozen in a block of ice, thawed out today and then shown the ARMv8 ISA, he would never in a million years call it "RISC"

Perhaps not, they'd be dead, yes? However, if instead of frozen in ice they were merely kept alive for two short decades...

Re:No thanks (1)

fnj (64210) | about a year ago | (#42182211)

We pretty much _have_ moved away from x86. It really only lives on in server, desktop and laptop form. Tablets, phones, and appliances are close to 100% non-x86 and vastly outweigh the x86 market in terms of units in service and probably total market value.

Re:No thanks (4, Interesting)

lkcl (517947) | about a year ago | (#42182381)

Can we please move away from x86?

yes please!

That architecture is horribly outdated, loaded down with things that sort-of made sense in the 1970s. Today's x86 CPUs are just dressed up RISC machines; let's free up some of that chip space and just use RISC.

this team have come from the perspective of what makes a good GPU, then turned it into a CPU. it's about as far as you can get from x86 as you can possibly get. luckily they've done the hard part of porting at least one OS (android) so have proven the tools, the compiler, the kernel, everythine.

with linux now being the main OS it's hard for me to even remember that windows and x86 was relevant at one point. not that i'm ruling out the possibility of MS porting windows to this chip: if they want to, that's great: they'll just have to bear in mind that there will be no DRM so they won't be able to lock everyone out.

If you want to run x86 binaries, use a dynamic translation tool.

who was it.... i think it was ICT who put 200 special instructions into the Loongson 2H, which allow it to accelerate-emulate the most common x86 instructions, they got 70% of the main processor speed.

Re:No thanks (1)

UK Boz (755972) | about a year ago | (#42182869)

No to x86, but yes to a standard peripherals BIOS library. I dont want to rewrite all my drivers for the umpteenth time for yet another SOC

Re:x86 - NOT!!!!! (5, Insightful)

fnj (64210) | about a year ago | (#42182063)

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.

Re:x86 - NOT!!!!! (0)

Anonymous Coward | about a year ago | (#42182533)

You also need a text editor for your hosts file!

APK

Re:x86 - NOT!!!!! (4, Funny)

VortexCortex (1117377) | about a year ago | (#42182901)

I need is a free Posix OS (probably linux) and a C/C++ compiler.

You also need a text editor for your hosts file!

Fools. Both of you. A text editor and C compiler are required by POSIX.

Re:x86 - NOT!!!!! (1)

ceoyoyo (59147) | about a year ago | (#42183103)

So you're volunteering to write the compiler, right? And porting Linux to a completely new architecture?

Re:x86 (1)

ipquickly (1562169) | about a year ago | (#42182293)

We are talking about a processor being as open as possible.
Unless you are running proprietary code - (Windows) why would you need x86 compatibility?

Granted there is some software out there that is difficult to port because of its size, complexity or willingness of anyone to put in the effort to make it run on anything but x86.

Re:x86 (1)

erroneus (253617) | about a year ago | (#42182441)

It's beyond time to dump the x86. It was a bad processor from the beginning. I learned Motorola 6809 as my first assembly language processor and then when I went to learn Intel's x86, I was like WTF?! The inconsistent way the instructions and registers were used blew me away and made me appreciate the Motorola way a lot more. But the popularity of the PC kept the processor going and growing. I know things in x86 world have improved some, but it all still maintains that backward compatibility and the CISC legacy.

So it is just about time we introduce new processors and instruction sets. We are in a transitional state right now where computer/data handing is concerned. We are amidst a mobile revolution and all new processors (relatively speaking) are being used... no longer tied to compatibility and stuff like that. Perhaps it is even a little late as ARM is kind of the thing now.

But with various advances and lessons learned in chip and PC architecture, it makes sense that an 800MHz processor could take on a 3GHz processor and kick its butt. Each discrete processor instruction in x86 land still takes several clock cycles to execute. (I know, pipelining and multiple instructions are being processed at all times assembly line style so the effective instructions per cycle is different.) But if you combine current technology and design it from the ground up to do the kinds of things we do today, it would make sense that it would use less power and fewer cycles per instruction. The reason we aren't doing all that well today is that x86 things are crippled into doing things the x86 way because they are still needed to run x86 software.

So, while all other things are changing, why not take the opportunity and update the processor, OS and software along with the style of computing? I know Microsoft's answer is to adapt x86 Wintel into other forms. No one wants this other than Microsoft...

Re:x86 (0)

Anonymous Coward | about a year ago | (#42183071)

Fuck x86! Seriously! Stop clinging to the whole damn reason why everything is still shit, you spineless pathetic loser!

Everything works wonderfully on other architectures. Especially if they are open from the ground up!
Windows is dead soon anyway. (And even MS seems to prefer ARM now.)

On Linux for pretty much everything but very low-level system software and the kernel, the architecture doesn't matter anyway, as that's the compiler's job.

Also, that CPU looks like a beast! One with serious chance so kick some major ass. What crazy person would not be excited about that and go "herp derp, x86, derp herp I have no spine derp derp"?

freedom! (0)

Anonymous Coward | about a year ago | (#42181943)

i would definitely buy this as a simple desktop/server linux computer, finally a platform you can fully trust through openness.

And no proprietary software either (-1, Troll)

ugen (93902) | about a year ago | (#42181953)

If this processor is going to be designed and licensed under GPLv3 - I guess one won't be able to build any license-compatible proprietary software for it either. Curious - but count me out :)

Re:And no proprietary software either (1)

fnj (64210) | about a year ago | (#42182079)

I can't even begin to imagine why you would suppose so.

Re:And no proprietary software either (4, Informative)

lkcl (517947) | about a year ago | (#42182169)

If this processor is going to be designed and licensed under GPLv3 - I guess one won't be able to build any license-compatible proprietary software for it either. Curious - but count me out :)

ah interesting. no, it wouldn't be. i believe there are two separate misunderstandings here.

first: i did actually look some time ago at LEONv..... v2 i think it is, which is LGPL licensed i think by Gaisler Research but the amount of work needed to turn it into a modern GPU/VPU-competitive processor would be too costly. then there is the stuff on http://opencores.org/ [opencores.org] but it's not really ready for prime-time - i've been keeping an eye on the projects there for quite some time [none of them are SMP capable for example]

instead, i kept hunting, spoke to tensilica about their core (which is superb btw!), talked to synopsis about their core (ARC), and even came up with a way to do software-interrupt-driven SMP (yes i ran it by alan cox on LKML!). when this current design popped up, and i saw both its capabilities and that they are willing to respect the GPL regarding the toolchain, i jumped at the chance.

second misunderstanding is over design of *hardware* impacting what *software* it can run. it would be necessary to have a modified version of the GPL, stating "all and any software programs running on this hardware *must* be GPL licensed". the impact that this would have would be extremely problematic, as well as being rather fascist and not in the spirit of free software at all.... and, also, as it would be a modified version of the GPL, it wouldn't *be* the GPL, so could not be FSF-Endorsed.

with that as background, to answer the question directly: this is a proprietary design just like all other proprietary designs, using off-the-shelf completed and *tested* hard macros (including the core processor itself albeit only under the MVP Programme), where there is no restriction of any kind on the software that can be run on that processor, be it free software or proprietary software.

anyone can play, in other words.

Re:And no proprietary software either (1)

Anonymous Coward | about a year ago | (#42182223)

Um, no? It's not like the program is linking with the processor, is it? (there has been a similar discussion regarding GPL bytecode interpreters long ago, as long as it's just the interpreter and not also libraries they're considered separate)

Re:And no proprietary software either (1)

Lonewolf666 (259450) | about a year ago | (#42182351)

With most proprietary software, you won't get the source code at all. You get a binary compiled by the vendor. With a completely new architecture, most software vendors won't bother to support it (that might change if you get to ARM or x86 levels of popularity).

Being compatible with proprietary licenses would be the least of your problems ;-)

DRM (4, Interesting)

queazocotal (915608) | about a year ago | (#42181975)

DRM, in some aspects - trusted computing - can be a positive thing.
My ideal system would have a root key I can set, that without software signed by it, it is a rock.

Re:DRM (1)

Anonymous Coward | about a year ago | (#42182643)

The problem with that is, who owns the key? Hint: Not you.

So we'd really need other mechanisms to ensure the other side is trustworthy, ones that rely on leaving the root key in the hands of the owner of the device. Something more along the lines of a web-of-trust rather than the usual tree hierarchies with some corporation owning the root.

That said, I would like encryption support in this chip. Crypto accelleration for one. Some other ideas that I'd like to mention but are patentable and I don't have the dosh to be the first to file (what utter nonsense that is, but I digress).

Also, the fastest possible context switching to support microkernel operating systems. Fast hardware access delegation to userland. And of course hypervisor support.

Re:DRM (0)

Anonymous Coward | about a year ago | (#42182807)

That's not DRM. That's security. There is a difference.

Re:DRM (1)

VortexCortex (1117377) | about a year ago | (#42182997)

DRM, in some aspects - trusted computing - can be a positive thing. My ideal system would have a root key I can set, that without software signed by it, it is a rock.

No, trusted computing is pointless. Let me explain: Exploits are caused by bugs in your software, even if signed and encrypted if the bugs exist that allow stack smashing or heap pointer overwrites (buffer overruns) then your signed and encrypted "trusted computing" can end up actually being a remote code execution vulnerability. See also: Return oriented programming.

Now perhaps you could brick your machine if the boot sector's been tampered with, but why would an exploit writer bother when they can just re-infect the machine after booting it up? So, If they can't make 100% secure OS's then your Trusted Computing (DRM) is pointless. Ah, but if they COULD make 100% secure OS's then Trusted Computing would be pointless... there wouldn't be any way to exploit it.

What you've got with trusted computing is simply raising the bar for normal folks to get alternate OSs installed, that and severe brain damage.

Re:DRM (0)

Rockoon (1252108) | about a year ago | (#42183119)

but why would an exploit writer bother when they can just re-infect the machine after booting it up?

How are they going to do that if *everything* read from disk during boot is signed?

You don't seem to understand what trusted computing actually means. It does not mean just the boot sector.

It means the bios validates the boot sector, the boot sector validates the kernel, the kernel then has the power to (if constructed properly) validate literally everything else.

One more weapon (0)

Anonymous Coward | about a year ago | (#42181981)

With the moves to put us more and more in walled gardens with tablets, smartphones, game consoles, and TV's we need open hardware. If we are going to keep the freedom we have to run "open" software we need platforms to run it on. Hurray!

Scientific Computing (5, Interesting)

simonbp (412489) | about a year ago | (#42181991)

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.

An almost unbelievable breakthrough if true (2)

fnj (64210) | about a year ago | (#42181997)

I always wondered why it is always assumed that separate CPU and GPU are somehow the most efficient use of silicon. It just seemed counter intuitive to me. If the proposed processor is as efficient as claimed, it looks like I was right to wonder. This absolutely annihilates Intel and AMD on a performance per watt basis.

Re:An almost unbelievable breakthrough if true (0)

Anonymous Coward | about a year ago | (#42182149)

I always wondered why it is always assumed that separate CPU and GPU are somehow the most efficient use of silicon.

I'm pretty sure no one ever made claim. GPUs are discrete so that they can be upgraded independent of the CPU and for performance reasons (separate bank so higher throughput memory rather than having to share slower access system RAM).

Re:An almost unbelievable breakthrough if true (1)

AvitarX (172628) | about a year ago | (#42182303)

Nobody assumes that, it's the entire point of the AMD APUs.

In some GPGPU workloads the e-350 outperforms cards of way higher specs. AMD's ultimate goal is to use the GPU for maths it is best suited for (see lower FPU per core than traditionally).

Re:An almost unbelievable breakthrough if true (3, Interesting)

muon-catalyzed (2483394) | about a year ago | (#42182321)

Hopefully FSF also patents it, so no troll can extort license fees from using the technology. In fact FSF should patent it all, make the blue prints available RFC-style and don't bother with anything else.

Re:An almost unbelievable breakthrough if true (1)

vlm (69642) | about a year ago | (#42182347)

This absolutely annihilates Intel and AMD on a performance per watt basis.

That's easy. Oh you want to be backwards compatible practically to the 8008. Turns out that is very hard after all.

Re:An almost unbelievable breakthrough if true (1)

h4rr4r (612664) | about a year ago | (#42182489)

No we don't.
There is no indication that this project has such a goal.

Re:An almost unbelievable breakthrough if true (1)

zill (1690130) | about a year ago | (#42182557)

Why would you assume it's x86 compatible? Don't just assume random things, it makes an ass out of u and me.

FPU (1)

lobiusmoop (305328) | about a year ago | (#42182023)

Didn't see any mention of hardware floating point unit(s). Is that just a given these days?

Re:FPU (1)

fnj (64210) | about a year ago | (#42182135)

I would think so. Even a five buck embedded oriented ARM like Cortex-M4 (sans MMU; hence not suitable for real OS) has one nowadays.

Re:FPU (1)

lkcl (517947) | about a year ago | (#42182403)

Didn't see any mention of hardware floating point unit(s). Is that just a given these days?

i believe so, yes - that's why i mentioned the GFLOPS figure. apologies if it wasn't made clear.

Re:FPU (1)

VortexCortex (1117377) | about a year ago | (#42183077)

Didn't see any mention of hardware floating point unit(s). Is that just a given these days?

Kind of hard to be used for graphics if not... Hint: "designed from the ground up to help accelerate 3D Graphics".

Anonymity (1)

mmHg760 (2780437) | about a year ago | (#42182047)

I may be way out of my field of expertise here, but I remember a nice trick that allowed to get information back from a live encrypted system by freezing the RAM http://www.zdnet.com/blog/security/cryogenically-frozen-ram-bypasses-all-disk-encryption-methods/900 [zdnet.com] .

It would be quite nice to have a end to end internally encrypted system. This kind of hack does not make a lot of sense from a personal use point of view, but when using a server, yes.

Re:Anonymity (1)

betterunixthanunix (980855) | about a year ago | (#42182083)

This is a tricky thing, not much different from signed bootloaders. In theory, it can be great for users; in practice, it is likely to be exploited by people wishing to push DRM and other non-free systems on us. See:

https://en.wikipedia.org/wiki/Bus_encryption [wikipedia.org]

Re:Anonymity (1)

mmHg760 (2780437) | about a year ago | (#42182151)

Agreed, but any type of progress can be used for good...or evil. In this case it's only a feature, a tool that can be an improvement in this type of product. One more choice instead of no choice.

Re:Anonymity (0)

Anonymous Coward | about a year ago | (#42182313)

Likely? It has. Look at any description of the Xbox 360 security system. The CPU encrypts and decrypts certain parts of memory at the L2 CACHE level that correspond to the security hypervisor. It's designed to prevent people from glitching out the hypervisor with hardware devices.

Re:Anonymity (0)

Anonymous Coward | about a year ago | (#42182283)

I may be way out of my field of expertise here, but I remember a nice trick that allowed to get information back from a live encrypted system by freezing the RAM

If you have the equipment to freeze a system in place without shutting it down first you probably got the equipment to remove the cover of the CPU and measure the key a few years before that.

Re:Anonymity (1)

mmHg760 (2780437) | about a year ago | (#42182421)

Not if the key is the public key of the current user account using resources on the server. Again, I'm out of my field of expertise, but it sounds like something feasible.

The terminal would be the only unencrypted part of the process, a terminal that could be anything ranging from another computer to a screen. All you have to do is to plug your hardware stored keychain to a screen with no data connection (expected encrypted video signal) to the server to get the unencrypted output.

That's going far, but that looks like a nice objective that could start with a processor that would allow a part of it.

"800MHz 8-core version would"... (0)

Anonymous Coward | about a year ago | (#42182069)

...suck. Yes, it would suck.

You know, that's great that you can cram so many cores into these things, but if programs aren't designed to handle the multiple cores properly, it's only as good as the power of a single core.

Re:"800MHz 8-core version would"... (1)

h4rr4r (612664) | about a year ago | (#42182143)

Speak for yourself.
Lots of different types of workloads are very parallel.

Just because whatever kinds of games you play are not does not mean this is commonly the case.

Re:"800MHz 8-core version would"... (0)

Desler (1608317) | about a year ago | (#42182253)

Yes, because only games involve serial tasks. *facepalm*

Re:"800MHz 8-core version would"... (1)

h4rr4r (612664) | about a year ago | (#42182325)

Which is not what I said.

Basically anything anyone would ever want to run on a server will benefit from more cpus. Add in much of what power users and developers will do.

These tasks range from hosting databases to transcoding video, to compiling code, or just using many programs at once.

Re:"800MHz 8-core version would"... (1)

Gordonjcp (186804) | about a year ago | (#42182207)

If only there was some way of running more than one program...

Re:"800MHz 8-core version would"... (1)

vlm (69642) | about a year ago | (#42182369)

If only there was some way of running more than one program...

Or one virtualized image.

Those performance numbers are BS (5, Informative)

CajunArson (465943) | about a year ago | (#42182121)

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 (1)

Anonymous Coward | about a year ago | (#42182247)

if you read the thread on arm-netbook you'll notice that they
don't even claim to have an instruction set yet. curiously,
they also claim to have a compiler pointedly not gcc. !?

one wonders if not gcc is code for, stop asking questions.
watch my waving hands.

Re:Those performance numbers are BS (0)

Anonymous Coward | about a year ago | (#42182271)

Do they have a bridge London that they are selling too?

Re:Those performance numbers are BS (3, Insightful)

godrik (1287354) | about a year ago | (#42182445)

Indeed, high gigaflops is easy, useful high gigaflops is hard. You can easily build a processor that only support float-addition and nothing else with a 1024 bit SIMD register clocked at 4 Ghz. And voila, you get 128Gflop/s per core. Problem is: it is useless.

The question is not how many adds or muls you can do per second in an ideal application for your architecture. The question is how many adds or muls (or whatever you need to measure) you can do per second on a real application.

For instance, the top-500 uses linpack, that measures how fast one can multiply dense matrices. That problem is only of interest to a small amount of people.

Re:Those performance numbers are BS (0)

Anonymous Coward | about a year ago | (#42182507)

Didn't you read the article? They have "specialist compilers" which can turn the MesaGL reference code into a cycle-optimal software rasterizer than will beat a PowerVR chip.

Yeah, reroute auxiliary power to the fore bullshit shield.

Also (4, Insightful)

Sycraft-fu (314770) | about a year ago | (#42182523)

Compare it to a more modern processor. You want floating point performance? Take a look at a Sandy/Ivy Bridge. My 2600k, which I have set to run at 4GHz, gets about 90GFlops in Linpack. The reason is Intel's new AVX extension, which really is something to write home about for DP FP. Ivy Bridge is supposedly a bit more efficient per clock (I don't have one handy to test).

If you are bringing out a processor at some point in the future, you need to compare to the latest products your competitors have, since that is realistically what you face. You can't look at something two generations old, as the 920 is, and say "Well we compete well with that!" because if I'm looking at buying your new product, it is competing against other new products.

Re:Those performance numbers are BS (0)

lkcl (517947) | about a year ago | (#42182553)

Those performance numbers are pure fantasy.

well, tell you what, rather than accusing, why don't you ask me to ask them? i can do that if you like.

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,

that's plain wrong - the current revision has 1333mhz DDR3 right *now*. unless you consider 1333mhz 32-bit DDR3 not to be a real memory controller?

you're also assuming that the data being crunched requires only one FLOP per number. you should know - you're on slashdot after all - that there's no correlation between the on/off-chip memory requirements and the on-chip processing requirements.

basically, you *know* that just because you're running the CPU at 100% capacity crunching numbers, does *not* mean that you have to run the memory bandwidth at 100% capacity as well. pay attention 007 :)

Re:Those performance numbers are BS (4, Insightful)

CajunArson (465943) | about a year ago | (#42183127)

unless you consider 1333mhz 32-bit DDR3 not to be a real memory controller?

Thanks for filling in that detail since I didn't know the precise specs (and for proving me right). To reiterate: No, this thing does not have a real memory controller compared to the 128 bit (2 channel 64-bit) or 192 bit (3 channel 64-bit) memory controllers in the AMD and Intel chips, respectively, that are mentioned in TFS.

You can go on and on about some busy-loop that you were able to code that gets all those gigaflops. I can get a 386 to tell me the result of 100 quadrillion quad-precision add-muls where the only operands are zero in less than a second too.. but it isn't useful work.

Trust me, if a chip even remotely like the one you are describing could do all that useful computational work in less than 3 watts using a previous generation process, then it would already have been deployed in supercomputers years ago and this wouldn't be some pie in the sky FSF project.

  I have no problem with a hobby project to build a CPU with an open architecture, but frankly hyperbole and outright dishonesty about performance expectations are not doing you or anyone else in the project any favors. Being "open" should include being honest & realistic first and foremost.

Re:Those performance numbers are BS (1)

skelly33 (891182) | about a year ago | (#42183055)

The one anecdotal piece I have to complement the above is that I was recently doing some work on an application in C to improve the performance of some legacy Fast Fourier Transform code compiled with GCC. The original code was doing a bunch of heavy lifting with double precision floats. I optimized the algorithm as far as I could without changing any data types and, as a last step I changed the doubles to pure 32bit integer arithmetic expecting at least twice the execution speed compared to the doubles on this Core i7 3Ghz processor. The end result: exactly the same performance for ints as for doubles, down to the microsecond. The new Intel chips have stunning FPU capabilities that I was definitely not expecting and, unless you plan for it as they clearly did, there will be a clear performance difference between int or even single vs. double precision on the GFlop counter...

Re:Those performance numbers are BS (5, Interesting)

AdamHaun (43173) | about a year ago | (#42183141)

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 [slashdot.org], 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 [opencores.org].

If it sounds to good to be true (0)

Anonymous Coward | about a year ago | (#42182155)

Show us the running hardware.

In 7 months? (0)

Anonymous Coward | about a year ago | (#42182173)

The goal is mass production in 7 months. Good luck!

Who cares? (-1)

Anonymous Coward | about a year ago | (#42182175)

So it's EFF-endorsable, big deal. This is like saying it's PETA-endorsable -- the loudest cranks approve, whoopee.

The reality is most people don't give a tinker's damn about the EFF. The great unwashed bearded one will approve ... we can all rest easily now in the knowledge that he's satisfied. Now maybe he'll STFU.

But, hey, I'm sure they'll port Hurd to it -- there must be 2 or 3 people who care about that.

interesting that the test is patented H.264 (1)

Creepy (93888) | about a year ago | (#42182181)

H.264 can't (legally) be encoded without paying for a license... interesting choice for an example. Yes, decoding is free at the moment, but these patents will be in effect until around 2020 or later and are part of the highly patented MPEG 4 standard.

Re:interesting that the test is patented H.264 (1)

Splab (574204) | about a year ago | (#42182343)

Why yes it can; might not be in the US, but the rest of the world are somewhat more sensible (but arguably still stupid) about patents.

Re:interesting that the test is patented H.264 (0)

lkcl (517947) | about a year ago | (#42182461)

H.264 can't (legally) be encoded without paying for a license... interesting choice for an example.

it's the hardest one to do, because of the inherently non-paralliseable CABAC decode (ok, there's a guy at MIT who came up with a probabilistic algorithm that guesses the block chain reasonably accurately).

if you're referring to patents, there's a little-known aspect of patent law which entitles individuals to create "one instance" of an invention, in order that they may "further improve on it". so if you download the source code, compile it up and, if questioned, cite patent law....

HDMI / Licensing (2)

lobiusmoop (305328) | about a year ago | (#42182201)

I know Allwinner did a separate version of their A10 chip without HDMI (A13) to avoid heavy licensing costs, would the HDMI push the cost of the chip up much?

Re:HDMI / Licensing (1)

gstoddart (321705) | about a year ago | (#42182499)

would the HDMI push the cost of the chip up much?

I doubt very much that the people who control the HDMI spec would allow an EFF-endorsed CPU to do this anyway -- the EFF has no interest in enforcing DRM, and HDCP pretty much requires you implement it end to end.

I'm not sure you could reconcile those two views.

HiPPi bus support (0)

Anonymous Coward | about a year ago | (#42182225)

http://en.wikipedia.org/wiki/HIPPI

Random number generator (2)

WaffleMonster (969671) | about a year ago | (#42182237)

I want a REAL cryptographic quality random number generator based on thermal noise or some other quantum mumbo jumbo.

https://www.eff.org/rng-bug [eff.org]

Lets at least make the spooks have to work for a living :)

Re:Random number generator (1)

lister king of smeg (2481612) | about a year ago | (#42182915)

you could have a radio active sample that emits partials randomly, use that as the base for your random number generator. the features i would like to see in this chip though is virtualization acceleration similar to what the better x86 and x86_64 chips now have. Maybe throw in hardware decoding of open media formats like ogg to.

Re:Random number generator (1)

VortexCortex (1117377) | about a year ago | (#42183179)

I write software that requires randomness to seed some key generation routines, for inverse DRM -- Where the user can validate mods other users make, or that my dev patches are valid (security, a value add, not the "prevent game from running" sense). When I do need randomness, I simply ask for it. I require the user to pound on the keyboard and randomly shake the mouse about, using the inputs to generate a bit of randomness to generate state and bit selection of the other random inputs for constructing the key. Hell, they even think they're playing a mini-game. Fortunately I don't need to do this often, once per install. Assuming you believe in free will, everyone has a "REAL cryptographic quality random number generator based on thermal noise or some quantum mumbo jumbo" already...

Onboard FPGA (0)

Anonymous Coward | about a year ago | (#42182285)

Would be a nice place for an engine.

Build in Co-Processor Support (1)

Anonymous Coward | about a year ago | (#42182307)

If you're doing an open source processor include the hooks to easily do coprocessing in FPGA for application specific acceleration like video encoding and decoding, etc...

Also build in hardware support for multi-threading primitives and atomic memory operations.

Production... (0)

Anonymous Coward | about a year ago | (#42182311)

Whatever they do, please DO NOT let Stallman into the clean room!

Single cycle FPU operations (0)

Anonymous Coward | about a year ago | (#42182341)

At least the basic operations (add, substract, multiply, divide, negate, compare) and conversion between integers and floats. This isn't counting memory accesses (i.e. operations between two registers).

Vaporware? (4, Interesting)

WoOS (28173) | about a year ago | (#42182401)

From TFA:

>The deadline:
> July 2013 for first mass-produced silicon
>
>The cost:
> $USD 10 million

This poster has either no idea or is dreaming. In 6 months he will not have an SoC through potentially several tape-outs, having first done System Engineering, Design, Synthesis, Layout, Verification, Validation, Documentation, ... and seemingly all without an existing organization. Or are SoC manufacturers lately doing short-term build-to-order processors. And the 10 million are not going to cover the necessary cost for all of the above. The masks alone might be that expensive depending on the number of tape-outs necessary (which - without an existing organization and working design flow - will be a lot).

Re:Vaporware? (0)

Anonymous Coward | about a year ago | (#42182865)

Did you read the part where they say they already have the silicon? This is $10m and 6 or so months for a die shrink and a modest clock speed increase.

Re:Vaporware? (3, Informative)

lkcl (517947) | about a year ago | (#42182907)

From TFA:

>The deadline:
> July 2013 for first mass-produced silicon
>
>The cost:
> $USD 10 million

This poster has either no idea or is dreaming.

both. i have no clue - that's why i posted this article online, as a way to solicit input and to double-check things - and i'm dreaming of success.

In 6 months he will not have an SoC through potentially several tape-outs, having first done System Engineering, Design, Synthesis, Layout, Verification, Validation,

what i haven't mentioned is that one of my associates (my mentor) used to work for LSI Logic, and he later went on to be Samsung's global head of R&D. he knows the ropes - i don't. we've been in constant communication, and also in touch with some people that he knows - long story but we have access to some of the best people who *have* done this sort of thing.

Documentation,

ahh, my old enemy: Documentation. [kung fu panda quote. sorry...] - yes, this is probably going to lag. at least there will be source code which we know already works. not having complete documentation has worked out quite well for the Allwinner A10 SoC, wouldn't you agree?

also, because this is going to be a Rhombus Tech Project, the CPU will *not* be available for sale separately. it will *ONLY* be available as an EOMA-68 module. no arguments over the hardware design. no *need* to do complex hardware designs. the EVB Board will *be* the "Production Unit" - just in a case, instead.

so by deploying that strategy, Documentation is minimised. heck, most factories in China have absolutely no clue what they're making. it might as well be shoes or handbags, for all they know. heck, many of the factories we've seen actually *make* shoes and handbags, and their owners have gone "i know, let's diversify, let's make tablets". you think they care about Documentation? :) ... ok, i know what you mean.

... and seemingly all without an existing organization.

yeah. it's amazing what you can do if you're prepared to say "i don't know what i'm doing" and ask other people for help rather than try to keep everything secret, controlled and "in-house". my associates are tearing their hair out, i can tell you :)

Or are SoC manufacturers lately doing short-term build-to-order processors. And the 10 million are not going to cover the necessary cost for all of the above. The masks alone might be that expensive depending on the number of tape-outs necessary (which - without an existing organization and working design flow - will be a lot).

well, because i know nothing, i've asked people who do know and have a lot of experience. the procedure we'll be following is to get an independent 3rd party - one that partners with the foundry - and get them to do the verification, even if the designers themselves have run the exact same tools. if it then goes wrong, we can tell them to fix it... *without* the extra cost of another set of masks. a kind of insurance, if you will.

but the other thing we are doing is: there will be *no* additional "design". it's a building-block exercise. the existing design is already proven in 65nm under the MVP Programme: USB-OTG works, DDR3/1333mhz works, RGB/TTL works, the core works, PWM works, I2S works, SD/MMC works and so on. all we're doing is asking them to dial up the macros to put down a few more cores, and surround it with additional well-proven hard macros (HDMI, USB3, SATA-II).

does that sound like a strategy which would, in your opinion, minimise the costs and increase the chances of first time success?

Feature Requests, Now that you asked (1)

davydagger (2566757) | about a year ago | (#42182465)

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

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

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

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.

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

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.

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.

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

DDR3 RAM, or something comparable.

Unlocked bootloader with firmware menu ala x86.

Atheros chipsets for wired ethernet(1GB fine, 10GB requested for future proofing), and wireless (every protocol up to N 600mbs, again future proof.)

split the graphics chipset into another PCI-E board, and sell it seperately, that works with x86.

I'd like to good support for ACPI tables, lots of hardware sensors, temp, fan speeds, intrusion, etc...

Requirements (2)

gr8_phk (621180) | about a year ago | (#42182667)

Off the top of my head:

0) A proper MMU and at least 1Meg of cache
1) 64bit - If not, there will be a need for yet another version at some point. Just do this.
2) Double precision floating point in hardware (for + - * / and preferably rsqrt)
3) GCC support.
4) LLVM support
5) LLVM-Pipe for OpenGL support
6) It would be nice if some instructions were optimized for running virtual machines.

I haven't looked into what makes sense for #6, but with all the VMs around it would be nice to have them run efficiently.

free fabrication process (2)

Dishwasha (125561) | about a year ago | (#42182679)

So will this 100% free processor follow a 100% free fabrication process? What is the use in being worried about dependencies on proprietary vendors' architectures in order to support 3rd, 4th generation processors when the ability to replace 3rd, 4th generation processors with an equivalent part requires production through a proprietary vendor manufacturing processes?

Hardware Virtualization (0)

Anonymous Coward | about a year ago | (#42182693)

I feel like I'm married to VMware in a way because I'm always using it for one thing or another. Hardware virtualization is better.

How about a bit of reprogrammable fabric? (0)

Anonymous Coward | about a year ago | (#42182843)

How about a small embedded, non-proprietary FPGA fabric and small bit of on-chip RAM that would be sufficient for certain useful tasks like, say, greatly accelerate decoding x86 or ARM or ??? instructions for emulation, handling custom high-speed i/o protocols, or performing filtering for software-defined radio. Maybe that's a bit too much to ask, but I've always wanted a CPU/FPGA hybrid that allows more dynamic application use off the FPGA side, rather than using external proprietary tools. Xilinx sort of had this for the virtex-II using a Java-based library but it's total abandonware now.

Actual (current) processor (0)

Anonymous Coward | about a year ago | (#42182855)

It seems fairly clear that http://icubecorp.com/products/ [icubecorp.com] is the current generation of the cpu which he is hoping to shrink, extend and speed up. Does it exist in any products? Is it already suitable for FSF endorsement? Wasn't the loongson (e.g. Lemote Yeeloong) already FSF endorsed?

What I would like from a processor (0)

Anonymous Coward | about a year ago | (#42182925)

OS programmable FPGA.
memset, strlen, etc, instructions
mutex instructions

I'll stick with my 386, thanks (0)

Anonymous Coward | about a year ago | (#42183121)

It's never steered me wrong and has more than enough power.

All of these new CPUs are pate.

How about the MUX instruction (from Knuth's MMIX)? (0)

Anonymous Coward | about a year ago | (#42183137)

I'd love to have the MUX instruction, as it is a pain to simulate.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...