GOL TEST: FPGA Draft Specification Paulo Moreira, CERN - 27/06/1999 General: From the functional view point the FPGA should implement the following functions: i) Program the GOL IC internal configuration register. This function is required to setup different operation and test modes of the GOL IC. ii) Generate fixed 20 bit data patterns. These patterns will be used during the first phase of the electrical testing and will be designed to catch potential problems in the high speed parallel-to-serial converter (serializer). iii) Generate valid G-link data frames using both fixed and "dynamic" data patterns. This function will allow data transmission tests to be performed using the CN G-link receiver. In this mode several different types of data patterns must be generated for transmission. These include: fixed patterns, cyclic data sequences and pseudo random sequences all with the proper G-link frame structure. iv) Generate valid G-bit Ethernet data frames. The implementation of this functionality (if necessary) can be delayed until the IC is successfully tested together with the CN G-link receiver. Testing G-bit Ethernet patterns will require the development of a G-bit Ethernet receiver. iv) PLL lock monitoring: the FPGA should monitor the GOL IC 40MHz clock signal and detect if the PLL is locked. More over, for use in the SEU radiation tests, the FPGA should count how many times lock has been lost. Electrically, the FPGA should be able to interface with the 2.5V I/O of the GOL IC and be capable of working with a 60MHz master clock producing data patters at a rate of 60MWords/s. FPGA Functional Specification: i) Configuration Register Programming: Internally the GOL IC contains a configuration register that is used to setup different operation and test modes of the IC. That register is a 16 bit wide register that is programmed serially using the signals "ProgDat", "ProgLoad" and "ProgClk". ProgDat is the serial data input, ProgClk is the serial shift-in clock input and ProgLoad is a strobe input signal that is used to latch the shifted-in data into the configuration register. All these signals are inputs and need to be generated by the FPGA. To execute this function the FPGA should have the following input and output signals: - StartProg (input): this signal starts the serial programming of the configuration register. For testing flexibility, this must be the only signal activating the configuration register programming function. That is, the FPGA reset signal must NOT activate this function; - Data signals (inputs): Signal Name Shift-In Default State Function order (GOL IC internal) ---------------------------------------------------------------------- NC 1 - - En120 2 0 (disabled) Enable Out120MHz En60 3 1 (enabled) Enable Out60MHz En40 4 1 (enabled) Enable Out40MHz STM1 5 0 (TestOut = "1") TestOut select STM0 6 0 ~S4 7 1 (Driving strength 50ohm driver "strength" ~S3 8 1 = "1/2") ~S2 9 0 ~S1 10 0 iSel4 11 0 (2.5uA) Charge pump current iSel3 12 1 iSel2 13 0 iSel1 14 0 iSel0 15 0 EnReSynch 16 0 (disabled) Re-Synchroniser ---------------------------------------------------------------------- These signals should be read from a set of switches after the StartProg signal is sensed as active. After being read by the FPGA they should be shifted-in into the GOL IC in the order indicated on the table (that is NC first and EnReSynch last). ProgDat (output): This signal carries the serial data that is to be sent to the IC. ProgClk (output): This is the shift in clock. Sixteen clock pulses are necessary to shift-in the sixteen data bits. ProgLoad (output): A single pulse in this line is used to latch the data into the GOL IC configuration register after the data has been shifted-in. (The reason for this signal is that, it allows to change any bit in the configuration register without disturbing any of the other bits during normal operation.) Notes: - Preferably all the signals related with this function should be quiet during normal operation. - Serial programming can be done at low frequencies, for example, (60/16)MHz or (60/32MHz) or even lower frequencies. - Signal NC is not a real signal. It has been included in the table because it will be simpler to design a 16 bit shift register than a 15 bit one. - If the StartProg signal is to be generated by a push-button, the FPGA must contain some debouncing logic on this signal input. ii) Fixed 20-bit Data Patterns Fixed data patterns are necessary for the most basic electrical testes of the serializer. Due to the serializer's architecture, some patterns will be more critical than others and/or more useful for diagnosis. Since these patterns will be used for electrical tests only, they need not comply with the G-link frame structure or with the 8B/10B coding scheme used in the G-bit Ethernet standard. The FPGA should contain the following input signals: FPS<2:0>, (Fixed Pattern Select) that will set the data outputs D<19:0> to one of the following patterns: FPS<2:0> value (HEX) D<19:0> (HEX) Useful for: -------------------------------------------------------------------------------- 0 55555 Estimate the internal clock duty cycle 1 AAAAA 2 300C0 Verify correct shift-register load 3 99A66 signal timing 4 54D53 Identify out of order shit-out 5 66666 Verify 2-to-1 word mux 6 63D1F 7 2761D -------------------------------------------------------------------------------- iii) G-link Data Frames: Valid G-link data frames will be used to do data transmission tests using the CN G-link receiver. This type of data frames will be used for generic data transmission tests and single event upset tests. In this mode several different types of data patterns must be generated for transmission. These include: fixed patterns, cyclic data sequences and pseudo random sequences all with the proper G-link data frame structure. In this case the FPGA must feed to the GOL IC data frames formated by the G-link Conditional Inversion with Master Transition (CIMT) encoding algorithm. That is, the FPGA should: - Conditionally invert the data depending on the data disparity history; - Inset the appropriate C-Field (containing the master transition); - Control the use of the flag bit (this point needs clarification). note: The frame needs to be shifted out in the proper order. The GOL IC shifts out the data bits in the following order: D<0> first to D<19> last. Since the transmission between the GOL IC and the G-link chip-set is going to be simplex, a method is required to correctly initialise the link or to recover from a synchronisation loss being it at the transmitter or at the receiver side. If the system is going to be strictly simplex (that is there is no return path between the receiver and the transmitter test card) them: - Upon a RESET the FPGA should start issuing the fill frame FF0 with C-Field=3 that is, FF03 (Hex). - After the FPGA detects that the GOL IC has achieved lock (see section v) it should continue to generate the pattern FF03 (Hex) for another xx? milliseconds (need to find-out how long this time really is). This will allow the receiver PLL to acquire lock. - After the initialisation phase is complete the FPGA should start sending data. - If the FPGA has detected that the GOL IC has lost lock during normal operation it should restart the initialisation process. If a return path can be implemented between the receiver and the transmitter test card them the startup procedure could be initiated with basis on the receiver status. This would imply monitoring the receiver operation and issue a start initialisation procedure signal to the transmitter board at any time that the receiver requires it. Data patterns: Ideally, the data patterns to be transmitted should "excite" any pathological conditions in the link. Also, the transmitted patterns should allow for easy monitoring. A realistic test will require the implementation of a long run length pseudo random data generator to cover all the possible situations. However, this might be incompatible with the present CN setup. The choice of the data patterns to be transmitted will depend thus on the previous experience in CN and on how easy it will be to adapt the present receiver setup to support the transmission of new data patterns. Three to four signal lines will be require to select the data stream to be generated. iv) G-bit Ethernet data frames: To be defined (if required) at a later time after the GOL IC is successfully tested with CN G-link receiver. v) PLL lock monitoring: The FPGA should control the lock status of the GOL IC. Additionally, for the single event upset tests it will be important that the FPGA counts how many times the PLL has become unlock during normal operation. The proposed way to monitor PLL lock is the following: The falling edge of the reference clock (ClockRef) will be used to sample the 40MHz clock produced by the GOL IC (Out40MHz). If a high level ("1") is sampled the two clocks are assumed to be in lock, otherwise the clocks are assumed to be unlocked. This simple scheme can give wrong information about the lock/unlock status of the GOL IC for example during lock acquisition or during SEU tests. To avoid possible false lock/unlock detection situations the following algorithm could be used: Lets call the sampled value of Out40MHz signal by the falling edge of the ClockRef signal Samp40MHz. Upon a RESET the unlock counter is reset and the lock monitoring state machine enters a "Wait-For-Lock" (WFL) state. In the WFL state the LockDetect signal is made "0" and the state machine remains in this state until 2^10 consecutive Samp40MHz="1" are detected. When that condition is detected the state machine moves to the "Locked" (LKD) state. In the LKD state the LockDetect signal is asserted and the state machine remains in this state until the condition Samp40MHz="0" occurs, in which case, the state machine moves to the state "Confirm Unlock" (CULK). In the CULK state the LockDetect signal is still asserted. In this state, the consecutive number of Samp40MHz="1" events and the number (consecutive or not) of Samp40MHz="0" events are counted. If the count of Samp40MHz="0" events reaches 2^7 then the PLL is considered unlock, the unlock counter incremented by one and the state machine moves to the WFL state. Otherwise, if the number of consecutive Samp40MHz="1" events reaches 2^7 the PLL is considered locked and the state machine moves back to LKD state. (We could also consider to increase the unlock counter in this case. I wonder however if we should do it since for example, a SEU could generate extra jitter which could be detect of loss of lock.)