alveo data center accelerator cards fru data specification · 2021. 1. 15. · fru data should...

Alveo Data CenterAccelerator Cards FRU DataSpecification

UG1378 (v1.0) January 16, 2020

https://www.xilinx.com

Revision HistoryThe following table shows the revision history for this document.

Section Revision Summary1/16/2020 Version 1.1

General updates Revised outline of document.

7/17/2019 Version 2019.1

Initial release. N/A

Revision History

UG1378 (v1.0) January 16, 2020 www.xilinx.comFRU Data Specification 2Send Feedback


https://www.xilinx.com/about/feedback/document-feedback.html?docType=User_Guides&docId=UG1378&Title=Alveo%20Data%20Center%20Accelerator%20Cards%20FRU%20Data%20Specification&releaseVersion=1.0&docPage=2

Table of ContentsRevision History...............................................................................................................2

Chapter 1: Introduction.............................................................................................. 4

Chapter 2: Xilinx Field Replaceable Unit Architecture ............................. 5FRU Storage Organization..........................................................................................................5

Chapter 3: FRU Data Description........................................................................... 7Common Header......................................................................................................................... 7Board Information Area............................................................................................................. 7Product Information Area........................................................................................................ 11Multi-Record Area..................................................................................................................... 16Xilinx OEM Record — Thermal.................................................................................................20Xilinx OEM Record — Power.................................................................................................... 21OEM Reserved Multi-Records.................................................................................................. 22

Appendix A: Background.......................................................................................... 23Checksum Calculation.............................................................................................................. 23Type/Length Byte Format........................................................................................................ 23

Appendix B: Additional Resources and Legal Notices............................. 25Xilinx Resources.........................................................................................................................25Documentation Navigator and Design Hubs.........................................................................25References..................................................................................................................................26Please Read: Important Legal Notices................................................................................... 26




Chapter 1

IntroductionThis specification describes the detailed design and layout of field replaceable unit (FRU) contentfor each unit stored in the EEPROM and used by all Xilinx® Alveo™ cards to facilitate itsimplmentation. The FRU information is primarily used to provide inventory information aboutwhere the FRU information device is located. All major field replaceable units should have anEEPROM that includes, at a minimum, the serial number, part number, manufacturer information,version number, and can be read through software.

Note: This FRU specification follows the Intelligent Platform Management Interface FRU Specification.

Chapter 1: Introduction


https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/ipmi-platform-mgt-fru-info-storage-def-v1-0-rev-1-3-spec-update.pdf



Chapter 2

Xilinx Field Replaceable UnitArchitecture

General FRU content to be stored in the EEPROM includes:

• Format version

• Manufacturer name/information

• Board/product name

• Vendor ID

• Device ID

• Board serial number

• Board part number

• Board revision number

• MAC addresses (not public information)

• Length of the previously listed FRU information

The Xilinx® FRU data should follow Intelligent Platform Management Interface FRU Specificationfor EEPROM layout. Currently, the FRU data retrieval only supports raw I2C.

Byte Ordering (Endianness)

All multi-byte fields represented in this document are little endian, unless otherwise noted.

FRU Storage OrganizationThe following table details the layout and storage organization of EEPROM contents. Thisscheme takes into consideration variable lengths and future changes (i.e., expansion, reduction,and removal) associated with each section. The common header section specifies the variablelength of each region. If necessary, a FRU data management entity can change the allocationsfrom their initial values.





Table 1: Recommended for 1 Kb (or more) EEPROM Organization

FRU Area Size DescriptionCommon header 8 bytes This is a mandatory section for all Xilinx accelerator

board implementations. It holds FRU specificationversion information and offsets to other areas.

Board information area 64 bytes This area provides general FRU information (serialnumber, part number, manufacturer information,

manufacturing date, etc.) about the board.

Product information area 72 bytes This area provides general FRU information (serialnumber, part number, and manufacturer

information). The contents from this section will beused by server BMC to display in GUI or CLI.

