3 ms·

Full writeup (first in series, each post links to the next): https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-0/ https://mnemocron.github.io/2023-12-08-DIY

Full writeup (first in series, each post links to the next): https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-0/ https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-0/

mikewarot 2y ago
If you took the right half of his CLB from his second entry[1], and connected each input bit to one of it's neighbors, that's enough to have a computing fabric. Latching them in 2 phase adds delay, but removes the need for worry about timing, as it becomes known. If you put 4 of them in parallel, so each neighbor gets it's own output, it's a BitGrid[2,3], which I've been tinkering with since the 1980s. He referenced an earlier effort 2012 in his video[4,5] that goes down the same detour towards computing fabrics. The HDL for that fabric, might prove useful for programming a bitgrid.[6] I see the appeal of routing fabric and saving silicon, and especially wanting to keep the latency to bare minimum, but the trade-offs aren't worth it in my opinion. Routing becomes a nightmare, as does getting the timing of things right, and watching out for race conditions. If you give up and embrace latency, and the wasting of gates to route signal, you end up with a homogenous, isolinear core. (The same in any linear direction) You can rather easily shift a part in any direction, rotate it, and flip it. You can route around defective cells (assuming the shift register chain doesn't break, of course). Latency goes to hell, but because every single operation is pipelined, your throughput can go through the roof, none of the data lines ever has to make it all the way across the chip, except the clock signals. The shift registers, and only have to load things before the computing starts, so they don't have to be fast at all. [1] https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-1/ https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-1/ [2] https://esolangs.org/wiki/Bitgrid https://esolangs.org/wiki/Bitgrid [3] https://github.com/mikewarot/Bitgrid https://github.com/mikewarot/Bitgrid [4] https://hackaday.com/2012/11/01/discrete-fpga-will-probably-win-the-7400-logic-competition/ https://hackaday.com/2012/11/01/discrete-fpga-will-probably-... [5] https://web.archive.org/web/20150621104100/http://blog.notdot.net/2012/10/Build-your-own-FPGA https://web.archive.org/web/20150621104100/http://blog.notdo... [6] https://github.com/Arachnid/dfpga/tree/master https://github.com/Arachnid/dfpga/tree/master
- convolvatron 2y ago
  seems like you could get pretty far bootstrapping a higher level language. how far have people gotten?
  - bobsh 2y ago
    Not sure if this is quite the same idea, but https://www.greenarraychips.com/ https://www.greenarraychips.com/ ?
    - mikewarot 2y ago
      No, but you could certainly use a GreenArray chip to emulate a BitGrid faster than a normal embedded processor could.

Full writeup (first in series, each post links to the next): https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-0/ https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-0/

mikewarot 2y ago

If you took the right half of his CLB from his second entry[1], and connected each input bit to one of it's neighbors, that's enough to have a computing fabric. Latching them in 2 phase adds delay, but removes the need for worry about timing, as it becomes known. If you put 4 of them in parallel, so each neighbor gets it's own output, it's a BitGrid[2,3], which I've been tinkering with since the 1980s. He referenced an earlier effort 2012 in his video[4,5] that goes down the same detour towards computing fabrics. The HDL for that fabric, might prove useful for programming a bitgrid.[6] I see the appeal of routing fabric and saving silicon, and especially wanting to keep the latency to bare minimum, but the trade-offs aren't worth it in my opinion. Routing becomes a nightmare, as does getting the timing of things right, and watching out for race conditions. If you give up and embrace latency, and the wasting of gates to route signal, you end up with a homogenous, isolinear core. (The same in any linear direction) You can rather easily shift a part in any direction, rotate it, and flip it. You can route around defective cells (assuming the shift register chain doesn't break, of course). Latency goes to hell, but because every single operation is pipelined, your throughput can go through the roof, none of the data lines ever has to make it all the way across the chip, except the clock signals. The shift registers, and only have to load things before the computing starts, so they don't have to be fast at all. [1] https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-1/ https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-1/ [2] https://esolangs.org/wiki/Bitgrid https://esolangs.org/wiki/Bitgrid [3] https://github.com/mikewarot/Bitgrid https://github.com/mikewarot/Bitgrid [4] https://hackaday.com/2012/11/01/discrete-fpga-will-probably-win-the-7400-logic-competition/ https://hackaday.com/2012/11/01/discrete-fpga-will-probably-... [5] https://web.archive.org/web/20150621104100/http://blog.notdot.net/2012/10/Build-your-own-FPGA https://web.archive.org/web/20150621104100/http://blog.notdo... [6] https://github.com/Arachnid/dfpga/tree/master https://github.com/Arachnid/dfpga/tree/master

convolvatron 2y ago
seems like you could get pretty far bootstrapping a higher level language. how far have people gotten?
- bobsh 2y ago
  Not sure if this is quite the same idea, but https://www.greenarraychips.com/ https://www.greenarraychips.com/ ?
  - mikewarot 2y ago
    No, but you could certainly use a GreenArray chip to emulate a BitGrid faster than a normal embedded processor could.