1. Collection of information about the Hardware and firmware upload within the PSB rf system A. Blas FMC WG 20/01/2010 1 Topic of the meeting: make sure that the hardware of the PSB rf daughter cards is compatible with the envisaged exchange of hardware information within the crate an within the global control structure the envisaged firmware download tree Participants: Pablo Alvarez-Sanchez, Maria Elena Angoletta, Alfred Blas, Petri Leinonen, John Molendijk, Jorge Sanchez-Quesada, Javier Serrano, Erik Van Der Bij

2. Collection of information about the Hardware and firmware upload within the PSB rf system A. Blas FMC WG 20/01/2010 2 Mezzanine boards designers: 4 ch. ADC: Jorge Sanchez (RF) 4 ch. DAC: Petri Leinonen (RF) Interesting site where to share info on electronic designs: The Open Hardware Repository (OHR) is a place on the web for electronics designers to collaborate on open hardware designs. http://www.ohwr.org/twiki/bin/view/OHR/FMCprojects/Description 2 ch. DAC: Matthieu Cattin (CO) 16 ch. I/O: Matthieu Cattin (CO) 4 ch. ADC: Maciej Fimiarz (CO) 2 ch. ADC: Michael Sordet (BI) Info from J. Serrano and E. Van Der Bij Database for the PSB rf development created by John Molendijk \\cern.ch\dfs\Departments\AB\Groups\RF\Machines\Booster\PSBfromLinac4\LowLevel

3. Collection of information about the Hardware A. Blas FMC WG 20/01/2010 3 What information do we need to collect ? About the VME boards plugged into the VME crate 1.Type of VME board (function, construction date, number of mezzanines, serial number) 2.Location (slot number, front or rear)

4. Collection of information about the Hardware A. Blas FMC WG 20/01/2010 4 What information do we need to collect ? About the mezzanines implemented within a VME board 1.Is it present? (check top and bottom FMC connectors (min 0, max 2)) 2.Type of mezzanine (single or double size, function, construction date, serial number)

5. Firmware upload A. Blas FMC WG 20/01/2010 5 What do we need to program locally? remotely? 1.FPGAs firmware on Motherboard and daughter cards (local and remote) 2.DSP software on the motherboard (local and remote) 3.Hardware description EEPROMs on MB and DC (local and remote)

6. A. Blas FMC WG 20/01/2010 6 VITA 57 approach: 5.7. IO Mezzanine Module Present This standard uses the PRSNT_M2C_L signal, for a carrier card to successfully detect that an IO mezzanine module is installed. Rule 5.74: The IO mezzanine module shall connect this signal to GND. Rule 5.75: For double width modules, if the mezzanine module populates P2 then the mezzanine module shall connect the PRSNT_M2C_L on the P2 connector to GND. Rule 5.76: The carrier card shall analyze the PRSNT_M2C_L signal to identify whether an IO mezzanine module is installed. Mezzanines implemented within a VME board 1.Is it present? (check top and bottom FMC connectors (min 0, max 2)) 2.Type of mezzanine (single or double size, function, construction date, serial number) Mezzanine’s hardware information retrieval

7. A. Blas FMC WG 20/01/2010 7 VITA 57 approach: 2 lines I2C link = 2 dedicated pins: SCL – System Management I2C serial clock. SDA - System Management I2C serial data (bi-dir) Mezzanines implemented within a VME board 1.Is it present? (check top and bottom FMC connectors (min 0, max 2)) 2.Type of mezzanine (single or double size, function, construction date, serial number) Rule 5.60: The IO mezzanine module shall provide an onboard EEPROM, which shall interface with the I2C bus signals. Observation 5.17: The EEPROM shall be used to store information pertaining to the characteristics of the IO mezzanine module. Rule 5.61: The EEPROM will be powered by the signal 3P3VAUX. Rule 5.62: On double width mezzanine modules, the non-volatile storage device will be connected to the I2C bus on the P1 connector. Rule 5.63: On double width mezzanine modules, the non-volatile storage device on P1 connector’s I2C bus shall contain data pertaining to setting for P2 connector if populated. Rule 5.64: On double width mezzanine modules, devices shall not be placed on the I2C bus located on P2. IPMI (Intelligent Platform Management Interface ) support: see next slide P1 = top FMC connector P2 = bottom FMC connector Mezzanine’s hardware information retrieval

8. A. Blas FMC WG 20/01/2010 8 Mezzanines implemented within a VME board 1.Is it present? (check top and bottom FMC connectors (min 0, max 2)) 2.Type of mezzanine (single or double size, function, construction date, serial number) 5.5.1. IPMI Support The FMC mezzanine module shall provide hardware definition information that may be read by an external controller using IPMI commands and I2C serial bus transactions. The mezzanine module shall support the I2C link on pins SDA and SCL and optionally support the base IPMI commands defined in the PICMG 2.9 specification. Rule 5.65: Data fields provided by the IPMI resource on the mezzanine module shall include the minimum records defined in the Platform Management FRU Information Storage Definition V1.0. Rule 5.66: The EEPROM shall include the BOARD_INFO area for identification of the mezzanine module. Rule 5.67: The mezzanine module description data shall be stored in a non-volatile memory resource on the mezzanine module. Rule 5.68: For FMC-specific MultiRecords, the MultiRecord’s header (see ISD section 16.1) shall specify OEM record type 0xFA (see ISD section 16.2.1). The Manufacturer ID field of the Multirecord’s data portion (see ISD section 18.7) shall specify VITA’s Organizationally Unique Identifier (OUI), 0x0012A2 Mezzanine’s hardware information retrieval

