<azonenberg>
at this point i have the 1G and 10G running, with auto failover
<azonenberg>
(not multihoming, it has one IP and one mac - it uses the fastest interface with a layer 2 link)
<azonenberg>
Then I have the DDR3 controller IP from xilinx reporting successful calibration but i have not tried talking to it
<azonenberg>
The 16x 5 Gsps / 1.25 Gbps logic analyzer channels are capturing data and feeding the 80 Gbps of samples into 16 separate RLE compression engines, which should reduce the bandwidth enough that it will fit into the capacity of the DDR3
<azonenberg>
But i have yet to write the glue between the DRAM and the LA. That's going to be this week's evening project after work
<azonenberg>
after spending the weekend on ethernet bringup which took a lot longer than anticipated
<azonenberg>
lots of code written for ultrascale+ needed porting and optimization to work on kintex7
<azonenberg>
much slower logic necessitating more pipelining, plus the ultrascale+ SERDES is a lot nicer to work with than the 7 series wrt 64/66b
massi has joined #scopehal
bvernoux has joined #scopehal
GyrosGeier has quit [Ping timeout: 256 seconds]
GyrosGeier has joined #scopehal
massi has quit [Remote host closed the connection]
<Degi>
Does SATA use 64/66?
<azonenberg>
Degi: sata is 8b10b
<azonenberg>
64/66 is afaik only used by 10g ethernet
<azonenberg>
(and some proprietary stuff i've worked on)
<Degi>
I see
<azonenberg>
pcie went from 8b10b to 128/130
<azonenberg>
i think gen 1/2 are 8b10b and gen 3 and up are 128/130
<azonenberg>
which is a similar LFSR+header scheme as 64/66, and likely inspired by it
<azonenberg>
but doubles the data block size
<azonenberg>
then Interlaken uses 64/67 which i know less about as i've never had to touch it
<Degi>
I guess half the overhead yeah
<azonenberg>
fundamentally, 8b10b is deterministic and codebook based
<azonenberg>
while most of the more modern ones are probabilistic and use a LFSR scrambler where a lock is not guaranteed, but you can choose the state machine to make the probability of a false lock vanishingly small
<Degi>
Like it can lock wrongly and then it gives you garbage while saying its locked?
<azonenberg>
Yes. basically, with 8b10b there are a known number of possible code words
<azonenberg>
and as soon as you see a comma in a K28.5 you know the sync instantly
<azonenberg>
that pattern cannot occur anywhere else
<azonenberg>
look for a few more just to rule out single bit errors and you're locked
<azonenberg>
With 64/66, the sync header can be 01 or 10 and the message payload can be arbitrary values xored with a lfsr
<azonenberg>
so if you see 11 or 00 more than once or twice (i.e. more than can be explained by random bit errors) you know you are not locked
<Degi>
Oh
<azonenberg>
But it's always possible that a pathological data stream could align exactly with your LFSR and result in scrambled bit patterns of 01 or 10 in packet content at a precise offset, causing a false lock
<azonenberg>
but with a 57 bit scrambler seed the odds of this happening (especially given the known idle sequence between packets) are extremely low
<azonenberg>
and the longer your window for checking for a lock is, the lower the probability is
<azonenberg>
roughly speaking if your data is not deliberately correlated to be pathological for the specific scrambler seed in use, and aligned cycle accurate to it
<azonenberg>
if you have a 128 cycle lock window you have a 2^-128 probability of a false lock
<azonenberg>
so while it's not impossible, the probability is suffciently low as to not be worth worrying about
<Degi>
Hmm I see
<azonenberg>
that was really the big jump in coding from 8b10b to 64b66b
<azonenberg>
the realization that you do not need fully deterministic lock behavior
<azonenberg>
as long as you can make the probability of a false lock lower than the probability of other failures in the system
<azonenberg>
which allows you to get much higher coding efficiency with less overhea