ConfigurationRegisters

Ports and APIs

see Ports and APIs
Configuration Registers
  • Provide Type 00 Configuration Space Header in the PCIeApi to be used by devices (End Points). This includes some functionality handling the read/write actions automatically.
  • Provide Type 01 Configuration Space Header to be used by the PCIeRouter. This does not include any functionality. That is done in the Router.
  • TODO: Provide building automatically a Capability Pointer List and Capability Registers. ???





OUTDATED:



The PCIe configuration registers which each device or function has to provide are located in the PCIeAPI. That makes it ease for a user to prepare his device to support these registers.

ConfigRegisters.png Figure 1

Preferred options are marked with a (!) .

Options:

  • (!) Use a memory space to model the configuration space. Simple, optimal memory utilization, matches address bases usage in TLPs, but hard to use providing access to the device.
  • Use parameter variables for each register. Results in many many parameters but easier to use.

How detailed store registers? E.g. Command register (4 Bytes):

  1. (!) Store in an array (as in original register memory).
  2. : + Later can be modeled with memory objects
  3. : + Optimal memory utilization
  4. : + Incoming transactions (TLPs) can be mapped directly to memory.
  5. : - API methods have to know where which register is stored and how big it is
  6. : - bit operations if detailed API
  7. Store register Byte aligned in variables

(unsigned int) Command 

    - User has to do bit operations <br>
    + Storage effort (amount of variables) is managable
 2. Structs combining bits of a register
    + easy to use for the user <br>
    - huge ( ! ) amount of variables (400) have to be stored and made accessible
  1. struct sCommand {
  2.   bool Bus_Master_Enable = 0; // default=0
  3.   bool Special_Cycle_Enable = 0; // hardwired
  4.   bool Memoy_Write_and_Invalidate = 0; // hardwired
  5.   bool VGA_PAlette_Snoop = 0; // hardwired
  6.   bool Parity_Error_Response = 0; // default=0
  7.   bool IDSEL_Stepping_Wait_Cycle_control = 0; // hardwired
  8.   bool SERR_Enable = 0; // default=0
  9.   bool Fast_Back_to_Back_Transactions_Enable = 0; // hardwired
  10.   bool Interrupt_Disable = 0; // default=0
  11. };
  12. struct sStatus {
  13.   bool Interrupt_Status;
  14.   bool Capabilities_List; // hardwired
  15.   bool MHz_66_Capable; // hardwired
  16.   bool Fast_Back_to_Back_Transaction_Capable; // hardwired
  17.   bool Master_Data_Parity_Error;
  18.   bool DEVSEL_Timing; // hardwired
  19.   bool
  20. };

What type of API do we need on Endpoint (device) side?

  1. e.g.

gs_uint32 value  = mAPI.getConfReg(RegEnum Vendor_ID);
gs_uint64 value2 = mAPI.getConfReg64(RegEnum64 Base_Address); 

    with Vendor_ID as element of the enumeration RegEnum and    <br>
    with Base_Address as element of the enumeration RegEnum64   <br>
    - only some datatypes (e.g. gs_uint32, gs_uint8, gs_unit64) <br>
    - complex                                                   <br>
    + mapping to memory regions

 2. ˙4˙
    - very hard to use   <br>
    + no mapping to memory region needed (done by user)

 3. Directly use variables/structs ˙5˙
    + different data types possible   <br>
    + very straight forward to use    <br>
    - storage: ''large'' amount of variables <br>
    - no opportunity to avoid write to hardwired and special (base address) registers

 4. Access methods for each register / part of register
mAPI.ConfReg.get_Vendor_ID()
mAPI.ConfReg.set_Vendor_ID(0xFFA0) 
    and <br>
mAPI.ConfReg.get_Command_Bus_Master_Enable()
mAPI.ConfReg.set_Command_Bus_Master_Enable(true) 
    or <br>
mAPI.ConfReg.Command.get_Bus_Master_Enable()
mAPI.ConfReg.Command.set_Bus_Master_Enable(true) 
    - mapping to memory regions <br>

What type of API do we need at the transaction access side?

PCIeMasterAccess: 

  ConfigurationReadRequest, ConfigurationWriteRequest
Provide the address based access (as it is originally in the TLPs).

Implementation

Memory modeled with an array (unsigned char) (stored in the PCIeAPI).

Access to the Configuration Registers with an ConfRegAPI (kept inside the PCIeAPI).

The ConfRegAPI should be independent of the memory itself so that an observer is able to get the memory as gc_param and use the API to access it: Instantiate the ConfRegAPI with the memory array pointer or reference.

Parameters

PCI 3.0 registers:

  • Device_ID
  • Vendor_ID
  • Status
  • Command
  • Class_Code
  • Revision_ID
  • Header_Type
  • Capabilities_Pointer
  • Interrupt_Pin
  • Interrupt_Line
  • BIST
  • Master_Latency_Timer (=Latency_Timer)
  • Cache_Line_Size

Type 00 Header:

  • Base_Address_Registers (more of them! 6 x 4 Bytes)
  • Cardbus_CIS_Pointer
  • Subsystem_ID
  • Subsystem_Vendor_ID
  • Expansion_ROM_Base_Address
  • Max_Lat
  • Min_Gnt

Type 01 Header (Switch, Root Complex virtual PCI Bridges):

  • Base_address_Register (two: 2 x 4 Bytes)
  • Secondary_Latency_Timer
  • Subordinate_Bus_Number
  • Secondary_Bus_Number
  • Primary_Bus_Number
  • Secondary_Status
  • I_O_Limit
  • I_O_Base
  • Memory_Limit
  • Memory_Base
  • Prefetchable_Memory_Limit
  • Prefetchable_Memory_Base
  • Prefetchable_Base_Upper_32_Bits
  • Prefetchable_Limit_Upper_32_Bits
  • I_O_Limit_Upper_16_Bits
  • I_O_Base_Upper_16_Bits
  • Expansion_ROM_Base_Address
  • Bridge_Control

‹ ApiDetailsupPcieAddressing ›

Posted January 8th, 2008 by MarkBurton