Sarayan has quit [Remote host closed the connection]
ydnatag has quit [*.net *.split]
playback2396[m] has quit [*.net *.split]
NullYang[m] has quit [*.net *.split]
FireFly has quit [*.net *.split]
_alice has quit [*.net *.split]
_alice has joined #amaranth-lang
FireFly has joined #amaranth-lang
FireFly has quit [Signing in (FireFly)]
FireFly has joined #amaranth-lang
ydnatag has joined #amaranth-lang
NullYang[m] has joined #amaranth-lang
FireFly has quit [Quit: Leaving]
FireFly has joined #amaranth-lang
playback2396[m] has joined #amaranth-lang
Bluefoxicy_ has joined #amaranth-lang
Wolfvak_ has joined #amaranth-lang
sensille_ has joined #amaranth-lang
mwk_ has joined #amaranth-lang
leptonix_ has joined #amaranth-lang
kbeckman1 has joined #amaranth-lang
TD--Linux has joined #amaranth-lang
Ekho- has joined #amaranth-lang
leptonix has quit [*.net *.split]
mwk has quit [*.net *.split]
Bluefoxicy has quit [*.net *.split]
lambda has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
sensille has quit [*.net *.split]
Wolfvak has quit [*.net *.split]
Ekho has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
Bluefoxicy_ is now known as Bluefoxicy
lambda has joined #amaranth-lang
chaoticryptidz_ has joined #amaranth-lang
chaoticryptidz has quit [Ping timeout: 265 seconds]
sensille_ is now known as sensille
<d1b2>
<Olivier Galibert> I don't understand the why of resources in platforms? Specifically, why aren't just Signals as members of the platform object?
<d1b2>
<Olivier Galibert> what is the resource layer adding?
<d1b2>
<zyp> if I understand your question correctly, it adds stuff like IO register abstraction
<whitequark>
it's several things. one of them is having a way to say "these pins are for I2C" and have the standardized names and directions be used
<whitequark>
another is that it's not really enough to have Signals as members of the platform object, they're grouped into objects you can pass around
<whitequark>
tbh, the resource layer isn't that great, I designed it in a pinch and it's due to a rework
<whitequark>
but those are the main reasons
<d1b2>
<zyp> while a plain unidirectional pin only needs a single signal, a bidirectional pin needs a signal for each direction plus an output enable, a registered pin needs a clock signal, and if it's a ddr pin it'll be wider than just one bit
<whitequark>
that as well
<whitequark>
though as of right now, that facility isn't that widely used, and the interface is kind of poorly designed
<whitequark>
(my fault)
<d1b2>
<Olivier Galibert> Hmmm, what about records-tng then? I agree that bare signal may not be enough
<whitequark>
records-tng?
<d1b2>
<Olivier Galibert> whatever it is you're building to replace the "structure signals together" part of records
<whitequark>
ah. yeah, that'll be used in the resource layer eventually
<d1b2>
<Olivier Galibert> I have no better name than records-tng for that at this point 🙂
<whitequark>
lib.data is the part that's already implemented
<whitequark>
"data structures" is the proper name
<whitequark>
"interfaces" (to be shipped as `lib.intf`) is the part that's not yet implemented
<d1b2>
<Olivier Galibert> is lib.data enough for wishbone for instance, or is lib.intf needed too?
<whitequark>
lib.intf is needed for wishbone
<whitequark>
lib.data is basically the equivalent of C array/struct/union (not pointer, just array)
<whitequark>
but lib.intf is something closer to a full header
<whitequark>
if I can make an odd analogy
<d1b2>
<Olivier Galibert> intf is what enabled "connect" if I understand correctly?
<whitequark>
it is heavily based on the Rust RFC process but differs in important ways, so please make sure to read it in full
<whitequark>
the goal behind the RFC process in case of Amaranth is to make sure all parties are heard and as many potential issues as possible are hashed out before a feature is implemented or merged
<whitequark>
unlike with Rust (which is, and was at the time the RFC process was defined), I don't think it's appropriate at the current moment to decide policy by RFC
<whitequark>
* and was a much larger project at the
<whitequark>
so RFCs are only used as a structured way to discuss technical issues, with the final decision made by, at this time, me
<whitequark>
hopefully Amaranth will gain more core contributors soon and I won't have to do everything myself, but right now that's the situation.
<whitequark>
after the meeting I'll put that into a PR and merge it, since we have (near unanimous, I think) consensus on it
<cr1901>
Yea, I test drove it back in May- no complaints, I'll have more to say when the interface library RFC is started
<whitequark>
I expect most (eventually all) substantial modifications to the language going forward to be done through the same process; this of course includes myself
<whitequark>
what are your thoughts, folks?
<jfng[m]>
can we use this process for -soc/-stdio proposals already, even if the README mentions they aren't covered yet ?
<whitequark>
jfng: absolutely
<whitequark>
if you want to do an RFC, go ahead
<whitequark>
it's a process that's very useful for hashing out issues, which is actually the primary reason I introduce it
<jfng[m]>
i'd be interesting in migrating the past work on soc peripherals to this format, and summarize previous discussions
<jfng[m]>
s/interesting/interested/
<whitequark>
we can definitely do that
<whitequark>
"retconned" RFCs are a thing in Rust, it's fine
<Chips4MakersakaS>
I agree that language changes are important and need to be discussed with enough depth. From the other side I do see an involved process as a possible road block for non-core contributors: "If I propose this I will likely need to write a RFC for this and I don't have the time for that.".
<cr1901>
That's by design?
<whitequark>
to be direct: that's intentional; I do not want "drive-by language changes"
<d1b2>
<Olivier Galibert> I'm creating a pll through instance that gives out a signal. How can I turn the output into a clock domain?
<d1b2>
<Olivier Galibert> I'm failing at finding examples or documentation
<whitequark>
Olivier Galibert: you create a clock domain, and do Instance(..., o_PLL_OUTPUT=my_domain.clk)
<d1b2>
<Olivier Galibert> (oh sorry, missed that there was a meeting running)
<d1b2>
<Olivier Galibert> thanks
<d1b2>
<Olivier Galibert> thanks
<whitequark>
a major issue with a lot of current feature proposals is that they don't consider interactions with the entire rest of the language
<whitequark>
people pick some one thing they find easy to implement and propose it as a feature because it is easy to implement
<whitequark>
this way you end up with a language that lacks a coherent design
<whitequark>
plus, once we introduce something, it's hard to remove it; people don't like it when you break their HDL
<Chips4MakersakaS>
I understand and I don't want these things to be accepted. From the other side knowing what people want to achieve they currently can't is good to know for the core contributors.
<whitequark>
regarding the process being involved: right now the process is functionally just as involved, but there is no actual description of it anywhere. I ask people to write about their feature in more detail (that's what writing an RFC is) and they don't know what to do, don't know how to proceed once they do it, don't know what the acceptance criteria
<whitequark>
so I see a clear description of the process as an improvement on the current situation
<whitequark>
regarding knowing what people want to achieve: issues requesting features are welcome!
<whitequark>
that's actually one of the next things on my list, adding a documentation page on contributing stuff, and that would primarily cover non-code
<whitequark>
if we want people to submit high quality bug reports or feature requests we need to lay out the criteria
<whitequark>
ultimately I'd like to end in a state where someone completely new but who has read the documentation can submit bug reports, feature requests, documentation, or code that is immediately acceptable to the project. this is an unachievable ideal, of course
<whitequark>
but I'd like to not have to explain things over and over in comments
<Chips4MakersakaS>
Agree that documentation on how to contribute makes it clear to people feedback is welcome.
<whitequark>
also, I very much want to see feature requests and frustration reports over drive-by feature PRs
<whitequark>
the latter are essentially never useful
<whitequark>
does anyone else have comments?
<whitequark>
then I think we're done
<whitequark>
there is one more issue to discuss today
<d1b2>
<Olivier Galibert> fyi, I recently did (and it works beautifully) a:
<d1b2>
<Olivier Galibert> data = open("boot/boot.bin", "rb").read() init = [int.from_bytes(data[p:p+4], byteorder='little') for p in range(0, len(data), 4)] self.ram = Memory(depth = self.ram_size//4, width = 32, name = "bootram", init = init)
Guest40 has quit [Quit: Client closed]
<jfng[m]>
transparent casting could be useful, though i haven't yet felt bothered by using boilerplate for that
<whitequark>
yeah I don't think anyone is actually bothered by it
<jfng[m]>
(i also use something like olivier's example, to initialize memories)
<whitequark>
the RFC author is I think no longer active in the Amaranth community, so it'd be up to someone else to pick this RFC up
Sarayan has joined #amaranth-lang
<d1b2>
<nelgau> Is there any middle-ground between transparent casting and leaving the boilerplate as-is?
<whitequark>
not at the moment
<d1b2>
<nelgau> Then, I'm inclined to agree with jfng. While I've encountered the need for a similar pattern, I've never been bothered by it enough to want to introduce a potentially difficult to reverse addition to the language.
<whitequark>
alright, seems like we have a rough consensus
<cr1901>
If I need that, I could create a function to do it for me (as above)
<whitequark>
and we actually finished a meeting on time once! 🎉
<nelgau>
What other things are similar in goals and design to "lib.intf" -- and exist right now -- that I could study to develop an informed opinion of its future RFC?
<d1b2>
<Olivier Galibert> I'm still learning my way around amaranth 🙂
<d1b2>
<Olivier Galibert> see add_output()
<whitequark>
yeah but... in what way
<whitequark>
ohhh yeah
<whitequark>
to be honest, what you're doing is what ClockSignal() should have been
<whitequark>
it's some more unfortunate Migen legacy
<d1b2>
<Olivier Galibert> oh, it's not that?
<d1b2>
<Olivier Galibert> I understood it as "it's a signal that happens to be a clock"
<whitequark>
almost every HDL makes a distinction between clocks and other signals
<d1b2>
<Olivier Galibert> verilog doesn't feel like it makes one
<d1b2>
<Olivier Galibert> vhdl I just don't remember though, that was 20 years ago 🙂
<d1b2>
<Olivier Galibert> or you mean sane HDLs?
<whitequark>
no, it's a late bound reference to a clock signal
<whitequark>
ClockSignal("sync") is "whatever clock signal will be used when you say m.d.sync"
<whitequark>
Verilog does not, but it's in a minority
<whitequark>
Chisel and FIRRTL do for example
<d1b2>
<Olivier Galibert> ahhhhh
<d1b2>
<Olivier Galibert> it's not an attribute of the domain? That's sad
<d1b2>
<Olivier Galibert> err wait, there's .clk on the domain isn't it?
<whitequark>
it is
<d1b2>
<Olivier Galibert> so it has no real reason to exist?
<whitequark>
but you can have m.d.sync without creating the domain
<whitequark>
with the domain being bound elsewhere
<d1b2>
<Olivier Galibert> would it be... m.domains.sync.clk?
<d1b2>
<Olivier Galibert> ah, inheriting it
<d1b2>
<Olivier Galibert> Error (14024): Parameter "duty_cycle" of instance "general[0].gpll" has illegal value "00000000000000000000000000110010" assigned to it. Possible parameter values are 1 to 99, inclusive. File: /people/galibert/quartus/intelFPGA_lite/18.1/quartus/libraries/megafunctions/altera_pll.v Line: 748
<whitequark>
it does
<whitequark>
if you don't have the ClockDomain object around, you can't refer to its .clk
<whitequark>
no
<whitequark>
yeah
<whitequark>
that only exists if you assigned something to m.domains.sync
<whitequark>
this whole system isn't particularly clear and I've not documented it yet
<whitequark>
it needs part redesign, part much better docs
<d1b2>
<Olivier Galibert> annoying, it wants a number, but amaranth turns it into 32'd50 and quartus gets all confused
<whitequark>
hm
<whitequark>
there was a verilog backend option, hold on
<whitequark>
this is wildly noncompliant iirc
<d1b2>
<Olivier Galibert> Info (12134): Parameter "duty_cycle0" = "00000000000000000000000000110010"
<whitequark>
verilog.convert(write_verilog_opts=["-decimal"]) is what you want
<d1b2>
<Olivier Galibert> turning it into a string works too
<d1b2>
<Olivier Galibert> quartus being quartus
<whitequark>
yeha
<d1b2>
<Olivier Galibert> Warning (10766): Verilog HDL Synthesis Attribute warning at top.v(7892): ignoring full_case attribute on case statement with explicit default case item File: /home/galibert/air/air/fpga/build/top.v Line: 7892
<d1b2>
<Olivier Galibert> feels like some part of the generated code doesn't agree with another