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

[lkcl]

On October 29, 2021 4:44:08 PM UTC, Richard Wilbur <richard.wilbur at gmail.com> wrote:
>On Thu, Oct 28, 2021 at 5:52 PM lkcl <luke.leighton at gmail.com> wrote:
>> On October 28, 2021 6:32:04 PM UTC, Andrey Miroshnikov
><andrey at technepisteme.xyz> wrote:
>>
>> >As for speculative execution, I'm not too knowledgable as to why the
>> >queue is dropped. I think of it as a failed branch-prediction, where
>> >the
>> >cpu pipe-line would have to be flushed,
>>
>> yes.  so for in-order, you think of the pipeline as being a
>one-to-one direct preservation of the issue order.
>>
>> but... why would an OoO be any different??
>>
>> it wouldn't, would it?
>>
>> therefore, the Shadow system still has to preserve the issue order,
>doesn't it?
>>
>> and, so, despite the data structure not being one-to-one "a
>pipeline", the cancellation still has to drop everything that was
>issued *after* the exception /branch-predict-fail.
>
>I think I understand the branch prediction/speculative execution and
>out-of-order execution.  That sounds like the domain of the processor
>instruction decoder and pipeline.  The scenario with the wishbone bus
>arbiter, though, seems to be contention for a shared resource bus by
>multiple bus masters.  The arbitration scheme outlined above treats
>them all very nearly as slaves of one master.

yes, that would be a problem in a multi-issue environment.

therefore there has to be a way to convey *multiple* simultaneous requests, and that means multi-input (and probably multi-output) arbiters.


>I can see dropping all the speculative execution results from a branch
>prediction once it has failed.  That would seem to be the domain of
>one bus master.  I don't see how the other bus masters must
>necessarily have their bus cycle requests predicated on a previous
>request from a different bus master.

if there are multiple paths so as to avoid routing contention.

>Furthermore, if the results of speculative execution which need to be
>dropped involve several different bus masters, this seems like a
>passive aggressive way of notifying them by dropping their bus cycle
>reservations.  I would recommend a more proactive method of notifying
>the functional units and coprocessors of the need to drop a certain
>set of results and depend on the notified functional units and
>coprocessors to drop their own bus cycle reservations as needed.

no: the Dependency Matrices are already designed and it took a year to work out how it is done.

there will be *no* changes to how it is done.

what you might be describing might fit with how it is done, so let's go through it.

* Multi-issue Transitive Dependencies are recorded
  precisely and exactly in issue-order in the DMs.

* some of those operations (LD/ST, FP exceptions, branches) MIGHT have to be cancelled so they raise full transitive "Shadows" right the way across not just their instruction but ALL instructions issued after that point.

* this Shadow "Write Commit Hold" ABSOLUTELY MUST WITHOUT FAIL propagate and be respected 100% absolute without fail absolute 100% under all and any circumstances right the way through all resources covered by that "Shadow"

(in the case of register write that's easy to do, just hook into the "picker", but for Memory it is ABSOLUTELY CRITICAL that even the Bus Architecture, right the FULL way through the ENTIRE memory system, respect the "hold-off". caches, buses, virtual memory, everything).

* notification of a failure to be able to process a given request requires broadcasting that "failure" throughout EVERY subsystem currently covered by the corresponding "Shadow".

this is not optional, Richard.

* furthermore it is a hard requirement that any failing Shadow covering later-issued instructions also pull absolutely every single later-issued instruction as well.

this is not optional either.

it doesn't matter *how* that notification occurs: it could take 1 cycle, it could take dozens, but it DOES have to occur and it does have to be respected: under no circumstances whatsoever is any subsystem (bus, arbiter, regfile, peripheral) permitted to ignore that cancellation request, nor is any subsystem permitted to disregard the issue-order.

(fascinatingly, once the exception is cleared (Exchange Phase negotiated successfully) the actual commit order does not matter, what matters is that each of the multi-issued contracts proceed *to* Completion)

>If the current sale (buyer 1) falls through because of a problem with
>financing and buyer 2 retracts their offer, I fully expect my offer to
>be considered.  I would not expect that buyer 2 retracting their offer
>would invalidate my offer.


right.   ok.  you've misunderstood the use of the House Contract here when it comes to multi-issue and to preservation of issue order.

the example is more:

* i am a property speculator
* i see 3 houses for sale
* i know (in advance) that i can:
  - only buy (and flip) house 2 if i have bought (and sold) house 1
  - only buy (and flip) house 3 if i have bought (and sold) house 2
 - this is our "issue order".  it is our "program being executed".

(of course i do not tell the sellers of my little enterprise, they might get pissed, so i run 3 totally separate lawyers - 3 Memory Buses)

* i find buyers for houses 1 2 and 3
* i make offers for houses 1 2 and 3
* my buyers all agree to deal
* my 3 lawyers all communicate back to me
* BUT...
* before i sign the contracts, Seller of House 2 PULLS OUT (the equivalent of a LD/ST Exception)

at this point, because of my little deals with *my* buyers, knowing that *i* cannot buy House 3 without the money from House 2, i not only lose the deal on House 2 but HOUSE 3 AS WELL.

but, happydays, at least House 1 went through.

those 3 deals were ALL SIMULTANEOUS.  they were all  in the same week/day/whatever.

i had to use 3 lawyers (3 Memory Buses) to do it.

the example that you gave was more like a Symmetric Multiprocessing example, where there was interaction between *two* separate cores.

this is NOT what we are discussing: SMP interaction and SMP synchronisation of Memory Models is a completely different issue, handled by completely different rules.

the preservation of issue order is NOTHING TO DO WITH ANYONE ELSE.  nobody knew it was *WE* who had a Dependency Order.  not the buyers, not the sellers, not the lawyers, not the postman delivering the contracts.

it is *WE* who dictate, based on our "finances" (cannot flip house 2 without the sale proceeds from house 1) what the order is and that it must be preserved.

not the Bus, not the Memory, not the Arbiters.  they all don't actually care, at all.

but it is the *instruction order* which absolutely must be preserved without fail, and that in and of itself defines, categorically, that yes, the ability *to* preserve the original instruction order must, in fact, propagate right the way through all subsystems all the way even to peripherals.

l.