<_whitenotifier-f>
[YoWASP/runtime] whitequark 58bca15 - [autorelease] Update wasmtime version requirement from <9 to <10.
PatD has joined #amaranth-lang
<PatD>
Greetings, I'd like to get to know the Amaranth internals a bit and, ideally, contribute to the project. My questions: is there a document related to coding standards or submissions process or anything of that nature I should be aware of? Also, are there any high priority areas that need some love that I should look at first? My personal
<PatD>
interest is currently on the simulation and verification side of things. Thanks.
<whitequark>
coding standards: not currently, it is planned (although other stuff is taking priority atm), if you style your code the way it's currently there you won't have issues
<whitequark>
at the moment a lot of contributions are gated on me personally in various ways. this isn't good and is in the process of being fixed; in the meantime you can look at issues with meta:help-wanted tag
<PatD>
acknowledged. do you use some sort of linter?
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #amaranth-lang
PatD has quit [Quit: Client closed]
<cr1901>
How do I access the current state/state names of an FSM outside of the FSM? Something like m.d.comb += [sig.eq(m.State() != "FOO" & bar)].
<jfng[m]>
cr1901: if you assign it to a variable (`with m.FSM() as fsm: ...`), you can do `sig.eq(~fsm.ongoing("FOO") & bar)`
SpaceCoaster has quit [Ping timeout: 240 seconds]
SpaceCoaster has joined #amaranth-lang
oter has quit [Ping timeout: 248 seconds]
oter has joined #amaranth-lang
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #amaranth-lang
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #amaranth-lang
<Chips4MakersakaS>
In the evenings when I get my Youtube & co. fix I am a-'social'; mostly ignoring messages on Element and other socials.
<Chips4MakersakaS>
Regarding `reset_less` we had similar discussion already few years and this resulted in [#185](https://github.com/amaranth-lang/amaranth/issues/185). Especially the fourth point about `reset_less` signals not being initialised during power-on is important. If your simulation of a `reset_less` signal still assumes it initialises to 0 this won't match reality on an ASIC.
<Chips4MakersakaS>
In similar vain a domain that is `reset_less` as a whole does not make much sense to me either for ASIC as one tupically at least want to have their FSM be initialized to a known start state. From the other side assuming all signals by default initialize to 0 makes all the flipflops be on the reset net making this a very high fan-out net and thus putting strain on P&R. I currently don't have insight if this trade-off is acceptabl
<Chips4MakersakaS>
performance and area wise.
<Chips4MakersakaS>
* Regarding `reset_less` we had similar discussion already few years and this resulted in [#185](https://github.com/amaranth-lang/amaranth/issues/185). Especially the fourth point about `reset_less` signals not being initialised during power-on is important. If your simulation of a `reset_less` signal still assumes it initialises to 0 this won't match reality on an ASIC.
<Chips4MakersakaS>
In similar vain a domain that is `reset_less` as a whole does not make much sense to me either for ASIC as one tupically at least want to have their FSM be initialized to a known start state. From the other side assuming all signals by default initialize to 0 makes all the flipflops be on the reset net making this a very high fan-out net and thus putting strain on P&R. I currently don't have insight if this trade-off is acceptabl
<Chips4MakersakaS>
performance and area wise.
<Chips4MakersakaS>
* Regarding `reset_less` we had similar discussion already few years and this resulted in [#185](https://github.com/amaranth-lang/amaranth/issues/185). Especially the fourth point about `reset_less` signals not being initialised during power-on is important. If your simulation of a `reset_less` signal still assumes it initialises to 0 this won't match reality on an ASIC.
<Chips4MakersakaS>
performance and area wise.
<Chips4MakersakaS>
In similar vain a domain that is `reset_less` as a whole does not make much sense to me either for ASIC as one typically at least wants to have their FSMs be initialized to a known start state. From the other side assuming all signals by default initializes to 0 makes all the flipflops be on the reset net making this a very high fan-out net and thus putting strain on P&R. I currently don't have insight if this trade-off is accept
<Chips4MakersakaS>
* Regarding `reset_less` we had similar discussion already few years ago and this resulted in [#185](https://github.com/amaranth-lang/amaranth/issues/185). Especially the fourth point about `reset_less` signals not being initialised during power-on is important. If your simulation of a `reset_less` signal still assumes it initialises to 0 this won't match reality on an ASIC.
<Chips4MakersakaS>
In similar vain a domain that is `reset_less` as a whole does not make much sense to me either for ASIC as one typically at least wants to have their FSMs be initialized to a known start state. From the other side assuming all signals by default initializes to 0 makes all the flipflops be on the reset net making this a very high fan-out net and thus putting strain on P&R. I currently don't have insight if this trade-off is accept
<Chips4MakersakaS>
performance and area wise.
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #amaranth-lang
cr1901 has quit [Remote host closed the connection]
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] whitequark f1c3b18 - Deploying to main from @ amaranth-lang/amaranth@52b9d3f799edec75cc3e441d6e6f0ef128d20336 🚀
<cr1901>
jfng[m]: I see. In Migen IIRC there was also "just entered", "about to leave", "didn't just enter and not about to leave", "not about to leave", and "didn't just enter" queries on the FSM.
<cr1901>
And I thought ongoing corresponded to "didn't just enter and not about to leave" (which would also be asserted just after reset)
tpw_rules has quit [Ping timeout: 268 seconds]
tpw_rules has joined #amaranth-lang
<whitequark>
most of the Migen FSM functionality is absent
<whitequark>
half of it was really bug-prne and fr the other half it wasn't clear if it's even that useful
<cr1901>
"next" is exposed via m.next. Are "(current_)state" and "prev" exposed at all within m.FSM() context?
<cr1901>
(Actually I've never tried reading m.next)
<cr1901>
And if not, worth an RFC?
Taha has joined #amaranth-lang
Taha is now known as Taha_
Taha_ is now known as Taha__
Taha__ is now known as Taha`
oter has quit [Remote host closed the connection]
<whitequark>
we need an RFC for a complete redesign of the FSM system
<whitequark>
incremental fixes are not going to cut it I think
oter has joined #amaranth-lang
<cr1901>
The statements I linked in Verilog could of course be rewritten in Amaranth w/ extra states to remove dependency on prev/curr (Moore FSM). I'm not convinced that's nicer than the Verilog solution. My opinion not representative.
<cr1901>
At least Amaranth makes it easy to add new States w/o needing to update enums all over the place
<crzwdjk>
I really want that RFC for better FSMs but I also don't really feel like I have specific enough ideas or sufficient HDL knowledge to actually write it.
PatD has joined #amaranth-lang
Taha` has quit [Quit: Client closed]
PatD has quit [Quit: Client closed]
cr1901 has quit [Read error: Connection reset by peer]
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] whitequark 9d36f28 - Deploying to main from @ amaranth-lang/amaranth@f96604f667516ba9fbf125db8dff8b3742f61f1d 🚀