Why I will be using RISC-V in my next chip

Btw, I'd love a hardware engineeer's take on my idea for bootstrapping open hardware. The idea is HW development issues make it too costly. Led me to consider an open-source FPGA on 45nm or below with tool-chain. Let academics build (and open) the hardest stuff with non-profit integrating that with I/O and other key I.P. onto small number of chips selling it at cost.

Example open FGPA (a start, not end-goal) http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-43...

Example open-flow (add VPR or whatever FPGA tool is called) http://opencircuitdesign.com/qflow/

Idea is we get an easy FPGA set up to allow targeting with open or commercial tools. Its specs are open for review and enhancement. There is a via- or metal-configurable S-ASIC co-developed that matches its architecture. Like with eASIC, people can do an inexpensive conversion if they choose. Even considered using people they turned down in their contest (but whose stuff worked) to build the tooling for that. ;)

So, you have cheap-as-possible 45nm or below FPGA's being cranked out with more I.P. and tooling all the time. S-ASIC conversion is inexpensive due to matched architecture. If designed for it in mind, ASIC conversion wouldn't be too difficult either for FPGA-proven designs given staff and tooling. The HW cost is essentially some important cells, NOC, key IP (eg USB, PCI, DDR), memories, some analog, and at least one integration. With MPW's & academic support, it might cost a fraction of what it otherwise would. Not going to be EDA or HW competitive with Xilinx or Altera but not $600-$2,000 a chip w/ closed bitstream either.

My main worry outside market demand is effect of patent suits, esp if they demand royalties per unit. Otherwise, I'm hoping combo of academics, existing tooling, open FPGA's, and S-ASIC's is a solid combo for a start on widely-accessible, open HW. Still getting feedback from HW pro's before I start knocking on doors, though.

1. Subversion and security concerns of all the black boxes in hardware alleviated with open I.P., tooling, and HW. Main concern in my field.

2. Both ASIC and FPGA entry cost to startups trying to get custom stuff out the door. Need to lower it.

3. Hobbyists and academics experimenting currently benefit from FPGA's with some HW and SW ecosystems built around them. I see that expanding with easy-to-use, open tooling. Plus maybe decent HLS system. Synflow is one I know in that niche.

4. I've been pushing potential of FPGA as accelerators for cloud, networked, and HPC applications for a while. There's an uptake in their use but cloud is cost-sensitive. FPGA's w/ OpenCL-style tooling sold at cost in boards pluggable into regular servers or desktops could... well, you know the potential because you're in that market & brave enough to compete on architecture. ;) Pico Computing also comes to mind with their FPGA desktops.

5. Maybe make HW prototyping, verification, etc cheaper as another source of revenue as I've seen some ASIC-oriented products that use FPGA's for this. I know many of the tools are too slow, too, so there's potential for straight acceleration as in 4.

6. Reduce cost (and runtime risk) of FPGA-proven components with S-ASIC conversion. Also thought about anti-fuse but think S-ASIC is legally & physically safer. Not a HW expert, though, so going on second-hand comments there.

So, there's at least 5 potential benefits from an open-source FPGA sold at cost. Especially on performance if people start cramming them into boards like Pico and Maxeler do with cloud company orders. Good on trustworthy, hobbyist, and prototyping ends with low cost & open, expanding SW side.

So, that's the idea. Pretty ambitious and with high failure potential for sure. It's why, if I attempt it, I'll be enlisting cloud companies and academics. AMD's "semi-custom" business seems to indicate some potential if it's integrated into a CPU's memory bus or a CPU itself. Core logic and stuff only needs to be done once on one good node. Subsequent integrations much cheaper.

https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-4...