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

DRM

[queazocotal]

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

[ipquickly]

A rock made of silicone. Oh, wait...

Re:DRM

[Anonymous Coward]

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

[VortexCortex]

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

[Jartan]

He's talking about CPU enforced no-execute rules. The thing you're getting upset about is a bios trick to stop certain root exploits.

Two completely different things. Ironically the thing he's talking about stops the exploits you list.

Re:DRM

[thrift24]

The reality is the signed executables are going to interact with unsigned data during bootup or normal operation and the exploit to run unsigned code can be triggered at this point

For example the original xbox could be convinced to run unsigned code through exploited game saves and then system files(fonts/audio db) could be replaced with corrupted versions meant to trigger an exploit on bootup. This is how soft modding was performed for the xbox.

Re:DRM

[gmueckl]

This is why all resources required to boot a newer windows system (e.g. the logo animation in Windows 7) are embedded in signed binaries as well.

Re:DRM

[Anonymous Coward]

"Required to boot" implies that there is some obvious and useful demarcation where booting (and security) is done and then everything becomes untrusted again. All the actual valuable data, which we would want to protect from exploit, lives in this layer after boot. All of the exploitable software that includes complex data and algorithms will live at this level too. Persistent infections will be able to live at this level, corrupting the way these algorithms process this data. Trusted boot is security theater or cargo-cultism.

Re:DRM

[Anonymous Coward]

Apply De Morgan's law to the TC problem and you'll arrive at the logically identical, but hilarious position known as the "Evil Bit" which has been the subject of April 1st RFCs. The Evil Bit is a bit that is applied to any software that is known to be Evil. Sounds silly, right? This is kind of how antivirus software functions. AV software attempts to detect an evil bit and remove the offending software. The fact that this isn't something you expect to function correctly all of the time should be enough to weaken the premise of your argument.

Your bootloader is signed and loads a signed operating system, which in turn loads a signed browser, which then executes arbitrary JavaScript on the net, which then exploits a problem in the browser. Or perhaps your signed browser executes the signed Adobe Reader, which loads a PDF you clicked on and runs some exploit code there. Or you download that .exe attachment, which was signed by a trusted vendor (who was hacked) and now you're running that happily signed trojan.

If Trusted Computing solved these problems, not one Apple device would ever have been rooted. The "problem" it solves is the one where any software vendor may currently sell their software without paying a tax to some other entity. By requiring a software signature, there is a de facto tax (more like extortion) on software vendors, which is collected by the now mandatory certificate authority.
--
oursland

Re:DRM

[arose]

It's not completely useless, in such a system fixing security issues would not just prevent future attacks but also neutralize compromises without rebuilding the whole thing from a trusted source. Current: your system gets exploited, you now may have untrusted executable code in the system, fixing the original exploit doesn't do much. Signed: your system gets exploited, you now may have untrusted data on your system ready to re-exploit at runtime, fixing the original exploit renders said data inert (like it should have been in the first place).

Re:DRM

[thrift24]

well its a good thing no data being read at bootup or during normal operation is subject to being written to because if it were it would be impossible to store inside of a presigned binary.

Re:DRM

[Rockoon]

If Trusted Computing solved these problems, not one Apple device would ever have been rooted.

Apple is doing it wrong, silly.

You people dont seem to get it. Just because there is shit OS's out there doesnt mean that you should prevent by mandate or technical decision that no good ones can exist.

If you dont offer signed bootloaders, then you can only offer shit OS's. You will never be able to implement an OS like Integrity-178B.

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.

Re:Scientific Computing

[korgitser]

imagine a beowulf cluster of those!

Re:Scientific Computing

[Durinia]

And interconnect them with what?

HDMI?

Re:Scientific Computing

[mako1138]

As long as we're comparing mysterious numbers*, let's take a closer look.
Future Chip:
38 GFLOPS / 2.7W = ~14 GFLOPS/W
Tesla K20x:
3950 GFLOPS / 235W = ~16.8 GFLOPS/W
Radeon 7970:
3790 GFLOPS / 280W = ~13.5 GFLOPS/W

So I'm not seeing a power advantage here. More questions: does the chip do double precision, and what's the rate? What's the memory bandwidth? Is there support for ECC/scrubbing, which is essential for Big Deal calculations? (The 7970 doesn't support ECC. The Tesla does, and it had better given the amount of money you pay for it.) I'd imagine the Future Chip would be a cheaper solution, but you're starting from scratch with the compilers when everyone else has a major head start.

So while I think a FSF Principles chip is a good idea, pitching it for scientific computing is a stretch.

*Future Chip numbers probably do not include memory power consumption, and are likely a optimistic extrapolation from the dual-core silicon. Radeon result is the unholy combination of AMD's published single-point FLOPS and the max power consumption from Anandtech's review. Tesla numbers are marketing numbers combined with TDP.

Re:Scientific Computing

[Durinia]

