Open Source CPUs Coming To a Club Near You?

lekernel writes "The Milkymist project (also mentioned earlier this year) have started shipping their so-called 'video synthesizer,' a device used by concert and other event organizers to create live visual effects. Most interestingly, the device is based on their fully open source system-on-chip design, including both a CPU and graphics accelerators — the latter being a significant part of what the Open Graphics project is still struggling with."

Comments

Finally, some serious nerd on this thing.

[blair1q]

I was beginning to worry that politics and journalism and business were all there was to /.

Re:Finally, some serious nerd on this thing.

[Ironchew]

I was beginning to worry that politics and journalism and business were all there was to /.

Don't worry, the Slashdot editors have had a journalism-free approach to summaries for a long time.

Mist/vapor

[Anonymous Coward]

Mist and vapor. Similar properties.

woot

[Anonymous Coward]

And all 5 people that care about this project will be thrilled.

I'm a bit ignorant on this subject I guess

[Synerg1y]

What exactly makes the design open source? Are they talking about open sourcing the drivers? Cause as with the omega project, there's just a long line of developers lining around the corner to do assembly level programming to reinvent the wheel to make it smaller (sarcasm to the max, nobody wants to work on this shit).

Also seems they have a profit model going here, open source here means, we'll take all your code and then close the source once we have enough and are making enough $.

Re:I'm a bit ignorant on this subject I guess

[Mr Z]

I take it you've never built hardware at the "design circuit boards and get them assembled" level. It's capital intensive. For my simple projects, the difference in cost per board was about 5-10x between a run of 5 and a run of 500. Of course they're selling these, because if they sell enough, they're cheaper for everyone. If everyone had to build one from scratch, nobody would, because they'd cost about $1000 more. Looks like it's a 6 layer board. I don't think that's something you can etch in your bathroom sink with a copper clad board from your local Fry's.

And they're truly open source. It's all GPLv3 or CC BY-SA 3.0. They provide the VHDL, the board design files (and the resulting Gerbers), everything. And according to their FAQ, they're even working on a free toolchain to compile the FPGA code.

Re:I'm a bit ignorant on this subject I guess

[lekernel]

Since we do not have a copyright transfer and most of the code is GPLv3 licensed, no one in this project has the right (nor the intention AFAIK) to close all the source.

Re:I'm a bit ignorant on this subject I guess

[WorBlux]

VHDL description files of the hardware, so you can mask it to an ASIC or "compile" it on any sufficiently large FPGA. IF I remember correctly these make use of an FPGA as the SOC.

Re:I'm a bit ignorant on this subject I guess

[Synerg1y]

That makes sense, the hardware schematic is open sourced as is this guy's programming...
http://en.wikipedia.org/wiki/Field-programmable_gate_array

Thanks for the explanations.

FPGA

[Ironchew]

The technical overview says the system-on-a-chip is implemented with FPGAs, and the open-source component is the Verilog HDL code.

Re:FPGA

[hedwards]

OK, I was wondering what problem this would solve that couldn't be more economically solved via FPGA. FPGAs have their issues, but unless you're intending to do a fairly substantial run of chips, I can't imagine it being practical without using FPGA chips.

Re:FPGA

[citizenr]

The technical overview says the system-on-a-chip is implemented with FPGAs, and the open-source component is the Verilog HDL code.

Verilog HDL code supplied by FPGA vendor

Re:FPGA

[Gordonjcp]

So how do you compile that and get it into an FPGA without closed-source tools?

Re:FPGA

[lekernel]

No. The Verilog code is there: https://github.com/milkymist/milkymist

Re:FPGA

[lekernel]

See here: http://www.ohwr.org/attachments/821/sebastien.pdf

Re:FPGA

[TeknoHog]

OK, so the entire process is not open source, but I think it is overall more open than stock CPUs. Besides, I find it much more geek-worthy to design my own circuits, rather than merely giving instructions to some other guy's circuit for which I don't even have schematics.

By the way, there are open source tools for some stages of FPGA work, at least synthesis and programming. I use UrJTAG all the time to program my chips on ARM and PPC, even if the bitfile must be built on x86 with closed tools.

Re:FPGA

[citizenr]

No. The Verilog code is there: https://github.com/milkymist/milkymist

cpu core is from fpga vendor, summary sounded like they wrote it from scratch

Re:FPGA

[Arlet]

OK, so the entire process is not open source, but I think it is overall more open than stock CPUs

