Thursday, 2022-08-18

*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC00:51
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc00:51
klys_lkcl, it intrigues me that you would be donating to me, as I have not been working on libre-soc myself.01:28
klys_lkcl, how come you have me as a recipient?  I have not been working on your project.01:29
programmerjakei'd guess because you contributed in the past...contributions don't have to be code, they can be ideas too01:30
klys_there is a legal problem I have with handling money.  and I just spent 1500 but, if I were to receive enough to put my bank account over 2k then bam I lose the money01:30
klys_I get a check every two weeks and so I would probably have a fiar chance of going over if you gave me 1300 like you said01:32
klys_my next paycheck for work at deseret industries of provo arrives a week from friday.01:32
klys_I have to pay careful attention to that because I am an insurance recipient (for now anyways) or else I lose my place of residence.01:33
klys_also I need documentation if I get hired anywhere because the dep't. office needs all my figures.01:34
klys_well, as long as programmerjake's here...01:35
klys_have you figured anything out about that bug report from last night?01:35
klys_it didn't look too promising except I remember there were a few suggestions in there01:36
programmerjakethe .pyi bug? no, nothing new01:38
klys_"Checking code based on stub files: no current solution, unless you get something using retype to work"01:38
programmerjakeiirc i've been to DI in provo before... 5-10yr ago01:39
klys_neat.  I work in the back room sizing clothes.01:39
programmerjakealso, if you get paid by nlnet, it would be a donation fron nlnet, not employment01:40
klys_oh?  well I worry about how long that would take to go through01:40
programmerjakein my experience, usually 1-3 weeks since submission01:41
programmerjakeI'd imagine you could ask them to split the payment into a few pieces so you don't go over your $2000 limit...01:42
klys_I have been building an Epyc 3 server system for my 4U rackmount eatx case.  so far I have a dual-socket motherboard and 28-core cpu.  ordered 256GB samsung a-class ram this week.01:42
klys_next week I'll get a high end (~280w tdp) cooler and some heat spreaders for the ram.01:43
programmerjakenice! all my servers are mostly just old pc parts i had lying around -- amd fx 8-core and ryzen 2600x01:44
klys_I can only do limited onlining with the current firewalled local wifi situation01:44
klys_may end up getting a 2TB nvme disk and using it all for swapspace01:46
programmerjakehmm, you could probably bypass that with a wireguard vpn if you wanted a small cloud server somewhere and install wireguard on it01:46
klys_I have a couple of vps servers up, one is and the other is
programmerjakethat's what I'm doing so is publicly accessible01:47
klys_they are low-end vps service01:47
klys_occasionally (like every week or so) I get outages01:48
klys_it might help to script the reconnect, though bandwidth is limited to 50% of the carrier because only 7-bit ascii can pass the firewall.01:49
programmerjakewait, so you can't just use udp connections? sad firewall...01:50
klys_yeah it does censorship and all that01:50
programmerjakewireguard runs over udp so it has very low additional latency, unlike most other vpns01:51
klys_I should be moving sometime in the coming year and then I'll subscribe to internet access hopefully through comcast.01:51
programmerjakeok, hopefully you get decent internet, a lot of isps have pretty terrible reputations...01:52
klys_yeah.  so, the server is pretty half-baked for now, it might be a few months before I have something you could login to.01:52
klys_of course, with a few extra bucks and a ulx3s 85f board you might get a bit more of my attention01:54
programmerjakeoh, also, why would you need 2TB of swap?!! i have 32gb of ram and haven't needed swap at all on my desktop...01:54
klys_because I'd be running complementary vm's for users of this ridiculously high-functioning system01:55
klys_it's a dual socket system so it could conceivably have 64 more cores01:56
programmerjakeand 128gb (iirc) of ram isn't sufficient? do you have 10000 vms or something?01:56
klys_yea I want to high-ball the number of services I'm providing...  :)01:57
programmerjake128gb is 4gb/core01:57
klys_also it's 2gb/thread01:57
klys_or...with 28/56 let'sr ecalculate01:57
programmerjakemore than my desktop which has 1.333gb/thread01:57
klys_with 56 threads that's 4.5714 GB/core01:58
klys_well per thread01:58
programmerjake2TB is so absurdly high that unless you have a specific program in mind, i'd rather use it for more filesystem space01:59
klys_there'll be another disk at this rate I'm sure02:00
klys_the mobo has two mini-sas connectors02:01
Veera[m]<Veera[m]> "lkcl: I ran build_full_4ksram_re..." <- ahem: read lkcl mail and found the generating gds file*02:02
klys_lkcl, I have been looking through my gmail account trying to find your correspondence and I'm drawing a blank.  I also rummaged through my safe-mail account and no dice.  pm me what you had for my email.02:15
programmerjakei was looking too, couldn't find anything...02:15
klys_lkcl, perhaps you were thinking of kyle1 (kylel1), he hasn't talked with you since last year it seems.03:17
klys_I was pouring through the logs and reviewed everything I have not pasted any email address nor the word "email" in the channel so far.03:18
klys_only thing I can think is if it appeared in the chat for a meeting I attended last year sometime03:21
klys_there seems to have been a meeting where we discussed pipelining?03:22
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC03:26
klys_in any case if the email you have on file matches my hostmask, that email server would not be accepting messages because procmail was compromised a little while back.03:27
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc03:27
programmerjakeyeah, i'm firmly in the no swap camp if your ram's big enough03:58
programmerjakelkcl: I'm working on a formal proof of PLRU, but I'm running into an issue: how does `BITS` and `TLBSZ` correlate with the number of ways in the cache? I would have expected BITS to be the number of ways, but looking at the diagrams in and the math for calculating TLBSZ, that makes no's off by around a factor of 2.07:16
programmerjakeI'm thinking whoever converted that botched the math, but I'm not 100% sure and I don't want to fix it and have our cpu unexpectedly change how many TLB or cache ways it has and costing a whole lot more/less...07:18
*** ghostmansd <ghostmansd!> has quit IRC07:28
*** ghostmansd <ghostmansd!> has joined #libre-soc07:41
*** octavius <octavius!> has joined #libre-soc09:48
lkclprogrammerjake, i have absolutely no idea. it's a direct conversion from microwatt.  therefore *please do not change it in any way shape or form*09:54
lkclklys_, ahhh. yes i was. thank you.09:55
lkclVeera[m], honestly i don't know.  cougar does indeed take an insane amount of time, and can be terminated. as long as the ".gds" file has been created (chip_r.gds) that's the important bit09:56
markoslkcl, I just found this, I remember you were looking for DDR3 fpga implementation, but you probably already know of this
markosand at the same place I also found this link:
lkclmarkos, nice!09:58
lkclon the list/wiki they go...09:59
markossaw them mentioned on some retro forum, some people are keen on reimplementing ancient hardware on fpgas :)10:00
markosI wish I knew HDL/Verilog10:00
lkcli collect them here
lkclmarkos, honestly? really? no... you don't :)10:00
lkcli "worked them out" - took about 6 months - the initial barrier to understanding was 3-4 weeks (ish)10:01
markoswell, I've been doing software for the past 30 years, and just recently I realized that I actually like hardware too and have been keeping myself busy with retro computers, because they're easy to understand10:01
lkclbut it was gate-level diagrams (yosys "show top") that helped the most10:02
markoseasier than today's computers at any rate10:02
markosI bought some books on electronics and verilog even, still waiting for me to read them, too busy these days10:03
lkclyosys "show top" chucks the connections between basic boxes at you. and if you've done schematics (logic diagrams) or even heard of the educational program "scratch", they're just so much more ridiculously easy to understand10:04
markoswell, electronics is easier I already have the physics background10:04
lkclthere you go10:04
markosit's a huge gap between electronics courses from almost 30y ago to reading and repairing full computers schematics10:04
markosbut I *have* managed to repair a dozen spectrums and a couple of amigas :)10:05
markosso I'm on a right track,it just takes time10:05
lkclthings like verilog registers make no sense how/why they get created until you see the DFFs that result from using the right verilog statements10:05
lkclseriously, though, verilog/HDL is like the equivalent of a 10x microscope on top of computing in assembler10:06
markosI have a small lab with a digital oscilloscope and I can at least check if the signals are going to the chips, but it's just able to handle low frequencies (up to 20Mhz)10:06
lkclthen yosys "show top" is like another 10x microscope zoom on top of that10:06
lkclpffh 20mhz is perfect for old computers10:07
lkclghostmansd, i got rid of the duplicates;a=commitdiff;h=97958abd1eae81b1cc74abd85d16c5d29fd7579110:08
lkclthere were *multiple* matches in the microwatt decode1.vhdl 0001 and 0000 which yes, they're deliberately meant to go through to the same line10:09
lkclbut by converting to patterns i could replace them with "000-" etc.10:09
lkclprogrammerjake, yeah i honestly don't fully understand the code - i did a verbatim/naive/direct/literal/faithful translation from microwatt as best i could10:13
lkclunnnfortunately, vhdl has the ability to use variables (because it is basically ADA)10:13
lkcli did my best to create actual intermediary signals so that nmigen would end up creating AST-expressions that got duplicated massively in an exponential fashion (sigh)10:14
programmerjakei figured out the issue, afaict you mistranslated vhdl's exponentiation operator as multiplication:
programmerjakeafaict BITS is supposed to be the base-2 log of the number of ways, or similar10:23
lkclahh deep frickin joy.10:23
lkclwell spotted10:25
programmerjakeand the inputs/outputs are encoded in binary, not unary10:25
lkclnggggh that's going to impact the TLB/MMU ngggggggh10:25
lkclbut it's a bugfix so is good to do.10:26
programmerjakehow about i copy and fix it in there, so we can convert plru users gradually?10:27
programmerjakelkcl: ^ sound good?10:29
programmerjakecan move back to plru and change all imports back once all users have converted10:30
programmerjakemove over again10:30
lkclprogrammerjake, yes that's a good idea10:32
lkclalthough there's only the one10:32
lkclat least it's nondisruptive10:32
programmerjakethere's 2 users: the caches and the formal proof i'm writing10:33
programmerjakeedited description to describe migration plans:
programmerjakemoving the caches to use will be under a different task which someone can do later10:38
* lkcl stressing out at the thought of dealing with that already :)10:39
programmerjakelkcl, please don't put docstrings on the same line as a variable assignment, autopep8 will automatically move them back to a new line:;a=commitdiff;h=38cb2af1a5a873a8b16ec887a2930a3fb8ab4ae010:47
programmerjakerest of that commit looks fine10:48
programmerjakeiirc we went over this before...10:49
* lkcl grumbles. they visually look cleaner.12:48
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC13:45
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc13:45
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC14:07
lkclholy cow15:27
lkclboulders placed in rivers that are now dry, across europe, with carvings in them15:28
lkclone has been revealed, from 1616, with the words "Wenn du mich seehst, dann weine" -- "If you see me, then weep,"15:29
*** octavius <octavius!> has quit IRC15:54
*** tplaten <tplaten!> has joined #libre-soc18:22
lkcl@@ -127,10 +127,12 @@ class FieldSelectableInt:19:09
lkcl         return self._op(xor, b)19:09
lkcl     def __lt__(self, b):19:09
lkcl-        return self._op(lt, b)19:09
lkcl+        vi = self.get_range()19:09
lkcl+        return bool(lt(vi, b))19:09
lkclghostmansd, be careful with that one.  it is highly likely that the Simulator - i.e. the pseudocode - critically relies on the result from lt/gt being a single-bit SelectableInt19:10
lkcl*not* a bool19:10
ghostmansdYeah that's currently what I debug :-)19:10
lkcldoh :)19:10
ghostmansdIt's likeky you read my mind19:10
ghostmansdI found that I broke the test_caller_svp64.py19:11
lkclthe Simulator has a trick where it generates code to explicitly turn things into a single-bit19:11
lkclcan't remember the name of the function.19:11
ghostmansdAnd already can see that it's caused by the fact is broken, too19:11
ghostmansdyeah there's such thing19:11
lkcland the compiler very deliberately sprinkles lots of them about when it encounters boolean expressions19:12
ghostmansdthat said...keeping it like other operators breaks the code, too19:12
ghostmansdiirc it fails on merge method19:12
ghostmansdsince the result is 1-bit19:12
lkclmerge? que? do you mean concat()?19:13
ghostmansdYeah return self.merge(vi) fails on expressions like FSI(666, 64) == 0b1119:13
ghostmansdoops, should've used bitmap there19:13
lkcl1 sec19:13
lkclyes i would expect a comparison against a non-SelectableInt to fail19:14
lkcltry FSI(666,64) == SelectableInt(2, 0b11)19:15
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc19:15
ghostmansdhow would we simplify stuff like `if != 0b11:` work?19:15
lkcleverything in SelectableInt is very strictly bit-length-defined19:15
ghostmansdI mean, I _could_ ensure it's bit-length-enabled...19:15
ghostmansdbut it's way too much to type :-)19:16
lkclthat's not optional, it's absolutely essential19:16
ghostmansd  File "/home/ghostmansd/src/openpower-isa/src/openpower/decoder/", line 340, in __getitem__19:16
ghostmansd    assert key < self.bits, "key %d accessing %d" % (key, self.bits)19:16
ghostmansdAssertionError: key 1 accessing 119:16
ghostmansdThat's what I experienced19:16
lkcl(and a total pain in the ass to write pseudocode for, but hey)19:16
lkclyep, that means you're trying to index something that's out of range of the strictly-defined length of the SelectableInt19:17
lkclit's a valid error, in other words19:18
ghostmansdif != _SelectableInt(0b11, 2):19:18
ghostmansdthis doesn't work either19:18
lkclhang on - do you have a test that's committed already that i can run?19:18
ghostmansdBut perhaps I fucked up the classes19:18
ghostmansdWell I have binary with svp64 instruction19:19
ghostmansdWithout elf headers19:19
ghostmansd0000000 00 00 40 05 14 02 41 7c19:19
lkclcan you add a simple test i can run?19:19
ghostmansdin a moment19:19
lkcl(helps as a unit test anyway)19:19
lkcli'll go out for a walk19:19
lkclor watch some cute kittens on youtube baraban-tv channel or something19:20
ghostmansdlkcl, submitted the reproducer19:25
ghostmansdpython3 src/openpower/sv/trans/pysvp64dis.py19:25
ghostmansdpysvp64dis branch19:26
ghostmansdI basically wanted to compare the FSI (this is exactly what we have as fields in the updated fields classes)19:27
ghostmansdAh no it seems to work19:34
ghostmansdWith changing to SelectableInt instead of plain int19:34
ghostmansdbut only if I use bool() in __eq__/__lt__19:35
ghostmansdanyway, please check the recent commit in that pysvp64dis branch19:35
ghostmansdit has the whole reproducer19:35
ghostmansdYeah I think I fould the way to solve it.19:39
ghostmansdOn one hand, I cannot use the usual merge() method with SI of one bit...19:39
ghostmansdthe recent commit19:41
ghostmansd...shows what on the other hand :-)19:41
ghostmansdso, in this regard, the stuff works with onebit()19:42
ghostmansdnow it's time to understand what did I break with src/openpower/decoder/isa/test_caller_svp64.py19:42
ghostmansdI'll check, likely I broke the the way we handle prefix or RM value19:43
ghostmansdIt seems I broke the comparison somehow, according to logs.19:58
ghostmansdOK I found the issue20:14
*** tplaten <tplaten!> has quit IRC20:24
ghostmansdOK src/openpower/decoder/isa/ also works20:40
ghostmansdThat said, I don't yet fully understand what's broken20:40
ghostmansdOr, well, rather, why20:41
*** octavius <octavius!> has joined #libre-soc20:55
ghostmansdlkcl, I submitted the minimal reproducer20:58
ghostmansdNotice the very first modified line: this is exactly what I had to fix so that test works.20:58
ghostmansdThat said... I don't understand why it doesn't work when I switch to FSI instead of SI.20:59
ghostmansdThis FSI should be a simple SI with br=range(SI.bits).21:00
ghostmansdThat is, for me these two records should be identical21:02
ghostmansdSVP64RMFields(value=0x2da0, bits=24)21:02
ghostmansdFieldSelectableInt(si=SVP64RMFields(value=0x2da0, bits=24), br=BitRange([(0, 0), (1, 1), (2, 2), (3, 3), (4, 4), (5, 5), (6, 6), (7, 7), (8, 8), (9, 9), (10, 10), (11, 11), (12, 12), (13, 13), (14, 14), (15, 15), (16, 16), (17, 17), (18, 18), (19, 19), (20, 20), (21, 21), (22, 22), (23, 23)]))21:02
ghostmansdAnd I don't understand why the first works with FSI.eq but other doesn't.21:03
ghostmansdFuck it's been almost 15 hours since I work, minus eating and other distractions. Enough for today.21:05
ghostmansd[m]lkcl, you already probably realized the ultimate goal beyond all this dubious activity. I want the fields to be shared by all code; also, some code will be dropped from module, and replaced with fields, too. I already moved the Instruction class and all its descendants to There are also classes PrefixedInstruction and SVP64Instruction; the last one has the prefix inherited from the fields we hav21:14
ghostmansd[m]and will work with to decode the instructions. The goal is to also provide some stuff usable for the other code around here.21:14
ghostmansd[m]As it was done with the instruction records, I'd like to share the decoding part, too.21:15
lkclghostmansd[m], will take a look21:20
lkclghostmansd[m], for when you're awake (i.e. not today)21:49
lkclcan i suggest instead of allowing this:21:49
lkcl   SelectableInt<--FieldSelectableInt<--FieldSelectableInt21:50
lkclto do21:50
lkcl  SelectableInt<--FieldSelectableInt (as is the case now)21:50
lkclif the double-referencing is attempted perform a *de-reference* of the fields-of-fields21:51
lkclcrushing the lookups *down* to only the *one* SI<--FSI21:51
lkclthe thing about FSI is that as you probably noticed it is *not* a copy of the SI it contains21:51
lkclit *actually* allows for arithmetic *on the SI*21:52
lkclbut SI<-FSI<-FSI is far too complex (and slow)21:52
lkcltherefore if you can do a FSI<-FSI resolution of the indices *in the constructor*, down to just the one FSI, you end up using the well-tested code-path21:53
lkclthis was too strict:21:53
lkcl    def __init__(self, value, bits=None):21:53
lkcl        if isinstance(value, SelectableInt):21:53
lkcl            if bits is not None:21:53
lkcl                raise ValueError(value)21:53
lkcli changed it to:21:54
lkcl                # check if the bitlength is different. TODO, allow override?21:54
lkcl                if bits != value.bits:21:54
lkcl                    raise ValueError(value)21:54
lkclbut... ngggh, i am sort-of feeling that it should be allowed (because it's a way to truncate the SI to a new bitwidth)21:55
lkcland sort-of not21:55
lkclcommit 5bf3c705cc0736cf34456d173fc4c50da5aba03721:56
lkcl    "fix" error introduced in sv/trans/ by using svp64_rm.spr21:56
lkcl    instead of spvp64_rm21:56
lkclalso did that ^21:56
ghostmansd[m]lkcl, I've thought about this model with fields...21:58
ghostmansd[m]My feeling is that they should also get SI by reference21:58
ghostmansd[m]And then pass this SI to all the properties21:59
ghostmansd[m]This way, for example, given SVP64Instruction...21:59
ghostmansd[m]The prefix would be PrefixFields(insn[32:64])22:00
ghostmansd[m]And also it should be allowed to use some field inside another field22:00
ghostmansd[m]That is, RM field inside Prefix should be somehow mapped to RM class...22:01
ghostmansd[m]There is never more than 1 indirection level with FSI22:02
ghostmansd[m]Whenever ones try to instantiate FSI from another FSI, indices are simply converted22:02
ghostmansd[m]So no, we don't invoke two __getitem__ methods if we instantiate FSI from FSI22:03
ghostmansd[m]We always operate on the SI directly22:03
ghostmansd[m]So the overhead can be neglected22:04
*** octavius <octavius!> has quit IRC23:33

Generated by 2.17.1 by Marius Gedminas - find it at!