For the record, the Tesla K20x TDP numbers include the memory (it's for the entire card).

A comment below says that it uses DDR3 1333. Total bandwidth of that, being extremely generous and giving them 6 memory channels (unlikely) puts you in the neighborhood of about 1/10th the memory bandwidth of the K20.

Combine that with the "how do you connect this to other things" problem, and this chip has no chance in scientific computing.

Re:Scientific Computing

[Durinia]

As a follow-up - it's one DDR3 channel - maybe 2. That puts it at about 1/30th of a K20.

People have tried to creep into Scientific Computing with processors like this (tile-based perf-per-watt SoCs). They haven't succeeded (see: Adapteva, Tilera, etc.). And they have much bigger budgets. :)

Re:Scientific Computing

[lkcl]

And interconnect them with what?

HDMI?

yeahhh... i hadn't really thought that one through. you kinda need 4 gigabit links, really (minimum)... hmmm....

Re:Scientific Computing

[plus_M]

Infiniband. That's what every scientific computing cluster I've used has had for multi-node parallel computations. Most parallelized scientific computing applications support MPI over Infiniband.

Re:Scientific Computing

[davydagger]

"So while I think a FSF Principles chip is a good idea, pitching it for scientific computing is a stretch."

while I don't expect the FSF principles chip to be A1 in perfomance, getting a FOSS chip in the same leauge with proprietary hardware is a good first step.

Its a good pitch for everyone who wants that sort of thing, me included. I know this guy is targeting "embedded" here, but I am looking for a scalled up 10-30 watt desktop model.

Re:Scientific Computing

[mako1138]

Ouch. Yeah, wishful thinking doesn't make for a viable product.

Re:Scientific Computing

[Durinia]

IB connects through PCIe.

which isn't on this.

An almost unbelievable breakthrough if true

[fnj]

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

[AvitarX]

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

[muon-catalyzed]

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

[vlm]

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

[h4rr4r]

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

Re:An almost unbelievable breakthrough if true

[zill]

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

Re:An almost unbelievable breakthrough if true

[amorsen]

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

Pins are expensive, and pin number 1000 is more expensive than pin number 1. That means the bandwidth going off a given chip is limited, and you cannot just add more of it, because that costs pins. The CPU and the GPU generally do not access the same memory at the same time, so it makes a lot of sense to split the chips into two; you can perhaps get away with 2 800-pin chips instead of a 1600-pin monster.

If you integrate CPU and GPU you also risk having to throw away your chips when either the CPU or the GPU has a defect. For an imaginary defect rate of 10% for each alone, you end up with 19% defects for both combined. That can quickly eat your profits.

However, bandwidth per pin has increased to the point that you can perhaps get away with using the same memory channels for both CPU and GPU and still get semi-reasonable performance. At the same time, chips have shrunk enough that even combined CPU-GPU silicon is small enough to not have a large risk of defects.

just a little skeptical of those numbers

[dywolf]

ok more than a little.

Re:just a little skeptical of those numbers

[fnj]

Yeah. I know the feeling.

Re:just a little skeptical of those numbers

[lkcl]

tell me about it. please share your concerns. this is not being sarcastic: i need to know. i need to know what the right questions to ask are, because i don't know.

Re:just a little skeptical of those numbers

[Anonymous Coward]

Not the grandparent, but I'll tell you some of the questions I had.

What's the architecture? What is the CPU core like? What is the GPU/video decoding block like?

MIPS? Okay, we all like MIPS. Any SIMD extensions?

Is there pipelining? Out-of-order execution? Exploitation of the MIPS branch delay slot? What's the C software throughput for 4-way SIMD adds and muls? Description of the memory hierarchy (caches, DRAM bandwidth, etc)?

What is the GPU subcores' instruction set like, assuming it's a design like modern GPUs from AMD and Nvidia -- i.e. a big stack of FPU/ALU lanes, running from a single instruction stream per something like 32 or 64 lanes? Is it OpenCL capable?

These questions being asked, I certainly hope you can pull this one off. It'd mean a revolution in embedded tech for 2015 or thereabouts, right on schedule.

No thanks

[betterunixthanunix]

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

[CajunArson]

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

[fnj]

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

[lkcl]

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

[K. S. Kyosuke]

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

[VortexCortex]

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

[UK Boz]

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:No thanks

[mcgrew]

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.

I'm a nerd, not an MBA. I want to tinker. I don't give two shits about market value or items in service and have no idea why you do. However, I also don't care what instruction set a chip is running, they're so fast these days emulation works. Nobody writes in assembly these days, as long as you have a compiler for the chip it's all good.

Re:No thanks

[suutar]

true, but it's got to be a good compiler. That's what hurt the Itanium; no compiler that could really take advantage of its capabilities. Although with that other article about improvements in automatic compiler-generated concurrency, that may get better.

Re:No thanks

[rrohbeck]

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

Are there any x86 instructions that are slow to emulate with standard RISC instructions so they could use special support instructions?

Oh and I love conditional skip instructions. They are so efficient. No more pipeline flushing, just ignore one instruction.

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.

Re:No thanks

[LordLimecat]

Much depends on the manner of freezing and thawing.

Re:No thanks

[mikael]

Here's a review: http://www.realworldtech.com/arm64/

The instruction set include arithmetic operators, a whole set of move (register/memory) instructions, floating-point instructions, SIMD vector instructions, cryptographic instructions. But the arithmetic instructions are separate from the memory transfer instructions.

Re:No thanks

[Richard_J_N]

How about implementing just a few of the most common C-library functions in dedicated hardware. For example, atoi(), strlen(), or printf(). Although the software routines are highly optimised, they still take hundreds to thousands of cycles. Dedicated libc functions would require a significant amount of chip die space, BUT, they would be really power-efficient - powered off most of the time, and simply used when needed. Imagine being able to use these functions as single-cycle commands... even if the core ran at 100MHz, the performance would be amazing. Essentially it lets us trade a few hundred thousand transistors (now very cheap) for a few mW (still rather valuable).

Re:No thanks

[bzipitidoo]

Conditional instructions are cool. The x86 instruction set isn't.

Are there any x86 instructions that are slow to emulate

Yes. Lots of them. Not only are these instructions slow, they're useless. No one needs the ASCII or decimal adjust instructions AAA, AAD, AAS, AAM, DAA, or DAS anymore, and they were never much use to start with. There have been a few cases in which these instructions were cleverly used for other than their intended purpose, but those are rare. Then there's the REP with CMPSB, CMPSW, SCASB, and SCASW instructions. They're useless for string searches-- we have much better string search algorithms than that. SCAS in particular is a legacy of C strings. Its main use is to search for the terminating null. Nice, except that the terminating null never was a good idea to start with, and we've been pulling away from it. They're useful for string comparison, except that we have lots of ways to avoid having to do a nasty old string comparison. LOOP could have been more useful, except they tied it to a single register-- the same register that REP needs. Besides, it doesn't save much-- a DEC plus JNE does the same thing. There is also CALL and RET, and PUSH, POP, PUSHF, and POPF. The idea of subroutines and stacks is fine, but this implementation pigs out on valuable registers (a longstanding criticism of x86 is that they didn't put in enough general purpose registers), and stacks can be implemented just fine with more general purpose instructions. CALL can be done with a store and jump, and RET can be done with a indirect jump that fetches the address stored earlier. Stacks are so 1970s in thinking. The x87 stuff is even more fixated on organizing around a stack. We have gobs of memory now, but this PUSH and POP work on one register at a time. Why? So a subroutine can save only the registers it uses? In the 1970s, every byte was precious. Now, have a LOADALL and STOREALL instruction with a more general pointer increment not one that must use only one register pair, SP:SI, don't worry if a few registers that didn't need saving got saved anyway, and let the CPU get on with the real code instead of forcing it to pipeline 8 or more PUSH instructions. Instructions like XLAT and LODS are more of those overspecific, too limited to be much use instructions. The function they perform is very useful, but it's better done more generally with an indirect MOV. The instructions for manipulating flags, LAHF and SAHF, and CLC, CLI, CLD, CMC, STC, STD, and STI are rather silly. Have a register devoted to the flags, and manipulate them with all the general purpose instructions that work on any register, rather than waste opcode space on them. Another dumb instruction is TEST, which is an AND that doesn't keep the result, it only sets flags. Totally unnecessary if there are plenty of registers.

The x86 is absolutely chock full of 1970s cruft that isn't much used anymore, but which must be dragged around for the odd compatibility need. Worse, it wasn't even all that good a design for its time!

Re:No thanks

[renoX]

Bleah, why was this moderated "Insightful"????

1) Itanium is a VLIW which is a very different beast than "normal" RISCs.

2) the new competition for x86 is ARM which is a RISC, so what about the bullshit with "good code" or "bad code"?

3) there are in-order and out-of-order implementation of both RISCs and x86..

Re:No thanks

[swflint]

And yet, I know assembly, and I'm in High school...

Re:No thanks

[n7ytd]

How about implementing just a few of the most common C-library functions in dedicated hardware. For example, atoi(), strlen(), or printf(). Although the software routines are highly optimised, they still take hundreds to thousands of cycles. Dedicated libc functions would require a significant amount of chip die space, BUT, they would be really power-efficient - powered off most of the time, and simply used when needed. Imagine being able to use these functions as single-cycle commands... even if the core ran at 100MHz, the performance would be amazing. Essentially it lets us trade a few hundred thousand transistors (now very cheap) for a few mW (still rather valuable).

Yeah, but how do we decide which functions those are? And why C functions? And once we hard-code those functions into silicon, we have to jump through extra hoops to change their behavior.

All three of your examples make a weak argument for this. atoi() is out of favor, since it doesn't detect errors like the strtol() function does. strlen() has no safety or bounds checking, and printf() is horribly complex.

BTW, some instructions in the x86 family are very specific for things exactly like this already. For your strlen() example, the SCASQ instruction and friends so something oh-so-close.

Re:No thanks

[mcgrew]

Well, get to work writing that compiler then!

Re:No thanks

[Richard_J_N]

