<whitequark[cis]>
OK, this is the last comment from me I think
<whitequark[cis]>
jfng: fun fact: using an unimplemented ALTERNATE mode on STM32 can result in a pin ending up as an output (in a totally unsafe way) http://efton.sk/STM32/gotcha/g131.html
<zyp[m]>
another fun one is setting USB_VBUS to alternate mode like the other USB pins
<whitequark[cis]>
does that kill some internal analog circuitry?
<zyp[m]>
no, you're supposed to set it to analog mode, otherwise you get an output or something that's attempting to fight VBUS and warming the chip
<whitequark[cis]>
oh
<zyp[m]>
it's benign enough that you can get it wrong and not realize for a long time, I've spotted it in multiple codebases
<whitequark[cis]>
> Even more tricky is a readout of multi-word values, where either a lock/release mechanism has to be employed (such as in RTC_SSR/TR/DR with BYPSHAD=0), or the user may be required to perform a read-twice-until-identical-values procedure (e.g. in reading out the LPTIM_CNT register).
<tpw_rules>
ah
<whitequark[cis]>
it's a bit of a weird case, since afaict in that case there can be torn data transferred across kernel/APB boundary
<whitequark[cis]>
but I would probably just put the CSR bridge behind the synchronizer then
<whitequark[cis]>
(and have another one dedicated to configuring clock muxing or something)
<tpw_rules>
hm, device logs report the mcu internal temp about 60C
<tpw_rules>
which i don't think is to bad
<whitequark[cis]>
(I think usually you mux the clocks in RCC which means you wouldn't need another CSR bridge if you wanted to replicate STM32)
<whitequark[cis]>
zyp: I lied, have many more questions about the exact semantics of the RFC
<anuejn>
I just read through rfc 55 and 53 and was wondering how they interact with the current Resource and Connectors DSL
<anuejn>
Will everything just stay as it is now?
<whitequark[cis]>
for now yes
<whitequark[cis]>
with the exception of changes to the return type of platform.request(dir="-"), though that one shouldn't be too important anyway
<anuejn>
Okay, I see
<whitequark[cis]>
my general plan is to decouple ResourceManager from core Amaranth stuff and then put it into amaranth_boards
<anuejn>
I was wondering if I could sneak in per-bit inversion into one of these while we are at it
<anuejn>
(which I forgot about again, sorry)
<anuejn>
whitequark[cis]: sounds like a plan
<whitequark[cis]>
there is per-bit inversion in RFC 55
<anuejn>
yes I read that, but it is not clear to me how the board definition dsl is changed
<whitequark[cis]>
it just isn't for the moment
<anuejn>
okay
<whitequark[cis]>
however my plan is to replace Pins("10 11 12 13", invert=True) with Bikeshed("!10 !11 !12 !13")
<whitequark[cis]>
and DiffPairs("10 12", "11 13") with Bikeshed("10:11 12:13") plus Bikeshed("10:11 12!13") for the partially inverted version
<anuejn>
okay
notgull has quit [Ping timeout: 256 seconds]
<anuejn>
that sounds pretty good
<anuejn>
I will just close 541 then :)
<anuejn>
sorry for the trouble
notgull has joined #amaranth-lang
<whitequark[cis]>
note that the diffpair order does not change in this instance, as usually you can't invert the value by connecting the buffer upside down
<whitequark[cis]>
note also that Bikeshed may not come very soon
<anuejn>
ah huh okay
<whitequark[cis]>
it's not on anyone's TODO list afaik
<anuejn>
shall I leave th pr open then and just implement it again atop 53 once it lands?
<whitequark[cis]>
yeah, now that I consider that interface fully deprecated-but-not-yet-replaced, I don't care all that much how clean it is
<anuejn>
okay
<anuejn>
then I will do that
<whitequark[cis]>
it's going to be replaced anyway, so who cares that invert= is slightly more awkward to use in one case
<anuejn>
thank you and sorry for leaving it hanging for so long again
<whitequark[cis]>
sorry about not getting back to it for like 3 years
<whitequark[cis]>
I actually don't know how the "new" resource manager should look like
<cr1901>
>the ports include the signature members, all IOPorts in the design, and clock/reset signals of all autocreated domains <-- why would you want non-IOPorts at the top-level?
<whitequark[cis]>
compatibility
<anuejn>
I dont know either for the new resource manager
<anuejn>
but I really like, that ddr / xdr is now specified after the platform.request() call
<whitequark[cis]>
oh yeah, that change was a long time coming
<anuejn>
this was one of my main pain points until now
<whitequark[cis]>
this will result in some extent of regression since xdr=4 or xdr=7 are no longer natively supported
<anuejn>
yeah but I actually never used them because when I needed these I always also needed some more advanced clocking
<whitequark[cis]>
ie you'd have to use XilinxPlatform.QDRBuffer or something (no idea how these should be called, probably just XilinxPlatform.SERDESBuffer
<whitequark[cis]>
yes, I don't expect this to result in basically any meaningful breakage
<anuejn>
(and delay elements)
<whitequark[cis]>
the platform bits were basically the cart ahead of the horse, the language hasn't caught up to my ambition in platforms at that moment
<whitequark[cis]>
ok, that's our current longest open PR closed :D
<anuejn>
I am still not entirely sure if making a vendor agnostic abstraction at this level is super helpful
<whitequark[cis]>
this being XDR>2?
<anuejn>
or if making a facility to write different "PHYs" for specific protocols (such as HDMI or MIPI) for different vendors would be more the way
<anuejn>
whitequark[cis]: yes
<whitequark[cis]>
I agree, the language's flaw was that there was no way to say "ok, I want the buffer's interface (or a part of it) to comply to this specification"
<whitequark[cis]>
and now with lib.wiring there is
<anuejn>
maybe it would though if we also had abstractions around IO delay blocks and plls
<anuejn>
yeah lib.wiring is quite cool :))
<whitequark[cis]>
I kiiiinda doubt you can abstract those in a workable way
<anuejn>
yeah same
<anuejn>
maybe for some stuff though
<whitequark[cis]>
lib.wiring is incredibly good, judging by how few complaints (basically zero) about it I've heard
<anuejn>
but I think that just needs somebody trying and maybe failing to do it for a few paltforms
<cr1901>
It has a learning curve, but lib.wiring was what I needed to get Amaranth libraries done
<whitequark[cis]>
what was the hardest parts of learning it?
<anuejn>
I have personally not actually ported my stuff to it
* anuejn
ducks
<whitequark[cis]>
why not?
<tpw_rules>
random semi-related q: has anyone actually proposed streams yet? it was supposed to be a banner feature for 0.5, no?
<anuejn>
that was also basically what I was waiting for to port my stuff from my own streams and record library over
<whitequark[cis]>
tpw_rules: nope! I *might* consider bumping them to 0.6, or having minimal streams in 0.5 (without stream combinators, ie single lane no packet only) and full streams in 0.6
<whitequark[cis]>
just because of the massive volume of updates already en route in 0.5 (I have not expected to get NIR done this year when I was planning), and the potential for breakage
<tpw_rules>
that's totally fair, just curious
<whitequark[cis]>
I've never mentioned this in the channel before, so it's good for others to read it
<cr1901>
whitequark[cis]: Lemme think about the specifics, but short version: "lib.wiring was a lot of new terminology to get used to as a user"
<whitequark[cis]>
anuejn: would minimal streams be useful to you?
<anuejn>
I am not quite sure
<anuejn>
I do a lot of video related stuff that currently has frame_end and line_end signals
<anuejn>
but I could of course just have my own streams downstream *badum tssss*
<whitequark[cis]>
those would just go into the payload (either with minimal or non-minimal streams)
<whitequark[cis]>
basically, stream combinators only ever affect the contents of stream.payload and how it gets formed and interpreted
<anuejn>
ah interesting
<anuejn>
I think I dont understand what you mean with stream combinators
<anuejn>
and would packets be different?
<whitequark[cis]>
ok so, theres a bunch of features people want on top of basic streams, like lanes and packets
<tpw_rules>
re learning, i've sort of been confused with the evolution of everything and porting my code through different revisions of the RFCs. i had to do that most with CSRs but a little with wiring stuff too. it's an unfortunate consequence of being eager to bang on things early but i think it makes it hard to make an accurate determination because i have a blurry picture
<whitequark[cis]>
however you could conceivably have either lanes-in-packets or packets-in-lanes
<anuejn>
in my imagination frames are kinda like packets and my frame_last is kinda like axis last
<tpw_rules>
for me the hardest thing i think was figuring out the semantics of connect() and when to flip, but that seems to be documented well now. i had to independently discover it myself though
<whitequark[cis]>
and you might want first, or last, or first+last for packets
<whitequark[cis]>
and you might want last_lane or en_lane for lanes
<tpw_rules>
so maybe it's not hard for new users
<whitequark[cis]>
tpw_rules: was it before I wrote the docs?
<tpw_rules>
yes
<whitequark[cis]>
oh yeah so a rather long ago
<whitequark[cis]>
that doc was a monumental undertaking
<tpw_rules>
well when did you write them
<whitequark[cis]>
like a year ago?
<tpw_rules>
didn't they get merged only recently?
<anuejn>
whitequark[cis]: yeah I guess basic streams would be kinda helpful then :)
* anuejn
will go to bed now
<anuejn>
nini everyone :)
<whitequark[cis]>
anuejn: night
<cr1901>
I can see the appeal of combining Component's signature with IOPorts to generate Verilog/RTLIL, but I aesthetically don't like that ports go from possibly being all in one place (The Top-level object's Signature) to unavoidably being in many places (wherever you created IOPorts in submodules)
<whitequark[cis]>
that's actually a specifically intended change
<whitequark[cis]>
not only dragging ports to the toplevel onerous, but it's also flat out impossible once we make it impossible to connect a Signal to an io_ instance port
<cr1901>
I don't like that at all. At least in Verilog you're forced to bubble down the IO ports from top to any module that needs them. I consider that easier to find which signal goes where
<whitequark[cis]>
* not only is dragging ports to the toplevel onerous, but it will also be flat out impossible once we make it impossible to connect a Signal to an io_ instance port
<tpw_rules>
yeah the docs only got merged late last year so that was when i became aware of them. all of my learning of the wiring module was done before i knew there were docs lol. i do also remember that it was nontrivial to intuit the differences between signatures and interfaces, particularly mixing with the CSR stuff
<whitequark[cis]>
you should think of the IO buffer (io.Buffer, io.FFBuffer, io.DDRBuffer, vendor Instance and so on) as basically a black box
<tpw_rules>
re i/o ports, i'm sort of thinking as toplevel ports being kind of a legacy hack. it seems cleaner and smarter to pipe them into an i/o black box
<whitequark[cis]>
there's no principal difference between, for example, an Instance of an on-chip oscillator and an Instance of a buffer connecting to pad A1, except that the latter happens to be accessible from the outside of the chip without dissolving it in acid
Degi_ has joined #amaranth-lang
<tpw_rules>
it's nice in some circumstances but presumably it won't be too difficult to enumerate the used i/o resources and get their instantiation locations; amaranth is good at keeping track of that
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
<whitequark[cis]>
the peripheral (whatever goes into amaranth_stdio eventually, for most parts) completely encapsulates all machinery that touches the pads connected to it
<cr1901>
The latter being accessible from outside the chip is _precisely_ the reason that I want to see the pins from the top-level. It means component.Signature no longer tells the whole story of "what ports will be generated"
<whitequark[cis]>
it can decide buffer type, it can decide buffer directionality, it can decide on additional synthesis attributes or even replace them entirely, it can connect weird buffers like SERDES ones which may have additional constraints on them that are related to the pin location
<tpw_rules>
i guess why does that matter? that was already the story of the resource system right? any elaboratable can request a resource and do stuff with it without involving the top level
<whitequark[cis]>
yes, when working with SERDES (GT in Xilinx parlance) or DDR primitives, you often have to know which specific package pin it is when configuring the primitive
<whitequark[cis]>
so the peripheral has to have complete control over everything that happens
<tpw_rules>
amaranth has never really had a top level, except when generating verilog
<whitequark[cis]>
in one particularly nasty case, in Xilinx, you actually need to sometimes generate a dummy toplevel port (1 to 4 bits) whose sole purpose is to satisfy a Xilinx placer constraint (this comes up with MIG)
<whitequark[cis]>
s/MIG/MIPI/
<whitequark[cis]>
(I think MIG too maybe? but it was about MIPI DSI in that case)
<whitequark[cis]>
I've seen somebody have to drag that through seven layers of hierarchy in Verilog manually
<whitequark[cis]>
and on the next change of pinout, the autogenerated core requested a differently sized register, like 2-bit instead of 1-bit, and she had to change it all again. by hand.
<whitequark[cis]>
anyway, when you are using a Platform, you never have a toplevel Component in first place
<tpw_rules>
^
<whitequark[cis]>
me & Wanda have actually been discussing deprecating everything but `IOPort` and creating a wrapper that turns any `wiring.Component` with a signature, into an elaboratable with no signature but full of unidirectional `IOBufferInstance`s
<cr1901>
That's viscerally more appealing to me- to relate Components to I/O buffers
<whitequark[cis]>
this could potentially address a bunch of weird edge csaes
<whitequark[cis]>
s/csaes/cases resulting from having three ways to specify ports/
<whitequark[cis]>
cr1901: but it doesn't serve the same purpose
<whitequark[cis]>
if you want an inout port, you have to go through IOPort. there's no other way to do it
<whitequark[cis]>
(the way we're currently doing it is basically unsound)
<cr1901>
If you're generating Verilog from a Component, I would expect the Component to not have inouts. They would be in a platform-specific top-level.
<whitequark[cis]>
what if it's a component that drives the bidirectional QSPI bus?
<cr1901>
What makes that different from route "i o oe" to the platform-specific inout at top-level?
<whitequark[cis]>
how exactly does the platform-specific top-level should know whether the SPI bus driver wants to use ISERDESE3 with IDELAY2?
<cr1901>
`defines that you bubble down? I don't know.
<whitequark[cis]>
that's horrific
<whitequark[cis]>
while considering the redesign of IO, I've thought about the use of a platform-specific toplevel (alongside a simulation toplevel) as one option, versus the option proposed in the RFC (that is to be coupled with a very similar in concept SimulatorPlatform some time later)
<whitequark[cis]>
the problem with routing out all of the IO to the platform-specific toplevel, while it has the benefit that you can test things at the digital boundary, is that it doesn't let an IO driver component fully encapsulate its functionality
<whitequark[cis]>
ideally, it would be able to autonomously look at the platform and instantiate appropriate platform-specific IO buffers (and sometimes PLLs), and also do something equally sensible for simulation (with the ability for a testbench to grab the digital representation of its IO)
<cr1901>
I don't even think IOPorts in submodule of use only without going to top-level is unconditionally bad. There are cool things you can do with them.
<cr1901>
E.g. Diamond Reveal doesn't require you to bring out the signals you want to probe to the top-level
<whitequark[cis]>
... because they are not toplevel ports and would not be IOPorts in Amaranth
<whitequark[cis]>
(they're connected to an internally generated IP that's connected to JTAG or something)
<whitequark[cis]>
basically, I looked at vendors shipping things like "transceiver that is always connected to IO pads because you set LOC" and "JTAG primitive that is connected to pads without any explicit connection to the toplevel", and realized that actually, there is literally no difference between blackbox pins and toplevel pins
<whitequark[cis]>
there are actually only two options for where a signal can go when we're talking about a netlist: it can go somewhere within the netlist, or it can go outside
<whitequark[cis]>
you can think of the toplevel as being connected to an implicit blackbox the ports of which match the ports of your top module exactly in reverse (this is how NIR represents the toplevel)
<cr1901>
Hmmm
<whitequark[cis]>
the reason we need IOPort at all is for legacy reasons in a way: while it would be possible in principle to specify the location of an IO buffer entirely using location attributes on the cell, it's not really practical because toolchains expect you to do it with constraints on the port
<whitequark[cis]>
well, ok, some people also use Verilog for simulating the analog and digital bits together
<whitequark[cis]>
Amaranth doesn't let you do anything with an inout, only connect it to a toplevel inout, and for the sole purpose of plugging that into a constraint file
<Wanda[cis]>
(Xilinx will actually let you specify most constraints via attributes on the cell/port, including IO buffer location)
<whitequark[cis]>
well yes but it's a pain on non-Vivado toolchains in many cases
<whitequark[cis]>
we just can't afford relying on that exclusively
<Wanda[cis]>
yup
<cr1901>
nextpnr-machxo2 flow's old constraints method was to put them on the cell in Verilog, and yosys would move it to the port before sending it to nextpnr
<cr1901>
Probably still works, but now that LPF is impl'd, why would you do that?
<whitequark[cis]>
16 bits? then birthday paradox ensures you'll get a collision on every 256th build on average unless you maintain state between builds (something I absolutely refuse to do in Amaranth)
<whitequark[cis]>
and that's if you have exactly one string
<tpw_rules>
i mean some sort of bitstream ID that's like the first thing out
<tpw_rules>
what do you mean by state between builds? could the build write out a format map along with the .v and log files and etc
<whitequark[cis]>
that can get out of date still
<tpw_rules>
how?
<whitequark[cis]>
think about the feature carefully: because of its nature it's clearly targeting the absolute least experienced of designers
<whitequark[cis]>
who may not really have a good understanding of which things to do and which not to do
<whitequark[cis]>
maybe they just copy the format map manually somewhere else.
<whitequark[cis]>
I see people doing things like that with Verilog every once in a while
<tpw_rules>
still, onboard formatting seems like a scary increase in the amount of logic and reduction of usable output bandwidth.
<tpw_rules>
then it becomes cargo culted to have the most mysterious debugging messages possible
<tpw_rules>
because less characters = more debugging
<whitequark[cis]>
is it? it should be doable in a hundred or two luts
<whitequark[cis]>
that's cheap even on an ice40
<tpw_rules>
bram to store all the messages and some nice formatting specifiers?
<whitequark[cis]>
and a bram, yes, which you often have spares of
<tpw_rules>
like, don't you need a divider to format %d?
<whitequark[cis]>
the divider would be a good chunk of those 100-200 luts
<whitequark[cis]>
you could probably get a lot of mileage out of converting to BCD first
<tpw_rules>
what if you accidentally try to format a 64 bit number and explode it to 500
<tpw_rules>
i think output bandwidth is the greater concern for me
<whitequark[cis]>
then don't use it?
<whitequark[cis]>
like... amaranth currently provides a combinatorial divide operation that can be invoked with just //
<tpw_rules>
don't use what
<whitequark[cis]>
the feature
<tpw_rules>
i'm saying from the perspective of a novice user
<tpw_rules>
(wrt the large signal concern)
<cr1901>
smolarith.div.MulticycleDiv unsigned only is 150 LUTs for 32-bit. A signed divider is more like 300-400 LUTs for 32-bit.
<whitequark[cis]>
i think many novice users are more concerned about their designs being broken for incomprehensible reasons than output bandwidth
<tpw_rules>
i think it would be difficult to fix without sufficient output bandwidth to see enough state
<whitequark[cis]>
like... this is basically similar to using printf() in interrupt handlers (although actually not as bad if you don't pause)
<whitequark[cis]>
you usually can fix something while seeing only last n samples, for some small n
<whitequark[cis]>
remember that unlike an ILA, it's trivially easy to just not sample at certain cycles
<tpw_rules>
heh, i've had to help novice users who have introduced problems using printf in interrupt handlers
<whitequark[cis]>
printf would actually be less bad than that if you just let the FIFO overflow
<tpw_rules>
yeah
<whitequark[cis]>
since it would have next-to-no impact on timings and fairly little impact on area
<tpw_rules>
i guess we can see how it works out. the idea of just hooking up a stateless console is nice, i admit
<tpw_rules>
(reductio ad absurdum: what if the user gets confused by scrollback. i've pulled that move on myself before...)
<whitequark[cis]>
each time it overflows it goes `>>>>>>>>>>>>>>>>>>>>>> OVERFLOW <<<<<<<<<<<<<<<<<<<<<<<<<`
<whitequark[cis]>
or restarts i suppose?
<whitequark[cis]>
also it's not absurd if it's a common actual occurrence
<tpw_rules>
restarts? i mean like if i'm scrolled back three screens in my serial terminal so what i see is not the latest version of my design
<tpw_rules>
i download a new one and the messages don't change cause they're in the future still
<whitequark[cis]>
oh
<whitequark[cis]>
i think my terminal jumps to the new input or something
<tpw_rules>
maybe if thought carefully it would not be hard to have an onboard and an offboard mode too. i think an offboard mode could be competitive in performance with a traditional ILA yet offer a lot more power and convenience
<whitequark[cis]>
ok no it doesn't
<whitequark[cis]>
well sure, the offboard mode is just ILA with a weird interface
<whitequark[cis]>
we could make it so that m.d.sync += Print(whatever) adds it to the waveform view instead of literally printing it
<tpw_rules>
literally == with this formatter?
<whitequark[cis]>
literally == as text. it's like, the exact same circuitry feeding the exact same decoder, the only difference is if it's formatted as a graph or as text
<tpw_rules>
i don't understand. you mean as a way to improve bandwidth? or is this just for simulation...?
<whitequark[cis]>
I don't understand the question
<tpw_rules>
" we could make it so that m.d.sync += Print(whatever) adds it to the waveform view instead of literally printing it" how does this relate to the proposal of printf debugging and the onboard/offboard formatting engine
<whitequark[cis]>
there are two separate proposals (generally speaking, not RFCs): ILA and FPGA-printf
<whitequark[cis]>
however if we format off-board, there is actually no difference at all in the gateware that goes onto the FPGA provided you do not use format strings
<whitequark[cis]>
and no difference at all allll the way up to where it's physically displayed in the UI, where you can do it with strings (as Print() would imply), or just ignore the name and display the same thing as a waveform
<whitequark[cis]>
(with gaps where you weren't sampling)
<whitequark[cis]>
so we could have an m.d.sync += Sample(signal) which feeds the ILA, which would be then gathered together with Print() and fed into ILA/PRN gateware
<tpw_rules>
... are there any FPGAs that let you dump the state over JTAG
<cr1901>
Diamond Reveal's ILA uses JTAG
<tpw_rules>
so does quartus's signaltap and vivado's whatever it's called
<tpw_rules>
i mean like stop the clocks and read every flop
<Wanda[cis]>
nearly all xilinx FPGAs had this
<Wanda[cis]>
I think they have gotten rid of it on ultrascale though
<Wanda[cis]>
the way it works is that for every FF there's this bit in bitstream which determines the initial value
<Wanda[cis]>
and there are two commands, GRESTORE and GCAPTURE; GRESTORE moves from this bitstream bit to FF, GCAPTURE moves from FF to bitstream bit
<Wanda[cis]>
so to look at the design state, you stop clock, poke GCAPTURE, and read out parts of bitstream with the flops you need
<whitequark[cis]>
why did they get rid of it on ultrascale i wonder
<cr1901>
(Note to self: you need to add csr.Registers as submodules in your peripheral, otherwise Amaranth won't generate code for their connections. I thought maybe the mux would do it as part of the received MemoryMap)
<cr1901>
Okay, first sign of life from the SoC at least in simulation w/ the -soc changes, bedtime for me
<tpw_rules>
we went over that yesterday, that's why the csr.Bridge exists
<tpw_rules>
did you not get an UnusedElaboratable warning
<tpw_rules>
the Bridge is a mux + automatic submodulaization of registers
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] be70d66 - Deploying to main from @ amaranth-lang/amaranth@bfe541a6d7f63b7a8402d86aa51e741c7d1c97bd 🚀
<whitequark[cis]>
PSA: after extensive feedback (still coming at this moment in fact) on RFC 36 I have decided to take it off today's agenda as it's not quite ready for a vote. we will be voting on RFCs 53, 55, 54, 56, in that order
<jfng[m]>
<whitequark[cis]> "re: the .f accessor, I guess..." <- how about just having singular `.field` and a `.f` alias ? i don't think it would be awkward for multi-field registers
melwyest has quit [Remote host closed the connection]
<tpw_rules>
jfng[m]: so you would rename .fields to .field? i can add that, i like it better than having three things
<jfng[m]>
but then it wouldn't match the `fields=` parameter in `__init__()`... so i'm not sure, maybe plural fields is less awkward ? but yeah i'd prefer to not have three different aliases to the same thing
<whitequark[cis]>
good evening everyone, it is time for our regularly scheduled Amaranth core language meeting
<whitequark[cis]>
who is attending?
<zyp[m]>
I'm here
<whitequark[cis]>
unfortunately there's clear outstanding questions on RFC 36 even as of this minute (some of which I wasn't able to as much as write down before the meeting), so we won't put it to a vote today. next time probably
<Wanda[cis]>
meow
<jfng[m]>
o/
<mcc111[m]>
hi
Chips4MakersakaS has joined #amaranth-lang
<Chips4MakersakaS>
o/
<galibert[m]>
Vaguely for now, shopping for dinner
<whitequark[cis]>
please respond with your comments or disposition: merge or close
<galibert[m]>
Is there an impact on platform files?
<tpw_rules>
do all top level ports have to be inout? does this affect those which aren't?
<whitequark[cis]>
I do want to note that unlike many RFCs, this one closes a soundness hole, so closing it rather than amending will require an overridingly good reason
<Wanda[cis]>
as in, board definitions?
<galibert[m]>
(I lean merge, it sounded good)
<galibert[m]>
Yeah
<Wanda[cis]>
tpw_rules: this is described in the RFC
<Wanda[cis]>
it depends on the directionality of the instance port they are instanced to, or the presence of o or i on the IOBufferInstance
<whitequark[cis]>
Wanda: oh, the empty `Cat` hack is no longer a drawback (since it's no longer a thing)
<Wanda[cis]>
* it depends on the directionality of the Instance port they are connected to, or the presence of o or i on the IOBufferInstance
<Wanda[cis]>
oh?
<whitequark[cis]>
did we not add IOValue.cast()?
<Wanda[cis]>
galibert: board definitions are unchanged by both this RFC and 55
<cr1901>
merge
<Wanda[cis]>
Catherine: yes, and it is essentially the centralized place for the empty `Cat()` hack
<tpw_rules>
ah, i see.
<whitequark[cis]>
ah ok
<tpw_rules>
yes, i vote merge.
<mcc111[m]>
Naive question: Does this have relevance to the case of integrating amaranth code with verilog, or is this about actually external IO?
<galibert[m]>
Ok cool. So there’s no need to adapt the generated qsf or whatever
<Chips4MakersakaS>
I don't like the distinction between top-level synthesizable design with and without platform. Ideally I would be able to make a generic design without platform and map that to a platform later. This would allow to make most code not having to care about platform.
<Wanda[cis]>
(there will likely be changes to platform stuff later that will make use of this and 55, but we don't really have a set design for that yet)
<Wanda[cis]>
Chips4MakersakaS: there's... not really a way to do this?
<Wanda[cis]>
for peripherials, it's already there
<Wanda[cis]>
they just want a *Port, you can either get one from a platform, or construct one yourself
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): I don't entirely understand the dislike you have
<Wanda[cis]>
for the user, the platform is the entity that manages the IO ports; if you don't have one, you have to do its job somehow, so of course it's going to be different
<whitequark[cis]>
as in, I don't understand your description
<Wanda[cis]>
(in effect: in code without a platform, you are the platform)
jjsuperpower_ has joined #amaranth-lang
<Chips4MakersakaS>
In which cases is that needed then ?
<Wanda[cis]>
to be clear: "code using platform" means any code using any of the platforms in amaranth.vendor.*
<zyp[m]>
I'm slightly concerned about «IOPorts are not supported in any way in simulation.», but I'm happy as long as there's a convenient way to mock IO registers
<Wanda[cis]>
it doesn't mean "tied to a particular one", just that you're not replacing a big part of the amaranth stack by custom things
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): ah, I think I understand. "top-level synthesizable design with Platform" uses one of the platforms from "amarnath.vendor". "top-level synthesizable design without platform" is an alternative to having to, currently, collect a `ports` array from every peripheral and collating them when you give them to `verilog.convert()`, one of the least Amaranth things you'd do
<Wanda[cis]>
Chips4Makers (aka Staf Verhaegen): in large part, that stuff is documented in the RFC, because it tells you how to *make* a platform yourself
<whitequark[cis]>
so for example at ChipFlow we are currently using a horrific hack to create a platform just because it's so unergonomic to work without one, but it also breaks constantly due to upstream changes; this proposal would relieve us from that hack
<whitequark[cis]>
zyp: current simulator doesn't support toplevel ports either, so this is very similar to status quo; and yes, a `SimulationPlatform` is very likely to be a follow-up
<cr1901>
Which part of the motivation, specifically, is the soundness hole? The "cursed kind of Signal" part?
<Wanda[cis]>
cr1901: yes
<Wanda[cis]>
(and the somewhat broken handling of them currently)
<whitequark[cis]>
Signal being inout is basically something I added as a quick hack in 2019 and which has been a blight ever since
<cr1901>
(One of the bullet points under that sentence describes IOBufferInstance, which is what you're adding, so I got a bit confused as to whether the cursed signal is what will be added or it's the status quo :P)
<whitequark[cis]>
it's never been well-defined and it can't really be, since Amaranth does not have z (but parts of Amaranth currently pretend we do, without any support in simulator among other things)
<Chips4MakersakaS>
So it's for Verilog module export without using a amaranth.vendor platform ?
<Wanda[cis]>
Chips4Makers (aka Staf Verhaegen): that is one use case, yes
<Wanda[cis]>
(in the case where doing a Component is not compatible with what you're doing)
<whitequark[cis]>
or for example when you want a Component that drives an inout bus (imagine an SPI flash memory controller)
<Wanda[cis]>
again: we expect the sidestepping of platform machinery to be rare; if you don't have a supported platform, it's usually eeasier to just hack one up than work without it, and it'll stay so
<zyp[m]>
I have no other concerns, so my vote is merge
<Wanda[cis]>
but we do want to allow replacing large bits of amaranth if you have a funny use case, so we're describing some of the low-level interfaces
<jfng[m]>
merge
<Chips4MakersakaS>
RFC LGTM then
<Chips4MakersakaS>
merge
<mcc111[m]>
abstain
<galibert[m]>
merge
<cr1901>
>Using IOPorts together with other ways of creating top-level ports is not recommended. <-- The subtext here is "make a platform if you need IOPorts", correct?
<whitequark[cis]>
disposition on RFC 53: merge
<Wanda[cis]>
cr1901: no, it's don't use `IOPort`s in a `Component` top-level
<galibert[m]>
Wanda: unless the Component's signature is empty I guess?
<Wanda[cis]>
I'm not sure whether this should be even allowed; hence the unresolved question in the RFC
<whitequark[cis]>
please respond with your comments or disposition: merge or close
<Wanda[cis]>
galibert: ... I guess? *shrug*
<whitequark[cis]>
this RFC is similar to the existing request functionality, but moves the responsibilty to the peripheral or amaranth_stdio core (where it belongs); it also adds a per-pin inversion flag (rather than per-named-port) that was requested on the issue tracker, and removes generic (but not platform-specific) support for gear ratios other than 0, 1, and 2
<whitequark[cis]>
platform-specific IO primitives (think amaranth.vendor.XilinxPlatform.FFBuffer or perhaps .SERDESBuffer) will be added at a later point with an interface more fit for purpose than xdr=4, xdr=7, or xdr=8 ever was for any existing platform
<whitequark[cis]>
the `request` functionality itself is not going to be affected, besides potentially removing `xdr>2` (which aren't really usable in practice anyway)
<zyp[m]>
how will this work in regard to being lowered to platform specific primitives?
<zyp[m]>
sorry, I just spotted platform.get_io_buffer
<whitequark[cis]>
I think that's described in the RFC?
<Wanda[cis]>
this is described in the RFC — platform method is called to lower them
<Wanda[cis]>
(the current Pin interface will be reimplemented in terms of *Buffer instantiated internally by platform, so net amount of per-platform code stays roughly the same)
<galibert[m]>
Ah so a lib.io.Buffer does not buffer?
<whitequark[cis]>
(procedural remark: given the volume of RFCs recently, I would much prefer it if basic questions about the RFC were asked before and not during the meeting; this is why I made sure to announce the agenda in advance--on Friday this time--and not add more things to it)
<whitequark[cis]>
galibert: it does buffer, as in it might instantiate an `altiobuf` if you want a bidirectional pin
<galibert[m]>
Ok, I'll try to annoy you before the meeting next time
<Wanda[cis]>
galibert[m]: it does buffer, it just so happens to support both kinds of ports
<whitequark[cis]>
thanks
<Wanda[cis]>
the *Port classes are a glorified data tuple, they don't do anything
<cr1901>
(Ahhh good thing I asked about 53 before the meeting. All the other RFCs today are "merge" from me, btw)
<Wanda[cis]>
the *Buffer classes look at whether you give them a SingleEndedPort or DifferentialPort and instantiate the right kind of platform buffer primitive
<galibert[m]>
I find it problematic to have to provide lib.io.Direction though when it's intrinsic to the port
<Wanda[cis]>
it's... not?
<whitequark[cis]>
it's not
<Wanda[cis]>
hmmmm
<Wanda[cis]>
there is a point here
<whitequark[cis]>
when you're driving a flash in SPI mode you will want to drive COPI (output) CIPO (input) etc. when you're driving a flash in QSPI mode the same two pins become DIO0 and DIO1 (inout)
<whitequark[cis]>
this has been a cause of unnecessary complexity in the current resource manager layer that I wanted to eliminate for a while
<Wanda[cis]>
platform may, for safety reason, want to restrict the directionality of buffers connected to a particular port
<whitequark[cis]>
namely, I want to kill Pins("1 2 3 4", dir="...") and instead just have Pins("1 2 3 4")
<galibert[m]>
Yeah, you're supposed to make shorts harder, not easier
<galibert[m]>
So you want people to, when they make mistakes, to if they're lucky detect them at runtime rather than compile time
<galibert[m]>
if they're unlucky detecting them when there's smoke
<whitequark[cis]>
generally speaking, the peripheral knows exactly what it needs to be driving the pins as, and any discrepancy between the peripheral and the platform is a problem with the platform
<galibert[m]>
blink
<jfng[m]>
is the clock polarity issue a blocker for this RFC ? (are we confident that the mentioned "platform-specific" hacks are feasible ?)
<whitequark[cis]>
I've never seen a case where dir= in the platform files prevented smoke
<whitequark[cis]>
the only thing it reliably does is making it harder to maintain platform files, especially if the pinout is slightly unconventional, and copy-paste is necessary to actually put the resource into the platform file
<Wanda[cis]>
jfng: so they are not a blocker for merging the RFC; they are a blocker for implementing it
<Wanda[cis]>
we can commit to providing mechanisms to do this somehow
<whitequark[cis]>
jfng: not a blocker for the RFC for sure (since it's an implementation concern); may be a blocker for the implementation though we think it is not
<Chips4MakersakaS>
Would switching between single SPI and QSPI be done by the Buffer, or is that the peripheral ?
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): this is entirely up to the peripheral and how it wants to talk to the flash
<galibert[m]>
well, input-only pins do not have a .oe, so you're not going to drive the pin by mistake. Your answer seems to be "you don't need to platform to ensure the semantics, just git gud"
<Wanda[cis]>
which I think we want to do, because such needs are common, and broadly applicable to cases where you want to instantiate any platform primitive
<galibert[m]>
s/to/the/
<zyp[m]>
> All of the above classes are fully introspectable, and the constructor arguments are accessible as read-only attributes.
<zyp[m]>
how does this work w.r.t. clock domains? are they resolved from strings to `ClockDomain`? if not, how do we handle renamed domains?
<whitequark[cis]>
galibert: no, that's a misrepresentation of what I want. specifically, I want to move the responsibility for deciding the buffer direction to the amaranth_stdio core
<Wanda[cis]>
zyp: the introspectability is largely meant for platform code implementing the buffer
<whitequark[cis]>
(or wherever you have the peripheral implemented, amaranth_stdio being one that should provide most common ones)
<zyp[m]>
Wanda[cis]: yes, and how does the platform code resolve the domain?
<Wanda[cis]>
it just grabs the string and does m.d[i_domain] += ...
<galibert[m]>
how... would stdio know if the user is giving it the wrong pins because they typoed?
<Wanda[cis]>
or uses a ClockSignal(i_domain)
<whitequark[cis]>
galibert: absolutely nothing will ever save you from having a typo in the platform file
<galibert[m]>
-stdio is not the platform file?
<whitequark[cis]>
(aside from robust instrumental controls)
<whitequark[cis]>
if the user typoes pins in the platform file, you're just screwed
<galibert[m]>
or you mean the platform file is going to generate full-blown components now? I'm lost here
<whitequark[cis]>
s/instrumental/administrative/
<galibert[m]>
I'm talking about a typo in toplevel here, not platform or -stdio. A typo where the connection is done
<whitequark[cis]>
ah! the toplevel no longer does the connection in this paradigm
<galibert[m]>
when you platform.request the wrong pin to pass to whatever
<whitequark[cis]>
the result of platform.request is passed directly to the stdio core
<whitequark[cis]>
the stdio core instantiates the right buffer internally
<Wanda[cis]>
is there going to be an stdio core for driving a led?
<whitequark[cis]>
why not
<galibert[m]>
Wanda: exactly what I was wondering
<whitequark[cis]>
driving a LED and sampling a button with debounce
<whitequark[cis]>
seems completely reasonable to me
<zyp[m]>
Wanda[cis]: right, because whatever it returns is placed under the caller's context, so it's resolved afterwards… no concern there then
<Wanda[cis]>
zyp[m]: yup!
<Chips4MakersakaS>
I'm also lost. How does platform now define that a pin is connected to a LED and one should not put a Buffer in Output direction on it ?
<galibert[m]>
how will the -stdio tell you if you're giving the led component the result of a request for a button input?
<Chips4MakersakaS>
*input
<Wanda[cis]>
anyway
<whitequark[cis]>
I want to also move all the *Resource methods from amaranth_boards to be (in a different form) in amaranth-stdio, and make them more strongly typed to catch the issue of requesting the wrong thing
<whitequark[cis]>
however that is out of scope for RFC 55
<zyp[m]>
okay, I'm happy with this so my vote is merge
<zyp[m]>
I'd still be interested in vendor independent abstractions for `xdr > 2`, but that doesn't need go into the scope of this RFC in any case
<galibert[m]>
Wanda: not having it is a direct loss of functionality and security
<whitequark[cis]>
we don't have it now
<cr1901>
My vote is still merge, and merge for the other two RFCs if no other complaints (i.e. don't block on me). I need to go rn.
<Wanda[cis]>
easily even; add a direction to *Port classes (perhaps with inout default), reject incompatible directionalities in *Buffer (and any other primitives that we add that decompose *Ports)
<galibert[m]>
once upon a time, when I did a platform.request on a pin with dir='o', you didn't get .oe and .i so you couldn't get it wrong. Did that break at some point?
<Wanda[cis]>
however, there's little point in doing it if platform changes will effectively obsolete it
<whitequark[cis]>
that's not actual directionality verification, just the observation that a subset of accesses, if they are done, will crash. if you do platform.request and then ignore the result you will happily get "smoke" (not on any FPGA devboard I've seen, but sure let's go with that)
<galibert[m]>
s/you/I/, s/you/I/
<whitequark[cis]>
and yes, I second what Wanda says
<whitequark[cis]>
the entire existing resource manager layer is something I'm going to deprecate and move to amaranth-boards so that it does not impede the core language evolution
<whitequark[cis]>
the requested functionality (of directionality verification) is additive on top of RFC 55, and until the resource manager functionality (platform.request) is deprecated, you have to opt into using RFC 55 by using dir="-" and instantiating buffers manually
<whitequark[cis]>
I don't think it's accurate to characterize a fully backward compatible change as "loss of safety and security"
<Chips4MakersakaS>
How will a LED or a button resource be defined in a platform after this change ?
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): same as right now
<whitequark[cis]>
this is purely an opt-in change until we actually redesign the platform layer; we are doing it this way to avoid gigantic RFCs that are bikeshedded (bikeshed?) to death
<Wanda[cis]>
(that and it's a way to refactor our internals a fair bit already)
<whitequark[cis]>
we have 5 minutes left so I'd like to have your votes on RFC 55, keeping in mind that as written this is a fully backwards-compatible change that preserves all existing functionality un-deprecated, and that any removal of functionality will require at the very least another RFC discussing platform.request
<zyp[m]>
FWIW I like smaller limited scope incremental RFCs like this
<jfng[m]>
merge
<galibert[m]>
It's opt-in but you're very clear it's going to become mandatory and you explicitely said you want to remove directionality information from the platform, so I have to vote close. I sincerely feel it's misguided.
<Chips4MakersakaS>
merge
<whitequark[cis]>
tpw_rules? mcc111?
<tpw_rules>
tpw_rules: i had said merge earlier
<tpw_rules>
(this is still 53 right, my connection dropped for a moment)
<whitequark[cis]>
sorry, it's hard to keep track with so much backlog
<whitequark[cis]>
no, 55
<tpw_rules>
i think i was merge on 55 but let me confirm
<whitequark[cis]>
we've been talking about 55 for half a hour
<tpw_rules>
let me abstain then, i apologize
<tpw_rules>
i don't think i ever used this part of amaranth seriously
<galibert[m]>
connecting to fpga pins?
<whitequark[cis]>
tpw_rules: OK, so you don't expect to have an opinion on it, correct?
<tpw_rules>
correct. i've mostly just used amaranth to generate verilog and do more toolchain flows
<tpw_rules>
toolchain-driven
<galibert[m]>
heh, makes sense
<mcc111[m]>
abstain
<galibert[m]>
Note that my vote would change to merge if there's some commitment to ensure that you can't connect the wrong way by mistake. If you go out of your way to ask for it of course, but not in a normal course of operations
<whitequark[cis]>
galibert: I intend to make that happen by actually checking that you're connecting to the right shape of resource (I mentioned this earlier)
<galibert[m]>
I must have missed it
<whitequark[cis]>
so an amaranth-stdio core (say SPIFlashController) will export an SPIFlashResource, and you'll only be able to pair the two exactly
<whitequark[cis]>
however this isn't in-scope for RFC 55, which only lays ground in the standard library, not touching platform definition files
<galibert[m]>
A lot of resources are not going to be covered by -stdio, at least for a while
<whitequark[cis]>
they aren't covered right now either, you just write whatever in your platform file and hope it's not too broken
<whitequark[cis]>
you can also write the same thing in your own libraries
<jfng[m]>
yeah, best effort is to test the platform definitions by instantiating a verilog instance of a litex core
<galibert[m]>
Sure, but you have the connectivity direction check essentially through what is returned by request, unless Port is broken. You did say you want to have direction removed from platform
<galibert[m]>
which makes me quite afraid
<whitequark[cis]>
I don't think relying on the connection happening to fail is a reliable error prevention mechanism (for one if you request a resource and don't ever use it you can have anything in it, and many cores just don't touch subsitnals), and it wasn't even intended as one when I wrote it
<whitequark[cis]>
I was just pissed that I had to do m.specials += SomeBullshitClass in Migen
<zyp[m]>
I don't think it'd be unreasonable for the platform definition to have a way to restrict what sort of buffers can be instanced on a pin
<zyp[m]>
and I don't think that's incompatible with this RFC
<whitequark[cis]>
yeah
<whitequark[cis]>
ok, we did very much run out of time
<galibert[m]>
this RFC requires giving the direction to the buffer independently of the Port contents
<Wanda[cis]>
hm.
<whitequark[cis]>
disposition on RFC 55: merge. galibert I will precisely record the nature of your concern/disagreement, and I'm choosing to merge it as I don't believe that RFC 55 is in any way incompatible with your desired safety guarantee (in fact, it is necessary to provide it, as `platform.request` cannot be amended to improve the provided safety guarantee)
<galibert[m]>
Yeah, my concern is only about that, I'm ok with the rfc in general
<Wanda[cis]>
hold on.
<Wanda[cis]>
are you opposed to adding direction to *Port like I described?
<galibert[m]>
you=me or Catherine?
<Wanda[cis]>
Catherine
<whitequark[cis]>
no, but I think it should be done together with resource manager redesign rather than as a part of this particular RFC, personally
<Wanda[cis]>
then I vote postpone
<whitequark[cis]>
we don't at all have a cohesive story for replacing Pins() and I want that to exist first
<zyp[m]>
I just thought of something; in LUNA, when you request an ULPI interface and pass it to the USB core, it's introspected to figure out whether the clock is provided from the PHY or the FPGA
<zyp[m]>
I don't think that's incompatible with this RFC, provided we've still got a way to do that introspection on whatever form the resource will have before we construct the appropriate buffer
<galibert[m]>
zyp: there is an issue that what request currently returns does not have everything it should, but that's obviously not part of this rfc's concerns
<whitequark[cis]>
Wanda: actually, postpone or defer? (postpone closes the RFC PR)
jjsuperpower_ has quit [Ping timeout: 256 seconds]
<Wanda[cis]>
my motivation is: we're not running out of RFCs to implement right now, we have it almost settled down anyway (I believe it's just a question of adding directionality to the port for double-check purposes or not), and we can wait for the next RFC in the series that will describe more platform bits
<Wanda[cis]>
defer
<Wanda[cis]>
specifically, defer to when we have more well-defined platform bits
<whitequark[cis]>
actually, now that I've heard what zyp says, I no longer think it's necessary to wait until that point
<Wanda[cis]>
also I believe that the RFC 55 has served its role today, which is being there as future context for RFC 53.
<whitequark[cis]>
having introspectable direction that affects functionality is an extremely useful thing that has considerably broader usefulness than just safety
<whitequark[cis]>
(there are a few different ways in which you can achieve the safety goal, but the clock directionality thing can only be achieved in this way)
<galibert[m]>
Catherine: very much so. And to add to that, request may return something that represents more than *one* pin
<whitequark[cis]>
that's just a bunch of separate SingleEndedPort/DifferentialPort objects in an empty class
<whitequark[cis]>
we already have that
<Wanda[cis]>
oh, I believe we may want more than that
<Wanda[cis]>
think interfaces/signatures but for pin sets
<galibert[m]>
Yeah but it could say "sram interface" and you introspect address size, data size, etc
<Wanda[cis]>
... but that's for the future RFC to decide
balrog has quit [Quit: Bye]
<zyp[m]>
IIRC LUNA already uses the platform system to attach extra information about the PHY and what initialization it requires
<whitequark[cis]>
Wanda: perhaps, but I'd be rather frustrated if I had to wait until a future, potentially months-in-the-future RFC to get to use reasonable IO buffers in Glasgow
<whitequark[cis]>
so I'm not happy with the decision to defer until an unknown later point
<Wanda[cis]>
we can literally just implement this RFC right now, as a private interface, and use it in glasgow.
<Wanda[cis]>
RFCs are about public interface.
<galibert[m]>
giving it a test run in glasgow can be an excellent idea
<whitequark[cis]>
that makes it de-facto-public though
<Wanda[cis]>
well, we actually can't quite implement it because of the clock domain introspection bits, which is another reason why I'm not leaning into merging this thing ASAP
<whitequark[cis]>
oh.
<whitequark[cis]>
so on second thought, I think it can probably be mostly implemented in Glasgow as normal synthesizable code not living in lib.io
<Wanda[cis]>
yup.
<whitequark[cis]>
yeah ok works for me
<whitequark[cis]>
RFC 53 is the bit that's absolutely necessary to use it
<Wanda[cis]>
glasgow has its own weird platform anyway
<whitequark[cis]>
the clock domain introspection bit does bother me
<Wanda[cis]>
yes
<whitequark[cis]>
it would be frustrating to fix that for memories and instantly break it for IO buffers (ok, it's already broken, sorta, in most practical use, but not conceptually at least)
<Wanda[cis]>
quite honestly: I didn't expect to get RFC 55 merged today; I mostly wrote it down to give context to RFC 53, which is the far more interesting one for now.
<galibert[m]>
incidentally, what would y'all be the reaction to proposing to move the parts of lib that are not really library but rather language definition (e.g. data, wiring, io, I'm forgetting some I'm sure) to a separate lang.* and keep lib for more traditional library-ish things like crc and fixed point?
<whitequark[cis]>
we already have "lang", it's called "hdl"
<galibert[m]>
I feel the current contents of lib confusing
<whitequark[cis]>
and it's extremely purposeful that lib.wiring isn't hdl.wiring
<Wanda[cis]>
<del>`core` and `std`</del>
<galibert[m]>
And I understand you don't want to have hdl locked into data/wiring/etc, I'm ok with that, but it's not really lib in the traditional sense either
<whitequark[cis]>
naming-wise, hdl+core+std is a lot less bad than hdl+lang+lib
<whitequark[cis]>
I think it's still going to be plenty confusing
<whitequark[cis]>
galibert: amaranth isn't a programming language in a traditional sense either
<galibert[m]>
no, but it's getting closer to something sane than verilog will ever be
<whitequark[cis]>
I think the ability to implement something like lib.wiring or lib.data yourself is extremely valuable and we want to emphasize that, not hide it
<whitequark[cis]>
"Amaranth: All Programmable, for All Programmable™"
<tpw_rules>
^
<zyp[m]>
galibert[m]: I don't really agree with your split, `lib.data` and `lib.fixed` are both types and belong in the same place
<whitequark[cis]>
oh yeah I missed that, I agree with zyp
<whitequark[cis]>
wherever you put data and enum you have to put `fixed
<whitequark[cis]>
* wherever you put data and enum you have to put `fixed`
<whitequark[cis]>
* wherever you put data and enum you have to put fixed too
<zyp[m]>
but cores like crc doesn't have to live the same place as types
<whitequark[cis]>
galibert: to answer your question more directly, I think the only way I can see myself compromising on that is if there's extensive feedback from new users of the language that the distinction is uncharacteristically confusing and impairing their ability to use and understand the language. I think I'll start asking newcomers that
<zyp[m]>
until we get lib.stream with a collection of both types and cores
<mcc111[m]>
I think it's not unusual for an stdlib of a language to contain "Mandatory" items. like, Vec<> in Rust or memcpy() in C.
<galibert[m]>
mcc111: I think std::forward and std::move are mistakes for instance
<galibert[m]>
but right now it's almost std::struct and std::decltype
<galibert[m]>
which is, kinda wow
<mcc111[m]>
I think actually my only criticism in this area is that Array should maybe go into lib.* as well, but the last time I asked about that Catherine pointed out that would create problems because Array is implemented on top of ArrayProxy (and I guess the problem there is… then you'd have to publicly document ArrayProxy?)
<mcc111[m]>
so maybe outside the scope of this discussion
<whitequark[cis]>
mcc111: note that RFC 52 allows making `ArrayProxy` implementable in `lib` (right now it cannot be implemented outside of `hdl`)
<galibert[m]>
I mean it's great w.r.t the design of the language that it's able to compartimentalize that, but it's kind of weird that there's no real separation between "the language as you should use it unless you want to do fun experiments" and "cool high-quality implementations of various things"
<whitequark[cis]>
so when/if that is merged, we could move it to lib. I don't know if it's worth the churn (seems excessive for little gain), but we could and I conceptually agree that if it was done all over maybe it should just be there
<whitequark[cis]>
galibert: I'm confused? what is "fun experiments" referring to here?
<galibert[m]>
using something else than lib.data to do structures for instance
<whitequark[cis]>
we have plenty of code in the wild relying on the ability of lib.wiring and lib.data to interopreate with code not using those
<galibert[m]>
or if someone is badly misguided reimplementing record :-)
<whitequark[cis]>
it's a core part of our backward compatibility approach
<whitequark[cis]>
if they couldn't do that, they would have probably never been implemented at all
<galibert[m]>
yeah and there's no problem with that, I'm thinking about code going forwards though
<galibert[m]>
What good amaranth code should look like
<whitequark[cis]>
I think it's completely reasonable and expected that people will implement things like lib.fixed outside of the stdlib
<galibert[m]>
And I think we all agree that having Signature everywhere for instance is a good idea
<whitequark[cis]>
I want to encourage that, not discourage it, as you're effectively proposing
<galibert[m]>
sure, and lib.crc too. It's less expected to redo data and wiring, and the future version of io
<zyp[m]>
it sounds to me like the argument is that crc is a bit out of place next to the other parts of lib
<galibert[m]>
well, crc is almost the only one to actually belong to lib :-)
<galibert[m]>
in the usual definition of lib
Abhishek_ has quit [Read error: Connection reset by peer]
<Wanda[cis]>
<whitequark[cis]> "actually, now that I've heard..." <- if you want to just add direction to `*Port` now, and redo the vote next monday, I'm likewise fine with it
Abhishek_ has joined #amaranth-lang
<whitequark[cis]>
you aren't really expected to have to redo lib.crc either
<galibert[m]>
Catherine: if you need variable granularity you kinda have to right now
<whitequark[cis]>
Wanda: I'm undecided. I'll have to think about what's best for the project in this case
<whitequark[cis]>
galibert: yes, and I consider that a defect (want to open an issue?)
<galibert[m]>
(usual case of 32-bits dma with <32 bits trailer)
<whitequark[cis]>
well, we can't actually fix it reasonably before we get streams, so not really a defect per se
<whitequark[cis]>
but something adjacent to it
<galibert[m]>
I haven't had to use it at this point, so I don't see it yet as a current issue as in "I can test the fix"
<whitequark[cis]>
"a flaw" perhaps
<galibert[m]>
yeah, or a limitation
<whitequark[cis]>
so another important bit about being able to redo data/wiring is that this way, data/wiring can be somewhat opinionated rather than being end-all and be-all for everyone
<whitequark[cis]>
I really do not want to cater to literally everyone's use case in lib.wiring, as it would have to happen if it was hdl.wiring
<whitequark[cis]>
don't like it? don't want to write an RFC? RFC closed? literally just roll your own
<zyp[m]>
«don't want to wait for it?» is another one
<galibert[m]>
I'm really, really not asking for hdl.wiring. I 100% agree with your argument. I'm pondering about something intermediate, core.wiring would be perfectly ok
<mcc111[m]>
I guess it seems like there's a spectrum and it's not totally obvious to me why crc would be in lib and fixed would be in core. So although a core/std split sounds conceptually reasonable as a low-end user I think it would increase rather than decrease the amount of effort spent on remembering what to include or not include.
<mcc111[m]>
Like, whereever you draw the line you could probably eventually argue for tuning it either up or down.
<whitequark[cis]>
^ that is why I don't want a core/std split despite not objecting to the naming per se
<whitequark[cis]>
I think it'll just become an endless source of bikeshedding
<zyp[m]>
I agree, I'm happy not having to draw a line
<whitequark[cis]>
we'll eventually end up with the problem that something in core needs something from std and we have this same problem all over again
<whitequark[cis]>
goddess knows Rust is suffering from that
<whitequark[cis]>
they've been, excruciatingly slowly, dragging some data types from std into core (like Ipv4Addr) so now there's both core::net and std::net and they have different contents
<whitequark[cis]>
remember, in Rust, "core" means "no alloc, no global state whatsoever". that's a bright technical line, and even then it causes issues
<whitequark[cis]>
in Amaranth there is no technical line, only an aesthetical one
<whitequark[cis]>
the amount of issues I'm willing to cause in the name of aesthetics is far from zero but I think this will be self-sabotage
<whitequark[cis]>
from other replies, it doesn't sound like we'll ever have anything even close to a consensus on what goes where
<whitequark[cis]>
e.g. where do streams go?
<galibert[m]>
core
<zyp[m]>
infrastructure part of it would be core, various stream components could maybe go elsewhere
<whitequark[cis]>
where do FIFOs go?
<galibert[m]>
lib
<galibert[m]>
cdc is the one I'm really not sure about honestly
<whitequark[cis]>
I think FIFOs are more core than streams
<whitequark[cis]>
you can implement streams trivially in your own code using just lib.wiring but FIFOs allow (and in some cases probably require) platform lowering
frgo has joined #amaranth-lang
notgull has joined #amaranth-lang
<galibert[m]>
that's kind of independant though, a floating-point alu would love lowering in the platform for multipliers and whatever else is available, doesn't make it core
<whitequark[cis]>
(like if you have hard FIFOs in your device)
<whitequark[cis]>
multipliers are a language construct
<whitequark[cis]>
but also, note that every single thing that has a platform lowering alters the type of a platform base class
<whitequark[cis]>
so it has to be core
<galibert[m]>
Altering the type of the platform base class for any lowering is not sustainable
<whitequark[cis]>
I'm actually going to stop discussing this right here because my point wasn't to draw a bright line but rather to demonstrate the lack of consensus
<whitequark[cis]>
I think agreeing on core/std split is such a lost cause it's never going to happen so any further effort spent discussing exactly where what goes is pointless
<whitequark[cis]>
I have strong opinions, you have strong opinions, zyp has a ... strong lack of opinion I guess?, etc
<whitequark[cis]>
also the only one who feels that it's confusing enough to bring it up was you, IIRC
<whitequark[cis]>
as for lowerings, I think if we have any hope for out-of-tree platforms (which I think we probably have to, given how there are dozens if not hundreds of small chinese FPGA vendors) we should be able to at least provide a list of possible lowerings
<whitequark[cis]>
this requires a delineation of responsibility where on one side it's platform.get_x and on the other it's isinstance(platform, Y)
<whitequark[cis]>
right now the former is reserved for things where you can say "ok, everything on every platform we will ever support will adhere to this signature, potentially with some optional flags" and the latter is for everything else
<Wanda[cis]>
<galibert[m]> "Altering the type of the..." <- I mean... default implementations of `get_*` methods are a thing, aren't they?
<Wanda[cis]>
(that or the lib primitive checking with hasattr like we currently do for lib.memory)
<Wanda[cis]>
if your platform doesn't have a hard FIFO primitive, you just don't write a get_fifo, and lib.fifo knows to provide the generic one
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] whitequark af4e808 - Deploying to main from @ amaranth-lang/rfcs@2c7ad0a6d74023d2f1bcaeac514c8aeb289fa3f4 🚀
<cr1901>
tpw_rules: Re: the bridge, yes, indeed. Bridge is a thin layer over mux, and sometime after I woke up I replaced all muxes with bridges. So "minimal number of changes to make it compile" is out the window now by executive decision.
<cr1901>
There were a few other errors with my code snippet, but I'm correcting them now
<tpw_rules>
you ditched Element for now?
<cr1901>
yes, afaict, element isn't user facing that much anymore. You can still interact with them, but as you noted, you probably you need a special reason to create them directly.
<tpw_rules>
okay. hopefully my soon to be written RFC will address that concern
<Wanda[cis]>
random thought re RFC 55: should ~port return same port with flipped invert? is this useful functionality?
<whitequark[cis]>
how else can you easily request inversion in the peripheral?
<Wanda[cis]>
okay then I'm going to add itr
<Wanda[cis]>
s/itr/it/
<zyp[m]>
what happens if you pass ~port to an Instance then?
<Wanda[cis]>
zyp: you can't, `Instance` takes `IOPort`s, I'm talking about `lib.io.*Port`s
<Wanda[cis]>
which are higher-level constructs
<Wanda[cis]>
(in fact, being used to store inversion is their main reason for existence)
<zyp[m]>
ah, right
<Wanda[cis]>
(as we don't want inversion on raw IOPort exactly because there would be no way to pass them to Instance)
<whitequark[cis]>
at one point I thought about horrific hacks that would magically move inverters across a buffer or something
<cr1901>
Is port inversion "a not gate driven by an input/driving an output"?
<Wanda[cis]>
port inversion is stuffing a not gate on the buffer's i and o ports
<Wanda[cis]>
so that the actual line level is opposite to HDL
<Wanda[cis]>
(or, for differential pairs, the P/N meaning is effectively swapped)
<cr1901>
ahhh okay, that would explain why "magically moving inverters across a buffer" isn't really viable
<cr1901>
the HDL shouldn't know about the inversion
<Wanda[cis]>
it is also expected that if you do a custom buffer type, eg. a SERDES, you will provide whatever inversions are necessary to make it work
<cr1901>
I vaguely recall this came up for machxo2 tristates being active low (and yosys not having a nice way to express that until you added the functionality)
<Wanda[cis]>
that's completely unrelated
<Wanda[cis]>
this is just platform-specific detail that gets taken care of completely internally to buffer implementation
<Wanda[cis]>
the invert attribute on ports is about inverting the data between actual electric state on the pad and user gateware
<cr1901>
(why is it unrelated? Both are platform specific details where you abstract away the actual logic value?)
<cr1901>
ahhh
<Wanda[cis]>
you can want it for three reasons: 1) board designer swapped P/N of diff pair for easier routing and you need to undo it, 2) board designed used some weirdass inverting level-shifter that you want to make transparent, 3) you want to normalize your signals to active-high in gateware (eg. active-low CS_B in SPI on the board becomes active-high CS in gateware)
<Wanda[cis]>
(and these reasons can overlap, meaning you get several inversions that cancel each other out)
<Wanda[cis]>
1) and 2) is the domain of board code; 3) is the domain of peripherial code
<Wanda[cis]>
.... I hate you too, matrix
<Wanda[cis]>
* 1\) and
<whitequark[cis]>
4) sometimes the signal is active-high and sometimes it's active-low (ever seen active-low UARTs?)
<whitequark[cis]>
* 4\) sometimes
<whitequark[cis]>
as in, instead of the board designer doing some weirdass thing it's an ASIC designer doing the same
<cr1901>
Never seen one, but my LA software has an option to invert UART decoder, so guessing it's not uncommon
<whitequark[cis]>
this is less prevalent now but it used to be quite commonplace for the designer to just say "fuck it, I'll draw an overbar here" and then you just suffer it
<zyp[m]>
sometimes resets are active low, sometimes resets are active high, I want to specify in the platform definition so peripheral code only need to deal with the normalized signal
<cr1901>
icebreaker has an active low and active hi push button
<whitequark[cis]>
here you go
<whitequark[cis]>
LEDs can be very reasonably either
<cr1901>
Yea, a 7sd driver will only need to be done once for common cathode; add inverter to do it for common anode (or vice-versa)
<whitequark[cis]>
PSA: the agenda for the next meeting will be: RFC 36 (if outstanding questions are resolved), RFC 55 (if it is updated to address concerns), RFC 54, RFC 56
<Wanda[cis]>
I have a proposal, while we're at the topic of IO buffers
<Wanda[cis]>
kill flatten, which is currently only used for Quartus IO buffers AFAIU (and doesn't work anyway?), replace it with Instance(force_toplevel=True) which ... well, forces the Instance to appear in the top level of the output, instead of wherever it actually is in hierarchy
<Wanda[cis]>
implementing it is essentially trivial with NIR
<whitequark[cis]>
that's profoundly cursed
<Wanda[cis]>
(it's a gross hack, but well, Quartus does require gross hacks)
<tpw_rules>
what about io buffers does quartus require them to be at the top level for?
<tpw_rules>
my design seems to work okay...
<whitequark[cis]>
I think I'm (for now) only okay with adding that as a private API used by the built-in IntelPlatform
<Wanda[cis]>
this also ensures that our FFBuffers will work wherever they are instantiated
<whitequark[cis]>
tpw_rules: try to go through the git logs
<whitequark[cis]>
I think I implemented that in 202
<whitequark[cis]>
I know why. I think it was probably because if you make a toplevel port and drive it from multiple subfragments each with one buffer, you get assertion errors and/or hierarchy flattening warnings.
<whitequark[cis]>
it maybe also helped something with Quartus 13?
<whitequark[cis]>
but the former reason should be the primary one
<Wanda[cis]>
as I said, doing the force_toplevel hack will be essentially trivial if it turns out to be needed
<whitequark[cis]>
zyp: I'm not trying to *prevent* somebody from branching on it, which is always going to be reachable (just look at some of the PRs in coreblocks)
<whitequark[cis]>
but rather, while it's definitely the most immediately reachable tool for solving some kind of problem, that doesn't mean it's a good tool for it
<whitequark[cis]>
just like, for example, yield Settle() is immediately reachable but not a good tool
<Wanda[cis]>
<del>if `Settle` doesn't work, clearly you're not using enough of it</del>
<whitequark[cis]>
however if it's just there, completely in the open and documented, I'll probably never hear from somebody who keeps making suboptimal in the long run decisions because it's just convenient enough
<whitequark[cis]>
like, if you're using ungetc() you probably want a lexer, but how many generations of programmers were there who thought ungetc() is a reasonable thing to just have?
<whitequark[cis]>
Wanda[cis]: this is why we automated it!
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 7700ab1 - Deploying to main from @ amaranth-lang/amaranth@cb96b15b8cbdee56651f783977c478786ec331f4 🚀
<cr1901>
How far into the future will the resource/platform overhaul be such that you decide to stop accepting new platforms until the overhaul is done?
<whitequark[cis]>
I don't anticipate stopping accepting new platforms at any point
<cr1901>
ahhh, cool
<Wanda[cis]>
buffer directionalities have been added to RFC 55
<Wanda[cis]>
and so has __invert__
<whitequark[cis]>
thanks
<whitequark[cis]>
looks good to me
<Wanda[cis]>
s/buffer/port/
<cr1901>
If I want to pass an Interface object to a function that expects a Component, how cursed is this?
<cr1901>
Honestly, I'm improvising for the non-CSR version of attosoc for sentinel, passing into the functions whatever data is required to make Amaranth generate, even if it's fake (since the CSR version won't fit into HX1K and I'm not giving up that novelty)
<cr1901>
This version of amaranth-soc does not restrict what is passed to add_resource; the generated Verilog works just fine, so presumably, amaranth-soc isn't touching e.g. self.leds, or (g.o for g in self.gpio), whatever
<cr1901>
I passed in fake data b/c I didn't know _what_ to pass in. But in the current version of amaranth-soc, the first param is restricted to Components. I, uhhh, I don't have any components to pass in :P.
<cr1901>
So I guess I'm making fake ones
<whitequark[cis]>
WBSerial isn't a component?
<cr1901>
I can't pass WBSerial into add_resource each time for each reg
<whitequark[cis]>
the reason it's a component is that the BSP generator will use component metadata (still not merged) to learn what to generate