<whitequark[cis]1>
<rxvoid[m]> "Hi, I was experimenting a bit..." <- it's not intentional I guess; it's just how the implementation is. does using a $adff there cause problems for you?
<whitequark[cis]1>
<mcc111[m]> "From the amaranth sample project..." <- it's a *variable annotation*; not a *type annotation*
<whitequark[cis]1>
cr1901: ohh cool! yeah this usage is def supported
<whitequark[cis]1>
<whitequark[cis]1> "it's a *variable annotation..." <- to expand on this a bit, there's been some disagreement in the python community whether the annotations are only for types, or for arbitrary stuff
<whitequark[cis]1>
a lot of people seem to strongly think they are only for types
<whitequark[cis]1>
i disagree, chiefly because python types are kind of a real pain and i don't want to be dealing with them
* cr1901
nods
<cr1901>
Re: your comment, I don't have a good solution to the duplicate names problem. I suppose we can punt to the user w/ a text replacement w/ a pipe/sed expr (eww :P).
<cr1901>
This is also a problem for the fusesoc generation now that I think about it. I just didn't experience it b/c no duplicate module names at all in all src files
<whitequark[cis]1>
yep
<cr1901>
can a list of names be passed to the name= parameter which can invoke yosys rename pass (Idk if the amaranth wasm yosys has rename)?
<whitequark[cis]1>
connect_rpc has a bespoke name mangling pass
<whitequark[cis]1>
cr1901: it cannot
<whitequark[cis]1>
how would a list work anyway?
<cr1901>
dict... operating at 20% today
<cr1901>
{"old": "new",...}
<whitequark[cis]1>
sounds like annoying busywork
<whitequark[cis]1>
(for the API consumer)
<cr1901>
Well yes. I can think of one case where explicit renaming is required if you use the class name to derive the module name: I have Python EFB class. When that becomes EFB() module in Verilog source code, it conflicts with EFB primitive that diamond understands.
<cr1901>
Is reusing the connect_rpc name mangling pass what you have in mind?
<whitequark[cis]1>
what probably needs to happen is that module names need to be mangled (prepended with the toplevel name at least) in rtlil backend
<whitequark[cis]1>
cr1901: that's not very reusable, this would be new back.rtlil functionality
<cr1901>
Ahhh
<cr1901>
Also, to be clear, I'm very happy w/ the refactors I've been able to make so far
<cr1901>
The name-mangling should work well- user provides a name= parameter to verilog.convert, which allows the user to instantiate the same module (with multiple child modules) in more than one way without any name collisions
<cr1901>
e.g. fifo_8x16 vs fifo_16x16
<whitequark[cis]1>
yeah
jjsuperpower has joined #amaranth-lang
<cr1901>
whitequark[cis]1: The refactor is nearly complete, btw. I have only one other question.
<cr1901>
Can you think of any resource besides __init__(**kwargs) to distinguish "str" input and "normal" dataclass params
<cr1901>
?
<cr1901>
recourse*
<whitequark[cis]1>
can you override init in a dataclass?
<cr1901>
Yes
<cr1901>
I just find **kwargs to be a rather blunt workaround for the lack of multiple constructors in Python
<whitequark[cis]1>
seems fine to me
<whitequark[cis]1>
it's used a few times in amaranth
<cr1901>
Alright, I'll do that then. At least if other ppl run into the same issue of "I need two constructors- one for amaranth CLI, one for everything else", they'll know what to do
<cr1901>
@dataclass(init=False) and "just defining your own __init__.py" prevent an init from being created
<cr1901>
just defining an __init__()*
<cr1901>
I don't even really use any special dataclass functionality. It's just documenting intent :P
<cr1901>
Oooooh I just realized... when you do __init__(self, *, foo, bar), the "*" means "this is the rest of the non keyword args, but I'm not bothering to give a binding"
<jer_emy[m]>
is there some way to print out all of the possible resources/pins defined for a particular board? To put it another way, for the platform.request(...) function, is there some way to get a list of all of the valid ... ?
jfng[m] has joined #amaranth-lang
<jfng[m]>
.jer_emy: `list(platform.resources)` ?
<jer_emy[m]>
yep that works 🙂
<jer_emy[m]>
for some reason I thought that the platform object only generated the resources at compile time
<jer_emy[m]>
thank you
FFY00 has quit [Ping timeout: 258 seconds]
FFY00 has joined #amaranth-lang
ovf has quit [Server closed connection]
ovf has joined #amaranth-lang
cr1901_ is now known as cr1901
<cr1901>
Is today a bank holiday or otherwise no meeting?
<galibert[m]>
Otherwise, I guess
<galibert[m]>
Hope Catherine is ok
<jfng[m]>
afaik catherine is unavailable atm, due to being in a train without a laptop charger and low battery
<galibert[m]>
Ok, at least that's not bad
<rxvoid[m]>
Thanks Catherine. Actually I found this while writing a SPI interface for my project where the bit banging is done in a domain clocked on SCK, using CS as (async) reset. Some signals need to be reset-less because the transfer to the main domain can occur when CS is already deasserted. Having said that, it's non-critical hobbyist stuff and I could also require the host to keep CS asserted a bit longer. But if you believe that
<rxvoid[m]>
honoring the reset_less can make sense, I can propose a pull request with the small change I made to make it work.
zyp[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
apologies to everyone re: current meeting; I was very exhausted and forgot my charger in the hotel room, and as a result had no connectivity for 4.5 hours
<whitequark[cis]>
s/current/today's/
<galibert[m]>
That’s ok, there always will be another one