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.

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

The whole point of RISC CPUs is to be less complex than their CISC counterparts.

Timing errors are always the hardest things to track down. Fortunately we are talking about a fully digital ASIC with one clock domain, except for the memory controller, and some other things I might have ignored. I recently finished a project where we converted a FPGA to an ASIC that had more than 180 clock domains. That, my friend, was hard.

The logic bugs are mostly tracked down in simulation, and on the FPGA prototypes. Remember that the openRISC CPU has been available for some time already, runs Linux 2.6.38 fine and is being used in the industry. The RTL is mostly done except for ASICification of some parts.

The fear of suppliers running out of MCUs is real, I can tell you. Reverse-engineering of chips, and reimplementation in FPGA happens all the time in the industry. It is expensive and time-consuming, so having the source code and constraints around is a big help.

...which is why opencores is asking for donations

1. Push ASIC button

2. Profit

Just kidding :) The CPU itself has been turned into ASICs before, so most of the code is in a good shape. The rest is implementation details and will probably be worked out when the ASIC vendor is chosen.

Verification is always the largest issue when you are building complex systems. One of the benefits of open source however, is that someone might have done it before you. In the case of the OpenRISC CPU, the 80000 (correct me if I'm wrong) regression tests of GCC is being used as one source of verification stimuli. Keep in mind also that the design isn't being created from scratch. The core is about ten years old

This isn't an effort to create the next-generation-273-bit-mega-hyper-threaded-with-DDR-5-and-379-core-subpixel-shader-gpgpu on crack. It's a fairly standard 32 bit RISC SoC, with the main difference that the RTL code is open source, and that the ASIC will be sold at a low cost even in low quantities. Think of how popular the Arduino platform is for example. It has some extra street cred, because the layout is open source. Now this is taken one step further, by using a LGPL:d CPU and peripherals. The quaking-in-their-boots part sounds a bit exaggerated, but still, it is primarily because this hasn't been done before. And if it turns out good, there is an ASIC proven SoC that can be modified and recreated by anyone that doesn't want to pay an ARM or a MIPS license for a 32-bit RISC system. Also, by using a fairly cheap FPGA, a reference board with either the ASIC or the FPGA can be sold at a reasonable cost.

Yes, that is true, but this is an attempt to produce a complete open source SoC as an ASIC, not just the CPU.

I think you confuse things here. The opencores servers are paid for by ORSoC. Opencores itself is the same as it always has been. Kind of like a sourceforge for HDL code. The ASIC project is partially funded by ORSoC as you can see on the donations page.

I don't understand what you mean by that? This is exactly what opencores is trying to do

Not sure about MIPS, but ARM is quick to act if someone puts out ARM clones, and I guess the same principle would apply to MIPS clones, as they both are licensable. The difference is that the R3000 is from 1988 (according to wikipedia), which probably makes it less interesting

Yes you can monitor every clock cycle. In a simulator, that is. Also, I'm well aware that most vendors ship good documentation, and of course, opencores can probably not afford to ship replacement chips if a bug is found after the chips have been manufactured. However, it's a known fact that we have problems with undocumented hardware on Linux. Being able to fully analyze not just the CPU, but also ethernet, PCI, USB and other peripherals should be a welcome addition for all those that are writing drivers or debugging a strange hardware behaviour. I have no comments on your last two sentences

Yes, it might be expensive to manufacture small quantities, but availability is the key here. The space industry has learned it's lesson, and that's why they are interested in open source CPUs like LEON and OpenRISC

No, I mean isolating the problem and running the RTL code in a simulator.

I understand your critisism, and I also would like to see a more detailed plan. Since this is a pilot project, some things will have to be worked out during the planning phase.

As it is stated in the FAQ, the more money donated, the smaller process opencores can afford. That will also decide the possible ASIC vendors that can be used. I'm a bit curious about what other costs than the NRE that you are thinking of

The OpenRISC has been used in many projects before. The IP cores that are going into the ASIC should cover most basic needs. There is also a PCI bus included to cover some additional uses. A MMU will most certainly be included, since it is targeted towards running standard Linux. The CPU speed will be limited by the process, and the current design. Still, I agree that there should be a place for these kinds of discussions. I'm guessing there will be one. For now, slashdot will have to do :)

I think there are a lot of use cases for this. You can buy these cheap ASICs and build a system. If you need to hardware accelerate something, then you can replace the ASIC with a FPGA and extend the design. Come to think of it, it seems kind of backwards to prototype on an ASIC and then implement it in a FPGA :)

I really hope that you are wrong here. Open source efforts should be able to handle as much criticism as other projects. Regarding your other point, what I see is that the borders between hardware and software are changing. Things that used to be done in ASIC is now done in software and the other way round. There are also many cool ideas how to decide what is going into hardware and software at compile time.

There is also the problem that for every hardware designer, there are probably more than a hundred software designers. There are so much stuff we would like to do, but there isn't enough time

But looking at the code and create workarounds that you know are working is a big step from guessing. Also, it theoretically enables you to optimize things, when you can monitor every register and clock cycle. Don't think that is very usable in reality though, but who knows. You don't need to donate $25 by the way. One dollar is fine

Haven't heard of HDCaml before, but the idea of inventing a nicer languange than Verilog and VHDL lives on. System Verilog adds a lot of syntactic sugar and new functionality, and there is a cool project called MyHDL that uses Python. System Verilog is gaining popularity in the industry, but unfortunately there aren't any open source tools to work with it yet. The commercial ones don't seem to implement the full language either. A bit like the HTML5 situation. We could really need something though. Even after having spent nearly ten yers doing hardware design, I find the two main languages horrible to work with.

It is a bit thin on the ASIC side, but the simulation and development tools are picking up speed. Verilator and Icarus verilog are cool projects. Icarus can also do a bit of synthesis nowadays

This is why opencores is asking for donations

Not necessarily. Of course, the more chips that are produced, the cheaper they get, but this is also a non-profit effort, so if you are looking to buy low quantities, it might be cheaper than commercial offerings