5 ms·

Are you making a pipelined FPGA architecture or a systolic array? How would you improve my FPGA? I have two directions that I could take my FPGA architecture s

Are you making a pipelined FPGA architecture or a systolic array? How would you improve my FPGA? I have two directions that I could take my FPGA architecture such as adding analog Logic Blocks and adding beamforming LUT interconnect. Can you explain how you would go about getting an MVP manufactured?

mikewarot 3y ago
If you look at them right, an FPGA is a bad systolic array. They're heterogeneous, or lumpy, the switching fabric makes them fast when you're trying to cut down on latency, but in terms of general purpose compute, it makes them horrible to program, as you have to solve the routing for a given chip architecture and its features and limitations. A BitGrid is completely uniform, a grid of cells with I/O to each Cartesian neighbor. If you have a compiled program ready to load into the LUTs, it's easy to move things over a row or column, or flip it, rotate everything 90 degrees, etc. Routing around a bad cell should be trivial. Because I add a latch to the I/O, and the clocking is in alternative phases, you can't have a race condition, it's stable. All "white" cells have I/O to black cells (which are latched at that time), and vice/versa. This makes it very easy to reason about, while still being Turing complete. It also means that you can have 4 independent functions of the same 4 bits of input, if you need it, in a given cell. Because each cell is doing its compute directly on data, and all in parallel, you should be able to get at least 50% utilization out of the LUTs without too much effort on the part of a compiler. If you have data flowing "right" on the grid through a number of cells, with carry and things sometimes going "up" and "down", you're not likely to use ALL of those signals. In that case, you could have a completely different stream of data and compute going "left" at the same time. It can get as tightly used as the compilers want to dedicate time to finding. Google supported (and I think still supports) an open source chip shuttle program that will make a chip, provided the design is licensed open source. I intend to get the BitGrid design made through that channel. I'll likely prototype it on an FPGA along the way. I've already got the emulator, so I can start work on some form of language/compiler to use to program it. --- As for your design, I think that it would be helpful to know how many % of chip defects are in what layers of the chips. If metallization almost never fails, then just using wires all the way across the chip in an X/Y grid isn't that likely to be an issue that needs to be solved. If the metallization does fail frequently, your design offers an advantage. However, any disabled section will effect propagation delays, which might eliminate the value of routing around damage.

mikewarot 3y ago

If you look at them right, an FPGA is a bad systolic array. They're heterogeneous, or lumpy, the switching fabric makes them fast when you're trying to cut down on latency, but in terms of general purpose compute, it makes them horrible to program, as you have to solve the routing for a given chip architecture and its features and limitations. A BitGrid is completely uniform, a grid of cells with I/O to each Cartesian neighbor. If you have a compiled program ready to load into the LUTs, it's easy to move things over a row or column, or flip it, rotate everything 90 degrees, etc. Routing around a bad cell should be trivial. Because I add a latch to the I/O, and the clocking is in alternative phases, you can't have a race condition, it's stable. All "white" cells have I/O to black cells (which are latched at that time), and vice/versa. This makes it very easy to reason about, while still being Turing complete. It also means that you can have 4 independent functions of the same 4 bits of input, if you need it, in a given cell. Because each cell is doing its compute directly on data, and all in parallel, you should be able to get at least 50% utilization out of the LUTs without too much effort on the part of a compiler. If you have data flowing "right" on the grid through a number of cells, with carry and things sometimes going "up" and "down", you're not likely to use ALL of those signals. In that case, you could have a completely different stream of data and compute going "left" at the same time. It can get as tightly used as the compilers want to dedicate time to finding. Google supported (and I think still supports) an open source chip shuttle program that will make a chip, provided the design is licensed open source. I intend to get the BitGrid design made through that channel. I'll likely prototype it on an FPGA along the way. I've already got the emulator, so I can start work on some form of language/compiler to use to program it. --- As for your design, I think that it would be helpful to know how many % of chip defects are in what layers of the chips. If metallization almost never fails, then just using wires all the way across the chip in an X/Y grid isn't that likely to be an issue that needs to be solved. If the metallization does fail frequently, your design offers an advantage. However, any disabled section will effect propagation delays, which might eliminate the value of routing around damage.