Well, how we decide is fairly simple: look at a selection of open source code, and count the function calls, then filter out anything too complex. I said C, because many other languages are actually written in C, or use similar primitives. Also, I would suspect that if atoi() were implemented in hardware, strtol() could use that as a part. Printf() is indeed horridly complex - it can take a significant fraction of 1ms to run.
But what would happen if we devoted, say 5M transistors to implementing a decent chunk of libc and friends. Yes it would be very hard to do (and vulnerable to bugs that make the "Pentium" bug look trivial) - but it could allow 100x improvement in effective clock speed, OR dramatically drop the power consumption.

Re:No thanks

[badkarmadayaccount]

How about an array of 6502s for every main core that handle IO, IBM channel controller style - the cycle savings would be huge.

FPU

[lobiusmoop]

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

Re:FPU

[fnj]

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

[lkcl]

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

[VortexCortex]

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

Re:FPU

[godefroi]

Cortex-M4 has single-precision floating point. Just like it's not suitable for a real OS, it's also not suitable for real floating point work ;)

Anonymity

[mmHg760]

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 .

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

[betterunixthanunix]

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

Re:Anonymity

[mmHg760]

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

[mmHg760]

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.

Re:Anonymity

[Logger]

Interesting article. However, it only affects software FDE implementations. FDE implemented in hard drives don't store keys in DRAM, and sector data stored DRAM (cache memory on the drive) is encrypted.

That said, for the described attack to work they'd have to steal a running computer. Which quite likely means they'd have access to all of your data without going through all the trouble.

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.

Re:And no proprietary software either

[fnj]

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

Re:And no proprietary software either

[h4rr4r]

Why would that be the case?
Do you just like spouting gibberish?

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

[Anonymous Coward]

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

[godrik]

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

[skelly33]

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

[CajunArson]

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

[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

[CajunArson]

Thanks for that post.. extremely informative and it's good to know that people who really have to deal with these issues on a daily basis are paying attention.

As I said above: I have no problem with a project to build an "open" chip for education & hobbyists, but scam artists that know how to fool their marks with the correct buzzwords and hype are not doing anyone any favors.

Re:Those performance numbers are BS

[Durinia]

Thanks for saving me a lot of typing. :-)

Re:Those performance numbers are BS

[lkcl]

Forget the performance numbers, the whole thing is bullshit:

* The proposal is dated December 2, 2012

pay attention 007: we're aiming for mid-2013, not yesterday :) literally yesterday: today's the 4th, right? also, we're open to all kinds of investment opportunities. this article is a heads-up.

also, bear in mind: the core design's already proven. 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.

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. i'm quite happy to let other people do this. if you can help provide some useful feedback, input, or even have the expertise that can be contracted out to you, GREAT.

Re:Those performance numbers are BS

[CajunArson]

Uh... moron: " In fact, teh only performance difference between float and doubles comes from vectorial SIMD instructions."

Thanks for proving my point: the x86 chips run at 1/2 the effective throughput for double precision operations because the operands are twice as large. I never said a single word about instruction latency, you just invented that to make yourself sound smart while actually being stupid.

Tell me, do you go around to kindergarten classes and call the kids stupid when they say that 1 + 1 = 2 too?

Re:Those performance numbers are BS

[expatriot]

High performance with eight cores doing H.264 is interesting if you are making a dedicated decoder, but general purpose CPUs target a very wide range of applications. Some are embarrassingly parallel, most are not. This project might be well intended, but I have no confidence this will surpass even the free version of the MIPS processor much less a modern processor with, and this important, a highly optimized tool chain and a range of peripherals.

Interesting as a geek hobby project. Some might even get built.

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:Those performance numbers are BS

[AdamHaun]

As I said above: I have no problem with a project to build an "open" chip for education & hobbyists

Me either. For the record, while I'm happy to trash people who come here looking for money for pie-in-the-sky projects, I think it's great that people are becoming interested in building custom chips. Particularly with more and more functionality moving into SoCs, it's important that hobbyists and amateurs be able to learn and create their own work in the semiconductor world. I just never seem to hear about that kind of stuff on Slashdot...

Re:Those performance numbers are BS

[PipsqueakOnAP133]

Amen, brotha!

It's also hilarious when some programmers try to write in Verilog as if it were C. :)

Re:Those performance numbers are BS

[CajunArson]

First of all: Lots of non-x86 high-performance computers have similar memory controller layouts. Look at high-end SPARC or Power architecture systems.

Second of all: Thanks for proving me right with your screed about how ARM chips don't have good memory controllers. Guess what: you're right! They don't! And guess what: The Cortex-A15 is the first ARM chip capable of beating a 4 year old Atom when clocked north of 1.5 Ghz! So that's the type of performance that even the supposedly miraculous ARM gets with its architecture and a similar memory controller! You are now claiming to be insanely smarter than everyone at ARM and Intel simultaneously.. if chips could be designed and built based solely on arrogance & ego, you'd put ARM & Intel out of business by next Tuesday.

So basically you have been trolling this thread calling everybody who has pointed out flaws in the grandiose promises that you have put forth "007" in a smarmy and condescending manner while presenting zero facts to backup your arguments and contradicting yourself at every turn.

From your annoying and repetitive use of "007", do you perchance speak with a British accent? Do you appear in informercials at 2AM pushing whatever fake product of the day some insomniac can buy for $19.95? Because that's exactly how you come across in these discussions, and if you actually are associated with this project and aren't just troll then I'd highly recommend that the FSF immediately disavow this project before they end up getting sued when you make off with somebody's money.

Re:Those performance numbers are BS

[LordLimecat]

well, tell you what, rather than accusing, why don't you ask me to ask them

Its not a matter of asking. If someone could match even a 2-gen old i7 design on 3 watts, they would have done so by now, undercut Intel, and made zillions. They cant, because Intel processors are really good and their R&D budget dwarfs the budget of most US states, not to mention they own their own fabs and are 1-2 generations ahead of literally everyone else in process scale.

Even without deep technical knowledge, it doesnt pass the smell test.

Re:Those performance numbers are BS

[LordLimecat]

it's clear that you're used to the x86 world

And there arent any processors AFAIK outside of the x86 / x64 world that can match Intel and AMD designs in raw performance-per-watt. Trying to claim otherwise is dishonest, and as parent mentioned if it were true the top supercomputers wouldnt be wasting their time on Intel and AMD parts.

Re:Those performance numbers are BS

[LordLimecat]

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

Im not sure if youre aware what Intel's operating budget is, but you dont measure it in millions, you measure it in billions. And last I checked, their chip designs take YEARS to materialize.

So forgive us if we're skeptical that with $10mil youre going to hit record performance/watt with a 6 month timeline.

Re:Those performance numbers are BS

[Yvanhoe]

Well it still beats out all of the other FSF-endorsed chips out there...

Re:Those performance numbers are BS

[Anonymous Coward]

Also: Everyone knows that if the RTL sims pass that must mean there can't possibly be any bugs!

(this is so not true)

Re:Those performance numbers are BS

[AdamHaun]

Thanks for the info! I had a feeling EOMA-68 was nonsense too, but I stopped reading after discovering that A) his first big hardware project was developing an "industry standard", and B) they had to change the name from EOMA/PCMCIA because it wasn't actually compatible with PCMCIA.

The only thing I might be inclined to worry about is the possibility that he might sucker gullible people into donating to his obviously doomed project. (I'm not quite cynical enough to believe he's a scammer, but intent doesn't matter when the money's been flushed and donors can't ever get it back.)

Yeah, that was why I commented in the first place. There are too many overly optimistic software people here to let this sort of thing slide.

p.s. I also work for a fabless semi company. HATE YOU if you work for a direct competitor. (okay, not really ;)

Fabless, heck, I work for TI! We have plenty of fabs. Although we like foundries too. Everyone likes foundries these days since process development is insanely expensive. I spent the last five years doing product engineering and embedded flash process development/testing, and recently moved on to applications engineering. I am intimately familiar with how much work it takes to do the stuff that these proposals gloss over, and become very annoyed when it is not taken seriously. :-)

