whitequark changed the topic of #amaranth-lang to: Amaranth hardware definition language · code https://github.com/amaranth-lang · logs https://libera.irclog.whitequark.org/amaranth-lang
<_whitenotifier-e> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±2] https://github.com/YoWASP/nextpnr/compare/81a5058b2324...7f89e61eba50
<_whitenotifier-e> [YoWASP/nextpnr] whitequark 7f89e61 - Update dependencies.
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
cr1901 has quit [Quit: Maintenance... be back when I wake up]
dcallagh has quit [Quit: You have been kicked for being idle]
wolfshappen has quit [Quit: later]
wolfshappen has joined #amaranth-lang
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
indy has joined #amaranth-lang
cr1901 has joined #amaranth-lang
<d1b2> <garbile> Can I assign "don't care" to a signal?
<whitequark> no
<d1b2> <dragonmux> Amaranth doesn't allow you to do anything that isn't representable by a real device
<d1b2> <dragonmux> if you need to tristate a pin, use the 'io'/'oe' dirs and the .oe member
<d1b2> <dragonmux> (Amaranth does allow you to use '-' type don't care in switch-cases though)
<whitequark> this isn't entirely true; internal tristates exist in some devices, and external tristates are commonplace
<whitequark> similarly, uninitialized values (also represented as x) are a real phenomenon encountered in e.g. uninitialized block RAMs in ASICs and some FPGAs
<d1b2> <dragonmux> ah, true.. but devices that do internal tristating are very rare now from what we understand, and external tristate is handled more elegantly and reliably with the proper signal direction stuff the Resource system uses
<d1b2> <dragonmux> ie, those external tristate signals are handled as just that.. external..
<whitequark> yes; they're not a part of the model because the model can be simplified considerably this way
<whitequark> the computation model that is
<d1b2> <dragonmux> mhm
<whitequark> it's not really about representability but about semantics of netlists and the way they are processed by the toolchain
<d1b2> <dragonmux> as for uninit BRAM.. reminds us of the PSRAM on the iCE40UP5K.. which is.. Complicated.. because "uninitialised" is actually a reliable bit pattern as we found out
<whitequark> consider that uninitialized values will be a part of the simulations at some point, but there's no indication of whether a given physical bit is "uninitialized"; that concept is just an abstraction we made up
<d1b2> <dragonmux> er.. SPRAM.. get the letters the right way around
<whitequark> oh yeah, that's how SRAM generally is
<d1b2> <dragonmux> agreed though that by banning it from the primary signal model in Amaranth it made things much easier to not just understand but also reason about
<d1b2> <dragonmux> harder to shoot one's foot this way
<d1b2> <dragonmux> same with not exposing "inout" signals
<d1b2> <dragonmux> er.. not generally exposing
modwizcode has joined #amaranth-lang
modwizcode has left #amaranth-lang [#amaranth-lang]
modwizcode has joined #amaranth-lang
lf_ has quit [Ping timeout: 272 seconds]
lf has joined #amaranth-lang