While fooling around with the VGA birds demo, I had several different RDFAST lines in the initialization section, all of which were commented out but one. I accidentally ran the code once with all the RDFASTs commented out, and it seemed to default to a RDFAST of all of hubram: the image would quickly wrap around, with regions of junk and black.
Now I'm curious and want to explore ways in which I can abuse the hub FIFO. Chip, please don't answer any of the questions in this paragraph, since I'm sure you have much more important things to do; they're just examples of things I want to try. What if you issue instructions read from or write to the FIFO while it's in the opposite write/read mode, or while in hubexec or XBYTE mode, or while the streamer is running? What if you start the streamer while in hubexec? If you call RDFAST with D set after finishing a WRFAST with stuff still in the buffer, can you sneak in a few more writes before the FIFO runs out and switches directions? Can you store constants inside hubexec code with RFVAR if you account for pipelining? If you get too creative, can you crash the FIFO? Can you crash the whole cog, and will a cogstop/coginit fix it or is a reset necessary?
My question is this: is this behavior well-defined in the verilog, i.e. is it guaranteed to be the same on an FPGA, the P2ES, and chips from the second run? Or might the synthesizer decide to make these unintended cases do different things on different versions of the chip? In other words, if useful behavior through FIFO abuse is found possible on my P2-ES, will the same tricks work on the final silicon?