Multi-record area Record 1 xx bytes This region is OEM implementation specific.

Record 2

…

Record n

Chapter 2: Xilinx Field Replaceable Unit Architecture




Chapter 3

FRU Data Description

Common HeaderThe common header section is mandatory for all Alveo™ card EEPROMs that contain FRUimplementation information. This section holds version information for the overall formatspecification, including offsets to the other area, as shown in the following table. The other areascan be present based on the application of the device. An area is inferred as null or not presentwhen the common header has a value of 00h for the starting offset of that area.

Table 2: Common Header

ByteAddress Field Description Size

(bytes)Byte

Address Notes

0 Common HeaderFormat version

1 0x01 Version number =0x01

1 Internal user area 1 0x00 Not present

2 Chassis information area 1 0x00 Not present

3 Board information area 1 0x01 Starting offset: 8;offset in multiples of 8 bytes

4 Product information area 1 0x09 Starting offset: 72; offset in multiples of 8bytes

5 Multi-record area 1 0x12 Starting offset: 144;offset in multiples of 8 bytes

6 Reserved 1 0x00

7 Common header checksum 1 0xE3

Board Information AreaThis section describes the board information FRU data that is stored in this region, as detailed inthe following table.




Table 3: Board Information Area

ByteAddress Field Description Size

(bytes) Format DefaultValue Notes

8 Board area formatversion

1 Binary;version 1.0

0x01 7:4 reserved, write as 0000b3:0 - format version number = 1h for thisspecification.

9 Board area length 1 Binary; 64bytes

0x08 Denoted in multiples of 8

10 Language code 1 Binary 0x00 Refer to section 15 of the IntelligentPlatform Management Interface FRUSpecification; 0x00 indicates English

11 Manufacturing date/time

3 Binary 0x00 0x000x00

Number of minutes from 0:00 hrs.1/1/96LSbyte first (little endian)

14 Board manufacturertype/length byte

1 8-bit ASCIIand length:

6

0xC6 Refer to section 13 of the IntelligentPlatform Management Interface FRUSpecification

15 Board manufacturer 6 ASCII 0x58 0x490x4C 0x490x4E 0x58

21 Board product nametype/length byte


16

0xD0

22 Board product name 16 ASCII TBD

38 Board serial numbertype/length byte


14

0xCE

39 Board serial number 14 ASCII TBD

53 Board part numbertype/length byte


9

0xC9

54 Board part number 9 ASCII TBD

63 FRU file ID type/lengthbyte

1 Binary andlength: 1

0x01

64 FRU file ID 1 Binary 0x00 FRU ID 0

65 End of fields 1 Binary 0xC1

66 Pad 5 Binary 0x00 0x000x00 0x000x00 0x00

71 Board information areachecksum

1 Binary TBD

Board Area Format VersionThe following table describes the board area format version field.

Chapter 3: FRU Data Description










Table 4: Board Area Format Version

Bits Meaning7:4 Reserved

3:0 Format version number, 0001b for IPMI FRU Specification. The value for this field is 0x01.

Board Information Area LengthThe elements of the board information area are padded up to the nearest 8-byte boundary (usingabsolute offsets). The default pad value is 0x0. The total length of the board information area isin 8-byte units.

Example Content: 0Eh x 8 byte = 64 bytes

Language CodeDefault value 00h indicates that the language code is english and all fields encoded as an 11btype are specified in single-byte ASCII format.

Note: For a detailed list of available language codes, refer to the Intelligent Platform Management InterfaceFRU Specification.

Example Content: 0x00 indicates English

Manufacturing Date and TimeThis value specifies the date and time that the board was manufactured. This field value is thenumeric value that is calculated as the number of minutes from 0:00 hours on 1 January 1996,and stored as the least-significant byte first (i.e., in offset 03h). If the field is not specified, thedefault value is 000000h.

Note: There are 525950 minutes in a non-leap year or 527040 minutes in a leap year. This algorithm timesout in the year 2028.

