a Forth for interactive hardware design on the PSoC 5LP
Adobe Portable Document Format - 7.46 MB - 11/20/2016 at 18:32
Lately I’ve been writing
! 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
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
I mentioned in my gelFORTH talk on Forth Day that on a CPLD or FPGA device with a configurable routing fabric,
! 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@ to just
@ Parallelism is implicit by the way.
Thanks Ed0 for pointing me to that paper!
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
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.
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!