6.1. Addresses for Physical and Virtual Functions
The SR-IOV bridge creates a static address map to match the number of PF and VFs specified in the component GUI. For systems using multiple PFs and ARI, the PFs are stored sequentially so that the offset values are contiguous. For systems including both PFs and VFs, the PFs are stored sequentially, followed by the VFs. The offset for the VFs associated with each PF are also contiguous. You cannot change the stride and offset values. For example, in a system with 4 PFs, the VFs for PF0, start at address 4 and continue to N0 +3, where N0 is the number of VFs attached to PF0. The VFs for PF1 begin at N0 +4 and continue to (N0 + N1+3), and so on.
The SR-IOV bridge provides component-specific Avalon-ST interface input signals to identify the PF and VF for TX TLPs. When the requestor is a PF, the Application Layer should drive the PF number on tx_st_pf_num. When the requestor is a VF, the Application Layer should drive the PF number on tx_st_pf_num and VF number index on tx_st_vf_num. The SR-IOV bridge samples these numbers when tx_st_sop and tx_st_valid are both asserted. The SR-IOV bridge combines this information with the captured bus numbers and VF offset and stride settings of the PF, to construct the RID and insert it TLP header.
In the following tables, N0 , N1 , N2 , and N3 are the number of VFs attached to PF 0, 1, 2, and 3, respectively.
Did you find the information on this page useful?