I bought one a while back ago, then I realized the number of I/O's was very low for what I wanted to do. Would have been nice to have access to all the 95 I/O's of the iCE40HX-1K instead of just 16 (or is it 26?)
The FPGA used (iCE40) is the only one currently on the market with a fully open-source toolchain, and the IceStick is among the cheapest boards for experimenting with the iCE40.
I always thought the advantage of a FPGA is that they are very fast when programmed for a specific task. This seems like an interesting project, but is there a case where this would be preferred over any given CPU?
You often need CPUs to control other, fast parts you can only implement in the FPGA. Then it often is easier to implement a CPU in the FPGA, rather than connecting an external CPU to the FPGA, because you can integrate them better (by adding instructions to the CPU, or have it share memory, not having to worry about getting signal across limited IO pins, easily running everything on the same clock, ...)
I think the typical use-case for general purpose CPU cores in FPGAs is for all sorts of random bookkeeping/scaffolding to support the main custom logic, for example handling the UI or something like that.
Kinda contrived analogy would be that while SQL is good for getting data from DB you still usually want to hand over the data to some more general purpose language app for display or whatnot.
You can add instructions on the fly or switch CPU architectures on the fly. Go from a MIPS clone to an ARM clone. The main advantage of FPGAs is flexibility.
Flexibility and lower development costs. ASIC developments cost hundreds of thousands to tens of millions. FPGA's give you low development cost but relatively-high, unit price.
Yes. There's been good work in that space to make some of them use hardly any power where unnecessary and asynchronous ones (eg Achronix) could take it even further. Yet, always will be behind on ASIC's on power usage. I don't see them getting around that.
You're thinking of Structured ASIC's: FPGA-like devices that are configured by via's or metal layers. They knock some layers and material issues off the design, lowering costs. They use less power, are faster, and have lower unit costs than FPGA's. So, it seems win win. They primarily didn't take off because lower-cost tooling and multi-project wafers made low-end ASIC's cheaper than before. Still a good option to consider if ramping up volume on a FPGA-proven design. I've always said best thing to do for open-hardware is a matching 45-90nm FPGA and S-ASIC architecture with plenty of pre-proven blocks (esp I/O and memory).
Anyway, here's you a list of some for your own research. eASIC is longest running plus has ability to prototype chips for you without mask costs. That's awesome. Triad is extending concept to analog/mixed-signal at about $400k a projects last I heard. Others I know nothing about.
Xilinx advertises "EasyPath" as an ASIC alternative, but I'm pretty sure that's just a form of cost reduction for the exact same FPGA chips (by enabling them to use defective chips where the specified bitstream doesn't hit the defect?) rather than an actual "hard" option.
Now that is interesting. Ive neither heard of nor though of that in FPGA's. It's a proven trick given it was used by AMD for Tri-Core processors which were Quad-Core processors with a faulty, disabled core. Now I'm wondering if I should ask more vendors about for discounts haha.
From my understanding it's a promising path towards a free, verifiable processor.
FPGA:s apparently are simple and repetitive enough that it's feasible to verify their structure by X-ray, and the configuration is under user control.
So while I doubt they would be able to compete on performance in most cases, it could offer access to a real rarity: A CPU that can really be known and trusted.
Soft CPU cores are often used as parts of larger designs, e.g., for managing communications with the rest of the world, or to run the core algorithm and accelerate the execution using custom instructions.
http://www.jopdesign.com/
Then maybe academics in INFOSEC can try to put JX OS on it for secure, embedded apps:
http://www4.cs.fau.de/Projects/JX/
Native Java means no breaking out of JVM's model down to weird native code.