Intel® Acceleration Stack for Intel® Xeon® CPU with FPGAs Version 1.1 Release Notes: Intel FPGA Programmable Acceleration Card N3000

Download PDF
ID 683749
Date 7/01/2021
Public
Document Table of Contents
Document Table of Contents x
Notice Intel® Acceleration Stack for Intel® Xeon® CPU with FPGAs Version 1.1 Release Notes Appendix: Intel Provided FPGA Factory Image Packet Drop
Intel® Acceleration Stack for Intel® Xeon® CPU with FPGAs Version 1.1 Release Notes x
Minimum Requirements Supported Features Intel Acceleration Stack v1.1 for Intel FPGA PAC N3000 Reference Table Known Issues Component Information Supported Software Revision History for Intel® Acceleration Stack for Intel® Xeon® CPU with FPGAs v1.1 Release Notes
Component Information x
Broadcom* PEX8747 PCIe* Switch Intel Ethernet Controller XL710
Supported Software x
Data Plane Development Kit (DPDK) Intel® Network Adapter Drivers
Notice
Intel® Acceleration Stack for Intel® Xeon® CPU with FPGAs Version 1.1 Release Notes
Appendix: Intel Provided FPGA Factory Image Packet Drop

Known Issues

Table 3.  Known Issues in Intel Acceleration Stack v1.1 for Intel® FPGA PAC N3000
Known Issue Details
fpgainfo mac command does not report correct MAC address.

This issue only applies to Intel® FPGA PAC N3000 that is pre-production and has been upgraded to the Intel Acceleration Stack production version.

  • fpgainfo mac reports FFFFFFFF instead of correct MAC address as a card serial number.
  • Workaround: You can obtain the source MAC address using the following command:
    $ ip  link show <XL710 Interface Name>
    For example: 
    $ ip  link show p4p1

92: p4p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 64:4c:36:11:07:30 brd ff:ff:ff:ff:ff:ff
  • Status: This limitation is fixed in the production version of the Intel® FPGA PAC N3000.
DDR4 accesses with a burstcount of 64 are not supported.

  • Burstcounts of 1, 2, 4, 8, 16 and 32 are supported.
  • Workaround: None.
  • Status: No planned fix.
False errors are reported when installing a configuration package.

  • You may encounter an error similar to this 2x2x25 GbE report when installing configuration packages:
    error running: ['yum', 'info', 'opae-one-time-update-n3000-25G.noarch']
error running: ['yum', 'info', 'opae-super-rsu-n3000-2x2x25G.noarch']
    You can ignore these errors.
  • Workaround: None.
  • Status: No planned fix.
Intel provided factory FPGA images may incur packet loss in FPGA when all ports are active and the packet size is not a multiple of 64.

  • The provided FPGA factory images are intended to demonstrate all interfaces. The internal clock rate is not set for dropless packet transfer for all packet sizes. For more details on expected packet drop measurements for the baseline images, refer to Appendix: Intel Provided FPGA Factory Image Packet Drop.
  • Workaround: While using an aggregated internal packet bus for your Intel® FPGA PAC N3000 design, set the clock rate to 285 MHz to have no packet drops for all packet sizes. The disaggregated and lightweight packet bus implementation options do not have this issue.
  • Status: No planned fix.
fpgainfo bmc may not return QSFP Supply Voltage if your QSFP module does not support supply voltage registers.

  • The Intel® MAX® 10 BMC obtains the QSFP module voltage sensor value from the Supply Voltage registers beginning at offset 26, as listed in the Free Side Monitoring Values, Table 6-7, of the SFF-8636 Specification for Management Interface for 4-lane Modules and Cables, rev 2.10a.
  • Workaround: If your QSFP module does not support this register, please disregard the value returned by the Intel® MAX® 10 BMC when using the fpgainfo bmc command.
  • Status: No planned fix.
OPAE fpgastats DEMUX_CDC_FIFO CNTR counts do not count correctly for 25G.

  • Software dependent accurate counts may be impacted by this issue.

  • Workaround: None
  • Status: This limitation is fixed in Software Update 2 and Software Update 3 for the Intel® Acceleration Stack for the Intel® FPGA PAC N3000.
