Erik van der BijEEPROM 24C02 - But why?
Update (January 2022)
The latest version of the FMC standard, ANSI/VITA 57.1-2019 reads:
Recommendation 5.7-1: Mezzanine cards should provide only one EEPROM, either 2Kb or 32Kb.
Observation 5.21-1: VITA 57.1 specifies the use of a 2Kb EEPROM per the IPMI specification which calls up a 24C02. This is shown in Table 10. The 2Kb EEPROM does not provide enough space for all FMCs, and larger EEPROMs are desired. 2Kb and smaller EEPROMs use one byte addressing. 4Kb to 16Kb EEPROMs also use single byte addressing but redefine some of the address pins that VITA 57.1 connects to the GA pins and are not compatible with the needs of the spec. 32Kb and larger EEPROMs switch to two byte addressing and define the address pins the same as 2Kb EEPROMs as shown in Table 10. As a result, the decision was made to skip over the 4 to 16Kb EEPROMs and specify a 32Kb or larger 24C32 compatible EEPROM if a module needs a larger EEPROM. Since the 24C32 uses two byte addressing, it also has a different base address than the 24C02 compatible EEPROMs.
Observation 5.21-2: For carrier cards to discern between 2Kb and 32Kb EEPROMs, they must first look for the 2Kb EEPROM at the addresses provided in Table 10.
The latest version of the FMC+ standard, ANSI/VITA 57.4-2018 defines that both 24C02 and 24C32 devices may be used:
Observation 5.4-1: VITA 57.1 specifies the use of a 2Kb EEPROM per the IPMI specification which calls up a 24C02. <..snip..> The 2Kb EEPROM does not provide enough space for all FMCs, and larger EEPROMs are desired. 2Kb and smaller EEPROMs use one byte addressing. <..snip..> As a result, the decision was made to skip over the 4 to 16Kb EEPROMs and specify a 32Kb or larger 24C32 compatible EEPROM if a module needs a larger EEPROM. Since the 24C32 uses two byte addressing, it also has a different base address than the 24C02 compatible EEPROMs.
Observation 5.4-2: For carrier cards to discern between 2Kb and 32Kb EEPROMs, they must first look for the 2Kb EEPROM at the addresses provided in Table 5.4-1. If not found, look for the 32Kb EEPROM per Table 5.4-2.
See also
- FPGA Mezzanine Card (FMC) standard ANSI/VITA 57.1-2019 - (CERN only)
- FPGA Mezzanine Card Plus (FMC+) standard AV57.4-2018 - (CERN only)
Original from May 2021
The Schematics Design Review checklist specifies:
"An FMC mezzanine should have a specific EEPROM (24C02, not a 24AA64T-I/MC, or a DS1624 temp sensor with EEPROM)."
But why?
The short answer is:
Note that Rule 5.74 already refers to 'Platform Management FRU Information Storage Definition v1.0' in another context, but this document also says: 'Presently, the supported devices are SEEPROMs that use a
24C02-compatible interface, and SEEPROMs that are compatible with the Dallas Semiconductor DS1624 Temperature Sensor/SEEPROM interface.' "So, looks like Platform Management FRU Information Storage Definition v1.0 calls up 24C02 indirectly. We are opening up VITA 57.1 for revision, we will add this as an item for inclusion.
The following mail exchange explains...
From: Erik Van Der Bij Erik.van.der.Bij@cern.ch
Date: Wed, 28 Feb 2018 at 17:46
Subject: RE: Re: FMC Discussion Forum - VITA 57.1 Rule 5.69: onboard EEPROM
To: be-dep-co-ht (All members of BE-CO-HT) be-dep-co-ht@cern.ch
Hi,
After the design review of the CTR mezzanine, I discussed with Federico who told that with the future software he will be able to handle both the old EEPROM (24AA64) and the suggested 24C02 EEPROM. Basically he will first read the contents as in the 24C02 format and if that doesn't show up some specific fields in the right place, he would read again, this time expecting to see a 24AA64.
Federico has not yet implemented this, this work likely can be done after the ADC work and Mock Turtle.
So from now on, new FMC designs we will design in the 24C02 EEPROM. I have added this in the design review checklist [1].
Best regards, Erik
[1] https://www.ohwr.org/projects/ed/wiki/schematics-checklist
PS: Sundance/UK is always using the 24C02. At the same time they don't think they have had a customer of their FMC carriers and FMC modules actually making use of this EEPROM.
-----Original Message-----
From: Federico Vaga
Sent: 20 February 2018 17:48
To: be-dep-co-ht (All members of BE-CO-HT) be-dep-co-ht@cern.ch
Subject: Fwd: Re: FMC Discussion Forum - VITA 57.1 Rule 5.69: onboard EEPROM
Hello,
I just received the answer from the VITA people about my question about the EEPROM type.
The quick answer is: our FMC mezzanine probably are not 100% compliant on this point because, indirectly, it was specified EEPROM 24C02 while we use bigger EEPROMs
Following the full discussion (I re-formatted the last email because of some weird character).
---------- Forwarded Message ----------
Subject: Re: FMC Discussion Forum - VITA 57.1 Rule 5.69: onboard EEPROM
Date: Tuesday, 20 February 2018, 16:49:33 CET
From: Jing Kwok (VITA) jing.kwok@vita.com
To: federico.vaga@cern.ch
CC: jerry@vita.com
Thank you for pinging back ...
Here is response form one member ...
"I totally agree that the current standard is missing this detail. I think it would be good to specify this in the new 57.1 revision. Abaco/4DSP always used 24C02 devices on FMCs, but others might have been using other devices.
Note that Rule 5.74 already refers to 'Platform Management FRU Information Storage Definition v1.0' in another context, but this document also says: 'Presently, the supported devices are SEEPROMs that use a 24C02-compatible interface, and SEEPROMs that are compatible with the Dallas Semiconductor DS1624 Temperature Sensor/SEEPROM interface.'
"
So, looks like Platform Management FRU Information Storage Definition v1.0 calls up 24C02 indirectly. We are opening up VITA 57.1 for revision, we will add this as an item for inclusion.
Thanks for bringing this to our attention.
Regards
-- Jing Kwok Technical Director, VITA w.602-281-4497 jing.kwok@vita.com website FAQ: http://www.vita.com/FAQ
On 2018-02-15 9:21 AM, Federico Vaga wrote:
Hello,
as promised I'm here to ping you on this topic: I2C EEPROM on FMC cards
On Tuesday, 23 January 2018 20:42:15 CET Federico Vaga wrote:
Thank you very much!
I will wait news from you (or I will ping you)
On Tuesday, January 23, 2018 8:40:05 PM CET Jing Kwok (VITA) wrote:
I do not know the answer to this ... I will send the question to the WG to see how they respond.
I do know there were some discussion in this area but I am not familiar with the details ...
I will pass on responses as I get them ... Stay tuned, feel free to ping me.
Regards
-- Jing Kwok Technical Director, VITA w.602-281-4497 jing.kwok@vita.com
website FAQ: http://www.vita.com/FAQOn 2018-01-23 9:31 AM, Federico Vaga wrote:
On Tuesday, 23 January 2018 14:44:25 CET Jing Kwok (VITA) wrote:
Hi Federico,
Please see below.
-- Jing Kwok Technical Director, VITA w.602-281-4497 jing.kwok@vita.com
website FAQ: http://www.vita.com/FAQOn 2018-01-22 4:05 AM, Federico Vaga wrote:
Hello,
I would like to have clarifications about the FMC standard (in particular rule 5.60). jk> re Rule 5.60: The mezzanine module card shall only have one load on the TMS signal. What is your specific question? Ok, I just realize that I got an old draft from the CERN repository. Actually I meant:
Rule 5.69: The IO mezzanine module shall provide an onboard EEPROM, which shall interface with the I2C bus signals.
In the standard I did not find any information about the kind of EEPROM to use on the FMC module. It looks like that this choice is open to the designers. Is it correct? Indeed I found mezzanines with 2K EEPROM and others with 64K EEPROM.
If my understand is correct, then I think the standard should improve by specifying the kind of EEPROM to use.
The information about an FMC module is specified in the FRU which is contained in the EEPROM on the module itself. How do I access, in a standardized way, this information? The way of accessing an EEPROM changes according to the EEPROM type. For example, we have small EEPROM with 1Byte address, bigger EEPROM with 2Byte address, or other EEPROM that uses the I2C address as part of the internal address. If I have to know in advance the FMC modules plugged, then I do not really need the FRU information for some sort of auto-discovery software.
The IPMI specification is clearer on this point. For example at chapter 38 it says: "System software needs to know the operation of a 24C02-compatible SEEPROM interface to access these devices."
Why this is not specified in VITA 57? The FRU information, of course, fits perfectly into the 24C02 EEPROM (and compatible devices).
Is there something that I miss?
thank you :)
2 February 2022