Absolutely!
Here's a full set of answers to the **30 PCIe Configuration Space
Interview Questions** often asked in Cadence interviews, categorized by level:
---
## 🔹 **Basic-Level Questions**
1. **What is the purpose of the PCIe configuration space?**
The PCIe configuration space provides a standard interface through which the
software (e.g., BIOS, OS) can identify and configure PCIe devices. It includes
device IDs, vendor IDs, BARs, and capabilities.
2. **How many configuration space registers are there in a PCIe endpoint/function?
**
A PCIe function supports **4 KB** of configuration space:
* **First 256 bytes**: Standard PCI configuration registers.
* **Next 4 KB**: Extended configuration space (PCIe-specific capabilities).
3. **What are the sizes of Type 0 and Type 1 configuration headers?**
Both are **64 bytes** in size.
* **Type 0**: Used for endpoints.
* **Type 1**: Used for bridges (to route config TLPs downstream).
4. **What is the size of the configuration space in PCIe?**
Each function has **4 KB** of configuration space (4096 bytes).
5. **What are the important registers present in the PCIe configuration header?**
* Vendor ID, Device ID
* Command, Status
* Revision ID, Class Code
* BARs (0–5)
* Subsystem ID/Vendor ID
* Capability Pointer
6. **What are BARs (Base Address Registers), and what is their purpose?**
BARs define the memory or I/O address ranges assigned to the device by the host.
They are used for address decoding so the device knows when it is being accessed.
7. **What is the difference between a 32-bit and 64-bit BAR?**
* A **32-bit BAR** uses only one register.
* A **64-bit BAR** uses two adjacent 32-bit registers (low and high).
The LSB of the BAR indicates the type (00b for memory, 10b for 64-bit memory).
---
## 🔸 **Intermediate-Level Questions**
8. **How does a Root Complex access the configuration space of an endpoint?**
Through Configuration TLPs (`Cfg Read/Write Type 0 or Type 1`). The root complex
forms these packets and sends them downstream to configure devices.
9. **What is ECAM (Enhanced Configuration Access Mechanism), and how does it map to
configuration space?**
ECAM maps the entire configuration space into system memory address space,
allowing the CPU to perform memory-mapped accesses to config space using a physical
address:
```
Address = Base + Bus[20:16] + Device[15:11] + Function[10:8] + Offset[7:0]
```
10. **What is the role of the capability pointer in configuration space?**
It's a pointer in the standard config space that leads to the first capability
structure (e.g., MSI, PM). Capabilities are chained via "Next Capability Pointer."
11. **Explain how extended capabilities differ from standard capabilities in
PCIe.**
* **Standard capabilities**: Located in the first 256 bytes (legacy PCI
format).
* **Extended capabilities**: Located in the extended 4 KB config space,
starting at offset 0x100 and are 16-byte aligned.
12. **What happens when software tries to write to a read-only configuration
register?**
The device ignores the write. The config space remains unchanged, and the write
is silently dropped.
13. **How is configuration space accessed over PCIe? Which TLP type is used?**
Via **Configuration TLPs**:
* `Cfg Type 0`: For devices on the same bus.
* `Cfg Type 1`: For devices on different buses (traverses bridges).
14. **What are the limitations on the number of devices and functions due to
configuration space addressing?**
Max 256 buses, 32 devices per bus, 8 functions per device.
Total max = 256 × 32 × 8 = **65536 functions**.
15. **How do multifunction devices affect configuration space layout?**
Each function gets its own 4 KB configuration space. Function 0 includes a
**Multifunction bit** in the header to indicate the presence of other functions.
---
## 🔺 **Advanced/Debug and Verification-Level Questions**
16. **How do you verify correct configuration space implementation in a PCIe
endpoint?**
* Read and check default values (e.g., Vendor ID).
* Write to writable registers and read back.
* Check capability pointers and traverse the chain.
* Verify that BARs decode addresses correctly.
* Simulate config accesses via UVM/PCIe VIP.
17. **How would you test/verify that a PCIe device correctly handles BAR sizing and
decoding?**
* Write `0xFFFFFFFF` to the BAR.
* Read it back; the device clears size-indicating bits.
* Size = `~(read_value & mask) + 1`.
* Program a valid base address and verify address decode via memory access.
18. **Explain how you would detect incorrect ECAM mapping in a simulation or on
real silicon.**
* Access known Vendor/Device ID through ECAM address.
* If reads return `0xFFFF`, mapping is likely incorrect.
* Compare ECAM-calculated address with expected physical address.
19. **What is the significance of the Device/Vendor ID register? What if it's all
Fs?**
This register identifies the device. If it returns `0xFFFFFFFF`, the function
is either not implemented or the config access failed.
20. **What’s the flow for software to determine how much memory a device needs
using the BARs?**
* Write all 1s to BAR.
* Read back to get size mask.
* Clear size bits, invert, add 1.
* Program actual base address in that size range.
21. **Explain what happens when software accesses a non-existent function in
configuration space.**
The access fails silently or returns `0xFFFF_FFFF` as no device responds. No
completion TLP is sent (or returns UR).
22. **Can two devices respond to the same configuration space address? Why or why
not?**
No. Each device/function must have a unique configuration address assigned
during enumeration.
23. **In a UVM testbench, how would you generate a TLP to access configuration
space of a function?**
Create a `CfgRd0` or `CfgRd1` TLP with proper BDF (Bus-Dev-Func), offset, and
address fields. Use a PCIe VIP sequence to issue it and check for completion.
---
## **Practical/Hands-On Scenarios**
24. **Describe a UVM test you’d write to check capability list traversal in config
space.**
* Read the **Capability Pointer**.
* Follow each “Next Capability” pointer until it reaches 0.
* Verify presence of MSI, PM, PCIe caps.
* Check if IDs and structure lengths are valid.
25. **How do you simulate a config write to a BAR and check that it gets mapped
correctly in address space?**
* Write base address to BAR via `CfgWr`.
* Issue a memory write TLP to the mapped address.
* Check if DUT responds and decodes the address properly.
26. **Have you debugged a case where the config space was not responding? What was
the root cause?**
Common causes:
* Incorrect ECAM base address.
* Device not enumerated.
* Power/clock not enabled.
* Device responding with UR (Unsupported Request).
27. **Can you explain how PCIe enumeration uses the config space?**
BIOS/OS starts at Bus 0, Device 0, Function 0.
* Reads Vendor ID to detect devices.
* Recursively scans buses, devices, and functions.
* Assigns BARs and configures interrupts.
28. **What’s the role of the Class Code and Subclass Code in config space?**
Indicates the function of the device (e.g., network controller, storage).
Used by OS to load appropriate drivers.
29. **If a BAR reports that it needs 64KB of memory, how would you verify this in
simulation?**
* Write `0xFFFFFFFF` to BAR.
* Read back: e.g., `0xFFFF0000`
* Size = `~0xFFFF0000 + 1 = 64KB`
* Program a base address and check that only addresses within 64KB are decoded.
30. **What is a config completion TLP? What fields does it contain?**
A Completion TLP is a response to a config read. Contains:
* Completion Status
* Byte Count
* Lower Address
* Completion Data (e.g., value of requested register)
---
If you'd like a **UVM testbench structure** for generating config TLPs or verifying
BAR decoding, let me know—I can provide that as well.
