Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

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

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 [milkymist.org], they're even working on a free toolchain to compile the FPGA code.

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.

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.

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 to

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 ju

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.

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

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 f

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 [milkymist.org] 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 [github.com] a few months ago.
The Lattice license [github.com] says:
" The Provider grants to You a personal, non-exclusive right to use object
code created from the Software or a Deriva

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

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.

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

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?

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