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.
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.
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.
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.
I do not make any special effort to sound negative here, but honestly that SoC did not really work on anything. Most of the stuff posted to Opencores is in fact half-finished, buggy projects, and Milkymist SoC does not use any other Opencores stuff than Wishbone (and still, this was because of LM32) for this very reason.
Even the OpenRISC GCC/glibc toolchain was crippled with various major problems until recently. The OpenRISC RTL still is, but I can see things moving in the right direction. Maybe Milkymist SoC will integrate OpenRISC at some point, if those technical improvements happen.
OpenSPARC and LEON were also considered, but they are very heavy resource-wise.
Ah and yes - the video input is pretty much to make stuff the dancers can play with. We have no good video footage or documentation of this however (which is part of the reasons while it's still "beta").
We considered this option, but OpenSPARC is very resource hungry. It is a good design for a stand alone ASIC microprocessor, but in our case it is better to use a small and resource efficient CPU and leave the bulk of the calculations to dedicated accelerators.
To answer your question about spare gates, we are using about 44% of the FPGA resources at the moment. I would also question your remark about the compared "grunt" of a netbook, as many non-tech people I have shown the device to have spontaneously praised it for its reactivity and fluidity. Finally, some people are working on a MMU and even though it is of little use for my intended video synthesis application, you are most welcome to join them.
Price mainly has to do with volume. Also, VGA is still widely used today, and does not mean low resolution as the Milkymist One can do 1280x1024. We are planning to add a connector to drive HDMI displays at some point, which consists merely in wiring it directly to the FPGA as the Spartan-6 we use has the TMDS stuff built in, but unless we have the time and the development resources to get it done fast in the FPGA design, it is not a priority.
(I work on Milkymist One)
The material we posted online so far is not so great, but from feedback on real uses of the product, it does much better than what you describe. But it can be a matter of taste, too.
-- disclosure: I work on Milkymist One --
The only comparable product from proprietary hardware companies is the Edirol CG8, which has inferior specs in most regards and is sold for a lot more (about 6 times the price of Milkymist One).
About the price tag: this has to do with volume alone. The only way we can bring it down is by selling lots of device. Traditional chicken and egg problem in electronics...
First, we are working on this, and your patches are welcome.
https://github.com/sbourdeauducq/llhdl/wikihttps://github.com/sbourdeauducq/antares
FPGA companies are not as evil as you make them out to be. As a matter of fact, a large part of Xilinx's motivation about closing the bitstream is not to be evil, but to limit the damage that can be done from their (stupid and large) customers misusing the FPGAs. They still publish a lot and you might be surprised to learn, for example, that the ISE software has options to dump the complete routing graph of all Xilinx FPGAs as well as some raw timing characterization numbers. The information is there, but it takes more work to go looking for it than to sit on your ass bashing the FPGA companies - as most free software activists do whenever the topic of FPGAs arises. No wonder why so little open source FPGA and EDA stuff gets done.
Finally, Milkymist SoC and FPGAs lie at two different levels of abstraction. When you are using a traditional CPU, both the logic design (HDL) and the physical implementation system (ASIC cells, P&R tools,...) are closed. When you are using Milkymist SoC, the logic design is open and the physical implementation system is closed. The logic design is portable, and ported, to other technologies. I think we all agree this represents a progress.
That open source implementation is nowhere near as good as the original MIPS. As a general rule, the complete open source HDL thing, and especially Opencores, has still a lot of problems with quality those days.
Slashdot Mirror
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.
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.
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.
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.
The unboxing video, though admittedly not perfect, also has a great deal of more up-to-date demo content in it.
See here: http://www.ohwr.org/attachments/821/sebastien.pdf
No. The Verilog code is there: https://github.com/milkymist/milkymist
There is already GCC, and a experimental/incomplete LLVM.
All OGD does is a dumb VGA framebuffer due to lack of development/skills on the FPGA design. We went a lot further than that.
By the way, I will present the device tomorrow in Amsterdam: http://nimk.nl/eng/calendar/pixxxel-milkymist
I do not make any special effort to sound negative here, but honestly that SoC did not really work on anything. Most of the stuff posted to Opencores is in fact half-finished, buggy projects, and Milkymist SoC does not use any other Opencores stuff than Wishbone (and still, this was because of LM32) for this very reason. Even the OpenRISC GCC/glibc toolchain was crippled with various major problems until recently. The OpenRISC RTL still is, but I can see things moving in the right direction. Maybe Milkymist SoC will integrate OpenRISC at some point, if those technical improvements happen. OpenSPARC and LEON were also considered, but they are very heavy resource-wise.
Ah and yes - the video input is pretty much to make stuff the dancers can play with. We have no good video footage or documentation of this however (which is part of the reasons while it's still "beta").
We considered this option, but OpenSPARC is very resource hungry. It is a good design for a stand alone ASIC microprocessor, but in our case it is better to use a small and resource efficient CPU and leave the bulk of the calculations to dedicated accelerators.
Yes and being a lighting professional, you probably already know that 3 pin 5 pin adapters are not hard to come by, don't you?
To answer your question about spare gates, we are using about 44% of the FPGA resources at the moment. I would also question your remark about the compared "grunt" of a netbook, as many non-tech people I have shown the device to have spontaneously praised it for its reactivity and fluidity. Finally, some people are working on a MMU and even though it is of little use for my intended video synthesis application, you are most welcome to join them.
Price mainly has to do with volume. Also, VGA is still widely used today, and does not mean low resolution as the Milkymist One can do 1280x1024. We are planning to add a connector to drive HDMI displays at some point, which consists merely in wiring it directly to the FPGA as the Spartan-6 we use has the TMDS stuff built in, but unless we have the time and the development resources to get it done fast in the FPGA design, it is not a priority. (I work on Milkymist One)
The material we posted online so far is not so great, but from feedback on real uses of the product, it does much better than what you describe. But it can be a matter of taste, too.
-- disclosure: I work on Milkymist One -- The only comparable product from proprietary hardware companies is the Edirol CG8, which has inferior specs in most regards and is sold for a lot more (about 6 times the price of Milkymist One).
About the price tag: this has to do with volume alone. The only way we can bring it down is by selling lots of device. Traditional chicken and egg problem in electronics...
First, we are working on this, and your patches are welcome. https://github.com/sbourdeauducq/llhdl/wiki https://github.com/sbourdeauducq/antares FPGA companies are not as evil as you make them out to be. As a matter of fact, a large part of Xilinx's motivation about closing the bitstream is not to be evil, but to limit the damage that can be done from their (stupid and large) customers misusing the FPGAs. They still publish a lot and you might be surprised to learn, for example, that the ISE software has options to dump the complete routing graph of all Xilinx FPGAs as well as some raw timing characterization numbers. The information is there, but it takes more work to go looking for it than to sit on your ass bashing the FPGA companies - as most free software activists do whenever the topic of FPGAs arises. No wonder why so little open source FPGA and EDA stuff gets done. Finally, Milkymist SoC and FPGAs lie at two different levels of abstraction. When you are using a traditional CPU, both the logic design (HDL) and the physical implementation system (ASIC cells, P&R tools, ...) are closed. When you are using Milkymist SoC, the logic design is open and the physical implementation system is closed. The logic design is portable, and ported, to other technologies. I think we all agree this represents a progress.
That open source implementation is nowhere near as good as the original MIPS. As a general rule, the complete open source HDL thing, and especially Opencores, has still a lot of problems with quality those days.
on-board computer running Windows Embedded.
www.notacon.org is pretty good.