Re:Those performance numbers are BS

[n7ytd]

I am intimately familiar with how much work it takes to do the stuff that these proposals gloss over, and become very annoyed when it is not taken seriously. :-)

Seems like the GP is a believer of the "I don't understand what that guy does, so it must be easy" crowd.

Re:Those performance numbers are BS

[AdamHaun]

Seems like the GP is a believer of the "I don't understand what that guy does, so it must be easy" crowd.

It's a pretty common blind spot. I'd be willing to cut him some slack for it if he hadn't jumped straight from "cool idea bro" to "give me all your money". Or at least if he weren't so willfully ignorant about his own project.

Re:"800MHz 8-core version would"...

[h4rr4r]

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:And no proprietary software either

[lkcl]

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

interesting that the test is patented H.264

[Creepy]

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

[Splab]

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.

HDMI / Licensing

[lobiusmoop]

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

[gstoddart]

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.

Re:HDMI / Licensing

[lkcl]

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.

funny you should mention this. i raised it with Dr Stallman because the same sort of thing occurred to me: why support DRM?? well... his answer was: the DRM in HDMI is so utterly broken that it's as if it didn't matter. therefore, he's okay with it.

which i find absolutely hilarious. DRM is okay, as long as the keys are available, one way or the other [thus making the DRM irrelevant, one way or the other]. this is primarily what the fuss over the GPLv3 is about, because of the endemic tivoisation that occurred a few years ago [and is still ongoing].

Re:HDMI / Licensing

[LordLimecat]

Your product would therefore be illegal to sell in the US, courtesy of the DMCA (at least AFAIK). Good luck securing funding for a project that cannot legally be sold in the biggest market, and probably a good number of the smaller markets.

Re:"800MHz 8-core version would"...

[Gordonjcp]

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

Re:And no proprietary software either

[Anonymous Coward]

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)

Random number generator

[WaffleMonster]

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

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

Re:Random number generator

[lister king of smeg]

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

[VortexCortex]

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

Re:Random number generator

[amorsen]

you could have a radio active sample that emits partials randomly, use that as the base for your random number generator.

There are certain challenges involved in having radioactive materials in your chip. Or even in your chip factory.

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.

Every decently-designed chip is self-virtualizing. It would be silly to do a new design which isn't.

Re:x86

[ipquickly]

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.

Build in Co-Processor Support

[Anonymous Coward]

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.

Re:"800MHz 8-core version would"...

[h4rr4r]

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:And no proprietary software either

[Lonewolf666]

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 ;-)

Re:"800MHz 8-core version would"...

[vlm]

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

Or one virtualized image.

Vaporware?

[WoOS]

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?

[lkcl]

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?

Re:Vaporware?

[Anonymous Coward]

PROTIP: Without documentation, THERE IS NO POINT in developing something. Because how will anybody use the undocumented parts?
Don't be a lazy bum. Here's a nice rule I follow: Documentation should come *first*. Basically the spec and the documentation should be (automatically generated) different views of the same thing. And *then* you do the implementation.

Re:Vaporware?

[imsabbel]

The masks alone would cost more.

Re:Vaporware?

[WoOS]

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

I don't know the A10 with the euphemistic name but I know that the typical SoC MCU I know has documentation in the thousands of pages. And most of it on internal blocks, not external connections which might see a reduced need by delivering it only on a board - although then you need to document the board.
An SoC MCU is not a PC CPU. It has lots of internal (I/O) modules which all need documentation. And that documentation normally 'ripes' while select customers get engineering samples of the MCU and - for the priviledge of getting them - have the fun of suffering through and reporting all the inconsistent or non-understandable parts which get into the documentation because it is just a bunch of individual module descriptions forced together.

> it's a building-block exercise. the existing design is already proven in 65nm under the MVP Programme ...
> 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
If I understood you correctly you want to shrink it to 40nm. Then there is no proven design as a shrink normally means a new libary.
Also you should have your mentor at Samsung have you get in contact with one of their SoC Design leads and have him tell you how 'easy' it is to just "dial a few macros" and connect them. Any new thing you add to an existing SoC has the chance of causing ripple effect, be it problems with your bus architecture (e.g. not enough ports on your bus for the new cores), larger power supply (internal to external, linear to switching), timing violations because the die size grew, .... .

On the danger of doing a Bill Gates: Open Source SW is useful because every halfway intelligent person can extend it and make use of it within a few days of installing a development environment. Open Source semiconductor designs on the other hand are not, because the market access barriers in that area are not the knowledge of the design but (the cost of) the technology and the people needed to execute it and make something useful of it. Until nanotechnology delivers there is no "Brew your own core in the backyard".

Re:x86

[erroneus]

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

free formats

[vlm]

hardware support for free formats, as opposed to non-free?

Feature Requests, Now that you asked

[davydagger]

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

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:Feature Requests, Now that you asked

[lkcl]

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

in x86-land, yes. in ARM-land, yes. MIPS, funnily enough no: look up MIPS64-ASE-3D. ingenic jz4760 and below: no (look up X-Burst).

this chip is more like MIPS-with-3D-ASE, or Ingenic-with-XBurst. you *can't* separate the GPU from the CPU: they're one and the same. ok, you could... but you'd end up with two identical processors connected by some sort of fast bus... why bother? why not just double the number of cores?

Re:Feature Requests, Now that you asked

[davydagger]

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

sorry, must have missed that part, I WOULD like to see in the future a desktop/laptop replacement that wouldn't mind hitting 10-30 watt power mark, that could be work for Free Software concious DIY enthusiasts (sell a standard ATX/ITX format mobo, with standard power supply hookups, etc...), and in laptop form. I know that is getting a little ahead of myself, as this one has yet to take place.

Thank you for responding, and thanks again for doing what you do.

Re:Feature Requests, Now that you asked

[amorsen]

10GbE, i don't know if you've seen the power consumption, it's insane. 6 watts for 10GBase-T PHY ICs just on their own! so 1GbE yes to that; 10GbE mmm.... not right now.

Just do the wires for SFP+. People can use Direct Attach Cables or put an external PHY on the board.

Or provide a single modern PCI-E-lane. Not quite enough for full-bandwidth 10Gbps, but close.

Re:Feature Requests, Now that you asked

[badkarmadayaccount]

IBM style channel controlers, something like a 6502, doorbell interrupts, iAXP 432 capabilities, no MMU, no memory controler, HyperTransport, RAM integrated memory controler, SPARC style CMT, IO blocks on separate chip, B5000 style async multithreading, separate kernel stack.

Re:Feature Requests, Now that you asked

[badkarmadayaccount]

Oh, and logartithmic arithmetic.

Also

[Sycraft-fu]

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

[PhrostyMcByte]

The summary is building expectations so much that I can't help feeling this is a massive flop (yup, I did that) waiting to happen.

I'd be really impressed if they did match the performance of the 920, even if it'll probably be somewhere between 5-10 years old by the time this Free CPU sees production and gets into consumer hands. That's quite a complex, performant CPU right there to match. But the summary has so many holes, I really have a hard time believing they'll get anywhere near the 920 for general-purpose computing.

Compare it to a modern processor? Intel's Haswell architecture, coming out mid-2013, has theoretical performance of 973 GFLOPS of single-precision and 486 GFLOPS of double-precision. And those numbers don't include the on-die GPU performing work in OpenCL simultaneously.

I'm all for a Free CPU design and really wish them well, but naming names and saying they'll be comparable opens them up to this kind of skepticism fair and square.

