Sunday, 2020-09-20

lkclyay the ls180 litex peripherals + core compiled in coriolis200:46
* lkcl waves to dcz_ 10:26
dcz_hi lkcl10:26
dczI wanted to say "hi" but I dropped out instead10:33
lkcldoh, been there.  we have the irc bot logs for catching up if you miss things10:33
lkclyou asked, "Does that mean the CPU has multiple ALUs that will get used in vector mode but unlikely to see full utilization in scalar mode?10:34
lkclI haven't found a diagram showing the issue width of a core yet."10:34
*** lkcl changes topic to ""10:34
lkclit depends on the width of the instruction multi-issue phase10:35
lkclso if the instruction multi-issue phase width is say 2, then we expect to be able to issue either 2 scalar or 2 VL-augmented instructions10:35
lkclthe VL-augmented instructions will be "expanded" by the special Simple-V hardware-for-loop10:36
lkcland analysed for their element width to see if they can be SIMD-i-fied10:36
lkclbut if they are still 64-bit, they'll be thrown into the ALUs *as if* they were much wider multi-issue scalar operations10:37
cesar[m]1Maybe something like hyperthreading could help ALU utilization in the case of a CPU-type workload, where you have multiple unrelated scalar threads for different processes.10:40
dczdid I understand it correctly, that each ALU is able to do multiple operations per cycle if the unit width is <64bit?10:40
lkclcesar[m]1: perhaps, maybe that will be something to add in future, it's big enough to request its own NLNet Grant12:48
lkcldcz: currently all ALUs are 64 bit scalar because we are aiming for OpenPowerISA compliance as a baseline12:49
lkclwhat we are then going to do is, using python OO techniques, *replace* the nmigen Signal() class with a specially-designed "PartitionedSignal" class12:50
lkclthis will *dynamically* allow, with a "context" that threads its way through every single PartitionedSignal, the ALU to be *dynamically* reconfigured12:51
lkcl1x 64-bit op12:51
lkcl2x 32-bit ops12:51
lkcl4x 16-bit ops12:51
lkcl8x 16-bit ops12:51
lkclactually it will be possible to do a mixture, say 1x 24-bit plus 2x 16 plus 3x 8-bit12:52
lkclthe beginnings of that are here12:53
lkcland you can see it's just "python operator overloads __add__, __or__, __eq__" etc.12:53
lkclotherwise it would be Absolute Hell to do SIMD.12:54
lkclone line of code12:54
lkcl  comb += x.eq(a + b)12:54
lkclwould become12:54
lkclif(SIMD_SPLIT == 8-bit)12:55
lkcl    for i in range(8):12:55
lkcl             comb += x[i].eq(a[i] + b[i])12:55
lkcland that's just one line!12:55
lkclcan you imagine how insanely unreadable that would become?12:55
lkclinstead we use python OO, and that if/elif/elif is *DYNAMICALLY* hidden behind the __add__ function.12:56
* dcz looks13:20
dczI more or less see the idea13:32
dczthe magic is in PartitionedScalarShift and friends13:32
lkclyes, very much so13:48
lkcland also PartitionedMux13:48
lkclwhich you can use to do a sort-of "if" statement13:48
lkclcomb += PartitionedMux(boolean_decider, iftruesignal, iffalsesignal)13:49
lkcljust like nmigen.Mux13:49
lkclexactly like it - except with a "dynamic partitioned context"13:49
lkclwith these primitives it *should* be possible to do something similar to nmigen "with m.If()" and "with m.Else()"13:50
sorearif OPF is (a) allowing you to do arbitrary non-standard extensions (b) refusing to give standard blessing to anything you do until it has been blessed by enough vendors, isn't that essentially the same as what RVF was doing?16:29
lkclsorear: the differences are twofold.  first is that OPF has been willing to listen, where RVF flat-out was not (in direct violation of Trademark Law)19:20
lkclsecond is that "Custom Extensions" are nowhere near adequate.19:20
lkclRV Custom Extensions are very, *very* specifically for non-upstream, non-public, isolated and one-off use19:21
lkclwhich i agree 100% with that that's what they should be for.  under NO circumstance should binutils, gcc or the linux kernel accept upstream mainstream patches for anything that uses custom RV or custom OpenPOWER opcodes19:22
lkclwith that possibility being eliminated, the *only* remaining option is to seek "official approval"19:23
lkclto work *with* the other stakeholders, to add clear, clean and well-defined extensions to the *official* ISA19:24
lkcland for those to be very specifically designed and defined in an ISA non-disruptive way (behind a "namespace" - also known in OpenPOWER is as "Program Compatibility Register")19:25
lkcland that's where RVF violated Trademark Law by systematically refusing to respond to in-good-faith requests to participate in an *open* fashion19:26
lkclbecause if we participated in secretive closed Working Groups it would make it clear that we were not in the slightest bit serious about our Business Objectives (full transparency)19:27
sorearhave you ever tried to get intel to respond to a good faith request to do anything in an open fashion19:28
* lkcl snorts :)19:28
lkclthey're not proposing to open up the ISA, are they?19:28
lkclif they did, as an already CISC ISA that'd be hilarious.19:29
sorearanyway the rvf got rid of the nda years ago19:29
lkclnot the sections that prevented us from signing as Members of the RVF19:31
lkcland it bound us to unacceptable levels of secrecy19:32
lkclfull transparency, accountability and independent auditability has to mean what it says otherwise this entire venture is ash19:33
lkclif we signed NDAs or any secrecy agreements NLnet would be quite justified in saying that we're no longer working for the public good19:34
lkcland could withdraw our funding!19:34
lkclthat has actually happened to some projects19:34
lkclthey got into trouble by signing commercial agreements that handed over the copyright, and the new "owners" decided to no longer release modifications under libre licenses19:48
lkclas the work that were doing was no longer meeting NLnet's Foundation Charter requirements ("works in the public good"), they had no choice but to stop funding them19:49

Generated by 2.17.1 by Marius Gedminas - find it at!