!bitstream ( startpoint endpoint --) takes the plain-text human readable routing path coordinates as parameters, and maps them to bitstream using Mill’s Methods, an approach similar to the one described in the paper From Bitstream to Netlist. !bitstream effectively maps netlist to bitstream and stores it to the live PSoC over the SWD interface or into a configuration blob.
bitstream@ ( endpoint -- startpoint) takes the endpoint reference and gets the startpoint mapped to it. This is the “from bitstream to netlist” word.
endpoint need not be an individual routing switch.
Mill’s methods work at different levels of granularity. If they can’t
yet isolate a switch, maybe they can isolate a tile. Conversely, if bits
within a register have been isolated but not the register bytes, the bytes
can be viewed as a single overlapping site because we’ve found how the
pattern repeats across those tiles. The pattern may repeat across tiles
with identical structure or in the same tile but across different
projects/bitstreams. The endpoint could also just be: The PSoC 5LP.
So, these fetch and store words don’t just fetch and store to a memory address, they also do a lot of heavy lifting. After !bitstream and bitstream@
have reverse engineered the bitstream automatically, these routing
words can be compiled to a simpler formula. Looking at Mill’s
Methods you might notice that they look a lot like Quine-McCluskey
or Karnaugh maps in that the mapping function is determined by what
varies and what doesn’t. Sounds like I could even make them defining
words for defining new @ and ! words.
I mentioned in my gelFORTH talk on Forth Day that on a CPLD or FPGA device with a configurable routing fabric, @ and ! do not just fetch and store values from some memory address. On such a configurable device the ! must actually configure a route to the said resource and @
references that variable source of data. These words are equivalent but
sometimes they do more. I may just rename the minimized, device
resident forms of the words !bitstream and bitstream@ to just ! and @ Parallelism is implicit by the way.
I'm cross-referencing the TRMs with the DSI patent by looking at how the addressing scheme connects the two in a way that makes mathematical sense... and well, I can now compile an XOR gate from gForth to the UDB + routing/DSI system and light up the blue led when I set either of the input pins with my Bus Pirate.
As I had hoped, the PLDs are also reconfigurable during operation, not just the DSI through the Dynamic Configuration RAM.
At first I tried to halt the PSoC before writing the configuration bytes over SWD. But for this to work, I needed to wipe the entire PSoC and write the configuration bytes over SWD withouthalting.
I've been doing a deep brainstorm on how best to factor the UDB, Routing, and DSI code such that it will work well for partial dynamic live reconfiguration, or in a way, compiling Forth words to Boolean algebra (the CPLD) from the interpreter. Once I've figured more of that out, cleaned-up my experiments, and reached some stability in my approach I think I can release the code to the world. Yay! Thanks for reading!