• fetch and store words that do more

    Andreas • 02/06/2017 at 00:24 • 0 comments

    Lately I’ve been writing @ and ! words that do more. For instance, I have the Cypress PSoC 5LP bitstream that I am reverse engineering for gelFORTH:

    !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.

    Thanks Ed0 for pointing me to that paper!

  • UDB XOR gate: from input pins to blue led (free/libre)

    Andreas • 07/01/2016 at 22:50 • 0 comments

    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 without halting.

    I used the mostly complete (?) openocd support for the KitProg and PSoC 5LP (by @cyrozap and Andreas Färber) to read and write the configuration bytes from extensible Forth over the tcl rpc interface.

    XOR gate: input pins 1'6 & 1'7 to output led 2'1

    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!