[Libre-soc-dev] Wishbone and House Contract Of Sale Proposition

[Andrey Miroshnikov]

Hi all,

Apologies in advance for the verbosity, wanted to make sure I was clear.

After a discussion with Luke on the shortcoming of Wishbone for the use 
with "House-Contract-Of-Sale", I wanted to write down my idea a bit more 
concretely to see if it makes sense.
See the IRC log here (my nick is octavius): 
https://libre-soc.org/irclog/%23libre-soc.2021-10-28.log.html

# Luke's summary of the problem:
'''
"i am making an OFFER for you to write.  could you let me know, WITHOUT 
any "commitment", if you COULD fulfil this write?"
if the answer is "yes, you COULD fulfil it, then let us proceed to 
EXCHANGE where you absolutely must COMPLETE once we have both agreed to"
this is the kind of protocol needed for caches and for speculative 
execution.
'''

So the important features are (as far as I understand):
1. Make a non-committed request
2. If the request can be granted, acknowledge and *let the requester 
decide* whether to proceed with the request. Once request started, it 
MUST be completed.
3. If the request cannot be granted, respond with busy, and add the 
request to a queue.
4. If at any point, one of the requesters in the queue cancel the 
request, drop the queue starting from this requester, and any later 
requesters.

#My extension to Wishbone is as follows:
##Topology Diagram:

Master0 <-->Arbiter <--> Slave0
             ^^^
Master1 <---|||
Master2 <----||
Master3 <-----|

##Example:
1. There's an ongoing transaction between Master0 and Slave0, so the 
common bus is busy. Master1, Master2, and Master3 are idle.
2. Master2 makes a query for availability of Slave0 by only asserting CYC_O.
3. Arbiter detects an asserted CYC_O on the clock edge, and updates an 
internal FIFO (to indicate which master should be given access to the 
common bus next).
  -Assuming another transaction is happening, the Arbiter uses the 
STALL_O to tell the master that the slave is busy. This is *not covered* 
by the spec, and can be considered an extension of the Wishbone 
protocol. In terms of implementation, the Arbiter could OR together this 
new ARB_STALL_O signal with the slave's existing STALL_O (which is used 
for pipe-lining).
  -The master detects an asserted STALL_I, and thus now has to wait 
before commencing a transaction. The master has to be *modified to 
support use of STALL_I outside of pipe-lining*. The master's FSM could 
then be hardwired to initiate a transfer (move from "Exchange" to 
"Complete" phase of the House-Contract-Of-Sale) once STALL_I is negated.
4. Master3 also makes a query to Slave0. Arbiter detects this, adds 
Master3 to the FIFO, and asserts STALL_O for Master3.
5. Master1 makes a query, Arbiter adds Master1 to the FIFO queue (same 
sequence as for Master3).

There are now three masters in the Arbiter's FIFO queue, and once 
Master0 finishes its transaction, the Arbiter will allow Master 2 to 
start, with Master3 and Master1 waiting.

Here are two potential scenarios:
Scenario 1:
1. Master0 finishes its transaction. Arbiter negates STALL_O for 
Master2, FIFO output is shifted by one. Master3 is now next in the queue.
2. Master2 detects the negated STALL_I, and (depending on the FSM 
implementation) starts the transaction by asserting STB_O. In addition, 
LOCK_O is asserted to *guarantee that neither the Arbiter or Slave0 will 
interrupt the transaction*.

Scenario 2:
1. Master3 decides to cancel the transaction by de-asserting CYC_O while 
the common bus is still busy.
2. Arbiter detects a negated CYC_I from Master3, and clears the FIFO 
entries for Master3 and later. This causes Master3 and Master1 to lose 
their place in the queue.
3. Master2 remains in the queue, waiting for Master0 to finish.

One problem is present with scenario 2. Master1 is still asserting 
CYC_O, even though the Arbiter has cleared the FIFO queue. Perhaps the 
Arbiter should assert RST_I or ERR_I (which will also act as a reset, 
clearing the master's FSM) of Master1?

Let me know if this makes sense to you.

In terms of Wishbone modification, only the STALL signal's state has to 
be considered by the master outside of pipelined mode, otherwise both 
the master and slave will be compatible with standard Wishbone.
Most of the implementation is with the Arbiter.


Andrey