I think stock CPUs are just as (or more) open, but they operate at a different level. The FPGA itself is usually not specified in such detail as the CPU. For instance, the bitfile format is proprietary and undocumented, as well as the exact properties of the FPGA fabric. You still need to buy the actual FPGAs from the vendor, and there's not a lot of choice between them, and then you need to get the synthesis tools from the same vendor.

With CPUs, you're limited to what the vendor put in the package, but that's usually pretty well documented, so you can generate your own binary files that will run on it, with your own tools. GCC supports many of those embedded CPUs.

The only difference is that FPGAs offer the flexibility to change stuff at a lower level, which can be fun and useful. On the other hand, CPUs are often easier to work with, faster, and offer integrated features that aren't available in the FPGA.

Here let me fix that for you.

[LWATCDR]

I was beginning to worry that politics and yellow journalism and business were all there was to /.

There is something there though...

[rickb928]

When someone decided there was a potential market for generic CPUs and SOC, something the size of an IC socket, the chip was built, etc, and Arduino is a marginally sustaining product.

If someone similarly decides that there is a market for a 'specialized' FPGA ( know, stupid), then it might get built, and expandign current FPGAs with some more specialized elements might result in a user-definable CPU that is actually useful.

The difference is that trying to design a new CPU today is assumed to require not just a design environment and tools, but then you get to actually fabricate the little things. So in the absence of a open-source design, lithography, fab, etc, you have no way to make very much at all. But if you had an FPGA with some clever elements added, maybe it becomes more practical.

How to do all this I dunno, but it sure sounds like fun. Which is probably why it isn't possible at all. That and the money.

Re:There is something there though...

[rickb928]

A dedicated ALU, for one.

Re:There is something there though...

[Anonymous Coward]

A dedicated ALU? Clearly, you have not bothered to study FPGAs before forming an opinion about them. For example, even the cheapest and smallest Xilinx Spartan-6 FPGA has eight DSPA1 slices. Each slice is a 18bit x 18bit multiplier with a 48-bit accumulator. Eight DSPA1 slices have more than enough resources to implement a general purpose 32-bit ALU, and if you go up one FPGA size (~$16 qty 1 instead of ~$10 qty1) you get 16 DSPA1 blocks instead of 8.

Xilinx FPGAs also have fast carry chain logic in every general purpose logic block, so you can easily implement tons of plain adders.

I don't know as much about Altera FPGAs but I'm quite sure they have similar features.

If someone similarly decides that there is a market for a 'specialized' FPGA ( know, stupid), then it might get built, and expandign current FPGAs with some more specialized elements might result in a user-definable CPU that is actually useful.

"Actually useful"? It's like you're in a time-warp from 1995. Use of soft (user-definable) CPU cores in FPGAs is not only possible, it's commonplace. The designs run the gamut from simplified cores running custom instruction sets which, by being very tightly designed around FPGA architectures, can achieve relatively high clock rates (such cores are commonly offered by FPGA vendors, with SDKs so you don't have to roll your own compiler), to implementations of major instruction set architectures well supported by OSS toolchains (ie GCC). Just to give one easily googled example, there's an open source synthesizable SPARC core (LEON) which has been used in many FPGA designs.

FPGA vendors also sell FPGA variants with embedded "hard" CPU cores. For example, Xilinx sells 65nm generation FPGAs with embedded PowerPCs, and they're in the process of switching to ARM in their 28nm generation.

Re:There is something there though...

[rickb928]

Then this whole thread is a waste of time. e.

Re:There is something there though...

[unixisc]

With all the die shrinks, FPGAs today have enough gates - which ultimately are the building blocks of all combinational and sequential logic - to make CPUs. Yeah, there may not be enough gates in them to make the latest and greatest Opterons, or Xeons, or POWER7s, or UltraSparc T4s. But there are enough in them to make generic CPUs of any architecture. If one wants an open CPU whose design one can later tweak for whatever their needs, this is a good way to do it. Once a design is frozen, and the volumes are there, one can make a real CPU instead of just simulating one on an FPGA

Too long ?

[unity100]

Why did it take that long for viable open source future cpu candidates to come up ?

Re:Too long ?

[olof_k]

Finally a comment that makes sense. The milky mist is a really cool project and deserves all the publicity it's getting. Thinking of buying one to try it out. The problem however is with the LM32. The license is very unclear, and IIRC there are at least three different licenses on the RTL code itself. I'm not even sure that it's really allowed to use it on any other FPGAs than Lattice's. From what I've heard it's also lacking a MMU (could be wrong on this part though) I also agree that there are way too few people working on open source hardware, but at least there is a lot more than there was five years ago. We have opencores for a lot of RTL cores and Dangerous prototypes cover a lot of cool open source hardware stuff on the PCB and MCU side just to mention a few. Open source also makes more sense for hardware in some cases as the verification part often is way more time consuming than the development. We have had much help from students that has chosen to do some formal verification project on the OpenRISC or some of the wishbone cores.

