Monday, 2022-08-15

ghostmansd[m]Thanks programmerjake! I'll rebase the branch.04:53
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC05:26
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc05:26
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC05:29
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc05:30
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC05:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc05:36
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc05:55
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC06:16
*** rsc <rsc!~robert@fedora/rsc> has quit IRC06:16
*** rsc <rsc!> has joined #libre-soc06:17
*** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc06:17
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc06:21
*** ghostmansd <ghostmansd!~ghostmans@> has quit IRC06:31
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc06:48
*** ghostmansd|2 <ghostmansd|2!~ghostmans@> has joined #libre-soc07:20
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC07:20
*** ghostmansd <ghostmansd!~ghostmans@> has quit IRC07:20
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc07:21
*** ghostmansd|2 <ghostmansd|2!~ghostmans@> has quit IRC08:23
*** Amare <Amare!~Amare@2402:d000:8114:342c:25c2:6bed:8a37:e5a0> has joined #libre-soc08:44
AmareHello all, I was wondering if there is a way to visualize verilog module level hierarchy.08:45
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC08:46
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc08:46
*** ghostmansd|2 <ghostmansd|2!> has joined #libre-soc08:59
programmerjakeI didn't see anything in yosys's manual... if your verilog is generated 100% from nmigen, you can grep it for the nmigen.heirarchy attribute (iirc) and use that to generate a directory structure that you can look at with filesystem tree utilities... something like:09:11
programmerjaketr '.' '/' < out.v | sed 's/^.*[ *]nmigen\/heirarchy *= *"\([^"]*\)".*/\1/p; d' | (mapfile -t a; for i in "${a[@]}"; do mkdir -p -- /tmp/heirarchy/"$i"; done)09:16
Amarethanks, I can try that.10:19
*** ghostmansd|2 <ghostmansd|2!> has quit IRC11:09
*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC12:29
*** jn <jn!> has joined #libre-soc12:29
*** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc12:29
*** ghostmansd|2 <ghostmansd|2!> has joined #libre-soc12:54
lkclAmare: a quick search online -
*** Amare <Amare!~Amare@2402:d000:8114:342c:25c2:6bed:8a37:e5a0> has quit IRC13:34
*** octavius <octavius!> has joined #libre-soc13:59
*** choozy <choozy!> has joined #libre-soc14:06
ghostmansd|2folks, I'm looking at src/openpower/decoder/power_svp64_rm.py14:40
lkclghostmansd|2, yep, fun one that one14:40
*** ghostmansd|2 is now known as ghostmansd14:40
ghostmansdHow does Signal work with If, Switch and Case? Where to read about it w/o too much low-level HW details?14:41
lkclit's needed to extract all the fields into very simple one-signal-thing14:41
lkclbasically they're exactly as you'd expect.14:42
ghostmansdAssuming I already decoded Prefix and RM, I'd simply like to re-construct the string for objdump14:42 would not necessarily be a good place to start for that.14:43
ghostmansdWhich'd be good?14:44
lkclhonestly i'd start from scratch but from those tables14:44
ghostmansdBecause doing it vice versa from pysvp64asm is even worse.14:44
lkclshould i do one in python, first?14:45
ghostmansdI assumed we had something already :-)14:46
lkcl(aside from anything, it'd be a good way to discuss it)14:46
lkclnope :)14:46
ghostmansdWell, not exactly for conversion to string...14:46
ghostmansd...but, I mean, something that actually _decodes_.14:46
lkclthe closest i have is, after using PowerDecoder, printing out the instruction name/string, in ISACaller.14:46
lkcland, hm, i think it goes to some lengths to add the "o" "." or "o." on the end14:47
lkclbut that's about it14:47
lkclactually, it uses PowerDecoder2.14:47
lkclbecause PowerDecoder2 has to decode the register numbers14:48
lkcland that's a whole bundle-o-joy on its own.14:48
lkclthere... miiight... be somewhere i did that manually...14:48
ghostmansdWell, instruction name, its operands, its prefix, suffix, and even RM, are already decoded in binutils.14:48
ghostmansdI'm kinda dubious how to move next, though.14:48
lkclfound them14:48
ghostmansdI want to convert the uint64_t to struct svp64_ctx (the same structure we fill when assemble).14:49
lkclyou can see that is _supposed_ to be using PowerDecoder214:49
lkclremember that the mode varies depending on the type of operation (the column with LDST, ALU, BRANCH, CR in it)14:51
ghostmansdYeah the mode is the most complicated part.14:51
lkclthat's the first step.14:51
ghostmansdI recall we have 4 modes, and they affect the stuff a lot.14:52
lkcltotally. like, totally different.  and LDST has two sub-modes, for immediate ops and indexed ops14:52
* lkcl afk for half an hour14:53
ghostmansdSpeaking of say get_pdecode_cr_in... what do these yield statements do?14:57
lkclyou know how python generators work?15:50
lkclyou have a top-level for-loop "for something in some_function()"15:51
lkcland the function "yields" the results that get passed, on each iteration, as "something"15:51
lkclin this case however if you ignore the keyword "yield" entirely and just go-with-the-flow, it basically gets the value15:52
lkclin1_sel = yield op.in1_sel "gets" the value stored in op.in1_sel and puts it into the local variable, in1_sel15:52
lkclthat's all there is to it15:53
ghostmansdAh OK. I thought we had some nice coroutines there.16:02
ghostmansdOK, here we kinda switch the context and get the value, right?16:02
ghostmansdIt's like "yield to where you were, say in the event loop, and return to this point when it yields"16:03
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC16:07
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:08
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:24
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc16:24
lkclyes, basically.  you may be interested/fascinated/horrified to know that javascript also has yield16:42
ghostmansdI'm reading the code but frankly it gives even less clues than the vice versa translation of svp64.py16:43
ghostmansdThese Signal concepts and similar stuff kinda hides the low-level details.16:44
ghostmansdI understand it goes from execute_one() and follows to call(). But all these nmigen classes and attributes hide what happens.16:45
ghostmansdIf these were just simple classes, present in the same repository, it'd have been simpler. :-)16:46
ghostmansdI'd rather prefer something obvious like SelectableInt[SOME_BIT_WE_NEED]...16:47
ghostmansdBut OK, I'll handle it eventually.16:47
ghostmansd[m]I think the main problem is, I'm thinking in terms of standalone 64-bit instructions. And the code we have thinks of decoders.16:57
ghostmansd[m]That is, when I think of bit masks, shifts and similar stuff applied to 64-bit unsigned integer, what we have is a complex set of nested decoders.16:58
lkclISACaller has a Finite State Machine built-in, because it needs to do "stepping".17:06
lkclconsequently it is possibly about the worst thing you could look at to try to understand what the hell's going on17:07
lkclto "understand" nmigen you need to appreciate that actually it is a compiler [language translator]17:07
lkclall those assignments comb += something.eq(somethingelse) are actually creating Abstract Syntax Tree code-fragments!17:08
lkclthe nmigen Simulator "understands" those but leverages them in such a way that... get this: it is AST-walked to create a *fragment of python code* which is then eval()ed and then run!17:09
lkclit's complicated for a reason.17:10
lkclthe nested decoders is basically equivalent to doing - in c - switch(major_opcode) { .... switch(XO) { } ... }17:11
lkclat some point i'd like to flatten that to a single-level17:11
lkclswitch(major_opcode|XO} { ........... }17:11
lkcl(sotto voice basically using the mask/value you just created)17:12
ghostmansdI get the concept, my point is, the way binutils do it differs  (and the way my mind works matches binutils)17:52
ghostmansd> consequently it is possibly about the worst thing you could look at to try to understand what the hell's going on17:53
ghostmansdBut this is exactly the chunk you also pointed me to! :-) Well, you pointed me to the standalone functions there, but they're also called in the ISACaller context, and to understand these I also have to understand ISACaller.17:54
ghostmansdBut, anyway, I'll perhaps stick to bit-level stuff for now.17:55
lkclyes, but _only_ those functions :)18:10
lkcloh, err, hang on, i realised that all those functions do is turn in1/in2/in3 into RA/RB/RC / FRA/FRB/FRC18:11
lkclthey still actually rely on PowerDecoder2, sigh18:12
ghostmansdyep :-)18:13
ghostmansdI think going backwards would be simpler, to be honest.18:13
lkcli think it's probably a good idea to do a reverse of sv/trans/svp64.py18:14
lkclin python18:14
ghostmansdYep, mine impression too.18:14
lkclthen do binutils based on that18:14
lkclone _should_ be possible to use to test the other18:14
ghostmansdBut, since I really run out of time, I'm not sure whether to start with the Python...18:14
ghostmansd...on the other hand, writing the code there is way simpler.18:15
lkcli'll help18:15
ghostmansdI'm worrying about time constraints. In the beginning of October, the carriage turns back into the pumpkin. :-)18:16
lkclheh :)18:16
lkclwell there is the cavatools grant, the MoU hasn't been agreed on that one18:16
ghostmansdBut OK, you persuaded me.18:16
ghostmansdI also think that it should be Python first.18:16
lkclso in theory it is possible to put in a reasonable (not-massive) budget there18:16
ghostmansdFirst, it's simpler to write. Second, it's simpler to follow the Python script to implement something in C. Third... we need it anyway.18:17
ghostmansdAt least for X-testing purposes.18:17
lkcli could probably justify up to... mm.... probably EUR 8k if it also included some of the scalar instructions18:17
ghostmansdI'll start doing it. I hope it won't take that much time that binutils grant is lost. :-)18:18
lkclwell it's perfectly reasonable to include it *as* part of binutils18:18
lkclbut we're scraping the corners of different Grants now18:18
lkcldaaang pack/unpack is going to be complicated in ISACaller18:20
ghostmansdNope, I mean, I hope that the task won't eat to much time and I'll be able to complete binutils.18:20
lkcli've put in a second NLnet grant request for it18:20
lkclplus, as i said, we can justify adding a budget to cavatools.18:21
lkclcavatools is *not* EU Horizon 202018:21
ghostmansdSo other stuff also turned out to be more difficult, right?18:21
lkclpack/unpack - hell yes.  basically the order of the subvl/vl for-loops swaps *dynamically*18:21
lkcland of course it's a Finite State Machine18:22
ghostmansdSince I already found myself hitting the wall several times, I kinda worried if it's my personal problem... :-)18:22
lkclhe, no :)18:22
lkclthis stuff really is... comprehensive18:22
ghostmansdsigh, yeah18:22
ghostmansdOK, let us have pysvp64disasm18:23
*** choozy <choozy!> has quit IRC18:23
lkcli'm considering whether to extract the for-looping into a completely separate function that actually just calculates the src/dst-step (and subvl-src/dst-step) right there, right then18:23
lkcland then ISACaller just enumerates through it in a mechanical by-rote fashion18:24
lkclworks for me18:24
ghostmansdISACaller is kinda the heart of this18:26
ghostmansdI still recall how difficult it was to even make some mixins work with it18:26
ghostmansdI mean those helpers from the code generation18:27
ghostmansdSo yeah, I understand how difficult refactoring there could be18:27
lkclwell it helps that i wrote it and have it semi-memorised18:34
lkcland also wrote most of the words in the spec18:35
lkclbut i believe i may be overthinking the complexity, as it really is just "do some for-loops, drop the indices into a list" then "use that list in ISACaller"18:36
lkclwhere that falls over - argh - is if SVSTATE is changed.18:36
lkclyep, it's complicated :)18:36
*** ibot` <ibot`!> has joined #libre-soc19:34
*** ibot <ibot!> has quit IRC19:34
*** octavius <octavius!> has quit IRC20:00
ghostmansdDrop a stub for pysvp64dis. Currently it only can read some binary file, get instructions and make a wild binutils-like guess whether the instruction is prefixed or not.20:31
ghostmansdI'll switch it to SelectableInt, for now shifts are to simplify quick checks on my local laptop.20:32
ghostmansd[m]Migrated to SelectableInt, will continue tomorrow21:10
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC22:00
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc22:00
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC22:34
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc22:34
*** octavius <octavius!> has joined #libre-soc23:04
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC23:17
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc23:18
*** octavius <octavius!> has quit IRC23:53

Generated by 2.17.1 by Marius Gedminas - find it at!