Suggested improvements to the Ibex revoker

[davidchisnall]

Currently, the Ibex's revoker has a single control register, which contains the epoch and the running status. There are a few things that would make this more useful:

• [ ] Making the epoch 32 bits and extending it. We currently wrap the revoker with software that fakes a 32-bit epoch.
• [ ] Reporting the running state in the epoch. The Flute version uses the low bit of the epoch to indicate running status, which lets us use arithmetic for a few things in software that would otherwise require branches.
• [ ] Making the response to writing to the 'start' register stateless. With the current revoker, we have to read the status then compare and then sometimes write back the response. With the Flute version, we just write to the 'go' register: if revocation is already running, this does nothing.
• [x] Providing an interrupt when revocation has finished. The allocator currently has to poll for completion of a revocation pass, this would let threads that are blocked on revocation sleep.

[kliuMsft]

The memory mapped register block is actually implemented outside of the ibex core (similar to clic). So we will probably implement the suggested changes when make the arty a7 FPGA release.

[kliuMsft]

Also - note that if we make the "start" bit stateless, firmware will need to clear the bit before the hardware state machine completes, otherwise the state machine will immediately restart after it completes.

[davidchisnall]

On Flute, it isn’t really a register, it’s an edge-triggered signal. Writing to it starts the operation, but reading from it doesn’t do anything.

[kliuMsft]

Ok, I am making it a single-cycle pulse triggered by writing a '1' to the bit location. The pulse will kick off the hardware revoker if it is currently idle, and if the revoker is running the pulse will be ignored

[kliuMsft]

@davidchisnall, shoudl we close this one?

[davidchisnall]

I believe all of these are now implemented.