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
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
sb0 has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling_ has joined #m-labs
kuldeep has joined #m-labs
sandeepkr has joined #m-labs
<sb0> _florent_, in wishbonebridge, you connect phy.source.ready (aka phy.source.ack) to 1. what happens if data arrives while the FSM is in the WRITE_DATA, READ_DATA or SEND_DATA states?
kuldeep has quit [Ping timeout: 260 seconds]
sandeepkr has quit [Ping timeout: 276 seconds]
kuldeep has joined #m-labs
sandeepkr has joined #m-labs
<sb0> whitequark, your kc705 udev entries are wrong
<sb0> they don't match the actual serial port
sandeepkr has quit [Ping timeout: 240 seconds]
kuldeep has quit [Ping timeout: 276 seconds]
FelixVi has joined #m-labs
fengling_ has quit [Ping timeout: 240 seconds]
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 240 seconds]
<whitequark> sb0: if I remember right, those aren't for the serial port, those are for the programmer
<whitequark> and the serial port cannot actually be matched except via its path
<whitequark> because it doesn't have a serial number
<sb0> openocd doesn't use the /dev entries
<sb0> and it can match itself by serial number
rohitksingh_work has joined #m-labs
<whitequark> yes. those udev entries turned out not to be very useful.
<sb0> _florent_, how are you going to write to the DAC SPI? soft-CPU?
<sb0> soft CPU and bitbang may be a good option, since I think we'll be doing that for a PLL already
<sb0> I'm still hesistating over that option; FSMs would work very well there
<sb0> but without a CPU changing things like the PLL phase requires recompiling the bitstream
<sb0> we could have hacks like BRAM rewriting, but they're a bit dirty
<sb0> well, it does seem to still work for the 7-series
<sb0> may not be that bad
<sb0> we can actually do this: wishbone bus, etherbone/uartbridge as master, some init FSM that pulls transactions from a block RAM at startup, SPI core, I2C core
<sb0> we can either use data2mem or etherbone/uartbridge for rapid SPI/I2C iterations
<sb0> is there a decent I2C core?
fengling_ has joined #m-labs
FelixVi has quit [Remote host closed the connection]
FelixVi has joined #m-labs
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
sandeepkr has quit [Max SendQ exceeded]
kuldeep has quit [Max SendQ exceeded]
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
kuldeep has quit [Max SendQ exceeded]
sandeepkr has quit [Max SendQ exceeded]
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
sandeepkr has quit [Ping timeout: 258 seconds]
kuldeep has quit [Ping timeout: 258 seconds]
mumptai has joined #m-labs
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
<sb0> _florent_, is there any disadvantage to keeping RXUSERRDY and TXUSERRDY at 1 at all times?
<sb0> seems you're supposed to drive it high only after clocks are stable...
FelixVi has quit [Remote host closed the connection]
<_florent_> sb0: for the DAC SPI, for now I'm controlling it with etherbone and python scripts for prototyping, but we can do something else for the demo
<sb0> _florent_, ok, good, I imagine the final design with just have a block RAM with the init transactions in it.
<sb0> unless we need anything else than blind writes.
<_florent_> sb0: if we only need to do a configuration at startup yes
<_florent_> sb0: for RXUSERRDY and TXUSERRDY always at 1 I haven't tested
<sb0> _florent_, isn't rxphaligndone an asynchronous signal that needs double latching before being fed into the FSM?
<_florent_> sb0: it's asynchronous yes, for SATA I'm double latching it in trx.py IIRC
<sb0> ah, correct
<sb0> _florent_, if the CPLL is already locked when the FSM enters this state https://github.com/enjoy-digital/litesata/blob/master/litesata/phy/k7/crg.py#L215 then it will stay in that state forever and never complete init.
<sb0> no?
<sb0> why do you need two states anyway? can't you combine RESET_GTX and WAIT_CPLL states?
<sb0> GTRXRESET does not unlock the CPLL as far as I can tell
<sb0> or, if you don't combine the states, at least remove the ~self.cplllock condition in RESET_GTX
<sb0> _florent_, rxdlyreset is asynchronous and doesn't need a PulseSynchronizer (just deglitching maybe)
kuldeep has quit [Quit: Leaving]
kuldeep has joined #m-labs
fengling_ is now known as fengling
mumptai has quit [Remote host closed the connection]
fengling has quit [Ping timeout: 240 seconds]
<rjo> cr1901_modern: the m-labs jesd204b and phaser repos.
<_florent_> sb0: thanks for the review, I'll look at that
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 260 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
rohitksingh1 has quit [Ping timeout: 250 seconds]
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 252 seconds]
<GitHub64> [artiq] jordens pushed 2 new commits to master: https://git.io/vKXOx
<GitHub64> artiq/master 06bb1a2 Robert Jordens: doc/installing_from_source: update/fix (closes #516)
<GitHub64> artiq/master ecda947 Robert Jordens: doc/management_system: point out check_pause() (closes #522)
rohitksingh1 has quit [Ping timeout: 244 seconds]
<bb-m-labs> build #562 of artiq-kc705-nist_clock is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-kc705-nist_clock/builds/562
rohitksingh has joined #m-labs
<bb-m-labs> build #277 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/277
<sb0> xilinx gtxs contain a lot of cruft, but they don't support aligning rxoutclk to commas, because that would be useful
<bb-m-labs> build #836 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/836
<sb0> hmm or does it?
<larsc> align like how?
<larsc> the data comes out in paralell
<sb0> RXSLIDE_MODE=PMA may do what I want
<sb0> larsc, yes, but the 20 output bits are unaligned
<sb0> you can do comma detection and realign afterwards, but this has variable latency
<sb0> changing the RXOUTCLK phase so that the comma stays at the same position fixes the latency
<sb0> "If RXOUTCLK is sourcing from the RX PMA, its phase might be changed. This mode provides minimum variation of latency compared to PCS mode."
<sb0> "might" "minimum variation" pffff
<sb0> wtf
sandeepkr has quit [Quit: Leaving]
<sb0> anyway
<sb0> "When RX buffer bypass is used, RXSLIDE_MODE cannot be set to AUTO or PMA"
<sb0> what a piece of garbag
<sb0> e
sandeepkr has joined #m-labs
<sb0> I suppose I can repeatedly reset it until it finally gives out the required phase
<larsc> do you do manual comma align?
fengling has joined #m-labs
<sb0> yes
<larsc> ok
<sb0> I'm actually not using anything from the transceiver except the CDR and SIPO
<sb0> the rest shouldn't be there anyway
<sb0> the built-in comma aligner has variable and as far as I can tell unknown latency
<larsc> in the end you always have variable latency
<sb0> why?
<larsc> clock jitter e.g.
<sb0> that's very small
fengling has quit [Ping timeout: 240 seconds]
<larsc> that's what I meant
<larsc> if you know the bounds you can work with it
<sb0> the comma aligner can easily change the latency by several nanoseconds
<sb0> clock jitter is << 1 ns
<larsc> so what you want to do know is to keep reseting the clock cicruit until your parallel output is aligned?
<larsc> so you know the phase relationship?
<sb0> essentially, the problem is RXOUTCLK is produced from the CDR clock output by a divide-by-20 circuit
<sb0> and at each RXOUTCLK pulse, the latest 20 sampled bits are sent downstream to the comma aligner
<sb0> (simplifying things a bit here, but that's the root of the issue)
<sb0> if you want to time something precisely when e.g. the first bit of the comma arrives, it's a royal pain, if not impossible due to the switching limits of the FPGA: you have to multiply RXOUTCLK by 20 again and then send the signal to the appropriate 20x clock pulse, depending where the comma was found
<sb0> if you were able to align RXOUTCLK with the comma, it would be trivial
<sb0> but you have no control over the divider.
<sb0> (and btw, it seems the built-in comma aligner doesn't tell you where the comma is found - but you can just ignore it and roll your own aligner)
<sb0> well, not impossible - you can use OSERDES and ODELAY to get many nanoseconds of range and 39ps resolution - but painful for sure
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
<rjo> sb0: the WR guys must have solved that. with fabric or using the transcievers?
<sb0> they do latency measurements and compensation
<sb0> same with DDMTD
<rjo> oh. so their transciever config is not deterministic latency at all.
<sb0> well actually there's a problem here, since the two receivers may take different latencies
<whitequark> rjo: calling the core log "a powerful debugging tool" is overstatement of the decade.
<sb0> maybe they just live with it
<rjo> sb0: yes. referring to the s6 transievers.
<sb0> even if you take two k7 transceivers: there are two receivers, and they may do comma alignment differently between power-ups
<whitequark> frankly, I'm not especially satisfied with the state of debugging in ARTIQ
<whitequark> fwiw we do not need a lot of code to get integrated debugging of kernel mode code
<rjo> whitequark: yeah. but i can rescue the statement by saying that the sum of the tools is powerful. which it is. a hardware post-mortem LA is veyr powerful.
<whitequark> there's lldb, which already comes with integrated Python, and can also be imported as a Python module with no additional headache
<rjo> whitequark: absolutely. on both counts.
<whitequark> and
<whitequark> *and I already emit lots of debug information for backtraces. adding the support for reading values to that is like a hour of work.
<whitequark> what's not especially easy is integrating it all to get a compelling end-user experience.
<rjo> and we can port gdbserver to the comms cpu and copy a lot of machinery from openocd.
<rjo> "can". always.
<whitequark> wait, where does openocd come from here?
<whitequark> lldb can directly use gdbservers over network
<rjo> the linkage of gdbserver to the kernel cpu.
<whitequark> do you mean driving the JTAG of kernel CPU from the comms CPU?
<rjo> yes.
<whitequark> that's a really roundabout way of doing it. just give me an interrupt I can trigger. that's enough.
<rjo> or by traps.
<rjo> yes.
<rjo> anyway. kelly is thinking of the python/host side mostly. which is fine and should be doable as well.
<whitequark> yeah, I don't think m-labs should be doing a lot of work on that
<whitequark> it seems hard to believe that Python doesn't have such tooling already
<sb0> oh actually we can get the built-in comma detector state, by reading DRP registers
<rjo> sb0: are you saying that to align, they are slipping the data (bit-wise) but leave the RXOUTCLK phase (bit-wise)?
<rjo> they = gtx
<sb0> yes, looks like it, and implement some sort of compensation based on where the comma was found
<sb0> (for white rabbit)
<rjo> whitequark: it does but it needs (a) some looking into and hints/paving the way how to do it nicely and (b) how to do it with an experiment running on the master/scheduler/worker
<whitequark> right.
<rjo> sb0: WR may just compensate for the sum of all latencies as long as it is symmetric (rx/tx !?) and constant.
key2 has joined #m-labs
<sb0> this latency is not symmetric, but it can be known at each end
<sb0> it's constant after startup but not between transceiver restarts
<sb0> ...if the distribution is balanced enough, we can just keep resetting the transceiver until it does the right thing
<sb0> there are 20 possible options, resetting is fast, and this needs to be done only once at link startup
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<sb0> yup, resetting the transceiver changes the phase
<sb0> let me collect a bunch of data
<sb0> yes, the phase is randomly distributed
<sb0> but of course, the transceiver doesn't restart correctly in 2.2% of the cases
<sb0> ah nah, just need to give it some time.
<sb0> 10k restarts, all correct.
<sb0> whitequark, does the si5324 recover on its own after you send it a broken clock for a while, or do you need to reset it after the clock becomes valid?
<sb0> hmm, there is some variation in the frequency of the output patterns
<rjo> same pattern. different alignment.
<rjo> and i think in 8b10b this is an invalid pattern.
<sb0> yes, but it matches what I'm transmitting and it has enough transitions for the cdr
<sb0> and yes, those are the expected 20 different alignments
<sb0> what is less expected is some alignments are less frequent than others, so it may take a lot of transceiver restarts to hit those
<sb0> (this list is the 20 alignments obtained by restarting the receiver 10k times, and their frequency)
<sb0> well, with this brute-force technique, it should still take less than one second to establish the link
<sb0> as opposed to a couple milliseconds had xilinx not fucked things up for once
<sb0> alternative is do what WR does, use the comma alignment data and compute the latency. it's more complicated and potentially less precise.
rohitksingh has quit [Quit: Leaving.]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
mumptai has joined #m-labs
fengling has joined #m-labs
<key2> has someone jtag'd a xilinx fpga with openocd in here ?
fengling has quit [Ping timeout: 240 seconds]
<whitequark> sb0: it recovers on its own
kuldeep has quit [Ping timeout: 240 seconds]
sandeepkr has quit [Ping timeout: 240 seconds]
sandeepkr_ has joined #m-labs
kuldeep has joined #m-labs
sandeepkr__ has joined #m-labs
sandeepkr_ has quit [Read error: No route to host]
sandeepkr_ has joined #m-labs
kuldeep has quit [Ping timeout: 264 seconds]
sandeepkr__ has quit [Ping timeout: 250 seconds]
kuldeep has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
sandeepkr_ has quit [Ping timeout: 240 seconds]
kuldeep_ has joined #m-labs
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep_ is now known as kuldeep
<mumptai> i'd like to set signals synchronously in a fsm state, is there a way to do this without defining an extra signal and term in the comb list?
_whitelogger has joined #m-labs
kuldeep has quit [Ping timeout: 258 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
whitequark has joined #m-labs
mumptai has quit [Quit: Verlassend]
fengling has joined #m-labs
kuldeep has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
sandeepkr has joined #m-labs
fengling has joined #m-labs
flaviusb has quit [Ping timeout: 250 seconds]
fengling has quit [Ping timeout: 240 seconds]