Just to check my understanding -- there's a 10x10 mm active interposer here, which has 64 "management-class" (MMU-less, I assume) cores, a crapload of interconnect, and a decent amount of I/O; and this can support up to a 5x5 array of chiplets bonded on top, each of which (of the current three) is either a quad core "application-class" processor (but still in-order), a tiny little FPGA (big question seems to be the width/capability of the DSP blocks), or something AI-ish that doesn't really interest me. Yes?<p>One question that immediately comes to mind is if there are a few pins on the interposer that are basically pass-through to the 2 x 2 mm chiplet on top, so that a chiplet that provides some level of I/O beyond what the interposer already has can be supported. I assume the UCIe links or something can be used as generic high speed SERDESes for that sort of use case, but more thinking about radar FEs and such.
Andreas Oloffson was behind the Parallela project as well... <a href="https://parallella.org/blog/" rel="nofollow noreferrer">https://parallella.org/blog/</a>
All the machine vision sensor companies use FPGA, which burns huge amount of power. Like 5w when it could be milliwatts.<p>I hope these guys have some ASIC modules for interfacing with CMOS global shutter sensors. Damn if they did I might start a machine vision cam company myself
I thought custom ASIC's were done when you have some computation that takes many instructions to implement in a CPU, for example for Bitcoin mining your computation might be "Find the sha256 of a fixed-length input and tell me if it begins with at least 32 zeros." The main benefit of using an ASIC (as opposed to an FPGA) is you can hard-wire the circuits, the FPGA has to use generic hardware (super-flexible LUT's and a super-flexible routing fabric) and you pay for all that flexibility with speed, power consumption and area.<p>I guess the main benefit of the chiplet idea is that you can get a really fast, low-latency connection between the CPU and FPGA? What kinds of problems can be solved with that architecture, that can't be solved by just putting the CPU and FPGA as separate chips on the same circuit board?<p>Or is it cost and design simplicity, you can have a lot of chiplet elements on the same chip, and the customization is in which chiplets you want ("give me a chip with 4xFPGA and 6xCPU") and how they're connected ("CPU A should be connected to FPGA #4, CPU B should be connected to FPGA #2 and #3")?
Curious to know how well this supports hybrid designs. No-code “IP block” composition is great for some stuff but there’s going to be customisations that aren’t on the standard “blocks”. That said, cool to see this emerge.
It looks like there's something interesting here, but I'm not really seeing what it is.<p>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?
At first glance I thought this was a new bleeding edge/carbon plate/superlight foam running shoe.<p><a href="https://www.dogonews.com/2023/9/25/adidas-super-shoes-help-tigist-assefa-shatter-womens-marathon-world-record" rel="nofollow noreferrer">https://www.dogonews.com/2023/9/25/adidas-super-shoes-help-t...</a>
Everything RISC-V is good. But we should go always for 64bits even if we "waste" some "logic material", because RISC-V as a worldwide/licence free standard is a very good ground for an assembly realm: write 64bits RISC-V once and run it on embeded/desktop/server/etc. Just need clean tables of functions for platform mobility which can be added slowly step by step.<p>The main pitfall while doing that, is abusing the preprocessor, because writting "c++" using a preprocessor assembly is hardly less worse than coding c++ then creating a absurdely massive and complex SDK dependency.