08:37 <xobs> Hey guys, simple question: in migen, how do I create a reg? I have a Signal(32) that I feed from a Wishbone bus (self.output.eq(bus.dat_w)), but the synthesized verilog keeps dfineing output as a wire and not a reg.

08:39 <xobs> ...and as a result I keep getting a synthesis error "procedural assignment to a non-register outputs is not permitted"

08:39 <whitequark> assign a signal in a sync block

08:39 <xobs> This is in a sync block. Specifically, "self.sync += self.gpio_outputs.eq(self.gpio_outputs_buf)".

08:41 <xobs> It's going to an IOBUF, which is instantiated with self.specials += Instance("IOBUF"). Does that IOBUF also need to be in a sync block?

08:41 <whitequark> what's the complete code?

08:42 <xobs> A fine question. https://gist.github.com/xobs/0e0d686f1d8c411b5102bf71dab4c891

08:43 <xobs> I'm trying to work around the issue by first buffering gpio_outputs into gpio_outputs_buf.

08:44 <whitequark> gpio_outputs is assigned in both the instance and the sync block

08:44 <whitequark> i think

08:48 <xobs> You're right there... the "I" line is FPGA output, and the "O" line is FPGA input (i.e. it's swapped -- it's from the perspective of FPGA fabric.) I need to swap that in my Verilog.

08:51 <xobs> Is it possible to instantiate a special inside a clock domain, then?

08:51 <whitequark> nope

08:55 <sb0> xobs: if you drive a signal from both an instance and a synchronous block, what do you expect to happen other than such an error?

08:55 <sb0> xobs: what do you mean by "instantiate a special inside a clock domain"?

08:55 <attie> uh, don't you give the clock signal explicitly when you have an Instance

08:56 <attie> other specials (like Memory) can be inside a clock domain I think

09:03 <xobs> I see, sorry for the noise. The issue appears to be that for a Xilinx IOBUF, the "O" line is FPGA input, and the "I" line is FPGA output. Vivado was picking up on this and failing.

09:10 <xobs> And now it successfully synthesizes and works as intended. Amazing. Thank you for the help.

12:39 <GitHub-m-labs> [artiq] sbourdeauducq pushed 3 new commits to switching: https://github.com/m-labs/artiq/compare/1ef39a98a7ae...65da1fee4a22

12:39 <GitHub-m-labs> artiq/switching ae72e3a Sebastien Bourdeauducq: firmware: add support for moninj and kern_hwreq over DRTIO switching

12:39 <GitHub-m-labs> artiq/switching 65da1fe Sebastien Bourdeauducq: firmware: fix build without DRTIO

12:39 <GitHub-m-labs> artiq/switching d19550d Sebastien Bourdeauducq: firmware: simplify drtioaux function names

13:57 <GitHub-m-labs> [artiq] klickverbot commented on issue #1150: Even with the ARP cache being limited, shouldn't the mapping just be re-learnt?... https://github.com/m-labs/artiq/issues/1150#issuecomment-421366641

14:11 <GitHub-m-labs> [artiq] klickverbot commented on issue #1150: Looking at the log, that does seem to happen. However, instead of the keepalive ACK, a RST/ACK is sent, presumably due to "timeout exceeded":... https://github.com/m-labs/artiq/issues/1150#issuecomment-421370769

14:13 <GitHub-m-labs> [artiq] klickverbot commented on issue #1150: Looking at the log, that does seem to happen. However, in addition to the keepalive ACK, a RST/ACK is sent, presumably due to "timeout exceeded":... https://github.com/m-labs/artiq/issues/1150#issuecomment-421370769

14:29 <GitHub-m-labs> [artiq] klickverbot commented on issue #1150: Ah, right, there is this:... https://github.com/m-labs/artiq/issues/1150#issuecomment-421376324

16:21 <GitHub-m-labs> [artiq] klickverbot commented on issue #1150: It seems like either the keepalive timeout needs to be adjusted to larger than the 3 s ARP discovery dead time, or the latter replaced by an actual rate limit (i.e. only delaying the ARP request if another was indeed sent in the last 3 s, rather than always waiting). https://github.com/m-labs/artiq/issues/1150#issuecomment-421410466

17:39 <GitHub-m-labs> [artiq] klickverbot commented on issue #1150: I've locally changed our Kasli masters to use a BTreeMap-backed neighbor cache (with default GC threshold of 1024), which should work around the issue by avoiding ARP table entries being evicted in the first place. If I don't succeed in provoking a crash, I'll post a PR. (It would still be good to have a more principled fix.) https://github.com/m-labs/artiq/issu

22:57 <GitHub-m-labs> [artiq] Justin318 opened issue #1151: with parallel becomes serial if called with for-loop https://github.com/m-labs/artiq/issues/1151

23:10 <GitHub-m-labs> [artiq] klickverbot commented on issue #1151: The ARTIQ timeline `with` statements are more or less implemented on a syntactic level. `with parallel` resets the timeline cursor before each statement in its body – but `for` is one statement (the body doesn't matter), so the `parallel` block is effectively trivial.... https://github.com/m-labs/artiq/issues/1151#issuecomment-421507068

23:21 <GitHub-m-labs> [artiq] Justin318 commented on issue #1151: Thanks David. Your suggestion work. https://github.com/m-labs/artiq/issues/1151#issuecomment-421508631

23:21 <GitHub-m-labs> [artiq] Justin318 commented on issue #1151: Thanks David. Your suggestion works. https://github.com/m-labs/artiq/issues/1151#issuecomment-421508631