Re:Also

[Sycraft-fu]

Ya I have no problem with the idea, I have a problem with the "We're going to beat all of the things!" attitude.

Plus there's the whole comparing theoretical to actual numbers. That 90 GFlop number I posted is the actual, measured, performance on my system. It is running Linpack, compiled with the ICC, in Windows.

A verified real world result is very different from looking at the design and saying "Well best case theoretical it should be able to do X!"

Re:x86

[BitZtream]

Contrary to Linux zealots belief, Windows is not the only proprietary software on the planet.

Requirements

[gr8_phk]

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.

Re:Requirements

[lkcl]

Off the top of my head:
 

always the best way :)

0) A proper MMU and at least 1Meg of cache

it's got 64k I & D 1st level, yes to the proper MMU, and the dual-core version has 256k 2nd-level (just enough). they reckon for 8-core that'll have to be increased.

1) 64bit - If not, there will be a need for yet another version at some point. Just do this.

yes. wellll aware of this :) have to be scheduled for the next version unfortunately.

2) Double precision floating point in hardware (for + - * / and preferably rsqrt)

it must have. i'll ask though.

3) GCC support.

ah no. this design is too different for gcc to handle. their compiler expert - someone with over 15 continuous years expertise in compiler design - chose open64 instead (which used gcc's front-end at some point, and so the whole compiler chain is *entirely* GPLv2 licensed).

4) LLVM support

don't know! good question.

5) LLVM-Pipe for OpenGL support

shouldn't need it... he said. i'll have to ask

6) It would be nice if some instructions were optimized for running virtual machines.

good point! i'll ask. in the mean-time (and esp. if it's not), i recently looked at LXC. replaced a set of 5 XEN instances in about 3 hours flat. first one was a bit hairy, the rest were almost a cut/paste by-rote job. it's going well. thoroughly recommend it.

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.

Re:Requirements

[gr8_phk]

I didn't mean that type of virtual machine ;-) I meant like the Java Virtual Machine, the Python interpreter, the .net Virtual Machine. For interpreted programming languages and emulators. This is important since Android apps run on the Dalvik VM.

Support for full virtual machines is nice too, but not so needed for tablets or phones at this point in time.

free fabrication process

[Dishwasha]

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?

Re:free fabrication process

[lkcl]

So will this 100% free processor follow a 100% free fabrication process?

interesting question! if it became an issue, i'd get quite pissed and would, if forced to, look for alternative processor designs. that's the whole point of the EOMA-68 and the Rhombus-Tech strategy: the products are *not* dependent on one particular CPU - processors are on *modules* that are completely interchangeable. but... i like the idea. i'll have to think how to handle this one - it's not actually our design.

Re:free fabrication process

[BitZtream]

I made it this far down the page before saying it, but I can't hold back any more.

You have absolutely no clue what you're doing and because of that, if you're leading this project, I doubt any of it exists.

You're trying to sell vaporware.

Go sod off you damn troll.

Re:free fabrication process

[lkcl]

I made it this far down the page before saying it, but I can't hold back any more.

You have absolutely no clue what you're doing

that's right - i don't. that's why i'm asking peoples' input.

and because of that, if you're leading this project, I doubt any of it exists.

that's right: it doesn't. the idea is to get it made, with as little risk as possible, using building blocks that have been proven as much as is possible.

anything that's in the "planning" phase doesn't exist until it actually exists. what's wrong with that? if everyone followed the line you're proposing, nobody would ever make anything, would they?

Re:x86 - NOT!!!!!

[VortexCortex]

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

[ceoyoyo]

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

Re:x86

[ipquickly]

Contrary to Linux zealots belief, Windows is not the only proprietary software on the planet.

I don't really use Linux, although that's going to change soon as I will be working with it daily.
I haven't used Windows in almost a decade.

But what other proprietary code do you have in mind?
How many proprietary operating systems are there?

Windows - already mentioned.
RTOS - if you need this - stay with i386.
OS X - license does not allow you to run on anything but Apple hardware - why would you care.
If you are amongst the remaining 0.1% using a niche proprietary OS then I guess x86 compatibility might be nice.

Any code optimized for x86 will run slower compared to an actual x86 processor, hell back in the early 90's Apple used to have an x86 processor add-on card.

If you are using proprietary code on an open source OS (eg. Flash on Linux) then x86 code execution would be nice, but in the long run - the ability (and documentation) to create an open source flash version has been available for years now. If anything - having a x86 proprietary Linux flash player has hampered development of FOSS flash implementations as there is less of a perceived need for it.

No CPU is an island

[ThatsNotPudding]

So what is this to be attached to? A virtual motherboard with non-Nvidia / Intel / Marvel / Broadcom... virtual chipsets? This will be quite a long march to the desktop....

Re:No CPU is an island

[lkcl]

So what is this to be attached to? A virtual motherboard with non-Nvidia / Intel / Marvel / Broadcom... virtual chipsets? This will be quite a long march to the desktop....

not really. the plan is to release it exclusively as an EOMA-68 module, which itself will be both the EVB *and* the mass-production PCB (just in a metal case). what we'll do is the same thing as done with the Allwinner A10 card: make the module power-able from the USB-OTG as a stand-alone computer, that also has an HDMI output. so it'd be a larger version of these USB-dongle-computers like the MK-802, except with more "oomph" and the option of being able to plug it directly into desktop chassis', tablet chassis', laptop chassis' etc. etc. if that sounds like pie-in-the-sky, it most certainly isn't: if you've heard of the KDE "Spark" Tablet, for various reasons they'd like us to design the tablet. we've got most of the components sourced, just need to find a casework designer with a good price, and we're off.

Re:x86 - NOT!!!!!

[lkcl]

So you're volunteering to write the compiler, right?

the team's done it already.

And porting Linux to a completely new architecture?

and that, too. and android on top of that.

relax - it's been taken care of. come on - think, 007. would i *really* have put this up as a proposal if the compiler and the linux port hadn't already been done? doh! :)

MMU

[zakeria]

A Memory Management Unit would be nice in today's CPU's

Re:MMU

