| lkcl | that's what i used to do microwatt-libresoc comparisons | 01:26 |
|---|---|---|
| lkcl | the $display output dumps the entire regfile in between single-steps (by reading over DMI) | 01:26 |
| lkcl | and you can do a "diff" of the two output files. | 01:27 |
| lkcl | toshywoshy, thank you, bot's woken up again | 11:38 |
| cesar | Got the DMI log from both libresoc and microwatt. | 15:10 |
| cesar | The microwatt one is consistent with single-stepping: the pc mostly increments by 4, except when it jumps. | 15:12 |
| cesar | The libresoc one seems strange: most pc readings are duplicated once, sometimes twice. | 15:14 |
| cesar | Investigating. | 15:15 |
| lkcl | ah nice, that you got microwatt up and running as well | 17:11 |
| lkcl | you can do a FST/VCD dump with verilator but you have to double-convert it | 17:12 |
| lkcl | vcd2fst then fst2vcd | 17:12 |
| lkcl | this "fixes" severe flaws in the file layout that gtkwave is unable to cope with | 17:12 |
| lkcl | sigh | 17:12 |
| cesar | OK, I see now how a DMI single-step command results in the core being released (setting execution in motion), and stopped in the very next clock cycle (which takes effect as soon as execution finishes). Sorry for the noise. | 18:33 |
| cesar | There still seem to be a problem where not every core release sets execution in motion. Maybe something to do with the FSM changes for SVP64. Investigating. | 18:37 |
| cesar | Argh, seems like it. I didn't anticipate core_stop being pulsed low. | 18:53 |
| cesar | Since we want to single-step a VL loop, I had put another core stop check after Execute. Together with the check before Fetch, that's two core stop checks in a row. | 18:59 |
| lkcl | :) | 19:03 |
| lkcl | one of the reasons why the --no-svp64 mode exists | 19:03 |
| cesar | As core_stop is pulsed high, the second check before Fetch catches it and doesn't resume execution. | 19:03 |
| cesar | Bad news: I think it affects --no-svp64. | 19:04 |
| cesar | Have to see the version that's on the chip. | 19:04 |
| cesar | I think the bug was introduced on Mar 7, commit e4b8ab4151fd21af0c9a7958df3c05026332b760 | 19:24 |
| cesar | lkcl: Do you know if the chip has it? | 19:24 |
| cesar | Well, looking at the dates in soclayout, I guess it does... | 19:40 |
| cesar | Well, the way it works, it will actually take two DMI single-steps to advance a single instruction. Taking that into account, I think all is well. | 19:54 |
| lkcl | cesar, ok, whew, that's a relief | 20:04 |
| cesar | On trouble, tough. If the core is running, and you stop it, you don't know if it stopped after Execute, or before Fetch. | 20:10 |
| programmerjake | oh, lkcl: on naga they mentioned a real DX12 API ident: VPAndRTArrayIndexFromAnyShaderFeedingRasterizerSupportedWithoutGSEmulation | 20:13 |
| programmerjake | they were mentioning that it was too confusing, joking that it should be: ViewPortAndRenderTargetArrayIndexFromAnyShaderFeedingRasterizerSupportedWithoutGeometryShaderEmulation | 20:14 |
| programmerjake | one ident that's longer than your 80-char limit!! | 20:15 |
| lkcl | oh fer god's sake :) | 20:32 |
| Veera[m] | Hi | 22:09 |
| Veera[m] | lkcl: How far you went with symbiflow install and use? | 22:10 |
| cesar | programmerjake: If it was a Power instruction, it would be (by initials): vpartaifasfrswgse | 22:40 |
| programmerjake | XD | 22:49 |
| programmerjake | meeting in 4min: lkcl cesar lxo etc. | 22:56 |
| Veera[m] | programmerjake: where is the meeting happening | 22:59 |
| programmerjake | on jitsi, i'll send you the link privately | 23:01 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!