Objectives:
External interfaces:
The test adapter will supply the input processor with all required voltages. All LVDS input channels will be accessible via 2mm connectors suitable for standard parallel pair cable assemblies. A block of 36 1.5V-I/Os will be fed to a 2mm male header to fit one full FIO block on the JEM0 backplane connector for signal level compatibility tests. The LVDS-chip JTAG pins will be connected (pull-down?? Andrey, check the documents, please) such that the SCAN circuitry is in a clean disabled state. The FPGA JTAG port will be connected to a 2.54mm header field (plus3.3V and GND for the Xchecker) and in parallel to a DB25 connector according to the Xilinx Parallel Cable schematics (series resistors??).
The serial config port will be connected to another DB25 connector. The same connector will act as PC data transmission path. Configuration will use mainly the control pins, data transmission takes place on the data pins. Andrey supply the pin allocation table, please. Series resistors will be required on all output lines that drive the PC port (ie. connections to the printer port status lines).
The 40MHz clock will be received differentially. There is a LVDS out on the TTCVX module. Please check for alternatives. We will require centre tap termination, AC coupled to GND. AC input coupling would be an advantage. Someone check the required bias on the LVDS inputs. Bruno, what LVDS translators have we recently used? spare chip somewhere? the 3.3V output signal needs to be resistor divided to match clock input signal level requirements on the input processor (1.5V,60R). We should supply an alternative crystal clock to allow for standalone debug of the module.
some further remarks:
At least some of the LVDS tracks should have a length comparable to the longest tracks expected on JEM1.
connect signal pairs (3.3V,1.5V) if available (for LVDS internal deserialisation tests) (Since we are not sure whether this is possible we should include pairs on JEM1 too. Might be on jet processor if sufficient spares..)
will we need de-bounce logic on the configuration clock? Recent tests with JEM0 suggest so. Unless anyone has a better scheme, two flip-flops and two XOR will be required to that end. One would seriously consider using a CPLD (XC2C64?) instead since it allows for bit stream serialisation. A two-rail XC2C128 would allow for the use of 1.5VI/O.