Collection of information about the Hardware
and firmware upload within the PSB rf system
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
A. Blas
FMC WG
20/01/2010
1
Collection of information about the Hardware
and firmware upload within the PSB rf system
Mezzanine boards designers:
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)
4 ch. ADC: Jorge Sanchez (RF)
4 ch. DAC: Petri Leinonen (RF)
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
A. Blas
FMC WG
20/01/2010
2
Collection of information about the Hardware
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)
A. Blas
FMC WG
20/01/2010
3
Collection of information about the Hardware
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)
A. Blas
FMC WG
20/01/2010
4
Firmware upload
What do we need to program
1.
2.
3.
A. Blas
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)
FMC WG
20/01/2010
5
Mezzanine’s hardware information retrieval
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)
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.
A. Blas
FMC WG
20/01/2010
6
Mezzanine’s hardware information retrieval
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)
VITA 57 approach:
2 lines I2C link = 2 dedicated pins:
SCL – System Management I2C serial clock.
SDA - System Management I2C serial data (bi-dir)
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.
P1 = top FMC connector
P2 = bottom FMC 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
A. Blas
FMC WG
20/01/2010
7
Mezzanine’s hardware information retrieval
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
A. Blas
FMC WG
20/01/2010
8
Mezzanine’s hardware information retrieval
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
A. Blas
FMC WG
20/01/2010
9
Mezzanine’s hardware information retrieval
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)
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.
A. Blas
FMC WG
20/01/2010
10
Mezzanine’s hardware information retrieval
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)
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.
A. Blas
FMC WG
20/01/2010
11
Mezzanine’s hardware information retrieval
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 ?
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.
A. Blas
FMC WG
20/01/2010
12
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 ”.
A. Blas
FMC WG
20/01/2010
13
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.
A. Blas
FMC WG
20/01/2010
14
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.
A. Blas
FMC WG
20/01/2010
15
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
A. Blas
FMC WG
20/01/2010
16
Next meeting
A presentation will be made to describe how the clock should be implemented within
the PSB rf system
A. Blas
FMC WG
20/01/2010
17
PSB rf: Firmware download
and hardware information
http://cdsweb.cern.ch/record/1172409/files/AV57DOT1.PDF
A. Blas
FMC WG
20/01/2010
18