01:09 <_whitenotifier-f> [nmigen] newhouseb opened pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6yD

01:10 <_whitenotifier-f> [nmigen] newhouseb edited pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6yD

01:11 <_whitenotifier-f> [nmigen] newhouseb edited pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6yD

01:12 <_whitenotifier-f> [nmigen] codecov[bot] commented on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6yN

01:12 <_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6yN

01:13 <_whitenotifier-f> [nmigen] whitequark commented on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6Se

01:13 <_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6yN

01:14 <_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6yN

01:16 <_whitenotifier-f> [nmigen] whitequark closed pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6yD

01:16 <_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JT6Ss

01:16 <_whitenotifier-f> [nmigen/nmigen] newhouseb 765c15c - setup: link to latest docs if VCS information is not available.

01:17 <_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JT6SC

01:17 <_whitenotifier-f> [nmigen/nmigen] whitequark 4440b9f - Deploying to gh-pages from @ 765c15c709a9f2366555ed86eecdbdc7de6721c5 🚀

01:17 <_whitenotifier-f> [nmigen] newhouseb commented on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6SW

01:17 <_whitenotifier-f> [nmigen] newhouseb edited a comment on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6SW

01:18 <_whitenotifier-f> [nmigen] whitequark commented on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6S2

01:19 <_whitenotifier-f> [nmigen] whitequark commented on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT6Sa

01:30 <_whitenotifier-f> [nmigen] newhouseb commented on pull request #516: Handle installation when not running from a full git checkout - https://git.io/JT69W

02:51 <_whitenotifier-f> [nmigen] whitequark reviewed pull request #512 commit - https://git.io/JT6F2

16:02 <agg> if I want two readers for a memory, normally i'd make two memories, tie the write ports together, and just use the two independent read ports; can i just add two read ports to a Memory and expect yosys to do the right thing?

16:02 <agg> on ice40/ecp5

16:04 <agg> on a sort of related note, i find i'm often passing read or write ports into my elaboratables' init methods, rather than later using comb statements to wire up addr/data/en to signals in the elaboratable, is that sensible or are there better techniques?

16:20 <whitequark> (two read ports) generally yes, you can

16:21 <whitequark> (passing ports into init methods) this would result in hierarchy flattening

16:23 <agg> hmm, I guess I haven't been looking for that but don't think I've observed it in simulation at least

16:23 <agg> would you usually comb wire the port signals into each module instead?

16:23 <agg> I guess ideally something like record that can connect all the signals in the right directions would be easier

16:24 <whitequark> yes, we have that planned

16:24 <agg> does it depend on which module's submodules the port gets added to?

16:25 <agg> e.g. if I pass the write port into an elaboratable which then adds it to its module's submodules in elaborate(), would that avoid flattening?

16:25 <whitequark> if you use memory ports in any two different modules it will flatten all hierarchy in between

16:26 <agg> just in synthesis or simulation too? if it's in synthesis... does it matter, if I'm flattening anyway (by default)?

16:26 <agg> I guess it will make it more annoying when I want to not flatten to get utilisation stats

16:29 <whitequark> in simulation as well

22:35 <bsmt> is there an example for requesting pins from a connector?

22:36 <whitequark> you can't request pins from a connector

22:36 <whitequark> you need to add a resource

22:51 <bsmt> gotcha, thanks. So I should just subclass the platform and make a Resource using the connector pins I want? or is there another way?

22:53 <whitequark> you don't need to subclass the platform

22:53 <whitequark> just `platform.add_resource` works

22:53 <bsmt> oh cool. yeah that's way better, thanks again!

23:01 <a314> In a testbench, is it possible to force all flops to initialize to random values

23:01 <a314> like what would happen in a "real" asic

23:02 <whitequark> at the moment nmigen requires every platform to provide deterministic power-on reset

23:02 <whitequark> there is an open issue for better ASIC support that would involve what you want

23:06 <a314> is asserting the reset signal at powerup sufficient?

23:06 <a314> (as in, does nmigen expect flops to have the right values on startup, or does it expect them to have the right values after asserting reset?)

23:12 <whitequark> a314: if your ASIC has a global reset signal (routed to every FF) and you assert that, then from nmigen's point of view this looks exactly like power-on reset

23:12 <whitequark> i.e. in nmigen, power-on reset values and domain reset values are always the same

23:13 <whitequark> the one place where you may encounter issues is SRAMs, because at the moment, nmigen assumes it can always initialize SRAMs and it defaults to zero-initializing them. which is obviously unviable for ASICs

23:13 <a314> ah okay

23:13 <a314> and that global reset signal is automatically generated for Resettable signals right?

23:14 <whitequark> it depends on the platform

23:15 <whitequark> for FPGAs, the global reset signal is the internal power-on reset that is implicit in the FPGA's architecture

23:15 <whitequark> i.e. it is not present in the netlist explicitly

23:15 <a314> how about if just generating a verilog module

23:15 <whitequark> if you specify no domain, or a non-reset-less domain (reset-ful?) then you will get an `input rst`

23:15 <a314> ah ok

23:16 <a314> and the SRAM init thing makes sense, my SRAMs are probably going to be written in pure verilog

23:22 <whitequark> well the usual reason SRAM doesn't have init is because it has 6T standard cells

23:22 <whitequark> so you don't really get to init them or to route a reset to them

23:25 <a314> oh i'm aware of that, I just meant I was going to have them external so nmigen / the testbench doesn't expect different behavior

23:27 <whitequark> right

23:27 <whitequark> please report your experience at https://github.com/nmigen/nmigen/issues/185

23:45 <_whitenotifier-f> [nmigen] rroohhh opened pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFl

23:49 <_whitenotifier-f> [nmigen] codecov[bot] commented on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFD

23:49 <_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFD

23:49 <_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFD

23:52 <_whitenotifier-f> [nmigen] rroohhh commented on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPbL

23:56 <_whitenotifier-f> [nmigen] whitequark commented on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPb0

23:58 <_whitenotifier-f> [nmigen] rroohhh synchronize pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFl

23:58 <_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFD