180 likes | 320 Views
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 .
E N D
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 Collection of information about the Hardwareand firmware upload within the PSB rf system Participants: Pablo Alvarez-Sanchez, Maria Elena Angoletta, Alfred Blas, Petri Leinonen, John Molendijk, Jorge Sanchez-Quesada, Javier Serrano, Erik Van Der Bij FMC WG 20/01/2010
Mezzanine boards designers: 4 ch. ADC: Jorge Sanchez (RF) 4 ch. DAC: Petri Leinonen (RF) 2 ch. DAC: MatthieuCattin (CO) 16 ch. I/O: MatthieuCattin (CO) 4 ch. ADC: MaciejFimiarz (CO) 2 ch. ADC: Michael Sordet (BI) Collection of information about the Hardwareand firmware upload within the PSB rf system Info from J. Serrano and E. Van Der Bij 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 Database for the PSB rf development created by John Molendijk \\cern.ch\dfs\Departments\AB\Groups\RF\Machines\Booster\PSBfromLinac4\LowLevel FMC WG 20/01/2010
What information do we need to collect ? About the VME boards plugged into the VME crate Type of VME board (function, construction date, number of mezzanines, serial number) Location (slot number, front or rear) Collection of information about the Hardware FMC WG 20/01/2010
What information do we need to collect ? About the mezzanines implemented within a VME board Is it present? (check top and bottom FMC connectors (min 0, max 2)) Type of mezzanine (single or double size, function, construction date, serial number) Collection of information about the Hardware FMC WG 20/01/2010
What do we need to program locally? remotely? FPGAs firmware on Motherboard and daughter cards (local and remote) DSP software on the motherboard (local and remote) Hardware description EEPROMs on MB and DC (local and remote) Firmware upload FMC WG 20/01/2010
Mezzanine’s hardware information retrieval Mezzanines implemented within a VME board Is it present? (check top and bottom FMC connectors (min 0, max 2)) Type of mezzanine (single or double size, function, construction date, serial number) 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. FMC WG 20/01/2010
Mezzanine’s hardware information retrieval Mezzanines implemented within a VME board Is it present? (check top and bottom FMC connectors (min 0, max 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. VITA 57 approach: 2 lines I2C link = 2 dedicated pins: SCL – System Management I2C serial clock. SDA - System Management I2C serial data (bi-dir) P1 = top FMC connector P2 = bottom FMC connector IPMI (Intelligent Platform Management Interface ) support: see next slide FMC WG 20/01/2010
Mezzanine’s hardware information retrieval Mezzanines implemented within a VME board Is it present? (check top and bottom FMC connectors (min 0, max 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 FMC WG 20/01/2010
Mezzanine’s hardware information retrieval Mezzanines implemented within a VME board Is it present? (check top and bottom FMC connectors (min 0, max 2)) Type of mezzanine (single or double size, function, construction date, serial number) IPMI support 2/2 FMC WG 20/01/2010
Mezzanine’s hardware information retrieval Mezzanines implemented within a VME board Is it present? (check top and bottom FMC connectors (min 0, max 2)) Type of mezzanine (single or double size, function, construction date, serial number) I2C addressing: 1/2 -> in case we want to have a single I2C line for both mezzanines 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. FMC WG 20/01/2010
Mezzanine’s hardware information retrieval Mezzanines implemented within a VME board Is it present? (check top and bottom FMC connectors (min 0, max 2)) Type of mezzanine (single or double size, function, construction date, serial number) I2C addressing: 2/2 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. FMC WG 20/01/2010
Mezzanine’s hardware information retrieval Mezzanines implemented within a VME board Is it present? (check top and bottom FMC connectors (min 0, max 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 ? ? 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. FMC WG 20/01/2010
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 ”. FMC WG 20/01/2010
Mezzanine’s firmware upload The Vita 57 approach Dedicated JTAG pins on the FMC 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. FMC WG 20/01/2010
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. FMC WG 20/01/2010
Conclusion • The requirements are fulfilled by: • Following the FMC pin definition • JTAG pins • I2C pins • PRSNT_M2C • GA[0..1] (address for I2C) • Adding a JTAG automatic switching to be able to program the firmware locally • Adding a I2C automatic switching to be able to program the EEPROM locally • Not using a silicon ID chip ?? Using the silicon ID chip on the I2C bus Corrected by the audience FMC WG 20/01/2010
Next meeting A presentation will be made to describe how the clock should be implemented within the PSB rf system FMC WG 20/01/2010
PSB rf: Firmware download and hardware information http://cdsweb.cern.ch/record/1172409/files/AV57DOT1.PDF FMC WG 20/01/2010