18.104.22.168. SR-IOV Implementation
Accessing VF PCIe Information
- Monitor specific VF registers using the Configuration Intercept Interface
- Read/write specific VF registers using the Hard IP Reconfiguration Interface
VF IDs are calculated within F-Tile. User application has sideband signals rx_st_vf_num_o and rx_st_vf_active_o with the TLP to identify the associated VFs within the PFs.
When SR-IOV is enabled, the ARI capability is always enabled.
- tx_st_hdr_sn: must be set to 0
- tx_st_hdr_sn: tx_st_vf_active
- tx_st_hdr_sn[82:80]: tx_st_func_num[2:0]
- tx_st_hdr_sn[95:84]: tx_st_vf_num[11:0]
- rx_st_func_num_o = 0x1 indicating that a VF associated with PF1 is making the request.
- rx_st_vf_num_o = 0x3
- rx_st_vf_active_o = 1 indicating that VF3 of PF1 is the active VF.
- tx_st_hdr_sn = 0x1
- tx_st_hdr_sn[82:80] = 0x1
- tx_st_hdr_sn[95:84] = 0x3
VF Error Reporting
The VFs, with no AER support, are required to generate Non-Fatal error messages. The IP does not generate any error message. It is up to the user application logic to generate appropriate messages when specific error conditions occur. The F-Tile IP for PCIe makes necessary signals available to the user application logic to generate these messages. The Completion Timeout Interface and VF Error Flag Interface provide the necessary information to generate Non-Fatal error messages.
VF to PF Mapping
VF to PF mapping always starts from the lowest possible PF number. For instance, if the IP has 2 PFs, wherein PF0 has 64 VFs and PF1 has 16 VFs, VF1 to VF64 are mapped to PF0, and VF65 to VF80 are mapped to PF1.
Currently, the IP core only supports the following PF/VF combinations.
|Number of PFs||Number of VFs per PF (PF0/PF1/PF2/PF3/PF4/PF5/PF6/PF7)||Total VFs|
For example, the row that shows the combination of four PFs, 256 VFs, and the notation 256/0/0/0 in the Number of VFs per PF column indicates that all 256 VFs are mapped to PF0, while no VF is mapped to PF1, PF2 or PF3. SR-IOV permutations allow any PF to be assigned the initial VF allocation.