You're doing great by digging into detailed sections of the **PCIe Base
Specification** — this level of understanding is *exactly* what many **VLSI and
protocol validation roles** demand.
Let’s break down the **Flow Control Initialization process** in a **clean,
practical, and interview-ready** way. I’ll also point out what you *really need to
know* to impress in a VLSI interview.
---
## ✅ **Why Flow Control (FC) Initialization?**
PCIe uses **Flow Control (FC)** to ensure that a sender doesn’t overwhelm the
receiver with more data than it can buffer. Before any TLPs (Transaction Layer
Packets) are sent, the **buffers must be advertised and synchronized** between both
sides of the link.
---
## 🎯 **When Does FC Initialization Happen?**
* **At Link start-up**, immediately after physical layer training.
* For **VC0**: Always initialized first, during entry into `DL_Init` state.
* For **VC1-7** (if used): Initialized when software enables them dynamically.
---
## 🔁 **Two Main FC Initialization States (per VC):**
| State | Purpose
|
| ---------- |
--------------------------------------------------------------------------------- |
| `FC_INIT1` | Send initial credit advertisements and collect credit info from the
link partner. |
| `FC_INIT2` | Confirm credit sync via additional DLLPs before allowing TLP
traffic. |
---
## 💡 **Practical View of Flow Control Initialization**
### ✅ `FC_INIT1`: Announce Your Buffer Sizes
> "Hey, I have these many credits. Please remember them."
### 📤 Transmitter Behavior
#### 🔹 **In Non-Flit Mode:**
Send 3 DLLPs (at least every 34 µs):
* `InitFC1-P` (Posted)
* `InitFC1-NP` (Non-Posted)
* `InitFC1-Cpl` (Completion)
#### 🔹 **In Flit Mode (PCIe Gen6+):**
Send 6 DLLPs:
* 3 dedicated: `InitFC1-P`, `InitFC1-NP`, `InitFC1-Cpl`
* 3 shared: `InitFC1-P (Shared)`, `InitFC1-NP (Shared)`, `InitFC1-Cpl (Shared)`
Each of these DLLPs carries:
* `HdrFC`, `HdrScale`
* `DataFC`, `DataScale`
These values advertise how much buffer space is available and whether **Scaled Flow
Control** is being used.
### ✅ Receiver Behavior
* Record each credit count (for P, NP, Cpl)
* Once all 3 (or 6) are received and recorded → set **flag FI1**
* **FI1 set → exit `FC_INIT1`, enter `FC_INIT2`**
---
## ✅ `FC_INIT2`: Confirm and Wait for Acknowledgment
> "I’m reminding you of the same credits again. Let’s sync."
### 📤 Transmitter Behavior
#### 🔹 Non-Flit Mode:
* Send same 3 DLLPs again: `InitFC2-P`, `InitFC2-NP`, `InitFC2-Cpl`
#### 🔹 Flit Mode:
* All 6 again (dedicated + shared)
Repeat every 34 µs.
### ✅ Receiver Behavior
* **No need to re-read credit values**, just acknowledge receipt
* Set **FI2** on:
* Receiving any `InitFC2` DLLP for the VC
* OR receiving any TLP or `UpdateFC DLLP` (used in normal flow control)
* **FI2 set → Exit `FC_INIT2`, now VCx is ready for normal operation**
---
## 📌 Summary Table
| **Mode** | **DLLPs Sent in FC\_INIT1/2** | **Credits** | **Exit FC\_INIT1
when...** | **Exit FC\_INIT2 when...** |
| -------- | ----------------------------- | ------------------ |
-------------------------- | ---------------------------- |
| Non-Flit | 3 (P, NP, Cpl) | Dedicated | All 3 received →
FI1 set | Any InitFC2 or TLP → FI2 set |
| Flit | 6 (3 Dedicated + 3 Shared) | Shared + Dedicated | All 6 received →
FI1 set | Same as above |
---
## 🔄 Scaled Flow Control: When & What?
* **Enabled only when both ends support it** (via capability exchange during link
up)
* If used:
* Values in `UpdateFC DLLPs` use `HdrScale` and `DataScale` (not just raw counts)
* These scale the advertised credits (e.g., a scale factor of 01b may mean *x4*
buffer units)
### 🧠 Real Interview Tips:
* Say: “Scaled FC is introduced for Gen6+ (Flit Mode) to compress credit info for
higher throughput.”
* Example: “If `HdrScale=01b` and `HdrFC=5`, the receiver is telling us it can
accept 20 headers.”
---
## 🛑 When Does This All Happen in the LTSSM?
| State | FC Event |
| ----------- | ---------------------------------------------------- |
| `DL_Init` | Enter `FC_INIT1` for VC0 |
| `DL_Active` | After both `FI1` and `FI2` set → TLPs allowed on VC0 |
| VCx Enabled | Enter `FC_INIT1` for that VC |
---
## ✅ Sample Interview Explanation (Use this!)
> "Before any TLPs can be sent, we need to synchronize flow control credits between
endpoints. This is done in two steps: first, in `FC_INIT1`, the sender announces
its credit buffer sizes via InitFC1 DLLPs. Once the receiver records all credit
values for Posted, Non-Posted, and Completion buffers, we move to `FC_INIT2`. Here,
InitFC2 DLLPs are sent as confirmation. When the receiver acknowledges by setting
FI2, TLP transmission can begin for that Virtual Channel. In Gen6’s Flit Mode, this
includes shared flow control with six DLLPs and optional scaled credits using
HdrScale and DataScale."
---
If you’d like, I can also prepare a **flowchart** or **practice Q\&A sheet** for
interviews. Would that help?
###################################################################################
##############################################################################
###################################################################################
##############################################################################
Great follow-up — and your confusion is **valid**! Let’s clear it up **step by
step**. You’ve hit a key point about how shared flow control works **across
multiple Virtual Channels (VCs)**.
---
## ✅ Core Point:
In **PCIe 6.0 (Flit Mode)**, the **shared credits are not sent *per VC* — they’re
sent *once for the whole group***.
> **Shared credits are "global" across all VCs** that support shared flow control —
unlike dedicated credits, which are still per VC.
---
## 🔸 Quick Recap of DLLPs in Flit Mode:
| Credit Type | Applies To | DLLP Name
| Sent Per VC? |
| ------------- | --------------------------------- |
------------------------------------------------------------------- |
------------------------ |
| **Dedicated** | Specific VC (e.g., VC0, VC1...) | `InitFC1-P`, `InitFC1-NP`,
`InitFC1-Cpl` | ✅ Yes |
| **Shared** | All VCs using shared flow control | `InitFC1-P [Shared]`,
`InitFC1-NP [Shared]`, `InitFC1-Cpl [Shared]` | ❌ No (Sent once for all) |
---
### 🔍 What Happens Practically:
Let’s say a Root Complex (RC) and Endpoint (EP) support **VC0 to VC3**, and shared
flow control is enabled.
1. During link training:
* For each VC (VC0, VC1, VC2, VC3), **3 dedicated DLLPs** are sent:
* e.g., `InitFC1-P`, `InitFC1-NP`, `InitFC1-Cpl` for **VC1**, and so on.
2. Then, **3 shared DLLPs are sent**:
* `InitFC1-P [Shared]`
* `InitFC1-NP [Shared]`
* `InitFC1-Cpl [Shared]`
👉 These 3 shared DLLPs are **broadcast** (not tied to any one VC) — and **all VCs
use the same shared credit pool** for their respective traffic types.
---
### 🧠 Now the Key Answer to Your Question:
> **Q: If I send 3 dedicated + 3 shared DLLPs to VC0, how does VC1/VC2/VC3 know
their credits?**
### ✅ Answer:
You're **not** sending 3 shared DLLPs **to VC0** — you're sending them to **the
link**, and **all VCs use them**.
The shared DLLPs are **not per VC** — **they’re global**.
So VC1, VC2, VC3 will **read the same shared credit info** (in those 3 shared
DLLPs) and **apply it to their own traffic types (P, NP, Cpl)** as needed.
---
## 📌 Visual Summary:
```
┌────────────┐ ┌────────────────────────────────┐
│ RC/EP Tx │────→ │ InitFC1-P (VC0) │
│ │────→ │ InitFC1-NP (VC0) │
│ │────→ │ InitFC1-Cpl (VC0) │
│ │────→ │ InitFC1-P [Shared] (ALL VCs) │
│ │────→ │ InitFC1-NP [Shared] (ALL VCs) │
│ │────→ │ InitFC1-Cpl [Shared] (ALL VCs)│
└────────────┘ └────────────────────────────────┘
→ VC1, VC2, VC3 all read the same 3 shared DLLPs
→ They also each receive their own 3 dedicated DLLPs
```
---
### 🧠 Bonus Tip for Interview:
You can say:
> The key benefit of shared flow control in PCIe 6.0 is that the shared DLLPs are
not tied to any single VC. They're sent once and apply across all Virtual Channels
that use shared resources, reducing redundant DLLPs and lowering link
initialization overhead.
---
Let me know if you'd like to do a **mini mock Q\&A** or get a visual diagram of
this!