<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 0babe7a - Deploying to main from @ amaranth-lang/amaranth@7870eb344b143dbc3b4f1a03b0a1e178196b8ef8 🚀
buganini has quit [Read error: Connection reset by peer]
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 785f2b9 - Deploying to main from @ amaranth-lang/amaranth@0140fe27e2f80464d640b346ac2f9b893d791a9b 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 28da18f - Deploying to main from @ amaranth-lang/amaranth@c649045f354db58e2b7e2ced4b7fbd0de3d71f90 🚀
<_whitenotifier-9>
[amaranth] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-1378-c649045f354db58e2b7e2ced4b7fbd0de3d71f90 - https://github.com/amaranth-lang/amaranth
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 59574b2 - Deploying to main from @ amaranth-lang/amaranth@6a2e789333520656376dae4dfedc197263687394 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] b61c3fc - Deploying to main from @ amaranth-lang/amaranth@86fdaba2db34b42a0ea990cbea28d073082c6855 🚀
underst0rm[m] has joined #amaranth-lang
<underst0rm[m]>
Can one also simulate external instances that are not amaranth code? Didn't see this in the docs.
<whitequark[cis]>
not currently
<whitequark[cis]>
but in the next release you should be able to
notgull has joined #amaranth-lang
notgull has quit [Ping timeout: 268 seconds]
<whitequark[cis]>
reminder: meeting in ~20 min
buganini has joined #amaranth-lang
<tpw_rules>
whitequark[cis]: random curious nit: is there a difference between .assertRaises(msg) and .assertRaisesRegex(f"^{msg}$")? you seem to prefer the latter
<whitequark[cis]>
iirc the former doesn't work correctly
<whitequark[cis]>
i think it.s something like... .assertRaises(msg) treats msg as the message to throw if the code doesn't raise anything
<tpw_rules>
"Changed in version 3.3: Added the msg keyword argument when used as a context manager."
<tpw_rules>
so you can do .assertRaises(msg=msg). just remembered i had found that out for that PR you recently reviewed and found the ^$ a bit bumpy
<tpw_rules>
actually you might be right. it's still unclear from the docs
<whitequark[cis]>
well you also often have to use assertRaisesRegex if you have {!r} in the exception string
<whitequark[cis]>
yeah, assertRaises just does not let you check the message
<whitequark[cis]>
and if you use msg="" thinking it's a comparison it does something completely wrong
<whitequark[cis]>
I don't love unittest
<tpw_rules>
oops
<whitequark[cis]>
good evening everyone, it is time for our weekly scheduled meeting
buganini has quit [Read error: Connection reset by peer]
<whitequark[cis]>
who is attending?
<tpw_rules>
hello, i am
Chips4MakersakaS has joined #amaranth-lang
<Chips4MakersakaS>
Still having dinner
zyp[m] has joined #amaranth-lang
<zyp[m]>
I'm here, but it's currently 2AM here, so I'm not sure I'll remain awake for the whole meeting
<whitequark[cis]>
does anyone have any comments on the RFC before we start discussing the unresolved questions?
<Wanda[cis]>
I think it's good
<whitequark[cis]>
yeah i'm happy with it
<tpw_rules>
it is deliberate that there is no __int__ or __float__ right?
<whitequark[cis]>
> Simulator and SimulatorContext both have a .time() -> Period method added that returns the elapsed time since start of simulation.
<whitequark[cis]>
I wonder if `.current_time()` or `.next_time()` would not be more appropriate
<whitequark[cis]>
(the way that method is going to work is that it's going to return the next timestep to be processed
<whitequark[cis]>
* be processed)
<whitequark[cis]>
tpw_rules: time is not a number!
<zyp[m]>
maybe .elapsed_time()
<whitequark[cis]>
I'm happy with that
<whitequark[cis]>
does anyone want to object to Period.MHz(1) and prefer Period.mhz(1) instead?
<whitequark[cis]>
to me the second option looks deranged
<tpw_rules>
i think it's okay as a method name
<tpw_rules>
if it were a property think it would be deranged...
<tpw_rules>
isn't elapsed time one "tick" different from the next timestamp to be processed?
<whitequark[cis]>
what is a tick?
buganini has quit [Ping timeout: 268 seconds]
<zyp[m]>
what do you even mean by «next timestamp to be processed»?
<tpw_rules>
the difference between the timestamp that was just processed and the next timestamp to process
<tpw_rules>
like next is in the future, right?
<zyp[m]>
if a testbench does elapsed_time(), delay(10ms), elapsed_time(), I expect them to return respectively 0ms and 10ms
<whitequark[cis]>
actually on second thought i think this RFC should not define exactly what .elapsed_time() returns
<whitequark[cis]>
zyp[m]: this would of course be held
<whitequark[cis]>
but consider calling sim.advance(): does sim.elapsed_time() return the time before the chunk of timeline where nothing is happening, or after?
<Chips4MakersakaS>
I'm used to think about clocks in frequencies not periods so would there be a Period.frequency or do you have to convert it oneself each time one want to report it to the user ?
<zyp[m]>
that's unresolved question #3
<tpw_rules>
according to the advance() docs it would be after
<Chips4MakersakaS>
Doh, and I did read it.
<Chips4MakersakaS>
So I would say yet.
<Chips4MakersakaS>
yet-
<Chips4MakersakaS>
yet->yes
<Wanda[cis]>
I think run_until is a more interesting case
<whitequark[cis]>
(it's just advance in a loop...)
<Wanda[cis]>
yes, but
<Wanda[cis]>
advance is a lower level primitive, and it's not surprising that the elapsed time will be set to the next event time
<Wanda[cis]>
with run_until, one could have an expectation that elapsed_time would be exactly equal to what was requested
<whitequark[cis]>
that's not possible though
<whitequark[cis]>
or well... until you've completed looping on a time point you wouldn't know if you've evaluated everything for that time point
<whitequark[cis]>
so if you want .run_until() to be inclusive you have to accept that .elapsed_time() would return something past it
<whitequark[cis]>
or it would have to be exclusive
<zyp[m]>
is the problem «zero-time» steps that are actually spaced femtoseconds apart?
<Wanda[cis]>
that doesn't work when simulation finishes due to no more events though?
<whitequark[cis]>
zero-time steps take actual zero time
<Wanda[cis]>
well, not "due to", but "with", which is a thing that can happen
<whitequark[cis]>
in that case run_until() can create an artificial event at exactly that time
<whitequark[cis]>
I guess the notion of "elapsed time" is just not well defined
<whitequark[cis]>
for example a=elapsed_time(); tick(); b=elapsed_time(); b-a could very well return 0
<whitequark[cis]>
which by the way would create a problem for the reciprocal methods, which is why I'm personally opposed to them
<Wanda[cis]>
that's fine though?
<zyp[m]>
I figure reciprocal properties would mostly see use in platform code that's dealing with clocks, not simulation code
<whitequark[cis]>
I guess the only thing we can actually guarantee that in a testbench, a=elapsed_time(); delay(x); b=elapsed_time(); assert x==b-a always holds
<whitequark[cis]>
and that if you wake up in a testbench, elapsed_time() points to wherever in the VCD the event that woke you up is
<whitequark[cis]>
come to think of it, should we just not have elapsed_time() on Simulator? that would solve most of the problem
<zyp[m]>
if scope was limited to simulation, I'd also argue for leaving them out, but if we're gonna use it to define clocks, it does make sense to have an easy way to convert it to frequencies
<Wanda[cis]>
whitequark[cis]: I'm thinking of it as well
<Chips4MakersakaS>
<whitequark[cis]> "which by the way would create..." <- Should we then be using the same type for a frequency and for elapsed time. You can argue frequency is not a period but period is a characteristic of a frequency.
<whitequark[cis]>
periods can be used to specify waveforms that aren't 50% duty square waves
<whitequark[cis]>
if you look at pnr tools, waveforms are specified using periods between events (vivado can take an arbitrary period waveform as a clock i think?)
<whitequark[cis]>
the reason i wanted a period data type is that, beyond its usefulness to simulations, you can use it to define any sort of waveform or event sequence
<whitequark[cis]>
but a frequency only lets you define a small subset
<whitequark[cis]>
s/period/periodic/
<zyp[m]>
I think it's fine for reciprocal properties to raise ZeroDivisionError or similar if the period is zero
<whitequark[cis]>
yeah, that's true
<whitequark[cis]>
what about names
<zyp[m]>
.hertz, .kilohertz, .megahertz, .gigahertz to be consistent
<whitequark[cis]>
hm, okay
<Chips4MakersakaS>
Maybe frequency could be method of Clock and then does not need to be of Period.
<tpw_rules>
bleh for the consturctors
<tpw_rules>
for the properties, sure
<whitequark[cis]>
please be clear on what you dislike
<Wanda[cis]>
I think having uppercase methods in Python looks Weird
<Wanda[cis]>
if the compromise ends up as megahertz, I can live with that
<whitequark[cis]>
the megahertz is a property, the MHz is a constructor
<tpw_rules>
i think having it fully spelled out for the properties is fine. i would not want such a long constructor name
<Wanda[cis]>
what
<Wanda[cis]>
no, that's just horrible
<Wanda[cis]>
there's absolutely no way I'd remember which is which
<whitequark[cis]>
seems fine to me; the short one is the one you want most of the time
<whitequark[cis]>
the properties aren't going to be used much
<whitequark[cis]>
okay; I feel like the RFC needs further discussion on GitHub before we can decide what to do with it (also I'm just very physically fatigued)
<whitequark[cis]>
that's it for today's meeting. on the next week I am (pending confirmation, but almost certainly) on vacation
<whitequark[cis]>
so let's discuss this further on GitHub and then continue in two weeks. thanks everyone!
<tpw_rules>
is the second meeting item also pushed two weeks out?
<zyp[m]>
in two weeks I'll be on a plane, probably without internet access
<whitequark[cis]>
tpw_rules: correct. although my view is that fixing the underlying issue doesn't require an RFC in first place
<whitequark[cis]>
so it doesn't seem especially problematic
<zyp[m]>
wait, I might be getting the date wrong
<whitequark[cis]>
24
<Wanda[cis]>
there's a proposed fix that would just handle the problem without adding any new methods at all
<Wanda[cis]>
so it's pretty likely that I'll just implement it and end up thrashing the RFC
<whitequark[cis]>
the API proposed in the RFC is also rather complex and doesn't seem worth the cognitive burden
<Wanda[cis]>
yup
<whitequark[cis]>
anyway, Wanda can you do the honors please?
<whitequark[cis]>
uh... write minutes under the RFC we discussed
<Wanda[cis]>
alright
<zyp[m]>
whitequark[cis]: yeah, I'm just getting confused by timezones
<whitequark[cis]>
very ironic, considering the topic of your RFC
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] c803614 - Deploying to main from @ amaranth-lang/amaranth-soc@e1b842800533f44924f21c3867bc2290084d100f 🚀