7-May-98 Goals and assumptions for the Connectivity Test ----------------------------------------------- The Connectivity Test will be used during two different phases in the life of the system (including L1 and L2 Framework): - as part of initial card commissioning, - as an exercizer, diagnostics, and repair tool to support the running system. As a diagnostic tool for the production system, this test should be able to probe any subset of the full system, in situ, and without moving cards or cables. We might want to locate a problem detected offline or might want to exercize the system during down time. The Connectivity Test should be used for diagnostics together with the Single-Chance System Test. The Connectivity test can help weeding out connection problems before using the Single-Chance System Test to concentrate on functionality and timing issues. The Connectivity Test should be configurable and adaptable to run on a Test-Stand, Test-Rack or on the Production system while concentrating on a single connection, a single card, a single functionality or the whole system. It should use modular ascii configuration files to describe the connections under test. The goal is to cover all possible types of connections, including - cables - connectors - on board traces - part placement - soldering We will need a set of special FPGA configurations (different from the production designs) where all FPGA inputs are readable from VME registers, and all outputs controllable from VME registers, with no connection inside the FPGA between inputs and outputs. The VME Interface FPGA will not (cannot) be programmed differently during the connectivity tests. A "connection" is defined as a source signal controlled by one bit in one register whose output is visible as one bit in some other VME register (probably always on a different FPGA, and typically but not always on a different card). There may be several receivers for one source signal. The Connectivity Test must cover testing the Main Array FPGA outputs of one card connected to the input to the Main Array FPGAs of another card. But it should also includes odd, individual, on card connections between, for example, Main Array FPGAs and the VME interface FPGAs. Whenever possible, "physically close" groups of signals should be handled by neighboring bits within a common register; ideally 16 connections at a time. This will shorten the ascii command files, and the software database needed to keep track of all these connections. It will also give the software an immediate chance, while reading the register receiving the signal that was just modified, to also check that the other 15 neighbouring signals received in the same register haven't changed. This test may assume that all FPGAs are functional, and that basic VME access is operational, as this has been established in previous steps during card commissioning. The syntax for the connection description files is defined in the example below. The Software will parse the source file and build a list of all the connections, including the register for the source signals, the mask of bits driven in parallel, and the corresponding single or multiple receiving register(s). The Connectivity Test Software will keep track, at all time, of the state of all source registers and thus the expected value on the corresponding bits of all receiving registers. During each loop of the Connectivity Test, the software will: - flip the state of one bit of one source register and write the new value - read and verify the state of the correponding bit on all recieving registers connected to the source that was just modified. - check all other bits on the same receiving registers that were just read (even if the source bits for the other received bits came from a different source register) - randomly pick one, or a few, other receiving register and verify that no bit (that was included in the test) has been modified. We will also need to enhance the error reports provided by the program beyond the basic "source bit at address ...didn't make it to receiver at address...". This feature will be added once we have started using the connectivity test and maybe better understand what we are up against, and come up to a good solution. =============================================================================== !------------------------------------------------------------------------------ ! This file holds a list of connections to be tested by the connectivity test ! Comments start with an exclamation mark ("!") anywhere on a line. ! See end of file for more syntax information. !------------------------------------------------------------------------------ ! Revision: 5-May-98 ! This file is a template ! and a reminder for the syntax rules for Connection List Description File Vertical_Master: 0 Vertical_Slave: 1 ! Define a 16-wide connection between one source and multiple recievers ! The first receiver being defined on and individual basis ! More recievers being defined as a range of cards and a range of Chips ! receiving this same source signals on the same register address ! (e.g. Multiple Main Array FPGA on Multiple AONM) Card_Slot: 4 Chip_Address: 0 Register_Address: 0 From_Mask: 0xffff Card_Slot: 5 Chip_Address: 2 Register_Address: 4 To_Mask: 0xffff ! define a single on-card connection between two FPGAs Card_Slot: 4 Chip_Address: 0 Register_Address: 0 From_Mask: 0b,0000,0001 Chip_Address: 17 Register_Address: 2 To_Mask: 0b,1000,0000 ! add one more receiver to a source defined earlier Card_Slot: 4 Chip_Address: 0 Register_Address: 0 From_Mask: 0xffff Card_Slot: 9 Chip_Address: 2 Register_Address: 4 To_Mask: 0xffff Include_File: \users\default\another.cnx ! Line Length template ! 1 2 3 4 5 6 7 8 9 0 1 2 3 !23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012 ! Card_Slot: xx Chip_Address: xx Register_Address: xx Source_Mask: 0xffff ! Card_Slot: xx To_Card_Slot: xx Chip_Address: xx To_Chip_Address: xx Register_Address: xx Receiver_Mask: 0xffff ! Card_Slot: xx Chip_Address: xx Register_Address: xx Receiver_Mask: 0b1234,1234,1234,1234 ! !------------------------------------------------------------------------------ ! 5-MAY-1998 ! Syntax rules: ! ! * Recommended file extension is ".CNX" ! ! - Blank lines are ignored. ! ! - Comments start after an exclamation mark ("!") anywhere on a line. ! ! * Recognized Keywords are (with colon required) ! Vertical_Master: (Vertical Interconnect Master Number; Range: 0 for now) ! Vertical_Slave: (Vertical Interconnect Slave Number; Range 0-1 for now) ! Card_Slot: (VME Card Slot Number; range 1-21) ! Chip_Address: (0=VME Interface; 1-16=Main Array FPGA, 17=Support FPGA) ! Register_Address:(Register ID; i.e. units of 16-bit words; Range 0-511) ! From_Mask: (Mask of source driver for connection) ! To_Mask: (Mask of receiver for a connection) ! Include_File: (Recursive call to external file) ! ! - Keywords are NOT case-sensitive. ! ! - Each Keyword must be followed by one and only one positive integer Value ! (with the exception of the Include_File Keyword using a character string) ! ! - One or more Keyword/Value pair may appear on the same line. ! ! - a Keyword and its matching Value may be separated by any number of spaces, ! and/or Tabs, but must appear on the same line. ! ! - Successive Keyword/Value pairs may be separated by any number of spaces, ! Tabs and/or Carriage_Returns (blank lines), or comments. ! ! * A New source is registered when a From_Mask Keyword is encountered. ! ! * All Register Address Keywords must have been specified before a From_Mask ! Keyword may be specified. ! ! * A New receiver is defined when a To_Mask Keyword is encountered. ! A source must have been specified before a receiver is specified. ! The receiver is associated with the last specified source. ! At least one receiver must be defined after a source has been specified ! (i.e. there must be at least one To_Mask Keyword between successive ! From_Mask Keywords). ! ! * The From_Mask and To_Mask values specify a set of sources controlled by ! a particular register. These values may be specified in Decimal (e.g. 15), ! Hexadecimal (e.g. 0xff), or Binary (.e.g. 0b1111). ! ! * Decimal, Hex, and Binary values may use commas to help readability. ! These commas will be removed during parsing (e.g. 0b,1000,0100,0111,0000). ! No spaces are allowed within any Value string. ! ! * Keyword/Values specified for a previous Register Address remain active ! for subsequent Register Selection until they are explicitly overwritten. ! This includes the case where only the relevant register descriptions need to ! be modified after a From_Mask Keyword and before a To_Mask Keyword ! (e.g. only specify new Chip/Register address when an on-card connection is ! being defined) ! ! * Connections may be defined one signal at a time, in which case the ! From_Mask and To_Mask values must only have one bit set and this can be ! a different bit in each mask. ! ! * Sets of connections may also be defined up to 16 bits at a time, where a ! source register controls 16 signals at a time, in which case ALL receiving ! registers must receive ALL of the SAME 16 signals and in the SAME BIT ORDER. ! ! * Smaller sets of signals driven by any CONTIGUOUS set of source bits in the ! From_Mask and To_Mask may also be defined, but they must follow the same ! rule that all of the same receiving bits must appear in the same contiguous ! bit order, but not necessarily on the same set of bits. ! ! * There is a limitation that no set of single or multiple signals may overlap. ! In particular one may not define a set of (e.g. 16) source signals and their ! receiving register(s), and later define additional receiver(s) for a subset ! (e.g. one bit) of the same source signals. The workaround (when it is ! necessary to circumvent this limitation) is to define ALL the signals ! involved as individual signals with a variable number of receiving ! registers. ! ! * When a From_Mask keyword is encountered, the list of all sources previously ! defined is searched to decide if this is a new source, or if a new receiver ! is about to be defined for a source that has already been partially defined. ! ! * When a To_Mask keyword is encountered, the list of all sources and recievers ! previously defined is searched to verify that this new mask does not overlap ! with any other mask already defined. i.e. a receiver bit cannot also be ! a source bit, and a receiver bit cannot have multiple sources. ! ! * The same register may appear both for a source and a receiver, as long as ! the corresponding bit masks do not overlap. [This may not be useful in ! practice but is allowed as long as it doesn't cost much to implement]. ! ! * There is an advantage in specifying the largest sets of signals wherever ! possible as this gives the test software maximum chance to systematically ! check the widest set of received signals every time one of the driving ! bits has been changed. This is particularly effective for detecting shorts ! among neighboring signals along cables, connectors and between on-card ! traces and chips. Shorts between signals specified in separate source ! registers have to be detected by chance and while doing limited checks ! on random registers that haven't been (shouldn't have been) modified. ! ! - The Include_File Keyword causes a recursive call to read the specified file. ! ! - Full local Keyword/Value context present before the Include_File Keyword ! is still valid after. ! ! - The syntax rules within an included file are the same as described here, ! including the necessity to (re)-specify all Keywords before specifying ! signal source and destination. !------------------------------------------------------------------------------