<jfng[m]>
(it is nighttime in EU, so i probabmy won't reply before morning)
<cr1901>
jfng[m]: Before you go (this is quick)
<cr1901>
Anything planned for the soc meeting on Friday?
<tpw_rules>
is there any problem with testing that?
<tpw_rules>
maybe i'll just slap down my own and migrate later
<jfng[m]>
the integration of component metadata in amaranth-soc is on the agenda for friday, as the PR should hopefulmy be ready by then
<cr1901>
I see. I need help to try to shave some LUTs off my sentinel amaranth_soc.wishbone example (proper use of sparse, minimizing resources dedicated to decoding). After the -soc agenda seems the best time to do it if there's time.
<jfng[m]>
if you try out the CSR API, we can also review your code
<cr1901>
I doubt it will fit in HX1K, but I'll see what I can do
<jfng[m]>
cr1901: also possible
<tpw_rules>
i would want some component metadata too
<tpw_rules>
if having an actual design is helpful, i can consider that
<cr1901>
re: trying out the CSR API, I will need to find some breathing room in the design before trying out the CSR API (as I expect that you will not be using dirty tricks like I am to make things fit)
<cr1901>
Right now, I have < 10 LUTs
<tpw_rules>
(i have plenty)
<tpw_rules>
i remember a little discussion about the component metadata, there's no prototype yet for that is there? but i could just manually visit everything?
<jfng[m]>
i'm working on the PR for the full implementation, so i'd recommend waiting a couple days
<tpw_rules>
ok. i really would like to bash something together quick in the next couple days myself. but maybe that's not necessary, element ordering is deterministic right? like as long as i add them in the same order they'll be in that order in the address space/
<jfng[m]>
yes, an address is implicitly assigned to them by default, in ascending order
<jfng[m]>
unless you specify the `addr` parameter (assuming you are talking about adding csr.Elements to a multiplexer)
<tpw_rules>
yes
Degi has quit [Ping timeout: 268 seconds]
Degi_ has joined #amaranth-lang
Degi_ is now known as Degi
nelgau has quit [Read error: Connection reset by peer]
<_whitenotifier-b>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] a4ea328 - Deploying to main from @ amaranth-lang/amaranth@ef5cfa72bc4c3edbbdcc4c38b35e8e756a27bb8c 🚀
<Wanda[cis]>
I think 972 can be closed now?
<Wanda[cis]>
also, nice, 3 items left on the 0.4 milestone list
<whitequark[cis]>
Wanda: yep, and only one requiring any substantial amount of work
<Wanda[cis]>
well then
<Wanda[cis]>
I'll be happy to knock one more off the list
<whitequark[cis]>
thank you! I'll try to figure out what we should do in that case
rahulgandhi has joined #amaranth-lang
<rahulgandhi>
Can anyone please tell me what is the purpose of Ecall and Ebreak Instructions of RiscV
<rahulgandhi>
And how should we implement it in amaranth
<zyp[m]>
the second question doesn't really make sense
<galibert[m]>
System calls, look in the other documentation for the description of what they do
<galibert[m]>
riscv-privileged-20211203.pdf
<rahulgandhi>
Is there anyone who already implemented it in there project?
<rahulgandhi>
Thank you for your guidance galibert
jjsuperpower has joined #amaranth-lang
rahulgandhi has quit [Quit: Client closed]
<ravenslofty[m]>
`ecall` says that you need some code with more privilege than you to do something - syscalls or hypercalls
<ravenslofty[m]>
`ebreak` says that something went wrong and the code that called you needs to clean up.
<ravenslofty[m]>
or at least that's my understanding thereof.
<cr1901>
Well, they're gone, but, if the privileged spec is implement, the only difference between ecall/ebreak is that they set the mcause register to a different value
rahulgandhi has joined #amaranth-lang
<cr1901>
ebreak always sets mcause to the value 3, ecall sets mcause to 11 (if you only implement the required parts of the privileged spec, it can be set to other values if you implement additional parts of the spec)
rahulgandhi has quit [Ping timeout: 250 seconds]
XgF has quit [Remote host closed the connection]
XgF has joined #amaranth-lang
johnsel[m] has quit [Quit: Idle timeout reached: 172800s]
zbrown23[m] has quit [Quit: Idle timeout reached: 172800s]
Bluefoxicy has quit [Read error: Connection reset by peer]
Bluefoxicy has joined #amaranth-lang
widlarizer[m] has joined #amaranth-lang
<widlarizer[m]>
If you're writing it for simulation you can use ebreak to terminate the simulation. Otherwise, you could use it for a breakpoint, to preserve cpu state until some custom mechanism resumes cpu execution. Ecall is like an x86 syscall instruction so maybe look into that.
<tpw_rules>
TIL: amaranth doesn't detect per se that the same Elaboratable has been added as a submodule of two different Elaboratables
<tpw_rules>
you just get a lot of DriverConflict warnings
<whitequark[cis]>
yep
<whitequark[cis]>
it's ... not actually considered wrong
<tpw_rules>
why not
<whitequark[cis]>
dunno. never thought of it :D
<tpw_rules>
(in this case it substantially obscured the problem since the other add was in a submodule i didn't expect to add the given elaboratable)
<whitequark[cis]>
it's not inherently an error to add the same elaboratable to two different design trees
<tpw_rules>
can/should that be distinguished from adding it to two places in the same tree?
<tpw_rules>
is wiring.Component.signature supposed to return a new Signature each time?
<tpw_rules>
the RFC suggests that it can be mutated but clearly it can't be if it's new each time
<tpw_rules>
(at least from the perspective of people using my wiring.Component)
<tpw_rules>
(i am probably also abusing the "wiring.Component as a nice list of my Elaboratable's i/o" scenario)
<tpw_rules>
jfng[m]: do you mind if i leave some minor comments about my experience on that PR?
<jfng[m]>
tpw_rules: sure! that would be an appropriate place
<jfng[m]>
thanks for testing, btw
Chips4MakersakaS has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
<tpw_rules> "can/should that be distinguished..." <- probably
<tpw_rules>
like class MyThing(wiring.Component): port1: In(3) \n port2: In(2)
<whitequark[cis]>
tpw_rules: so I think your difficulty in using the CSR API and such stems from the fact that you're trying to use something that is very much a work in progress
<whitequark[cis]>
tpw_rules: this makes no sense. why not make your actual elaboratable a component?
<tpw_rules>
so it's obvious that port1 and port2 are things and inputs. without ever having any intention of passing it to `connect`
<tpw_rules>
(MyThing would still have an elaborate() method that does things)
<tpw_rules>
and returns a module
<whitequark[cis]>
hold on
<whitequark[cis]>
okay, I see why I got confused
<whitequark[cis]>
you are describing what is literally the intended use case for wiring.Component
<tpw_rules>
surely not "the"
<whitequark[cis]>
no, "the".
<tpw_rules>
oh, i suppose yes
<whitequark[cis]>
while it's not impossible to connect a component I don't foresee anyone actually doing that
<tpw_rules>
ok good to know, i guess just i was overthinking
<whitequark[cis]>
* while it's not impossible to connect a component (directly) I don't foresee anyone actually doing that
<tpw_rules>
then i go back to my previous concern, i'm not sure wiring.Component.signature returning a new Signature object every single time it's accessed jives with the comment about mutability in the RFC
<tpw_rules>
i'd be happy to submit a PR to fix it that just shoved the signature in a member variable
<whitequark[cis]>
it's more complex than 'just' doing that
<whitequark[cis]>
one thing I'm not sure of is exactly when to do it. in the constructor probably, but someone else suggested in the property
<tpw_rules>
(my money is in the property)
<tpw_rules>
and that's totally understandable
<whitequark[cis]>
I actually do not particularly like doing it in the property because then the results may be different depending on when the property is first accessed
<tpw_rules>
i think doing it in the constructor would not solve the illustrated use case though. if there's a better way to accomplish that then that would be good to know
<tpw_rules>
(maybe some sort of self._add_member could be provided)
<tpw_rules>
(or constructor parameter)
<tpw_rules>
**kwargs on the constructor for that would be neat
<tpw_rules>
"results may be different depending on when the property is first accessed" is this actually true? `self` is only accessed to get the type
<tpw_rules>
(idk if cls.mro() can change)
<whitequark[cis]>
<tpw_rules> "(maybe some sort of self...." <- that goes squarely out of scope of `Component`; if I have to add things like that I'd rather remove the whole class
frgo has joined #amaranth-lang
<whitequark[cis]>
anyway, your example could trivially be made to work with the existing system by overriding the signature property to extend the returned signature with foo
<whitequark[cis]>
I actually assumed that you were referring to .freeze(), which would not work as easily
<tpw_rules>
that's actually not a bad idea
<galibert[m]>
Component is for when you can sanely use a struct-like description of the interface. Otherwise use Elaboratable and you’re free to do anything you want
<tpw_rules>
i do think there's a little room for "struct with variable size members". particularly when it's only one (like, say, C and a zero-length array at the end)
<whitequark[cis]>
there's no particularly good way to shoehorn this into Python's syntax
<whitequark[cis]>
that said I don't understand why Component is being discussed in the context of structures
<tpw_rules>
but as a result i think "additional Signature members which would have been in __annotations__ if we knew them then" isn't a crime as a Component constructor argument
<whitequark[cis]>
I don't think so
<whitequark[cis]>
we don't provide this facility in data.Struct either
<whitequark[cis]>
(but in any case this would require an RFC to change)
<tpw_rules>
i see, okay
<whitequark[cis]>
the problem with using kwargs for that is that it means we can't add any other kwarg, ever, at any point
<tpw_rules>
for what it's worth, which is probably quite a lot now, the reason i wanted to do this is that i couldn't figure out another way to use `csr.Signature`. it might be possible with manually shuffling around memory maps but the mutability issue would still need to be fixed
<whitequark[cis]>
okay, so that's a classic XY problem
<tpw_rules>
for the illustrated use case, yes
<whitequark[cis]>
I do agree that something needs to be done about mutability, for the .freeze() case at least
<tpw_rules>
i'm not sure how .freeze() plays into this
<whitequark[cis]>
well, .freeze() is also a type of mutability (one that prevents further mutability)
<whitequark[cis]>
if you recreate the signature each time it defeats the point
<tpw_rules>
the possibility i raise earlier would still require mutating the signature, it just wouldn't change the members
<tpw_rules>
(rather the set of their names)
<whitequark[cis]>
I'm confused
<whitequark[cis]>
you cannot change an already existing member
<tpw_rules>
i think i got confused between interfaces and signatures there
<tpw_rules>
so right know i want to reach into self.signature and add another member. but that results in how to add it before it gets .create()d, which you think is dubious. what i could do to make my case with `csr.Interface` work instead is reach into self.signature and change a Signature which already exists before it gets .create()d
<tpw_rules>
but if the only mutation of wiring.Component.interface you're comfortable with is calling .freeze() in it then the second thing there wouldn't work either
<tpw_rules>
s/csr.Interface/csr.Signature/
<whitequark[cis]>
wiring.Component.interface?
<whitequark[cis]>
I'm extremely confused as to what's going on here at all
<tpw_rules>
my god
<tpw_rules>
wiring.Component.signature
<whitequark[cis]>
so .freeze() only exists because of other mutation (either adding members or mutating mutable properties, like the memory map)
<tpw_rules>
yes
<whitequark[cis]>
what I mean is that with the current implementation, calling .freeze() completely bypasses the purpose of .freeze()
<tpw_rules>
yes
<whitequark[cis]>
which is what I thought you were reportnig
<whitequark[cis]>
s/reportnig/reporting/
<tpw_rules>
but you said "something needs to be done about mutability, for the .freeze() case at least". which sounds to me like the ideal solution for you would fix .freeze() but none of my cases
<tpw_rules>
maybe i'm reading too much into it
<whitequark[cis]>
you are, I think
<whitequark[cis]>
I don't actually understand any of your cases so I don't say anything about them
<whitequark[cis]>
I don't really get what you're doing with CSRs that needs all this
<tpw_rules>
okay. hopefully it can become more clear at the SoC meeting
<tpw_rules>
perhaps there's a design problem there and not in amaranth itself
<galibert[m]>
Honestly I’m not sure what interfaces have to do with csr. The csr object interface is the standard wishbone target or whatever
nyanotech has quit [Remote host closed the connection]
<zyp[m]>
I had some fun with interfaces yesterday, now my amaranth-in-litex glue lets me request resources defined in the litex platform and turns them into amaranth interfaces: https://paste.jvnv.net/view/0cZha
nyanotech has joined #amaranth-lang
jjsuperpower has quit [Ping timeout: 264 seconds]
<tpw_rules>
sweet, my design is all working nice and just added another register with no trouble
<whitequark[cis]>
:D nice!!
<whitequark[cis]>
zyp: that's ... an interesting design
<whitequark[cis]>
there's nothing wrong with it, it just looks weird
<whitequark[cis]>
(and it's very repetitive, but not like that's an issue either)
<tpw_rules>
yeah i'm sorry if i was overly negative, i know it's all a work in progress
<zyp[m]>
whitequark[cis]: it's not very thought through, it's a rather quick hack :)
<zyp[m]>
I considered adding a helper that both does setattr and adding the signature member in one operation
<tpw_rules>
(idk whose fault it is but your certs/ssl is all out of whack from my uni connecton)
<whitequark[cis]>
which?
<tpw_rules>
paste.jvnv.net
<tpw_rules>
i can't see the link
<zyp[m]>
it should have a valid let's encrypt cert
<tpw_rules>
oh, yeah it's our firewall. the bare link says "The web page you were trying to visit has been blocked due to potentially malicious content."
<tpw_rules>
actually uh Field inheriting from Elaboratable means you can't have two of the same peripheral i think, but i'm not sure if the hierarchy would work for that anyway
<zyp[m]>
right, just increasing the recursion limit works for now, can't be assed to install a newer python on this computer now when I'll be replacing it in a few days
vipqualitypost[m has joined #amaranth-lang
<vipqualitypost[m>
so what's a good way to parameterize having a number of input signals to a module? right now I have a module that I pass the width and some other things to the constructor, but the inputs are fixed to four signals. Is it possible to generate a module with variable signals of variable width?
<zyp[m]>
set self.signature from the constructor before calling super().__init__()