| *** ibot <ibot!~supybot@libre-riscv.org> has joined #microwatt | 17:19 | |
| *** ibot is now known as Guest2118 | 17:19 | |
| lkcl | i trust that people do not mind, i have introduced an ircbot to #microwatt | 17:28 |
|---|---|---|
| lkcl | https://libre-soc.org/irclog-microwatt/index.html | 17:28 |
| lkcl | toshywoshy: ^ | 17:28 |
| lkcl | this provides an unofficial informal way to refer to prior discussions | 17:28 |
| lkcl | that's if the cron jobs run successfully :) | 17:30 |
| lkcl | mithro: i'd be intrigued to know what the context is for the FP operators for the DSP48E1-FP | 17:31 |
| lkcl | is it a way to target the specific resources of the DSP of a particular FPGA? | 17:32 |
| lkcl | https://github.com/fbrosser/DSP48E1-FP/blob/master/src/FPMult/FPMult.v | 17:32 |
| lkcl | looks pipelined | 17:32 |
| lkcl | and hard-wired to IEEE754 FP32 | 17:34 |
| lkcl | https://github.com/fbrosser/DSP48E1-FP/blob/master/src/FPMult/FPMult_ExecuteModule.v | 17:34 |
| lkcl | i'm not seeing signs of guard, sticky, or rounding bits | 17:35 |
| lkcl | meaning, it'll fail the majority of IEEE754 FP unit tests | 17:35 |
| openpowerbot | [slack] <Gustavo Romero> hmm got it, interesting, so the code is currently wrong no? `core_stopped` is just use to map it in `stat_reg` but not really to trigger when the debugger will rise `core_stop` to effectively stop the core no? in that case only `terminate` is being usedt to drive `core_stop` (well `do_step` but that also is not related to `core_stopped` ) | 17:36 |
| openpowerbot | [slack] <Gustavo Romero> hmm got it, interesting, so the code is currently wrong no? `core_stopped` is just used to map it in `stat_reg` but not really to trigger when the debugger will rise `core_stop` to effectively stop the core no? in that case only `terminate` is being usedt to drive `core_stop` (well `do_step` but that also is not related to `core_stopped` ) | 17:37 |
| openpowerbot | [slack] <Gustavo Romero> hmm got it, interesting, so the code is currently wrong no? `core_stopped` is just used to map it in `stat_reg` but not really used to trigger the core stop when the debugger will rise `core_stop` to effectively stop the core no? in that case only `terminate` is being usedt to drive `core_stop` (well `do_step` but that also is not related to `core_stopped` ) | 17:37 |
| openpowerbot | [slack] <Gustavo Romero> hmm got it, interesting, so the code is currently wrong no? `core_stopped` is just used to map it in `stat_reg` but not really used to trigger the core stop when the debugger will rise `core_stop` to effectively stop the core no? in that case only `terminate` is being used to drive `core_stop` (well `do_step` as well but that also is not related to `core_stopped` ) | 17:38 |
| openpowerbot | [slack] <Gustavo Romero> btw, neat getting NFS working on microwatt 🙂 | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> ```# mount | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> rootfs on / type rootfs (rw,size=113960k,nr_inodes=28490) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> devtmpfs on /dev type devtmpfs (rw,relatime,size=113960k,nr_inodes=28490,mode=755) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> proc on /proc type proc (rw,relatime) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=666) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> tmpfs on /tmp type tmpfs (rw,relatime) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> sysfs on /sys type sysfs (rw,relatime) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> 192.168.15.100:/rootfs on /nfs type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.15.100,mount) | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> # uname -a | 17:39 |
| openpowerbot | [slack] <Gustavo Romero> thanks ; ) | 17:42 |
| openpowerbot | [slack] <Gustavo Romero> @joel @Paul Mackerras @Benjamin Herrenschmidt @Michael Neuling are you ok if I enable by default NFS client v2 and v3 on microwatt? | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> ```diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> index 9465209b8c5b..89d9bff51294 100644 | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> --- a/arch/powerpc/configs/microwatt_defconfig | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> +++ b/arch/powerpc/configs/microwatt_defconfig | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> @@ -77,7 +77,7 @@ CONFIG_SPI_SPIDEV=y | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> # CONFIG_IOMMU_SUPPORT is not set | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> # CONFIG_NVMEM is not set | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> CONFIG_EXT4_FS=y | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> -# CONFIG_FILE_LOCKING is not set | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> +CONFIG_FILE_LOCKING=y | 17:56 |
| openpowerbot | [slack] <Gustavo Romero> # CONFIG_DNOTIFY is not set | 17:56 |
| lkcl | Gustavo: that's incorrect, the DMI VHDL (and Libre-SOC's matching implementation) is correct. | 18:49 |
| lkcl | the DMI implementation is purely a "communication gateway" in effect. | 18:50 |
| lkcl | * you send in a request to STOP by writing to bit 0 of the CTRL register | 18:51 |
| lkcl | * the DMI interface **COMMUNICATES THIS DESIRE** to the main core (which could be in the middle of a fetch, could have large numbers of instructions outstanding in pipelines and FSMs) | 18:52 |
| openpowerbot | [slack] <Gustavo Romero> incorrect in microwatt's code in `core_debug.vhdl` do you meant? | 18:53 |
| openpowerbot | [slack] <Gustavo Romero> incorrect in microwatt's code in `core_debug.vhdl` do you mean? | 18:53 |
| lkcl | * the core, **ON COMPLETION OF ALL OUTSTANDING WORK**, will communicate that it has, in fact, completed all of the outstanding work, by raising the "core_stopped" flag | 18:53 |
| lkcl | (no, i said, "your understanding is incorrect. the *code* is perfectly correct and functions exactly as designed" | 18:53 |
| lkcl | * to ascertain whether the core has in fact now stopped, it is *your* responsibility, as the *USER* of the DMI API, to read the "STAT" register | 18:54 |
| lkcl | * only when the core has raised the "core_stopped" flag can you be absolutely certain that it has, in fact, stopped, AS EARLIER REQUESTED | 18:54 |
| lkcl | the reason for this is that it is completely unreasonable for the core to simply blithely chuck away or terminate work that it is already in the middle of executing | 18:55 |
| lkcl | some of that work is literally impossible to terminate anyway | 18:55 |
| lkcl | (for example, Wishbone LD/STs, once started, you are NOT permitted to terminate them in the middle) | 18:55 |
| lkcl | thus, there MUST be a way to REQUEST stopping and WAIT until stoped | 18:56 |
| lkcl | not | 18:56 |
| lkcl | "do what i say right now, this instantaneous clock cycle, and terminate all and any outstanding work" | 18:56 |
| lkcl | it is simply not possible to meet the expectations that you have, to terminate, instantly, and "stop". | 18:57 |
| lkcl | is that clearer? | 18:57 |
| openpowerbot | [slack] <Gustavo Romero> yep, I think so, thanks for the explanations | 18:58 |
| lkcl | there is one other potential way that the expectation "i raise the "STOP" signal, you (DMI) respond *ONLY* when the core has, in fact "STOPPED"" | 18:58 |
| openpowerbot | [slack] <Gustavo Romero> yes that's more on the lines I was thinking of it | 18:59 |
| openpowerbot | [slack] <Gustavo Romero> fact is that step seems here busted currently | 18:59 |
| lkcl | and it's for the DMI interface to *ONLY* respond with an ACK signal when the core responds (many many cycles later, in the case where it might be in the middle of an IEEE754 FSM) | 18:59 |
| openpowerbot | [slack] <Gustavo Romero> I can stop and start again the core | 18:59 |
| openpowerbot | [slack] <Gustavo Romero> but I can't stop and step for isntance, currently | 18:59 |
| lkcl | 1 sec.. hang on... i explained it already - but let me come back to the DMI "ACK" delay things | 19:00 |
| lkcl | if the implementation of the DMI interface were to be implemented as a synchronous "delay" system, it would have two huge detrimental consequences: | 19:00 |
| lkcl | 1) the extremely simple DMI interface, which responds IMMEDIATELY (one cycle after a command) would now be completely broken, and/or made far more complex | 19:01 |
| lkcl | 2) any down-stream users of that DMI interface - for example JTAG - would likewise be made massively more complex because they would have to take into account the delay in the DMI "ACK" | 19:02 |
| lkcl | the entire DMI interface is designed around the fundamental principle that *at no time* shall there be a delay, period. | 19:02 |
| lkcl | clock cycle 1: send request | 19:02 |
| lkcl | clock cycle 2: receive ack of request | 19:02 |
| lkcl | anything beyond that is far too complex to implement and use | 19:02 |
| lkcl | what that in turn means is that if you want to know what is "in progress", you *HAVE* to send a *SECOND* DMI command in order to determine that fact. | 19:03 |
| lkcl | and, if whatever you are expecting to have been completed has not in fact been completed, then, well, tough, you have to keep looping and polling until it is. | 19:04 |
| lkcl | you *could* in theory stop, then wait say 10 cycles, and *THEN* step | 19:04 |
| lkcl | but what if you issued "STOP" just as the core was running an IEEE754 DIV operation? | 19:05 |
| lkcl | which takes tens of cycles to complete? | 19:05 |
| lkcl | bottom line is, you *must* follow the procedure. | 19:05 |
| lkcl | 1) issue STOP | 19:05 |
| lkcl | 2) read STAT, check "STOPPED" bit, repeat until set | 19:05 |
| lkcl | 3) **ONLY THEN** issue "step" | 19:05 |
| openpowerbot | [slack] <Gustavo Romero> I'm totally ok that the user should loop and poll the state util the core is really stopped | 19:06 |
| lkcl | 4) repeat step (2) to make sure that it's actually stopped (again) after running the "stepped" instruction | 19:06 |
| lkcl | take a close look, again, at the sim.py code i sent. | 19:06 |
| lkcl | follow the FSM through, which follows the stop-poll-step-poll procedure | 19:07 |
| lkcl | it worked perfectly fine on both Microwatt and Libre-SOC when i wrote it, last year, and was using it to do $Display dumps of all register files after each single-stepped instruction | 19:07 |
| lkcl | that was how i got exact and precise instruction-for-instruction compliance with Microwatt | 19:08 |
| openpowerbot | [slack] <Gustavo Romero> but what I meant is that it seems that `core_stopped` is never ever raised after a stop is requested or `stopping`signal is never cleared once `core_stopped` is raised | 19:08 |
| lkcl | by comparing the 2 debug outputs | 19:08 |
| lkcl | after how many clock cycles did you read the STAT register, and did you put it on a "loop"? | 19:08 |
| lkcl | it could be 5 cycles, it could be 50 cycles, it could be 100 cycles | 19:08 |
| lkcl | it's been a year since i ran sim.py so i can't tell you exactly how long it will take for core_stopped to be raised | 19:09 |
| lkcl | plus, it varies depending on what instruction is being executed, anyway | 19:10 |
| openpowerbot | [slack] <Gustavo Romero> wm_debug step will read the stat_reg and check for the stopping bit, if it's set it will say core is not stopped, so if run that comment some seconds apart it should at some point read `stopping` as `0` . some seconds apart on 100Mhz isn't enough cycles to let the cpu complete its work? | 19:11 |
| lkcl | reminder, sim.py with (working) DMI interface interaction: https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=sim.py;hb=HEAD | 19:11 |
| lkcl | apologies i don't know what wm_debug is | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> ah ok, it's a simple tool in microwatt's script/mw_debug | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> the issue I'm talking about is: | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> ```gromero@gromero2:~/git/microwatt/scripts/mw_debug$ mw stop | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> Connected to libftdi driver. | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> Found device ID: 0x13631093 | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> Core: stopping | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> NIA: c000000000064348 | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> MSR: 9000000000001001 | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> gromero@gromero2:~/git/microwatt/scripts/mw_debug$ mw step | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> Connected to libftdi driver. | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> Found device ID: 0x13631093 | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> Core not stopped ! | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> Core: stopping | 19:12 |
| openpowerbot | [slack] <Gustavo Romero> NIA: 0000000000000900 | 19:13 |
| openpowerbot | [slack] <Gustavo Romero> the first command sends a stop request via DMI | 19:13 |
| lkcl | 1 sec, let me take a look | 19:13 |
| openpowerbot | [slack] <Gustavo Romero> and the second one will only step if the CPU is really stopped as you said | 19:13 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/master/scripts/mw_debug/mw_debug.c | 19:14 |
| openpowerbot | [slack] <Gustavo Romero> however it checks for stat_reg bit `stopping`which apparently never gets cleaned , hence the `Core not stopped !` | 19:14 |
| lkcl | then that'll be a bug, if it's being polled correctly | 19:14 |
| * lkcl looking for where core_status is called | 19:14 | |
| openpowerbot | [slack] <Gustavo Romero> I can't see in vhdl `stopping` being cleaned except on reset and when `start` is requested... | 19:14 |
| openpowerbot | [slack] <Gustavo Romero> so I'm wondering if that's right | 19:15 |
| lkcl | hmm, core_status is only called at the end of the mw_debug command. odd | 19:15 |
| lkcl | where is mw_debug called from? | 19:15 |
| openpowerbot | [slack] <Gustavo Romero> from the command line | 19:16 |
| lkcl | once and only once? | 19:16 |
| openpowerbot | [slack] <Gustavo Romero> it's actually like a tiny debugger using the DMI | 19:16 |
| openpowerbot | [slack] <Gustavo Romero> so you can run it many times | 19:16 |
| openpowerbot | [slack] <Gustavo Romero> to get register status, etc | 19:17 |
| openpowerbot | [slack] <Gustavo Romero> stop cpu | 19:17 |
| lkcl | because if it's only called once, i would indeed expect the possibility that core_status *might* report "not stopped" | 19:17 |
| openpowerbot | [slack] <Gustavo Romero> and step (which seems to not be working 🙂 ) | 19:17 |
| lkcl | there's no polling | 19:17 |
| lkcl | i mean, however, if you issue the stop command | 19:17 |
| lkcl | then wait several seconds | 19:17 |
| lkcl | then request a status | 19:18 |
| lkcl | there's no way that the "stopping" should not, by that time, have actually stopped. | 19:18 |
| openpowerbot | [slack] <Gustavo Romero> there is no polling right, but there is check for stopping bit in stat_reg before a step command | 19:18 |
| lkcl | millions of clock cycles would have passed | 19:18 |
| lkcl | yeah that's a good idea | 19:18 |
| lkcl | issuing "STEP" when the core's not actually stopped is bad | 19:18 |
| lkcl | Bad (tm) :) | 19:19 |
| openpowerbot | [slack] <Gustavo Romero> if I do `mw_debug stop` wait let's say 40 s then do `mw_debug step` and it checks for the bit in question that would have the same result of a polling | 19:19 |
| lkcl | let me just do a quick checkout of the latest microwatt HDL | 19:19 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/0a415410c9f75e4fd8699c70b43dc26d4114d6ed/core_debug.vhdl#L32 | 19:21 |
| lkcl | is an input | 19:21 |
| openpowerbot | [slack] <Gustavo Romero> my point is: where in core_debug.vhdl `stopping` bit (which is checked by mw_debug before doing a `step` ) is cleared if not in reset or start state | 19:21 |
| lkcl | reported here | 19:21 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/0a415410c9f75e4fd8699c70b43dc26d4114d6ed/core_debug.vhdl#L128 | 19:21 |
| openpowerbot | [slack] <Gustavo Romero> right | 19:21 |
| openpowerbot | [slack] <Gustavo Romero> core_stopped comes from the core | 19:22 |
| lkcl | grep core_stopped *.vhdl ==> .... | 19:22 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/0a415410c9f75e4fd8699c70b43dc26d4114d6ed/core.vhdl#L484 | 19:22 |
| lkcl | which connects dbg_core_is_stopped | 19:22 |
| lkcl | grep dbg_core_is_stopped *.vhdl ==> | 19:22 |
| lkcl | is connected to decode2.vhdl | 19:23 |
| lkcl | decode2.vhdl's stopped_out signal | 19:23 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/0a415410c9f75e4fd8699c70b43dc26d4114d6ed/decode2.vhdl#L26 | 19:23 |
| lkcl | which is connected to work.control | 19:24 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/0a415410c9f75e4fd8699c70b43dc26d4114d6ed/decode2.vhdl#L339 | 19:24 |
| lkcl | grep stopped_out *.vhdl ==> control.vhdl | 19:24 |
| lkcl | which leads here | 19:25 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/0a415410c9f75e4fd8699c70b43dc26d4114d6ed/control.vhdl#L253 | 19:25 |
| lkcl | stop_mark_in is probably the request (when it was made) via the DMI command "STOP" | 19:26 |
| lkcl | v_int.outstanding is probably the Register Hazard system | 19:27 |
| lkcl | i.e. "it's a bad idea to tell you we stopped when there's still stuff outstanding to write to the regfile" | 19:27 |
| lkcl | :) | 19:27 |
| lkcl | there's been quite a few changes since i used this | 19:29 |
| lkcl | including | 19:29 |
| lkcl | https://github.com/antonblanchard/microwatt/commit/31b55b2a75cd439a00c5eeb3f246e4c2805137ed#diff-e55d140d3f570910e5c7df73af5c77184171361243e42e7460237829f0922d90 | 19:29 |
| lkcl | which changes the way that "outstanding" is written to | 19:29 |
| lkcl | i am using a version of microwatt that is around a year old | 19:29 |
| lkcl | so it *may* be the case that there have been bugs introduced | 19:29 |
| lkcl | i.e. an unintentional side-effect of some of those changes resulted in the stopped_out not being set. | 19:31 |
| lkcl | don't honestly know. | 19:31 |
| lkcl | there's enough to justify raising a bugreport about it (expected behaviour of mw_debug is broken) | 19:32 |
| lkcl | and hey! there's an IRC log bot now, so it's possible to provide this URL as context in the bugreport! | 19:33 |
| lkcl | https://libre-soc.org/irclog-microwatt/%23microwatt.2021-09-16.log.html#t2021-09-16T19:12:49 | 19:33 |
| lkcl | :) | 19:33 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!