<_whitenotifier-9>
[yosys] mithro opened issue #36: What would be required to add support for SystemVerilog through Surelog+UHDM in YoWASP? - https://github.com/YoWASP/yosys/issues/36
<cr1901>
B/c we already discussed the things currently marked as needs-rfc last week (unless that changed in the past 3 hours I last looked)?
<whitequark[cis]>
we haven't
<whitequark[cis]>
matrix fucking broke
<whitequark[cis]>
one RFC never got any attention at all, one RFC's discussion was cut short and also I've updated it since
<whitequark[cis]>
plus I think I specifically said that we've ran out of time to discuss things previous Monday and will do it next Monday
<cr1901>
Well, I'll likely be physically present, but Idk if I'll be attending- my bandwidth has been kinda shot lately, and it's not clear I can give this the attention it deserves.
<cr1901>
I will see how I feel.
<whitequark[cis]>
ah, and RFC 52 should have been nominated
<whitequark[cis]>
so it's three: 69, 68, 52 (in this order)
<tpw_rules>
i thought last time you had said there was a holiday and the next one would be in two weeks
<tpw_rules>
perhaps i got that mixed up with an earlier instance
<whitequark[cis]>
yeah
<cr1901>
There were 4-something weeks without meetings b/c there was nothing to do before 0.5 release (I _think_?). Why couldn't my ADHD-ass update all my Amaranth code then? lmao
<whitequark[cis]>
oh yeah, at the time I was spending basically all my time writing the excellent docs that are online now
<cr1901>
Besides "updating to 0.5", "some refactors", and "I need amaranth-soc to have a release", docs are the reason Sentinel hasn't gotten a PyPI release. I won't release until the docs are done. But I don't feel like writing docs. So, I procrastinate, and nothing gets done.
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
Wanda[cis] has quit [Quit: Bridge terminating on SIGTERM]
RobTaylor[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #amaranth-lang
_catircservices has quit [Client Quit]
_catircservices has joined #amaranth-lang
whitequark[cis] has joined #amaranth-lang
<whitequark[cis]>
test
<whitequark[cis]>
ok, I just had to update catircservices.org because of the recent openssh vuln
<Wanda[cis]>
1434: I'm for the pr, undecided on bikeshed
<cr1901>
I'm here
<tpw_rules>
i would prefer "init" instead of "payload_init" but am slightly confused about the motivating example? if oe is a constant 1 what does init change?
<whitequark[cis]>
adding init makes it not necessary to set oe explicitly
<tpw_rules>
what do you mean by set explicitly?
<whitequark[cis]>
this is basically necessary to be able to wrap an io.Buffer into a stream based interface and keep the io.Buffer contract (oe's init being 0 when Direction.Bidir, 1 when Direction.Output)
<jfng[m]>
1434: i prefer `payload_init=`; `init=` may suggest that members like `valid`,`ready`,etc are covered, which isn't the case
<whitequark[cis]>
the previous meeting was cut short by a matrix.org outage
<whitequark[cis]>
since then I have done some updates to the RFC, namely rejected the multibit oe alternative, as it makes it impossible to slice or concatenate SimulationPort objects
<whitequark[cis]>
the slicing part goes against the PortLike contract, and both parts would not work well for an API whose purpose is to be a stand-in for simulation
<whitequark[cis]>
er, rejected the single-bit oe alternative
<whitequark[cis]>
that is, in the current RFC version, oe has the same amount of bits as o and
<whitequark[cis]>
I have also added concatenation to the PortLike contract formally
<tpw_rules>
so the SimulationPort has no logic (just some Signals) and it is up to the *Buffer to detect it and use those signals in a manner appropriate to simulation
<tpw_rules>
and the particular buffer
<whitequark[cis]>
yes
<whitequark[cis]>
I don't think it would even be possible to design it otherwise?
<whitequark[cis]>
it's not like SingleEndedPort has any logic either
<jfng[m]>
`SimulationPort(width, *, invert=False, direction)` (i.e. alternative #1) is fine to me, as it requires testbenches to explictly give a direction; in this particular context, being verbose isn't a problem imo
<whitequark[cis]>
I actually really don't like the verbosity, having written some tests
<tpw_rules>
oh thank you, github search was not locating it
<tpw_rules>
i would say alternative #3 for the constructor signature. the user will be most familiar with bufffers
<whitequark[cis]>
in addition to what's in the guide, there is also a secret (or rather, not described in the guide) metadata field, which has the constraint, and other stuff like attributes, in a platform-private format (hence the lack of description)
<whitequark[cis]>
I think the direction should always be specified because it is for buffers
<tpw_rules>
the constraint being the pin?
<Wanda[cis]>
pin and things like IO standards or pulls
<tpw_rules>
yes, i think it should always be specified too, but not behind "direction="
<cr1901>
besides making separate classes, where can you shoehorn direction?
<whitequark[cis]>
what do you mean by that?
<whitequark[cis]>
the RFC lists all of the alternatives, Alternative #3 matches io.Buffer
<tpw_rules>
what happens if you specify a wrong direction? the RFC just says that it provides "valuable checks". if it's not optional, is it always an error if the port direction does not match the buffer to which it is passed?
<Wanda[cis]>
making an input port prevents you from driving the port, making an output port prevents you from looking at the port, making a bidir port has no restrictions
<jfng[m]>
which is more important? matching the argument order of `SingleEndedPort`,etc or the arguments of `Buffer()` ?
<tpw_rules>
i say the arguments of buffer as the user
<whitequark[cis]>
basically no Amaranth user is going to manually construct SingleEndedPort
<Wanda[cis]>
SingleEndedPort is generally not something most people will instantiate
<whitequark[cis]>
this is almost entirely reserved to implementations of platform.request and the like
<jfng[m]>
then alternative #3 has my preference
<whitequark[cis]>
it's my preference as well
<Chips4MakersakaS>
I follow y'all
<whitequark[cis]>
does anyone have any comments besides the bikeshed?
<cr1901>
I do, but I lost my text buffer, h/o
<cr1901>
Actually nvm
<tpw_rules>
i still think that that issue and some others betray the fact that this isn't actually a Port and i think the opportunity should be left open for it to be more than a passthrough
<whitequark[cis]>
it is a library I/O port
<tpw_rules>
arguably not from the user perspective
<whitequark[cis]>
I don't understand your comments and how they relate to the design of the library I/O ports at all
<whitequark[cis]>
what?
<whitequark[cis]>
a library I/O port is anything that implements the PortLike interface
<whitequark[cis]>
including a hardware FPGA pin, or something like GlasgowPlatformPort which actually secretly drives another thing from the oe pin
<whitequark[cis]>
the purpose of the PortLike interface is to abstract the exact nature of a driven port from the I/O core implementation so that they can be targeted to different hardware they may not actually know about or (as in this case) simulated
<tpw_rules>
i think the concept i'm thinking of could be an addon. this would be useful in simulation to make sure the device is using its own buffer properly
<whitequark[cis]>
I don't understand this comment either
<whitequark[cis]>
like, at all, what checks are you referring to, or what is an addon?
<tpw_rules>
if you wanted to simulate from an outside perspective, i think in the future you could have a SingleConnectionBus that would swap i/o and have a .port member which would return a SimulationPort you pass to the buffer
<whitequark[cis]>
what is "simulate from an outside perspective"? the simulator always gives you an outside perspective since it's external to the device
<Wanda[cis]>
I think the usecase for what you are describing is pretty niche
<tpw_rules>
which is why it never made sense to me that the simulation drives .i of a (bidir for the sake of explanation) simulation port. external to the device it should be .o
<Wanda[cis]>
so you want to connect several ports together via a bus
<whitequark[cis]>
the simulation would need to check that the .oe is driven if you want to have any hope of verifying an IO device that uses a bidirectional bus, like QSPI
<tpw_rules>
JTAG pin frobbing like wanda brought up, is that really external to the device?
<Wanda[cis]>
the only way this would be useful is when you are cosimulating several amaranth designs that live in distinct die
<whitequark[cis]>
what would that even be called if you swapped i and o? ie? that makes no sense
<Wanda[cis]>
and yes, such connection can be done externally on top of SimulationPort (though I suppose you'd really want to model 'x values in the simulator somehow so that you have any way of detecting when shit goes south)
<whitequark[cis]>
you can implement the design you want yourself since PortLike is a public interface, but so far I don't understand from your explanation how it would work at all or why it would be desired
<whitequark[cis]>
what Wanda says is covered in "Future possibilities" already
<tpw_rules>
i think i don't want the user to create a SimulationPort, i want them to create a Bus of some kind and have Port be constructed by that
<whitequark[cis]>
I also don't see Wanda talk about JTAG?
<whitequark[cis]>
am I losing it?
<Wanda[cis]>
I talked about JTAG last week
<tpw_rules>
it was brought up last meeting and was helping me understand
<Wanda[cis]>
I said that simulation port interface is conceptually equivalent to putting your design in a piece of silicon and INTESTing it
<whitequark[cis]>
oh I see
<tpw_rules>
but anyway, i think maybe my idea only makes sense to me. it is more applicable to the future Bus discussion. i think this is good as is
<whitequark[cis]>
thank you
<whitequark[cis]>
please respond with your disposition on RFC 69: merge or close
<tpw_rules>
merge
<Chips4MakersakaS>
merge
<Wanda[cis]>
merge
<jfng[m]>
merge
<cr1901>
merge
<whitequark[cis]>
disposition on RFC 69 (nice): merge
<whitequark[cis]>
I bring it up to hear what others think, but I personally have eventually concluded that I probably want to close it
<cr1901>
I agree w/ you; I don't want this
<whitequark[cis]>
this is because we can slice ports, so the proposed functionality would be a full duplication of something we can already do
<whitequark[cis]>
and all generic code would now have to take it into account
<tpw_rules>
so if you slice it, oe would just apply to the sliced subset?
<whitequark[cis]>
correct
<whitequark[cis]>
this is why SimulationPort.oe has to be multibit
<whitequark[cis]>
otherwise it is not possible to implement the contract that SingleEndedPort and DifferentialPort adhere to
<whitequark[cis]>
the reason I originally wanted fine grained oe is because of my QSPI work
<whitequark[cis]>
but QSPI is just fine with four separate io0 io1 io2 io3 ports
<whitequark[cis]>
this is not onerous even if it is slightly repetitive in two or three places
<whitequark[cis]>
so I don't feel that it is worth the complexity at all, personally
<Wanda[cis]>
idk
<Wanda[cis]>
I kinda liked the RFC
<Wanda[cis]>
maybe because we do exactly that in multiple platform impls
<tpw_rules>
can you mix it? what if you only assign oe in a slice? like suppose you have an n-bit o and oe, can you do "m.d.comb += buf.o.eq(o) ; m.d.comb += Cat(buf[n].oe for n in range(len(buf))).eq(oe)" ?
<tpw_rules>
if not, you could assign o the same way
<Wanda[cis]>
but in the end, I agree it's just complexity that doesn't actually help anything
<whitequark[cis]>
the question is: is it worth making every single other thing that's generic over IO buffer related stuff be aware of this distinction?
<whitequark[cis]>
which is probably going to be used only by a few interfaces... I can't think of anything more than QSPI that's still in wide use today, actually
<Chips4MakersakaS>
Also don
<whitequark[cis]>
tpw_rules: I don't think you can slice buffers?
<jfng[m]>
close; peripherals can already slice ports as they want and expose them differently if needed (as was suggested last meeting)
<tpw_rules>
oh, so you would have to make n buffers. that's blegh, i'm more with wanda here
<Chips4MakersakaS>
Also don't see urgent need, so no problem with closing it.
<whitequark[cis]>
so, me, JF, Staf: close. Wanda?
<Wanda[cis]>
yeah, close
<tpw_rules>
close
<cr1901>
close
<whitequark[cis]>
tpw_rules: ultimately I'm not looking for "it's blegh" but more for "there is a really compelling use case we should care about"
<whitequark[cis]>
simply "it is kind of ugly" is unfortunately not useful in this case since I put the effort of writing the RFC in first place because I thought it's kinda ugly as it is
<whitequark[cis]>
before realizing it would just be worse after
<whitequark[cis]>
I could not come up with this compelling use case so I chose to vote close on it
<tpw_rules>
thank you for clarifying
<tpw_rules>
i can't either
<whitequark[cis]>
but figured I should give others a chance to chime in
<whitequark[cis]>
we have discussed it previously but it seems to have fallen through the cracks somewhat, and there was the 0.5 release looming
<whitequark[cis]>
does anyone have any comments?
<whitequark[cis]>
in my personal view the RFC is mature enough in its current state, and I cannot find a better syntax than the Builder pattern
<Wanda[cis]>
I should note that, in the meantime, the backend part of the RFC has already been implemented in Amaranth as SwitchValue
<whitequark[cis]>
s/Builder/builder/
<Wanda[cis]>
Mux and Array are already implemented in terms of it
<jfng[m]>
happy to see it; it will be useful when metaprogramming things like decoders
<Wanda[cis]>
so the thing left to do and discuss is the syntax it should be exposed with
<whitequark[cis]>
yes, the question is essentially only over whether we expose this as a public interface and what that interface will be
<cr1901>
I like the *args alternative, but that can be impl'd in terms of builder pattern with a for loop. Looks fine to me
<whitequark[cis]>
I don't think it will be used a huge amount, but in cases where you do need it, it would be quite handy to have
<whitequark[cis]>
the 1st *args alternative has no space to add guard conditions in the future
<whitequark[cis]>
the 2nd *args alternative reserves two prelude keywords for a somewhat niche feature
<cr1901>
What do you mean?
<whitequark[cis]>
so, a guard condition would be something like with m.Case(1, if=enabled): that lets arbitrary expressions to control whether a particular Switch arm gets executed
<whitequark[cis]>
if enabled is deasserted in this example, the next arm will be activated instead
<jfng[m]>
> If default= is not used, the default value is 0 when on right-hand side, and no assignment happens when on left-hand side.
<jfng[m]>
should this be an error instead ? i don't know if there is a case where it would be intentional
<cr1901>
Oooooh
<cr1901>
The *args alternative permits using an iterable for Choices. But you can do that w/ the builder pattern too with a few extra lines, so that's fine w/ me.
<whitequark[cis]>
jfng: `Array` itself for example
<tpw_rules>
yeah there is probably a thing in functools to handle that
<whitequark[cis]>
or I've hit another case recently
<Wanda[cis]>
jfng[m]: > <@jfng:matrix.org> > If default= is not used, the default value is 0 when on right-hand side, and no assignment happens when on left-hand side.
<Wanda[cis]>
> should this be an error instead ? i don't know if there is a case where it would be intentional
<Wanda[cis]>
consider switching over an enum, where you have `case` for each possible value
<Wanda[cis]>
you don't really want to specify a default
<whitequark[cis]>
this issue would be solvable by delegating to Choice, but if the Enum doesn't cover every bit pattern, you don't really have a ... choice
<cr1901>
ba-dum tsh
<jfng[m]>
ah.. right
<whitequark[cis]>
basically, I would say omitting default= is useful for cases where you are matching over something that doesn't cover every bit pattern of a Value
<whitequark[cis]>
we don't currently have anything sanitizer like to help with catching those mistakes, but we should
<whitequark[cis]>
and lack of default= will allow to autogenerate an assert for it
<jfng[m]>
i just, don't like having an assignment that gets silently removed
<whitequark[cis]>
we have that already with Array
<jfng[m]>
yeah
<whitequark[cis]>
and with certain uses of word_select (if you assign to out-of-range bits)
<whitequark[cis]>
I'm open to discussing whether we should somehow address that but I think it should be done for every construct we have, not just Choice arbitrarily
<Wanda[cis]>
also yeah, consider using Choice to implement a register address decoder
<whitequark[cis]>
otherwise there are cases where someone has to use Array instead of Choice despite it being a worse fit
<Wanda[cis]>
for the read path, you just switch on the reg address and wire in the data; for write path, you do likewise with Choice on LHS
<jfng[m]>
yeah, and you've given valid use cases anyway
<Wanda[cis]>
you don't really care what happens for invalid reg addresses
<Wanda[cis]>
and the RFC handles that by reading 0 and discarding writes
<whitequark[cis]>
we have only 5 minutes left, if there's no fundamental objections, let's vote on it
<cr1901>
merge
<tpw_rules>
merge, using builder pattern
<whitequark[cis]>
merge
<jfng[m]>
you may want to set a flag or something in case of an invalid address, but you'd use Switch for that
<Wanda[cis]>
merge
<jfng[m]>
merge
<tpw_rules>
actually hold on one second
<Chips4MakersakaS>
merge
<whitequark[cis]>
yes, tpw_rules ?
<tpw_rules>
is the example after "Choice can also be used on the left-hand side of an assignment:" valid python syntax?
<Wanda[cis]>
no, I forgot the ()
<tpw_rules>
ok. well i still vote merge if that's all it needs
<whitequark[cis]>
disposition on RFC 52: merge
<whitequark[cis]>
thanks everyone, today was a very productive meeting!
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark c41ad6e - Deploying to main from @ amaranth-lang/rfcs@a54d3a2a3988b27a8fe0d5488d96d9e518e2683a 🚀
<_whitenotifier-9>
[amaranth] whitequark closed issue #1416: Add a way to have fine grained control over `oe` for `io.Buffer`, `io.FFBuffer`, `io.DDRBuffer` - https://github.com/amaranth-lang/amaranth/issues/1416
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark e5fabd5 - Deploying to main from @ amaranth-lang/rfcs@e159c9ad11a4d87f0ca47f3d75055882a3e9277d 🚀
<whitequark[cis]>
zyp: do you think you could dust off #66 for the next Monday?
zyp[m] has joined #amaranth-lang
<zyp[m]>
oh, yeah, sorry, I was meaning to have it ready for today
<whitequark[cis]>
no worries, we had the hour slot full anyway
roflin has quit [Quit: WeeChat 4.2.1]
roflin has joined #amaranth-lang
smkz has quit [Quit: smkz]
smkz has joined #amaranth-lang
nyanotech has quit [Remote host closed the connection]
<lonjil[m]>
Forgive me if I missed something, but I can't find any documentation for FSMs other than what is in the guide. If there is something, could someone point me to it?