4 ms·

I like this, want to brainstorm with me further? I raised $372.03 for my FPGA chip on my profile and I've only sketched out a rough mock prototype of what I wa

I like this, want to brainstorm with me further? I raised $372.03 for my FPGA chip on my profile and I've only sketched out a rough mock prototype of what I want the architecture to be. So far, it works with any amount of silicon defects, can be up to the size of a silicon wafer, and the larger it is, the more it can reconfigure itself in parallel, which is directly proportional to its size growth.

mikewarot 3y ago
I found your previous post - https://news.ycombinator.com/item?id=38170336 https://news.ycombinator.com/item?id=38170336 I find your ideas interesting, especially your strong interest in routing around any faults, but still ending up with a relatively usable compute fabric. My approach is much, much simpler.... just a grid of cells, with the programming lines unspecified. Each cell has a 4 bits in from their neighbors, a 4x4 LUT, a latch on each of the 4 bits of output. Clocking on the latch is in 2 phases, like the colors on a chess board.... this makes everything deterministic, but fully Turing complete. The fact that the logic does the routing means that you can route around anything at runtime. The homogeneity and simplicity of the fabric means the run-time libraries on the host computer could do that routing, provided it had a map of the defects. Here's a write up as an Esoteric Language: https://esolangs.org/wiki/Bitgrid https://esolangs.org/wiki/Bitgrid Here's an emulator written in Pascal: https://github.com/mikewarot/Bitgrid https://github.com/mikewarot/Bitgrid I think the best approach is for both of us to try to get our ideas in the next Google open source chip shuttle.
- pantantrant 3y ago
  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

I found your previous post - https://news.ycombinator.com/item?id=38170336 https://news.ycombinator.com/item?id=38170336 I find your ideas interesting, especially your strong interest in routing around any faults, but still ending up with a relatively usable compute fabric. My approach is much, much simpler.... just a grid of cells, with the programming lines unspecified. Each cell has a 4 bits in from their neighbors, a 4x4 LUT, a latch on each of the 4 bits of output. Clocking on the latch is in 2 phases, like the colors on a chess board.... this makes everything deterministic, but fully Turing complete. The fact that the logic does the routing means that you can route around anything at runtime. The homogeneity and simplicity of the fabric means the run-time libraries on the host computer could do that routing, provided it had a map of the defects. Here's a write up as an Esoteric Language: https://esolangs.org/wiki/Bitgrid https://esolangs.org/wiki/Bitgrid Here's an emulator written in Pascal: https://github.com/mikewarot/Bitgrid https://github.com/mikewarot/Bitgrid I think the best approach is for both of us to try to get our ideas in the next Google open source chip shuttle.

pantantrant 3y ago
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.