Bitgrid and Isolinear Memory

In exploring the design of a BitGrid cell to fit within the confines of a TinyTapeout project, it quickly became apparent that the shift registers to hold all of the programming data for a cell were the majority of the silicon.

It also has become apparent that in order to utilize BitGrid in an actual application, there need to be blocks of memory embedded into the cells.

I decided that it might be interesting to allow the use of the shift registers that normally hold the contents of the BitGrid cell's LUT as memory. Adding some multiplexing and a few more shift registers could greatly increase the functionality of a cell without destroying the homogeneity and logical consistency that makes the BitGrid so easy to think about and use. For now, I'm calling it IsoLinear Memory, as it would add a line of memory into any bitgrid array on demand, in any direction, uniformly.

 Here is the cell design at present, as I learn to use KiCad 8.0. The cells get their inputs from IN_A through IN_D, and are clocked in to latch U6 at the rising edge of Clock_A.  The state of the LUT table is stored in U2 and U3, and the value selected is fed through either U4 or U5 to the output multiplexer.

The last output cell is also sent to the multiplexer.

I'm going to add logic to allow shifting the LUT contents out, subject to the contents of U1.

That's it for today.

BitGrid meets the Advent Of Code

 I'm a big fan of the Advent of Code, in the past, I used Lazarus/Free Pascal as my language of choice, you can see the code here. So, this year, I'm going to update the BitGrid engine, and do whatever is required to get code to run in the virtual BitGrid. You can follow my progress here.

This requires an ecosystem to support me. I've got to add I/O, programming and Debug SubSystems to the BitGrid engine. I've got to figure out a programming language, and a compiler, router, etc. I hope to get all of the 2023 problems done before Advent of Code 2024 starts.

Making a fresh start, in Pascal

I've recently been made aware that there is a page devoted to BitGrid in the Esoteric Languages wiki. Needless to say, this came as a bit of a shock to me. I was particularly impressed with the working example of the game of life implemented in a BitGrid.

I've let this project sit far too long, and since I've got nothing but free time these days, I'm pushing at implementing a simulator for the BitGrid, in Lazarus, which is a GUI builder based on Free Pascal.  The GitHub repository for the project has the latest code, which isn't much to look at for the moment.

I'm hoping that I can sustain small bits of progress that add up over time.

Eventually, I'll have a system to really allow programming and evaluation of programs. It would then be on to a chip design, and onward to Exaflop computing. ;-)

A chance to make a bitgrid chip appears suddenly

 This thread on Hacker News pointed to a Google funded project to let people design their own chips. The window is already half way over, so I need to learn chip design in the next 2 weeks or so. It should be fun.

Applications - image processing, survey plane

One of the long term issues with having a technology, which should be much more powerful than existing hardware is finding an appropriate use scenario for it.  Today one occurred to me on my commute.

I've been doing a lot of experimenting with synthetic focus imagery. Having recently written a tool to help me do image matching, I've begun to appreciate why Hugin gets so bogged down generating and matching control points. The cross correlation of 2d image sets is a huge resource hog. Fortunately, the bitgrid  should be quite capable of handling it, because the computations are data local, with the only global data being the source material which loads once per frame, and the output maximum coordinates, again once per frame.

I imagine a remote control glider with a pair (latter an array) of cameras feeding into a system which correlates the images to generate altitude data. It should be possible once this 2d triangulation is done, with hints from the navigation system, to then generate a 3d image of the area below, with altitude information at least as accurate as the pixel resolution allows.

If the plane is slow and stable enough to allow multiple overlapping images of the same area, it should be possible to derive super-resolution images using Richardson-Lucy deconvolution.

It all hinges on the question of power consumption of a single bitgrid cell. Something I don't know, but an experienced IC designer should be able to figure out on his lunch break.

Spreadsheet iteration and other linguistic hits

I continue to search for ideas that are close to the BitGrid, and I've come across Amir Hersch's mention of the need for a "spreadsheet iterator" in his blog post titled "More versus Faster"... the BitGrid would be a good spreadsheet iterator.

I'm still trying to figure out the cost/benefit ratio of getting rid of all routing in an a real world FPGA device. As an abstraction tool, it's totally cool and cost effective, as there are no static or dynamic power costs in a thought experiment. 8)

As an intermediate stage of compiling a design, there are time costs in translations, but they might be worth it when it comes to the ability to move elements of a system design orthogonal to other design decisions.

Time and persistent effort to get the questions answered will tell. I'm glad I'm still asking questions and pursuing the goal of getting a BitGrid chip built

Oh... another linguistic hit  "hardware spreadsheet" as mentioned here.

Reconfigurable Systolic Array

I've been searching, and searching, and searching for anything that matches the Bitgrid in architecture... and I've found nothing... today's Google search is reconfigurable systolic array.

I get a lot of results, mostly academic (which means they are behind a paywall, and thus worthless). It does give me a better way to describe the bitgrid, though.

The bitgrid is a fine grained homogeneous 2d reconfigurable systolic array and/or mesh. It will be verified as to utility by simulation. I hope to popularize it with blogs, social media, and making a game out of it.

It is my belief that the flexibility of the LUT based approach more than makes up for the lack of dedicated routing and compute blocks.  Any inactive elements of the circuit are unclocked, and thus should be at very low power.

I'm not sure if I'm going to be a good fit for the OHPC project or not, I've got until August 6 to write a proposal.