whitequark[cis] changed the topic of #amaranth-lang to: Amaranth hardware definition language · weekly meetings: Amaranth each Mon 1700 UTC, Amaranth SoC each Fri 1700 UTC · play https://amaranth-lang.org/play/ · code https://github.com/amaranth-lang · logs https://libera.irclog.whitequark.org/amaranth-lang · Matrix #amaranth-lang:matrix.org
notgull has joined #amaranth-lang
notgull has quit [Ping timeout: 268 seconds]
lf has joined #amaranth-lang
lf_ has quit [Ping timeout: 268 seconds]
cr1901_ has joined #amaranth-lang
Degi_ has joined #amaranth-lang
cr1901 has quit [Ping timeout: 260 seconds]
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
Lord_Nightmare has joined #amaranth-lang
Lunaphied[m] has joined #amaranth-lang
<Lunaphied[m]> Just used the "new" wiring lib for the first time, very nice! Makes things significantly better IMO 
<whitequark[cis]> thanks. if I recall correctly, you've had some input to the early draft of that RFC
cr1901_ is now known as cr1901
richardeoin has quit [Remote host closed the connection]
richardeoin has joined #amaranth-lang
VA3TEC-Mikek-143 has quit [Quit: Idle timeout reached: 172800s]
jfng[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has joined #amaranth-lang
notgull has quit [Ping timeout: 264 seconds]
notgull has joined #amaranth-lang
notgull has quit [Ping timeout: 268 seconds]
Stevetronics has joined #amaranth-lang
<Lunaphied[m]> I believe so, I'm happy to see how it turned out
<Lunaphied[m]> One thing I did think about (and this is more for documentation) is that if you're dealing with tristates because you're defining ports connected to tristates upstream, you'll probably want to define them as "In" so they get wired up in the right order
<Lunaphied[m]> This is arguably a hack but it seems effective enough
<Lunaphied[m]> For a concrete example. I have an SRAMProducer that bridges between the physical SRAM interface and a simplified internal interface. The upstream interface is linked through connections only to the pins, and I instantiate the tristate buffers inside for the IOs to connect to. I capture the upstream definition in a Signature to make the chaining to the top level easier
<Stevetronics> I apologize for what may be a simple "RTFM" question - is there documentation for the simulator interface? I'd like to run a test where I do some stuff, then assert reset, then do some more stuff to make sure my logic behaves correctly. I may simply fundamentally misunderstand the action of the (reset=value) field when creating a signal. Is there a
<Stevetronics> "default" reset signal wired into `wiring.Component` in the same way that `sync` domains pass clocks?
<Stevetronics> Ok wait I think I have a lead, but I could use some help getting all the way to the end. I see in the docs for ClockDomain that each domain has a `cd.rst` signal associated with it. is there a straightforward way to access that signal from inside the simulator?
Stevetronics has quit [Quit: Client closed]
Stevetronics has joined #amaranth-lang
Stevetronics has quit [Quit: Client closed]
Stevetronics has joined #amaranth-lang
Stevetronics has quit [Quit: Ping timeout (120 seconds)]
Stevetronics has joined #amaranth-lang
Stevetronics has quit [Quit: Client closed]
<whitequark[cis]> > is there documentation for the simulator interface?
<whitequark[cis]> not yet
<whitequark[cis]> > is there a straightforward way to access that signal from inside the simulator?
<whitequark[cis]> try `ResetSignal()`
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
lf has quit [Ping timeout: 240 seconds]
lf has joined #amaranth-lang
Stevetronics has joined #amaranth-lang
<Stevetronics> whitequark[cis] - thanks for the heads up! I