| lkcl | https://freenode.irclog.whitequark.org/nmigen/2020-07-25#27585807 | 22:14 |
|---|---|---|
| lkcl | hi awygle. yes, about the "house contract of sale" - offer, exchange, complete | 22:16 |
| lkcl | it allows a couple of crucial things to be done. | 22:16 |
| lkcl | one is: if the bus has a memory map associated with it, and that you consider part of the "offer" phase, you don't have to tie up the bus waiting for an error message you *know* you are going to get because it's an invalid address | 22:17 |
| lkcl | so if you have a "is this address even valid" function, it can be used to answer the "offer" question, "if i *was* to make this request, at this address, *would* it succeed?" | 22:18 |
| lkcl | the second improvement comes when you have either multi-issue, an out-of-order, or a SMP, or, well.. anything-other-than-the-simplest-of-simple-designs | 22:19 |
| lkcl | with an "offer-exchange-complete" bus protocol, you can request things like: "if i were to make a request for this virtual memory-mapped page, *would* it succeed?" | 22:20 |
| lkcl | and that becomes extremely important for multi-issue because if there's anything that is operating in parallel, out-of-order, you absolutely cannot have a *future* instruction succeed but an earlier one fail. | 22:21 |
| lkcl | so the "offer" part gets you a GUARANTEE that when you move to "exchange-and-complete" phase, it's GOING to work, 100%. | 22:21 |
| lkcl | then, you can do the "offer" parts out-of-order, determine BEFORE any damage is done, which ones will succeed | 22:22 |
| lkcl | check their order | 22:22 |
| lkcl | stop at the one that has a "fail" | 22:22 |
| lkcl | and issue all the others, knowing *full well* that even if they're actually actioned out-of-order, you have a 100% GUARANTEE that they will complete | 22:23 |
| lkcl | without that protocol, you have to do this: | 22:23 |
| lkcl | * issue 2, 3, 4, 5, ... 100 LOAD operations | 22:24 |
| lkcl | * do operation 2 | 22:24 |
| lkcl | * do operation 3 | 22:24 |
| lkcl | ... | 22:24 |
| lkcl | zzzz | 22:24 |
| lkcl | finally do operation 100 | 22:24 |
| lkcl | and it *has* to be done in-order, one at a time, taking potentially hundreds of cycles, because you have no idea whether one of them would fail. | 22:25 |
| awygle | hm, ok, that makes sense. so how do you actualize this on top of AXI, and why can't you on top of WB? | 22:30 |
| lkcl | i've _heard_ that AXI has "identifiers", i don't know the details | 22:30 |
| lkcl | wishbone only has "stb / cyc / ack". | 22:31 |
| lkcl | there is no signal to say "please let me know *if* this read/write operation *would* succeed". | 22:31 |
| lkcl | as in: "don't actually do it, just tell me if, *if* you were to do it, *would* you be able to 100% successfully complete it... *WITHOUT* and that's the important bit *WITHOUT* actually doing the request" | 22:32 |
| lkcl | wishbone *only* has "do this read, take it or leave it" and "do this write, take it or leave it" | 22:32 |
| lkcl | now, now, now. | 22:32 |
| lkcl | it's the game host / scammer protocol :) | 22:33 |
| lkcl | once-in-a-lifetime, give me your answer now, now now | 22:33 |
| lkcl | TileLink i understand has some sort of cache coherence protocol, which will also be an "offer / exchange / complete" | 22:34 |
| lkcl | it'll be along the lines of, "if i make this cache request *in the future*, will you guarantee to hold that line for me?" kind of thing | 22:34 |
| lkcl | it requires additional state, basically, beyond a simple single handshake (stb/ack) | 22:35 |
| awygle | hm. admittedly i'm not especially familiar with AXI but i don't see anything in the spec that maps _directly_ to the kind of "speculative" transaction operations you're describing | 22:36 |
| lkcl | from what i gather - and bear in mind i've only glanced at code which *sigh* wasn't documented - i believe there is separate "control" protocol messaging separate from "data" read/write? | 22:38 |
| lkcl | and that there is space for unique incrementing identifiers, and a guarantee in the protocol that the responses must come back in order | 22:39 |
| lkcl | i would imagine that it would be possible to "create" an offer-exchange-complete protocol on _top_ of that "control message passing" | 22:39 |
| awygle | i see | 22:40 |
| awygle | i wonder if it is properly impossible to build such a thing on top of WB, or if one could leverage the seldom-used "tag" portions of the spec to do so | 22:40 |
| lkcl | yeah this thought occurred to me | 22:40 |
| lkcl | maybe... to use/abuse the... what was it... have to open the WB4 spec PDF... | 22:41 |
| lkcl | section 3.1.6 | 22:41 |
| lkcl | create a signal that's tagged as cycle or something | 22:42 |
| lkcl | however even when looking at the rules for the different types | 22:42 |
| lkcl | you have to obey the protocol rules for that tag type | 22:42 |
| lkcl | anything tagged as "address", you are *only* allowed to raise it at the same time as wb.adr | 22:43 |
| lkcl | anything tagged "dat_i" you are *only* allowed to raise it at the same time as wb.dat_r (?) | 22:44 |
| lkcl | and, well, basically, that just doesn't fit with the idea of having a "control channel". | 22:44 |
| lkcl | *unless*.... :) | 22:44 |
| lkcl | ... you actually *use* a completely separate actual wishbone bus *as* a control channel :) | 22:44 |
| lkcl | ... or.... | 22:45 |
| lkcl | you have an entirely new wire, "this_is_a_control_channel_message" wire | 22:45 |
| lkcl | and from then on you can start doing anything you like. | 22:46 |
| lkcl | hmmm yeah i think that would work. | 22:50 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!