| Veera[m] | expected/alu_cases/case_cmp.py... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9de2f27d5383bd326ea6ff4b7b19b493e26d49a7) | 01:42 |
|---|---|---|
| Veera[m] | * def case_cmp(self):... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f29a885bc060ba7628b8d789168f0e15755c4bc0) | 01:42 |
| Veera[m] | * def case_cmp(self):... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/541f41628e4aa8945ba1f1fda92df3276664616d) | 01:43 |
| Veera[m] | * def case_cmp(self):... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/39b17cff4dadfe1b78ea3644a1a37cc562747899) | 01:46 |
| Veera[m] | * def case_cmp(self):... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/97884f14e4a45d6c8495c6f198771c2d4911ab52) | 01:47 |
| kylel | Veera[m], nice catch with the cr...I pushed a fix which now should match to what you thought | 03:55 |
| Veera[m] | kylel: I will see | 03:56 |
| Veera[m] | is there a way to show XER changes | 03:58 |
| kylel | It should.... | 03:59 |
| kylel | yeah, case_addme_ca_so_3 sets one | 04:01 |
| kylel | or two actually | 04:01 |
| Veera[m] | kylel: I think I made wrong buzilla post! 0x4 is equal to 0b0100 for cr0 is right! Anyway please clarify? | 08:03 |
| lkcl | Veera[m], kylel, yes XER should definitely be part of "ExpectedState", that's quite important. | 12:47 |
| lkcl | the (new) dump function should definitely blat out the XER reg so it can be put into the tests | 12:48 |
| lkcl | Veera[m]: please make sure to commit each unit test addition of a new ExpectedState variable one at a time | 12:48 |
| lkcl | *please don't* wait until you have done all unit tests 100% before committing. | 12:48 |
| lkcl | there are (appx) 15 functions in alu_cases.py therefore there should be *fifteen separate commits* | 12:49 |
| lkcl | each commit message saying, "added expected state to case_extsb" | 12:49 |
| lkcl | "added expected state to case_cmpeqb for alu_cases unit test" | 12:50 |
| lkcl | etc. etc. | 12:50 |
| kylel | lkcl, five months for the msb...yikes | 12:59 |
| kylel | that had to be frustrating | 12:59 |
| lkcl | openpower summit 2021 started | 15:13 |
| lkcl | uses zoom (sigh) | 15:14 |
| lkcl | click on the schedule event to see the zoom link https://cfp.openpower.foundation/summit2021/schedule/ | 15:14 |
| lkcl | should work in browser | 15:14 |
| octavius | Joined, watching atm. Do you know where the link to their mattermost chat is? Or is it just easier to get into the IRC openpower-events channel? | 15:20 |
| lkcl | https://chat.openpower.foundation/opf/channels/events | 15:21 |
| octavius | Thanks luke! | 15:21 |
| lkcl | i'm trying to join now (#openpower-events) but there's no acknowledgement from libera | 15:21 |
| octavius | Ah ok | 15:21 |
| lkcl | ahh finally | 15:21 |
| lkcl | it worked | 15:21 |
| octavius | managed to avoid zoom myself, drawing mode must've been a pain for many a presenter XD | 15:34 |
| lkcl | :) | 15:41 |
| lkcl | CXL looks like something we should investigate | 15:41 |
| octavius | atm we're only using WB 3.0 right? | 15:42 |
| octavius | The wishbone spec was a nice read, only 100 ish pages | 15:42 |
| lkcl | yes. except it is a "take-it-or-leave-it" contract | 15:43 |
| toshywoshy | yes, a chiplet design with CXL+OMI ports would be a good idea | 15:43 |
| octavius | The wishbone "contract"? As in, you have to implement it exactly? | 15:43 |
| lkcl | where what we need is more "House Contract-of-Sale" - which is *three* stage: Offer, Exchange, Complete | 15:43 |
| octavius | Ah, sorry, you meant CXL | 15:44 |
| lkcl | Wishbone you absolutely *must* take the read/write request, right there, right then. the only allowed exception to that is to throw a (catastrophic) wishbone error condition | 15:45 |
| lkcl | [ | 15:45 |
| lkcl | ' | 15:45 |
| * lkcl oops dropped the keyboard :) | 15:45 | |
| octavius | Single R/W, pipelined R/W, optional tags, do you need more flexibility than that? I thought the biggest drawback is the maximum 64-bit width | 15:48 |
| lkcl | octavius: "please hold off don't commit this request until i ask you to, but please let me know if you *can* do it, before you actually do it" | 16:03 |
| lkcl | that is the House "Contract Of Sale" arrangement | 16:03 |
| lkcl | wishbone *cannot* ask the question: | 16:03 |
| lkcl | "i am making an OFFER for you to write. could you let me know, WITHOUT any "commitment", if you COULD fulfil this write?" | 16:04 |
| lkcl | 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" | 16:05 |
| lkcl | this is the kind of protocol needed for caches and for speculative execution. | 16:05 |
| lkcl | and Wishbone simply doesn't have it. | 16:05 |
| lkcl | hence why wishbone is quotes simple quotes | 16:05 |
| octavius | I see what you mean. CYC must be asserted for the duration of the transaction, but you just want to query the availability of the slave, not actually start the transaction. Transactions however, also require STB signal to be asserted. I'll read the spec's section on the rules again to confirm, but here's a suggestion. What if the master asserts CYC_O, leaves STB_O negated, and then checks for the | 16:22 |
| octavius | value of STALL_I (coming from the slave)? The slave could leave STALL asserted indicating the slave cannot accept requests (used for pipelined mode). The master could simply wait untill STALL_I is negated, and start a transaction. Only issue is in an arbitrated system, the master shouldn't hold CYC_O for longer than necessary. As for guaranteeing the transaction happens, the master could assert | 16:22 |
| octavius | LOCK_O, which forces the transaction to become uninterruptable | 16:22 |
| lkcl | "query the availability of the slave, not actually start the transaction" .... yes: but at the same time, *if* the transaction *is* (eventually) accepted, its order *must* be preserved | 16:25 |
| lkcl | as in: if there are two such House-Contract-Of-Sale requests, it is critically important that the first is completed before the second, if the first comes in (is initiated) before the second | 16:26 |
| lkcl | "polling" in other words is not an option. | 16:26 |
| lkcl | also, the way that Wishbone is set up, it is a Trademark violation to make fundamental changes to the Wishbone Specification that are incompatible with the Wishbone Specification | 16:27 |
| lkcl | about the only thing you *can* do (and not violate the Trademark) is: use "tags" | 16:27 |
| cesar | Is this something like a cache coherence protocol maybe... | 16:27 |
| octavius | What if the arbitrator took note of the transaction request order? | 16:28 |
| lkcl | cesar, i'm honestly not sure. | 16:28 |
| lkcl | arbitrators would need to be *aware* of the House-Contract-Of-Sale "1. Offer 2. Exchange 3. Complete" protocol | 16:29 |
| octavius | So the master and slave remain as they are, but the arbitrator that multiplexes the bus would have an internal record of "House-Contract-Of-Sale" requests | 16:29 |
| octavius | ah ok | 16:29 |
| lkcl | my understanding is that it would have to be a full end-to-end protocol addition | 16:30 |
| lkcl | because even peripherals might have speculative execution | 16:30 |
| lkcl | caches definitely would | 16:31 |
| cesar | It could have separate tagged address and data channels, like AXI. | 16:31 |
| lkcl | peripherals which have multiple incoming requests to deal with (DMA + processor) for example might have to receive both requests in order to ascertain which one takes priority | 16:32 |
| lkcl | or something | 16:32 |
| lkcl | but | 16:32 |
| octavius | I think I'll write out what I suggested and see if it makes sense after giving the spec a quick look. If the STALL signal was available outside of pipelined mode (only extension to the slave itself) as well as arbitrator keeping track | 16:32 |
| lkcl | if that's an out-of-order speculative memory access by the main processor... | 16:32 |
| cesar | Only, on AXI, there is no way to abort a transaction. | 16:32 |
| lkcl | cesar: not at all? | 16:33 |
| lkcl | octavius, cool | 16:33 |
| lkcl | octavius, are you familiar with multi-issue out-of-order speculative execution? | 16:33 |
| lkcl | i studied it 2+ years ago (5 months!!) in particular Mitch Alsup explained to me how "Shadowing" circuits hook into the Write | 16:34 |
| octavius | No, just the general concept of OOO exec (processor predicting a branch in advance, and I guess updating the cache to include the branch instructions?) | 16:34 |
| lkcl | Shadowing "holds off" the Write-Commit (anything that could cause "damage") | 16:35 |
| lkcl | 1 sec let me find the page | 16:35 |
| lkcl | https://libre-soc.org/3d_gpu/architecture/6600scoreboard/ | 16:35 |
| lkcl | section "Shadowing" | 16:35 |
| lkcl | https://libre-soc.org/3d_gpu/shadow.svg | 16:35 |
| lkcl | Veera[m], thank you for doing that superb clear diagram :) | 16:35 |
| lkcl | basically, when "Shadow" is HI, you are still in the "Offer" or "Exchange" phase of House-Contract-Of-Sale | 16:36 |
| lkcl | only when "Shadow" goes "LOW" are you permitted to move from "Exchange" to "Complete" phase. | 16:37 |
| cesar | lkcl: not in the middle of a burst. | 16:37 |
| lkcl | cesar, ahh that makes sense | 16:37 |
| lkcl | Multi-Issue transaction order is preserved in Shadowing by having Transitive relationships. | 16:38 |
| lkcl | Memory Request 1 holds a Shadow across Request 2 3 4 5 6 7 8 | 16:38 |
| lkcl | Memory Request 2 holds a Shadow across Request 3 4 5 6 7 8 | 16:38 |
| lkcl | ... | 16:38 |
| lkcl | Memory Request 7 holds a Shadow across Request 8 | 16:39 |
| octavius | So request 3, for example, could not come before 2 (as 2 is shadowing it)? | 16:39 |
| lkcl | and that capability *actually* needs to be *actually* part of the Memory Bus Architecture | 16:39 |
| lkcl | request 3 could not be SERVICED before request 2 is completed | 16:39 |
| lkcl | and | 16:39 |
| lkcl | crucially. | 16:39 |
| lkcl | Cancellation of Request 1 causes ALL Requests 2-8 to also be cancelled | 16:40 |
| octavius | Oh, I didn't realise this | 16:40 |
| lkcl | cancellation of Request 2 causes ALL Requests 3-8 to also be cancelled | 16:40 |
| lkcl | ... | 16:40 |
| lkcl | cancellation of Request 7 causes Request 8 to also be cancelled | 16:40 |
| octavius | So this would be akin to a failed branch prediction, where the pipeline has to be flushed? | 16:40 |
| lkcl | it's pretty complex but also pretty clear and straightforward at the same time | 16:41 |
| lkcl | correct | 16:41 |
| lkcl | Shadowing can be used for | 16:41 |
| lkcl | Branch Prediction | 16:41 |
| lkcl | Speculative Execution | 16:41 |
| lkcl | Predication | 16:41 |
| lkcl | Memory "Total Store Order" preservation | 16:41 |
| lkcl | Cache access resolution | 16:41 |
| lkcl | everything | 16:41 |
| octavius | Ah, that's why you use Shadowing, it's the more generalised concept | 16:41 |
| lkcl | yeees :) | 16:41 |
| lkcl | otherwise we have to do an absolutely awful concept of "rollback transactions" | 16:42 |
| lkcl | which would be hell | 16:42 |
| lkcl | like... taking snapshots of register file contents, and having the L1/L2/L3 cache infrastructure be totally "aware" of the rollback capability | 16:43 |
| * lkcl goes dizzy thinking about it | 16:43 | |
| octavius | That sounds like pure pain | 16:43 |
| octavius | so much data to backup | 16:43 |
| lkcl | yes! i have *no idea* why some architects actually implement it! | 16:43 |
| lkcl | ok that's not totally fair: i do know why | 16:43 |
| octavius | "Seems" easier when first considered? | 16:44 |
| lkcl | it's because using Shadowing, you have to have massive numbers of Reservation Stations | 16:44 |
| lkcl | in IBM POWER10 and i think in latest x86 cores they have a THOUSAND Reservation Stations. | 16:44 |
| lkcl | that's a THOUSAND "Shadow" Flags! | 16:44 |
| octavius | "flags"? The usual concept of flags (single/multi-bit signals indicating certain states/config, like overflow flag)? | 16:45 |
| lkcl | single-bit, yes | 16:50 |
| lkcl | "Shadow" in this diagram https://libre-soc.org/3d_gpu/shadow.svg | 16:50 |
| lkcl | one off-the-wall idea i had was not to use the WB Spec "tags" (you are allowed to add Address "Tags", and Data "Tags", and Control "Tags") | 16:51 |
| lkcl | but to actually have a dual (synchronous) "Shadow Wishbone Bus" | 16:51 |
| lkcl | (!!) | 16:51 |
| lkcl | which has its own completely separate CYC/STB/Addr/Data/Wen | 16:51 |
| lkcl | maybe only say 8-bit or 12-bit address (whatever is needed) | 16:52 |
| lkcl | but where the Shadow flag is a... a... data bus item | 16:52 |
| lkcl | and Address is... is... "please initiate a Shadow" or "please cancel this Shadow" | 16:53 |
| lkcl | basically, AXI "Control Bus" :) | 16:53 |
| octavius | lkcl: Sent my wishbone concept. Once you have some more time, please give it a look and let me know if I'm missing something. | 18:07 |
| lkcl | octavius, got it. focussing on the conference at the moment, will at least acknowledge it | 18:31 |
| lkcl | i think we have a bugreport somewhere for it | 18:31 |
| lkcl | ah! yes! https://bugs.libre-soc.org/show_bug.cgi?id=410 | 18:32 |
| octavius | Thanks, looking forward to the svp64 summary! | 18:33 |
| lkcl | ah this one is... complicated. it's a deep-dive | 18:34 |
| lkcl | i recommend skimming the "overview" beforehand | 18:35 |
| octavius | Hahah, everything is complicated | 18:35 |
| octavius | although I'll look at the overview as well | 18:35 |
| lkcl | https://libre-soc.org/openpower/sv/overview/ | 18:35 |
| lkcl | :) | 18:35 |
| lkcl | SVP64 talk in 6 mins https://zoom.us/j/95126412199 | 18:54 |
| lkcl | room's open now | 18:54 |
| lkcl | wheww that was a tech-heavy talk :) | 19:51 |
| lkcl | Jean-Paul's talk is on soon, 5 mins | 19:56 |
| lkcl | https://cfp.openpower.foundation/summit2021/talk/SF8YLK/ | 19:56 |
| octavius | Great to hear about DCT and FFT again though...been a while a few years since I touched maths like this ;) | 19:58 |
| lkcl | yeah it was insane | 19:58 |
| lkcl | do support Jean-Paul with the coriolis2 talk | 19:58 |
| octavius | of course | 19:58 |
| lkcl | https://zoom.us/j/99233712280 | 19:58 |
| octavius | I want to learn more about our toolflow anyway | 19:59 |
| lkcl | it's pretty cool, it's in python | 19:59 |
| octavius | Oh I know, had fun with the setup script earlier ;) | 20:08 |
| lkcl | deep joy :) | 20:10 |
| octavius | I'm suprised how few joined. Is it not as "exciting" as "AI"? XD | 21:05 |
| lkcl | there were 3 other talks | 21:07 |
| lkcl | and it's recorded | 21:07 |
| lkcl | LibreBMC started | 21:07 |
| lkcl | https://cfp.openpower.foundation/summit2021/talk/GLZJVY/ | 21:07 |
| lkcl | but Toshaan's talk is in 22 mins | 21:08 |
| lkcl | about the OPF Workgroups | 21:08 |
| octavius | A live talk is more fun though, you can ask questions ;) | 21:11 |
| lkcl | yehyeh | 21:15 |
| lkcl | octavius, nice to hear your voice finally | 21:15 |
| lkcl | where the heck in the world are you, anyway? | 21:15 |
| octavius | Norfolk | 21:23 |
| octavius | although my accent is from surrey | 21:23 |
| octavius | I introduced myself back in september | 21:24 |
| octavius | http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-September/003674.html | 21:25 |
| octavius | Found out about Libre-SOC by discovering EOMA68 first | 21:26 |
| octavius | I'd argue EOMA68 is what phones should have been | 21:26 |
| octavius | an actual portable computer | 21:26 |
| octavius | but Libre-SOC is a step towards that | 21:26 |
| octavius | and as for why my nick is very different, I study Latin, and octavius sounded nice XD | 21:27 |
| lkcl | :) | 21:30 |
| lkcl | toshaan's up next, OPF Workgroups | 21:31 |
| lkcl | https://zoom.us/j/95181619677 | 21:31 |
| octavius | has libresoc done any meetups/calls? | 21:44 |
| programmerjake | we have a regular meeting every tuesday at 22:00 UTC on jitsi, we can give you the meeting link privately but we don't want to publish the link since we have no auth. system. the meeting is basically us talking about whatever we want (openpower related or not). | 22:01 |
| programmerjake | it's the continuation of the OpenPower virtual coffee calls | 22:03 |
| octavius | Sure, if you can add me that'd be cool, you could send the link via email? | 22:05 |
| lkcl | octavius, try not to drop that jitsi meet link onto public resources | 22:07 |
| lkcl | because it's no password | 22:07 |
| octavius | Sure, will keep it to myself | 22:12 |
| octavius | Has the summit finished? | 23:35 |
| lkcl | looks like it. | 23:37 |
| octavius | Well, I'm knackered, ttyl | 23:38 |
| lkcl | https://github.com/open-power/ocmb-explorer-fw | 23:39 |
| lkcl | to explore later | 23:39 |
| octavius | Thanks, bookmarked | 23:39 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