[Pinky's Brain]

With a tagged TLB while you're at it so you can have a microkernel with drivers in their own memory space without a huge performance penalty.

Re:MMU

[Pinky's Brain]

Windows 7/8 and MacOS X don't put microkernels in their own memory space, they are in kernel space ... basically most MMUs have two tags, kernel and user.

Re:x86

[zakeria]

the x86 was only supposed to be around for about 5 or 6 years tops, it's almost 40 so I think it's time to say goodbye!

Reconfigurable instruction support

[ubergeek65536]

I'd like to see support for a small chunk of FPGA fabric to allow for specialized instructions. I have no idea if FPGAs can be implemented free of patents.

Re:x86 - NOT!!!!!

[morgauxo]

He must be because surely the GNU/Linux community will not jump on the chance to port to this thing...

Re:And no proprietary software either

[morgauxo]

Why would that be? The GPL would only cover the processor's design. So, unless you are removing the die from the case and grafting on additional logic gates to add some new proprietary function to the CPU you are fine. Running proprietary code on the processor is just using the processor. Saying your code has to be GPL would be like saying every document you write in a GPL'd office suite has to be GPL. It doesn't make any sense!

Questions

[EmperorOfCanada]

First a boatload of cores. 8 is a good start but I want 128 or 1024. One idea would be to have variable cores. That is a handful of crazy powerful cores and then another 1000 lightweight cores for all kinds of lightweight stuff.

But the difficult question is how compatible with existing things to make it. If you venture too far into the land of cool you might only end up with a tiny bunch of hardcore followers like Lisp and Erlang presently have. I am not saying that lisp or Erlang are good or bad but what strikes them from most people's toolsets is that they are too different from most people's norms. It is not too hard for a C++ person to wrap their head around Java or C# but ()))()()()())()()(Lisp)()())()))()()()() can be a bit hard to wrap a CPP::Brain(); around.

But at the same time if you stick with similar solution to ARM then why bother? I guess it all boils down to can Linux be ported to the new and cool or would a new and better ARM really be that much better?

I guess there is a third option. If a new CPU demanded a wholly new OS then maybe a whole new demand might be created. I have leafed through the Linux architecture and quite a bit of it seems legacy and often solving problems I don't have. Thus maybe the world is ready for a new OS/CPU. Strikes me as way too hard but for all I know this might be one of those "Wow it was so easy that we are puzzled someone didn't do this long ago" moments.

MMIX

[aglider]

I woyuld recommend MMIX (thanks Knuth) with a GPU alongside.

By the time it gets done, it will be obsolete

[Animats]

Remember OpenMoko, the open source cell phone? By the time it shipped, it was obsolete. And they didn't even have to do IC design.

There are parts such as the Allwinner family which have no US intellectual property. That's how they can ship a rather impressive ARM SOIC for $7.

Re:And no proprietary software either

[DamonHD]

Hmm, one problem I have with the full GPL is that it *is* by design rather intent on spreading itself virally and to the exclusion of other legitimate models, and thus a restriction on what software the hardware would be allowed to run would be unfortunately in keeping with the GPL.

I agree that that would be excessive, but then I think that the full GPL is generally excessive.

You may guess that I prefer to license my stuff under BSD licences to allow fully commercial uses. B^>

Rgds

Damon

Bootloader and device tree.

[Alex Belits]

1. Built-in, externally SPI-programmable bootloader flash. Preferrably too small to work with any imaginable UEFI implementation, so it won't work in locked down devices with Windows RT, and if someone will stuff it there, bootloader would be easy to replace by the user.

2. If the chip contains anything more than the CPU itself, and any kind of ROM/flash, ship it with a matching flat device tree in a known location, so bootloaders and OS won't have to have those things hardcoded.

Re:Onboard FPGA

[Pinky's Brain]

A patent mine field ... I'd rather see say a wide bus to tie it to a FPGA. A couple 400-800 MHz hypertransport links would be nice (there is an open HT core for FPGAs) but I'd settle for a couple 32 bit wide ports with 400-800 MHz LVDS source synchronous signalling with DMA support, with the protocol handled completely in software.

Re:How about the MUX instruction (from Knuth's MMI

[gr8_phk]

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

Isn't that just a = (b&mask) | (c& ~mask) ?

Octa-SPI

[Alex Belits]

Octa-SPI interfaces -- two quad SPIs (each with its own clock) with DMA buffers on the same controller and combined interrupt logic, for fast communication with cheap FPGAs.

Re:And no proprietary software either

[lkcl]

Hmm, one problem I have with the full GPL is that it *is* by design rather intent on spreading itself virally and to the exclusion of other legitimate models, and thus a restriction on what software the hardware would be allowed to run would be unfortunately in keeping with the GPL.

you are absolutely, absolutely dead wrong. waaayyyy off base.

I agree that that would be excessive, but then I think that the full GPL is generally excessive.

You may guess that I prefer to license my stuff under BSD licences to allow fully commercial uses. B^>

Rgds

Damon

and how's that working out in the android community? you've seen the list of GPL violations as people mistake "android equals linux", yeah? it's a serious problem, and it's why i started the whole rhombus-tech initiative: to get free software developers involved right from the beginning in the mass-volume industry, right the way through to sales in hypermarket retail stores. the "dream" if you will is for free software people to be able to walk into a supermarket and go go "fuckin'A! i helped write the software for that! you wanna buy one of these, grandma, i can replace the OS in no time, with something that i can manage remotely for you".

you have to remember that the BSD license was designed and written at a time when everyone trusted (because they knew them personally) everyone else in the industry. *everyone* shared source code. then fuckers like apple came along and went "thank you very much. BYE". at one point, microsoft's NT Team took the TCP/IP BSD-licensed stack, and put it directly into MSRPC (because winsock was so shit). it's almost 20 years later that Wine have finally reverse-engineered MSRPC. i really don't understand people who don't understand why the GPL is so necessary, i really don't.

2008 called

[viperidaenz]

They want their i7 920 back. 2009 want their Phenom 2 back as well.

Re:x86 - NOT!!!!!

[davydagger]

I do actually. Its not a deal breaker, but I won't lie and say I don't use some x86 only binaries, both in WINE and some proprietary software.

Also, my favorite distros revolve around x86.

Re:x86 - NOT!!!!!

[davydagger]

"So you're volunteering to write the compiler, right?"
more like "port of gcc".

" And porting Linux to a completely new architecture?"
make it #14 for linux. I can't imagine that it would be hard if you are able to design a CPU archetecure/CPU in the first place, specificly one with linux in mind. Specificly one you have all the specs and already have intimate knowledge with.

Re:And no proprietary software either

[DamonHD]

But I've had some of my code used in places where the user could not have deployed GPL code and where there was a pressing need but not necessarily much money. Those few lines redeployed made the world a slightly better place IMHO.

I *want* corporates to be able to use my code *as well as* for it to be used in FOSS. My agenda is more important than RMS's for my code, sorry.

Anyhow, this disagreement is not a new one, but I'm just pointing out that your horror about GPLed h/w excluding legitimate non-GPL s/w is to me not really distinguishable from GPLed code refusing to co-exist with non-GPLed code in common instances.

Regardless of licensing/philosophy disagreements, it looks like a fantastic project!

Rgds

Damon

Re:And no proprietary software either

[davydagger]

Slow day at work Mr Balmer?

Instructions for language virtual machines

[Paul Fernhout]

On 6) instructions for virtual machines, there are probably many good ideas for this. One thing I've wanted since implementing my first VM in the early 1980s is to have a way to tell a processor to interpret a sequence of virtual instructions (8 or 16 bit) as calls to a jump table of real instructions. Or perhaps the instructions could be wider (like 64 bit or 128 bit) with extra data beyond the first 8 or 16 bits as a jump indirection being loaded automatically into registers. There would then be instructions to process the next virtual instruction or perhaps to jump to some toerh virtual instruction. This approach is somewhat analagous to "microcode" in the sense that you are defining what virtual instructions do. This kind of support would remove the inner loop speed penalty of a lot of interpretation which can cause programming language virtual machines to run several times slower than native code. I've long thought proprietary CPU vendors would never add such a feature since it makes CPU families more easily interchangeable.

You could talk to people who implement Forth, Smalltalk, and Java language VMs for some general ideas in this direction as well, as a broader area of dynamic language support. In particular, better support for dynamic stack frames (which are objects in themselves in Smalltalk, but usually can be on the CPU stack) could make a language like Smalltalk run faster. Anything that improved support for Smalltalk-like message passing would be a good thing. Basically, ask Chuck Moore, Dan Ingalls or the FONC project what he would like to see.
http://en.wikipedia.org/wiki/Charles_H._Moore
http://en.wikipedia.org/wiki/Daniel_Henry_Holmes_Ingalls,_Jr.#Work
http://vpri.org/mailman/listinfo/fonc

Re:Instructions for language virtual machines

[gr8_phk]

For performance you never call an function to execute virtual instructions. The best way today seems to be load a byte, use it as an index into a jump table and jump. You make that operation a macro and put it at the end of every virtual instruction. It eliminates the central loop which is really strange.

One person suggested to me that the byte-code be replaced with the addresses normally found in the jump table. Then you could use a stack pointer as the virtual machines instruction pointer and just execute a RETurn instruction to do: fetch, decode (they're pre-decoded), increment, and jump. The problems with that are 1) you need to do the translation (address substitution) which means problems with dynamic code (or similar) and 2) You need an extra stack pointer in the host processor - otherwise function calls in the emulator or interrupts will overwrite the decoded instructions on the virtual machine. Neat thought though, 1 instruction for all that decoding. And it also means every instruction emulation function would end with RETurn. Weird.

Re:x86

[jones_supa]

If you are using proprietary code on an open source OS (eg. Flash on Linux) then x86 code execution would be nice, but in the long run - the ability (and documentation) to create an open source flash version has been available for years now. If anything - having a x86 proprietary Linux flash player has hampered development of FOSS flash implementations as there is less of a perceived need for it.

Quartus, Maya, MATLAB... There's much more closed-source packages than just Flash. And all the upcoming Steam games for Linux will be binary x86.

OpenRisc

[nurb432]

So what is wrong with them that FSF doesn't like them? Mature and 'open'.

Some ideas

[jonwil]

One idea I had was to copy what Microsoft did on the XBOX 360 and have encrypted memory pages (i.e. a given page of memory is encrypted before it even gets to the RAM or virtual memory page file). Completely prevents attacks like the cold-boot read-the-old-contents-of-RAM attack. Note that I know nothing about how the 360 did it or how it could be done on a SoC like this, its just an idea.

I also like the idea of having the ability to directly extend the instruction set by adding a co-processor or FPGA.
And I like the idea of having hardware-level instructions for optimizing the most important/common encryption algorithms like AES, RSA and SHA.

And I also like the idea of having a hardware level trusted-computing type setup (one where the key storage is blank until the end-user decides to load keys in there)

Re:x86 - NOT!!!!!

[ceoyoyo]

You might want to talk to some of the people who actually do the work porting things before imagining it will be easy. Introducing a brand new processor (along with a brand new motherboard) is hard enough. It's a lot harder if there's no software that will run on it.

Re:x86

[NadMutter]

Oops. Replying to undo accidental down mod

Re:x86 - NOT!!!!!

[ceoyoyo]

Reading the very sparse information you've provided I get the impression you're using an ARM core. That's not the same thing as implementing an entirely new instruction set, as some posters have suggested you should. Rereading, it does sound like the OP for this thread would be happy with an ARM processor and not a completely new one.

Re: Comercial too

[epSos-de]

The future version will have:

SATA-II, Gigabit Ethernet, HDMI 1.4, NAND Flash, DDR3 32-bit @ 1333mhz, USB-3, USB-OTG, I2S, I2C, RS232, SD/MMC, GPIO, PWMs and so on - all the things to be expected of a modern general-purpose mass-volume System-on-a-Chip.

This is going to be one very popular chip for embedded devices !

Re:And no proprietary software either

[BitZtream]

you have to remember that the BSD license was designed and written at a time when everyone trusted (because they knew them personally) everyone else in the industry. *everyone* shared source code. then fuckers like apple came along and went "thank you very much. BYE". at one point, microsoft's NT Team took the TCP/IP BSD-licensed stack, and put it directly into MSRPC (because winsock was so shit). it's almost 20 years later that Wine have finally reverse-engineered MSRPC. i really don't understand people who don't understand why the GPL is so necessary, i really don't.

The BSD license was created for the purpose of being compatible with closed source licenses.

Apple also contributes back to pretty much every OSS project they use. Saying they copied and disappeared is a flat out lie on your best day.

BSD's TCP/IP stack being basically the reference implementation for the entire world resulted in ... compatible networking. This is a good thing, yet you act like its horrible that everyone could be compatible by using the same code.

GPL isn't necessary. Thats a stupid statement. GPL, just like BSD license is a political statement. GPL is 'all scratch your back but then you have to scratch mine'. BSD code is 'here's a back scratcher, tell people where you got it from!'

End result?

Everyone uses BSD's back scratcher, GPL's back scratcher stays a niche tool for GPL fanboys who continue to be befuddled by the fact that it isn't the year of the Linux desktop.

Re:freedom!

[BitZtream]

Openness doesn't really help, the guy who produces your chip can still do the exact same thing intel can if they wanted to.

Unless you maintain the whole process yourself from start to finish, or verify it all, then you can't trust anything.

Wow that's harsh.

[gr8_phk]

While I agree the his GPL is necessary statement is a bit crap, this:

Everyone uses BSD's back scratcher, GPL's back scratcher stays a niche tool for GPL fanboys who continue to be befuddled by the fact that it isn't the year of the Linux desktop.

Is also crap. When is an open source BSD on the desktop going to happen? How about BSD on a smartphone?

Just sayin' each license has its place and uses. I still don't understand why there are so many others. BSD and GPL pretty much cover the two main philosophies, everything else seems to want to be some kind of sneaky open-source-except-for-we-who-can-take-it-closed.

Re:Wow that's harsh.

[arose]

You haven't seen anyone using "BSD's back scratcher" because what it actually means is that it was made from BSD wood. Some people like seeing their wood carved into back scratchers and seeing their name in the booklet everyone throws away without reading, I don't get it, but I don't have a problem with it. Why they feel the need to complain that those who insist that back scratchers made from their wood come with schematics ready for laser cutting are somehow less helpful is beyond me.

Re:x86

[petermgreen]

Everything works wonderfully on other architectures.

For sufficiently small values of "wonderfully".

Re:And no proprietary software either

[DamonHD]

I wish! B^>

Rgds

Damon

Re:x86 - NOT!!!!!

[davydagger]

he actually posted in the thread, he said the compiler is already done.

Re:x86

[Anonymous Coward]

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.

No, it doesn't actually. Not when the 3GHz processor is one of the world's most efficient (in terms of realized computational power per clock cycle) designs in existence. Not when the effort required to reach that pinnacle of complexity and performance is... astonishing. (Think: 5 year long design projects.)

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

You don't have any clue anyways. Throughput on common x86 instructions often exceeds 1 per cycle on modern advanced x86 core designs. It hardly matters that the start-to-finish latency for individual instructions is many cycles due to pipelining; without pipelines no design could operate even as fast as 800 MHz.

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.

This only makes "sense" if you're an armchair theorizer who has no real insight into the problem space. In reality, the worst problem with x86 as of x86-64 is that its instruction encoding is somewhat difficult to efficiently decode, due to the variable length instructions. A nicer encoding (even one with variable length, so long as it made it easy to detect total length from the first 2 bytes instead of having to scan the whole instruction like you do with x86) would basically save some power.. But not a lot. There isn't any revolution lurking the way you naively want to believe.

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

Just how old are you? I'm thinking you can't possibly be very old if you aren't aware that all the way back in 1991 the Apple-IBM-Motorola consortium created PowerPC, which was going to eat the lunch of all of the x86 CPUs by being a clean new architecture designed on scientific RISC principles. Apple replaced 68K with PPC. Motorola ported Windows NT to PPC and touted how in the brave new world people would flock to PPC for far better performance which x86 could never provide.

It took all of about 5 minutes for the NT-on-PPC plans to flop. There wasn't a real performance advantage there, so no third party software vendors were interested in porting application software, so no users wanted to buy PPC NT machines just so they could wank off about how pure and wonderful their CPUs were. The first PPC Macs shipped in 1994. Apple was reasonably successful with it for a while, because Mac users had little choice but to switch and PPC performance at least generally kept up with x86 for a while, but eventually PPC began falling behind and Apple was forced to switch.

The problems with x86 weren't fatal in 1991, and they aren't fatal 20 years later either. A clean sheet design could indeed be slightly better, but not radically better.

VLIW/EPIC please

[unixisc]

I've suggested this a few times, but given the FSF goals of forcing the source code to be always available, it seems that a VLIW/EPIC based CPU would be the perfect FSF flagship. In VLIW, there is no dynamic analysis happening within the CPU, so a lot of things that RISC CPUs do - branch prediction, speculative execution, register renaming, et al have to be done by the compiler. Which sounds perfect from the FSF POV - every time a new CPU is released, the software will have to be recompiled for the new platform if anything changes - #registers, #pipelines, et al. Now, they could just make the perfect gcc compilers for these, which shouldn't be difficult, since gcc compilers presumably already exist for Itanium, they'd be off to the races. Obviously, the job of fine-tuning the compiler would be left w/ the CPU maker. Also, the CPU might even prefer an EPIC architecture like Itanium, where flag bits may indicate which branch to preemptively execute, or which executed branch to retain if the CPU executes both branches and discards the other later.

Oh, and the HDL models of such CPUs - make them available under GPL3 or AGPL3. Anybody w/ the cash to blow and for whom the liberation of hardware and software both matters can take them, and try doing tape-outs, fab-outs... They could then do something like what Transmeta did, except that this time, they are running their native VLIW binaries, rather than translated x86 code.

Re:VLIW/EPIC please

[unixisc]

Also, they can have 2 CPUs for this - one modeled after the Itanium (since Intel is so uninterested @ this point, can they get Intel to just open it up?) targeted @ servers, and another modeled after Transmeta, targeted @ portables, tablets, laptops and netbooks. The instruction sets of these 2 platforms can be completely different - the latter can focus on power savings and not try overclocking the CPU, and have enough ALUs, registers and so on thereby eliminating the need to extra cores. The former can focus on performance, extra cores, higher clock speeds and everything needed to exact the maximum performance.

Re:"800MHz 8-core version would"...

[spyked]

In fact games involve massively parallel tasks at the data level. It's why dedicated hardware for graphics use architectures with tens or hundreds of cores. IMHO games would benefit a lot from multiple lower-frequency CPU even for non-graphics tasks (think: simulating a unit in a some real-time strategy game using a thread).

Re:And no proprietary software either

[Eunuchswear]

Hmm, one problem I have with the full GPL is that it *is* by design rather intent on spreading itself virally and to the exclusion of other legitimate models, and thus a restriction on what software the hardware would be allowed to run would be unfortunately in keeping with the GPL.

Please engage brain before typing.

Simple thought experiment - can you compile closed source code with gcc? Can you write copyrighted text with Abiword? So why couldn't you run closed source code on a processor who's design was licenced under the GPL?

What licencing the processor under the GPL means is that any modified versions of that processor also have to be licenced under the GPL. No more, no less.

Re:And no proprietary software either

[DamonHD]

Gee, thanks for your calm consideration.

Since (full) GPL software imposes conditions on stuff that just *links* to it without modifying it, never mind deriving from GPL-licensed types in (say) an OO language, and that turned out to be so toxic that the LGPL came to be, my point stands that a reasonable default view is that many other forms of usage that don't involve modification may be impacted unless shown otherwise.

Software running on such GPL hardware might be ensnared, and I wouldn't want to be the person dragged into court because I'd misunderstood.

(This is not theoretical: I had to unpick and redo a great deal of someone else's work because they hadn't noticed that one small library was GPL rather than LGPL, probably by accident; leaving it might have exposed trade secrets.)

Rgds

Damon

Re:x86

[erroneus]

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.

No, it doesn't actually. Not when the 3GHz processor is one of the world's most efficient (in terms of realized computational power per clock cycle) designs in existence. Not when the effort required to reach that pinnacle of complexity and performance is... astonishing. (Think: 5 year long design projects.)

But if a processor can do the same amount of work using less power and an 800MHz clock, then it is NOT the world's most efficient. That's kind of the point of efficiency. What's more, it's a requirement for progress. We can't make an artificial brain when we are saddled with huge power consumption. Speed alone is not the only factor.

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

You don't have any clue anyways. Throughput on common x86 instructions often exceeds 1 per cycle on modern advanced x86 core designs. It hardly matters that the start-to-finish latency for individual instructions is many cycles due to pipelining; without pipelines no design could operate even as fast as 800 MHz.

I think it is you who doesn't have a clue. I went to school on much of this. What you are missing is that much of the processing in these pipelines is wasted as the execution is speculative. So long as every series of instructions are a single stream, uninterrupted and involve no conditional branches, then yes, you can realize multiple instructions per clock cycle. But really you can't. That's not how processors work... especially not x86 processors. ...naivite ...

If improvements are to be made, there much be a discard of things which are legacy whenever and wherever possible. We are in the midst of big changes in the way [inter]networking and data are made accessible to people. The "PC" is becoming less significant. We are using new OSes and new hardware platforms. It is only a matter of time before those OSes and platforms invade business space just as the PC invaded the business mainframe space.

PowerPC

The PowerPC was a great thing. Unfortunately, it lacked something... a few somethings. One, it lacked the backing of Microsoft which was the dominant and growing force behind the move to PCs in the work place. Another thing lacking was that it didn't address any "needs" which weren't answerable by current and available technology. A solution without a problem is less likely to be adopted. Lots of ideas are good on paper. Computer history is cluttered with "better things" which never caught on because there was not enough need behind it.

problems with x86 are not fatal.

I beg to differ. We are now entering a time in which x86 cannot be the answer to the problem. The problem is that people want more mobility. x86 can't deliver.

Re: Comercial too

[godefroi]

'Cause my phone needs SATA-II and gig-E, right?

Confused - "licensing of the modern interfaces"?

[daboochmeister]

I'm confused ... I rtfa'ed, and it says in the project costs section that of the $10m needed, "$1.5m will be for licensing of the modern interfaces such as DDR3, HDMI, SATA-II, USB-3 and RGMII." If those modern interfaces need to be licensed that way, don't they violate FSF endorsability, ipso facto? Or, is it that the licensing terms for such are compatible with e.g. GPLv3?

What about Loongson?

[swflint]

I though the Loongson was just this, it's what RMS uses.

Older systems that already solved some problems.

[multicsfan]

I recommend looking at some of the Multics features, particularly the use of segmentation and paging instead of a more normal file system.
see http://www.multicians.org/features.html for an introduction to Multics features and the references for how they really work. Multics was written to run on an SMP system so a system with 1 processor was the special case.

I would also suggest looking into security, again both the permissions an perhaps the ring based permission levels. The more the cpu can help with building in security from the start the easier it will be in the long run.

You might also want to look into the NS32xxx series from National Semiconductor in the late 80's/90's( not sure exactly when). The NS3200 all had the same instruction set, however you could get the chip with 8bit, 16bit, and 32bit memory/data access. At this stage of CPU's I'd suggest looking into detaching the instruction set from the 'bit' size so the external access to memory/data was independent of the bit size. With a 32 bit data/address bus it may take 2 transfers to handle a 64 bit data item, but that can be done by the hardware without the software having to know about it. All the software sees is a 64 bit (or maybe later on with added instructions a 128bit) address/data path with the actual path width hidden by the hardware. A 64 bit program might run a little slower on a 32 bit bus, but it will run.

Re:And no proprietary software either

[badkarmadayaccount]

*rant* shitty window scaling algorithm *rant*

Re:Onboard FPGA

[badkarmadayaccount]

DisplayPort.