Part 87: Assignment #AC10: Logic Board

Logic Board

NETHUNS is almost complete, and I've been able to puzzle together what the goal of it all is. We're making a sort of... I guess you could call it a hybrid biological and machine-based 'cortex'. The intent is to create a distributed system with sufficient complexity to provide a means of emulating the kind of networks found in the brain, with the intent to model emergent properties of consciousness.

In plain English: we're making a machine capable of true thought.



Which means I have one more job on my hands before all this is complete.








This board is a little different than pretty much every other design I've worked on so far. Those neural processors in the middle of the board are fixed components. Not only are they not movable, I can't route wires under them, either. Given that the pump motor inputs are on the opposite side to the LOGOS and TELOS neural processor outputs, and there's only a one-wire gap to get from point A to point B, I have a small problem on my hands.
(By the way: 'logos' is Greek for 'reason', and 'telos' is Greek for 'purpose'.)

My first order of business is definitely going to be to get something reading the output of the neural processors and passing a go/no-go signal to the pump inputs. Because either processor can output a thought packet at any point, the MCs that handle the pumps will have to be notified whether or not to flush the flow of... whatever's in those tubes... every time unit.

I'll try and get as far as that, because those long-ass packets are staring me in the face, dauntingly. 25-unit thought packets are big enough that I don't know what I'll do to handle storing them - because I WILL have to store them while I process the checksum. Otherwise, I risk sending on a corrupted packet.

For now, let's work on pumping some cool neural goo.

[ ~ ]





   

 

Here's my first stab at it. The MC6000 on the left side checks both of the neural processors for values that aren't -999. (It's kind of like dealing with a radio input, really.) If it finds a value that's part of a thought packet, it'll send that value (and the rest of the packet) out on x0 to... I don't know what yet.
The MC will also send the first value it gets from each processor in a time unit, along the wire that leads to the pump MCs. It'll do it in the following sequence: Logos's value, then Telos's value. The reason for this is that the pump MCs are designed to respond in a staggered order.

The pump MCs themselves are pretty simple. Each pump MC reads a single value from the input-processing MC each time unit - but the lower (Telos) pump has an extra slx that will make it always lose the race to get the first value. This ensures that the Logos pump MC gets Logos's value, and the Telos pump gets Telos's value. In both cases, if a pump MC sees a value that's not -999, it cycles the pump immediately and resets its countdown, which is stored in acc. Otherwise, it will subtract from its countdown as normal, and cycle the pump when it hits 0.

At this point, the next step is to actually store and checksum the packets. This is tricky - I don't see an obvious way forward just yet - but I'll play around with the design. With luck, I'll be able to make some headway soon.

[ ~ ~ ]





   

   

This design took longer to piece together than you'd think. At one point, I went off chasing a variant design that had each MC6000 attached to one (and only one) neural processor, and both of those MCs would do the checksum for their neural processor's output in-chip. I abandoned that design for a few reasons, the biggest being that I couldn't get things to synchronize properly.

This version is a step forward from the previous one I blogged about. The input-handling MC's code has been finalized; Kamran was helpful enough to inform me that LOGOS and TELOS should never both generate a thought packet on the same time unit, so the input MC will send off any not-minus-999 input to the new MC6000 above it, then pass along a single -999 to indicate that it's done.

The new MC6000 does checksumming. If it gets a -999 value at the start of the time unit, it concludes no thought packet is present and goes to sleep. Otherwise, it moves the input into its acc (as well as passing a copy of the input out on its x0 to be stored and processed in an as-yet-undefined way), then performs the checksum on the rest of the input as it arrives, continuing to pass copies of the input values along.
This continues until the checksummer MC gets (and passes along) a -999, signaling the end of the input. After this happens, the MC will output its acc (the completed checksum) forward on x0, which the storage MC (to be designed) will interpret as a 'go' or 'no go' signal depending on whether the result is 0 or not.

There's one other change to this design: it turns out I had the wrong initial timing on the pump MCs. It turns out their acc counters need to be set to 5 at the start, not 4, to get the desired behavior.


So far, so good. But I'm on to the hardest challenge of all. I need to store that thought packet while it's being checksummed, and read it out afterwards - and I've got to do it in an area of board space the approximate size of a postage stamp. (Maybe smaller, after fabrication.)
One possibility is putting everything in a single memory chip - packet contents, except for the checksum, appear to be single digits, so this could work if the 24 non-checksum values double up and share two digits to a memory cell. But I'm not sure if it'll work - and, once again, I'll have to play around with the design before I can get something that behaves properly.

So: once more to work. And once I crack this, we should have a finished design, and the final piece to possibly the biggest advancement in computing the world's ever seen.

[ ~ ~ ~ ]

Here it is. It turns out that sometimes, the simple solutions are the best ones.





   

 

 

This is definitely the final design. I haven't changed anything about the input-handling, checksumming, or pump MCs (except for commenting out the slp 1 on the TELOS pump MC, as it doesn't need it with the slx it has at the top).

The big, obvious change from the last version is - the storage mechanism is complete. I went with two memory chips, instead of one, because it was easier to do. The storage MC alternates between the two RAM chips, storing each value it receives, first to one, then the other. This includes the -999 the checksummer MC sends along to indicate 'end of input'.
Once the -999 is stored, the storage MC will make sure that the checksum it receives from the checksummer is 0. (If it's not, it will stop and start over, waiting for the next packet to store.) Once the checksum is confirmed, the final step starts: reading out the stored packet.

Once the packet, the checksum, and the -999 to mark end-of-input have been stored in the RAM chips, the input has taken up a total of 26 memory slots, 13 in each RAM chip. This is exactly enough that I can use a single command, mov x1 x2, to reset the RAM chips' memory pointers to the the start of their portions of the packet. (It works because the pointers will be pointing to the one slot that's not used for anything in each memory chip, so the instruction makes the pointers wrap around to the beginning.)

From there, the storage MC can read out the values from the RAM chips and output them to mesh-data, stopping once it reads a -999. Then, the packet output is complete and the device can wait for the next thought packet.

In total: ¥25, and 2979 average power per run. And I've made a contribution to the annals of experimental computing.



Past this point, my part of the NETHUNS project is done, but I'll keep you updated for the grand finale: putting everything all together.

Expect another post in a few days. Talk to you then?