00:54 <_whitenotifier> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JI2Ba

00:54 <_whitenotifier> [YoWASP/yosys] whitequark 34d7360 - Update dependencies.

05:00 <_whitenotifier> [nmigen] rachsug opened issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JI2Fn

05:17 <_whitenotifier> [nmigen] davidlattimore commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JI2N7

08:03 <_whitenotifier> [nmigen] daveshah1 commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIaGo

09:46 <_whitenotifier> [nmigen] weshu opened issue #559: Negative values support in Switch-Case - https://git.io/JIagQ

17:01 <_whitenotifier> [nmigen] whitequark commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIVxG

17:06 <_whitenotifier> [nmigen-boards] whitequark commented on issue #128: [RFC] Testing and releasing nmigen-boards - https://git.io/JIVpq

17:13 <_whitenotifier> [nmigen] whitequark commented on issue #559: Negative values support in Switch-Case - https://git.io/JIVht

17:13 <whitequark> XMPPwocky: okay, so... that's unfortunate but in my view the right thing to do is to figure out what it is that quartus doesn't like

17:14 <whitequark> nmigen lives on a higher level of abstraction than the one where net fanout matters, so even if you insert buffers with something like m.d.comb += .eq(), quartus will probably fold them all back

17:14 <whitequark> of course, you can always add vendor primitives manually, but that's also not something nmigen can do in general

17:14 <whitequark> since it's design-specific

18:12 <Bertl_oO> whitequark: ktemkin: what's the current state of the art for an USB 2.0 sniffer/tool which can optionally also alter the communication (PITM)?

18:13 <Bertl_oO> i.e. what tools (hardware and software) would you use for this?

18:16 <whitequark> i never really needed to modify packets

18:16 <whitequark> so i use openvizsla

18:16 <whitequark> well... i use it mostly because i have an openvizsla and nothing else... not because it is state of the art :)

18:17 <Bertl_oO> fair enough :)

18:18 <Bertl_oO> I have a case where neither the host nor the client side is really under my control, so I'd like to be able to first sniff/analyze the traffic and then do some probing by altering or injecting packets

18:19 <Bertl_oO> I'm toying with the idea to build my own hardware for that, but if there is something available already it would of course be preferred ...

20:36 <XMPPwocky> whitequark: okay, thanks - yeah quartus is either doing something weird or just something i don't understand yet - it claims the reset synchronizer's output *is* in fact using a global clock line, with fanout 1696, and also that the same signal is a 'non-global high-fanout signal' with fanout 3732

20:36 <XMPPwocky> i've managed to sort of massage things enough that timing passes, so not an issue anymore (for now)

20:37 <whitequark> interesting

20:37 <whitequark> can you show me the .il file? it might be something obvious

20:39 <XMPPwocky> how do i get that? atm my nmigen -> verilog ; the reset synchronizer is from the design my logic is embedded in and is in VHDL; i don't *think* it's (immediately) an nmigen-related issue, was more looking to see if i could work around it

20:39 <whitequark> oh i see

20:40 <whitequark> nevermind then, i assumed the synchronizer would be a part of nmigen code

20:40 <whitequark> that... sounds really annoying, sorry you're dealing with that

20:42 <XMPPwocky> yeah i mean it's also even possible that everything's working fine and reset is actually either getting register-duplicated or using a gclk buffer... and timing just happened to fail on paths from the reset signal to other stuff for unrelated reasons

20:43 <whitequark> "non-global high-fanout signal" with higher fanout than the global seems troublesome

20:43 <whitequark> can you uh... explore the post-placement netlist?

20:44 <XMPPwocky> well, that segfaulted quartus, let's try again

20:50 <XMPPwocky> https://imgur.com/a/jpQeIs9 zoomed in / zoomed out, not quite sure what i'm looking for (lmk if this'd be more appropriate for another channel)

20:50 <whitequark> hm

20:51 <XMPPwocky> (i stuck that extra register in there to at least help things along a bit- the output of *that* register is the one that's both global and non-global

20:51 <whitequark> by any chance, do you have a mixture of sync and async resets tied to that signal?

20:52 <XMPPwocky> the synchronizer producing it seems to give you async assertion, synchronous deassertion, aiui

20:53 <whitequark> no no

20:53 <whitequark> i mean that you can have a flop with sync reset or async reset

20:53 <whitequark> (or both)

20:53 <whitequark> so in the rest of the logic (after the synchronizer), which resets is the signal connected to?

20:54 <XMPPwocky> at a glance, seems to be all sclr

20:55 <whitequark> okay, no ideas here

20:57 <XMPPwocky> fair, thanks anyways

21:20 <nfbraun> In a Pysim process, how do I wait for a signal to change?

21:26 <whitequark> nfbraun: poll it in a loop

21:27 <nfbraun> Ok, that's what I am doing right now.

21:27 <nfbraun> But then I have to pick a delay time in the loop, right?

21:28 <nfbraun> while ((yield foo) == old_foo):

21:28 <nfbraun> yield Delay(1e-9)

21:28 <nfbraun> Like this?

21:29 <whitequark> you could also `yield Tick("domain")` if that makes sense for your design

21:34 <nfbraun> Does not really make sense (I'm trying to simulate an off-FPGA SPI slave), but I guess it could work.

21:37 <whitequark> internally, python processes can wait on any signal, but this capability isn't currently exposed

21:37 <whitequark> this is mainly because the simulator interface is not well thought out and it's not something i want to commit to long term

21:41 <nfbraun> Ok. I found https://github.com/m-labs/nmigen/issues/228 while searching for an answer, so I guess that is work in progress for now?

21:41 <nfbraun> Anyway, the poll loop will do for now. Thanks!

21:47 <nfbraun> Ok, I should have looked at https://github.com/nmigen/nmigen/issues/228 . Sorry...

22:13 <XMPPwocky> nfbraun: fwiw you might be able to write a function just for the delay loop and then 'yield from wait_for_change(foo)' ?

22:21 <_whitenotifier> [nmigen] nfbraun commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIw6B

22:25 <_whitenotifier> [nmigen] nfbraun edited a comment on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIw6B

22:30 <_whitenotifier> [nmigen] whitequark commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIwii

22:36 <_whitenotifier> [nmigen] nfbraun commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIwPs

22:44 <_whitenotifier> [nmigen] whitequark commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIwXf

22:49 <_whitenotifier> [nmigen] nfbraun commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIwX4

22:51 <_whitenotifier> [nmigen] whitequark commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIwX1

23:03 <_whitenotifier> [nmigen] nfbraun commented on issue #558: write_cfgmem is writing to arty board when not specified to in the code - https://git.io/JIw1w

23:18 <nfbraun> XMPPwocky: Yes, sure. The problem with the Delay in the loop is more that the delay is either small, meaning it makes the simulation take longer than necessary, or long, meaning I go beyond the edge I am interested in.

23:29 <whitequark> there's a phenomenon where making a language facility more useful (in nmigen processes are fully asynchronous, unlike in migen) leads to more complaints (because the more complex interface has more potential pitfalls)