9. A. Blas FMC WG 20/01/2010 9 Mezzanines implemented within a VME board 1.Is it present? (check top and bottom FMC connectors (min 0, max 2)) 2.Type of mezzanine (single or double size, function, construction date, serial number) IPMI support 2/2 Mezzanine’s hardware information retrieval

10. A. Blas FMC WG 20/01/2010 10 Mezzanines implemented within a VME board 1.Is it present? (check top and bottom FMC connectors (min 0, max 2)) 2.Type of mezzanine (single or double size, function, construction date, serial number) Mezzanine’s hardware information retrieval 5.6. Geographic Addresses These signals enable the FMC carrier card to address specific FMC slots that share an IPMI I2C bus. Rule 5.70: A mezzanine module shall use GA0 and GA1 to determine the address of the non-volatile storage device EEPROM devices and optional devices. The address decoding shall follow the addresses outlined in Table 10. I2C addressing: 1/2 -> in case we want to have a single I2C line for both mezzanines

11. A. Blas FMC WG 20/01/2010 11 Mezzanines implemented within a VME board 1.Is it present? (check top and bottom FMC connectors (min 0, max 2)) 2.Type of mezzanine (single or double size, function, construction date, serial number) Mezzanine’s hardware information retrieval Observation 5.18: Table 10 assumes that the most significant bit is transmitted first. Rule 5.71: The carrier card shall provide a unique code on GA[0..1] for all FMC slots that share an IPMI I2C bus. Rule 5.72: The carrier card shall connect the GA[0] and GA[1] directly to either the 3V3PAUX supply or GND signal. Rule 5.73: Optional Devices shall not use the address spaces assigned to the serial EEPROM. Observation 5.19: The mezzanine module may want to put a current limiting resistor on GA[0] and GA[1] signals. I2C addressing: 2/2

12. A. Blas FMC WG 20/01/2010 12 Mezzanines implemented within a VME board 1.Is it present? (check top and bottom FMC connectors (min 0, max 2)) 2.Type of mezzanine (single or double size, function, construction date, serial number) Do we need to implement a silicon id chip as in LHC rf Or can we define S/N in the I2C eeprom ? ? Mezzanine’s hardware information retrieval To this question the answer of the audience is that the Si ID chip should be installed on the mezzanine, ideally using the I2C bus or else connected to the DC FPGA.

13. A. Blas FMC WG 20/01/2010 13 Mezzanine’s firmware information retrieval Presently each FPGA includes a register called: Compilation date (in the form yyyy.mm.dd.hh.hh) This register is automatically updated by a script running on Quartus at each compilation. How would this be implemented with Visual Elite? To make sure that the firmware corresponds to the hardware, we could add a register called “Firmware function ”.

14. A. Blas FMC WG 20/01/2010 14 Mezzanine’s firmware upload Rule 5.50: The carrier card shall ensure that an independently buffered TCK shall be input to each IO mezzanine module. Rule 5.51: The mezzanine module card shall only have one load on the TMS signal. Rule 5.52: The carrier card shall connect TDI directly to TDO, if the FMC module is not plugged into carrier card Rule 5.53: The FMC module shall connect TDI to TDO, if the module does not use the JTAG interface. Rule 5.54: For double width modules the carrier card shall connect the TDI on P2 to TDO on P2 if no connector is present Rule 5.55: For double width modules the FMC module shall connect TDI of P2 to TDO of P2, if the module does not use the JTAG interface. Rule 5.56: For double width modules the FMC module shall treat the JTAG interfaces on each of P1 and P2 as independent JTAG chain. Hence the JTAG path entry of TDI on P1 shall route back through TDO of P1 and the JTAG path entry of TDI on P2 shall route back through TDO of P2. Suggestion 5.2: PRSNT_M2C_L should be used to detect the presence of the module and used to control the switching of the TDI signal that would normally connect to the IO Mezzanine module directly to the TDO signal, thus bypassing the module and keeping the JTAG chain intact Observation 5.16: JTAG support is optional on compliant IO mezzanine modules. Rule 5.57: The FMC JTAG signals require LVTTL (3.3V) levels on the JTAG signals. Rule 5.58.: The carrier shall not drive signals onto the JTAG signals to the IO Mezzanine module that exceed LVTTL levels. Rule 5.59: The IO Mezzanine Module shall not drive signals to the carrier card that exceed LVTTL levels. The Vita 57 approach Dedicated JTAG pins on the FMC

15. A. Blas FMC WG 20/01/2010 15 Mezzanine’s firmware upload The upload can be remote or local An automatic switching mechanism needs to be implemented On the DC when the local JTAG is used On the MB when the FMC connector is not plugged in (in case the JTAG is in a chain) Concerning this topic there was a consensus among the participants that the local JTAG connector on the mezzanine should be avoided. The programming of the FPGA on the mezzanine will be done via a carrier board connector or during a transient phase on a connector interface.

16. A. Blas FMC WG 20/01/2010 16 Conclusion The requirements are fulfilled by: 1.Following the FMC pin definition JTAG pins I2C pins PRSNT_M2C GA[0..1] (address for I2C) 2.Adding a JTAG automatic switching to be able to program the firmware locally 3.Adding a I2C automatic switching to be able to program the EEPROM locally 4.Not using a silicon ID chip ?? Using the silicon ID chip on the I2C bus Corrected by the audience

17. A. Blas FMC WG 20/01/2010 17 Next meeting A presentation will be made to describe how the clock should be implemented within the PSB rf system

18. PSB rf: Firmware download and hardware information A. Blas 18 http://cdsweb.cern.ch/record/1172409/files/AV57DOT1.PDF FMC WG 20/01/2010