08:59 <sb0> the design of xilinx transceivers is ugly, as expected

08:59 <sb0> they have a 8b10b encoder inside (which itself is a questionable decision since the fabric does that very well)

09:00 <sb0> and it can be disabled, in which case a sane designer would have made the data port 10 bit wide and ignore the two MSBs when the encoder is enabled

09:01 <sb0> but no, the data port is 8-bit wide, and when the encoder is disabled the two extra bits come from signals with absolutely inane names TXCHARDISPMODE and TXCHARDISPVAL

09:23 <sb0> ...and of course, since they included data encoders in the transceivers, it's a whole can of worms with 64/66 and 64/67

09:23 <sb0> sigh

09:53 <sb0> pff, there is even a PRNG in those things

09:56 <larsc> it's for testing though

09:57 <larsc> verify that your physical connection works without having to know whether your fabric works

10:00 <sb0> yes. but that's again something best left to the fabric.

10:01 <sb0> and if the fabric is broken to the point it cannot implement a PRNG, I'm not sure how you're even supposed to bring up a transceiver

10:06 <larsc> well you might just have made a mistake in connecting all the strange data signals

10:07 <larsc> and a hardware prbs is cheap anyway

10:07 <larsc> like so cheap you don't even notice whether you put it in or not

10:14 <sb0> the hardware PRNG contributes to the strange data signals, which is the very problem I have with it - not resources

10:16 <sb0> pretty sure you could remove at least 75% of the signals and attributes of those things if you killed all the cruft and put all high level operations into the fabric

10:24 <larsc> not going to argue with that some of the things could be moved into fabric, but the prbs in the tranceiver is quite sensible

10:27 <sb0> in what case is it useful exactly?

10:28 <sb0> "The PCI Express specification includes a feature that allows the transmitter on a given link to detect if a receiver is present. The decision if a receiver is present is based on the rise time of TXP/TXN."

10:28 <sb0> ...why?

10:34 <larsc> it's useful for finding out where things are broken when they don't work

10:39 <sb0> in what situation is a transceiver broken in a way that it can clock its internal PRNG but not the fabric that could be used to implement one?

10:41 <larsc> well, its about finding out what is broken and what not

10:42 <larsc> divide and conquer

10:43 <sb0> but this particular division point does not sound relevant to me+

10:44 <larsc> ok

11:54 <sb0> can those things that rely on transceiver data to be random-like be used for DoS attacks?

11:54 <sb0> send packets that cause pathological scrambler behavior

12:03 <zoobab> hi

12:04 <zoobab> just wanted to know if HK was different:

12:04 <zoobab> http://dangerousprototypes.com/blog/2016/05/12/amazon-web-service-beijing-woefully-inadequate-for-international-use/

12:07 <sb0> I don't know about AWS, but HK internet is generally fine (except for accessing some western govt website), unlike on the mainland where it is slow and unreliable (and censored as you know)

12:28 <sb0> urgh, comic sans ms on diagrams in the transceiver user guide

12:29 <sb0> actually, that goes very well with the general aesthetics of those devices

12:44 <sb0> "If RXP and RXN differential traces are accidentally swapped on the PCB, the differential data received by the GTX/GTH transceiver RX are reversed. The GTX/GTH transceiver RX allows inversion to be done on parallel bytes in the PCS after the SIPO to offset reversed polarity on differential pair. Polarity control function uses the RXPOLARITY input, which is driven High from the fabric user interface to invert the polarity"

12:44 <sb0> another cruft signal that could go if they dropped the 8b10b encoder...

12:44 <sb0> *decoder