4K to 2MB huge page allocations requests may be satisfied by 1GB pool Linux memory allocation even if you have reserved 2MB buffers and 1GB buffers.

  • An inefficient use of memory allocation can occur when a 2MB or less huge page allocation request is assigned to the 1GB buffer.

  • Workaround: None
  • Status: This limitation is fixed in Software Update 2 and Software Update 3 for the Intel® Acceleration Stack for the Intel® FPGA PAC N3000.
fpgainfo bmc reports the QSFPs as QSFP0 and QSFP1 instead of QSFP A and QSFP B.

  • QSFP0 Supply Voltage and QSFP0 Temperature are QSFP A Supply Voltage and QSFP A Temperature, respectively. QSFP1 Supply Voltage and QSFP1 Temperature are QSFP B Supply Voltage and QSFP B Temperature, respectively.
  • Status: This limitation is fixed in Software Update 2 and Software Update 3 for the Intel® Acceleration Stack for the Intel® FPGA PAC N3000.
The PCIe* link between the PEX 8747 PCIe* Switch and the Intel® Ethernet Conroller XL710 PCIe* end point downgrades to Gen1 width=0 and is unable to establish a link.

  • The probability of encountering this issue is fairly low. However, you may observe this issue during warm reboot or AC power cycle testing.
  • Workaround: Check the expected PCIe link speed and width between the PEX8747 PCIe Switch and the downstream Intel XL710. If one of the links reports Width x0, apply a card reset using rsu bmcing to recover.
  • Status: This limitation is fixed in NVM Update 8.10 (EtrackID = 0x8000a3e9) for PCIe Device 0D58.
During the server power-down process, PCIe errors may be reported between the PEX8747 PCIe ports and the downstream Intel® XL710 Ethernet Controllers. You may observe this issue during warm server reboot and AC Power Cycle stress testing. The observed errors are Replay Num Rollover and Replay Timer Timeout errors.
  • The issue is intermittent with a very low probability of occurring. The issue is only observed during the power-down phase. During the power-up phase, these PCIe errors are not present.
  • After confirming the errors during server power-down, if the PCIe errors cannot be masked, then system should ignore these errors.
  • Workaround: None.
  • Status: No planned fix.
Incorrect PLDM GetSensorReadings command response.

  • PLDM GetSensorReadings command response fields presentState and eventState are reported as “0x9” constantly indicating UpperCritical when the sensor is in a Normal state.
  • Workaround: None
  • Status: No planned fix.
GetPDR command returns scaled value for criticalHigh and fatalHigh fields.

  • In response to GetPDR PLDM message, the temperature thresholds are scaled by a factor of 2 in violation of th Platform Level Data Model (PLDM) for Platform Monitoring and Control Specification (Section 28.4 "Numeric Sensor PDR") which states for warningHigh, criticalHigh, and fatalHigh fields, the value is given directly in the specified units without the use of any conversion formula.

  • Workaround: None
  • Status: No planned fix.
MCTP Get Endpoint UUID command returns different UUID after reboot card.

Issuing a PLDM GetPDR command with a requestCount of 0 reports PLDM_BASE_CODE_ERROR_INVALID_DATA.

If you use the SetSensorThresholds command to set to an unsupported threshold field value a PLDM_BASE_CODE_ERROR_INVALID_DATA error is returned.

PLDM GetSensorThreshold does not return the same value sent using the SetSensorThreshold command.

  • Although the PLDM SetSensorThreshold sets the value correctly, the GetSensorThreshold reports the set _value-1.
  • Workaround: None
  • Status: No planned fix.
The GetPLDMVersion command reports success when TransferOperationFlag = GetNextPart.

  • Workaround: None
  • Status: No planned fix.
The PLDM command SetSensorThreshold reports PLDM_BASE_CODE_SUCCESS if you attempt to set thresholds for sensors 4 and 6 to 20 even though these sensors cannot be modified.

  • Workaround: None
  • Status: No planned fix.
The Intel® MAX® 10 BMC responds to MCTP GetMessageTypeSupport with a value of 0x2.

  • Because the Intel® MAX® 10 BMC supports only one message type besides the MCTP control message type, the GetMessageTypeSupport is supposed to report a value of 0x1 instead of 0x2.
  • Workaround: None
  • Status: No planned fix.
Level Two Title