10:36 <Chips4MakersakaS> I won't be able to join call later today. For #66, I don't have preference on solutions for concerns of last discussion so happy to accept any outcome of discussion on it.

10:36 <Chips4MakersakaS> Only I find that talking in periods on clocks feels less natural than talking about them in frequency; e.g. 200MHz clock vs 5ns clock period.

11:40 <whitequark[cis]> the idea is that you pick whichever number is more convenient for you

11:40 <whitequark[cis]> right now you have to use periods, but with this RFC, you could do frequency too

12:10 <Chips4MakersakaS> I see it for definition where you can easily specify period from a frequency. I was more thinking about reporting, e.g. reporting the frequency of a clock without always needing to have to compute freq. from period oneself; e.g. the open question about having reciprocal properties available for this purpose.

12:11 <zyp[m]> those properties were added in the last revision of the RFC

12:12 <Chips4MakersakaS> I'm really bad at reading RFCs it seems...

12:12 <Chips4MakersakaS> All OK for this RFC from my side.

12:12 <zyp[m]> the reason those weren't there from the beginning is because the scope of the RFC was originally about elapsed simulation time, before it was expanded to also cover clock periods

17:01 <whitequark[cis]> good evening everyone, it is time for our weekly Amaranth core language meeting

17:01 <whitequark[cis]> who is attending?

17:01 <Wanda[cis]> meow

17:02 <jfng[m]> o/

17:02 <mcc111[m]> hi

17:10 <tpw_rules> hello

17:10 <whitequark[cis]> today we have one item on the agenda, RFC #66: Simulation time https://github.com/amaranth-lang/rfcs/pull/66

17:12 <jfng[m]> should we wait until zyp is here before voting ?

17:12 <Wanda[cis]> I'm not convinced the *hertz accessors should return a Fraction instead of a float

17:14 <whitequark[cis]> oh yes, we should definitely make sure zyp is here

17:15 <Wanda[cis]> like... either the original frequency was such that the period comes out exact, and you get an exact result in fraction which would also be exact as float, or you get a rounding error on the original conversion to period, and getting back the frequency as a Fraction is completely pointless

17:17 <mcc111[m]> whitequark[cis]: So is the discussion happening today, then?

17:26 <whitequark[cis]> I think I'm not actually feeling well enough to conduct a meeting. sorry everyone

17:26 <jfng[m]> no worries, let's continue next week

17:27 <mcc111[m]> I am not sure I will be present for next week's meeting, but I have a minor suggestion, so I will put it in the issue.

17:27 <tpw_rules> sounds good

17:29 <_whitenotifier-9> [rfcs] mcclure commented on pull request #66: RFC #66: Simulation time - https://github.com/amaranth-lang/rfcs/pull/66#issuecomment-2229028837

17:29 <mcc111[m]> * the issue. https://github.com/amaranth-lang/rfcs/pull/66#issuecomment-2229028837

18:09 <_whitenotifier-9> [rfcs] whitequark commented on pull request #66: RFC #66: Simulation time - https://github.com/amaranth-lang/rfcs/pull/66#issuecomment-2229096943

18:16 <zyp[m]> sorry, I got home later than I expected

18:42 <_whitenotifier-9> [rfcs] zyp commented on pull request #66: RFC #66: Simulation time - https://github.com/amaranth-lang/rfcs/pull/66#issuecomment-2229152164

22:11 <zyp[m]> <Wanda[cis]> "like... either the original..." <- you're making a good point, but I'll nitpick and claim that there's a third option: original frequency isn't exact as a float (e.g. because you've got a PLL or other divisor doing something like 100MHz / 3) -- but of course this is moot since the trip through integer femtoseconds already doesn't guarantee exactness

22:12 <zyp[m]> so I agree that floats would have sufficient precision for the numbers involved in typical frequency calculations, and my only argument for returning fractions would be that I like being consistent

22:23 <whitequark[cis]> why do we care about exactness anyway

22:24 <whitequark[cis]> even the best oscillators are like 1 ppm at best, and that's already an OCXO

22:24 <whitequark[cis]> so any precision beyond that is excessive

22:24 <whitequark[cis]> I think the only place where caring about exactness makes any sense at all is trying to catch up from one task to another in the simulator

22:24 <zyp[m]> like I said, we don't

22:24 <whitequark[cis]> while this is generally a bad idea, the representation being an integer number of femtoseconds takes care of that

22:25 <whitequark[cis]> right, ok

22:25 <whitequark[cis]> just making sure this doesn't get lost

22:26 <zyp[m]> the only reason I see to care about frequency exactness would be when we want code to spit out nice round numbers in e.g. generated defines/metadata, and that's really just an aesthetics thing

22:27 <zyp[m]> the reason the .*second properties use fractions is because we care about resolution and it not decreasing the longer a simulation runs