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
<GitHub36>
artiq/drtio 381e584 Sebastien Bourdeauducq: drtio: handle link restarts at transceiver level
<GitHub36>
[artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/vXFLv
<sb0>
cr1901_modern1, yes, rtio serdes phys, ddr/ddr2/ddr3 phy, dvi_sampler, etc.
<sb0>
and it's not only xilinx plls, most plls are designed to be used that way
<GitHub70>
[artiq] sbourdeauducq pushed 2 new commits to drtio: https://git.io/vXFLK
<GitHub70>
artiq/drtio 02adae7 Sebastien Bourdeauducq: drtio: fix link shutdown
<GitHub70>
artiq/drtio abd1b2a Sebastien Bourdeauducq: drtio: wait longer for remote (bruteforce clock aligner can be slow)
cr1901_modern1 is now known as cr1901_modern
<cr1901_modern>
sb0: Because it's not possible to reduce phase error of a PLL to 0 in practice (static error), and two output PLL clocks go through different dividers (jitter), I didn't know whether alignment of the output clocks could be meaningfully measured. >>
<sb0>
jitter and skew are not specific to PLLs
<cr1901_modern>
Right, but you'd never try to align clocks without one ;). (Would you?)
<cr1901_modern>
I haven't finished reading Xilinx docs on it, but from what I can tell, the "correct" way to use two clocks like this is to add a period constraint on the PLL's input, and Xilinx tools will calculate timing constraints on the output accounting for PLL jitter.
<cr1901_modern>
Thus the PLL's outputs and inputs can be related to each other, and it becomes *possible* that clock domain crossing circuitry isn't needed.
_whitelogger has joined #m-labs
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined #m-labs
kuldeep has quit [Ping timeout: 260 seconds]
<sb0>
jitter in an array of dividers isn't particularly high, you are mostly concerned about skew, which isn't very troublesome either
_whitelogger has joined #m-labs
sandeepkr has joined #m-labs
Zou has joined #m-labs
kuldeep has joined #m-labs
Gurty has quit [Ping timeout: 256 seconds]
mumptai has joined #m-labs
sandeepkr has quit [Remote host closed the connection]
kuldeep has quit [Quit: Leaving]
<sb0>
rjo, I'm not sure about your "multiple DMA engine" idea. interleaving "automatically" is complicated and will require things like sorting the sequences and handling conflicting commands at the same time on the same channel.
<sb0>
also the RTIO core needs 2 system clock cycles per event for underflow/overflow detection
<sb0>
s/overflow/collision etc.
<sb0>
the "multiple channels at the same time" also runs against the "shared channel state BRAM" idea in DRTIO
<rjo>
sb0: it would never be two engines feeding the same channels. the interleaving is the same as it is now. at the phy-side the TSC interleaves events.
<rjo>
sb0: if multiple dma engines (or the kernel api) access the same channel, they always risk out-of-sequence events. that's up to the user.
<sb0>
and btw we don't have 64Gbps net DRAM bandwidth
<rjo>
we don't?
<sb0>
not with the current controller logic
<rjo>
64-epsilon or much less?
<rjo>
i.e. overhead
<sb0>
we can get 63Gbps with tricks like pipelining and bank rolling
<rjo>
then let's write 32.
<sb0>
they are implemented in lasmicon
<sb0>
but doing those correctly with DDR3 require more timing variables like tFAW
<sb0>
which afaict _florent_ is just ignoring
<rjo>
then let's write what we can safely and without too much work achieve.
<sb0>
the current controller has a more stupid access pattern that doesn't push the DRAM to the area where we need to care about those timing constraints
<rjo>
the rtio core can handle 1 event per 2 cycles?
<sb0>
2 system clock cycles
<sb0>
not rtio cycles
<sb0>
that's due to the underflow/guard time logic
<sb0>
it is theoretically pipelinable but I have spent a few weeks hunting concurrency bugs in there and not looking forward to doing it again
<rjo>
ok.
<rjo>
would moving the fifo completely into the rtio CD and transferring the data to/from the sys domain via some slower multi-cycle handshaking CD crossing make sense? then the entire logic overflow/collision/dma engine state BRAM etc could live in the rtio domain.
<sb0>
then either we lose precise exceptions or we make the CPU even slower
<sb0>
and btw DMA would come from the sys domain as well
<sb0>
DDR3 is only specd to run at certain frequencies that do not necessarily play well with the desired RTIO frequencies
<sb0>
well, re. memory bandwidth tFAW isn't too hard to manage with the rolling-bank pattern actually
<sb0>
you can solve it by splitting the address into row/column/bank in a smart way
<sb0>
then you get 99% efficiency for sequential transfers
<sb0>
I wonder how much of the rowhammer bug is caused by misunderstanding of tFAW
<sb0>
rjo, well, 2 system cycles per RTIO event (64-bit timestamp, 16-bit channel, 32-bit data) at 125MHz is still 7Gbps, which is more than the 4Gbps planned for drtio
<sb0>
drtio also needs 2 cycles (lookup channel state in BRAM, write back channel state)
<sb0>
that again can be pipelined by using dual-port RAM but I'm not sure if we need that complexity
kuldeep has joined #m-labs
key2 has joined #m-labs
sandeepkr has joined #m-labs
key2 has quit [Ping timeout: 260 seconds]
sandeepkr has quit [Remote host closed the connection]
kuldeep has quit [Read error: Connection reset by peer]
sb0 has quit [Ping timeout: 252 seconds]
<GitHub61>
[artiq] jordens pushed 4 new commits to phaser2: https://git.io/vXFrf
<GitHub61>
artiq/phaser2 e53d0bc Robert Jordens: dsp: add limits support to SatAddMixin
<GitHub61>
artiq/phaser2 97a5404 Robert Jordens: rtio: auto clear output event data and address...
<GitHub61>
artiq/phaser2 b714137 Robert Jordens: phaser: 150 MHz rtio/jesd clock
<rjo>
sb0: ack the dma on system side stuff. and the rate limiting is also ok. just fyi, sayma events will be much larger (256 bits or even 1024 bits).