<d1b2>
<VA3TEC-Mikek-14362> @bl0x I am at the section 17 of your amaranth version of BrunoLevy fpga riscv tutorial. But looking at your blinky.py I do not see any UART connections, Is this by design? https://github.com/bl0x/learn-fpga-amaranth I can add it in and send you the Pull Request if you wanted. Thanks! Mike K
<cr1901>
whitequark: What time is the meeting tomorrow, taking into account DST started where I am and am pretty sure it does _not_ start where you are for another 2 weeks
<whitequark>
UTC is unambiguous!
<whitequark>
the only thing less ambiguous is TAI but no one knows what that is and it's only a minute off anyway
<cr1901>
fair enough... 1pm then
<cr1901>
(EDT*)
<cr1901>
and yea I just learned about TAI. I don't need _that_ level of accuracy :)
<adamgreig[m]>
it's not really more accurate than UTC. maybe one day UTC will stop tracking leap seconds and TAI will just be a weirdo fixed UTC offset like every other timezone.
<d1b2>
<VA3TEC-Mikek-14362> Ah, ok... I see now, Got it. Yeah I was going into each directory separately. and compiling and loading on the (Deca) baord from each directory separately. Because I didn;t see the pins defined in the blink.py file. Thanks for the tip! 🙂
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 248 seconds]
Degi_ is now known as Degi
Luke has quit [Quit: o/ 3w 6d 23h 59m 15s]
Luke has joined #amaranth-lang
skipwich_ has joined #amaranth-lang
skipwich has quit [Ping timeout: 248 seconds]
kivikakk has quit [Remote host closed the connection]
kivikakk has joined #amaranth-lang
<josuah>
adamgreig[m]: morocco is my favorite, changing so often that there is an EMACS macro in the IANA .txt source file's comments
<whitequark>
a major issue with RFC 11 is that there is tension between different uses of annotations; whether they are for types or whether they are for values that can be sometimes types
<whitequark>
Staf: I would argue that if the Python developers wanted annotations to be non-semantic, they should not have made them to be available at runtime, but defined them to be strictly ignored
<whitequark>
(I guess it's useful for documentation if they are available)
<whitequark>
oh, I think it's not even true that you can remove annotations from the classes used in the standard library without affecting semantics
<Chips4MakersakaS>
I don't know the ins-and-outs; but using annotations now may hamper the annotations to be used later on for actual typing information.
<cr1901_>
What is meant by "Values that can sometimes be types"?
<whitequark>
in Python, types are a subset of values
<whitequark>
subclasses of type and also a bunch of stuff in typing.*/types.*
<whitequark>
so you could say that only those things, and only in specific syntactic forms, are valid in annotation positions (what mypy, etc require), or you can say that anything is valid in annotation positions (how cpython works)
<Chips4MakersakaS>
AFAICS in the docs for datatypes they only use types in the annotations.
<cr1901_>
Hmmm
<whitequark>
Staf: oh yeah, I meant the "one should be able to remove the type hints and the code should have the same effect" part from your comment
<whitequark>
@dataclass class C: x: int is very much not the same as @dataclass class C: pass
<Chips4MakersakaS>
Yeah, I agree now with that that part seems to not be true anymore.
<whitequark>
in https://lwn.net/Articles/866613/, you can see references to pydantic (I think fairly popular software) using annotations for non-type-related purposes
<whitequark>
it has enough traction that the core Python developers are not able to commit to annotations being used strictly for types
<whitequark>
> but using annotations now may hamper the annotations to be used later on for actual typing information.
<whitequark>
I suppose this is true. we have a few options here
<whitequark>
I think having something like data.Struct is quite valuable, since people have been trying to subclass Record for so long
<whitequark>
data.Struct does only two things: inherits from data.View (which you can do yourself) and set up some metaclass magic to extract annotations
<whitequark>
there are existing use cases where data.Struct is not really enough and the docs I'm writing are recommending manually inheriting from data.View in that case, constructing StructLayout manually in the constructor. there's an example in the RFC
<whitequark>
the example you give in "I'm thinking of changing syntac to something" part is using the class dictionary to populate IEEE754SingleLayout's fields
<whitequark>
I feel like that's... not really appropriate? if you do that, an instance of IEEE754SingleLayout() does not have a .mantissa method or property, plus it is virtually never useful to define methods on layouts, or even make layout classes if the contents is static
<whitequark>
basically, XLayout should be a singleton object (if it's a single thing, like IEEE754 single) or a function (if it's a class of things, like in a generic fixpoint number library)
<Chips4MakersakaS>
I was inspired by how python Enum are defined.
<whitequark>
yes, but with Enum, the names you define in the class namespace are actual names
<whitequark>
if you do class E(Enum): X = 1, you can do E.X
<whitequark>
anyway, if we wanted to provide something like data.Struct but without the annotation magic, what could be done is e.g....
<whitequark>
if you inherit from `data.View` and specify a `layout` field like this:
<whitequark>
so, I used int for conciseness, because there is no real difference in using 23, unsigned(23), or Shape(23, signed=False)
<whitequark>
they are all equally illegal according to mypy, for example
<whitequark>
pyright/pylance is capable of inferring that there is now a field called mantissa no matter what the annotation says, so no matter what syntax we use, we have autocomplete covered
* josuah
note to self: reading the class definition in the source helps a lot understanding the parentship in all that, essential for me to understand -> fewer noob questions from me!
<whitequark>
making `Value[23]` valid gives you autocomplete for `x.mantissa.<cursor>`, but if you already know Amaranth, that autocomplete isn't that important
<whitequark>
it does not help typecheckers, it does not enable any other interesting capability, it just enables that one tiny improvement in autocompletion
<whitequark>
so given how contentious (I mean this in a neutral way) this has been, I think we should close RFC 11
<whitequark>
but we might as well discuss the way forward with any future RFCs that touch annotations
<whitequark>
and discuss also potentially amending RFC1
<Chips4MakersakaS>
Does this mean you keep mantisse: 23 valid ?
<Chips4MakersakaS>
whitequark: OK
<Chips4MakersakaS>
For me all hope is not lost but need definitely more work; which I don't have ATM. So would agree with closing RFC 11.
<whitequark>
when we close RFC 11, mantissa: 23 will remain valid
<whitequark>
I am open to discussing that
<d1b2>
<Olivier Galibert> I suspect RFC11 needs python to clean up its act in the first place anyway
<whitequark>
I think this syntax is a nice shortcut that will result in readable code but it is not strictly essential because the escape hatch that is used when you need parametric layouts is also usable in general
<whitequark>
i.e. if you want, you can skip using mantissa: 23 syntax with 3 more lines of code or so
<whitequark>
the above is how you would write out mantissa: 23 without using annotations, today with RFC 1
<whitequark>
it is not a lot of work nor it is complicated, but it is kind of ugly and I feel unnecessarily so
<whitequark>
note that if you do this, you lose autocompletion again, unless you explicitly write something like mantissa: Value separately
<whitequark>
so just amending RFC 1 to tell everyone to use this syntax will leave people who want autocompletion in IDEs unhappy
<whitequark>
there is a compromise
<whitequark>
we could make data.Struct accept namespace items of the form mantissa: Value = 23
<whitequark>
so instead of the annotation containing the shape (whether directly or by proxy through Value[]), we could put it in the value of the field
<whitequark>
right now, mantissa = xxx means that xxx is the reset value (unless overridden)
<Chips4MakersakaS>
Worst case I think later on a data.TStruct or something may be introduced for typing afficionados that is compatible with the type checkers and autocompletion.
<whitequark>
actually, can't you already use .pyi files (yourself, in your first party code) to enrich data.Struct with type information?
<whitequark>
.pyi files give you the ability to give Amaranth one annotation, and mypy another annotation
<Chips4MakersakaS>
I try to avoid .pyi files and have til now.
<whitequark>
you can't use mypy with upstream Amaranth anyway
<Chips4MakersakaS>
Actually, I haven't done much Amaranth stuff in some time; will look closer when I go into it again.
<d1b2>
<Olivier Galibert> Since everybody seems halfway asleep, is Struct capable of replacing the Record in wishbone.Interface already, or is the second part required?
<whitequark>
wishbone.Interface would be a, well, Interface
<d1b2>
<Olivier Galibert> so, the second part 🙂
<josuah>
Is discussion open to other topics than RFCs?
<josuah>
I was about to ask if it was too early to start working on documenting Amaranth
<josuah>
or if it was worth waiting that more things stabilize first.
<josuah>
in partiular, pointing at where to find the missing documentation seemed helping with discovering Amaranth as it is built:
<josuah>
- looking at adopted RFCs (rationale, description and definition, examples... much of what some doc provides
<whitequark>
okay, this concludes the meeting. RFC 11 is closed, the discussion of RFC 7 can continue on the next one
<josuah>
in the meantime that doc come for them)
<josuah>
- source code and docstrings
<whitequark>
josuah: for the time being I'm planning to write documentation myself as collaborating on documentation with (mostly new) contributors will not be a sufficiently effective use of the limited time and review bandwidth I have
<josuah>
the overhead of collaboration is high for doc, I will do my best to reduce my own overhead
<josuah>
thank you again
<d1b2>
<Nate> Is there a preliminary implementation of Interface yet?
<josuah>
Nate: I did not find anything for: grep -R 'class Interface' amaranth-lang/amaranth
<josuah>
Nate: I see something named Interface in `amaranth-lang/amaranth-soc/amaranth_soc/wishbone/bus.py` but it extends from Record:
<d1b2>
<Nate> yep same
<josuah>
`class Interface(Record):`
<josuah>
So there might be some rewrite of amaranth-soc to be done
<d1b2>
<VA3TEC-Mikek-14362> Please Please do not chop my head off, not sure if this the appropriate time, but this repo might be of some interest for people for streaming interfaces. https://github.com/alexforencich/verilog-axis A lot of code has been written in verilog, not sure if it can be used. (Again not sure if anyone has seen it yet. ) really hope this helps.
<d1b2>
<Nate> About to start a project and would prefer to use the new Interface, but will revert to Record for now ig
<josuah>
Nate: keeping in mind how Interface will likely work would help writing code that is easy to upgrade
<josuah>
VA3TEC-Mikek-14362: always good to have something to look at when working on something I guess!
<josuah>
VA3TEC-Mikek-14362: did you plan porting any of that to Amaranth?
<whitequark>
take a look at RFC 2 drafr
<whitequark>
s/drafr/drafy/
<whitequark>
s/drafr/draft/
<d1b2>
<Olivier Galibert> I see 1/3/4/5 in the repo?
<d1b2>
<VA3TEC-Mikek-14362> @josuah_dem Yes, in my limited abilities, still learning. Amaranth. 😁
<cr1901>
I'll wait for the Interface RFC to elaborate, but I feel like there should be a way to automatically generate an interface to a view. Happy to give an example
<cr1901>
and also happy to be told "I'm doing it wrong"
<whitequark>
there shouldn't be such a thing as "interface to a view" I think
<whitequark>
an interface is a collection of signals (with directions); a view is a set of fields in a single signal
<whitequark>
you can put a view in an interface though
<whitequark>
and that's what you will usually do when working with streams (so you're sending structured data around)
<whitequark>
huh, you're actually using FlexibleLayout?
<cr1901>
I have to bring "ch_sel" out of the SPICtrl Elaboratable as a comb signal because I update view synchronously inside the SPICtrl
<cr1901>
I needed padding
<whitequark>
I'd probably just use a field called _1 or something
<whitequark>
FlexibleLayout is intended for cases where you have e.g. weird overlaps between fields
<whitequark>
but don't want to use a unin
<whitequark>
s/unin/union/
<cr1901>
Well using a struct wouldn't change the fact that I needed to bring ch_sel out of the module, and it _feels_ like I want an Interface to that View so I can combinatorially connect parts of the View to the outside world
<cr1901>
err, ignore combinatorially in the above
<cr1901>
Anyways I can't do m.d.comb += SPICtrl().cmd.ch_sel.eq(), because that's a multiple driver problem for backing_store
<cr1901>
I can't do m.d.comb += SPICtrl().cmd.ch_sel.eq(...) in a parent module
<whitequark>
anyway, I'm not sure what the question is exactly; what would I call that specific line?
<cr1901>
1. Would you call that "putting a view in an interface"?
<cr1901>
^that linked code*
<cr1901>
2. If you don't think there should be such a thing as an interface to a view, is there anything you would suggest (ignoring the padding) to make bringing out ch_sel to the outside world more ergonomic?
<cr1901>
Or is this the correct way and I just need to "deal" with having to write duplicated signals to a view every time I have to expose parts of a view to the outside world?
<whitequark>
this entire module reads a bit odd to me
<whitequark>
lemme just add a diagnostic for it, it's probably common
<cr1901>
Ack
<cr1901>
The module is: "Set the user-settable parts of the COPI part of an SPI ADC and send it out when en is asserted. Then when done is asserted, the same buffer will have the CIPO results"
<cr1901>
It's fine if you think it's odd, but I think you'll need to be a bit more specific if I am to change it :P
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 7f78f52 - Deploying to main from @ amaranth-lang/amaranth@80343d1c4ca3e989b089bf7c93bdb8fb6a1a8749 🚀
<cr1901>
Ahhh oops
<whitequark>
four warnings on your code
<whitequark>
yeah, figures that "Be mindful of this edge case!" is not enough to prevent people from introducing this bug, or otherwise we'd all be happily writing CVE-free C code..
<cr1901>
Yea, I converted from the old Signal(max = whatever) format and didn't realize/forgot/whatever that python ranges are exclusive
<cr1901>
Only been programming in Python for *checks* 11 years
<josuah>
I learn a lot of python by reading at Amaranth sources
<josuah>
never really needed much before now, not displeasant by how it is being taken advantage of
<josuah>
FSM syntax feels good!
<josuah>
not sure I have seen any other language defining switch/cases as you go
<whitequark>
it's kind of unavoidable here, I think
<cr1901>
Is "Signal(layout["foo"].shape)" the shortest way to create a signal that has the same shape as the "foo" field in layout?
<whitequark>
yep
<cr1901>
So besides the off-by-one errors (fixing them in a bit), what's odd/"wrong" with my Elaboratable?
<whitequark>
in a bit
<whitequark>
*will respond in a bit
<josuah>
I like how the core of the language is very small
<josuah>
something I notice with FSM: since the FSM state is internal, handling "soft resets" becomes this: