ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 12th
<_whitenotifier-f> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-f> [YoWASP/nextpnr] whitequark cea1344 - Update dependencies.
peeps[zen] has quit [Read error: Connection reset by peer]
peeps[zen] has joined #nmigen
samlittlewood has quit [Quit: samlittlewood]
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
proteusguy has quit [Ping timeout: 258 seconds]
proteusguy has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
Asu has joined #nmigen
proteusguy has quit [Ping timeout: 260 seconds]
proteusguy has joined #nmigen
chipmuenk has joined #nmigen
<_whitenotifier-f> [nmigen] rroohhh commented on issue #425: Support for PLL primitives -
chipmuenk has quit [Ping timeout: 260 seconds]
<FL4SHK> does nMigen mind if I read from an output pin?
<FL4SHK> VHDL doesn't let you do that (for some reason?)
<FL4SHK> I think VHDL 2008 will let you
<lkcl> FL4SHK: you mean in simulation? you can read anything (yield x)
<FL4SHK> no, I mean in a DUT
<lkcl> trying to set one however, not so much
<FL4SHK> I said "output pin"
<FL4SHK> a port
<lkcl> yes. a dut. meaning in simulation.
<lkcl> yes of course.
<FL4SHK> uh
<miek> what do you mean by reading an output pin? by definition that doesn't really make sense
<lkcl> "dut" equals "device under test" and is just a naming convention
<FL4SHK> I mean in synthesizable code
<FL4SHK> terminology is getting mixed up
<lkcl> ah so you mean "when converted to rtlil or verilog"?
<FL4SHK> and in synthesis
<tpw_rules> FL4SHK: i believe it does?
<FL4SHK> "synthesizable" doesn't mean it's in synthesis
<FL4SHK> it means it *might* be
<FL4SHK> that's also what "DUT" means
<lkcl> if converted to verilog then verilog "rules" apply to outputs
<lkcl> which will have nothing to do with nmigen "per se"
<tpw_rules> but there's nothing stopping nmigen from adding a temporary i guess
<tpw_rules> not sure if it does
<FL4SHK> I don't mind if nMigen adds a temporary
<FL4SHK> I just want to not have to have the temporary
<FL4SHK> because I think it's nuts
<FL4SHK> reading an output pin is very much allowed in SV
<FL4SHK> and it isn't in VHDL
<FL4SHK> I like SV more than I do VHDL for some stuff
<FL4SHK> VHDL does a few things better in my book
<tpw_rules> then yes it does work afaik
<FL4SHK> like letting you put unconstrained stuff on ports
<FL4SHK> *on subprogram ports
<FL4SHK> I know that SV does a pretty good job with `interface`s
<FL4SHK> but the downside of those is you can't use them as `function` or `task` arguments
<FL4SHK> nMigen doesn't have arbitrary restrictions like this from what I can tell
<FL4SHK> mainly because Python doesn't :)
<FL4SHK> looks like Python 3.9 has generics
<FL4SHK> without them being function arguments
chipmuenk has joined #nmigen
emeb_mac has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<_whitenotifier-f> [nmigen] pbsds commented on issue #425: Support for PLL primitives -
<FL4SHK> do `Case` items need to be the same size as what you're `Switch`ing?
<FL4SHK> can't do this in VHDL or SV
<FL4SHK> I need a different number of `Case`s based on a generic
<FL4SHK> the generic determines the `len(loc.gt_vec)`
<FL4SHK> seems I screwed up
<FL4SHK> "1" + ("-" * i)
<FL4SHK> instead of the `"".join` business
<Sarayan> whitequark: Isn't the routing problem for the pll the work of nextpnr or whatever? The verilog for the NES on mister does not include which pll to use, which means nmigen doesn't have to choose either
<Sarayan> and I suspect it tends to be selected with "which pll has the dedicated connection to the clock pin"
<vup> Sarayan: xilinx 7series for example has two types of PLLs (one called PLL and one called MMCM). Choosing which one of them to use for which clocks is something I would count under the routing problem, and is not something done by the pnr tools usually (atleast that I am aware of)
<cr1901_modern> whitequark: Potentially useful for nmigen-soc? (It's "cargo for C/C++ projects", essentially)
<Sarayan> vup: Interesting
<Sarayan> so it's more for when you have to choose between multiple types, makes sense
Asu has quit [Quit: Konversation terminated!]
<_whitenotifier-f> [nmigen] whitequark commented on issue #425: Support for PLL primitives -
<whitequark> cr1901_modern: well, I'm personally primarily interested in Rust for nmigen-soc
<FL4SHK> started formally verifying my long divider