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
No one has chip fabs in their basement. So someone will have to pay big money to make the masks and tape-out and test the hardware.
This is why opencores is asking for donations
Unless some major vendor picks up the design and mass produces it lots of 100s of thousands, the price per CPU is going to be stupidly more expensive than an off-the-shelf CPU/motherboard or embedded system.
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
The price will probably depend a lot on the fab method, but the goal is to make it cheap and available. The main difference between this and beagleboard/arduino/freerunner is that they are all closed source ASICs. This is both a philosophical difference (Yeah! It's open source) and a practical (I wonder why the CPU is acting strangely, Oh well, I just have to look at the source code)
The OpenRISC spec supports 64-bit, but the current implementation is 32 bit. I agree with the GPU part. There is a cool project that has built a FPGA-based graphics card http://wiki.opengraphics.org/ . One problem with the open source hardware community is that it is a bit fragmented. Would be awesome to combine a lot of the efforts.
There are a number of open source CPU cores, most notably are probably Leon and opensparc. I'm not sure, however if the OpenSPARC has been turned into an ASIC.
This is a milestone in open source history. No more complaining about undocumented behaviour that causes drivers to crash. It's just to download the RTL code and see for yourself what is going on. If this catches on, the chances of building truly open systems greatly improves. Go OpenCores!
Slashdot Mirror
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
No one has chip fabs in their basement. So someone will have to pay big money to make the masks and tape-out and test the hardware.
This is why opencores is asking for donations
Unless some major vendor picks up the design and mass produces it lots of 100s of thousands, the price per CPU is going to be stupidly more expensive than an off-the-shelf CPU/motherboard or embedded system.
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
The price will probably depend a lot on the fab method, but the goal is to make it cheap and available. The main difference between this and beagleboard/arduino/freerunner is that they are all closed source ASICs. This is both a philosophical difference (Yeah! It's open source) and a practical (I wonder why the CPU is acting strangely, Oh well, I just have to look at the source code)
The OpenRISC spec supports 64-bit, but the current implementation is 32 bit. I agree with the GPU part. There is a cool project that has built a FPGA-based graphics card http://wiki.opengraphics.org/ . One problem with the open source hardware community is that it is a bit fragmented. Would be awesome to combine a lot of the efforts.
There are a number of open source CPU cores, most notably are probably Leon and opensparc. I'm not sure, however if the OpenSPARC has been turned into an ASIC.
This is a milestone in open source history. No more complaining about undocumented behaviour that causes drivers to crash. It's just to download the RTL code and see for yourself what is going on. If this catches on, the chances of building truly open systems greatly improves. Go OpenCores!