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>
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