I will forever be grateful to Bunnie, he pointed me in the direction of murmurhash when I needed something to help with the integrity of a section of memory in a microcontroller. Legend.
Emulating the RPI PIOs instead of the TI PRUs is really a miss.
The PRUs really get a bunch right. Very specifically, the ability to broadside dump the ENTIRE register file in a single cycle from one PRU to the other is gigantic. It's the single thing that allows you to transition the data from a hard real-time domain to a soft real-time domain and enables things like the industrial Ethernet protocols or the BeagleLogic, for example.
Tooling for the RPI PIO design is probably a bit more accessible than the TI PRU situation. I'd say its not really a miss - more of a necessity given bennies' proclivity towards open/available tools. Getting access to architecture details of the TI PRU would necessitate an NDA, would it not?
> Getting access to architecture details of the TI PRU would necessitate an NDA, would it not?
Nope. All the information is right in the publicly available architecture manuals. However, you don't need to copy the PRUs, per se. All this can be done with RISC-V.
The important parts are deterministic execution, the register file sideload between paired processors, and, possibly, single cycle instruction execution. None of these are precluded by using RISC-V.
And, given how large his PIO stuff is, I'd argue it would be better to do this with RISC-V.
What are your thoughts on efficiency? BIO vs PIO implementing, say, 68k 16-bit-wide bus slave. I know i can support 66MHz 68K bus clock with PIO at 300MHz. How much clock speed would BIO need?
It depends a lot upon where the processing is happening. For example, you could do something where all the data is pre-processed and you're just blasting bits into a GPIO register with a pair of move instructions. In which case you could get north of 60MHz, but I think that's sort of cheating - you'll run out of pre-processed data pretty quickly, and then you have to take a delay to generate more data.
The 25MHz number I cite as the performance expectation is "relaxed": I don't want to set unrealistic expectations on the core's performance, because I want everyone to have fun and be happy coding for it - even relatively new programmers.
However, with a combination of overclocking and optimization, higher speeds are definitely on the horizon. Someone on the Baochip Discord thought up a clever trick I hadn't considered that could potentially get toggle rates into the hundreds of MHz's. So, there's likely a lot to be discovered about the core that I don't even know about, once it gets into the hands of more people.
I specified slave specifically because slave is a LOT harder. Master is always easy. Waiting for someone else’s clock and then capturing and replying asap is the hard part. Especially if as a slave you need to simulate a read.
On rp2350 it is pio (wait for clock) -> pio (read address bus) -> dma (addr into lower bits of dma source for next channel) -> dma (Data from SRAM to PIO) -> pio (write data to data bus) chain and it barely keeps up.
If there's a single rising edge on the bus that you can use as quantum trigger, then, the reads turn into as series of moves into a FIFO, and the response can be quite fast. The quantum-trigger-on-GPIO was provided to solve exactly the problem you described.