3 ms·

It looks like there's something interesting here, but I'm not really seeing what it is. Can someone explain in simple terms what's the added value, compared to

It looks like there's something interesting here, but I'm not really seeing what it is. Can someone explain in simple terms what's the added value, compared to buying an FPGA with an embedded RISC-V core? Like, if you want maximum configurability, you already have FPGAs, and if you want maximum performance, you have ICs. Where does Zero ASIC come in? How does it push the Pareto frontier? Is it for prototyping or for final products?

adapteva 3y ago
If a catalog low performance $1 mirocontroller is good enough, then it's probably the right answer. A low cost FPGA (~$5) with an embedded CPU is also a great choice. If none of the off the shelf components can meet the application cost, power, performance, size, weight, security constraints, you have the choice of either abandoning the project or spending $10M-100M to design an ASIC. Our chiplet approach fills the gap between ASICs and off the shelf FPGAs.
- PoignardAzur 3y ago
  Sure, but how does it fill that gap? Like, say I'm in a startup working on a novel microcontroller, or a novel ASIC, or a chip for a space rocket. Right now I'm prototyping on an FPGA, but performance / power / weight isn't good enough. Where does your product come in? Like, if I'm not getting enough performance-per-power from an FPGA, how am I going to get enough from your eFabric chiplets? The underlying computation still happens on FPGAs and RISC-Vs, right? Or is that you can embed your own custom circuits between pre-made chiplets? In that case, how do you save on capital costs (eg making the mask)? Through a fab shuttle?
  - adapteva 3y ago
    There is no guarantee that it will, but... case #1. If you truly have something custom IP, we could save time/effort by only chipletizing that part rather than working on the while SoC. The design and verification is an exponential function with respect to complexity(#blocks, die size). We can turn RTL into a 2mm x 2mm brick fairly easily.It would require a fab shuttle/mask sets though. case #2. Depends on huw much power goes to the PL vs other functions. For PL dominated FPGAs that you fill up to the brim, our only value would be to help like in case #1. For multi chip solutions (FPGA + CPU) with small amounts of PL, a corretly designed small catalog of off the shelf chiplet approach wins.

adapteva 3y ago

If a catalog low performance $1 mirocontroller is good enough, then it's probably the right answer. A low cost FPGA (~$5) with an embedded CPU is also a great choice. If none of the off the shelf components can meet the application cost, power, performance, size, weight, security constraints, you have the choice of either abandoning the project or spending $10M-100M to design an ASIC. Our chiplet approach fills the gap between ASICs and off the shelf FPGAs.

PoignardAzur 3y ago
Sure, but how does it fill that gap? Like, say I'm in a startup working on a novel microcontroller, or a novel ASIC, or a chip for a space rocket. Right now I'm prototyping on an FPGA, but performance / power / weight isn't good enough. Where does your product come in? Like, if I'm not getting enough performance-per-power from an FPGA, how am I going to get enough from your eFabric chiplets? The underlying computation still happens on FPGAs and RISC-Vs, right? Or is that you can embed your own custom circuits between pre-made chiplets? In that case, how do you save on capital costs (eg making the mask)? Through a fab shuttle?
- adapteva 3y ago
  There is no guarantee that it will, but... case #1. If you truly have something custom IP, we could save time/effort by only chipletizing that part rather than working on the while SoC. The design and verification is an exponential function with respect to complexity(#blocks, die size). We can turn RTL into a 2mm x 2mm brick fairly easily.It would require a fab shuttle/mask sets though. case #2. Depends on huw much power goes to the PL vs other functions. For PL dominated FPGAs that you fill up to the brim, our only value would be to help like in case #1. For multi chip solutions (FPGA + CPU) with small amounts of PL, a corretly designed small catalog of off the shelf chiplet approach wins.