There's a company called Zifra https://zifra.tech/ that does exactly this. They have the hardware ready and plenty of clever ideas for the software. I have talked to them quite a lot over the last year and they are doing a great job
You're right. And it's being done already by a company called Zifra https://zifra.tech/ They have the hardware already and many clever ideas for how to make this easy and secure. I have talked to them quite a lot over the last year
Hi,
Having worked on the OpenRISC project for ~4 years I thought I could share some insights here, as the licensing question pops up all the time.
The RTL for OpenRISC and most of the peripheral controllers that are used are licensed under LGPL, not GPL. While we all know that this is a software license with some concepts that don't translate well to hardware, the consensus is that LGPL means that you are obliged to shared modifications of the LGPL-licensed core, while GPL-licensed RTL would require the whole SoC to be GPL.
This is a view that we in the OpenRISC community share with the Open Source Hardware developers at CERN and other groups. This has also been tried by IP lawyers for a large company that wanted to use OpenRISC about ten years ago.
As for ASIC implementations it could be worth mentioning that there are ASICs running or1200 (the original LPGL-licensed OpenRISC implementation) in Samsung Digital TVs, in some of the Allwinner SoCs, Zigbee ASICs and other places, so it has been done many times over the years
Oh yes!
I failed to beat it even with the cheat code that gave you unlimited lives. I think even the cheat code itself was hard to get right
Re:Does 'hardware' extend to FPGAs and the like
on
Open Hardware Journal
·
· Score: 1
One way is to get into the OpenRISC project. You can implement your algorithms in software, and when you have identified the parts that could benefit from being run in hardware, write an IP core that takes care of it, hook it up to the wishbone system bus and write a driver.
License is a big thing. In most cases you want to put your own IPs in the same ASIC, and many companies are afraid of putting GPL code together with their own stuff.
The leon and opensparc are available as GPL and as a commercial license that cost quite a bit, while the OpenRISC is LGPL only, which makes it more suitable for commercial interests in this case.
I'm very interested in that area, but haven't had time to look at it in details. One way to move forward could be to profile drivers and see if there are any heavy number-crunching parts that could benefit from being moved to hardware. In the short run this would require patched drivers to interface the hardware, but in the long run I would like to see completely new interfaces, just as OpenGL defined a HW/SW interface for something that was traditionally done in software
Some of the OpenRISC founders started Beyond semiconductors. They have made ASICs of designs based on the OpenRISC. As it is closed-source, I don't know how far from the original OpenRISC they have deviated.
Flextronics have also made OpenRISC ASICs about ten years ago. There are many more, but most are under NDAs.
Yes, there are several ports for different development boards with FPGAs from Actel, Altera or Xilinx.. Here's a list of some boards that are supported by ORPSoC (The OpenRISC Reference System On Chip) http://opencores.org/or1k/FPGA_Development_Boards
Most of them contain UART, Ethernet, GPIO, SPI and in some cases HDMI, USB and Flash.
MinSoC support even more boards (http://opencores.org/project,minsoc) but there are less supported peripherals there. Ethernet and UART IIRC
The cheapest ones are about $50 or $60. Think the de0-nano is cheapest
If you want to try out some OpenRISC developing without having to buy a dev board, there is also the OpenRISC architecture simulator or1ksim http://opencores.org/or1k/Or1ksim It supports UART through xterm or telnet, ethernet with TUN/TAP and a framebuffer
Or simply the dude who did it owned a DSP1800 as opposed to the board I have at home?
You're actually spot on:)
I think it was a tight fit though, so I'm not sure it will fit on smaller spartan 3 FPGAs. Disabling caches and hardware mul/div and stuff like that could help. It's a pretty common board, so if anyone is interested in trying, just drop in to #opencores on freenode and chat with us
The OpenRISC is a lot smaller and simpler than the OpenSPARC and probably a bit slower, as it is a single issue CPU. Haven't seen any benchmarks comparing them though. The advantage is that you can buy a $50 FPGA dev board and start hacking on the OpenRISC. The hardware required for an OpenSPARC dev board is significantly more expensive
It could be done. We have booted Linux for OpenRISC on a dev board with 8MB of RAM. A quick look at the xilinx website shows that their top end Virtex-7 FPGAs have 85Mb of Block RAM which theoretically should be enough if not too much of that is used by the cores. You could also build some extra memory from the Slice FFs
But that alternative certainly will be expensive. I don't know if there are cheaper FPGAs that specializes in having a higher memory to logic ratio.
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:)
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:)
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.
If your order volume is small, the fixed costs will eat you alive.
...which is why opencores is asking for donations
There is a block level view of what's going in, which is mostly off-the-shelf OpenCores cores, but there are no detailed plans about how this is going to be translated into an actual ASIC design.
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.
There are only plans for making a FPGA based development platform.
Don't get me wrong, a FPGA platform is a good thing to do. A project like this won't have the resources to do very much design validation through simulation (which requires lots of people writing tests and running sims, i.e. real money), so FPGA based prototyping and validation is even more important than it is for conventional "closed source" ASIC projects. However, there is no plan given for how they're going to take their working FPGA design and turn it into an ASIC design.
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
It's somewhat revealing that they're using a single small Altera Cyclone IV FPGA (under $60 qty 1 through Digikey). If you don't understand the significance, this means their design is tiny and trivial and low tech by current standards.
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.
Sparc has been open since start when it comes to specifications, and the Verilog code has been open for many years.
Yes, that is true, but this is an attempt to produce a complete open source SoC as an ASIC, not just the CPU.
Opencores is a private held swedish company today making money by ads and consultants, it is not a.org company like opencores once was and this was
a great ad!!
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.
You cant make chips like that
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
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.
1. If this doesn't catch on and people want it to continue, this could be a significant ongoing cost for running this project above and beyond allocating what people might think are one-time NRE charges. None of this appears to be detailed enough on that site so I'm not sure how far they've thought through this. Who are the target vendors, and have they tendered bids? Costs vary greatly, and I'm not at all ready to throw money when there appears not to be an "open source" plan with sufficient detail to make this real, nor with open listing of the credentials of the individuals involved. If you're gathering up to $250k for a project and you want my money, I had damned well better know that you're able to execute and that you have a real plan and definitely not just an FAQ.
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
2. How did they define the product? Is it based on market needs? If so, what markets and where is the information on said markets? If it's for hobbyists, I get that, but did anyone do even a rudimentary survey to say how many timers or UARTs might be necessary, whether they should embed an MMU so you can run a more advanced OS, or what the max CPU clock speed should be? If *I* am going to put my money in it, then why not ask *me* what I want? And yeah, I know I can contribute, but how have all of those contributions been managed, organized and synthesized into what is being built AND make it sufficiently relevant for enough time that this would be worth doing before technology moves on? I don't see a single place for that around their site.
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:)
3. Frankly, why bother when there are many other vendors such as Microchip who offer 32-bit micros with fully-documented architectures and better capabilities that you can run Linux on? I know, I know, this is what open source is about, but we're not just talking about someone's spare time on a machine they do other things with; this is a real product with real implications. I seriously don't buy how they're going to change the industry since the successful players in the industry guarantee supply to their customers.
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 know I'm going to get flamed and down-voted for this post, but the open source hardware world is much tougher than the software world, and ASIC designs are steadily dropping because ASSPs are taking their place. I think people's efforts need to be focused on software, and this is coming from a guy who's been on Slashdot more than a decade with a hardware background (and hence my name) and has switched to the software and systems world...
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
Slashdot Mirror
There's a company called Zifra https://zifra.tech/ that does exactly this. They have the hardware ready and plenty of clever ideas for the software. I have talked to them quite a lot over the last year and they are doing a great job
You're right. And it's being done already by a company called Zifra https://zifra.tech/ They have the hardware already and many clever ideas for how to make this easy and secure. I have talked to them quite a lot over the last year
Hi, Having worked on the OpenRISC project for ~4 years I thought I could share some insights here, as the licensing question pops up all the time. The RTL for OpenRISC and most of the peripheral controllers that are used are licensed under LGPL, not GPL. While we all know that this is a software license with some concepts that don't translate well to hardware, the consensus is that LGPL means that you are obliged to shared modifications of the LGPL-licensed core, while GPL-licensed RTL would require the whole SoC to be GPL.
This is a view that we in the OpenRISC community share with the Open Source Hardware developers at CERN and other groups. This has also been tried by IP lawyers for a large company that wanted to use OpenRISC about ten years ago.
As for ASIC implementations it could be worth mentioning that there are ASICs running or1200 (the original LPGL-licensed OpenRISC implementation) in Samsung Digital TVs, in some of the Allwinner SoCs, Zigbee ASICs and other places, so it has been done many times over the years
Oh yes! I failed to beat it even with the cheat code that gave you unlimited lives. I think even the cheat code itself was hard to get right
One way is to get into the OpenRISC project. You can implement your algorithms in software, and when you have identified the parts that could benefit from being run in hardware, write an IP core that takes care of it, hook it up to the wishbone system bus and write a driver.
License is a big thing. In most cases you want to put your own IPs in the same ASIC, and many companies are afraid of putting GPL code together with their own stuff. The leon and opensparc are available as GPL and as a commercial license that cost quite a bit, while the OpenRISC is LGPL only, which makes it more suitable for commercial interests in this case.
The spartan3an has built-in flash for storing the bitstream, and I think you can put other stuff in there too and access it through SPI. http://www.xilinx.com/support/documentation/user_guides/ug333.pdf might get you started
I'm very interested in that area, but haven't had time to look at it in details. One way to move forward could be to profile drivers and see if there are any heavy number-crunching parts that could benefit from being moved to hardware. In the short run this would require patched drivers to interface the hardware, but in the long run I would like to see completely new interfaces, just as OpenGL defined a HW/SW interface for something that was traditionally done in software
Some of the OpenRISC founders started Beyond semiconductors. They have made ASICs of designs based on the OpenRISC. As it is closed-source, I don't know how far from the original OpenRISC they have deviated. Flextronics have also made OpenRISC ASICs about ten years ago. There are many more, but most are under NDAs.
MinSoC support even more boards (http://opencores.org/project,minsoc) but there are less supported peripherals there. Ethernet and UART IIRC
The cheapest ones are about $50 or $60. Think the de0-nano is cheapest
If you want to try out some OpenRISC developing without having to buy a dev board, there is also the OpenRISC architecture simulator or1ksim http://opencores.org/or1k/Or1ksim It supports UART through xterm or telnet, ethernet with TUN/TAP and a framebuffer
Or simply the dude who did it owned a DSP1800 as opposed to the board I have at home?
You're actually spot on :)
I think it was a tight fit though, so I'm not sure it will fit on smaller spartan 3 FPGAs. Disabling caches and hardware mul/div and stuff like that could help. It's a pretty common board, so if anyone is interested in trying, just drop in to #opencores on freenode and chat with us
The OpenRISC is a lot smaller and simpler than the OpenSPARC and probably a bit slower, as it is a single issue CPU. Haven't seen any benchmarks comparing them though. The advantage is that you can buy a $50 FPGA dev board and start hacking on the OpenRISC. The hardware required for an OpenSPARC dev board is significantly more expensive
It could be done. We have booted Linux for OpenRISC on a dev board with 8MB of RAM. A quick look at the xilinx website shows that their top end Virtex-7 FPGAs have 85Mb of Block RAM which theoretically should be enough if not too much of that is used by the cores. You could also build some extra memory from the Slice FFs But that alternative certainly will be expensive. I don't know if there are cheaper FPGAs that specializes in having a higher memory to logic ratio.
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
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 :)
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 :)
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.
If your order volume is small, the fixed costs will eat you alive.
...which is why opencores is asking for donations
There is a block level view of what's going in, which is mostly off-the-shelf OpenCores cores, but there are no detailed plans about how this is going to be translated into an actual ASIC design.
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.
There are only plans for making a FPGA based development platform.
Don't get me wrong, a FPGA platform is a good thing to do. A project like this won't have the resources to do very much design validation through simulation (which requires lots of people writing tests and running sims, i.e. real money), so FPGA based prototyping and validation is even more important than it is for conventional "closed source" ASIC projects. However, there is no plan given for how they're going to take their working FPGA design and turn it into an ASIC design.
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
It's somewhat revealing that they're using a single small Altera Cyclone IV FPGA (under $60 qty 1 through Digikey). If you don't understand the significance, this means their design is tiny and trivial and low tech by current standards.
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.
Sparc has been open since start when it comes to specifications, and the Verilog code has been open for many years.
Yes, that is true, but this is an attempt to produce a complete open source SoC as an ASIC, not just the CPU.
Opencores is a private held swedish company today making money by ads and consultants, it is not a .org company like opencores once was and this was
a great ad!!
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.
You cant make chips like that
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.
1. If this doesn't catch on and people want it to continue, this could be a significant ongoing cost for running this project above and beyond allocating what people might think are one-time NRE charges. None of this appears to be detailed enough on that site so I'm not sure how far they've thought through this. Who are the target vendors, and have they tendered bids? Costs vary greatly, and I'm not at all ready to throw money when there appears not to be an "open source" plan with sufficient detail to make this real, nor with open listing of the credentials of the individuals involved. If you're gathering up to $250k for a project and you want my money, I had damned well better know that you're able to execute and that you have a real plan and definitely not just an FAQ.
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
2. How did they define the product? Is it based on market needs? If so, what markets and where is the information on said markets? If it's for hobbyists, I get that, but did anyone do even a rudimentary survey to say how many timers or UARTs might be necessary, whether they should embed an MMU so you can run a more advanced OS, or what the max CPU clock speed should be? If *I* am going to put my money in it, then why not ask *me* what I want? And yeah, I know I can contribute, but how have all of those contributions been managed, organized and synthesized into what is being built AND make it sufficiently relevant for enough time that this would be worth doing before technology moves on? I don't see a single place for that around their site.
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 :)
3. Frankly, why bother when there are many other vendors such as Microchip who offer 32-bit micros with fully-documented architectures and better capabilities that you can run Linux on? I know, I know, this is what open source is about, but we're not just talking about someone's spare time on a machine they do other things with; this is a real product with real implications. I seriously don't buy how they're going to change the industry since the successful players in the industry guarantee supply to their customers.
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 know I'm going to get flamed and down-voted for this post, but the open source hardware world is much tougher than the software world, and ASIC designs are steadily dropping because ASSPs are taking their place. I think people's efforts need to be focused on software, and this is coming from a guy who's been on Slashdot more than a decade with a hardware background (and hence my name) and has switched to the software and systems world...
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