05:48 <cr1901_modern> sb0: Why do you check DUP_TOP in get_var_name? Additionally, under what conditions in Python code would frame.f_lasti _not_ be a CALL instruction? https://github.com/m-labs/migen/blob/master/migen/fhdl/tracer.py#L8

05:54 <cr1901_modern> (And by extension, if frame.f_lasti _was_ a CALL insn, why wouldn't you find at least a STORE_NAME, STORE_ATTR, etc while going up the stack. It feels like you should _always_ be able to extract a var name)

06:10 <sb0> cr1901_modern, DUP_TOP is for handling things like self.x = x = Signal()

06:12 <cr1901_modern> I suppose I should dump the bytecode of statements like that and see what's actually generated

06:14 <cr1901_modern> Oh interesting... get_var_name isn't actually used anywhere within migen itself

06:14 <cr1901_modern> erm, scratch that

06:18 <cr1901_modern> sb0: I don't see how get_obj_var_name() is called as a part of, for example, "self.x = x = Signal()"

06:18 <cr1901_modern> unless github's search is missing some results for "get_obj_var_name"

06:29 <sb0> cr1901_modern, is it not? try adding a print() there and creating a Signal

06:37 <cr1901_modern> I see, get_var_name is called in trace_back()

06:39 <cr1901_modern> sb0: I was hoping to have the 3.6 fix done tonight, but I need to look into it a bit more.

06:39 <cr1901_modern> Support Python 3.5 CALL_FUNCTION_KW/CALL_FUNCTION_KW_ARGs requires that we detect/ignore a few more opcodes (like BUILD_TUPLE). But I haven't yet been able to generate an example that crashes

06:40 <cr1901_modern> Supporting*. For that reason, I think the fix should be two phase- complete Python 3.5, then refactor to support Python 3.5 and 3.6 side-by-side. Should I open a separate issue for the former?

06:42 <cr1901_modern> (Source: https://docs.python.org/3.5/library/dis.html#opcode-CALL_FUNCTION_VAR_KW "The top element on the stack contains the keyword arguments dictionary, followed by the variable-arguments tuple, followed by explicit keyword and positional arguments.")

07:44 <sb0> cr1901_modern, yes, open another issue

08:26 <sb0> _florent_, when you are resetting a FSM with ResetInserter, it stays stuck in its initial state, which is decoded combinatorially

08:26 <sb0> therefore, this code https://github.com/enjoy-digital/transceiver_test/blob/master/transceiver/gtp_7series_init.py#L95 incorrectly drives the transceiver reset high immediately upon configuration

08:33 <sb0> the qpll doesn't have annoying reset requirements? surprising...

08:34 <sb0> well, requiring a reset at all is slightly annoying already

10:10 <_florent_> sb0: thanks, will look at that

10:10 <sb0> I'm rewriting that code right now, you may want to build upon that

10:12 <_florent_> sb0: ok i'll wait then

10:12 <sb0> _florent_, in the meantime there is the jesd stuff

10:13 <_florent_> sb0: yes sure

10:23 <sb0> _florent_, also the PLL reset is apparently also subject to this 500ns timer

10:23 <sb0> If the reset mode is defaulted to sequential m

10:23 <sb0> ode upon configuration, then PLL[0/1]RESET and

10:23 <sb0> GTRXRESET can be asserted after waiting for

10:23 <sb0> a minimum of 500 ns after configuration is

10:23 <sb0> complete.

12:02 <GitHub122> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/2ee3d5496c54d548ac63e3d6391e738ab7169cd6

12:02 <GitHub122> misoc/master 2ee3d54 Sebastien Bourdeauducq: a7gtp: add transceiver initialization code

12:02 <sb0> _florent_, I guess the phase alignment code when buffer bypass is used can be added as external modules? it seems, this phase alignment is something you can do after the regular reset sequence has been completed?

12:05 <bb-m-labs> build #293 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/293

12:48 <_florent_> sb0: yes probably, i was also thinking about that while looking at multi-lane initialization for gth

12:49 <_florent_> sb0: between single or multi-lane, phase alignment sequence is different, so yes having it outside would simplify things

15:05 <GitHub189> [artiq] jbqubit commented on issue #854: @sbourdeauducq ping https://github.com/m-labs/artiq/issues/854#issuecomment-351077836

16:20 <GitHub108> [artiq] gkasprow commented on issue #854: It should look like this:... https://github.com/m-labs/artiq/issues/854#issuecomment-351102602

16:22 <GitHub194> [artiq] sbourdeauducq commented on issue #854: Does the built-in JTAG work with vivado? https://github.com/m-labs/artiq/issues/854#issuecomment-351103141

16:46 <GitHub133> [artiq] gkasprow commented on issue #854: I didnt even try. I use external jtag cable https://github.com/m-labs/artiq/issues/854#issuecomment-351110976

17:45 <GitHub27> [smoltcp] jonaskeller commented on issue #93: Sure, I'll just have to wait for it to occur again. Based on what I've seen so far, that might take a few days. https://github.com/m-labs/smoltcp/issues/93#issuecomment-351128965

18:44 <rjo> sb0: did anyone check that the M* switches on the sayma boards are in the correct position?

22:12 <GitHub191> [artiq] philipkent opened issue #866: Installing artiq 3.1 https://github.com/m-labs/artiq/issues/866

22:41 <GitHub155> [artiq] gkasprow commented on issue #854: @sbourdeauducq I found little issue with the bits I published. The nibbles on the Rx side were swapped and could cause confusion. I fixed it and now it's fine. The files are in the Dropbox directory I shared.... https://github.com/m-labs/artiq/issues/854#issuecomment-351219156

22:41 <GitHub173> [artiq] gkasprow commented on issue #854: @sbourdeauducq I found little issue with the design and bits I published. The nibbles on the Rx side were swapped and could cause confusion. I fixed it and now it's fine. The files are in the Dropbox directory I shared.... https://github.com/m-labs/artiq/issues/854#issuecomment-351219156