jevinskie[m] has quit [Quit: Idle timeout reached: 172800s]
Maya[m] has quit [Quit: Idle timeout reached: 172800s]
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
<crzwdjk>
Once the RFC 2 implementation lands, I assume that some standard library things will be rewritten to use Signatures? For example, stuff like FIFOs but also maybe the read/write ports of Memory?
charlottia has quit [Quit: Idle timeout reached: 172800s]
urja has quit [Read error: Connection reset by peer]
<josuah>
so nice to see the features of the language debated like this before they are implemented
<josuah>
a lot easier now than receiving issues and pull requests "what about changing the language this way" after features are out and people rely on it
nak has quit [Ping timeout: 246 seconds]
nak has joined #amaranth-lang
saberhawk[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
<zyp[m]> "Catherine: by the way, what..." <- I would like to prohibit that so that future stdlib extensions can have stream payload be a signature without potential compatibility concerns
<whitequark[cis]>
<crzwdjk> "Once the RFC 2 implementation..." <- there is no rewrite necessary
jfng[m] has quit [Quit: Idle timeout reached: 172800s]
<galibert[m]>
Memory is core language, interfaces isn’t (yet?), so Memory is not allowed to depend on interfaces
<whitequark[cis]>
I'm thinking it would go the other way around
<whitequark[cis]>
memory would become lib.memory or something
<whitequark[cis]>
there are multiple reasons to do that, interfaces being just one of those
<galibert[m]>
Maybe 0.7 will put interfaces in core because it will be obvious then. Or not. It will be interesting to see the evolution
<whitequark[cis]>
the only thing the core language really needs to have is syntax to netlist transformation
<whitequark[cis]>
and the interoperability classes that lets you combine components with each other, like ShapeCastable and ValueCastable
Wanda[cis] has joined #amaranth-lang
<Wanda[cis]>
huh, that's an interesting direction
<whitequark[cis]>
Memory would do a lot better as a library class; it ended up being in the core language solely because of Yosys and it's not a very good fit
<Wanda[cis]>
kinda exposes the Verilog-formed biases
<Wanda[cis]>
where memory is something fundamental because it's syntax
<Wanda[cis]>
... or yosys-formed, yes, same thing
<galibert[m]>
Or the rtlil ones. I'm not sure things can generate Instance-ish rtlil yet
<Wanda[cis]>
they do all the time
<galibert[m]>
I mean outside core
<whitequark[cis]>
there is nothing stopping you from doing it
<Wanda[cis]>
does the I/O stuff count as outside core? does vendor support and lib.cdc count?
<whitequark[cis]>
which is kind of sketch but who cares honestly
<Wanda[cis]>
because those already do it
<whitequark[cis]>
interestingly, CDC (but not lib.cdc) should be in the core language
<Wanda[cis]>
huh.
<Wanda[cis]>
CDC or ability to annotate primitives with domain information?
<galibert[m]>
isn't the i/o stuff generating an Instance-equivalent? I'm not sure what an instance looks like at the rtlil level
<Wanda[cis]>
the thing you're looking for in RTLIL (cell) is pretty much directly equivalent to amaranth Instance
<Wanda[cis]>
if you instantiate a yosys internal cell instead of a vendor cell, it'll work, and in fact the IO stuff does that with a $tribuf cell
<Wanda[cis]>
whether that's a good thing is a different matter
<galibert[m]>
interesting
<Wanda[cis]>
the sole exception is memory stuff, because that is special-cased in RTLIL itself
<galibert[m]>
Is that a mistake-in-hindsight of rtlil or are there good reasons?
<whitequark[cis]>
Wanda[cis]: the latter
<Wanda[cis]>
(though given that RTLIL now supports a monolith $mem cell in addition to per-port cells, even that could be changed)
<Wanda[cis]>
galibert[m]: the memory stuff? load-bearing liability.
<galibert[m]>
love the expression
<Wanda[cis]>
it caused no end of problems I spent a ton of effort trying to exorcise
<galibert[m]>
Ah, it's the memory/ports split that makes things complicated?
<Wanda[cis]>
yes
<Wanda[cis]>
it was worse than that tbh, yosys had both a monolith cell to represent memory and a cell-per-port representation
<galibert[m]>
worst of both worlds
<Wanda[cis]>
still has (I couldn't remove either due to compatibility requirements), but now there's a wrapper used everywhere that allows you to work with both equivalently on the C++ level
<crzwdjk>
Thanks for all the hard work on RFC 2, whitequark[cis] and everyone else, it's looking really good.
<whitequark[cis]>
have you been using it already?
DX-MON has quit [Ping timeout: 252 seconds]
lethalbit has quit [Ping timeout: 240 seconds]
crzwdjk has quit [Ping timeout: 248 seconds]
DX-MON has joined #amaranth-lang
lethalbit has joined #amaranth-lang
crzwdjk has joined #amaranth-lang
<crzwdjk>
Yeah, I have been rewriting some of my stuff using it this week. I actually meant to rewrite some of my code anyway now that I understand HDL a bit more and figured I'd take the opportunity to upgrade to the new way of doing things.
<crzwdjk>
And I think the latest update to RFC 2 addresses all my issues
<whitequark[cis]>
\o/
<whitequark[cis]>
very happy to hear that
<whitequark[cis]>
I'm in the process of writing the reference documentation
<crzwdjk>
I definitely wasted a lot of time debugging typos wiring up the connections in my old design, so connect() is very, very helpful
<whitequark[cis]>
ooooh, this is really a curious project, and relevant to my interests
<crzwdjk>
Oh, cool. Btw, there's a bunch more old code I need to clean up and port to the new framework, so hopefully there will be more updates soon.
<crzwdjk>
Among other things, I have a (Q)SPI flash reader component and a PS/2 keyboard controller. Well and the UART I copied out of amaranth-stdio
<whitequark[cis]>
out of curiosity why not go with yowasp? the benefit is mainly so that you can put the toolchain version into a lockfile
<crzwdjk>
I might just switch to that, mostly I didn't want to figure out how it worked. Possibly also some concerns about performance on my development machine which is a pinebook pro.
<whitequark[cis]>
is that arm64?
<crzwdjk>
Yep
<crzwdjk>
But I tried out the template-fpga project today and that worked fine, so maybe I will just switch.
<whitequark[cis]>
this makes it clear that it's computed and lets you have a smaller and neater constructor
<crzwdjk>
Ah okay, I will update that at some point. Didn't know about that particular detail of Python.
<whitequark[cis]>
so this definitely goes into docs
<crzwdjk>
👍
<crzwdjk>
The docs, where present, are quite good btw.
<whitequark[cis]>
thanks! I do my best. and I write docs for all new functionality that goes in
mcc111[m] has joined #amaranth-lang
<mcc111[m]>
Hey, silly question. If comments were done as like, quotes, or a amaranth.Comment(""") operator, would it be possible to carry comments all the way into the generated verilog files?
<whitequark[cis]>
in principle it would be feasible to carry normal comments down to Verilog files
<whitequark[cis]>
this is solely a question of investment of effort into Yosys