ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting TBD
<_whitenotifier> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JIufl
<_whitenotifier> [YoWASP/nextpnr] whitequark 74b5ff0 - Update dependencies.
<_whitenotifier> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JIukU
<_whitenotifier> [YoWASP/yosys] whitequark 9be4de1 - Update dependencies.
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
Sarayan has joined #nmigen
XMPPwocky has joined #nmigen
<XMPPwocky> is there a recommended way to go about duplicating a synchronous reset signal for submodules of a large design, to reduce fan-out?
<XMPPwocky> attempts to do this by setting max-fanout attributes in quartus have failed because quartus just... ignores them and doesn't say why
<XMPPwocky> but my global reset has uh 7k fanout now and it's starting to fail timing
<XMPPwocky> actually, any resources in general on how nmigen handles reset signals would be handy too, because i don't really know what's going on besides "my generated verilog has an 'rst'"
<whitequark> nmigen won't give you anything beyond that
<whitequark> i'm pretty sure inserting buffers to reduce fanout is not the job of the RTL entry software; are you sure quartus doesn't have some kind of a command for it?
<d1b2> <OmniTechnoMancer> Would it not usually route the global reset using global routing resources?
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
davidlattimore has quit [Read error: Connection reset by peer]
_florent_ has quit [Read error: Connection reset by peer]
_florent_ has joined #nmigen
sorear has quit [Ping timeout: 264 seconds]
davidlattimore has joined #nmigen
sorear has joined #nmigen
SpaceCoaster has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
SpaceCoaster has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
m4ssi has joined #nmigen
happycube has quit [Ping timeout: 265 seconds]
happycube has joined #nmigen
Chips4Makers has quit [Remote host closed the connection]
Chips4Makers has joined #nmigen
smkz has quit [Quit: smkz]
smkz has joined #nmigen
Chips4Makers has quit [Quit: Leaving.]
Chips4Makers has joined #nmigen
Chips4Makers has quit [Remote host closed the connection]
Chips4Makers has joined #nmigen
Chips4Makers has quit [Remote host closed the connection]
chipmuenk has quit [Quit: chipmuenk]
lkcl has quit [Ping timeout: 256 seconds]
Chips4Makers has joined #nmigen
lkcl has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #nmigen
Chips4Makers has quit [Remote host closed the connection]
emeb has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
chipmuenk has joined #nmigen
Lord_Nightmare has quit [Quit: ZNC - http://znc.in]
Lord_Nightmare has joined #nmigen
m4ssi has quit [Remote host closed the connection]
<agg> is ValueCastable considered 'public' yet? i noticed it's not exported from nmigen/nmigen.hdl, only nmigen.hdl.ast
<whitequark> it's public
<whitequark> the import situation is a bit weird tbh, it was never particularly clear
<whitequark> i'll likely resolve it simultaneously with improving docs
<agg> thanks
<lkcl> whitequark: oh, that reminds me. proposal / idea: ternary operator function (aka Mux) as a function similar to bool/any
<lkcl> and for Mux to call it:
<lkcl> def Mux(x,y,z): return x.mux(y,z)
<lkcl> the reason is that we can then do a ValueCastable "dynamic SIMD" object that behaves as expected for all operators... including Mux.
<awygle> morning
<lkcl> moornin
<lkcl> right now i've had to create a parallel function "PMux" and would be forced to perform a global/search/replace, all occurrences of "Mux" with "PMux" in code that is to be converted to Dynamically-partitioned SIMD
<lkcl> if however it was part of the Value / ValueCastable API... no such global/search/replace is required
<lkcl> actually it's even worse than having to do global/search/replace of Mux, we would be forced to record a higher-order-class containing Mux as one of the things in it
<lkcl> and do:
<lkcl> self.context.Mux(x,y,z)
key2 has quit [Ping timeout: 272 seconds]
key2 has joined #nmigen
<lkcl> because i would like the code to be re-configureable, transparently and seamlessly, from SIMD to non-SIMD by passing in a "context"
<whitequark> you wouldn't. you can just replace the import
<whitequark> re-export everything in nmigen.hdl except for Mux, then replace Mux with whatever you want
GenTooMan has quit [Ping timeout: 264 seconds]
<d1b2> <TiltMeSenpai> has anyone played with Minerva
jeanthom has joined #nmigen
GenTooMan has joined #nmigen
mwk has quit [Remote host closed the connection]
DonTrash has joined #nmigen
DonTrash has quit [Remote host closed the connection]
jeanthom has quit [Ping timeout: 258 seconds]
<lkcl> whitequark, so that sounds like a reasonable solution until attempting to have, in the same unit test and/or in the same processor, one SIMD ALU and one "scalar" ALU.
<lkcl> hence the reason for creating a class (API) that contains the "context" with:
<lkcl> * type of signal class (Signal or PartitionedSignal)
<lkcl> * type of Mux operation (nmigen.hdl.Mux or nmutil.PartitionedMux)
<lkcl> * etc. etc.
<lkcl> and to pass one of those in - *at runtime* - containing the *class* names (and functions) that the HDL module is to use
<lkcl> consequently, global/search/replace "Mux" with "whatever-you-want" is not an appropriate solution
<lkcl> it has to be:
<lkcl> signal = self.thecontext.TheSignalClass(width=64)
<lkcl> and all Muxes to be replaced with:
<lkcl> "comb += self.thecontext.Mux(x, y, z)"
<lkcl> which is... awful.
<lkcl> if however mux was an *OO function* - a peer of bool, some, __add__, __gt__ etc - then the problem entirely disappears
<lkcl> the god-awful dog's dinner mess that the code will be turned into will go away, entirely
<lkcl> and, if you think about it, it feels a little more "natural" (more pythonic) to have
<lkcl> comb += x.mux(y, z)
<lkcl> the global "Mux" function is... well... you need it, but it's not exactly pythonic. it's akin to operator.add (etc.) but in this case
<lkcl> where operator.add you know will call x.__add__(y)
<lkcl> nmigen.hdl.Mux is anomalous / asymmetric in that it does no such thing, despite it being a logical (ternary) operator.
* lkcl is trying to think of compelling reasons why it would be disruptive / disadvantageous / negative to add...
<lkcl> Verilog / VHDL aren't OO-based so they don't apply...
<whitequark> lkcl: no, you can have both just fine
<whitequark> branch on isinstance(x, YourValueCastableSubclass)
<lkcl> ,,, including on Signal, Record, and its replacement?
<whitequark> no? just on Mux
<lkcl> the idea is to pass in a class instance containing classes with either:
<whitequark> it's the same thing conceptually as the overload you want me to add, except you can use it right now without waiting for it to be added
<lkcl> * Signal + Mux on the one hand
<lkcl> * PartitionedSignal + PMux on the other
<whitequark> i'm not even going to discuss adding new public items until 0.3 release, it's dragged for long enough already
<whitequark> so that's your best option currently
<lkcl> ahh ok right. yepyepyep, no perfectly good point.
<lkcl> won't take up more of your time, then, it's for later, i'm just planning/thinking ahead
mwk has joined #nmigen
jeanthom has joined #nmigen
emeb_mac has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
jeanthom has joined #nmigen
Chips4Makers has joined #nmigen
<XMPPwocky> whitequark: re: yesterday - yes, quartus does have a command for it (both in .qsf and as a directive in vhdl/verilog). but quartus sees that command/directive, looks at it, and goes "no <3"
<XMPPwocky> Warning (18060): Ignored Maximum Fan-Out logic option for node "reset_synchronizer:U_reset_sync_rx|sync"
<XMPPwocky> @XMPPwocky
<XMPPwocky> and exactly no other information
Chips4Makers has quit [Quit: Leaving.]
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Ping timeout: 265 seconds]
Chips4Makers has joined #nmigen
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #nmigen
jeanthom has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
jeanthom has quit [Ping timeout: 256 seconds]
lkcl has joined #nmigen
emeb has quit [Quit: Leaving.]
sakirious has quit [Quit: The Lounge - https://thelounge.chat]