CPU implementations, in this case, are far from what they could be. Why is there not an open source equivalent of ARM's processors in the way that the Linux kernel was developed due to a lack of other open OS kernels? There's actually a couple of good reasons, but none should be terminal to the idea.

I'm working on the OpenRISC project. That is 100% LGPL and with Linux 3.1 it will be supported in the mainline kernel (along with an ever increasing support for different RTOS's). We are slowly getting there :)

Re:Too long ?

[lekernel]

The LM32 _is_ a good example of open source CPU; and there's more to open source than GNU. Also, it is simply more technically appropriate here than LEON, OpenRISC and OpenSPARC. There was some confusion about the LM32 license (sparkled among other things by confidentiality notices left in the source files) but Lattice cleaned up most of the mess a few months ago. The Lattice license says: " The Provider grants to You a personal, non-exclusive right to use object code created from the Software or a Derivative Work to physically implement the design in devices such as a programmable logic devices or application specific integrated circuits." So - yes, we can implement it in non-Lattice FPGAs. There is no MMU; some people talked about building one but it did not happen. We are open to switching to OpenRISC should it become as small and fast as LM32.

Re:Too long ?

[olof_k]

I checked my facts, and as you say, Lattice fixed the licensing issues. Also, I wasn't aware of the differences in size between the two. Modularity is one of the things on the todo list for the OpenRISC. Hopefully we can bring it down in size in the future. Sounds like a fun weekend project to do some resource usage analysis between the two. If only there were more weekends :)

Re:Too long ?

[olof_k]

New, is to stretch it a bit as it's about 12 years old by now :) Anyways, it is MIPS-inspired, but not compatible. There has been some discussion about making next version MIPS-compatible, but we chose not too, as we would like to add and remove features that can better fit modern embedded systems. Here's a link to the or1200 spec http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2For1200%2Fdoc%2Fopenrisc1200_spec.pdf

It's a $499 screen saver.

[Animats]

The site has an "unboxing video", but not a demo video. Here's a demo video. That was version 0.3. It looks like a rather lame screen saver. Here's version 1.0 from a techno party in Berlin. It's still rather lame.

I'm all in favor of good nightclub video, but this isn't it.

Re:It's a $499 screen saver.

[lekernel]

The unboxing video, though admittedly not perfect, also has a great deal of more up-to-date demo content in it.

Re:It's a $499 screen saver.

[Animats]

Milkdrop 2 is pretty good. It makes this thing look pathetic.

Re:GCC

[lekernel]

There is already GCC, and a experimental/incomplete LLVM.

Re:But still, no one gives a shit

[lekernel]

Maybe you do not care, but in about two months, components of the Milkymist SoC are flying into space - and this means more to the project and to open hardware in general than your negative comment.

High performance open source CPUs are a while off

[Btarlinian]

One of the problems with open source hardware is that the highest performance chips are designed under restrictive design rules which are a result of fabrication process limitations at the smallest technology nodes. That's one of the biggest reasons the semiconductor industry hasn't moved entirely to a fabless model. The folks making high performance computing hardware need to know exactly what limitations are imposed upon them by the fabrication process. And the fabircation process will never become "open source" (at least not until Moore's law no longer works), there' just way too much money invested in process technology for it to be freely released.

Not another MIPS variant?

[kriston]

Is this not another MIPS variant? There are so many questionably licensed and non-licensed MIPS microprocessors out there, I tried looking at the data sheets, but I don't see what instruction set this processor uses. I suspect a non-patent-encumbered variant of MIPS32. Can anyone verify?

Re:This already exists

[lekernel]

This is where the Milkymist project is different - you can implement the SoC on a small, affordable FPGA and still get good performance, in part thanks to dedicated accelerators. By the way, there is also FPGA platforms for OpenSPARC so your estimate is too high, but they're still quite expensive and OpenSPARC runs pretty slowly on them.

There are more open source processors out there

[jeremypbennett]

Congratulations to the Milkymist team - it's a great example of what you can do with open source hardware. As well as the LM32 used by Milkymist, there are other open source processors out there, for example picoJava, OpenSPARC, LEON and the OpenRISC 1200. Most of these are finished projects, subsequently open sourced - kudos to the developers for freeing their designs. The OpenRISC 1200, hosted on www.opencores.org, is different, in that it has an active community continuing to develop the processor and its tool chain.