Saturday, 2023-06-03

*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC01:49
*** jn <jn!> has joined #libre-soc01:50
*** jn <jn!> has quit IRC01:50
*** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc01:50
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC04:00
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:01
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC04:15
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:15
lkclprogrammerjake, the file-thing works great.  still at 12 gb on 3.2.5 but that's perfectly fine12:40
lkclnicely done12:40
*** octavius <octavius!> has joined #libre-soc13:35
octaviuslkcl, I've looked at the ls2 verilator sim today. Although I got the gtkwave traces printing and I can see the processor executing, I don't see the UART tx coming out to stdout. I expected this because the microwatt repo verilator sim does this. Has something changed between the microwatt and ls2 uart functions that redirects the uart tx somewhere else?13:38
octaviusI compared the 'uart-verilator.cpp' drivers and 'microwatt-verilator.cpp' between microwatt and ls2 repos and found no significant difference13:39
lkcli really don't know, it's been too long14:09
lkclyou'll need to trace the instructions one at a time14:10
lkclyou know the order of instructions from verilator14:10
lkclah uart-verilator.cpp is not a "driver"14:12
lkclit is a c++ verilator... there's a special term for it14:12
lkclno wait14:13
lkcluart_tx and uart_rx are just "functions that do stuff which happens to emulate a 16550 UART"14:13
lkclwhat you *actually* meant was,14:14
lkcl"at line 308 which is where uart_tx() is called, there *is* no data received that that function recognises"14:15
lkcltherefore, the most logical and obvious thing to do is:14:15
lkcllook at the input to uart_tx14:15
lkclthat's the "information-discernment-point"14:16
lkclyou should have a model in your head "how this works"14:16
lkcl"what do i expect this to do, why is it not doing it, what is *producing* it so i can take a look at it"14:16
lkcldrill-down, drill-down, drill-down, drill-down...14:17
lkcl        uart_tx(top->uart0_txd);14:17
lkcl        top->uart0_rxd = uart_rx();14:17
lkclwhat do you think goes in and out of those functions, yes?14:18
lkclthe data doesn't come from nowhere14:18
lkcltop-> .... oh! that's the verilator model!14:18
lkclah, i can look at the verilator gtkwave trace, i guess it's called "uart0_txd" and "uart0_rxd"?14:19
lkclah, yes!  okay!  what are those signals doing?14:19
lkclwell, they're are moving / are not moving14:19
lkclhmm, i wonder why *that* is?14:19
lkcland you have moved on to the next drill-down in the debugging chain14:20
lkclnext, next, next, next14:20
lkclbasically you can't treat everything as "a black box expected to work 1st time"14:21
lkclremember i taught you, you need to make comparisons (diffs)14:21
lkclfrom known-good to known-bad14:22
lkclbut if the diff is too big14:22
lkclyou have to decrease the diff14:22
octaviusOk, thanks.Looks like uart_0__tx remains at 1 (idle), while uart_0__rx remains at 0.15:09
octaviusThat's the signals inside the 'uart' module.15:10
octaviusAt the top level, tx_o and rx_i are both stuck at 1.15:10
octaviusWill have a look at why15:10
lkclso that's eliminated the line of enquiry "uart-verilator.cpp and/or microwatt-verilator.cpp must be faulty"15:20
lkclwhich was an assumption that you made rather than a "hypothesis to be tested"15:20
lkcltesting _that_ hypothesis however would involve wiggling top->uart_tx manually15:21
lkcland/or calling uart_tx(somethingsomething)15:21
lkcli.e. you *can* insert deliberately-intrusive code that *actually* modifies the output16:00
lkclcutting off "the other stuff even though it's running"16:00
lkcland just use the verilator binary as "an easy in-situ way to test a hypothesis"16:01
lkclaka "hack it" :)16:01
lkclghostmansd[m], i leave it with you to fix the renames (to remove the use of common python modules).16:26
lkcli have no problem with what they are, as long as they are not common standard python module names16:26
lkcli have to terminate working on investigating the Idx0/1/2/3 ValueError16:28
ghostmansd[m]Please check the comments, it's not something to be fixed.16:29
lkclghostmansd[m], i can't do any work16:30
ghostmansd[m]It's perfectly normal to have modules named as python modules, because, in general, we don't control what modules are there with each new version.16:30
ghostmansd[m]lkcl, just call the script via pysvp64db16:30
ghostmansd[m]Not python3 src/openpower/insndb/db.py16:31
ghostmansd[m]And that's it, the "issue" is fixed.16:31
ghostmansd[m]Yes it's a bogus behavior, described in PEP and acknowledged. Yes they demonstrate how to fix it.16:31
lkclghostmansd[m], i am in distress because i feel have not been heard16:32
ghostmansd[m]Our imports are correct, don't override the builtins and work with like charm.16:32
lkclplease can you make the requested renames to something that you are happy with16:32
ghostmansd[m]It's rather me than you16:32
ghostmansd[m]Or, well, haven't been "read"16:33
ghostmansd[m]I explained the rationale16:33
lkclghostmansd[m], i am not able to use the correct english words to explain16:33
ghostmansd[m]And, by the way, the way you do imports has much bigger chances for collisions16:33
lkcli am in distress because i cannot...16:33
lkcli cannot explain properly16:34
lkcland i cannot do any work16:34
lkclthat means that as the project leader if you have stopped me from being able to work it is extremely serious16:34
ghostmansd[m]No I don't stop16:34
lkclfar more serious than any "policy" or "process"16:34
ghostmansd[m]Again, you did
ghostmansd[m]Then everything works16:35
lkcli am in distress16:35
lkcli cannot work16:35
lkcli have complex work to do16:35
lkcli cannot do it16:35
ghostmansd[m]The thing is, you asking to fix something which never been broken and _wroks_16:35
ghostmansd[m]I'll rename these16:35
lkclthis is more important than policies16:35
ghostmansd[m]But you know what? Fuck it. I'm in distress too.16:35
lkcli know16:36
ghostmansd[m]So to keep your work I'm renaming this and leaving this to you. I'm pretty much fed up with this.16:36
ghostmansd[m]You don't even listen or read anything I write. Took about an hour to provide rationale to be never read.16:37
ghostmansd[m]Fine, just fine.16:37
lkcli'm so sorry - i am currently trying to stabilise the spec16:38
lkcland am under time-pressure because the ISA WG Chair is retiring16:38
ghostmansd[m]You don't listen. I explained several times why it's not an issue. But you just don't listen.16:38
lkclso it's not "deliberately not listening"16:39
lkclit's not like last year when there was no time-pressure, and i could focus on working with you16:39
lkcldon't make any changes16:40
lkcllet's do one thing at a time.16:42
ghostmansd[m]too late, it's disasm now16:44
ghostmansd[m]Run $(python3 src/openpower/insndb/, it works16:45
ghostmansd[m]I'm shutting for a while, otherwise I'll say something rude and bad16:46
ghostmansd[m]I need to think about something else and be distracted by something less moving16:48
*** vaino[m] <vaino[m]!~vainomatr@2001:470:69fc:105::3:5474> has quit IRC16:54
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC18:51
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC19:29
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc19:42
*** octavius <octavius!> has quit IRC19:50
*** sadoon[m]1 <sadoon[m]1!~sadoonalb@2001:470:69fc:105::3:5f7c> has quit IRC20:15
*** sadoon[m] <sadoon[m]!~sadoonsou@2001:470:69fc:105::2:bab8> has quit IRC20:23
*** sadoon[m] <sadoon[m]!~sadoonsou@2001:470:69fc:105::2:bab8> has joined #libre-soc20:25
*** josuah <josuah!~josuah@> has quit IRC22:05
*** josuah <josuah!~josuah@> has joined #libre-soc22:05
*** sadoon[m]1 <sadoon[m]1!~sadoonalb@2001:470:69fc:105::3:5f7c> has joined #libre-soc22:33
*** vaino[m] <vaino[m]!~vainomatr@2001:470:69fc:105::3:5474> has joined #libre-soc22:33

Generated by 2.17.1 by Marius Gedminas - find it at!