<_whitenotifier-1>
[amaranth-lang/rtl-debugger] whitequark 2bff774 - Improve hierarchy display and navigation.
<_whitenotifier-1>
[amaranth-lang/rtl-debugger] whitequark 89cbb22 - Implement more features.
<_whitenotifier-1>
[amaranth-lang/rtl-debugger] ... and 5 more commits.
<whitequark[cis]>
good news: I can now publish my work on "RTL debugger", an interactive tool that lets you single-step your hardware design and observe its state, currently integrated into VS Code as an extension but using an open protocol https://github.com/amaranth-lang/rtl-debugger
<whitequark[cis]>
right now it's in a very early state and not all that useful, but this should change in the coming days
<whitequark[cis]>
the idea I had that led me to designing it is that a waveform viewer is useful but in many cases it's a downright unfriendly experience; rather, being able to set breakpoints, see terminal output (via Print statements in Amaranth or $display statements in Verilog), and step forward and back, while still retaining waveform viewer integration, would make certain workflows much easier, especially to new developers
<whitequark[cis]>
imagine being able to set a breakpoint on a condition in your source code, and then run your simulation up until the point where the condition becomes true--all with as little as 10% time overhead and without multi-gigabyte VCD files, but while still retaining the full view of the design... anywhere in a mixed Amaranth/Verilog/VHDL environment
<whitequark[cis]>
this was prototyped and should be ready for use with just a bit of development and polishing
<_whitenotifier-1>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] ad7c888 - Deploying to main from @ amaranth-lang/amaranth@c6090255aa9be4b985fb8abcac771780d69c3013 🚀
buganini has quit [Ping timeout: 246 seconds]
galibert[m] has joined #amaranth-lang
<galibert[m]>
Catherine: that looks very, very interesting
<galibert[m]>
Unrelated, you who has played with usb at low level, do you have any idea how what the timings should be for retrying after getting a NAK?
<galibert[m]>
I just can't find the appropriate google invocation to ferret out the information, and the usb standard is silent on that
<whitequark[cis]>
it's up to the HC
<galibert[m]>
I was afraid of that. Any idea what's a typical value?
<galibert[m]>
(need to simulate a host to get the descriptors & co information out of an emulated usb device)
Guest21 has joined #amaranth-lang
<Guest21>
Hi I want to know if we can add external verilog file in amarnath-hdl project
<vup>
I am having troubles understanding the following combinatorial cycle error:
<vup>
/tmp/test.py:13: signal flit_out__payload bit 0
<vup>
/tmp/test.py:16: cell AssignmentList bit 0
<vup>
/tmp/test.py:15: cell PriorityMatch bit 0
<vup>
/tmp/test.py:15: cell Matches bit 0
<vup>
/tmp/test.py:15: operator & bit 0
<vup>
```
<vup>
And removing the comb assignment in the if statement removes it, but I dont see how this forms a combinatorial cycle, as `payload.data` and `payload.last` should be unrelated?
<galibert[m]>
IIRC they're not, you need an Interface for that
<whitequark[cis]>
<galibert[m]> "I was afraid of that. Any..." <- "next microframe" will work
<whitequark[cis]>
Guest21: platform.add_file()
<galibert[m]>
ok, 125us then, thanks
<whitequark[cis]>
it's usually that or next frame
<galibert[m]>
Yeah, I'll hook the retry on the SOF, that sounds viable
<vup>
galibert[m]: thats unfortunate, is there some more advanced comb cycle analysis planned down the line that understands structs?
<galibert[m]>
I don't know, but don't use structs when you want an interface would be an obvious answer
<galibert[m]>
Interface is not just a struct with directionality
<galibert[m]>
Structs decompose a pile-of-bits, while interfaces compose a set of signals
<galibert[m]>
(for now, Catherine may or may not want to change that at some point)
<whitequark[cis]>
hm, NIR is done on the bit level already
<whitequark[cis]>
interfaces and structs should be handled exactly the same, for the reasons vup brings up and others
<whitequark[cis]>
are you sure the initial analysis is correct?
<galibert[m]>
They should both be composition then? Nice to know
<whitequark[cis]>
well it's just that for timing/dependency/other netlist purposes, they are treated as collections of nets
<whitequark[cis]>
signals are aesthetical only during and after NIR
<galibert[m]>
vup: I don't get what is driving data in the first place?
<galibert[m]>
well payload.data
<whitequark[cis]>
Wanda: can you take a look please?
<vup>
galibert[m]: well nothing, but this should still be valid, no? (was too lazy to make it a port, because slices cannot be a port)
<galibert[m]>
I see, so nothing should read last and even less loop it
<galibert[m]>
nothing writes data, nothing reads last, so yeah, a loop is surprising
<zyp[m]>
<galibert[m]> "Unrelated, you who has played..." <- FS or HS?
zyp[m] has joined #amaranth-lang
<zyp[m]>
IME for FS a host controller will typically retry continously whenever it doesn't have anything better to do, i.e. many times per frame
<zyp[m]>
for HS there's a more elaborate flow control mechanism involving PING and NYET tokens, and bInterval
buganini has joined #amaranth-lang
buganini has quit [Read error: Connection reset by peer]
buganini has joined #amaranth-lang
buganini has quit [Read error: Connection reset by peer]
<vup>
so i looked at the `comb_edges_to` of assignmentlist and it is not clear to me why the condition for every assignment, even those that do not assign to the bit requested, should be part of the `comb_edges_to`...
<_whitenotifier-1>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] b9b2699 - Deploying to main from @ amaranth-lang/amaranth@8c5ed4051dd74a6347af8d52f8e397eb53218ac4 🚀
<whitequark[cis]>
zyp: so, I don't think this is a very good way to handle the issue
<whitequark[cis]>
even ignoring the use of a private API, it's littering the code with warnings that are in fact on point
<whitequark[cis]>
I think the PYTHONWARNINGS variable lets you exclude warnings based on a rege
<whitequark[cis]>
s//`/, s//`/, s/rege/regex/
<whitequark[cis]>
you should be able to use that to exclude them
buganini has quit [Remote host closed the connection]
<zyp[m]>
just for the smoketest CI workflows then?
<whitequark[cis]>
i think so, yes
<zyp[m]>
okay, I'll try figuring it out
<whitequark[cis]>
thanks ^^
<zyp[m]>
better? it doesn't seem like I can modify PYTHONWARNINGS in the CI workflow when it's overridden in pyproject.toml, so I resorted to editing pyproject.toml instead
<whitequark[cis]>
yep
<whitequark[cis]>
thanks
<zyp[m]>
I can do PRs for the actual deprecation fixes as well, to be merged once 0.6 is out, since I already made those changes as well