<whitequark>
most tests reliably pass with smoltcp
<whitequark>
there are a few bugs left.
<whitequark>
1) when the peers simultaneously issue FIN to each other with data in the segment, this causes a crash
<whitequark>
2) for some utterly inexplicable reason the buffers are capped at 1K
<whitequark>
3) test_i2c_switch fails (unrelated to smoltcp)
<whitequark>
4) test_clock_generator_loopback fails (likely due to the tracing code, and will go away with network tracing disabled)
<whitequark>
actually, no, it is mysteriuos as to why it fails
<whitequark>
5) test_pulse_rate_dds fails for some utterly inexplicable reason, which manifests as the RunFinished message not arriving, despite smoltcp logs indicating the host ACKed it
cr1901_modern has quit [Ping timeout: 248 seconds]
<key2>
how would you describe what J/K are in this case ?
<whitequark>
j=green1+orange0, k=green0+orange1
<whitequark>
arbitrarily
<whitequark>
it doesn't matter
sandeepkr has joined #m-labs
<key2>
ok, after that i'll get a set of J/K
<key2>
is it encoded at that point ?
<cr1901_modern>
I'm guessing it's self-clocking?
<key2>
meaning
<cr1901_modern>
The clock is sent with the data stream/not all transitions are meaningful data
<cr1901_modern>
See Differential Manchester for an example
sb0 has joined #m-labs
<key2>
ha
<key2>
cr1901_modern: that could explain why there is never more than 3 close pic next to eachother
<key2>
(and usually only 2)
sandeepkr_ has joined #m-labs
sandeepkr has quit [Ping timeout: 240 seconds]
<cr1901_modern>
key2: This is just a guess. In high speed signals, it doesn't typically make sense to send the clock on a separate line from the data (HDMI being an exception)
<key2>
pcie being anothre
<cr1901_modern>
And HDMI gets away w/ it by running the clock 10 times slower than the actual "bit time"
<key2>
yeah i got that
<key2>
how would you recover the clock in there ?
<cr1901_modern>
in HDMI?
<cr1901_modern>
Using a PLL as a clock multiplier
<cr1901_modern>
If you mean your mystery signal, I'm not 100% sure :/
<cr1901_modern>
same reason as HDMI I guess (but the data stream's recovered clock takes priority)?
<larsc>
cr1901_modern: so TX and RX can use the same reference
<larsc>
otherwise your TX and RX lanes might run at slightly different rates
<larsc>
or you'd need a jitter cleaner
<larsc>
to clean up the recovered RX signal
<cr1901_modern>
larsc: Isn't that what a PLL is for? I don't see why TX/RX need the same exact rate if both receiving ends have PLLs (I have not played with PCIe)
<larsc>
and I guess it might be cheaper to just use the 100MHz reference rather than putting a low ppm crystal on each board
<cr1901_modern>
Well, if the ref clk is sent, then what's the point of embedding the clk?
<larsc>
better data dependent jitter tolerance
<cr1901_modern>
Is "data dependent jitter tolerance" due to "missing transitions inherent in a self-clocked signal"?
zumbi has quit [Ping timeout: 245 seconds]
* cr1901_modern
confesses he isn't sure what you mean, if not
zumbi has joined #m-labs
<larsc>
high-speed transmission lines typically have a frequency dependend response
<larsc>
e.g. if you send 00000111111 or 0101010101 will cause different behaviour
<larsc>
including different phase delays
<larsc>
so your bits arrive sometime earlier, sometimes later, depending on what has been sent so far
<larsc>
if you just sample based on an external clock your margins get smaller
<larsc>
if your clock is defined by the transistions in the data you can realign
<larsc>
I guess this even applies to all types of jitter, not just DDJ
key2 has quit [Ping timeout: 260 seconds]
<cr1901_modern>
It's been a while since I worked with transmission lines. To save mental bandwidth I usually use the approximation "transmission lines ruin the amplitude of your signal/cause reflections"
<cr1901_modern>
Looks like that fails for digital signals
<larsc>
the problem with digital data is that your edges are supposed to be straight up or down
<larsc>
which they obviously are not since the bandwidth of the transmission line limits rise and fall time
<larsc>
this is one of the contributing factors to DDJ
<larsc>
this is called precursor and postcursor. a symbol affects the symbols around itself
* cr1901_modern
adds to his "clock recovery todo"
<cr1901_modern>
I'm not sure how one can using the optional 100MHz clk to their advantage since it's really important to monitor transitions in the incoming RX signal
<larsc>
it's for the TX PLL
<larsc>
and for RX just as an initial reference
<larsc>
to get the RX roughly into the region of the RX clock
<cr1901_modern>
I see. And it's optional, but in practice PCIe cards rely on 100MHz clock existing to power the TX multiplier?
<larsc>
you need some kind of reference
<larsc>
what is optional is using the 100MHz as the reference
<larsc>
e.g. you can use your own crystal if you want to
<larsc>
but there is a tight specification on the +-ppms the crystal can have
<cr1901_modern>
Oh! The 100MHz clk is always provided lol. Up to device to use it. You don't want to know what I was thinking :P.
<cr1901_modern>
larsc: Last q... what did you mean by "same reference"? And isn't a PLL a jitter cleaner :)?
<larsc>
autocorrelation is a special case of crosscorrelation, so strictly speaking you are right ;)
<cr1901_modern>
:)
<cr1901_modern>
(I thought you meant to "split up each packet" and cross-correlate w/ each other. But autocorrelating a single signal of *multiple* packets will give the same information)
<GitHub31>
[artiq] jordens commented on issue #645: works fine in master https://git.io/vMiE6
rohitksingh has quit [Quit: Leaving.]
<cr1901_modern>
sb0: Responded to email. I know the perfect person, and they are interested in meeting you as well after I told them about your work
mumptai has joined #m-labs
<GitHub99>
[artiq] vontell commented on issue #656: Some of the tricks you have mentioned work great. I notice that tuples have no accessors on them (for instance, `my_tuple[0]` will throw an exception `type is not iterable`). Is this due to the fact that experiments must not have a runtime dispatch, and tuples are capable of holding values of different types? https://git.io/vMixH
<GitHub31>
[artiq] vontell commented on issue #656: Also, I believe that warnings to the developers during compilation (i.e. `Note that append on the array type (line ###) is not supported within kernels!`) would be extremely helpful. https://git.io/vMipZ
<GitHub86>
[artiq] vontell commented on issue #656: Also, I believe that warnings to the developers during compilation (i.e. `Note that append on the array type (line ###) is not supported within kernels!`) would be extremely helpful. https://git.io/vMipZ
key2 has quit [Ping timeout: 260 seconds]
mumptai has quit [Remote host closed the connection]