sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale has joined #m-labs
rohitksingh_work has joined #m-labs
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <-]
<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
<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)
<sb0> cr1901_modern, DUP_TOP is for handling things like self.x = x = Signal()
<cr1901_modern> I suppose I should dump the bytecode of statements like that and see what's actually generated
<cr1901_modern> Oh interesting... get_var_name isn't actually used anywhere within migen itself
<cr1901_modern> erm, scratch that
<cr1901_modern> sb0: I don't see how get_obj_var_name() is called as a part of, for example, "self.x = x = Signal()"
<cr1901_modern> unless github's search is missing some results for "get_obj_var_name"
<sb0> cr1901_modern, is it not? try adding a print() there and creating a Signal
<cr1901_modern> I see, get_var_name is called in trace_back()
<cr1901_modern> sb0: I was hoping to have the 3.6 fix done tonight, but I need to look into it a bit more.
<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
<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?
<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.")
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
<sb0> cr1901_modern, yes, open another issue
<sb0> _florent_, when you are resetting a FSM with ResetInserter, it stays stuck in its initial state, which is decoded combinatorially
mumptai has joined #m-labs
<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
<sb0> the qpll doesn't have annoying reset requirements? surprising...
<sb0> well, requiring a reset at all is slightly annoying already
mumptai has quit [Remote host closed the connection]
<_florent_> sb0: thanks, will look at that
<sb0> I'm rewriting that code right now, you may want to build upon that
<_florent_> sb0: ok i'll wait then
<sb0> _florent_, in the meantime there is the jesd stuff
<_florent_> sb0: yes sure
<sb0> _florent_, also the PLL reset is apparently also subject to this 500ns timer
<sb0> If the reset mode is defaulted to sequential m
<sb0> ode upon configuration, then PLL[0/1]RESET and
<sb0> GTRXRESET can be asserted after waiting for
<sb0> a minimum of 500 ns after configuration is
<sb0> complete.
sb0 has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
sb0_ has joined #m-labs
sb0_ has quit [Client Quit]
<GitHub122> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/2ee3d5496c54d548ac63e3d6391e738ab7169cd6
<GitHub122> misoc/master 2ee3d54 Sebastien Bourdeauducq: a7gtp: add transceiver initialization code
<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?
<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
X-Scale has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
<_florent_> sb0: yes probably, i was also thinking about that while looking at multi-lane initialization for gth
<_florent_> sb0: between single or multi-lane, phase alignment sequence is different, so yes having it outside would simplify things
kristian1aul has quit [Quit: Reconnecting]
kristianpaul has joined #m-labs
Gurty has quit [Ping timeout: 255 seconds]
<GitHub189> [artiq] jbqubit commented on issue #854: @sbourdeauducq ping https://github.com/m-labs/artiq/issues/854#issuecomment-351077836
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
FabM has quit [Ping timeout: 240 seconds]
FabM has joined #m-labs
<GitHub108> [artiq] gkasprow commented on issue #854: It should look like this:... https://github.com/m-labs/artiq/issues/854#issuecomment-351102602
<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
<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
<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
<rjo> sb0: did anyone check that the M* switches on the sayma boards are in the correct position?
mumptai has joined #m-labs
_whitelogger_ has joined #m-labs
edef has joined #m-labs
rqou has joined #m-labs
_whitelogger has quit [Remote host closed the connection]
ohsix has joined #m-labs
bunnie has joined #m-labs
balrog has quit [*.net *.split]
balrog has joined #m-labs
ashafir has quit [Quit: Connection closed for inactivity]
<GitHub191> [artiq] philipkent opened issue #866: Installing artiq 3.1 https://github.com/m-labs/artiq/issues/866
<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
<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
mumptai has quit [Quit: Verlassend]
X-Scale has quit [Ping timeout: 240 seconds]