3d_gpu/architecture/6600scoreboard/discussion.mdwn

   1 # Discussion
   2
   3 TODO: add links to images, here
   4
   5 # Shadow Matrices and Contracts of Sale
   6
   7 we are having some difficulty in effectively communicating the
   8 "contract" - the API - that is required for an out-of-order processor
   9 to become an effective parallel engine that happens to respect
  10 sequential instruction order in what is termed a "precise exception"
  11 fashion.
  12
  13 i began the technical discussion here:
  14 https://bugs.libre-soc.org/show_bug.cgi?id=397
  15
  16 i wanted in particular to raise the observation of an analogy when
  17 buying goods and services - or, better - a house.
  18
  19 the current Wishbone interface uses the following contract language:
  20
  21     "hello {insert person here}, i love your house.
  22     i will offer you $$$$$ for it, RIGHT now.
  23     this is a take-it or leave-it offer.
  24     i require your answer immediately.
  25     i will transfer the money immediately to your bank"
  26
  27 most people, unless the value offered was extremely high, would shut
  28 the door in a hurry, and probably call the police.  even then, they'd
  29 probably be backing away.
  30
  31 yet this protocol - this type of contract - is a fundamental part of
  32 computer science!  it's used in many many places.
  33
  34
  35 what we *actually* need is *this* protocol:
  36
  37     "hello {insert person here}, i love your house.
  38     if i was to give you an offer of $$$ for it, what would you say?
  39     i can go away and give you time to think about it.
  40     i will come back later for your answer
  41     if you agree, we can then exchange and sign contracts.
  42     or, at any time (including right now), up until we exchange
  43     contracts, you can say no"
  44
  45 *THIS* is the protocol that we need for our processor, in *ALL*
  46 aspects and at *ALL* levels.
  47
  48 the contract is:
  49
  50 * speculative (an offer)
  51 * it is possible to offer MULTIPLE contracts to MULTIPLE people (view
  52 several houses)
  53 * it is possible to even move forward right the way to exchange of
  54 contracts - in parallel
  55 * it is possible to even *buy* multiple houses in parallel and to have
  56 multiple outstanding contracts.
  57 * it is possible for anyone to pull out - at any time - on any of
  58 those contracts.
  59
  60 this basically illustrates very clearly that the augmented-6600 system
  61 that we are deploying is in fact a very simple and well-known contract
  62 negotiation technique!
  63
  64 where the "precise" part comes into play (where the Shadow Dependency
  65 Matrix is activated) is where the analogy breaks down.
  66
  67 the Shadow Matrix preserve the instruction order where, if one of the
  68 above "contracts" is cancelled, any contracts that were *INITIATED*
  69 after the time that the *cancelled* contract was cancelled, those
  70 other contracts are *ALSO CANCELLED*.
  71
  72 *this* is how we achieve "precise exceptions".
  73
  74 let's go back to that contract terminology, illustrating the shadow diagram here
  75 https://libre-soc.org/3d_gpu/shadow.jpg
  76
  77       "hello {insert person here}, i love your house.
  78              ISSUE and SHADOW is raised
  79        if i was to give you an offer of $$$ for it, what would you say?
  80             REQ_READ is asserted
  81        i can go away and give you time to think about it.
  82             GO_READ asserted to indicate "i'm thinking about it"
  83        i will come back later for your answer
  84            REQ_WRITE internal condition is asserted
  85            but because SHADOW is held, REQ_WRITE does
  86           NOT go out [the contract is NOT signed]
  87       if you agree, we can exchange and sign contracts.
  88          "SHADOW_SUCCESS" flag is raised, SHADOW is dropped.
  89       or, at any time (including right now), up until we exchange
  90       contracts, you can say no"
  91         "SHADOW_FAIL" flag is raised, GO_DIE is asserted for one cycle.
  92
  93 something like that.  it's not quite like that, but it's close.  for
  94 example: GO_READ could indicate that the potential seller is happy to
  95 review the contract.  GO_WRITE could indicate "the contract has been
  96 signed".
  97
  98 or, if we apply this to the LD/ST protocol (which may be more accurate
  99 an analogy), "GO_ADDR" may be considered "i'm thinking about it",
 100 "GO_WRITE" could be "the solicitor is drafting the contract" and
 101 "GO_STORE" could be "the contract is signed".
 102
 103 however the important part is to understand and appreciate - *at all*
 104 - that the 6600 precise-augmented protocol is a *standard contract
 105 negotiation* procedure that is *required* to have *two separate
 106 phases*:
 107
 108 * an "offer" phase, being the start of the transaction.
 109 * an "exchange" phase, during which the "offer" may not change.
 110 * a recognition of "completion" being the end of the transaction.
 111
 112 thus we have actually 2 distinct phases (offer, exchange) delineated by terminology that marks the time at which the FSM transitions (offer, exchange, complete).
 113
 114 this is absolutely fundamental to understand when it comes to our
 115 architecture.  proposals to use technology and APIs that are of the
 116 "standard" (simple) protocol - as implemented for example by Wishbone
 117 - *will not work* for us.
 118
 119 the problem that we have is that whilst the ALU "result-generation"
 120 pipelines do not interact with the "Shadow" system in any way (they
 121 are simply subjected *to* cancellation), the following *do* interact
 122 with it:
 123
 124 * Branch
 125 * Trap
 126 * LOAD/STORE
 127 * Predication (when we get to it)
 128
 129 LOAD/STORE in particular is complex in that there are successive
 130 cascades of ever-faster caches (L0, L1, L2, L3) that have protocols
 131 that must be respected, *all whilst preserving this contract*.
 132
 133 it is particularly unfortunate, then, to find that after careful
 134 consideration, Wishbone's simple protocols are *fundamentally*
 135 incompatible with what we need.
 136
 137 we will therefore need to design a Bus Protocol that does actually
 138 work for this processor, based on the standard Contract of Sale to
 139 help guide us in that design.
 140
 141 # Scoreboard and LDST Questions
 142
 143 <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-June/008253.html>