LVDS line mapping

[kaolpr]

• Make LVDS net names follow DIOT naming
• Current LVDS1 line is mapped to DIOT MGT_Rx (CPCIs PE_Rx). This is incompatible with DIOT Controller, where non-MGT connection was foreseen only for PE_Tx:
  

[kaolpr]

This can be solved by removing questionable object from #11 and using those lines as LVDS1.

[gkasprow]

USB line on the CPCIS backplane is used for LVDS as well. In case of the adapter, the only reason to have such assembly option is when we have FPGA and want to use MGT instead.

[kaolpr]

But I don't want to have assembly option on the adapter. The point is that current design is incompatible with DIOT Controller. LVDS1 is routed to DIOT Controller's MGTx_RX that has no assembly variant on controller that would enable driving this line with IO pins.

[gkasprow]

DIOT controller has an assembly variant - with LVDS only or with one LVDS replaced with MGT.

[kaolpr]

Yes, but for TX only:

Note that adapter uses "PE_RX00" as potentially bidirectional LVDS line:

[gkasprow]

Once we switch the controller to LVDS mode, it can be bi-dir.

[kaolpr]

You mean MGT RX line can be treated as IO? Then what for is an assembly variant for TX?

[gkasprow]

Let's start from the beginning. When we started the unification of SInara and DIOT, one issue arrived.
The backplane has only 18 fabrics (original PCIe, USB, Ethernet, SATA, and clock lines). For Sinara we need 16 LVDS + one clock.
For DIOT we need MGT in addition. They are not fixed about LVDS. To fulfill both requirements we decided to make two dedicated high-speed, 10Gbit capable lanes to support MGT, and in the case of DIOT use it for MGT, but in the case of Sinara use one of them for LVDS, eliminating the use of MGT.
But since we have a dedicated chassis and backplane maybe it makes sense to add one pair to support both MGT and LVDS without the need of using assembly variants. We have one free diff pair in the P1 peripheral board connector (pins E2, F2). We also have 8 free pairs on the P2 controller connector (J33A, J33B).

[gkasprow]

with such an approach, we would use the Sinara assembly variant now, but later on, get rid of variants once the universal backplane is done.

[gkasprow]

btw, it looks like Schroff (nVent) will also offer DIOT crates.

[kaolpr]

btw, it looks like Schroff (nVent) will also offer DIOT crates.

Wow, do you have any official information?

[kaolpr]

Coming back to LVDS lines. Take a look at the table:

DIOT SB Slot harness	DIOT SB	DIOT BKPL	Adapter
LVDS 0	USB3_TX	DIFF_0	LVDS 8
LVDS 1	USB3_RX	DIFF_1	LVDS 9
LVDS 2	USB2	DIFF_2	Pads?? #11
LVDS 3	SATA_TX	DIFF_3	LVDS 10
LVDS 4	SATA_RX	DIFF_4	LVDS 11
LVDS 5	PE_TX01	DIFF_5	LVDS 2
LVDS 6	PE_RX01	DIFF_6	LVDS 3
LVDS 7	PE_TX02	DIFF_7	LVDS 4
LVDS 8	PE_RX02	DIFF_8	LVDS 5
LVDS 9	PE_TX03	DIFF_9	LVDS 6
LVDS 10	PE_RX03	DIFF_10	LVDS 7
LVDS 11	ETH_A	DIFF_11	LVDS 12
LVDS 12	ETH_B	DIFF_12	LVDS 13
LVDS 13	ETH_C	DIFF_13	LVDS 14
LVDS 14	ETH_D	DIFF_14	LVDS 15
LVDS 15	PE_TX00 (MGT variant)	MGT_Tx	LVDS 0
No LVDS!!	PE_RX00	MGT_Rx	LVDS 1

LVDS 1 on adapter has no way to be connected to normal IO on DIOT controller. It can only be connected to MGT RX. In current configuration, when using DIOT controller, we won't have 16 LVDS lines.

At the same time, one line (DIFF_2 in DIOT backplane nomenclature) is wasted for some questionable pads...

[gkasprow]

Wow, do you have any official information?

they delivered prototypes to CERN

[gkasprow]

OK, so it seems that LVDS1 must be connected to these pads. No idea why Michal connected it in such a way.