Manufacturer NameThe value for this field is Xilinx encoded in 8-bit ACSII + Latin 1. The values for this field are0x58, 0x49, 0x4C, 0x49, 0x4E, and 0x58.

Manufacturer Type/Length Byte

This value defines the type and length of the board manufacturer field. See Type/Length ByteFormat for information on the IPMI defined type/length byte format. The fixed value for this fieldis 0xC6, which is decoded as 8-bit ASCII + Latin , and 6 bytes long.








Product NameThe ASCII character value consists of the variable-length product name (maximum length is 16bytes). The product name is programmed at the time of manufacturing. This value is static for agiven board. If the value is less than the chosen board product name length, the remaining/trailing bytes will occupy empty spaces.

Product Name Type/Length Byte

This value defines the type and length of the product name field. See Type/Length Byte Formatfor information on the IPMI defined type/length byte format. The fixed value for this field is0xD0, which is decoded as 8-bit ASCII + Latin 1, and 16 bytes long.

Board Serial NumberThe ASCII character value consists of the variable-length serial number (maximum length is 14bytes). The serial number is programmed at the time of manufacturing. This value is static for agiven board. If the value is less than the chosen board serial number length, the remaining/trailing bytes will occupy empty spaces.

Board Serial Number Type/Length Byte

This value defines the type and length of the board serial number field. See Type/Length ByteFormat for information on the IPMI defined type/length byte format. The fixed value for this fieldis 0xCE, which is decoded as 8-bit ASCII + Latin 1, and 14 bytes long.

Part NumberThe ASCII character value consists of the variable-length part number (maximum length is 9bytes). The part number is programmed at the time of manufacturing. This value is static for agiven board. If the value is less than the chosen board part number length the remaining bytesare filled with 0x00.

Part Number Type/Length Byte

This value defines the type and length of the part number field. See Type/Length Byte Format forinformation on the IPMI defined type/length byte format. The fixed value for this field is 0xC9,which is decoded as 8-bit ASCII + Latin 1, and 9 bytes long.

FRU File IDThis field is used to indicate the version of the binary data used to program the FRU storagedevice. It is intended to aid with FRU file data identification and its use is optional. Non-00h andnon-FFh content indicates that this field is being used for FRU file version identification.





• 0x00: This field is unused for version identification

• 0x01: Version 1 of FRU data


• 0xnn: Version nn of FRU data

• 0xFF: This field is used for version identification

The Xilinx fixed value for this field is 0x00.

FRU File ID Type/Length Byte

This value defines the type and length of the FRU file ID field. See Type/Length Byte Format forinformation on the IPMI defined type/length byte format. The fixed value for this field is 0x01,which is decoded as binary data, and 1 byte long.

End of FieldsThe value for this field is 0xC1.

PadPad with 0x00 until the board information area ends on an 8-byte boundary (relative to absoluteoffsets).

Board Area ChecksumSee the Checksum Calculation section for guidance.

Product Information AreaThis section describes the production information FRU data that is stored in this region, asdetailed in the following table.

Table 5: Product Information Area

ByteAddress Field Description

Size(bytes) Format Default

Value Notes

72 Product informationarea format version

1 Binary; version 1.0 0x01 7:4 reserved, write as 0000b 3:0 —format version number = 1h forthis specification.





