<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 787f051 - Deploying to main from @ amaranth-lang/amaranth@41762f143538488b568302ac30801a59ca09c86b 🚀
<vup>
whitequark / mwk: what is supposed to happen in amaranth if you give a `Format("{:c}", sig)` a `sig` that is bigger than 32 bits? The rfc says it follows the Python semantics, which gives a `OverflowError: %c arg not in range(0x110000)`, but this obviously doesn't care about the "number of bits" and only about the value as the Python int is bigint. The `emit_rtlil` part of `kernel/fmt.cc` of yosys, has a `log_assert(part.sig.size() <= 32)` (see https://
<vup>
But I don't think this can actually be hit, as `emit_rtlil` is only called when parsing a verilog format statement, which cannot generate a `UNICHAR` format type
<whitequark[cis]>
vup: `{:c}` is a character, right? why are you even doing that?
<whitequark[cis]>
we actually discussed that and iirc anything above ASCII is undefined
<whitequark[cis]>
although there is a UTF-8 encoder I've hidden inside of the Yosys string formatting code
<vup>
yes, `c` is a character, im am not using it, just trying to figure out the semantics of `UNICHAR` to fix https://github.com/YosysHQ/yosys/issues/4644, and seeing that it got added to be able to translate the amaranth `c` format specificier I was working backwards from there. (As UNICHAR and the others added in https://github.com/YosysHQ/yosys/pull/4301 did not get documented in the yosys_internals docs)
<whitequark[cis]>
I'm not sure I've even known about yosys_internals at the time...
<whitequark[cis]>
anyway, UNICHAR is a unicode code point
<whitequark[cis]>
if you pass more than a 21 bit signal to it, it's an error. we could just trim it to 21 bits
<_whitenotifier>
[amaranth-lang/rtl-debugger] whitequark a3c8178 - Implement a command to directly set current time cursor.
<vup>
makes sense, should I submit a PR that makes amaranth error out when trying to format a signal with more than 21 bits with the `c` format specifier?
<whitequark[cis]>
let's wait for mwk
<whitequark[cis]>
but yeah
<Wanda[cis]>
hm
<Wanda[cis]>
it may be a little annoying
<Wanda[cis]>
storing unicode characters in 32-bit containers is a thing, right?
<vup>
I guess so, the main thing I would be worried about would be, that just silently casting that to 21 bits / ignoring the upper bits could make things hard to debug
<Wanda[cis]>
you could just emit U+FFFD whenever the character doesn't fit in 21-bit
<Wanda[cis]>
this is not a unique situation; even if you limit the input to 21-bit, the valid unicode codepoint range is not 0..(2 ** 21)
<Wanda[cis]>
so I don't see why you're concerned about things not fitting in 21 bits; you have to handle invalid codepoints somehow anyway
<vup>
yes true, the bit depth based check idea is coming from the `log_assert(part.sig.size())` in `emit_rtlil` of `Fmt`, but as I said, as far as I can tell that sould never trigger anyways.
<vup>
but yeah, I like the idea of replacing it with U+FFFD whenever the character is outside [0x0, 0x10FFFF]
<Wanda[cis]>
mhm
<Wanda[cis]>
(you also have to replace surrogate code points)
<_whitenotifier>
[amaranth-lang/rtl-debugger] whitequark 71027d2 - Examine scopes only within specific super-scopes, like with items.
d_olex has joined #amaranth-lang
<whitequark[cis]>
do any of you want to test the RTL debugger? it doesn't have waveform viewing yet but you can add variables to the watchlist and step through the execution of your code
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] c6c0e0e - Deploying to main from @ amaranth-lang/amaranth@b6bf515e5b2f7cb64fbeac7f17997e5099a80731 🚀
Xesxen has quit [Read error: Connection reset by peer]
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined #amaranth-lang
FFY00 has joined #amaranth-lang
FFY00_ has quit [Ping timeout: 252 seconds]
John_K has joined #amaranth-lang
<John_K>
thanks, SimulationPort worked for me. Is there a better way to assign to it than manually shoving bits at s_port._i?
<whitequark[cis]>
wait, ._i?
John_K has quit [Quit: Client closed]
John_K has joined #amaranth-lang
<John_K>
(unsure if previous message sent correctly) Yeah ctx.set(bus.clk, 1) results in TypeError: Object SimulationPort(i=(sig clk__i), invert=False, direction=Direction.Input) cannot be converted to an Amaranth value
<zyp[m]>
shouldn't it be ctx.set(bus.clk.i, 1)?
<John_K>
...that also works. I'm not sure why I didn't try that last night. I'd been grasping around by looking at the output of dir() on the various parts to figure out how to do this
<zyp[m]>
it's also possible to pass a platform object to an elaboratable before you pass it to the simulator, ref. the discussion around my proposed RFC 48
<John_K>
oh, that's interesting. I ended up ditching the platform approach and just passing a PortGroup to my class's constructor in order to make it easier for simulation
<zyp[m]>
I've got some code that does that, but it predates RFC 55 and RFC 69 and was also based on a draft of RFC 36 that changed significantly afterwards, so it's not very useful anymore
<zyp[m]>
I plan to circle back to it at some point though
<John_K>
I'll go take a look at those RFC's after I'm done this work
<John_K>
another weird question, how do I print out the text label of the current FSM state? m.d.comb += Print("Bus State FSM: ", fsm.state) only prints the numerical index. I figured there would be a way to use the fsm.state.decoder() to get it, but I couldn't figure out the right thing to pass as an argument
<John_K>
I'm happy to help improve documents on all of this btw