Table 5: Product Information Area (cont'd)

ByteAddress Field Description

Size(bytes) Format Default

Value Notes

73 Product informationarea length

1 Binary; 72 bytes 0x09 Denoted in multiples of 8

74 Language code 1 Binary 0x00 Refer to section 15 of the Intelligent Platform ManagementInterface FRU Specification; 0x00indicates English

75 Manufacturer nametype/length byte

1 8-bit ASCII & Length: 6 0xC6 Refer to section 13 of the Intelligent Platform ManagementInterface FRU Specification

76 Manufacturer name 6 ASCII 0x580x490x4C0x490x4E0x58

82 Product name type/length byte

1 8-bit ASCII & Length:16

0xD0

83 Product name 16 ASCII TBD

99 Product part numbertype/length byte

1 8-bit ASCII & Length: 9 0xC9

100 Product part number 9 ASCII TBD

109 Product version type/length byte

1 8-bit ASCII & Length: 3 0xC8

110 Product version 8 ASCII TBD

118 Product serial numbertype/length byte

1 8-bit ASCII & Length:14

0xCE

119 Product serial number 14 ASCII TBD

133 Asset tag type/lengthbyte

1 N/A 0x0 N/A

134 Asset tag 0 N/A N/A N/A

134 FRU file ID type/lengthbyte

1 Binary & Length: 1 0x01

135 FRU file ID 1 Binary 0x00 FRU ID 0

136 End of fields 1 Binary 0xC1

137 Pad 6 Binary 0x000x000x000x000x000x00

143 Product informationarea checksum

Binary TBD









Product Information Area Format VersionTable 6: Product Information Area Format Version

Bits Meaning7:4 Reserved

3:0 Format version number, 0001b for IPMI FRU Specification. The value for this field is 0x01.

Product Information Area LengthThe elements of the product information area are padded up to the nearest 8-byte boundary(using absolute offsets). The default pad value is 0x0. The total length of the board informationarea is in 8-byte units.

Example Content: 0Eh x 8 byte = 72 bytes

Language CodeDefault value 00h indicates that the language code is english and all fields encoded as an 11btype are specified in single-byte ASCII format.

Note: For a detailed list of available language codes, refer to the Intelligent Platform Management InterfaceFRU Specification.

Example Content: 0x00 indicates English

Manufacturer NameThe value for this field is Xilinx encoded in 8-bit ACSII + Latin 1. The values for this field are0x58, 0x49, 0x4C, 0x49, 0x4E, and 0x58.

Manufacturer Type/Length Byte

This value defines the type and length of the board manufacturer field. See Type/Length ByteFormat for information on the IPMI defined type/length byte format. The fixed value for this fieldis 0xC6, which is decoded as 8-bit ASCII + Latin , and 6 bytes long.

Product NameThe ASCII character value consists of the variable-length product name (maximum length is 16bytes). The product name is programmed at the time of manufacturing. This value is static for agiven board. If the value is less than the chosen board product name length, the remaining/trailing bytes will occupy empty spaces.








Product Name Type/Length Byte

This value defines the type and length of the product name field. See Type/Length Byte Formatfor information on the IPMI defined type/length byte format. The fixed value for this field is0xD0, which is decoded as 8-bit ASCII + Latin 1, and 16 bytes long.

Product Part NumberThe ASCII character value consists of the variable-length part number (maximum length is 9bytes). The part number is programmed at the time of manufacturing. This value is static for agiven board. If the value is less than the chosen board part number length the remaining bytesare filled with 0x00.

Product Part Number Type/Length Byte

This value defines the type and length of the part number field. See Type/Length Byte Format forinformation on the IPMI defined type/length byte format. The fixed value for this field is 0xC9,which is decoded as 8-bit ASCII + Latin 1, and 9 bytes long.

Product VersionThe ASCII character value consists of the variable-length board revision number (maximumlength is 8 bytes). The revision number is programmed at the time of manufacturing. This value isstatic for a given board. If the value is less than the chosen board revision number length, anyremaining/trailing bytes will occupy empty spaces.

Product Version Type/Length Byte

This value defines the type and length of the board revision number field. See Type/Length ByteFormat for information on the IPMI defined type/length byte format. The fixed value for this fieldis 0xC8, which is decoded as 8-bit ASCII + Latin 1, and 8 bytes long.

Product Serial NumberThe ASCII character value consists of the variable-length serial number (maximum length is 14bytes). The serial number is programmed at the time of manufacturing. This value is static for agiven board. If the value is less than the chosen board serial number length, the remaining/trailing bytes will occupy empty spaces.

Product Serial Number Type/Length Byte

This value defines the type and length of the board serial number field. See Type/Length ByteFormat for information on the IPMI defined type/length byte format. The fixed value for this fieldis 0xCE, which is decoded as 8-bit ASCII + Latin 1, and 14 bytes long.





Asset TagThe asset tag is N/A for Alveo cards.

Asset Tag Type/Length Byte

This field is will be set to 0x0.

FRU File IDThis field is used to indicate the version of the binary data used to program the FRU storagedevice. It is intended to aid with FRU file data identification and its use is optional. Non-00h andnon-FFh content indicates that this field is being used for FRU file version identification.

• 0x00: This field is unused for version identification



• 0xnn: Version nn of FRU data

• 0xFF: This field is used for version identification

The Xilinx fixed value for this field is 0x00.

FRU File ID Type/Length Byte

This value defines the type and length of the FRU file ID field. See Type/Length Byte Format forinformation on the IPMI defined type/length byte format. The fixed value for this field is 0x01,which is decoded as binary data, and 1 byte long.

End of FieldsThe value for this field is 0xC1.

PadPad with 0x00 until the board information area ends on an 8-byte boundary (relative to absoluteoffsets).

Product Information Area ChecksumSee the Checksum Calculation section for guidance.





Multi-Record AreaThis section describes the how Xilinx specific data as well as server OEM specific data isrepresented. While all FRU data is exposed via I2C raw commands, some of the multi-records arereserved for Xilinx or for server OEM. Not all records in this multi-record area are relevant toevery server OEM where an Alveo card is supported/qualified.

Table 7: Multi-Record Type

Record ID Record Type0x00 – 0x0F IPMI specific

Refer to the Intelligent Platform Management Interface FRU Specification0x10 – 0xBF Reserved0xC0 – 0xCF Reserved

0xD0 Alveo card thermal information0xD1 Alveo card power information0xD2 Xilinx Alveo card information

0xD3 - 0xDF Xilinx reserved

0xE0 - 0xFF Reserved

Multi-Record Information

This field enables the software to determine record form at version. Refer to the IntelligentPlatform Management Interface FRU Specification, section 6.1.2 for additional information. Thebits are defined in the following table.

Table 8: Multi-Record Information

Bits DescriptionBits 7:7 End of List

Bits 6:4 Reserved, 000b

Bits 3:0 Record Format Version0x02 for IPMI FRU v1.0; 0x00 otherwise

Multi-Area Record ChecksumRecord Checksum

The record checksum covers byte positions after the header (following offset 0x04). This valuemust be calculated before the record header checksum. In the following example, the bytes 0x05to 0x09 are used to calculate the record checksum.








Record Header Checksum

The checksum covers byte positions 0x00 to 0x03. This value must be calculated after therecord checksum and updated at byte offset 0x04.

Table 9: Record and Record Header Checksum Example

Byte Offset Field Description Size (bytes) Sample Value0 Record type (multi-record area) 1 0xC0 (FPGA warranty record)

1 Record information 1 0x02 (multi-record area)

2 Record length 1 0x05

3 Record checksum 1 0xA6

4 Record header checksum 1 0x93

5 Data 1 0x01

6 Data 1 0x02

7 Data 1 0xF0

8 Data 1 0xAA

9 Data 1 0xBD

Multi-Record Area LayoutTable 10: Multi-Record Area Layout

Field Description Size (bytes) Format Default Value CommentXilinx multi-record header 9 Binary 0x00 Xilinx OEM thermal

information

Record 21 Binary 0x00 TBD

Xilinx multi-record header 9 Binary 0x00 Xilinx OEM powerinformation


Xilinx multi-record header 9 Binary 0x00 OEM reserved


Xilinx multi-record header 9 Binary 0x00 OEM reserved


Xilinx multi-record header 9 Binary 0x00 OEM reserved (end ofrecords)






Xilinx Multi-Record HeaderThe multi-area record header is defined by the IPMI specification (byte address 0-4). The OEMspecific information can be derived from the 3-byte manufacturer identification field and the 1-byte version number field (byte address 5 and 8). The IPMI header along with the two additionalfields (manufacturing ID and version number) are called Xilinx header for the multi-record area,which is nine bytes long. All of the Xilinx multi-record area has this header to the convenience ofmanufacturer identification. This helps server OEMs to parse and make sense of data that isrelevant to their server platforms. Per the IPMI specification, the total length of record is 256.

Table 11: Xilinx Multi-Record Header

ByteAddress Field Description Size (bytes) Format

DefaultValue Notes

0 Record type 1 Binary 0x00 Refer to Table 7: Multi-RecordType

1 Record information 1 Binary 0x00 Refer to Table 8: Multi-RecordInformation

2 Record length 1 Binary 0x00

3 Record checksum 1 Binary 0x00 Refer to Multi-Area RecordChecksum

4 Header checksum 1 Binary 0x00 Refer to Multi-Area RecordChecksum

5 Manufacturer ID 3 Binary 0xDA 0x100x00

Xilinx IANA ID

8 Version number 1 Binary 0x01

Record Type

This unsigned byte is used to identify the information contained in the record. Refer to Table8: Multi-Record Information.

Record Information

Refer to Table 8: Multi-Record Information

End of List

This bit indicates whether or not this is the last record in the multi-record area. If this bit is zero,it indicates that one or more records follow.





Record Format Version

The area version format is stored in the lower nibble of the second byte. This field is used toidentify the revision level of information stored in this area. This number starts at zero for eachnew area. If changes need to be made to the record (e.g., fields added/removed) the versionnumber should be increased to reflect the change. Unless otherwise noted, the record formatversion for all record types is 02h for this specification, including OEM record types. The latterprovision is to provide for standardized data fields that precede the OEM specific data within theOEM record.

Record Length

This unsigned byte indicates the number of bytes of data in the record. This byte can also beused to find the next area in the list. If the end of list bit is zero, the length can be added to thestarting offset of the current record data to get the offset of the next record header. This fieldallows for 0 to 255 bytes of data for each record.

Version Number

For Xilinx OEM multi-records, the version number is 0x01.

Manufacturer ID

The manufacturer ID field correlates multi-record information to a specific OEM. For Xilinx, themanufacturer ID is 4314 (0x10DA). Per the IPMI specification, this field is three bytes in long. ForXilinx specific multi-records, the full manufacturer ID, in LSB first, is 0xDA 0x10 0x00.

Note: Look up the manufacturer ID in the following webpage. The Manufacturer ID is a 20-bit valuederived from the IANA Private Enterprise ID.

https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers



https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers



Xilinx OEM Record — ThermalTable 12: Xilinx Thermal Information Record

Byte Offset Field Description Size (bytes) Format Default Values0 Record type (multi-record area) 1 Xilinx thermal information 0xD0

1 Record information 1 Multi-record area 0x02

2 Record length 1 Binary; excluding pad 0x19 (25 Bytes)

3 Record checksum 1 Binary TBC

4 Record header checksum 1 Binary TBC

5 Manufacturer ID 3 Binary 0xDA 0x10 0x00


9 Reserved 21 Binary TBD

Record Type

The record type ID for Xilinx OEM information is 0xD0.

Record Information

The record information is 0x02. Refer to Table 8: Multi-Record Information.

Length

The length of Xilinx thermal record is 25 bytes, excluding 5 pad bytes.

Record Checksum

Refer to Multi-Area Record Checksum



Manufacturer ID

For Xilinx, the manufacturer ID is 4314 (0x10DA). Per the IPMI specification, where LSB is first,Xilinx manufacturer ID is 0xDA 0x10 0x00.

Version Number

The Xilinx record version is 0x01.





Reserved

The values in these bytes are reserved and might not default to 0x00.

Xilinx OEM Record — PowerTable 13: Xilinx Power Information Record

Byte Offset Field Description Size (bytes) Format Default Values0 Record type (multi-record

area)1 Xilinx power information 0xD0

1 Record information 1 Multi-record area 0x02

2 Record length 1 Binary; excluding pad 0x19 (25 bytes)

3 Record checksum 1 Binary TBD

4 Record header checksum 1 Binary TBD

5 Manufacturer ID 3 Binary 0xDA 0x10 0x00


9 Reserved 21 Binary TBD

Record Type

Record Type ID for Xilinx OEM Information is 0xD1.

Record Information

Record information is 0x02. Refer to Table 8: Multi-Record Information

Record Length

The length of Xilinx thermal record is 25 bytes, excluding five pad bytes.

Checksum




Manufacturer ID

The Xilinx manufacturer ID is 4314 (0x10DA). Per IPMI specification, in LSB first, the Xilinxmanufacturer ID is 0xDA 0x10 0x00.





Version Number

Xilinx record version is 0x01.

Reserved

The values in these bytes are TBD and might not default to 0x00.

OEM Reserved Multi-RecordsPer the Intelligent Platform Management Interface FRU Specification, multi-records can be OEMspecific. The Alveo card FRU has three OEM specific contents, as detailed in the following table.

Table 14: OEM Reserved Multi-Records

Field Description Size (bytes) Format DefaultValue Comment

Xilinx multi-record header 9 Binary 0x00 OEM reserved (record type 0xE1)

Record data 21 Binary 0x00 TBD

Xilinx multi-record header 9 Binary 0x00 OEM reserved (record type 0x00)


Xilinx multi-record header 9 Binary 0x00 OEM reserved (record type 0xE3)Record info (end of records)







Appendix A

Background

Checksum CalculationChecksum ranges are noted throughout this specification. These are provided as a range of bytesto include within the checksum calculation. These are not provided as a range for the resultantchecksum value.

Steps for calcuating checksums:

1. Set checksum value to zero (0).

2. Perform a byte-wise sum of all other bytes within the specified range.

3. Subtract byte-wise sum from step 2 from zero (0).

4. Assign value from step 3 to checksum.

Checksum ranges that include the checksum itself assume a value of zero or do not include thechecksum in the range at all. Padded ranges might include the pads. This does not affect theoutcome of the checksum calculation since the pad values themselves are required to be 0x00.

Type/Length Byte FormatThe following table presents the specification of the type/length byte format as detailed in Intelligent Platform Management Interface Specification v2.0, section 13 of the document.


https://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html



Table 15: Type/Length Format

Bits Meaning7:6 Type code

00… Binary or unspecified

01… Binary-coded decimal plus

10… 6-bit ASCII packed (overrides language codes)

11… Interpretation depends on language codes. 11b indicates 8-bit ASCII +Latin 1 if the language code is English for the area or record containingthe field, or 2-byte UNICODE (least significant byte first) if the languagecode is not English. At least two bytes of data must be present when thistype is used. Therefore, the length (number of data bytes) will always be>1 if data is present, 0 if data is not present.

5:0 Number of data bytes000000 indicates that the field is empty. When the type code is 11b, alength of 000001 indicates ‘end of fields, i.e., Type/Length = C1hindicates end of fields.

ASCII+LATIN1 is derived from the first 256 characters of unicode 2.0. The first 256 codes ofunicode follow ISO 646 (ASCII) and ISO 8859/1 (Latin 1). The Unicode C0 Controls and Basic Latinset defines the first 128 8-bit characters (00h-7Fh), and the C1 Controls and Latin-1 Supplementdefines the second 128 (80h-FFh).

6-bit ASCII is the 64 characters starting from character 20h (space) from the ASCII+LATIN1 set.For example, 6- bit ASCII value 000000b maps to 20h (space), 000001b maps to 21h (!), etc.Packed 6-bit ASCII takes the 6-bit characters and packs four characters to every three bytes,with the first character in the least significant six bits of the first byte.

Appendix A: Background




Appendix B

Additional Resources and LegalNotices

Xilinx ResourcesFor support resources such as Answers, Documentation, Downloads, and Forums, see XilinxSupport.

Documentation Navigator and Design HubsXilinx® Documentation Navigator (DocNav) provides access to Xilinx documents, videos, andsupport resources, which you can filter and search to find information. To open DocNav:

• From the Vivado® IDE, select Help → Documentation and Tutorials.

• On Windows, select Start → All Programs → Xilinx Design Tools → DocNav.

• At the Linux command prompt, enter docnav.

Xilinx Design Hubs provide links to documentation organized by design tasks and other topics,which you can use to learn key concepts and address frequently asked questions. To access theDesign Hubs:

• In DocNav, click the Design Hubs View tab.

• On the Xilinx website, see the Design Hubs page.

Note: For more information on DocNav, see the Documentation Navigator page on the Xilinx website.


https://www.xilinx.com/support

https://www.xilinx.com/support

https://www.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://www.xilinx.com/cgi-bin/docs/rdoc?t=docnav



ReferencesThis document provides supplemental material useful with this guide:

1. Intelligent Platform Management Interface FRU Specification

Please Read: Important Legal NoticesThe information disclosed to you hereunder (the "Materials") is provided solely for the selectionand use of Xilinx products. To the maximum extent permitted by applicable law: (1) Materials aremade available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES ANDCONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TOWARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANYPARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, includingnegligence, or under any other theory of liability) for any loss or damage of any kind or naturerelated to, arising under, or in connection with, the Materials (including your use of theMaterials), including for any direct, indirect, special, incidental, or consequential loss or damage(including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of anyaction brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinxhad been advised of the possibility of the same. Xilinx assumes no obligation to correct anyerrors contained in the Materials or to notify you of updates to the Materials or to productspecifications. You may not reproduce, modify, distribute, or publicly display the Materialswithout prior written consent. Certain products are subject to the terms and conditions ofXilinx's limited warranty, please refer to Xilinx's Terms of Sale which can be viewed at https://www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and support terms containedin a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe orfor use in any application requiring fail-safe performance; you assume sole risk and liability foruse of Xilinx products in such critical applications, please refer to Xilinx's Terms of Sale which canbe viewed at https://www.xilinx.com/legal.htm#tos.

AUTOMOTIVE APPLICATIONS DISCLAIMER

AUTOMOTIVE PRODUCTS (IDENTIFIED AS "XA" IN THE PART NUMBER) ARE NOTWARRANTED FOR USE IN THE DEPLOYMENT OF AIRBAGS OR FOR USE IN APPLICATIONSTHAT AFFECT CONTROL OF A VEHICLE ("SAFETY APPLICATION") UNLESS THERE IS ASAFETY CONCEPT OR REDUNDANCY FEATURE CONSISTENT WITH THE ISO 26262AUTOMOTIVE SAFETY STANDARD ("SAFETY DESIGN"). CUSTOMER SHALL, PRIOR TO USING

Appendix B: Additional Resources and Legal Notices


https://www.intel.com/content/www/us/en/products/docs/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html

https://www.xilinx.com/legal.htm#tos





OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, THOROUGHLY TESTSUCH SYSTEMS FOR SAFETY PURPOSES. USE OF PRODUCTS IN A SAFETY APPLICATIONWITHOUT A SAFETY DESIGN IS FULLY AT THE RISK OF CUSTOMER, SUBJECT ONLY TOAPPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCTLIABILITY.

Copyright

© Copyright 2019–2020 Xilinx, Inc. Xilinx, the Xilinx logo, Alveo, Artix, Kintex, Spartan, Versal,Virtex, Vivado, Zynq, and other designated brands included herein are trademarks of Xilinx in theUnited States and other countries. PCI, PCIe, and PCI Express are trademarks of PCI-SIG andused under license. All other trademarks are the property of their respective owners.

Appendix B: Additional Resources and Legal Notices




alveo data center accelerator cards fru data specification · 2021. 1. 15. · fru data should...

Documents