CB-PCI Express Base 5.0r1.0-2019-05-22

The following informative "changebar" versions of the PCI Express Base 5.0 Specification are available: CB-PCI_Express_Base_5.0r1.0-2019-05-22.html CB-PCI_Express_Base_5.0r1.0-2019-05-22.pdf <-- this file CB9-PCI_Express_Base_5.0r1.0-2019-05-22.html CB9-PCI_Express_Base_5.0r1.0-2019-05-22.pdf The CB documents compare Base 4.0 and Base 5.0. More specifically: * PCI Express Base Specification Revision 4.0 Version 1.0 (left) to * PCI Express Base Specification Revision 5.0 Version 1.0 (right) The CB9 documents compare Base 5.0/0.9 and Base 5.0/1.0. More specifically: * PCI Express Base Specification Revision 5.0 Version 0.9 (left) to * PCI Express Base Specification Revision 5.0 Version 1.0 (right) The compare was performed using a text compare tool. Changes to figures are not shown. HTML and PDF versions are provided. Both versions are derived from common source material but have different characteristics, and readers may wish to reference both. The NCB-PCI_Express_Base_5.0r1.0-2019-05-22.pdf is the normative version of this specification. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1 PCI Express® Base Specification Revision 4.0 Version 1.0 2 3 4.0-1.0-PUB — — PCI Express® Base Specification Revision 4.0 Version 1.0 September 27, 2017 5 7 PCI Express® Base Specification Revision 5.0 Version 1.0 8 9 9 10 PCI-SIG Working Draft 07 March 2018 11 10 22 May 2019 11 12 12 13 Copyright © 2018 PCI-SIG ® 14 13 Copyright © 2002-2019 PCI-SIG ® 14 15 15 PCI, PCI Express, PCIe, and PCI-SIG are trademarks or registered trademarks of PCI-SIG. All other product names are trademarks, registered trademarks, or servicemarks of their respective owners. 17 16 PCI, PCI Express, PCIe, and PCI-SIG are trademarks or registered trademarks of PCI-SIG. All other product names are trademarks, registered trademarks, or servicemarks of their respective owners. 17 18 19 5.0-1.0-PUB — PCI Express® Base Specification Revision 5.0 Version 1.0 6 PCI Express® Base Specification Revision 4.0 Version 1.0 September 27, 2017 8 16 4 5 6 7 PCI Express® Base Specification Revision 5.0 Version 1.0 2 3 4 1 18 Contact PCI-SIG Membership Services for questions about membership in the PCI-SIG or to obtain the latest revision of this specification. Contact PCI-SIG Technical Support for technical questions about this specification. 20 19 Contact PCI-SIG Membership Services for questions about membership in the PCI-SIG or to obtain the latest revision of this specification. Contact PCI-SIG Technical Support for technical questions about this specification. 20 21 21 22 22 Web Site 23 Web Site 23 173 2.2.8.5 Slot Power Limit Support 174 173 2.2.8.5 Slot Power Limit Support 174 175 2.2.8.6 Vendor_Defined Messages 176 175 2.2.8.6 Vendor_Defined Messages 176 177 2.2.8.6.1 PCI-SIG-Defined VDMs 178 177 2.2.8.6.1 PCI-SIG-Defined VDMs 178 179 2.2.8.6.2 LN Messages 180 179 2.2.8.6.2 LN Messages 180 181 2.2.8.6.3 Device Readiness Status (DRS) 181 Message 2.2.8.6.3 Device Readiness Status (DRS) Message 182 182 183 2.2.8.6.4 Function Readiness Status (FRS) 183 Message 184 185 184 2.2.8.6.5 Hierarchy ID Message 186 Page 1 2.2.8.6.5 Hierarchy ID Message 187 2.2.8.7 Ignored Messages 189 190 185 186 187 188 2.2.8.6.4 Function Readiness Status Message (FRS Message) 188 2.2.8.7 Ignored Messages 189 2.2.8.8 Latency Tolerance Reporting (LTR) Message 190 2.2.8.8 Latency Tolerance Reporting (LTR) Message /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 190 2.2.8.8 Latency Tolerance Reporting (LTR) Message 191 190 2.2.8.8 Latency Tolerance Reporting (LTR) Message 191 192 2.2.8.9 Optimized Buffer Flush/Fill (OBFF) Message 193 192 2.2.8.9 Optimized Buffer Flush/Fill (OBFF) Message 193 290 3.4.1 Flow Control Initialization State Machine Rules 291 290 3.4.1 Flow Control Initialization State Machine Rules 291 292 3.4.2 Scaled Flow Control 293 292 3.4.2 Scaled Flow Control 293 294 294 295 3.5 Data Link Layer Packets (DLLPs) 296 295 3.5 Data Link Layer Packets (DLLPs) 296 297 3.5.1 Data Link Layer Packet Rules 298 297 3.5.1 Data Link Layer Packet Rules 298 299 299 300 3.6 Data Integrity 301 300 3.6 Data Integrity Mechansisms 301 302 3.6.1 Introduction 303 302 3.6.1 Introduction 303 304 3.6.2 LCRC, Sequence Number, and Retry Management (TLP 304 Transmitter) 3.6.2 LCRC, Sequence Number, and Retry Management (TLP Transmitter) 305 305 306 3.6.2.1 LCRC and Sequence Number Rules (TLP 306 Transmitter) 3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter) 307 307 308 3.6.2.2 Handling of Received DLLPs 308 309 309 310 310 352 3.6.2.2 Handling of Received DLLPs 352 353 4.2.2.3.2 Transmitter Framing Requirements 354 353 4.2.2.3.2 Transmitter Framing Requirements 354 355 4.2.2.3.3 Receiver Framing Requirements 356 355 4.2.2.3.3 Receiver Framing Requirements 356 357 4.2.2.3.4 Recovery from Framing Errors 358 357 4.2.2.3.4 Recovery from Framing Errors 358 359 359 360 4.2.2.4 Scrambling 361 360 4.2.2.4 Scrambling 361 362 4.2.2.5 Loopback with 128b/130b Code 362 4.2.2.5 Precoding 363 364 363 4.2.2.6 Loopback with 128b/130b Code 365 364 366 365 4.2.3 Link Equalization Procedure for 8.0 GT/s and 367 Higher Data Rates 366 367 368 4.2.3.1 Rules for Transmitter Coefficients 368 369 4.2.3.2 Encoding of Presets 4.2.3.1 Rules for Transmitter Coefficients 371 4.2.3.2 Encoding of Presets 372 371 Page 2 369 370 370 372 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates 373 4.2.4 Link Initialization and Training 374 4.2.4 Link Initialization and Training /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 372 4.2.4 Link Initialization and Training 373 374 4.2.4 Link Initialization and Training 375 374 4.2.4.1 Training Sequences 375 376 4.2.4.1 Training Sequences 377 376 4.2.4.2 Electrical Idle Sequences 378 4.2.4.2 Alternate Protocol Negotiation 379 380 377 4.2.4.3 Electrical Idle Sequences (EIOS) 381 378 4.2.4.3 Inferring Electrical Idle 379 382 4.2.4.4 Inferring Electrical Idle 383 380 4.2.4.4 Lane Polarity Inversion 381 384 4.2.4.5 Lane Polarity Inversion 385 382 4.2.4.5 Fast Training Sequence (FTS) 383 386 4.2.4.6 Fast Training Sequence (FTS) 387 384 4.2.4.6 Start of Data Stream Ordered Set 388 4.2.4.7 Start of Data Stream Ordered Set (SDS Ordered Set) 385 389 386 4.2.4.7 Link Error Recovery 387 390 4.2.4.8 Link Error Recovery 391 388 4.2.4.8 Reset 389 392 4.2.4.9 Reset 393 390 4.2.4.8.1 Fundamental Reset 391 394 4.2.4.9.1 Fundamental Reset 395 392 4.2.4.8.2 Hot Reset 393 396 4.2.4.9.2 Hot Reset 397 394 398 395 4.2.4.9 Link Data Rate Negotiation 396 399 4.2.4.10 Link Data Rate Negotiation 400 397 4.2.4.10 Link Width and Lane Sequence Negotiation 398 401 4.2.4.11 Link Width and Lane Sequence Negotiation 402 399 4.2.4.10.1 Required and Optional Port Behavior 400 403 4.2.4.11.1 Required and Optional Port Behavior 404 401 405 402 4.2.4.11 Lane-to-Lane De-skew 403 406 4.2.4.12 Lane-to-Lane De-skew 407 404 4.2.4.12 Lane vs. Link Training 405 408 4.2.4.13 Lane vs. Link Training 409 406 410 407 4.2.5 Link Training and Status State Machine (LTSSM) 411 Descriptions 408 409 412 4.2.5.1 Detect 410 411 4.2.5.2 Polling 4.2.5.3 Configuration 418 Page 3 415 4.2.5.2 Polling Overview 417 4.2.5.3 Configuration Overview 418 4.2.5.4 Recovery 416 417 4.2.5.1 Detect Overview 416 414 415 413 414 412 413 4.2.5 Link Training and Status State Machine (LTSSM) Descriptions 419 4.2.5.4 Recovery Overview 420 4.2.5.5 L0 421 422 4.2.5.5 L0 Overview /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 418 422 419 423 4.2.5.6 L0s 420 4.2.5.6 L0s Overview 424 421 425 4.2.5.7 L1 422 4.2.5.7 L1 Overview 426 423 427 4.2.5.8 L2 424 4.2.5.8 L2 Overview 428 425 4.2.5.9 Disabled 426 429 4.2.5.9 Disabled Overview 430 427 4.2.5.10 Loopback 428 431 4.2.5.10 Loopback Overview 432 429 4.2.5.11 Hot Reset 430 433 4.2.5.11 Hot Reset Overview 434 431 435 432 4.2.6 Link Training and Status State Rules 433 436 4.2.6 Link Training and Status State Rules 437 434 4.2.6.1 Detect 435 438 4.2.6.1 Detect 439 436 4.2.6.1.1 Detect.Quiet 437 440 4.2.6.1.1 Detect.Quiet 441 438 4.2.6.1.2 Detect.Active 442 439 443 490 494 491 4.2.6.1.2 Detect.Active 495 492 4.2.6.4 Recovery 493 496 4.2.6.4 Recovery 497 494 4.2.6.4.1 Recovery.RcvrLock 495 498 4.2.6.4.1 Recovery.RcvrLock 499 496 4.2.6.4.2 Recovery.Equalization 497 500 4.2.6.4.2 Recovery.Equalization 501 498 4.2.6.4.2.1 Downstream Lanes 499 502 4.2.6.4.2.1 Downstream Lanes 503 500 4.2.6.4.2.1.1 4.2.6.4.2.1.1 Phase 1 of 504 Transmitter Equalization 4.2.6.4.2.1.1 Phase 1 of Transmitter Equalization 501 505 502 4.2.6.4.2.1.2 4.2.6.4.2.1.2 Phase 2 of 506 Transmitter Equalization 4.2.6.4.2.1.2 Phase 2 of Transmitter Equalization 503 507 504 4.2.6.4.2.1.3 4.2.6.4.2.1.3 Phase 3 of 508 Transmitter Equalization 4.2.6.4.2.1.3 Phase 3 of Transmitter Equalization 505 509 506 510 507 4.2.6.4.2.2 Upstream Lanes 508 511 4.2.6.4.2.2 Upstream Lanes 512 509 4.2.6.4.2.2.1 4.2.6.4.2.2.1 Phase 0 of 513 Transmitter Equalization 4.2.6.4.2.2.1 Phase 0 of Transmitter Equalization 510 514 511 4.2.6.4.2.2.2 4.2.6.4.2.2.2 Phase 1 of 515 Transmitter Equalization 4.2.6.4.2.2.2 Phase 1 of Transmitter Equalization 512 516 513 4.2.6.4.2.2.3 4.2.6.4.2.2.3 Phase 2 of Transmitter Equalization Page 4 517 4.2.6.4.2.2.3 Phase 2 of Transmitter Equalization /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 513 4.2.6.4.2.2.3 4.2.6.4.2.2.3 Phase 2 of 517 Transmitter Equalization 4.2.6.4.2.2.3 Phase 2 of Transmitter Equalization 514 518 515 4.2.6.4.2.2.4 4.2.6.4.2.2.4 Phase 3 of 519 Transmitter Equalization 4.2.6.4.2.2.4 Phase 3 of Transmitter Equalization 516 520 517 521 518 522 519 4.2.6.4.3 Recovery.Speed 520 523 4.2.6.4.3 Recovery.Speed 524 521 4.2.6.4.4 Recovery.RcvrCfg 522 525 4.2.6.4.4 Recovery.RcvrCfg 526 523 4.2.6.4.5 Recovery.Idle 527 524 528 525 529 782 4.2.6.4.5 Recovery.Idle 786 783 5.4.1.1 L0s ASPM State 784 787 5.4.1.1 L0s ASPM State 788 785 5.4.1.1.1 Entry into the L0s State 786 789 5.4.1.1.1 Entry into the L0s State 790 787 5.4.1.1.2 Exit from the L0s State 788 791 5.4.1.1.2 Exit from the L0s State 792 789 793 790 5.4.1.2 L1 ASPM State 791 794 5.4.1.2 L1 ASPM State 795 792 5.4.1.2.1 Entry into the L1 State 793 796 5.4.1.2.1 ASPM Entry into the L1 State 797 794 5.4.1.2.2 Exit from the L1 State 795 798 5.4.1.2.2 Exit from the L1 State 799 796 800 797 5.4.1.3 ASPM Configuration 798 801 5.4.1.3 ASPM Configuration 802 799 5.4.1.3.1 Software Flow for Enabling or 803 Disabling ASPM 800 804 801 805 802 819 806 5.5.3.3 L1.2.Exit 820 821 823 5.5.3.3.1 Exit from L1.2 825 826 823 827 824 5.5.3.3.1 Exit from L1.2 828 5.5.4 L1 PM Substates Configuration 826 827 5.5.3.3 L1.2.Exit 824 822 825 5.4.1.3.1 Software Flow for Enabling or Disabling ASPM 829 5.5.4 L1 PM Substates Configuration 830 5.5.5 L1 PM Substates Timing Parameters 828 831 5.5.5 L1 PM Substates Timing Parameters 832 833 5.5.6 Link Activation 834 829 830 Page 5 835 5.6 Auxiliary Power Support 836 5.6 Auxiliary Power Support /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 830 5.6 Auxiliary Power Support 831 832 5.7 Power Management System Messages and DLLPs 838 5.7 Power Management System Messages and DLLPs 839 5.8 PCI Function Power State Transitions 835 836 5.6 Auxiliary Power Support 837 833 834 836 840 5.8 PCI Function Power State Transitions 841 5.9 Function Power Management Policies 842 5.9 State Transition Recovery Time Requirements 837 838 5.9.1 State Transition Recovery Time Requirements 839 840 841 843 5.10 PCI Bridges and Power Management 842 843 5.10.1 Switches and PCI Express to PCI Bridges 6.5.7 PCI Express Endpoints 6.6.1 Conventional Reset 6.6.2 Function Level Reset (FLR) 1042 6.7.1 Elements of Hot-Plug 1044 6.7.1.1 Indicators 1047 1049 1051 6.7.1.1.1 Attention Indicator 1053 6.7.1.1.2 Power Indicator 1055 1056 1054 1057 1094 6.7.1.1 Indicators 6.7.1.1.1 Attention Indicator 6.7.1.1.2 Power Indicator 1097 6.7.3.1 Slot Events 1096 1098 6.7.3.1 Slot Events 1099 6.7.3.2 Command Completed Events 1098 1100 6.7.3.2 Command Completed Events 1101 6.7.3.3 Data Link Layer State Changed Events 1100 1102 6.7.3.3 Data Link Layer State Changed Events 1103 6.7.3.4 Software Notification of Hot-Plug Events 1104 1102 1105 1103 1106 Page 6 6.7.1 Elements of Hot-Plug 1054 1053 1101 6.7 PCI Express Native Hot-Plug 1052 1051 1099 6.6.2 Function Level Reset (FLR) 1050 1049 1097 6.6.1 Conventional Reset 1048 1047 1095 6.6 PCI Express Reset - Rules 1046 6.7 PCI Express Hot-Plug Support 1045 1052 1040 1045 1043 1050 6.5.7 PCI Express Endpoints 1043 1042 1048 6. System Architecture 1041 1040 1046 1037 1039 6.6 PCI Express Reset - Rules 1038 1044 852 1038 1036 1041 5.11 Power Management Events 851 6. System Architecture 1035 1039 849 850 848 1037 5.10.1 Switches and PCI Express to PCI Bridges 848 5.11 Power Management Events 847 1034 846 847 845 849 5.10 PCI Bridges and Power Management 845 844 846 844 6.7.3.4 Software Notification of Hot-Plug Events /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1103 1106 1104 6.7.4 Firmware Support for Hot-Plug 1107 6.7.4 System Firmware Intermediary (SFI) Support 1108 1109 6.7.4.1 SFI ERR_COR Event Signaling 1110 1111 6.7.4.2 SFI Downstream Port Filtering (DPF) 1112 1113 6.7.4.3 SFI CAM 1114 1115 6.7.4.4 SFI Interactions with Readiness Notifications 1105 1116 1106 6.7.5 Async Removal 1117 6.7.4.5 SFI Suppression of Hot-Plug Surprise Functionality 1118 1119 1120 6.7.5 Firmware Support for Hot-Plug 1121 1122 1107 6.7.6 Async Removal 1123 1108 1124 1109 6.8 Power Budgeting Capability 1110 1125 6.8 Power Budgeting Capability 1126 1111 6.8.1 System Power Budgeting Process Recommendations 1112 1127 6.8.1 System Power Budgeting Process Recommendations 1128 1113 1129 1114 6.9 Slot Power Limit Control 1115 1130 6.9 Slot Power Limit Control 1131 1116 6.10 Root Complex Topology Discovery 1125 1132 6.10 Root Complex Topology Discovery 1141 1126 6.12.1.2 ACS Functions in SR-IOV Capable and Multi- 1142 Function Devices 1127 1128 1143 6.12.1.3 Functions in Single-Function Devices 1129 1147 6.12.2 Interoperability 1148 6.12.3 ACS Peer-to-Peer Control Interactions 1134 1135 6.12.1.3 Functions in Single-Function Devices 1146 6.12.2 Interoperability 1132 1133 1144 1145 1130 1131 6.12.1.2 ACS Functions in SR-IOV Capable and MultiFunction Devices 1149 6.12.3 ACS Peer-to-Peer Control Interactions 1150 6.12.4 ACS Violation Error Handling 1151 6.12.4 ACS Enhanced Capability 1152 1153 1136 1137 6.12.5 ACS Redirection Impacts on Ordering Rules 1138 1139 1155 6.12.5.1 Completions Passing Posted Requests 1157 6.12.6.1 Completions Passing Posted Requests 1158 6.12.5.2 Requests Passing Posted Requests 1159 1142 1160 1143 1161 Page 7 6.12.6 ACS Redirection Impacts on Ordering Rules 1156 1140 1141 6.12.5 ACS Violation Error Handling 1154 6.12.6.2 Requests Passing Posted Requests /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1143 1161 1144 1162 1145 6.13 Alternative Routing-ID Interpretation (ARI) 1146 1163 6.13 Alternative Routing-ID Interpretation (ARI) 1164 1147 6.14 Multicast Operations 1148 1165 6.14 Multicast Operations 1166 1149 6.14.1 Multicast TLP Processing 1150 1167 6.14.1 Multicast TLP Processing 1168 1151 6.14.2 Multicast Ordering 1255 1169 6.14.2 Multicast Ordering 1273 1256 6.27 Flattening Portal Bridge (FPB) 1257 1274 6.27 Flattening Portal Bridge (FPB) 1275 1258 6.27.1 Introduction 1259 1276 6.27.1 Introduction 1277 1260 6.27.2 Hardware and Software Requirements 1261 1278 6.27.2 Hardware and Software Requirements 1279 1262 1280 1263 6.28 Vital Product Data (VPD) 1264 1281 6.28 Vital Product Data (VPD) 1282 1283 6.28.1 VPD Format 1284 1285 6.28.2 VPD Definitions 1286 1287 6.28.2.1 VPD Large and Small Resource Data Tags 1288 1289 6.28.2.2 Read-Only Fields 1290 1291 6.28.2.3 Read/Write Fields 1292 1293 6.28.2.4 VPD Example 1294 1295 1296 1265 6.29 Native PCIe Enclosure Management 1266 1297 6.29 Native PCIe Enclosure Management 1298 1299 6.30 Conventional PCI Advanced Features Operation 1300 1267 1301 1268 7. Software Initialization and Configuration 1269 1302 7. Software Initialization and Configuration 1303 1270 7.1 Configuration Topology 1271 1304 7.1 Configuration Topology 1305 1272 7.2 PCI Express Configuration Mechanisms 1273 1306 7.2 PCI Express Configuration Mechanisms 1307 1274 7.2.1 PCI-compatible Configuration Mechanism 1275 1308 7.2.1 PCI-compatible Configuration Mechanism 1309 1276 7.2.2 PCI Express Enhanced Configuration Access 1310 Mechanism (ECAM) 1277 1278 1279 Page 8 7.2.2 PCI Express Enhanced Configuration Access Mechanism (ECAM) 1311 7.2.2.1 Host Bridge Requirements 1312 1313 7.2.2.1 Host Bridge Requirements /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1279 1313 1280 7.2.2.2 PCI Express Device Requirements 1281 1314 7.2.2.2 PCI Express Device Requirements 1315 1282 1316 1283 7.2.3 Root Complex Register Block 1284 1317 7.2.3 Root Complex Register Block (RCRB) 1318 1285 1319 1286 7.3 Configuration Transaction Rules 1287 1320 7.3 Configuration Transaction Rules 1321 1288 7.3.1 Device Number 1289 1322 7.3.1 Device Number 1323 1290 7.3.2 Configuration Transaction Addressing 1291 1324 7.3.2 Configuration Transaction Addressing 1325 1292 7.3.3 Configuration Request Routing Rules 1293 1326 7.3.3 Configuration Request Routing Rules 1327 1328 1362 1329 7.5.1.1.13 Interrupt Pin Register (Offset 3Dh) 1330 1363 7.5.1.1.13 Interrupt Pin Register (Offset 3Dh) 1364 1331 7.5.1.1.14 Error Registers 1332 1365 7.5.1.1.14 Error Registers 1366 1333 1367 1334 7.5.1.2 Type 0 Configuration Space Header 1335 1368 7.5.1.2 Type 0 Configuration Space Header 1369 1336 7.5.1.2.1 Base Address Registers (Offset 10h - 1370 24h) 7.5.1.2.1 Base Address Registers (Offset 10h 24h) 1337 1371 1338 7.5.1.2.2 Cardbus CIS Pointer (Offset 28h) 1372 7.5.1.2.2 Cardbus CIS Pointer Register (Offset 28h) 1339 1340 1373 7.5.1.2.3 Subsystem Vendor ID register/ Subsystem ID register (Offset 2Ch/2Eh) 1341 1374 7.5.1.2.3 Subsystem Vendor ID Register/ Subsystem ID Register (Offset 2Ch/2Eh) 1375 1342 7.5.1.2.4 Expansion ROM Base Address Register 1376 (Offset 30h) 7.5.1.2.4 Expansion ROM Base Address Register (Offset 30h) 1343 1377 1344 7.5.1.2.5 Min_Gnt Register/Max_Lat Register 1378 (Offset 3Eh/3Fh) 7.5.1.2.5 Min_Gnt Register/Max_Lat Register (Offset 3Eh/3Fh) 1345 1379 1346 1380 1347 7.5.1.3 Type 1 Configuration Space Header 1348 1381 7.5.1.3 Type 1 Configuration Space Header 1382 1349 7.5.1.3.1 Base Address Registers (Offset 1383 10h-14h) 7.5.1.3.1 Type 1 Base Address Registers (Offset 10h-14h) 1350 1384 1351 7.5.1.3.2 Primary Bus Number Register (Offset 1385 18h) 7.5.1.3.2 Primary Bus Number Register (Offset 18h) 1352 1386 1353 7.5.1.3.3 Secondary Bus Number Register (Offset 1387 19h) 1354 Page 9 7.5.1.3.3 Secondary Bus Number Register (Offset 19h) 1388 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1354 1388 1355 7.5.1.3.4 Subordinate Bus Number Register 1389 (Offset 1Ah) 1356 1390 1357 7.5.1.3.5 Secondary Latency Timer (Offset 1Bh) 1358 1391 7.5.1.3.6 I/O Base/I/O Limit Registers(Offset 1393 1Ch/1Dh) 7.5.1.3.7 Secondary Status Register (Offset 1395 1Eh) 7.5.1.3.7 Secondary Status Register (Offset 1Eh) 1362 1396 1363 7.5.1.3.8 Memory Base Register/Memory Limit 1397 Register(Offset 20h/22h) 7.5.1.3.8 Memory Base Register/Memory Limit Register(Offset 20h/22h) 1364 1398 7.5.1.3.9 Prefetchable Memory Base/Prefetchable Memory Limit Registers (Offset 24h/26h) 1366 1399 7.5.1.3.9 Prefetchable Memory Base/Prefetchable Memory Limit Registers (Offset 24h/26h) 1400 7.5.1.3.10 Prefetchable Base Upper 32 Bits/ Prefetchable Limit Upper 32 Bits Registers (Offset 28h/2Ch) 1368 1369 7.5.1.3.6 I/O Base/I/O Limit Registers(Offset 1Ch/1Dh) 1361 1367 7.5.1.3.5 Secondary Latency Timer (Offset 1Bh) 1392 1359 1365 7.5.1.3.4 Subordinate Bus Number Register (Offset 1Ah) 1401 7.5.1.3.10 Prefetchable Base Upper 32 Bits/ Prefetchable Limit Upper 32 Bits Registers (Offset 28h/2Ch) 1402 7.5.1.3.11 I/O Base Upper 16 Bits/I/O Limit Upper 16 Bits Registers (Offset 30h/32h) 1370 1403 7.5.1.3.11 I/O Base Upper 16 Bits/I/O Limit Upper 16 Bits Registers (Offset 30h/32h) 1404 1371 7.5.1.3.12 Expansion ROM Base Address (Offset 1405 38h) 7.5.1.3.12 Expansion ROM Base Address Register (Offset 38h) 1372 1406 1373 7.5.1.3.13 Bridge Control Register (Offset 1407 3Eh) 7.5.1.3.13 Bridge Control Register (Offset 3Eh) 1374 1408 1375 1409 1376 1410 1377 7.5.2 PCI Power Management Capability Structure 1378 1411 7.5.2 PCI Power Management Capability Structure 1412 1379 7.5.2.1 Power Management Capabilities Register 1413 (Offset 00h) 7.5.2.1 Power Management Capabilities Register (Offset 00h) 1380 1414 1381 7.5.2.2 Power Management Control/Status Register 1415 (Offset 04h) 7.5.2.2 Power Management Control/Status Register (Offset 04h) 1460 1494 1461 7.7.1.7 Mask Bits Register for MSI (Offset 0Ch or 1495 10h 7.7.1.7 Mask Bits Register for MSI (Offset 0Ch or 10h 1462 1496 1463 7.7.1.8 Pending Bits Register for MSI (Offset 10h 1497 or 14h) 7.7.1.8 Pending Bits Register for MSI (Offset 10h or 14h) 1464 1498 1465 1499 1466 7.7.2 MSI-X Capability and Table Structure 1467 1500 7.7.2 MSI-X Capability and Table Structure 1501 1468 7.7.2.1 MSI-X Capability Header (Offset 00h) 1469 1502 7.7.2.1 MSI-X Capability Header (Offset 00h) 1503 1470 7.7.2.2 Message Control Register for MSI-X (Offset 04h) Page 10 1504 7.7.2.2 Message Control Register for MSI-X (Offset 02h) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1470 7.7.2.2 Message Control Register for MSI-X (Offset 1504 04h) 1471 1505 1472 7.7.2.3 Table Offset/Table BIR Register for MSI-X 1506 (Offset 04h) 1507 1474 7.7.2.4 PBA Offset/PBA BIR Register for MSI-X 1508 (Offset 08h) 7.7.2.4 PBA Offset/PBA BIR Register for MSI-X (Offset 08h) 1475 1509 1476 7.7.2.5 Message Address Register for MSI-X Table 1510 Entries 7.7.2.5 Message Address Register for MSI-X Table Entries 1477 1511 1478 7.7.2.6 Message Upper Address Register for MSI-X 1512 Table Entries 7.7.2.6 Message Upper Address Register for MSI-X Table Entries 1479 1513 1480 7.7.2.7 Message Data Register for MSI-X Table 1514 Entries 7.7.2.7 Message Data Register for MSI-X Table Entries 1515 7.7.5.4 16.0 GT/s Status Register (Offset 0Ch) 1516 1549 7.7.5.4 16.0 GT/s Status Register (Offset 0Ch) 1550 1517 7.7.5.5 16.0 GT/s Local Data Parity Mismatch Status 1551 Register (Offset 10h) 7.7.5.5 16.0 GT/s Local Data Parity Mismatch Status Register (Offset 10h) 1518 1552 7.7.5.6 16.0 GT/s First Retimer Data Parity Mismatch Status Register (Offset 14h) 1520 1521 7.7.2.3 Table Offset/Table BIR Register for MSI-X (Offset 04h) 1473 1519 7.7.2.2 Message Control Register for MSI-X (Offset 02h) 1553 7.7.5.6 16.0 GT/s First Retimer Data Parity Mismatch Status Register (Offset 14h) 1554 7.7.5.7 16.0 GT/s Second Retimer Data Parity Mismatch Status Register (Offset 18h) 1522 1555 7.7.5.7 16.0 GT/s Second Retimer Data Parity Mismatch Status Register (Offset 18h) 1556 1523 7.7.5.8 Physical Layer 16.0 GT/s Reserved (Offset 1557 1Ch) 7.7.5.8 Physical Layer 16.0 GT/s Reserved (Offset 1Ch) 1524 1558 1525 7.7.5.9 16.0 GT/s Lane Equalization Control 1559 Register (Offset 20h ) 7.7.5.9 16.0 GT/s Lane Equalization Control Register (Offsets 20h to 3Ch) 1560 1561 1562 7.7.6 Physical Layer 32.0 GT/s Extended Capability 1563 1564 7.7.6.1 Physical Layer 32.0 GT/s Extended Capability Header (Offset 00h) 1565 1566 7.7.6.2 32.0 GT/s Capabilities Register (Offset 04h) 1567 1568 7.7.6.3 32.0 GT/s Control Register (Offset 08h) 1569 1570 1526 7.7.6.4 32.0 GT/s Status Register (Offset 0Ch) 1571 1572 7.7.6.5 Received Modified TS Data 1 Register (Offset 10h) 1527 1573 1528 7.7.6 Lane Margining at the Receiver Extended Capability Page 11 1574 7.7.6.6 Received Modified TS Data 2 Register (Offset 14h) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1528 7.7.6 Lane Margining at the Receiver Extended 1574 Capability 1529 1530 7.7.6.6 Received Modified TS Data 2 Register (Offset 14h) 1575 7.7.6.1 Lane Margining at the Receiver Extended Capability Header (Offset 00h) 1531 1576 7.7.6.7 Transmitted Modified TS Data 1 Register (Offset 18h) 1577 1532 7.7.6.2 Margining Port Capabilities Register 1578 (Offset 04h) 7.7.6.8 Transmitted Modified TS Data 2 Register (Offset 1Ch) 1533 1579 1534 7.7.6.3 Margining Port Status Register (Offset 1580 06h) 7.7.6.9 32.0 GT/s Lane Equalization Control Register (Offset 20h) 1535 1581 1536 7.7.6.4 Margining Lane Control Register (Offset 08h) 1537 1582 1538 7.7.6.5 Margining Lane Status Register (Offset 1583 0Ah) 7.7.7 Lane Margining at the Receiver Extended Capability 1539 1584 1585 1540 7.7.7.1 Lane Margining at the Receiver Extended Capability Header (Offset 00h) 1586 1541 7.7.7 ACS Extended Capability 1587 7.7.7.2 Margining Port Capabilities Register (Offset 04h) 1542 1588 1543 7.7.7.1 ACS Extended Capability Header (Offset 1589 00h) 7.7.7.3 Margining Port Status Register (Offset 06h) 1544 1590 1545 7.7.7.2 ACS Capability Register (Offset 04h) 1591 7.7.7.4 Margining Lane Control Register (Offset 08h) 1546 1592 1547 7.7.7.3 ACS Control Register (Offset 06h) 1593 7.7.7.5 Margining Lane Status Register (Offset 0Ah) 1548 1594 1549 7.7.7.4 Egress Control Vector Register (Offset 1595 1596 08h) 7.7.8 ACS Extended Capability 1597 1598 7.7.8.1 ACS Extended Capability Header (Offset 00h) 1599 1600 7.7.8.2 ACS Capability Register (Offset 04h) 1601 1602 7.7.8.3 ACS Control Register (Offset 06h) 1603 1604 7.7.8.4 Egress Control Vector Register (Offset 08h) 1550 1605 1551 1606 1552 1553 1607 7.8 Common PCI and PCIe Capabilities 1554 1555 Page 12 1608 7.8 Common PCI and PCIe Capabilities 1609 7.8.1 Power Budgeting Extended Capability 1610 7.8.1 Power Budgeting Extended Capability /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1555 7.8.1 Power Budgeting Extended Capability 1556 1610 7.8.1 Power Budgeting Extended Capability 1611 1557 7.8.1.1 Power Budgeting Extended Capability Header 1612 (Offset 00h) 7.8.1.1 Power Budgeting Extended Capability Header (Offset 00h) 1558 1613 1559 7.8.1.2 Power Budgeting Data Select Register 1614 (Offset 04h) 1575 7.8.1.2 Power Budgeting Data Select Register (Offset 04h) 7.8.3 L1 PM Substates Extended Capability 1576 1630 7.8.3 L1 PM Substates Extended Capability 1631 1577 7.8.3.1 L1 PM Substates Extended Capability Header 1632 (Offset 00h) 7.8.3.1 L1 PM Substates Extended Capability Header (Offset 00h) 1578 1633 1579 7.8.3.2 L1 PM Substates Capabilities Register 1634 (Offset 04h) 7.8.3.2 L1 PM Substates Capabilities Register (Offset 04h) 1580 1635 1581 7.8.3.3 L1 PM Substates Control 1 Register (Offset 1636 08h) 7.8.3.3 L1 PM Substates Control 1 Register (Offset 08h) 1582 1637 1583 7.8.3.4 L1 PM Substates Control 2 Register (Offset 1638 0Ch) 7.8.3.4 L1 PM Substates Control 2 Register (Offset 0Ch) 1584 1639 1640 7.8.3.5 L1 PM Substates Status Register (Offset 10h) 1641 1585 1642 1586 7.8.4 Advanced Error Reporting Extended Capability 1587 1588 1643 7.8.4 Advanced Error Reporting Extended Capability 1644 7.8.4.1 Advanced Error Reporting Extended Capability Header (Offset 00h) 1589 1645 7.8.4.1 Advanced Error Reporting Extended Capability Header (Offset 00h) 1646 1590 7.8.4.2 Uncorrectable Error Status Register (Offset 1647 04h) 7.8.4.2 Uncorrectable Error Status Register (Offset 04h) 1591 1648 1592 7.8.4.3 Uncorrectable Error Mask Register (Offset 1649 08h) 7.8.4.3 Uncorrectable Error Mask Register (Offset 08h) 1593 1650 1594 7.8.4.4 Uncorrectable Error Severity Register 1651 (Offset 0Ch) 7.8.4.4 Uncorrectable Error Severity Register (Offset 0Ch) 1603 1660 1604 7.8.4.9 Root Error Command Register (Offset 2Ch) 1605 1661 7.8.4.9 Root Error Command Register (Offset 2Ch) 1662 1606 7.8.4.10 Root Error Status Register (Offset 30h) 1607 1663 7.8.4.10 Root Error Status Register (Offset 30h) 1664 1608 7.8.4.11 Error Source Identification Register 1665 (Offset 34h) 1609 1610 1666 7.8.4.12 TLP Prefix Log Register (Offset 38h) 1611 1614 Page 13 1667 7.8.4.12 TLP Prefix Log Register (Offset 38h) 1668 1612 1613 7.8.4.11 Error Source Identification Register (Offset 34h) 1669 7.8.5 Enhanced Allocation (EA) Capability Structure 1670 1671 7.8.5 Enhanced Allocation Capability Structure (EA) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1614 1671 1615 7.8.5.1 Enhanced Allocation Capability First DW 1672 (Offset 00h) 7.8.5.1 Enhanced Allocation Capability First DW (Offset 00h) 1616 1673 1617 7.8.5.2 Enhanced Allocation Per-Entry Format 1674 7.8.5.2 Enhanced Allocation Capability Second DW (Offset 04h) 1675 [Type 1 Functions Only] 1676 1677 7.8.5.3 Enhanced Allocation Per-Entry Format (Offset 04h or 08h) 1618 1678 1619 1679 1620 7.8.6 Resizable BAR Extended Capability 1621 1680 1622 7.8.6.1 Resizable BAR Extended Capability Header 1682 (Offset 00h) 1683 1624 7.8.6.2 Resizable BAR Capability Register 1625 1684 7.8.6.2 Resizable BAR Capability Register 1685 1626 7.8.6.3 Resizable BAR Control Register 1627 1686 7.8.6.3 Resizable BAR Control Register 1687 1792 1852 1793 7.9.9.4 Root Complex Link Status Register (Offset 1853 0Ah) 7.9.9.4 Root Complex Link Status Register (Offset 0Ah) 1794 1854 1795 1855 7.9.10 Root Complex Event Collector Endpoint Association Extended Capability 1797 1798 7.8.6.1 Resizable BAR Extended Capability Header (Offset 00h) 1623 1796 7.8.6 Resizable BAR Extended Capability 1681 1856 7.9.10 Root Complex Event Collector Endpoint Association Extended Capability 1857 7.9.10.1 Root Complex Event Collector Endpoint Association Extended Capability Header (Offset 00h) 1799 1858 7.9.10.1 Root Complex Event Collector Endpoint Association Extended Capability Header (Offset 00h) 1859 1800 7.9.10.2 Association Bitmap for RCiEPs (Offset 1860 04h) 7.9.10.2 Association Bitmap for RCiEPs (Offset 04h) 1801 1861 1862 7.9.10.3 RCEC Associated Bus Numbers Register (Offset 08h) 1863 1802 1864 1803 7.9.11 Multicast Extended Capability 1804 1865 7.9.11 Multicast Extended Capability 1866 1805 7.9.11.1 Multicast Extended Capability Header 1867 (Offset 00h) 7.9.11.1 Multicast Extended Capability Header (Offset 00h) 1806 1868 1807 7.9.11.2 Multicast Capability Register (Offset 1869 04h) 1808 1809 1870 7.9.11.3 Multicast Control Register (Offset 06h) 1810 1811 1896 Page 14 7.9.11.2 Multicast Capability Register (Offset 04h) 1871 7.9.11.3 Multicast Control Register (Offset 06h) 1872 7.9.11.4 MC_Base_Address Register (Offset 08h) 1873 1958 7.9.11.4 MC_Base_Address Register (Offset 08h) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1896 1897 1958 7.9.17.1 Readiness Time Reporting Extended Capability Header (Offset 00h) 1898 1959 7.9.17.1 Readiness Time Reporting Extended Capability Header (Offset 00h) 1960 1899 7.9.17.2 Readiness Time Reporting 1 Register 1961 (Offset 04h) 7.9.17.2 Readiness Time Reporting 1 Register (Offset 04h) 1900 1962 1901 7.9.17.3 Readiness Time Reporting 2 Register 1963 (Offset 08h) 7.9.17.3 Readiness Time Reporting 2 Register (Offset 08h) 1902 1964 1903 1965 1904 7.9.18 Hierarchy ID Extended Capability 1905 1966 7.9.18 Hierarchy ID Extended Capability 1967 1906 7.9.18.1 Hierarchy ID Extended Capability Header 1968 7.9.18.1 Hierarchy ID Extended Capability Header (Offset 00h) 1907 1969 1908 7.9.18.2 Hierarchy ID Status Register 1909 7.9.18.2 Hierarchy ID Status Register (Offset 04h) 1971 1910 7.9.18.3 Hierarchy ID Data Register 1911 1972 7.9.18.3 Hierarchy ID Data Register (Offset 08h) 1973 1912 7.9.18.4 Hierarchy ID GUID 1 Register 1913 1974 7.9.18.4 Hierarchy ID GUID 1 Register (Offset 0Ch) 1975 1914 7.9.18.5 Hierarchy ID GUID 2 Register 1915 1976 7.9.18.5 Hierarchy ID GUID 2 Register (Offset 10h) 1977 1916 7.9.18.6 Hierarchy ID GUID 3 Register 1917 1978 7.9.18.6 Hierarchy ID GUID 3 Register (Offset 14h) 1979 1918 7.9.18.7 Hierarchy ID GUID 4 Register 1919 1980 7.9.18.7 Hierarchy ID GUID 4 Register (Offset 18h) 1981 1920 7.9.18.8 Hierarchy ID GUID 5 Register 1921 1982 7.9.18.8 Hierarchy ID GUID 5 Register (Offset 1Ch) 1983 1922 1984 1923 7.9.19 Vital Product Data Capability (VPD Capability) 1924 1985 7.9.19 Vital Product Data Capability (VPD Capability) 1986 1925 7.9.19.1 VPD Address Register 1926 1987 7.9.19.1 VPD Address Register 1988 1927 7.9.19.2 VPD Data Register 1928 1989 7.9.19.2 VPD Data Register 1990 1929 1930 1970 1991 7.9.20 Native PCIe Enclosure Management Extended Capability (NPEM Extended Capability) 1931 1992 7.9.20 Native PCIe Enclosure Management Extended Capability (NPEM Extended Capability) 1993 1932 7.9.20.1 NPEM Extended Capability Header (Offset 1994 00h) 1933 1934 1995 7.9.20.2 NPEM Capability Register (Offset 04h) 1935 1936 1996 7.9.20.3 NPEM Control Register (Offset 08h) 1998 7.9.20.3 NPEM Control Register (Offset 08h) 1999 7.9.20.4 NPEM Status Register (Offset 0Ch) 2000 1939 2001 1940 2002 Page 15 7.9.20.2 NPEM Capability Register (Offset 04h) 1997 1937 1938 7.9.20.1 NPEM Extended Capability Header (Offset 00h) 7.9.20.4 NPEM Status Register (Offset 0Ch) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1940 2002 2003 7.9.21 Alternate Protocol Extended Capability 2004 2005 7.9.21.1 Alternate Protocol Extended Capability Header (Offset 00h) 2006 2007 7.9.21.2 Alternate Protocol Capabilities Register (Offset 04h) 2008 2009 7.9.21.3 Alternate Protocol Control Register (Offset 08h) 2010 2011 7.9.21.4 Alternate Protocol Data 1 Register (Offset 0Ch) 2012 2013 7.9.21.5 Alternate Protocol Data 2 Register (Offset 10h) 2014 2015 7.9.21.6 Alternate Protocol Selective Enable Mask Register (Offset 14h) 2016 2017 2018 7.9.22 Conventional PCI Advanced Features Capability (AF) 2019 2020 7.9.22.1 Advanced Features Capability Header (Offset 00h) 2021 2022 7.9.22.2 AF Capabilities Register (Offset 03h) 2023 2024 7.9.22.3 Conventional PCI Advanced Features Control Register (Offset 04h) 2025 2026 7.9.22.4 AF Status Register (Offset 05h) 2027 2028 2029 7.9.23 SFI Extended Capability 2030 2031 7.9.23.1 SFI Extended Capability Header (Offset 00h) 2032 2033 7.9.23.2 SFI Capability Register (Offset 04h) 2034 2035 7.9.23.3 SFI Control Register (Offset 06h) 2036 2037 7.9.23.4 SFI Status Register (Offset 08h) 2038 2039 7.9.23.5 SFI CAM Address Register (Offset 0Ch) 2040 2041 2042 Page 16 7.9.23.6 SFI CAM Data Register (Offset 10h) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2042 2043 2044 7.9.24 Subsystem ID and Sybsystem Vendor ID Capability 2045 1941 2046 1942 2047 1943 8. Electrical Sub-Block 1944 2048 8. Electrical Sub-Block 2049 1945 8.1 Electrical Specification Introduction 1946 2050 8.1 Electrical Specification Introduction 2051 1947 8.2 Interoperability Criteria 1948 2052 8.2 Interoperability Criteria 2053 1949 8.2.1 Data Rates 1950 2054 8.2.1 Data Rates 2055 1957 2062 1958 8.3.1.1 Breakout and Replica Channels 1959 2063 8.3.1.1 Breakout and Replica Channels 2064 1960 2065 1961 8.3.2 Voltage Level Definitions 1962 2066 8.3.2 Voltage Level Definitions 2067 1963 8.3.3 Tx Voltage Parameters 1964 2068 8.3.3 Tx Voltage Parameters 2069 1965 8.3.3.1 2.5 and 5.0 GT/s Transmitter Equalization 1966 2070 8.3.3.1 2.5 and 5.0 GT/s Transmitter Equalization 2071 1967 8.3.3.2 8.0 and 16.0 GT/s Transmitter Equalization 2072 8.3.3.2 8.0, 16.0, and 32.0 GT/s Transmitter Equalization 1968 2073 1969 8.3.3.3 Tx Equalization Presets 1970 2074 8.3.3.3 Tx Equalization Presets 2075 1971 8.3.3.4 Measuring Tx Equalization for 2.5 GT/s and 2076 5.0 GT/s 8.3.3.4 Measuring Tx Equalization for 2.5 GT/s and 5.0 GT/s 1972 2077 1973 8.3.3.5 Measuring Presets at 8.0 GT/s and 16.0 GT/s 2078 8.3.3.5 Measuring Presets at 8.0 GT/s, 16.0 GT/s, and 32.0 GT/s 1974 2079 1975 8.3.3.6 Method for Measuring VTX-DIFF-PP at 2.5 GT/ 2080 s and 5.0 GT/s 8.3.3.6 Method for Measuring VTX-DIFF-PP at 2.5 GT/ s and 5.0 GT/s 1976 2081 1977 8.3.3.7 Method for Measuring VTX-DIFF-PP at 8.0 GT/ 2082 s and 16.0 GT/s 1978 8.3.3.7 Method for Measuring VTX-DIFF-PP at 8.0 GT/ s, 16.0 GT/s, and 32.0 GT/s 2083 1979 8.3.3.8 Coefficient Range and Tolerance 1980 2084 8.3.3.8 Coefficient Range and Tolerance 2085 1981 8.3.3.9 EIEOS and VTX-EIEOS-FS and VTX-EIEOS-RS 2086 Limits 8.3.3.9 EIEOS and VTX-EIEOS-FS and VTX-EIEOS-RS Limits 1982 2087 1983 8.3.3.10 Reduced Swing Signaling 1984 2088 8.3.3.10 Reduced Swing Signaling 2089 1985 8.3.3.11 Effective Tx Package Loss at 8.0 GT/s and 2090 16.0 GT/s 1986 Page 17 2091 8.3.3.11 Effective Tx Package Loss at 8.0 GT/s, 16.0 GT/s and 32.0 GT/s /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 1986 2091 1987 2092 1988 8.3.4 Transmitter Margining 1989 2093 8.3.4 Transmitter Margining 2094 1990 8.3.5 Tx Jitter Parameters 1991 2095 8.3.5 Tx Jitter Parameters 2096 1992 8.3.5.1 Post Processing Steps to Extract Jitter 1993 2097 8.3.5.1 Post Processing Steps to Extract Jitter 2098 1994 8.3.5.2 Applying CTLE or De-embedding 2099 1995 2100 2011 2116 2012 8.3.5.2 Applying CTLE or De-embedding 2117 2013 8.3.6 Data Rate Dependent Parameters 2014 2118 8.3.6 Data Rate Dependent Parameters 2119 2015 8.3.7 Tx and Rx Return Loss 2016 2120 8.3.7 Tx and Rx Return Loss 2121 2017 8.3.8 Transmitter PLL Bandwidth and Peaking 2018 2122 8.3.8 Transmitter PLL Bandwidth and Peaking 2123 2019 8.3.8.1 2.5 GT/s and 5.0 GT/s Tx PLL Bandwidth and 2124 Peaking 8.3.8.1 2.5 GT/s and 5.0 GT/s Tx PLL Bandwidth and Peaking 2020 2125 2021 8.3.8.2 8.0 GT/s and 16.0 GT/s Tx PLL Bandwidth and 2126 Peaking 8.3.8.2 8.0 GT/s, 16.0 GT/s and 32.0 GT/s Tx PLL Bandwidth and Peaking 2022 2127 2023 8.3.8.3 Series Capacitors 2024 2128 8.3.8.3 Series Capacitors 2129 2025 2130 2026 8.3.9 Data Rate Independent Tx Parameters 2027 2131 8.3.9 Data Rate Independent Tx Parameters 2132 2028 2133 2029 8.4 Receiver Specifications 2030 2134 8.4 Receiver Specifications 2135 2031 8.4.1 Receiver Stressed Eye Specification 2035 8.4.1.2 Calibration Channel Insertion Loss 2136 8.4.1 Receiver Stressed Eye Specification 2140 Characteristics 8.4.1.2 Calibration Channel Insertion Loss Characteristics 2036 2141 2037 8.4.1.3 Post Processing Procedures 2038 2142 8.4.1.3 Post Processing Procedures 2143 2039 8.4.1.4 Behavioral Rx Package Models 2040 2144 8.4.1.4 Behavioral Rx Package Models 2145 2041 8.4.1.5 Behavioral CDR Model 2042 2146 8.4.1.5 Behavioral CDR Model 2147 2043 8.4.1.6 No Behavioral Rx Equalization for 2.5 and 2148 5.0 GT/s 8.4.1.6 No Behavioral Rx Equalization for 2.5 and 5.0 GT/s 2044 2149 2045 8.4.1.7 Behavioral Rx Equalization for 8.0 and 16.0 2150 GT/s 8.4.1.7 Behavioral Rx Equalization for 8.0, 16.0, and 32.0 GT/s 2151 2152 2046 2047 Page 18 8.4.1.8 Behavioral CTLE (8.0 and 16.0 GT/s) 2153 8.4.1.8 Behavioral CTLE (8.0 and 16.0 GT/s Only) 2154 8.4.1.9 Behavioral CTLE (32.0 GT/s ) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2047 8.4.1.8 Behavioral CTLE (8.0 and 16.0 GT/s Only) 2048 2154 8.4.1.9 Behavioral CTLE (32.0 GT/s ) 2155 2049 8.4.1.9 Behavioral DFE (8.0 and 16.0 GT/s Only) 2156 8.4.1.10 Behavioral DFE (8.0, 16.0, and 32.0 GT/s Only) 2050 2157 2051 2158 2052 8.4.2 Stressed Eye Test 2053 2159 8.4.2 Stressed Eye Test 2160 2054 8.4.2.1 Procedure for Calibrating a Stressed EH/EW 2161 Eye 8.4.2.1 Procedure for Calibrating a Stressed EH/EW Eye 2055 2162 2056 8.4.2.1.1 Post Processing Tool Requirements 2057 2163 8.4.2.1.1 Post Processing Tool Requirements 2164 2058 2165 2059 8.4.2.2 Procedure for Testing Rx DUT 2112 2166 8.4.2.2 Procedure for Testing Rx DUT 2219 2113 8.5.1.3.3 Simulation Tool Outputs 2114 2220 8.5.1.3.3 Simulation Tool Outputs 2221 2115 8.5.1.3.4 Open Source Simulation Tool 2116 2222 8.5.1.3.4 Open Source Simulation Tool 2223 2117 2224 2118 8.5.1.4 Behavioral Transmitter Parameters 2119 2225 8.5.1.4 Behavioral Transmitter Parameters 2226 2120 8.5.1.4.1 Deriving Voltage and Jitter 2227 Parameters 8.5.1.4.1 Deriving Voltage and Jitter Parameters 2121 2228 2229 2122 8.5.1.4.2 Optimizing Tx/Rx Equalization (8.0 GT/s, 16.0 GT/s and 32.0 GT/s only) 2230 2123 8.5.1.5 Optimizing Tx/Rx Equalization (8.0 GT/s and 2231 8.5.1.4.3 Pass/Fail Eye Characteristics 16.0 GT/s only) 2124 2125 2232 8.5.1.6 Pass/Fail Eye Characteristics 2233 8.5.1.4.4 Characterizing Channel Common Mode Noise 2126 2127 2234 8.5.1.7 Characterizing Channel Common Mode Noise 2128 2129 2235 8.5.1.8 Verifying VCH-IDLE-DET-DIFFp-p 2130 2237 2131 2238 2132 2133 2239 8.6 Refclk Specifications 2134 2135 8.6.1 Refclk Test Setup 2242 8.6.2 REFCLK AC Specifications 2244 8.6.1 Refclk Test Setup 8.6.2 REFCLK AC Specifications 2245 8.6.3 Data Rate Independent Refclk Parameters 2246 2158 2265 2159 2266 Page 19 8.6 Refclk Specifications 2243 2138 2139 2240 2241 2136 2137 8.5.1.4.5 Verifying VCH-IDLE-DET-DIFF-pp 2236 8.6.3 Data Rate Independent Refclk Parameters /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2159 2266 2160 8.6.7 Jitter Limits for Refclk Architectures 2161 2267 8.6.7 Jitter Limits for Refclk Architectures 2268 2162 8.6.8 Form Factor Requirements for RefClock 2269 Architectures 2163 2270 2164 2271 2165 2166 2272 9. Single Root I/O Virtualization and Sharing 2167 2168 8.6.8 Form Factor Requirements for RefClock Architectures 2273 9. Single Root I/O Virtualization and Sharing 2274 9.1 Architectural Overview 2275 9.1 SR-IOV Architectural Overview 2276 2277 9.1.1 PCI Technologies Interoperability 2278 2279 2280 9.2 SR-IOV Initialization and Resource Allocation 2281 2282 9.2.1 SR-IOV Resource Discovery 2283 2284 9.2.1.1 Configuring SR-IOV Capabilities 2285 2286 9.2.1.1.1 Configuring the VF BAR Mechanisms 2287 2288 2289 9.2.1.2 VF Discovery 2290 2291 9.2.1.3 Function Dependency Lists 2292 2293 9.2.1.4 Interrupt Resource Allocation 2294 2295 2296 9.2.2 SR-IOV Reset Mechanisms 2297 2298 9.2.2.1 SR-IOV Conventional Reset 2299 2300 9.2.2.2 FLR That Targets a VF 2301 2302 9.2.2.3 FLR That Targets a PF 2303 2304 2305 9.2.3 IOV Re-initialization and Reallocation 2306 2307 9.2.4 VF Migration 2308 2309 9.2.4.1 Initial VF State 2310 2311 9.2.4.2 VF Migration State Transitions 2312 2313 2314 2315 2316 Page 20 9.3 Configuration /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2316 2317 9.3.1 SR-IOV Configuration Overview 2318 2319 9.3.2 Configuration Space 2320 2321 9.3.3 SR-IOV Extended Capability 2322 2323 9.3.3.1 SR-IOV Extended Capability Header (Offset 00h) 2324 2325 9.3.3.2 SR-IOV Capabilities Register (04h) 2326 2327 9.3.3.2.1 VF Migration Capable 2328 2329 9.3.3.2.2 ARI Capable Hierarchy Preserved 2330 2331 9.3.3.2.3 VF 10-Bit Tag Requester Supported 2332 2333 9.3.3.2.4 VF Migration Interrupt Message Number 2334 2335 2336 9.3.3.3 SR-IOV Control Register (Offset 08h) 2337 2338 9.3.3.3.1 VF Enable 2339 2340 9.3.3.3.2 VF Migration Enable 2341 2342 9.3.3.3.3 VF Migration Interrupt Enable 2343 2344 9.3.3.3.4 VF MSE (Memory Space Enable) 2345 2346 9.3.3.3.5 ARI Capable Hierarchy 2347 2348 2349 9.3.3.4 SR-IOV Status Register (Offset 0Ah) 2350 2351 9.3.3.4.1 VF Migration Status 2352 2353 2354 9.3.3.5 InitialVFs (Offset 0Ch) 2355 2356 9.3.3.6 TotalVFs (Offset 0Eh) 2357 2358 9.3.3.7 NumVFs (Offset 10h) 2359 2360 9.3.3.8 Function Dependency Link (Offset 12h) 2361 2362 9.3.3.9 First VF Offset (Offset 14h) 2363 2364 Page 21 9.3.3.10 VF Stride (Offset 16h) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2364 9.3.3.10 VF Stride (Offset 16h) 2365 2366 9.3.3.11 VF Device ID (Offset 1Ah) 2367 2368 9.3.3.12 Supported Page Sizes (Offset 1Ch) 2369 2370 9.3.3.13 System Page Size (Offset 20h) 2371 2372 9.3.3.14 VF BAR0 (Offset 24h), VF BAR1 (Offset 28h), VF BAR2 (Offset 2Ch), VF BAR3 (Offset 30h), VF BAR4 (Offset 34h), VF BAR5 (Offset 38h) 2373 2374 9.3.3.15 VF Migration State Array Offset (Offset 3Ch) 2375 2376 9.3.3.15.1 VF Migration State Array 2377 2378 2379 2380 9.3.4 PF/VF Configuration Space Header 2381 2382 9.3.4.1 PF/VF Type 0 Configuration Space Header 2383 2384 9.3.4.1.1 Vendor ID Register Changes (Offset 00h) 2385 2386 9.3.4.1.2 Device ID Register Changes (Offset 02h) 2387 2388 9.3.4.1.3 Command Register Changes (Offset 04h) 2389 2390 9.3.4.1.4 Status Register Changes (Offset 06h) 2391 2392 9.3.4.1.5 Revision ID Register Changes (Offset 08h) 2393 2394 9.3.4.1.6 Class Code Register Changes (Offset 09h) 2395 2396 9.3.4.1.7 Cache Line Size Register Changes (Offset 0Ch) 2397 2398 9.3.4.1.8 Latency Timer Register Changes (Offset 0Dh) 2399 2400 9.3.4.1.9 Header Type Register Changes (Offset 0Eh) 2401 2402 2403 Page 22 9.3.4.1.10 BIST Register Changes (Offset 0Fh) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2403 2404 9.3.4.1.11 Base Address Registers Register Changes (Offset 10h, 14h, … 24h) 2405 2406 9.3.4.1.12 Cardbus CIS Pointer Register Changes (Offset 28h) 2407 2408 9.3.4.1.13 Subsystem Vendor ID Register Changes (Offset 2Ch) 2409 2410 9.3.4.1.14 Subsystem ID Register Changes (Offset 2Eh) 2411 2412 9.3.4.1.15 Expansion ROM Base Address Register Register Changes (Offset 30h) 2413 2414 9.3.4.1.16 Capabilities Pointer Register Changes (Offset 34h) 2415 2416 9.3.4.1.17 Interrupt Line Register Changes (Offset 3Ch) 2417 2418 9.3.4.1.18 Interrupt Pin Register Changes (Offset 3Dh) 2419 2420 9.3.4.1.19 Min_Gnt Register/Max_Lat Register Changes (Offset 3Eh/3Fh) 2421 2422 2423 2424 9.3.5 PCI Express Capability Changes 2425 2426 9.3.5.1 PCI Express Capabilities Register Changes (Offset 00h) 2427 2428 9.3.5.2 PCI Express Capabilities Register Changes (Offset 02h) 2429 2430 9.3.5.3 Device Capabilities Register Changes (Offset 04h) 2431 2432 9.3.5.4 Device Control Register Changes (Offset 08h) 2433 2434 9.3.5.5 Device Status Register Changes (Offset 0Ah) 2435 2436 9.3.5.6 Link Capabilities Register Changes (Offset 0Ch) 2437 2438 Page 23 9.3.5.7 Link Control Register Changes (Offset 10h) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2438 9.3.5.7 Link Control Register Changes (Offset 10h) 2439 2440 9.3.5.8 Link Status Register Changes (Offset 12h) 2441 2442 9.3.5.9 Device Capabilities 2 Register Changes (Offset 24h) 2443 2444 9.3.5.10 Device Control 2 Register Changes (Offset 28h) 2445 2446 9.3.5.11 Device Status 2 Register Changes (Offset 2Ah) 2447 2448 9.3.5.12 Link Capabilities 2 Register Changes (Offset 2Ch) 2449 2450 9.3.5.13 Link Control 2 Register Changes (Offset 30h) 2451 2452 9.3.5.14 Link Status 2 Register Changes (Offset 32h) 2453 2454 2455 9.3.6 PCI Standard Capabilities 2456 2457 9.3.6.1 VPD Capability 2458 2459 2460 9.3.7 PCI Express Extended Capabilities Changes 2461 2462 9.3.7.1 Virtual Channel/MFVC 2463 2464 9.3.7.2 Device Serial Number 2465 2466 9.3.7.3 Power Budgeting 2467 2468 9.3.7.4 Resizable BAR 2469 2470 9.3.7.5 VF Resizable BAR Extended Capability 2471 2472 9.3.7.5.1 VF Resizable BAR Extended Capability Header (Offset 00h) 2473 2474 9.3.7.5.2 VF Resizable BAR Capability Register (Offset 04h) 2475 2476 9.3.7.5.3 VF Resizable BAR Control Register (Offset 08h) 2477 2478 2479 Page 24 9.3.7.6 Access Control Services (ACS) Extended Capability Changes /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2479 9.3.7.6 Access Control Services (ACS) Extended Capability Changes 2480 2481 9.3.7.7 Alternative Routing ID Interpretation Extended Capability (ARI) Changes 2482 2483 9.3.7.8 Address Translation Services Extended Capability Changes (ATS) 2484 2485 9.3.7.9 MR-IOV Changes 2486 2487 9.3.7.10 Multicast Changes 2488 2489 9.3.7.11 Page Request Interface Changes (PRI) 2490 2491 9.3.7.12 Dynamic Power Allocation Changes (DPA) 2492 2493 9.3.7.13 TPH Requester Changes (TPH) 2494 2495 9.3.7.14 PASID Changes 2496 2497 9.3.7.15 Readiness Time Reporting Extended Capability Changes 2498 2499 2500 2501 9.4 SR-IOV Error Handling 2502 2503 9.4.1 Baseline Error Reporting 2504 2505 9.4.2 Advanced Error Reporting 2506 2507 9.4.2.1 VF Header Log 2508 2509 9.4.2.2 Advanced Error Reporting Capability Changes 2510 2511 9.4.2.3 Advanced Error Reporting Extended Capability Header Changes (Offset 00h) 2512 2513 9.4.2.4 Uncorrectable Error Status Register Changes (Offset 04h) 2514 2515 9.4.2.5 Uncorrectable Error Mask Register Changes (Offset 08h) 2516 2517 9.4.2.6 Uncorrectable Error Severity Register Changes (Offset 0Ch) 2518 2519 9.4.2.7 Correctable Error Status Register Changes (Offset 10h) Page 25 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2519 9.4.2.7 Correctable Error Status Register Changes (Offset 10h) 2520 2521 9.4.2.8 Correctable Error Mask Register Changes (Offset 14h) 2522 2523 9.4.2.9 Advanced Error Capabilities and Control Register Changes (Offset 18h) 2524 2525 9.4.2.10 Header Log Register Changes (Offset 1Ch) 2526 2527 9.4.2.11 Root Error Command Register Changes (Offset 2Ch) 2528 2529 9.4.2.12 Root Error Status Register Changes (Offset 30h) 2530 2531 9.4.2.13 Error Source Identification Register Changes (Offset 34h) 2532 2533 9.4.2.14 TLP Prefix Log Register Changes (Offset 38h) 2534 2535 2536 2537 9.5 SR-IOV Interrupts 2538 2539 9.5.1 Interrupt Mechanisms 2540 2541 9.5.1.1 MSI Interrupts 2542 2543 9.5.1.2 MSI-X Interrupts 2544 2545 9.5.1.3 Address Range Isolation 2546 2547 2548 2549 9.6 SR-IOV Power Management 2550 2551 9.6.1 VF Device Power Management States 2552 2553 9.6.2 PF Device Power Management States 2554 2555 9.6.3 Link Power Management State 2556 2557 9.6.4 VF Power Management Capability 2558 2559 9.6.5 VF EmergencyPower Reduction State 2560 2169 2561 2170 2171 Page 26 2562 10. ATS Specification 2563 10. ATS Specification /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2171 10. ATS Specification 2172 2173 10.1 Architectural Overview 10.1.1 Address Translation Services (ATS) Overview 10.1.2 Page Request Interface Extension 10.1.3 Process Address Space ID (PASID) 10.2.2.1 Attribute Field 10.2.2.2 Length Field 10.2.2.3 Tag Field 10.2.2.4 Untranslated Address Field 10.2.2.5 No Write (NW) Flag 10.2.2.6 PASID TLP Prefix 10.2.3.1 Translated Address Field 10.2.3.2 Translation Range Size (S) Field 10.2.3.3 Non-snooped (N) Field 10.2.2.4 Untranslated Address Field 2588 10.2.2.5 No Write (NW) Flag 2590 10.2.2.6 PASID TLP Prefix on Translation Request 2593 10.2.3 Translation Completion 2595 10.2.3.1 Translated Address Field 2597 10.2.3.2 Translation Range Size (S) Field 2599 10.2.3.3 Non-snooped (N) Field 2630 10.3.8 PASID TLP Prefix and Global Invalidate 2240 2631 10.3.8 PASID TLP Prefix and Global Invalidate 2632 2241 2633 10.4 Page Request Services 2243 2634 10.4 Page Request Services 2635 10.4.1 Page Request Message 2245 2636 10.4.1 Page Request Message 2637 10.4.1.1 PASID TLP Prefix Usage 2247 2248 2586 2600 2238 2246 10.2.2.3 Tag Field 2598 2208 2244 2584 2596 2206 2242 10.2.2.2 Length Field 2594 2204 2239 2582 2592 10.2.3 Translation Completion 2202 2207 10.2.2.1 Attribute Field 2591 2200 2205 2580 2589 2199 2203 10.2 ATS Translation Services 2587 2197 2201 2574 2585 2195 2198 10.1.3 Process Address Space ID (PASID) 2583 2193 2196 2571 2581 2191 2194 10.1.2 Page Request Interface Extension 2575 2189 2192 2569 2573 10.2 ATS Translation Services 2183 2190 10.1.1 Address Translation Services (ATS) Overview 2572 2181 2188 2567 2570 2180 2182 10.1 ATS Architectural Overview 2568 2178 2179 2565 2566 2176 2177 10. ATS Specification 2564 2174 2175 2563 2638 10.4.1.1 PASID TLP Prefix Usage 2639 10.4.1.2 Managing PASID TLP Prefix Usage 2640 10.4.1.2 Managing PASID TLP Prefix Usage on PRG Requests 2249 2250 2641 10.4.1.2.1 Stop Marker Messages 2642 2251 2643 2252 2644 2253 2645 Page 27 10.4.1.2.1 Stop Marker Messages /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2253 2645 2254 10.4.2 Page Request Group Response Message 2255 2646 10.4.2 Page Request Group Response Message 2647 2256 10.4.2.1 Response Code Field 2257 2648 10.4.2.1 Response Code Field 2649 2258 10.4.2.2 PASID TLP Prefix Usage 2650 2259 2651 2260 2652 2261 10.4.2.2 PASID TLP Prefix Usage on PRG Responses 2653 2262 10.5 ATS Configuration 2263 2654 10.5 ATS Configuration 2655 2264 10.5.1 ATS Extended Capability 2265 2656 10.5.1 ATS Extended Capability 2657 2266 10.5.1.1 ATS Extended Capability Header 2658 10.5.1.1 ATS Extended Capability Header (Offset 00h) 2267 2659 2268 10.5.1.2 ATS Capability Register 2269 2660 10.5.1.2 ATS Capability Register (Offset 04h) 2661 2270 10.5.1.3 ATS Control Register 2271 2662 10.5.1.3 ATS Control Register (Offset 06h) 2663 2272 2664 2273 10.5.2 Page Request Extended Capability Structure 2274 2665 10.5.2 Page Request Extended Capability Structure 2666 2275 10.5.2.1 Page Request Extended Capability Header 2667 10.5.2.1 Page Request Extended Capability Header (Offset 00h) 2276 2668 2277 10.5.2.2 Page Request Control Register ( 04h) 2669 10.5.2.2 Page Request Control Register (Offset 04h) 2278 2670 2279 10.5.2.3 Page Request Status Register ( 06h) 2280 2671 10.5.2.3 Page Request Status Register (Offset 06h) 2672 2281 10.5.2.4 Outstanding Page Request Capacity ( 08h) 2673 10.5.2.4 Outstanding Page Request Capacity (Offset 08h) 2282 2674 2283 10.5.2.5 Outstanding Page Request Allocation ( 0Ch) 2675 10.5.2.5 Outstanding Page Request Allocation (Offset 0Ch) 2284 2676 2285 2677 2286 2678 2287 2679 2288 A. Isochronous Applications 2289 2680 2290 A.1 Introduction 2291 2682 A.1 Introduction 2683 2292 A.2 Isochronous Contract and Contract Parameters 2684 2293 2685 2407 2799 2408 2800 2409 2410 A. Isochronous Applications 2681 A.2 Isochronous Contract and Contract Parameters 2801 H. Flow Control Update Latency and ACK Update Latency Calculations Page 28 2802 H. Flow Control Update Latency and ACK Update Latency Calculations /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2410 H. Flow Control Update Latency and ACK Update Latency 2802 Calculations 2411 H. Flow Control Update Latency and ACK Update Latency Calculations 2803 2412 H.1 Flow Control Update Latency 2413 2804 H.1 Flow Control Update Latency 2805 2414 H.2 Ack Latency 2806 2415 2807 2416 2808 H.2 Ack Latency 2809 I. Async Hot-Plug Reference Model 2810 2811 I.1 Async Hot-Plug Initial Configuration 2812 2813 I.2 Async Removal Configuration and Interrupt Handling 2814 2815 I.3 Async Hot-Add Configuration and Interrupt Handling 2816 2817 2417 2818 2418 2819 2419 2820 2420 2821 2421 Table of Figures 2422 2822 Table of Figures 2823 2423 2824 2424 Figure 1-1 PCI Express Link 2425 2825 Figure 1-1 PCI Express Link 2826 2426 Figure 1-2 Example PCI Express Topology 2827 Figure 1-2 Example PCI Express Topology 2440 Figure 2-4 Fields Present in All TLPs 2841 Figure 2-4 Fields Present in All TLPs 2441 2842 2442 Figure 2-5 Fields Present in All TLP Headers 2443 2843 Figure 2-5 Fields Present in All TLP Headers 2844 2444 Figure 2-6 Examples of Completer Target Memory Access for 2845 FetchAdd 2445 2446 2846 Figure 2-7 64-bit Address Routing 2447 2448 2847 Figure 2-7 64-bit Address Routing 2848 Figure 2-8 32-bit Address Routing 2449 2450 Figure 2-6 Examples of Completer Target Memory Access for FetchAdd 2849 Figure 2-8 32-bit Address Routing 2850 Figure 2-9 ID Routing with 4 DW Header 2851 Figure 2-9 Non-ARI ID Routing with 4 DW Header 2852 2853 Figure 2-10 ARI ID Routing with 4 DW Header 2854 2855 Figure 2-11 Non-ARI ID Routing with 3 DW Header 2856 2857 2451 2452 Figure 2-10 ID Routing with 3 DW Header 2453 2454 2457 Page 29 2859 Figure 2-13 Location of Byte Enables in TLP Header 2860 Figure 2-11 Location of Byte Enables in TLP Header 2455 2456 Figure 2-12 ARI ID Routing with 3 DW Header 2858 2861 Figure 2-14 Transaction Descriptor 2862 Figure 2-12 Transaction Descriptor 2863 2864 Figure 2-15 Transaction ID /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2457 2864 2458 Figure 2-13 Transaction ID 2459 2865 Figure 2-16 Attributes Field of Transaction Descriptor 2866 2460 Figure 2-14 Attributes Field of Transaction Descriptor 2867 Figure 2-17 Request Header Format for 64-bit Addressing of Memory 2461 2868 2462 Figure 2-15 Request Header Format for 64-bit Addressing of 2869 Memory Figure 2-18 Request Header Format for 32-bit Addressing of Memory 2463 2870 2464 Figure 2-16 Request Header Format for 32-bit Addressing of 2871 Figure 2-19 Request Header Format for I/O Transactions Memory 2465 2872 2466 Figure 2-17 Request Header Format for I/O Transactions 2467 2468 2873 Figure 2-20 Request Header Format for Configuration Transactions 2874 Figure 2-18 Request Header Format for Configuration Transactions 2469 2875 Figure 2-21 TPH TLP Prefix 2876 2470 Figure 2-19 TPH TLP Prefix 2471 2877 Figure 2-22 Location of PH[1:0] in a 4 DW Request Header 2878 2472 Figure 2-20 Location of PH[1:0] in a 4 DW Request Header 2473 2879 Figure 2-23 Location of PH[1:0] in a 3 DW Request Header 2880 2474 Figure 2-21 Location of PH[1:0] in a 3 DW Request Header 2881 Figure 2-24 Location of ST[7:0] in the Memory Write Request Header 2475 2882 2476 Figure 2-22 Location of ST[7:0] in the Memory Write Request 2883 Header 2477 2478 Figure 2-25 Location of ST[7:0] in Memory Read and AtomicOp Request Headers 2884 Figure 2-23 Location of ST[7:0] in Memory Read and AtomicOp Request Headers 2479 2480 Figure 2-25 Header for Vendor-Defined Messages Figure 2-26 Header for PCI-SIG-Defined VDMs Figure 2-27 LN Message Figure 2-28 DRS Message Figure 2-29 FRS Message Figure 2-30 Hierarchy ID Message Figure 2-31 LTR Message 2499 Page 30 Figure 2-30 LN Message 2895 Figure 2-31 DRS Message 2897 Figure 2-32 FRS Message 2899 Figure 2-33 Hierarchy ID Message 2901 Figure 2-34 LTR Message 2902 Figure 2-32 OBFF Message 2497 2498 2893 2900 2495 2496 Figure 2-29 Header for PCI-SIG-Defined VDMs 2898 2493 2494 2891 2896 2491 2492 Figure 2-28 Header for Vendor-Defined Messages 2894 2489 2490 2889 2892 2487 2488 Figure 2-27 ERR_COR Message 2890 2485 2486 2887 2888 2483 2484 Figure 2-26 Message Request Header 2886 Figure 2-24 Message Request Header 2481 2482 2885 2903 Figure 2-35 OBFF Message 2904 Figure 2-33 PTM Request/Response Message 2905 2906 Figure 2-36 PTM Request/Response Message /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2499 2906 2500 Figure 2-34 PTM ResponseD Message (4 DW header and 1 DW 2907 payload) 2501 2908 2502 Figure 2-35 Completion Header Format 2503 2909 Figure 2-36 (Non-ARI) Completer ID 2505 2911 Figure 2-37 ARI Completer ID 2507 2913 Figure 2-40 ARI Completer ID 2914 2508 Figure 2-38 Flowchart for Handling of Received TLPs 2509 2915 Figure 2-41 Flowchart for Handling of Received TLPs 2916 2510 Figure 2-39 Flowchart for Switch Handling of TLPs 2511 2917 Figure 2-42 Flowchart for Switch Handling of TLPs 2918 2512 Figure 2-40 Flowchart for Handling of Received Request 2513 2919 Figure 2-43 Flowchart for Handling of Received Request 2920 2514 Figure 2-41 Example Completion Data when some Byte Enables are 2921 0b Figure 2-44 Example Completion Data when some Byte Enables are 0b 2515 2922 2516 Figure 2-42 Virtual Channel Concept - An Illustration 2517 2923 Figure 2-45 Virtual Channel Concept - An Illustration 2924 Figure 2-43 Virtual Channel Concept - Switch Internals (Upstream Flow) 2519 2925 Figure 2-46 Virtual Channel Concept - Switch Internals (Upstream Flow) 2926 2520 Figure 2-44 An Example of TC/VC Configurations 2521 2927 Figure 2-47 An Example of TC/VC Configurations 2928 2522 Figure 2-45 Relationship Between Requester and Ultimate 2929 Completer Figure 2-48 Relationship Between Requester and Ultimate Completer 2523 2930 Figure 2-46 Calculation of 32-bit ECRC for TLP End to End Data Integrity Protection 2525 2931 Figure 2-49 Calculation of 32-bit ECRC for TLP End to End Data Integrity Protection 2932 2526 Figure 3-1 Layering Diagram Highlighting the Data Link Layer 2527 2933 Figure 3-1 Layering Diagram Highlighting the Data Link Layer 2934 2528 Figure 3-2 Data Link Control and Management State Machine 2529 2530 Figure 2-39 (Non-ARI) Completer ID 2912 2506 2524 Figure 2-38 Completion Header Format 2910 2504 2518 Figure 2-37 PTM ResponseD Message (4 DW header and 1 DW payload) 2935 Figure 3-2 Data Link Control and Management State Machine 2936 Figure 3-3 VC0 Flow Control Initialization Example with 8b/10b Encoding-based Framing 2531 2937 Figure 3-3 VC0 Flow Control Initialization Example with 8b/10b Encoding-based Framing 2938 2532 Figure 3-4 DLLP Type and CRC Fields 2533 2939 Figure 3-4 DLLP Type and CRC Fields 2940 2534 Figure 3-5 Data Link Layer Packet Format for Ack and Nak 2535 2941 Figure 3-5 Data Link Layer Packet Format for Ack and Nak 2942 2536 Figure 3-6 NOP Data Link Layer Packet Format 2537 2943 Figure 3-6 NOP Data Link Layer Packet Format 2944 2538 Figure 3-7 Data Link Layer Packet Format for InitFC1 2539 2945 Figure 3-7 Data Link Layer Packet Format for InitFC1 2946 2540 Figure 3-8 Data Link Layer Packet Format for InitFC2 2541 2947 Figure 3-8 Data Link Layer Packet Format for InitFC2 2948 2542 Figure 3-9 Figure 3-9: Data Link Layer Packet Format for UpdateFC Page 31 2949 Figure 3-9 Data Link Layer Packet Format for UpdateFC /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2542 Figure 3-9 Figure 3-9: Data Link Layer Packet Format for UpdateFC 2543 2950 2544 Figure 3-10 PM Data Link Layer Packet Format 2545 Figure 3-10 PM Data Link Layer Packet Format 2952 2546 Figure 3-11 Vendor-specific Data Link Layer Packet Format 2547 2953 Figure 3-11 Vendor-specific Data Link Layer Packet Format 2954 2548 Figure 3-12 Data Link Feature DLLP 2549 2955 Figure 3-12 Data Link Feature DLLP Format 2956 2550 Figure 3-13 Diagram of CRC Calculation for DLLPs 2551 2957 Figure 3-13 Diagram of CRC Calculation for DLLPs 2958 2552 Figure 3-14 TLP with LCRC and TLP Sequence Number Applied 2553 2554 2951 2959 Figure 3-14 TLP with LCRC and TLP Sequence Number Applied 2960 Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits 2555 2961 Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits 2962 2556 Figure 3-16 Figure 3-16: Calculation of LCRC 2557 2963 Figure 3-16 Calculation of LCRC 2964 2558 Figure 3-17 Received DLLP Error Check Flowchart 2559 2965 Figure 3-17 Received DLLP Error Check Flowchart 2966 2560 Figure 3-18 Ack/Nak DLLP Processing Flowchart 2561 2967 Figure 3-18 Ack/Nak DLLP Processing Flowchart 2968 2562 Figure 3-19 Receive Data Link Layer Handling of TLPs 2563 2969 Figure 3-19 Receive Data Link Layer Handling of TLPs 2970 2564 Figure 4-1 Layering Diagram Highlighting Physical Layer 2565 2971 Figure 4-1 Layering Diagram Highlighting Physical Layer 2972 2566 Figure 4-2 Character to Symbol Mapping 2973 Figure 4-2 Character to Symbol Mapping 2592 Figure 4-15 Packet Transmission in a x8 Link 2999 Figure 4-15 Packet Transmission in a x8 Link 2593 3000 2594 Figure 4-16 Nullified TLP Layout in a x8 Link with Other 3001 Packets 2595 3002 2596 Figure 4-17 SKP Ordered Set of Length 66-bit in a x8 Link 2597 2598 Figure 4-18 LFSR with Scrambling Polynomial in 8.0 GT/s and Above Data Rate 3005 Figure 4-18 LFSR with Scrambling Polynomial in 8.0 GT/s and Above Data Rate 3007 Figure 4-19 Alternate Implementation of the LFSR for Descrambling 3008 2602 Figure 4-20 8.0 GT/s Equalization Flow 2603 3009 Figure 4-20 Precoding working the scrambler/ de-scrambler 3010 2604 Figure 4-21 16.0 GT/s Equalization Flow 2605 3011 Figure 4-21 8.0 GT/s Equalization Flow 3012 Figure 4-22 Electrical Idle Exit Ordered Set for 8.0 GT/s and Above Data Rates 2607 2608 Figure 4-17 SKP Ordered Set of Length 66-bit in a x8 Link 3006 Figure 4-19 Alternate Implementation of the LFSR for Descrambling 2601 2606 3003 3004 2599 2600 Figure 4-16 Nullified TLP Layout in a x8 Link with Other Packets 3013 Figure 4-22 16.0 GT/s Equalization Flow 3014 Figure 4-23 Main State Diagram for Link Training and Status State Machine 2609 2610 Page 32 3015 Figure 4-23 Equalization Bypass Example 3016 Figure 4-24 Detect Substate Machine 3017 Figure 4-24 Alternate Protocol Negotiation and Equalization Bypass LTSSM States /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3017 2611 3018 2612 Figure 4-25 Polling Substate Machine 2613 3019 Figure 4-24 Alternate Protocol Negotiation and Equalization Bypass LTSSM States Figure 4-25 Electrical Idle Exit Ordered Set for 8.0 GT/s and Above Data Rates (EIEOS) 3020 2614 Figure 4-26 Configuration Substate Machine 2615 3021 Figure 4-26 Main State Diagram for Link Training and Status State Machine 3022 2616 Figure 4-27 Recovery Substate Machine 2617 3023 Figure 4-27 Detect Substate Machine 3024 2618 Figure 4-28 L0s Substate Machine 2619 3025 Figure 4-28 Polling Substate Machine 3026 2620 Figure 4-29 L1 Substate Machine 2621 3027 Figure 4-29 Configuration Substate Machine 3028 2622 Figure 4-30 L2 Substate Machine 2623 3029 Figure 4-30 Recovery Substate Machine 3030 2624 Figure 4-31 Loopback Substate Machine 2625 3031 Figure 4-31 L0s Substate Machine 3032 2626 Figure 4-32 Receiver Number Assignment 2627 3033 Figure 4-32 L1 Substate Machine 3034 2628 Figure 4-33 Supported Retimer Topologies 2629 3035 Figure 4-33 L2 Substate Machine 3036 2630 Figure 4-34 Retimer CLKREQ# Connection Topology 3037 Figure 4-34 Loopback Substate Machine 3038 3039 Figure 4-35 Receiver Number Assignment 3040 3041 Figure 4-36 Supported Retimer Topologies 3042 3043 2631 2632 Figure 5-1 Link Power Management State Flow Diagram 2633 3045 Figure 5-1 Link Power Management State Flow Diagram 3046 2634 Figure 5-2 Entry into the L1 Link State 2635 3047 Figure 5-2 Entry into the L1 Link State 3048 2636 Figure 5-3 Exit from L1 Link State Initiated by Upstream 3049 Component Figure 5-3 Exit from L1 Link State Initiated by Upstream Component 2637 2638 Figure 4-37 Retimer CLKREQ# Connection Topology 3044 3050 Figure 5-4 Conceptual Diagrams Showing Two Example Cases of WAKE# Routing 2639 3051 Figure 5-4 Conceptual Diagrams Showing Two Example Cases of WAKE# Routing 3052 2640 Figure 5-5 A Conceptual PME Control State Machine 3053 Figure 5-5 A Conceptual PME Control State Machine 2658 Figure 5-14 L1.2 Substates 3071 Figure 5-14 L1.2 Substates 2659 2660 3072 Figure 5-15 Example: Illustration of Boundary Condition due to Different Sampling of CLKREQ# 2661 2662 Figure 5-15 Example: Illustration of Boundary Condition due to Different Sampling of CLKREQ# 3074 Figure 5-16 Example: L1.2 Waveforms Illustrating Upstream Port Initiated Exit 2663 2664 3073 3075 Figure 5-16 Example: L1.2 Waveforms Illustrating Upstream Port Initiated Exit 3076 Figure 5-17 Example: L1.2 Waveforms Illustrating Downstream Port Initiated Exit Page 33 3077 Figure 5-17 Example: L1.2 Waveforms Illustrating Downstream Port Initiated Exit /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2664 Figure 5-17 Example: L1.2 Waveforms Illustrating Downstream 3077 Port Initiated Exit 2665 Figure 5-17 Example: L1.2 Waveforms Illustrating Downstream Port Initiated Exit 3078 2666 Figure 5-18 Function Power Management State Transitions 2667 3079 Figure 5-18 Function Power Management State Transitions 3080 2668 Figure 5-19 Non-Bridge Function Power Management Diagram 3081 Figure 5-19 PCI Express Bridge Power Management Diagram 2669 2670 Figure 5-20 PCI Express Bridge Power Management Diagram 2671 3082 2672 Figure 6-1 Error Classification 2673 2674 3083 Figure 6-1 Error Classification 3084 Figure 6-2 Flowchart Showing Sequence of Device Error Signaling and Logging Operations 2675 3085 Figure 6-2 Flowchart Showing Sequence of Device Error Signaling and Logging Operations 3086 2676 Figure 6-3 Pseudo Logic Diagram for Error Message Controls 2677 3087 Figure 6-3 Pseudo Logic Diagram for Selected Error Message Control and Status Bits 3088 2678 Figure 6-4 TC Filtering Example 2679 3089 Figure 6-4 TC Filtering Example 3090 2680 Figure 6-5 TC to VC Mapping Example 2681 3091 Figure 6-5 TC to VC Mapping Example 3092 2682 Figure 6-6 An Example of Traffic Flow Illustrating Ingress and 3093 Egress Figure 6-6 An Example of Traffic Flow Illustrating Ingress and Egress 2683 3094 2684 Figure 6-7 An Example of Differentiated Traffic Flow Through a 3095 Switch Figure 6-7 An Example of Differentiated Traffic Flow Through a Switch 2685 3096 2686 Figure 6-8 Switch Arbitration Structure 3097 Figure 6-8 Switch Arbitration Structure 2690 Figure 6-10 Multi-Function Arbitration Model 3101 Figure 6-10 Multi-Function Arbitration Model 2691 3102 2692 Figure 6-11 Root Complex Represented as a Single Component 2693 3103 Figure 6-11 Root Complex Represented as a Single Component 3104 2694 Figure 6-12 Root Complex Represented as Multiple Components 2695 3105 Figure 6-12 Root Complex Represented as Multiple Components 3106 2696 Figure 6-13 Example System Topology with ARI Devices 2697 3107 Figure 6-13 Example System Topology with ARI Devices 3108 2698 Figure 6-14 Segmentation of the Multicast Address Range 2699 3109 Figure 6-14 Segmentation of the Multicast Address Range 3110 3111 2700 Figure 6-15 Latency Fields Format for LTR Messages 3112 3113 2701 3114 2702 3115 Figure 6-16 CLKREQ# and Clock Power Management Figure 6-17 Use of LTR and Clock Power Management 2703 2704 2705 3116 2706 Figure 6-18 Codes and Equivalent WAKE# Patterns 2707 2708 3117 Figure 6-18 Codes and Equivalent WAKE# Patterns 3118 Figure 6-19 Example Platform Topology Showing a Link Where OBFF is Carried by Messages 2709 2710 Page 34 3119 Figure 6-19 Example Platform Topology Showing a Link Where OBFF is Carried by Messages 3120 Figure 6-20 PASID TLP Prefix 3121 Figure 6-20 PASID TLP Prefix /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2710 Figure 6-20 PASID TLP Prefix 2711 2712 3121 Figure 6-20 PASID TLP Prefix 3122 Figure 6-21 Sample LN System Block Diagram 2713 3123 Figure 6-21 Sample LN System Block Diagram 3124 2714 Figure 6-22 LN Protocol Basic Operation 3125 Figure 6-22 LN Protocol Basic Operation 2752 Figure 7-2 PCI Express Switch Device Mapping 3163 Figure 7-2 PCI Express Switch Device Mapping 2753 2754 3164 Figure 7-3 PCI Express Configuration Space Layout 2755 2756 Figure 7-4 Common Configuration Space Header Figure 7-5 Command Register Figure 7-6 Status Register Figure 7-7 Table 7-5: Class Code Register Figure 7-8 Header Type Register Figure 7-9 Table 7-7: BIST Register Figure 7-10 Figure 7-10: Type 0 Configuration Space Header Figure 7-11 Base Address Register for Memory Figure 7-12 Base Address Register for I/O Figure 7-13 Figure 7-13: Expansion ROM Base Address Register Figure 7-14 Type 1 Configuration Space Header Figure 7-15 Secondary Status Register Figure 7-16 Table 7-11: Bridge Control Register Figure 7-17 Power Management Capability Structure Figure 7-10 Type 0 Configuration Space Header 3181 Figure 7-11 Base Address Register for Memory 3183 Figure 7-12 Base Address Register for I/O 3185 Figure 7-13 Expansion ROM Base Address Register 3187 Figure 7-14 Type 1 Configuration Space Header 3189 Figure 7-15 Secondary Status Register 3191 Figure 7-16 Bridge Control Register 3193 Figure 7-17 Power Management Capability Structure 3194 Figure 7-18 Power Management Capabilities Register 2785 2786 3179 3192 2783 2784 Figure 7-9 BIST Register 3190 2781 2782 3177 3188 2779 2780 Figure 7-8 Header Type Register 3186 2777 2778 3175 3184 2775 2776 Figure 7-7 Class Code Register 3182 2773 2774 3173 3180 2771 2772 Figure 7-6 Status Register 3178 2769 2770 3171 3176 2767 2768 Figure 7-5 Command Register 3174 2765 2766 3169 3172 2763 2764 Figure 7-4 Common Configuration Space Header 3170 2761 2762 3167 3168 2759 2760 Figure 7-3 PCI Express Configuration Space Layout 3166 2757 2758 3165 3195 Figure 7-18 Power Management Capabilities Register 3196 Figure 7-19 Power Management Capabilities Register 3197 Figure 7-19 Power Management Control/Status Register 3198 3199 2787 2788 Figure 7-20 Power Management Control/Status Register 2789 2790 Figure 7-21 Power Management Control/Status Register 2795 Page 35 Figure 7-21 PCI Express Capability Structure 3203 Figure 7-22 PCI Express Capability List Register 3204 Figure 7-22 Table 7-14: Data Register 2793 2794 3201 3202 2791 2792 Figure 7-20 Data Register 3200 3205 Figure 7-23 PCI Express Capabilities Register 3206 Figure 7-23 PCI Express Capability Structure 3207 3208 Figure 7-24 Device Capabilities Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2795 3208 2796 Figure 7-24 PCI Express Capability List Register 2797 3209 Figure 7-25 Device Control Register 3210 2798 Figure 7-25 PCI Express Capabilities Register 2799 3211 Figure 7-26 Device Status Register 3212 2800 Figure 7-26 Device Capabilities Register 2801 3213 Figure 7-27 Link Capabilities Register 3214 2802 Figure 7-27 Device Control Register 2803 3215 Figure 7-28 Link Control Register 3216 2804 Figure 7-28 Device Status Register 2805 3217 Figure 7-29 Link Status Register 3218 2806 Figure 7-29 Link Capabilities Register 2807 3219 Figure 7-30 Slot Capabilities Register 3220 2808 Figure 7-30 Link Control Register 2809 3221 Figure 7-31 Slot Control Register 3222 2810 Figure 7-31 Link Status Register 2811 3223 Figure 7-32 Slot Status Register 3224 2812 Figure 7-32 Slot Capabilities Register 2813 3225 Figure 7-33 Root Control Register 3226 2814 Figure 7-33 Slot Control Register 2815 3227 Figure 7-34 Root Capabilities Register 3228 2816 Figure 7-34 Slot Status Register 2817 3229 Figure 7-35 Root Status Register 3230 2818 Figure 7-35 Root Control Register 2819 3231 Figure 7-36 Device Capabilities 2 Register 3232 2820 Figure 7-36 Root Capabilities Register 2821 3233 Figure 7-37 Device Control 2 Register 3234 2822 Figure 7-37 Root Status Register 2823 3235 Figure 7-38 Link Capabilities 2 Register 3236 2824 Figure 7-38 Device Capabilities 2 Register 2825 3237 Figure 7-39 Link Control 2 Register 3238 2826 Figure 7-39 Device Control 2 Register 2827 3239 Figure 7-40 Link Status 2 Register 3240 2828 Figure 7-40 Link Capabilities 2 Register 2829 3241 Figure 7-41 Slot Capabilities 2 Register 3242 2830 Figure 7-41 Link Control 2 Register 2831 3243 Figure 7-42 PCI Express Extended Configuration Space Layout 3244 2832 Figure 7-42 Link Status 2 Register 2833 3245 Figure 7-43 PCI Express Extended Capability Header 3246 2834 Figure 7-43 PCI Express Extended Configuration Space Layout 3247 Figure 7-44 MSI Capability Structure for 32-bit Message Address 2835 3248 2836 Figure 7-44 PCI Express Extended Capability Header 3249 Figure 7-45 MSI Capability Structure for 64-bit Message Address 2837 3250 2838 Figure 7-45 MSI Capability Structure for 32-bit Message 3251 Address Figure 7-46 MSI Capability Structure for 32-bit Message Address and PVM 2839 3252 2840 Figure 7-46 MSI Capability Structure for 64-bit Message 3253 Address 2841 Page 36 Figure 7-47 MSI Capability Structure for 64-bit Message Address and PVM 3254 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2841 3254 2842 Figure 7-47 MSI Capability Structure for 32-bit Message Address 3255 Figure 7-48 MSI Capability Header and PVM 2843 3256 2844 Figure 7-48 MSI Capability Structure for 64-bit Message Address 3257 Figure 7-49 Message Control Register for MSI and PVM 2845 3258 2846 Figure 7-49 MSI Capability Header 2847 3259 Figure 7-50 Message Address Register for MSI 3260 2848 Figure 7-50 Message Control Register for MSI 2849 3261 Figure 7-51 Message Upper Address Register for MSI 3262 2850 Figure 7-51 Message Address Register for MSI 2851 3263 Figure 7-52 Message Data Register for MSI 3264 2852 Figure 7-52 Message Upper Address Register for MSI 2853 3265 Figure 7-53 Extended Message Data Register for MSI 3266 2854 Figure 7-53 Message Data Register for MSI 2855 3267 Figure 7-54 Mask Bits Register for MSI 3268 2856 Figure 7-54 Extended Message Data Register for MSI 2857 3269 Figure 7-55 Pending Bits Register for MSI 3270 2858 Figure 7-55 Mask Bits Register for MSI 2859 3271 Figure 7-56 MSI-X Capability Structure 3272 2860 Figure 7-56 Pending Bits Register for MSI 2861 3273 Figure 7-57 MSI-X Table Structure 3274 2862 Figure 7-57 MSI-X Capability Structure 2863 3275 Figure 7-58 MSI-X PBA Structure 3276 2864 Figure 7-58 MSI-X Table Structure 2865 3277 Figure 7-59 MSI-X Capability Header 3278 2866 Figure 7-59 MSI-X PBA Structure 2867 3279 Figure 7-60 Message Control Register for MSI-X 3280 2868 Figure 7-60 MSI-X Capability Header 2869 3281 Figure 7-61 Table Offset/Table BIR Register for MSI-X 3282 2870 Figure 7-61 Message Control Register for MSI-X 2871 3283 Figure 7-62 PBA Offset/PBA BIR Register for MSI-X 3284 2872 Figure 7-62 Table Offset/Table BIR Register for MSI-X 2873 3285 Figure 7-63 Message Address Register for MSI-X Table Entries 3286 2874 Figure 7-63 PBA Offset/PBA BIR Register for MSI-X 3287 Figure 7-64 Message Upper Address Register for MSI-X Table Entries 2875 3288 2876 Figure 7-64 Message Address Register for MSI-X Table Entries 2877 3289 Figure 7-65 Message Data Register for MSI-X Table Entries 3290 2878 Figure 7-65 Message Upper Address Register for MSI-X Table 3291 Figure 7-66 Vector Control Register for MSI-X Table Entries Entries 2879 3292 2880 Figure 7-66 Message Data Register for MSI-X Table Entries 2881 3293 Figure 7-67 Pending Bits Register for MSI-X PBA Entries 3294 2882 Figure 7-67 Vector Control Register for MSI-X Table Entries 3295 Figure 7-68 Secondary PCI Express Extended Capability Structure 2883 3296 2884 Figure 7-68 Pending Bits Register for MSI-X PBA Entries 2885 2886 3297 Figure 7-69 Secondary PCI Express Extended Capability Header 3298 Figure 7-69 Figure 7-66: Secondary PCI Express Extended Capability Structure Page 37 3299 Figure 7-70 Link Control 3 Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2886 Figure 7-69 Figure 7-66: Secondary PCI Express Extended Capability Structure 2887 3299 Figure 7-70 Link Control 3 Register 3300 2888 Figure 7-70 Secondary PCI Express Extended Capability Header 2889 3301 Figure 7-71 Lane Error Status Register 3302 2890 Figure 7-71 Link Control 3 Register 2891 3303 Figure 7-72 Lane Equalization Control Register 3304 2892 Figure 7-72 Lane Error Status Register 2893 3305 Figure 7-73 Lane Equalization Control Register Entry 3306 2894 Figure 7-73 Lane Equalization Control Register 2895 3307 Figure 7-74 Data Link Feature Extended Capability 3308 2896 Figure 7-74 Lane Equalization Control Register Entry 2897 3309 Figure 7-75 Data Link Feature Extended Capability Header 3310 2898 Figure 7-75 Data Link Feature Extended Capability 2899 3311 Figure 7-76 Data Link Feature Capabilities Register 3312 2900 Figure 7-76 Data Link Feature Extended Capability Header 2901 3313 Figure 7-77 Data Link Feature Status Register 3314 2902 Figure 7-77 Table 7-58: Data Link Feature Capabilities 3315 Figure 7-78 Physical Layer 16.0 GT/s Extended Capability Register 2903 3316 2904 Figure 7-78 Data Link Feature Status Register 3317 Figure 7-79 Physical Layer 16.0 GT/s Extended Capability Header 2905 3318 2906 Figure 7-79 Physical Layer 16.0 GT/s Extended Capability 2907 3319 Figure 7-80 16.0 GT/s Capabilities Register 3320 2908 Figure 7-80 Physical Layer 16.0 GT/s Extended Capability 3321 Figure 7-81 16.0 GT/s Control Register Header 2909 3322 2910 Figure 7-81 16.0 GT/s Capabilities Register 2911 3323 Figure 7-82 16.0 GT/s Status Register 3324 2912 Figure 7-82 16.0 GT/s Control Register 3325 Figure 7-83 16.0 GT/s Local Data Parity Mismatch Status Register 2913 3326 2914 Figure 7-83 16.0 GT/s Status Register 3327 Figure 7-84 16.0 GT/s First Retimer Data Parity Mismatch Status Register 2915 3328 2916 Figure 7-84 16.0 GT/s Local Data Parity Mismatch Status 3329 Register 2917 Figure 7-85 16.0 GT/s Second Retimer Data Parity Mismatch Status Register 3330 2918 Figure 7-85 16.0 GT/s First Retimer Data Parity Mismatch Status 3331 Figure 7-86 16.0 GT/s Lane Equalization Control Register Entry Register 2919 2920 3332 Figure 7-86 16.0 GT/s Second Retimer Data Parity Mismatch Status Register 2921 2922 3333 Figure 7-87 Physical Layer 32.0 GT/s Extended Capability 3334 Figure 7-87 High Level Structure of 16.0 GT/s Lane Equalization Control Register 2923 2924 Page 38 Figure 7-88 Physical Layer 32.0 GT/s Extended Capability Header 3336 Figure 7-88 16.0 GT/s Lane Equalization Control Register Entry 2925 2926 3335 3337 Figure 7-89 32.0 GT/s Capabilities Register 3338 Figure 7-89 Lane Margining at the Receiver Extended Capability 3339 Figure 7-90 32.0 GT/s Control Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2926 Figure 7-89 Lane Margining at the Receiver Extended Capability 2927 3339 Figure 7-90 32.0 GT/s Control Register 3340 2928 Figure 7-90 Lane Margining at the Receiver Extended Capability 3341 Figure 7-91 32.0 GT/s Status Register Header 2929 3342 2930 Figure 7-91 Margining Port Capabilities Register 2931 3343 Figure 7-92 Received Modified TS Data 1 Register 3344 2932 Figure 7-92 Margining Port Status Register 2933 3345 Figure 7-93 Received Modified TS Data 2 Register 3346 2934 Figure 7-93 2935 3347 Figure 7-94 Transmitted Modified TS Data 1 Register 3348 2936 Figure 7-94 Lane N: Margining Lane Status Register Entry 2937 3349 Figure 7-95 Transmitted Modified TS Data 2 Register 3350 2938 Figure 7-95 ACS Extended Capability 2939 3351 Figure 7-96 32.0 GT/s Lane Equalization Control Register Entry 3352 2940 Figure 7-96 ACS Extended Capability Header 2941 3353 Figure 7-97 Lane Margining at the Receiver Extended Capability 3354 2942 Figure 7-97 ACS Capability Register 3355 Figure 7-98 Lane Margining at the Receiver Extended Capability Header 2943 3356 2944 Figure 7-98 ACS Control Register 2945 3357 Figure 7-99 Margining Port Capabilities Register 3358 2946 Figure 7-99 Egress Control Vector Register 2947 3359 Figure 7-100 Margining Port Status Register 3360 2948 Figure 7-100 Power Budgeting Extended Capability Structure 2949 3361 Figure 7-101 Lane N: Margining Control Register Entry 3362 2950 Figure 7-101 Power Budgeting Extended Capability Header 2951 3363 Figure 7-102 Lane N: Margining Lane Status Register Entry 3364 2952 Figure 7-102 Power Budgeting Data Register 2953 3365 Figure 7-103 ACS Extended Capability 3366 2954 Figure 7-103 Power Budgeting Capability Register 2955 3367 Figure 7-104 ACS Extended Capability Header 3368 2956 Figure 7-104 LTR Extended Capability Structure 2957 3369 Figure 7-105 ACS Capability Register 3370 2958 Figure 7-105 LTR Extended Capability Header 2959 3371 Figure 7-106 ACS Control Register 3372 2960 Figure 7-106 Max Snoop Latency Register 2961 3373 Figure 7-107 Egress Control Vector Register 3374 2962 Figure 7-107 Max No-Snoop Latency Register 2963 3375 Figure 7-108 Power Budgeting Extended Capability 3376 2964 Figure 7-108 L1 PM Substates Extended Capability 2965 3377 Figure 7-109 Power Budgeting Extended Capability Header 3378 2966 Figure 7-109 L1 PM Substates Extended Capability Header 2967 3379 Figure 7-110 Power Budgeting Data Register 3380 2968 Figure 7-110 L1 PM Substates Capabilities Register 2969 3381 Figure 7-111 Power Budgeting Capability Register 3382 2970 Figure 7-111 L1 PM Substates Control 1 Register 2971 3383 Figure 7-112 LTR Extended Capability Structure 3384 2972 Figure 7-112 L1 PM Substates Control 2 Register 2973 3385 Figure 7-113 LTR Extended Capability Header 3386 2974 Figure 7-113 Advanced Error Reporting Extended Capability Structure Page 39 3387 Figure 7-114 Max Snoop Latency Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 2974 Figure 7-113 Advanced Error Reporting Extended Capability 3387 Figure 7-114 Max Snoop Latency Register Structure 2975 3388 2976 Figure 7-114 Advanced Error Reporting Extended Capability 3389 Figure 7-115 Max No-Snoop Latency Register Header 2977 3390 2978 Figure 7-115 Uncorrectable Error Status Register 2979 3391 Figure 7-116 L1 PM Substates Extended Capability 3392 2980 Figure 7-116 Uncorrectable Error Mask Register 2981 3393 Figure 7-117 L1 PM Substates Extended Capability Header 3394 2982 Figure 7-117 Uncorrectable Error Severity Register 2983 3395 Figure 7-118 L1 PM Substates Capabilities Register 3396 2984 Figure 7-118 Correctable Error Status Register 2985 3397 Figure 7-119 L1 PM Substates Control 1 Register 3398 2986 Figure 7-119 Correctable Error Mask Register 2987 3399 Figure 7-120 L1 PM Substates Control 2 Register 3400 2988 Figure 7-120 Advanced Error Capabilities and Control Register 2989 3401 Figure 7-121 L1 PM Substates Status Register 3402 2990 Figure 7-121 Header Log Register 3403 Figure 7-122 Advanced Error Reporting Extended Capability Structure 2991 3404 2992 Figure 7-122 Root Error Command Register 3405 Figure 7-123 Advanced Error Reporting Extended Capability Header 2993 3406 2994 Figure 7-123 Root Error Status Register 2995 3407 Figure 7-124 Uncorrectable Error Status Register 3408 2996 Figure 7-124 Error Source Identification Register 2997 3409 Figure 7-125 Uncorrectable Error Mask Register 3410 2998 Figure 7-125 TLP Prefix Log Register 2999 3411 Figure 7-126 Uncorrectable Error Severity Register 3412 3000 Figure 7-126 Table 7-98: First DW of Enhanced Allocation 3413 Figure 7-127 Correctable Error Status Register Capability 3001 3002 3414 Figure 7-127 Table 7-99: First DW of Each Entry for Enhanced Allocation Capability 3003 3415 Figure 7-128 Correctable Error Mask Register 3416 3004 Figure 7-128 Format of Entry for Enhanced Allocation 3417 Figure 7-129 Advanced Error Capabilities and Control Register Capability 3005 3418 3006 Figure 7-129 Figure 7-123: Example Entry with 64b Base and 64b 3419 Figure 7-130 Header Log Register MaxOffset 3007 3420 3008 Figure 7-130 Figure 7-124: Example Entry with 64b Base and 32b 3421 Figure 7-131 Root Error Command Register MaxOffset 3009 3422 3010 Figure 7-131 Figure 7-125: Example Entry with 32b Base and 64b 3423 Figure 7-132 Root Error Status Register MaxOffset 3011 3424 3012 Figure 7-132 Figure 7-126: Example Entry with 32b Base and 32b 3425 Figure 7-133 Error Source Identification Register MaxOffset 3013 3014 Page 40 3426 Figure 7-133 Resizable BAR Extended Capability 3427 Figure 7-134 TLP Prefix Log Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3014 Figure 7-133 Resizable BAR Extended Capability 3015 3016 Figure 7-134 Resizable BAR Extended Capability Header 3429 Figure 7-135 First DW of Enhanced Allocation Capability 3430 Figure 7-135 Resizable BAR Capability Register 3019 3020 Figure 7-134 TLP Prefix Log Register 3428 3017 3018 3427 3431 Figure 7-136 Second DW of Enhanced Allocation Capability 3432 Figure 7-136 Resizable BAR Control Register 3433 Figure 7-137 First DW of Each Entry for Enhanced Allocation Capability 3021 3022 3434 Figure 7-137 Resizable BAR Control Register 3435 Figure 7-138 Format of Entry for Enhanced Allocation Capability 3023 3024 3436 Figure 7-138 ARI Extended Capability 3025 3026 Figure 7-139 ARI Capability Header Figure 7-140 ARI Capability Register Figure 7-141 ARI Control Register Figure 7-142 Figure 7-135: PASID Extended Capability Structure Figure 7-143 PASID Extended Capability Header Figure 7-144 PASID Capability Register Figure 7-145 Table 7-109: PASID Control Register Figure 7-146 FRS Extended Capability Figure 7-147 FRS Queueing Extended Capability Header Figure 7-148 FRS Queueing Capability Register Figure 7-149 FRS Queueing Status Register Figure 7-150 FRS Queueing Control Register Figure 7-151 FRS Message Queue Register Figure 7-152 FPB Capability Structure Figure 7-153 FPB Capability Header Figure 7-154 FPB Capabilities Register Figure 7-155 FPB RID Vector Control 1 Register Page 41 3455 Figure 7-148 ARI Extended Capability Header 3457 Figure 7-149 ARI Capability Register 3459 Figure 7-150 ARI Control Register 3461 Figure 7-151 PASID Extended Capability Structure 3463 Figure 7-152 PASID Extended Capability Header 3465 Figure 7-153 PASID Capability Register 3467 Figure 7-154 PASID Control Register 3469 Figure 7-155 FRS Queueing Extended Capability 3471 Figure 7-156 FRS Queueing Extended Capability Header 3472 Figure 7-156 FPB RID Vector Control 2 Register 3061 3062 Figure 7-147 ARI Extended Capability 3470 3059 3060 3453 3468 3057 3058 Figure 7-146 Resizable BAR Control Register 3466 3055 3056 3451 3464 3053 3054 Figure 7-145 Resizable BAR Capability Register 3462 3051 3052 3449 3460 3049 3050 Figure 7-144 Resizable BAR Extended Capability Header 3458 3047 3048 3447 3456 3045 3046 Figure 7-143 Resizable BAR Extended Capability 3454 3043 3044 3445 3452 3041 3042 Figure 7-142 Example Entry with 32b Base and 32b MaxOffset 3450 3039 3040 3443 3448 3037 3038 Figure 7-141 Example Entry with 32b Base and 64b MaxOffset 3446 3035 3036 3441 3444 3033 3034 Figure 7-140 Example Entry with 64b Base and 32b MaxOffset 3442 3031 3032 3439 3440 3029 3030 Figure 7-139 Example Entry with 64b Base and 64b MaxOffset 3438 3027 3028 3437 3473 Figure 7-157 FRS Queueing Capability Register 3474 Figure 7-157 FPB MEM Low Vector Control Register 3475 Figure 7-158 FRS Queueing Status Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3062 Figure 7-157 FPB MEM Low Vector Control Register 3063 Figure 7-158 FRS Queueing Status Register 3476 3064 Figure 7-158 FPB MEM High Vector Control 1 Register 3065 3477 Figure 7-159 FRS Queueing Control Register 3478 3066 Figure 7-159 FPB MEM High Vector Control 2 Register 3067 3479 Figure 7-160 FRS Message Queue Register 3480 3068 Figure 7-160 FPB Vector Access Control Register 3069 3481 Figure 7-161 FPB Capability Structure 3482 3070 Figure 7-161 FPB Vector Access Data Register 3071 3483 Figure 7-162 FPB Capability Header 3484 3072 Figure 7-162 Virtual Channel Extended Capability Structure 3073 3485 Figure 7-163 FPB Capabilities Register 3486 3074 Figure 7-163 Virtual Channel Extended Capability Header 3075 3487 Figure 7-164 FPB RID Vector Control 1 Register 3488 3076 Figure 7-164 Table 7-125: Port VC Capability Register 1 3077 3489 Figure 7-165 FPB RID Vector Control 2 Register 3490 3078 Figure 7-165 Port VC Capability Register 2 3079 3491 Figure 7-166 FPB MEM Low Vector Control Register 3492 3080 Figure 7-166 Port VC Control Register 3081 3493 Figure 7-167 FPB MEM High Vector Control 1 Register 3494 3082 Figure 7-167 Table 7-128: Port VC Status Register 3083 3495 Figure 7-168 FPB MEM High Vector Control 2 Register 3496 3084 Figure 7-168 VC Resource Capability Register 3085 3497 Figure 7-169 FPB Vector Access Control Register 3498 3086 Figure 7-169 VC Resource Control Register 3087 3499 Figure 7-170 FPB Vector Access Data Register 3500 3088 Figure 7-170 VC Resource Status Register 3089 3501 Figure 7-171 Virtual Channel Extended Capability Structure 3502 3090 Figure 7-171 Example VC Arbitration Table with 32 Phases 3091 3092 3475 3503 Figure 7-172 Virtual Channel Extended Capability Header 3504 Figure 7-172 Example Port Arbitration Table with 128 Phases and 2-bit Table Entries 3093 3094 Figure 7-174 MFVC Extended Capability Header Figure 7-175 MFVC Port VC Capability Register 1 Figure 7-176 MFVC Port VC Capability Register 2 Figure 7-177 MFVC Port VC Control Register Figure 7-178 MFVC Port VC Status Register Figure 7-179 MFVC VC Resource Capability Register Page 42 3513 Figure 7-177 VC Resource Capability Register 3515 Figure 7-178 VC Resource Control Register 3517 Figure 7-179 VC Resource Status Register 3519 Figure 7-180 Example VC Arbitration Table with 32 Phases 3520 Figure 7-180 MFVC VC Resource Control Register 3109 3110 Figure 7-176 Port VC Status Register 3518 3107 3108 3511 3516 3105 3106 Figure 7-175 Port VC Control Register 3514 3103 3104 3509 3512 3101 3102 Figure 7-174 Port VC Capability Register 2 3510 3099 3100 3507 3508 3097 3098 Figure 7-173 Port VC Capability Register 1 3506 Figure 7-173 MFVC Capability Structure 3095 3096 3505 3521 Figure 7-181 Example Port Arbitration Table with 128 Phases and 2-bit Table Entries 3522 Figure 7-181 MFVC VC Resource Status Register 3523 Figure 7-182 MFVC Capability Structure /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3110 Figure 7-181 MFVC VC Resource Status Register 3111 3523 Figure 7-182 MFVC Capability Structure 3524 3112 Figure 7-182 Device Serial Number Extended Capability 3525 Figure 7-183 MFVC Extended Capability Header Structure 3113 3526 3114 Figure 7-183 Device Serial Number Extended Capability Header 3115 3527 Figure 7-184 MFVC Port VC Capability Register 1 3528 3116 Figure 7-184 Serial Number Register 3117 3529 Figure 7-185 MFVC Port VC Capability Register 2 3530 3118 Figure 7-185 Vendor-Specific Capability 3119 3531 Figure 7-186 MFVC Port VC Control Register 3532 3120 Figure 7-186 VSEC Capability Structure 3121 3533 Figure 7-187 MFVC Port VC Status Register 3534 3122 Figure 7-187 Vendor-Specific Extended Capability Header 3123 3535 Figure 7-188 MFVC VC Resource Capability Register 3536 3124 Figure 7-188 Vendor-Specific Header 3125 3537 Figure 7-189 MFVC VC Resource Control Register 3538 3126 Figure 7-189 Designated Vendor-Specific Extended Capability 3127 3539 Figure 7-190 MFVC VC Resource Status Register 3540 3128 Figure 7-190 Designated Vendor-Specific Extended Capability 3541 Header Figure 7-191 Device Serial Number Extended Capability Structure 3129 3542 3130 Figure 7-191 Designated Vendor-Specific Header 1 3131 3543 Figure 7-192 Device Serial Number Extended Capability Header 3544 3132 Figure 7-192 Designated Vendor-Specific Header 2 3133 3545 Figure 7-193 Serial Number Register 3546 3134 Figure 7-193 RCRB Header Extended Capability Structure 3135 3547 Figure 7-194 Vendor-Specific Capability 3548 3136 Figure 7-194 Table 7-152: RCRB Header Extended Capability 3549 Figure 7-195 VSEC Capability Structure Header 3137 3550 3138 Figure 7-195 RCRB Vendor ID and Device ID register 3139 3551 Figure 7-196 Vendor-Specific Extended Capability Header 3552 3140 Figure 7-196 RCRB Capabilities register 3141 3553 Figure 7-197 Vendor-Specific Header 3554 3142 Figure 7-197 RCRB Control register 3143 3555 Figure 7-198 Designated Vendor-Specific Extended Capability 3556 3144 Figure 7-198 Root Complex Link Declaration Extended Capability 3557 Figure 7-199 Designated Vendor-Specific Extended Capability Header 3145 3558 3146 Figure 7-199 Root Complex Link Declaration Extended Capability 3559 Figure 7-200 Designated Vendor-Specific Header 1 Header 3147 3148 3560 Figure 7-200 Element Self Description Register 3149 3150 Figure 7-201 Link Entry 3155 Page 43 3563 Figure 7-202 RCRB Header Extended Capability Structure 3564 Figure 7-202 Link Description Register 3153 3154 Figure 7-201 Designated Vendor-Specific Header 2 3562 3151 3152 3561 3565 Figure 7-203 RCRB Header Extended Capability Header 3566 Figure 7-203 Link Address for Link Type 0 3567 3568 Figure 7-204 RCRB Vendor ID and Device ID register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3155 3568 3156 Figure 7-204 Link Address for Link Type 1 3157 3569 Figure 7-205 RCRB Capabilities register 3570 3158 Figure 7-205 Root Complex Internal Link Control Extended 3571 Figure 7-206 RCRB Control register Capability 3159 3160 3572 Figure 7-206 Root Complex Internal Link Control Extended Capability Header 3161 3573 Figure 7-207 Root Complex Link Declaration Extended Capability 3574 3162 Figure 7-207 Figure 7-200: Root Complex Link Capabilities 3575 Register Figure 7-208 Root Complex Link Declaration Extended Capability Header 3163 3576 3164 Figure 7-208 Table 7-161: Root Complex Link Capabilities 3577 Figure 7-209 Element Self Description Register Register 3165 3578 3166 Figure 7-209 Root Complex Link Control Register 3167 Figure 7-210 Root Complex Link Status Register 3169 3581 Figure 7-211 Link Description Register 3582 Figure 7-211 Root Complex Event Collector Endpoint Association Extended Capability 3171 3172 Figure 7-210 Link Entry 3580 3168 3170 3579 3583 Figure 7-212 Link Address for Link Type 0 3584 Figure 7-212 Table 7-164: Root Complex Event Collector Endpoint Association Extended Capability Header 3173 3585 Figure 7-213 Link Address for Link Type 1 3586 3174 Figure 7-213 Multicast Extended Capability Structure 3587 Figure 7-214 Root Complex Internal Link Control Extended Capability 3175 3588 3176 Figure 7-214 Multicast Extended Capability Header 3177 3589 Figure 7-215 Root Complex Internal Link Control Extended Capability Header 3590 3178 Figure 7-215 Multicast Capability Register 3179 3591 Figure 7-216 Root Complex Link Capabilities Register 3592 3180 Figure 7-216 Multicast Control Register 3181 3593 Figure 7-217 Root Complex Link Control Register 3594 3182 Figure 7-217 MC_Base_Address Register 3183 3595 Figure 7-218 Root Complex Link Status Register 3596 3184 Figure 7-218 MC_Receive Register 3185 3597 Figure 7-219 Root Complex Event Collector Endpoint Association Extended Capability 3598 3186 Figure 7-219 MC_Block_All Register 3187 3599 Figure 7-220 Root Complex Event Collector Endpoint Association Extended Capability Header 3600 3188 Figure 7-220 MC_Block_Untranslated Register 3189 3601 Figure 7-221 RCEC Associated Bus Numbers Register 3602 3190 Figure 7-221 MC_Overlay_BAR Register 3191 3603 Figure 7-222 Multicast Extended Capability Structure 3604 3192 Figure 7-222 Dynamic Power Allocation Extended Capability 3605 Figure 7-223 Multicast Extended Capability Header Structure 3193 3194 Page 44 3606 Figure 7-223 DPA Extended Capability Header 3607 Figure 7-224 Multicast Capability Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3194 Figure 7-223 DPA Extended Capability Header 3195 Figure 7-224 Multicast Capability Register 3608 3196 Figure 7-224 DPA Capability Register 3197 3609 Figure 7-225 Multicast Control Register 3610 3198 Figure 7-225 DPA Latency Indicator Register 3199 3611 Figure 7-226 MC_Base_Address Register 3612 3200 Figure 7-226 DPA Status Register 3201 3613 Figure 7-227 MC_Receive Register 3614 3202 Figure 7-227 DPA Control Register 3203 3615 Figure 7-228 MC_Block_All Register 3616 3204 Figure 7-228 DPA Power Allocation Array 3205 3206 3607 3617 Figure 7-229 MC_Block_Untranslated Register 3618 Figure 7-229 Substate Power Allocation Register (0 to Substate_Max) 3207 3208 3619 Figure 7-230 MC_Overlay_BAR Register 3620 Figure 7-230 TPH Extended Capability Structure 3621 Figure 7-231 Dynamic Power Allocation Extended Capability Structure 3209 3210 3622 Figure 7-231 TPH Requester Extended Capability Header 3211 3212 Figure 7-232 TPH Requester Capability Register Figure 7-233 TPH Requester Control Register Figure 7-234 TPH ST Table Figure 7-235 TPH ST Table Figure 7-236 LN Requester Extended Capability Figure 7-237 LNR Extended Capability Header Figure 7-239 LNR Control Register Figure 7-240 DPC Extended Capability Header Figure 7-241 DPC Capability Register Figure 7-242 DPC Control Register Figure 7-243 DPC Status Register Figure 7-244 DPC Error Source ID Register 3241 Page 45 3637 Figure 7-239 TPH Extended Capability Structure 3639 Figure 7-240 TPH Requester Extended Capability Header 3641 Figure 7-241 TPH Requester Capability Register 3643 Figure 7-242 TPH Requester Control Register 3645 Figure 7-243 TPH ST Table 3647 Figure 7-244 TPH ST Table Entry 3649 Figure 7-245 LN Requester Extended Capability 3650 Figure 7-245 RP PIO Status Register 3239 3240 Figure 7-238 Substate Power Allocation Register (0 to Substate_Max) 3648 3237 3238 3635 3646 3235 3236 Figure 7-237 DPA Power Allocation Array 3644 3233 3234 3633 3642 3231 3232 Figure 7-236 DPA Control Register 3640 3229 3230 3631 3638 3227 3228 Figure 7-235 DPA Status Register 3636 Figure 7-238 LNR Capability Register 3225 3226 3629 3634 3223 3224 Figure 7-234 DPA Latency Indicator Register 3632 3221 3222 3627 3630 3219 3220 Figure 7-233 DPA Capability Register 3628 3217 3218 3625 3626 3215 3216 Figure 7-232 DPA Extended Capability Header 3624 3213 3214 3623 3651 Figure 7-246 LNR Extended Capability Header 3652 Figure 7-246 RP PIO Mask Register 3653 3654 Figure 7-247 LNR Capability Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3241 3654 3242 Figure 7-247 RP PIO Severity Register 3243 3655 Figure 7-248 LNR Control Register 3656 3244 Figure 7-248 RP PIO SysError Register 3245 3657 Figure 7-249 DPC Extended Capability 3658 3246 Figure 7-249 RP PIO Exception Register 3247 3659 Figure 7-250 DPC Extended Capability Header 3660 3248 Figure 7-250 RP PIO Header Log Register 3249 3661 Figure 7-251 DPC Capability Register 3662 3250 Figure 7-251 RP PIO ImpSpec Log Register RP PIO ImpSpec Log 3663 Figure 7-252 DPC Control Register Register 3251 3664 3252 Figure 7-252 RP PIO TLP Prefix Log Register 3253 3665 Figure 7-253 DPC Status Register 3666 3254 Figure 7-253 Figure 7-244: PTM Capability Structure 3255 3667 Figure 7-254 DPC Error Source ID Register 3668 3256 Figure 7-254 PTM Extended Capability Header 3257 3669 Figure 7-255 RP PIO Status Register 3670 3258 Figure 7-255 Table 7-200: PTM Capability Register 3259 3671 Figure 7-256 RP PIO Mask Register 3672 3260 Figure 7-256 Table 7-201: PTM Control Register 3261 3673 Figure 7-257 RP PIO Severity Register 3674 3262 Figure 7-257 Readiness Time Reporting Extended Capability 3263 3675 Figure 7-258 RP PIO SysError Register 3676 3264 Figure 7-258 Readiness Time Encoding 3265 3677 Figure 7-259 RP PIO Exception Register 3678 3266 Figure 7-259 Readiness Time Reporting Extended Capability 3679 Figure 7-260 RP PIO Header Log Register Header 3267 3268 3680 Figure 7-260 Readiness Time Reporting 1 Register 3269 3270 Figure 7-261 Readiness Time Reporting 2 Register Figure 7-262 Hierarchy ID Extended Capability Figure 7-263 Hierarchy ID Extended Capability Header Figure 7-264 Hierarchy ID Status Register Figure 7-265 Hierarchy ID Data Register Figure 7-266 Hierarchy ID GUID 1 Register Figure 7-264 PTM Extended Capability Header 3689 Figure 7-265 PTM Capability Register 3691 Figure 7-266 PTM Control Register 3693 Figure 7-267 Readiness Time Reporting Extended Capability 3694 Figure 7-267 Hierarchy ID GUID 2 Register 3283 3284 3687 3692 3281 3282 Figure 7-263 PTM Capability Structure 3690 3279 3280 3685 3688 3277 3278 Figure 7-262 RP PIO TLP Prefix Log Register 3686 3275 3276 3683 3684 3273 3274 Figure 7-261 RP PIO ImpSpec Log Register 3682 3271 3272 3681 3695 Figure 7-268 Readiness Time Encoding 3696 Figure 7-268 Hierarchy ID GUID 3 Register 3697 Figure 7-269 Readiness Time Reporting Extended Capability Header 3285 3286 3698 Figure 7-269 Hierarchy ID GUID 4 Register 3287 3288 Page 46 3699 Figure 7-270 Readiness Time Reporting 1 Register 3700 Figure 7-270 Hierarchy ID GUID 5 Register 3701 Figure 7-271 Readiness Time Reporting 2 Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3288 Figure 7-270 Hierarchy ID GUID 5 Register 3289 3290 Figure 7-271 VPD Capability Structure Figure 7-272 VPD Address Register Figure 7-273 VPD Data Register Figure 7-274 NPEM Extended Capability Figure 7-275 NPEM Extended Capability Header Figure 7-276 NPEM Capability Register Figure 7-274 Hierarchy ID Status Register 3709 Figure 7-275 Hierarchy ID Data Register 3711 Figure 7-276 Hierarchy ID GUID 1 Register 3713 Figure 7-277 Hierarchy ID GUID 2 Register 3714 Figure 7-277 NPEM Control Register 3303 3304 3707 3712 3301 3302 Figure 7-273 Hierarchy ID Extended Capability Header 3710 3299 3300 3705 3708 3297 3298 Figure 7-272 Hierarchy ID Extended Capability 3706 3295 3296 3703 3704 3293 3294 Figure 7-271 Readiness Time Reporting 2 Register 3702 3291 3292 3701 3715 Figure 7-278 Hierarchy ID GUID 3 Register 3716 Figure 7-278 NPEM Status Register 3717 Figure 7-279 Hierarchy ID GUID 4 Register 3718 3719 Figure 7-280 Hierarchy ID GUID 5 Register 3720 3721 Figure 7-281 VPD Capability Structure 3722 3723 Figure 7-282 VPD Address Register 3724 3725 Figure 7-283 VPD Data Register 3726 3727 Figure 7-284 NPEM Extended Capability 3728 3729 Figure 7-285 NPEM Extended Capability Header 3730 3731 Figure 7-286 NPEM Capability Register 3732 3733 Figure 7-287 NPEM Control Register 3734 3735 Figure 7-288 NPEM Status Register 3736 3737 Figure 7-289 Alternate Protocol Extended Capability 3738 3739 Figure 7-290 Alternate Protocol Extended Capability Header 3740 3741 Figure 7-291 Alternate Protocol Capabilities Register 3742 3743 Figure 7-292 Alternate Protocol Control Register 3744 3745 Figure 7-293 Alternate Protocol Data 1 Register 3746 3747 Figure 7-294 Alternate Protocol Data 2 Register 3748 3749 Figure 7-295 Alternate Protocol Selective Enable Mask Register 3750 3751 Figure 7-296 Conventional PCI Advanced Features Capability (AF) Page 47 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3751 Figure 7-296 Conventional PCI Advanced Features Capability (AF) 3752 3753 Figure 7-297 Advanced Features Capability Header 3754 3755 Figure 7-298 AF Capabilities Register 3756 3757 Figure 7-299 Conventional PCI Advanced Features Control Register 3758 3759 Figure 7-300 AF Status Register 3760 3761 Figure 7-301 SFI Extended Capability 3762 3763 Figure 7-302 SFI Extended Capability Header 3764 3765 Figure 7-303 SFI Capability Register 3766 3767 Figure 7-304 SFI Control Register 3768 3769 Figure 7-305 SFI Status Register 3770 3771 Figure 7-306 SFI CAM Address Register 3772 3773 Figure 7-307 SFI CAM Data Register 3774 3775 3305 3306 Figure 8-1 Tx Test Board for Non-Embedded Refclk 3307 3777 Figure 8-2 Tx Test board for Embedded Refclk 3309 3779 Figure 8-2 Tx Test board for Embedded Refclk 3780 3310 Figure 8-3 Single-ended and Differential Levels 3311 3781 Figure 8-3 Single-ended and Differential Levels 3782 3312 Figure 8-4 Tx Equalization FIR Representation 3313 3783 Figure 8-4 Tx Equalization FIR Representation 3784 3314 Figure 8-5 Definition of Tx Voltage Levels and Equalization 3785 Ratios 3324 Figure 8-5 Definition of Tx Voltage Levels and Equalization Ratios Figure 8-10 Measuring VTX-EIEOS-FS and VTX-EIEOS-RS at 8.0 GT/ 3795 s Figure 8-10 Measuring VTX-EIEOS-FS and VTX-EIEOS-RS at 8.0 GT/ s 3325 3796 3326 Figure 8-11 Compliance Pattern and Resulting Package Loss Test 3797 Waveform Figure 8-11 Compliance Pattern and Resulting Package Loss Test Waveform 3327 3798 Figure 8-12 2.5 and 5.0 GT/s Transmitter Margining Voltage Levels and Codes 3329 3799 Figure 8-12 2.5 and 5.0 GT/s Transmitter Margining Voltage Levels and Codes 3800 3330 Figure 8-13 First Order CC Behavioral CDR Transfer Functions 3331 3332 Figure 8-1 Tx Test Board for Non-Embedded Refclk 3778 3308 3328 Figure 7-308 Subsystem ID and Sybsystem Vendor ID Capability 3776 3801 Figure 8-13 First Order CC Behavioral CDR Transfer Functions 3802 Figure 8-14 2nd Order Behavioral SRIS CDR Transfer Functions for 2.5 GT/s and 5.0 GT/s Page 48 3803 Figure 8-14 2nd Order Behavioral SRIS CDR Transfer Functions for 2.5 GT/s and 5.0 GT/s /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 3332 /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html Figure 8-14 2nd Order Behavioral SRIS CDR Transfer Functions 3803 for 2.5 GT/s and 5.0 GT/s 3333 3804 3334 Figure 8-15 Behavioral SRIS CDR Functions for 8.0 and 16.0 GT/ 3805 s 3335 Figure 8-15 Behavioral SRIS CDR Function for 8.0 GT/s and SRIS and CC CDR for 16.0 GT/s 3806 3336 Figure 8-16 Relation Between Data Edge PDFs and Recovered Data 3807 Clock Figure 8-16 Relation Between Data Edge PDFs and Recovered Data Clock 3337 3808 3338 Figure 8-17 Derivation of TTX-UTJ and TTX-UDJDD 3339 3809 Figure 8-17 Derivation of TTX-UTJ and TTX-UDJDD 3810 3340 Figure 8-18 PWJ Relative to Consecutive Edges 1 UI Apart 3341 3342 Figure 8-14 2nd Order Behavioral SRIS CDR Transfer Functions for 2.5 GT/s and 5.0 GT/s 3811 Figure 8-18 PWJ Relative to Consecutive Edges 1 UI Apart 3812 Figure 8-19 Definition of TTX-UPW-DJDD and TTX-UPW-TJ Data Rate Dependent Transmitter Parameters 3343 3344 3813 Figure 8-19 Definition of TTX-UPW-DJDD and TTX-UPW-TJ Data Rate Dependent Transmitter Parameters 3814 Figure 8-20 Tx, Rx Differential Return Loss Mask 3815 Figure 8-20 Tx, Rx Differential Return Loss Mask with 50 Ohm Reference 3345 3346 3816 Figure 8-21 Tx, Rx Common Mode Return Loss Mask 3817 Figure 8-21 Tx, Rx Common Mode Return Loss Mask with 50 Ohm Reference 3347 3348 3818 Figure 8-22 Rx Testboard Topology for 16.0 GT/s 3349 3350 Figure 8-23 Calibration Channel IL Mask Excluding Rx Package Figure 8-25 Stackup for Example 16.0 GT/s Calibration Channel Figure 8-26 CEM Connector Drill Hole Pad Stack Figure 8-24 Example 16.0 GT/s Calibration Channel 3825 Figure 8-25 Stackup for Example 16.0 GT/s Calibration Channel 3827 Figure 8-26 CEM Connector Drill Hole Pad Stack 3828 Figure 8-27 Pad Stack for SMA Drill Holes 3359 3360 3823 3826 3357 3358 Figure 8-23 Example Calibration Channel IL Mask Excluding Rx Package for 8.0 GT/s 3824 3355 3356 3821 3822 Figure 8-24 Example 16.0 GT/s Calibration Channel 3353 3354 Figure 8-22 Rx Testboard Topology for 16.0 and 32.0 GT/s 3820 3351 3352 3819 3829 Figure 8-27 Pad Stack for SMA Drill Holes 3830 Figure 8-28 Transfer Function for 8.0 GT/s Behavioral CTLE 3831 Figure 8-28 Example 32.0 GT/s Calibration Channel 3832 3833 Figure 8-29 Stack-up for Example 32.0 GT/s Calibration Channel 3834 3835 Figure 8-30 Transfer Function for 8.0 GT/s Behavioral CTLE 3836 3837 Figure 8-31 Loss Curves for 8.0 GT/s Behavioral CTLE 3838 3839 3361 3362 Figure 8-29 Loss Curves for 8.0 GT/s Behavioral CTLE 3363 3364 Figure 8-30 Loss Curves for 16.0 GT/s Behavioral CTLE Figure 8-33 Loss Curves for 32.0 GT/s Behavioral CTLE 3843 Figure 8-34 Variables Definition and Diagram for 1-tap DFE 3844 Figure 8-31 Variables Definition and Diagram for 1-tap DFE 3367 3368 3841 3842 3365 3366 Figure 8-32 Loss Curves for 16.0 GT/s Behavioral CTLE 3840 3845 Figure 8-35 Diagram for 2-tap DFE 3846 Figure 8-32 Diagram for 2-tap DFE 3847 Figure 8-36 Layout for Calibrating the Stressed Jitter Eye at 8.0 GT/s Page 49 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3847 Figure 8-36 Layout for Calibrating the Stressed Jitter Eye at 8.0 GT/s 3369 3848 3370 Figure 8-33 Layout for Calibrating the Stressed Jitter Eye at 3849 8.0 GT/s 3371 3850 3372 Figure 8-34 Layout for Calibrating the Stressed Jitter Eye at 3851 16.0 GT/s 3852 3374 Figure 8-35 Sj Mask for Receivers Operating in IR mode at 8.0 3853 GT/s Figure 8-39 Sj Mask for Receivers Operating in SRIS mode at 16.0 GT/s 3375 3854 3376 Figure 8-36 Sj Mask for Receivers Operating in IR mode at 16.0 3855 GT/s Figure 8-40 Sj Mask for Receivers Operating in CC mode at 16.0 GT/s 3377 3856 Figure 8-37 Sj Masks for Receivers Operating in CC Mode at 8.0 GT/s and 16.0 GT/s 3379 3857 Figure 8-41 Sj Mask for Receivers Operating in SRIS mode at 32.0 GT/s 3858 3380 Figure 8-38 Layout for Jitter Testing Common Refclk Rx at 16.0 3859 GT/s Figure 8-42 Sj Mask for Receivers Operating in CC mode at 32.0 GT/s 3381 3382 Figure 8-38 Sj Mask for Receivers Operating in IR mode at 8.0 GT/s 3373 3378 Figure 8-37 Layout for Calibrating the Stressed Jitter Eye at 16.0 GT/s 3860 Figure 8-39 Layout for Jitter Testing for Independent Refclk Rx at 16.0 GT/s 3383 3861 Figure 8-43 Sj Masks for Receivers Operating in CC Mode at 8.0 GT/s 3862 3384 Figure 8-40 Exit from Idle Voltage and Time Margins 3863 Figure 8-44 Layout for Jitter Testing Common Refclk Rx at 16.0 GT/s 3385 3864 3386 Figure 8-41 Allowed Ranges for Maximum Timing and Voltage 3865 Margins 3387 Figure 8-45 Layout for Jitter Testing for Independent Refclk Rx at 16.0 GT/s 3866 3388 Figure 8-42 Flow Diagram for Channel Tolerancing at 2.5 and 5.0 3867 Figure 8-46 Exit from Idle Voltage and Time Margins GT/s 3389 3868 3390 Figure 8-43 Flow Diagram for Channel Tolerancing at 8.0 and 3869 16.0 GT/s 3391 3392 Figure 8-47 Allowed Ranges for Maximum Timing and Voltage Margins 3870 Figure 8-44 Tx/Rx Behavioral Package Models 3871 Figure 8-48 Flow Diagram for Channel Tolerancing at 2.5 and 5.0 GT/s 3393 3394 3872 Figure 8-45 Behavioral Tx and Rx S-Port Designation 3873 Figure 8-49 Flow Diagram for Channel Tolerancing at 8.0 and 16.0 GT/s 3395 3396 3874 Figure 8-46 SDD21 Plots for Root and Non-Root Packages 3397 3398 Figure 8-50 Tx/Rx Behavioral Package Models 3876 Figure 8-47 Derivation of 8.0 GT/s Jitter Parameters for 3399 3400 3875 3877 Figure 8-51 Behavioral Tx and Rx S-Port Designation for 8.0 and 16.0 GT/s Packages 3878 Figure 8-48 EH, EW Mask 3879 Figure 8-52 SDD21 Plots for Root and Non-Root Packages for 16.0 GT/s 3401 3402 3880 Figure 8-49 Refclk Test Setup 3881 Figure 8-53 Insertion Loss for Root Reference Package for 32.0 GT/s Page 50 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3881 Figure 8-53 Insertion Loss for Root Reference Package for 32.0 GT/s 3403 3404 3882 Figure 8-50 Single-Ended Measurement Points for Absolute Cross Point and Swing 3405 3883 3884 3406 Figure 8-51 Single-Ended Measurement Points for Delta Cross 3885 Point Figure 8-55 NEXT for Root Reference Package (Worst Case) for 32.0 GT/s 3407 3408 Figure 8-54 Return Loss for Root Reference Package for 32.0 GT/ s 3886 Figure 8-52 Single-Ended Measurement Points for Rise and Fall Time Matching 3409 3887 Figure 8-56 FEXT for Root Reference Package (Worst Case) for 32.0 GT/s 3888 3410 Figure 8-53 Differential Measurement Points for Duty Cycle and 3889 Period Figure 8-57 Insertion Loss for Non-Root Reference Package for 32.0 GT/s 3411 3890 3412 Figure 8-54 Differential Measurement Points for Rise and Fall 3891 Time Figure 8-58 Return Loss for Non-Root Reference Package for 32.0 GT/s 3413 3892 3414 Figure 8-55 Differential Measurement Points for Ringback 3415 3893 Figure 8-59 NEXT for Non-Root Reference Package (Worst Case) for 32.0 GT/s 3894 3416 Figure 8-56 Limits for phase jitter from the Reference 3417 3895 Figure 8-60 FEXT for Non-Root Reference Package (Worst Case) for 32.0 GT/s 3896 3418 Figure 8-57 5 MHz PLL Transfer Function Example 3419 3897 Figure 8-61 32.0 GT/s Reference Package Port Connections for Pin to Pin Channel Evaluation 3898 3420 Figure 8-58 Common Refclk Rx Architecture 3899 Figure 8-62 Example Derivation of 8.0 GT/s Jitter Parameters for 3421 3900 3422 Figure 8-59 Common Refclk PLL and CDR Characteristics for 2.5 3901 Figure 8-63 EH, EW Mask GT/s 3423 3902 3424 Figure 8-60 Common Refclk PLL and CDR Characteristics for 5.0 3903 GT/s 3425 3426 Figure 8-64 Oscilloscope Refclk Test Setup For All Cases Except Jitter at 32.0 GT/s 3904 Figure 8-61 Common Refclk PLL and CDR Characteristics for 8.0 and 16.0 GT/s 3905 Figure 8-65 Single-Ended Measurement Points for Absolute Cross Point and Swing 3906 3907 Figure 8-66 Single-Ended Measurement Points for Delta Cross Point 3908 3909 Figure 8-67 Single-Ended Measurement Points for Rise and Fall Time Matching 3910 3911 Figure 8-68 Differential Measurement Points for Duty Cycle and Period 3912 3913 Figure 8-69 Differential Measurement Points for Rise and Fall Time 3914 3915 Page 51 Figure 8-70 Differential Measurement Points for Ringback /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3915 Figure 8-70 Differential Measurement Points for Ringback 3916 3917 Figure 8-71 Limits for phase jitter from the Reference with 5000 ppm SSC 3918 3919 Figure 8-72 5 MHz PLL Transfer Function Example 3920 3921 Figure 8-73 Common Refclk Rx Architecture for all Data Rates Except 32.0 GT/s 3922 3923 Figure 8-74 Common Refclk PLL and CDR Characteristics for 2.5 GT/s 3924 3925 Figure 8-75 Common Refclk PLL and CDR Characteristics for 5.0 GT/s 3926 3927 Figure 8-76 Common Refclk PLL and CDR Characteristics for 8.0 and 16.0 GT/s 3928 3929 Figure 8-77 Common Refclk PLL and CDR Characteristics for 32.0 GT/s 3427 3930 3428 Figure 9-1 Generic Platform Configuration 3429 3430 3931 Figure 9-1 Generic Platform Configuration 3932 Figure 9-2 Generic Platform Configuration with a VI and Multiple SI 3431 3933 Figure 9-2 Generic Platform Configuration with a VI and Multiple SI 3934 3432 Figure 9-3 Generic Platform Configuration with SR-IOV and IOV 3935 Enablers 3433 3434 3936 Figure 9-4 Example Multi-Function Device 3435 3436 3439 3937 Figure 9-4 Example Multi-Function Device 3938 Figure 9-5 Example SR-IOV Single PF Capable Device 3437 3438 Figure 9-3 Generic Platform Configuration with SR-IOV and IOV Enablers 3939 Figure 9-5 Example SR-IOV Single PF Capable Device 3940 Figure 9-6 Example SR-IOV Multi-PF Capable Device 3941 Figure 9-6 Example SR-IOV Multi-PF Capable Device 3942 3943 Figure 9-7 Example SR-IOV Device with Multiple Bus Numbers 3944 3945 Figure 9-8 Example SR-IOV Device with a Mixture of Function Types 3946 3947 Figure 9-9 I/O Virtualization Interoperability 3948 3949 Figure 9-10 BAR Space Example for Single BAR Device 3950 3951 Figure 9-11 Initial VF Migration State Array 3952 3953 Figure 9-12 VF Migration State Diagram 3954 3955 3956 Page 52 Figure 9-13 SR-IOV Extended Capability /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3956 3957 Figure 9-14 SR-IOV Extended Capability Header 3958 3959 Figure 9-15 SR-IOV Capabilities Register 3960 3961 Figure 9-16 SR-IOV Control Register 3962 3963 Figure 9-17 SR-IOV Status 3964 3965 Figure 9-18 VF Migration State Array Offset 3966 3967 Figure 9-19 VF Migration State Entry 3968 3969 Figure 9-20 PF/VF Type 0 Configuration Space Header 3970 3971 Figure 9-21 VF Resizable BAR Extended Capability 3972 3973 Figure 9-22 VF Resizable BAR Extended Capability Header 3974 3975 Figure 9-23 VF Resizable BAR Control Register 3976 3977 Figure 9-24 MSI-X Capability 3978 3440 Figure 10-1 Example Illustrating a Platform with TA, ATPT, and ATC Elements 3441 3979 3980 3442 Figure 10-2 Example ATS Translation Request/Completion 3981 Exchange 3982 3444 Figure 10-3 Example Multi-Function Device with ATC per 3983 Function Figure 10-3 Example Multi-Function Device with ATC per Function 3445 3984 Figure 10-4 Invalidation Protocol with a Single Invalidation Request and Completion 3447 3448 Figure 10-2 Example ATS Translation Request/Completion Exchange 3443 3446 Figure 10-1 Example Illustrating a Platform with TA, ATPT, and ATC Elements 3985 Figure 10-4 Invalidation Protocol with a Single Invalidation Request and Completion 3986 Figure 10-5 Single Invalidate Request with Multiple Invalidate Completions 3449 3987 Figure 10-5 Single Invalidate Request with Multiple Invalidate Completions 3988 3450 Figure 10-6 Memory Request Header with 64-bit Address 3451 3989 Figure 10-6 Memory Request Header with 64-bit Address 3990 3452 Figure 10-7 Figure 10-7: Memory Request Header with 32-bit 3991 Figure 10-7 Memory Request Header with 32-bit Address Address 3453 3454 3992 Figure 10-8 64-bit Translation Request Header 3455 3456 Figure 10-9 32-bit Translation Request Header 3461 Page 53 3995 Figure 10-9 32-bit Translation Request Header 3996 Figure 10-10 Translation Completion with No Data 3459 3460 Figure 10-8 64-bit Translation Request Header 3994 3457 3458 3993 3997 Figure 10-10 Translation Completion with No Data 3998 Figure 10-11 Successful Translation Completion 3999 4000 Figure 10-11 Successful Translation Completion /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3461 4000 3462 Figure 10-12 Translation Completion Data Entry 4001 Figure 10-12 Translation Completion Data Entry 3470 Figure 10-16 Page Request Message 4009 Figure 10-16 Page Request Message 3471 4010 3472 Figure 10-17 Stop Marker Message 3473 Figure 10-18 PRG Response Message 3475 4013 Figure 10-19 ATS Extended Capability Structure 3477 4015 Figure 10-19 ATS Extended Capability Structure 4016 3478 Figure 10-20 ATS Extended Capability Header 3479 4017 Figure 10-20 ATS Extended Capability Header 4018 3480 Figure 10-21 ATS Capability Register 3481 4019 Figure 10-21 ATS Capability Register (Offset 04h) 4020 3482 Figure 10-22 ATS Control Register 3483 4021 Figure 10-22 ATS Control Register 4022 3484 Figure 10-23 Page Request Extended Capability Structure 3485 4023 Figure 10-23 Page Request Extended Capability Structure 4024 3486 Figure 10-24 Page Request Extended Capability Header 3487 4025 Figure 10-24 Page Request Extended Capability Header 4026 3488 Figure 10-25 Page Request Control Register 3489 4027 Figure 10-25 Page Request Control Register 4028 3490 Figure 10-26 Page Request Status Register 3491 4029 Figure 10-26 Page Request Status Register 4030 Figure A-1 An Example Showing Endpoint-to-Root-Complex and Peer-to-Peer Communication Models 3493 4031 Figure A-1 An Example Showing Endpoint-to-Root-Complex and Peer-to-Peer Communication Models 4032 Figure A-2 Two Basic Bandwidth Resourcing Problems: OverSubscription and Congestion 3495 4033 Figure A-2 Two Basic Bandwidth Resourcing Problems: OverSubscription and Congestion 4034 3496 Figure A-3 Isochronous Bandwidth Ranges and Granularities 4035 3497 3498 Figure 10-18 PRG Response Message 4014 3476 3494 Figure 10-17 Stop Marker Message 4012 3474 3492 4011 Figure A-3 A Simplified Example Illustrating PCI Express Isochronous Parameters Figure A-4 A Simplified Example Illustrating PCI Express Isochronous Parameters 3499 3500 4036 Figure C-1 Scrambling Spectrum at 2.5 GT/s for Data Value of 0 3501 3502 Figure E-1 Reference Topology for IDO Use 4039 Figure E-1 Reference Topology for IDO Use 4040 Figure G-1 Device and Processor Connected Using a PMUX Link 3505 3506 Figure C-1 Scrambling Spectrum at 2.5 GT/s for Data Value of 0 4038 3503 3504 4037 4041 Figure G-1 Device and Processor Connected Using a PMUX Link 4042 Figure G-2 PMUX Link 3507 4043 Figure G-2 PMUX Link 4044 3508 Figure G-3 PMUX Packet Flow Through the Layers 4045 Figure G-3 PMUX Packet Flow Through the Layers 3522 Figure G-10 PMUX Control Register 4059 Figure G-10 PMUX Control Register 3523 3524 4060 Figure G-11 PMUX Status Register 3525 3526 4061 Figure G-12 PMUX Protocol Array Entry 4063 3527 4064 3528 4065 Page 54 Figure G-11 PMUX Status Register 4062 Figure G-12 PMUX Protocol Array Entry /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3528 4065 3529 4066 3530 4067 3531 3532 4068 Table of Equations 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 Equation 8-1 Equation 8-1 3562 3563 Equation 8-2 Equation 8-2 3564 3565 Equation 8-3 SRIS Behavioral CDR at 8.0 and 16.0 GT/s 3566 3567 Equation 8-4 SRIS Behavioral CDR Parameters at 8.0 GT/s 3568 3569 Equation 8-5 SRIS Behavioral CDR Parameters at 16.0 GT/s 3570 3571 3572 3573 3574 3575 3576 3577 3578 Page 55 Equation 8-6 Equation 8-6 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 Table of Tables 4069 3596 4070 3597 4071 Table of Tables 3598 3599 3600 Table 2-1 Transaction Types for Different Address Spaces 3601 3602 Table 2-2 Fmt[2:0] Field Values Table 2-3 Fmt[2:0] and Type[4:0] Field Encodings Table 2-4 Length[9:0] Field Encoding Table 2-5 Address Field Mapping Table 2-17 Message Routing Table 2-18 INTx Mechanism Messages Table 2-19 Bridge Mapping for INTx Virtual Wires Table 2-20 Power Management Messages Table 2-21 Error Signaling Messages Table 2-22 Unlock Message Table 2-23 Set_Slot_Power_Limit Message Table 2-24 Vendor_Defined Messages Page 56 Table 2-18 INTx Mechanism Messages 4108 Table 2-19 Bridge Mapping for INTx Virtual Wires 4110 Table 2-20 Power Management Messages 4112 Table 2-21 Error Signaling Messages 4114 Table 2-22 ERR_COR Subclass (ECS) Field Encodings 4116 Table 2-23 Unlock Message 4118 Table 2-24 Set_Slot_Power_Limit Message 4119 Table 2-25 Notification Reason (NR) Field Encodings 3649 3650 4106 4117 3647 3648 Table 2-17 Message Routing 4115 3645 3646 4104 4113 3643 3644 Table 2-5 Address Field Mapping 4111 3641 3642 4080 4109 3639 3640 Table 2-4 Length[9:0] Field Encoding 4107 3637 3638 4078 4105 3635 3636 Table 2-3 Fmt[2:0] and Type[4:0] Field Encodings 4081 3633 3634 4076 4079 3609 3632 Table 2-2 Fmt[2:0] Field Values 4077 3607 3608 4074 4075 3605 3606 Table 2-1 Transaction Types for Different Address Spaces 4073 3603 3604 4072 4120 Table 2-25 Vendor_Defined Messages 4121 Table 2-26 LN Messages 4122 Table 2-26 Notification Reason (NR) Field Encodings /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3650 Table 2-26 LN Messages 3651 Table 2-27 Table 2-27: DRS Message 3653 Table 2-28 FRS Message 3655 Table 2-29 Hierarchy ID Message 3657 4126 Table 2-28 DRS Message 4128 Table 2-29 FRS Message 4129 3658 Table 2-30 Ignored Messages 3659 4130 Table 2-30 Hierarchy ID Message 4131 3660 Table 2-31 LTR Message 3661 4132 Table 2-31 Ignored Messages 4133 3662 Table 2-32 OBFF Message 3663 4134 Table 2-32 LTR Message 4135 3664 Table 2-33 Precision Time Measurement Messages 3665 4136 Table 2-33 OBFF Message 4137 3666 Table 2-34 Completion Status Field Values 3667 4138 Table 2-34 Precision Time Measurement Messages 4139 3668 Table 2-35 Local TLP Prefix Types 3669 4140 Table 2-35 Completion Status Field Values 4141 3670 Table 2-36 End-End TLP Prefix Types 3671 4142 Table 2-36 Local TLP Prefix Types 4143 3672 Table 2-37 Calculating Byte Count from Length and Byte Enables 3673 4144 Table 2-37 End-End TLP Prefix Types 4145 3674 Table 2-38 Calculating Lower Address from 1st DW BE 3675 4146 Table 2-38 Calculating Byte Count from Length and Byte Enables 4147 3676 Table 2-39 Ordering Rules Summary 3677 4148 Table 2-39 Calculating Lower Address from First DW BE 4149 3678 Table 2-40 TC to VC Mapping Example 3679 4150 Table 2-40 Ordering Rules Summary 4151 3680 Table 2-41 Flow Control Credit Types 3681 4152 Table 2-41 TC to VC Mapping Example 4153 3682 Table 2-42 TLP Flow Control Credit Consumption 3683 4154 Table 2-42 Flow Control Credit Types 4155 3684 Table 2-43 Minimum Initial Flow Control Advertisements 3685 4156 Table 2-43 TLP Flow Control Credit Consumption 4157 3686 Table 2-44 [Field Size] Values 3687 4158 Table 2-44 Minimum Initial Flow Control Advertisements 4159 Table 2-45 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s (Symbol Times) 3689 4160 Table 2-45 [Field Size] Values 4161 Table 2-46 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) 3691 4162 Table 2-46 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s (Symbol Times) 4163 Table 2-47 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s (Symbol Times) 3693 3694 Table 2-27 LN Messages 4127 3656 3692 4124 4125 3654 3690 Table 2-26 Notification Reason (NR) Field Encodings 4123 3652 3688 4122 4164 Table 2-47 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) 4165 Table 2-48 Maximum UpdateFC Transmission Latency Guidelines for 16.0 GT/s (Symbol Times) 3695 3696 Page 57 4166 Table 2-48 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s and Higher Data Rates (Symbol Times) 4167 Table 2-49 Mapping of Bits into ECRC Field 4168 Table 2-49 Mapping of Bits into ECRC Field /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3696 Table 2-49 Mapping of Bits into ECRC Field 3697 4168 Table 2-49 Mapping of Bits into ECRC Field 4169 3698 Table 3-1 Data Link Feature Supported Bit Definition 3699 4170 Table 3-1 Data Link Feature Supported Bit Definition 4171 3700 Table 3-2 Scaled Flow Control Scaling Factors 3701 4172 Table 3-2 Scaled Flow Control Scaling Factors 4173 3702 Table 3-3 DLLP Type Encodings 3703 4174 Table 3-3 DLLP Type Encodings 4175 3704 Table 3-4 HdrScale and DataScale Encodings 3705 4176 Table 3-4 HdrScale and DataScale Encodings 4177 3706 Table 3-5 Mapping of Bits into CRC Field 3707 4178 Table 3-5 Mapping of Bits into CRC Field 4179 3708 Table 3-6 Mapping of Bits into LCRC Field 3709 4180 Table 3-6 Mapping of Bits into LCRC Field 4181 3710 Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol 4182 Times) Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol Times) 3711 4183 3712 Table 3-8 Maximum Ack Latency Limits for 5.0 GT/s (Symbol 4184 Times) Table 3-8 Maximum Ack Latency Limits for 5.0 GT/s (Symbol Times) 3713 4185 3714 Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s (Symbol 4186 Times) Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s and higher data rates (Symbol Times) 3715 3716 Table 3-10 Maximum Ack Latency Limits for 16.0 GT/s (Symbol Times) 3717 4187 3718 Table 4-1 Special Symbols 3719 4188 Table 4-1 Special Symbols 4189 3720 Table 4-2 Framing Token Encoding 3721 4190 Table 4-2 Framing Token Encoding 4191 3722 Table 4-3 Transmitter Preset Encoding 4192 Table 4-3 Equalization requirements under different conditions 3723 3724 Table 4-4 Receiver Preset Hint Encoding for 8.0 GT/s 3725 3726 Table 4-5 TS1 Ordered Set 3727 3728 Table 4-6 TS2 Ordered Set 3729 3730 4193 Table 4-7 Electrical Idle Ordered Set (EIOS) for 2.5 GT/s and 5.0 GT/s Data Rates 3731 3732 4194 Table 4-4 Transmitter Preset Encoding 4195 Table 4-8 Electrical Idle Ordered Set (EIOS) for 8.0 GT/s and Above Data Rates 3733 4196 Table 4-5 Receiver Preset Hint Encoding for 8.0 GT/s 4197 3734 Table 4-9 Electrical Idle Exit Ordered Set (EIEOS) for 5.0 GT/s 4198 Table 4-6 TS1 Ordered Set Data Rate 3735 3736 4199 Table 4-10 Electrical Idle Exit Ordered Set (EIEOS) for 8.0 GT/ s Data Rates 3737 3738 4200 Table 4-7 TS2 Ordered Set 4201 Table 4-11 Electrical Idle Exit Ordered Set (EIEOS) for 16.0 GT/s Data Rate Page 58 4202 Table 4-8 Modified TS1/TS2 Ordered Set (8b/10b encoding) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3738 Table 4-11 Electrical Idle Exit Ordered Set (EIEOS) for 16.0 GT/s Data Rate 3739 4202 Table 4-8 Modified TS1/TS2 Ordered Set (8b/10b encoding) 4203 3740 Table 4-12 Electrical Idle Inference Conditions 3741 4204 Table 4-9 Modified TS Information 1 field in Modified TS1/TS2 Ordered Sets if Modified TS Usage = 010b (Alternate Protocol) 4205 3742 Table 4-13 FTS for 8.0 GT/s and Above Data Rates 3743 4206 Table 4-10 Electrical Idle Ordered Set (EIOS) for 2.5 GT/s and 5.0 GT/s Data Rates 4207 3744 Table 4-14 SDS Ordered Set (for 8.0 GT/s and Above Data Rate) 3745 4208 Table 4-11 Electrical Idle Ordered Set (EIOS) for 8.0 GT/s and Above Data Rates 4209 3746 Table 4-15 Link Status Mapped to the LTSSM 3747 4210 Table 4-12 Electrical Idle Exit Ordered Set (EIEOS) for 5.0 GT/ s Data Rate 4211 3748 Table 4-16 Standard SKP Ordered Set with 128b/130b Encoding 3749 4212 Table 4-13 Electrical Idle Exit Ordered Set (EIEOS) for 8.0 GT/ s Data Rates 4213 3750 Table 4-17 Control SKP Ordered Set with 128b/130b Encoding 3751 4214 Table 4-14 Electrical Idle Exit Ordered Set (EIEOS) for 16.0 GT/s Data Rate 4215 4216 3752 Table 4-15 Electrical Idle Exit Ordered Set (EIEOS) for 32.0 GT/s Data Rate 4217 4218 3753 Table 4-16 Electrical Idle Inference Conditions 4219 4220 3754 Table 4-17 FTS for 8.0 GT/s and Above Data Rates 4221 4222 Table 4-18 SDS Ordered Set (for 8.0 GT/s and 16.0 GT/s Data Rate) 3755 4223 4224 Table 4-19 SDS Ordered Set (for 32.0 GT/s and higher Data Rate) 3756 4225 4226 3757 4228 3758 Table 4-21 Compliance Pattern Settings 4229 4230 3759 Table 4-22 Standard SKP Ordered Set with 128b/130b Encoding 4231 4232 3760 Table 4-23 Control SKP Ordered Set with 128b/130b Encoding 4233 4234 3761 Table 4-24 Illustration of Modified Compliance Pattern 4235 4236 3762 Table 4-25 Margin Command Related Fields in the Control SKP Ordered Set 4237 4238 3763 3764 Table 4-20 Link Status Mapped to the LTSSM 4227 Table 4-26 Margin Commands and Corresponding Responses 4239 Table 4-24 Margin Command Related Fields in the Control SKP Ordered Set Page 59 4240 Table 4-27 Maximum Retimer Exit Latency /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3764 Table 4-24 Margin Command Related Fields in the Control SKP Ordered Set 3765 4241 3766 Table 4-25 Margin Commands and Corresponding Responses 3767 4242 Table 4-28 Inferring Electrical Idle 4243 3768 Table 4-26 Maximum Retimer Exit Latency 3769 4244 Table 4-29 Retimer Latency Limit not SRIS (Symbol times) 4245 3770 Table 4-27 Inferring Electrical Idle 4246 Table 4-30 Retimer Latency Limit SRIS (Symbol times) 3771 3772 Table 4-28 Retimer Latency Limit not SRIS (Symbol times) 3773 3774 Table 4-29 Retimer Latency Limit SRIS (Symbol times) 3775 4247 3776 Table 5-1 Summary of PCI Express Link Power Management States 3777 4248 Table 5-1 Summary of PCI Express Link Power Management States 4249 3778 Table 5-2 Relation Between Power Management States of Link and 4250 Components Table 5-2 Relation Between Power Management States of Link and Components 3779 4251 3780 Table 5-3 Encoding of the ASPM Support Field 3781 4252 Table 5-3 Encoding of the ASPM Support Field 4253 3782 Table 5-4 Description of the Slot Clock Configuration Bit 3783 4254 Table 5-4 Description of the Slot Clock Configuration Bit 4255 3784 Table 5-5 Description of the Common Clock Configuration Bit 4256 3790 Table 5-8 Encoding of the Endpoint L0s Acceptable Latency 4262 Field 4263 Table 5-9 Encoding of the Endpoint L1 Acceptable Latency Field 3793 3794 Table 5-10 Encoding of the ASPM Control Field Table 5-11 L1.2 Timing Parameters 4266 Table 5-10 Encoding of the ASPM Control Field 4268 Table 5-11 L1.2 Timing Parameters 4269 Table 5-12 Power Management System Messages and DLLPs 3799 3800 Table 5-9 Encoding of the Endpoint L1 Acceptable Latency Field 4267 3797 3798 4264 4265 3795 3796 Table 5-8 Encoding of the Endpoint L0s Acceptable Latency Field 3791 3792 Table 5-5 Description of the Common Clock Configuration Bit 4270 Table 5-12 Power Management System Messages and DLLPs 4271 Table 5-13 D0 Power Management Policies 4272 Table 5-13 PCI Function State Transition Delays 3801 3802 Table 5-14 D1 Power Management Policies 3803 3804 Table 5-15 D2 Power Management Policies 3805 3806 Table 5-16 D3hot Power Management Policies 3807 3808 Table 5-17 D3cold Power Management Policies 3809 3810 Table 5-18 PCI Function State Transition Delays 3811 3812 4273 Table 6-1 Error Messages 3813 3814 3817 Page 60 Table 6-1 Error Messages 4275 Table 6-2 General PCI Express Error List 3815 3816 4274 4276 Table 6-2 General PCI Express Error List 4277 Table 6-3 Physical Layer Error List 4278 4279 Table 6-3 Physical Layer Error List /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3817 4279 3818 Table 6-4 Data Link Layer Error List 3819 4280 Table 6-4 Data Link Layer Error List 4281 3820 Table 6-5 Transaction Layer Error List 3821 4282 Table 6-5 Transaction Layer Error List 4283 3822 Table 6-6 Elements of Hot-Plug 4284 Table 6-6 Multi-Function Arbitration Error Model Example 3823 3824 Table 6-7 Attention Indicator States 3825 4285 3826 Table 6-8 Power Indicator States 3827 3828 4286 Table 6-7 Elements of Hot-Plug 4287 Table 6-9 ACS P2P Request Redirect and ACS P2P Egress Control Interactions 3829 3830 Table 6-11 Processing Hint Mapping Table 6-13 PASID TLP Prefix Table 6-14 Emergency Power Reduction Supported Values 4294 Table 6-15 System GUID Authority ID Encoding 4296 4298 4300 4302 4304 Table 6-14 PASID TLP Prefix Table 6-15 Emergency Power Reduction Supported Values Table 6-16 System GUID Authority ID Encoding 4305 Table 6-17 Small Resource Data Type Tag Bit Definitions 3845 4306 Table 6-17 Small Resource Data Type Tag Bit Definitions 4307 Table 6-18 Large Resource Data Type Tag Bit Definitions 3847 4308 Table 6-18 Large Resource Data Type Tag Bit Definitions 4309 Table 6-19 Resource Data Type Flags for a Typical VPD 3849 3850 Table 6-13 ST Modes of Operation 4303 3843 3848 Table 6-12 Processing Hint Mapping 4301 3842 3846 Table 6-11 ECRC Rules for MC_Overlay 4299 3841 3844 Table 6-10 ACS P2P Request Redirect and ACS P2P Egress Control Interactions 4297 3839 3840 4292 4295 3837 3838 Table 6-9 Power Indicator States 4293 Table 6-12 ST Modes of Operation 3835 3836 4290 4291 3833 3834 Table 6-8 Attention Indicator States 4289 Table 6-10 ECRC Rules for MC_Overlay 3831 3832 4288 4310 Table 6-19 Resource Data Type Flags for a Typical VPD 4311 Table 6-20 Example of Add-in Serial Card Number 3851 4312 Table 6-20 Example of Add-in Serial Card Number 4313 3852 Table 6-21 VPD Large and Small Resource Data Tags 4314 Table 6-21 VPD Large and Small Resource Data Tags 3860 Table 6-25 NPEM States 4322 Table 6-25 NPEM States 3861 3862 4323 Table 7-1 Enhanced Configuration Address Mapping 3863 3864 Table 7-2 Register and Register Bit-Field Types Table 7-3 Command Register Page 61 Table 7-2 Register and Register Bit-Field Types 4328 Table 7-3 Command Register 4329 Table 7-4 Status Register 3869 3870 4326 4327 3867 3868 Table 7-1 Enhanced Configuration Address Mapping 4325 3865 3866 4324 4330 Table 7-4 Status Register 4331 Table 7-5 Table 7-5: Class Code Register 4332 Table 7-5 Class Code Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3870 Table 7-5 Table 7-5: Class Code Register 3871 4332 Table 7-5 Class Code Register 4333 3872 Table 7-6 Header Type Register 3873 4334 Table 7-6 Header Type Register 4335 3874 Table 7-7 Table 7-7: BIST Register 3875 4336 Table 7-7 BIST Register 4337 3876 Table 7-8 Table 7-8: Memory Base Address Register Bits 2:1 4338 Table 7-8 Memory Base Address Register Bits 2:1 Encoding Encoding 3877 3878 4339 Table 7-9 I/O Addressing Capability 3879 3880 Table 7-10 Secondary Status Register Table 7-11 Table 7-11: Bridge Control Register Table 7-12 Power Management Capabilities Register Table 7-13 Power Management Control/Status Register Table 7-14 Table 7-14: Data Register Table 7-15 Power Consumption/Dissipation Reporting Table 7-16 PCI Express Capability List Register Table 7-17 PCI Express Capabilities Register Table 7-18 Device Capabilities Register Table 7-19 Device Control Register Table 7-20 Device Status Register Table 7-21 Link Capabilities Register Table 7-22 Link Control Register Table 7-23 Link Status Register Table 7-24 Slot Capabilities Register Table 7-25 Slot Control Register Table 7-26 Slot Status Register Table 7-27 Root Control Register 3919 Page 62 Table 7-18 PCI Express Capabilities Register 4360 Table 7-19 Device Capabilities Register 4362 Table 7-20 Device Control Register 4364 Table 7-21 Device Status Register 4366 Table 7-22 Link Capabilities Register 4368 Table 7-23 Link Control Register 4370 Table 7-24 Link Status Register 4372 Table 7-25 Slot Capabilities Register 4374 Table 7-26 Slot Control Register 4376 Table 7-27 Slot Status Register 4377 Table 7-28 Root Capabilities Register 3917 3918 4358 4375 3915 3916 Table 7-17 PCI Express Capability List Register 4373 3913 3914 4356 4371 3911 3912 Table 7-16 Power Consumption/Dissipation Reporting 4369 3909 3910 4354 4367 3907 3908 Table 7-15 Data Register 4365 3905 3906 4352 4363 3903 3904 Table 7-14 Power Management Control/Status Register 4361 3901 3902 4350 4359 3899 3900 Table 7-13 Power Management Capabilities Register 4357 3897 3898 4348 4355 3895 3896 Table 7-12 Bridge Control Register 4353 3893 3894 4346 4351 3891 3892 Table 7-11 Secondary Status Register 4349 3889 3890 4344 4347 3887 3888 Table 7-10 I/O Addressing Capability 4345 3885 3886 4342 4343 3883 3884 Table 7-9 Expansion ROM Base Address Register 4341 3881 3882 4340 4378 Table 7-28 Root Control Register 4379 Table 7-29 Root Status Register 4380 4381 Table 7-29 Root Capabilities Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3919 4381 3920 Table 7-30 Device Capabilities 2 Register 3921 4382 Table 7-30 Root Status Register 4383 3922 Table 7-31 Device Control 2 Register 3923 4384 Table 7-31 Device Capabilities 2 Register 4385 3924 Table 7-32 Link Capabilities 2 Register 3925 4386 Table 7-32 Device Control 2 Register 4387 3926 Table 7-33 Link Control 2 Register 3927 4388 Table 7-33 Link Capabilities 2 Register 4389 3928 Table 7-34 Link Status 2 Register 3929 4390 Table 7-34 Link Control 2 Register 4391 3930 Table 7-35 PCI Express Extended Capability Header 3931 4392 Table 7-35 Link Status 2 Register 4393 3932 Table 7-36 MSI Capability Header 3933 4394 Table 7-36 Slot Capabilities 2 Register 4395 3934 Table 7-37 Message Control Register for MSI 3935 4396 Table 7-37 PCI Express Extended Capability Header 4397 3936 Table 7-38 Message Address Register for MSI 3937 4398 Table 7-38 MSI Capability Header 4399 3938 Table 7-39 Message Upper Address Register for MSI 3939 4400 Table 7-39 Message Control Register for MSI 4401 3940 Table 7-40 Message Data Register for MSI 3941 4402 Table 7-40 Message Address Register for MSI 4403 3942 Table 7-41 Extended Message Data Register for MSI 3943 4404 Table 7-41 Message Upper Address Register for MSI 4405 3944 Table 7-42 Mask Bits Register for MSI 3945 4406 Table 7-42 Message Data Register for MSI 4407 3946 Table 7-43 Pending Bits Register for MSI 3947 4408 Table 7-43 Extended Message Data Register for MSI 4409 3948 Table 7-44 MSI-X Capability Header 3949 4410 Table 7-44 Mask Bits Register for MSI 4411 3950 Table 7-45 Message Control Register for MSI-X 3951 4412 Table 7-45 Pending Bits Register for MSI 4413 3952 Table 7-46 Table Offset/Table BIR Register for MSI-X 3953 4414 Table 7-46 MSI-X Capability Header 4415 3954 Table 7-47 PBA Offset/PBA BIR Register for MSI-X 3955 4416 Table 7-47 Message Control Register for MSI-X 4417 3956 Table 7-48 Message Address Register for MSI-X Table Entries 3957 4418 Table 7-48 Table Offset/Table BIR Register for MSI-X 4419 3958 Table 7-49 Message Upper Address Register for MSI-X Table 4420 Table 7-49 PBA Offset/PBA BIR Register for MSI-X Entries 3959 3960 4421 Table 7-50 Message Data Register for MSI-X Table Entries 3961 3962 4422 Table 7-50 Message Address Register for MSI-X Table Entries 4423 Table 7-51 Vector Control Register for MSI-X Table Entries 4424 Table 7-51 Message Upper Address Register for MSI-X Table Entries 3963 3964 4425 Table 7-52 Pending Bits Register for MSI-X PBA Entries 3965 3966 3967 Page 63 4426 Table 7-52 Message Data Register for MSI-X Table Entries 4427 Table 7-53 Secondary PCI Express Extended Capability Header 4428 4429 Table 7-53 Vector Control Register for MSI-X Table Entries /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 3967 4429 3968 Table 7-54 Link Control 3 Register 4430 Table 7-54 Pending Bits Register for MSI-X PBA Entries 3969 3970 Table 7-55 Lane Error Status Register 3971 3972 Table 7-56 Lane Equalization Control Register Entry 3973 4431 4432 3974 Table 7-55 Secondary PCI Express Extended Capability Header 4433 4434 3975 Table 7-56 Link Control 3 Register 4435 4436 3976 Table 7-57 Lane Error Status Register 4437 4438 3977 Table 7-58 Lane Equalization Control Register Entry 4439 3978 Table 7-59 Data Link Feature Extended Capability Header 3979 4440 Table 7-59 Data Link Feature Extended Capability Header 4441 3980 Table 7-60 Table 7-58: Data Link Feature Capabilities Register 3981 4442 Table 7-60 Data Link Feature Capabilities Register 4443 3982 Table 7-61 Data Link Feature Status Register 3983 4444 Table 7-61 Data Link Feature Status Register 4445 3984 Table 7-62 Physical Layer 16.0 GT/s Extended Capability Header 3985 4446 Table 7-62 Physical Layer 16.0 GT/s Extended Capability Header 4447 3986 Table 7-63 16.0 GT/s Capabilities Register 3987 4448 Table 7-63 16.0 GT/s Capabilities Register 4449 3988 Table 7-64 16.0 GT/s Control Register 3989 4450 Table 7-64 16.0 GT/s Control Register 4451 3990 Table 7-65 16.0 GT/s Status Register 3991 4452 Table 7-65 16.0 GT/s Status Register 4453 3992 Table 7-66 16.0 GT/s Local Data Parity Mismatch Status 4454 Register Table 7-66 16.0 GT/s Local Data Parity Mismatch Status Register 3993 4455 3994 Table 7-67 16.0 GT/s First Retimer Data Parity Mismatch Status 4456 Register Table 7-67 16.0 GT/s First Retimer Data Parity Mismatch Status Register 3995 4457 3996 Table 7-68 16.0 GT/s Second Retimer Data Parity Mismatch Status 4458 Register Table 7-68 16.0 GT/s Second Retimer Data Parity Mismatch Status Register 3997 4459 3998 Table 7-69 16.0 GT/s Lane Equalization Control Register Entry 3999 4460 Table 7-69 16.0 GT/s Lane Equalization Control Register Entry 4461 4462 4000 Table 7-70 Physical Layer 32.0 GT/s Extended Capability Header 4463 4464 4001 Table 7-71 32.0 GT/s Capabilities Register 4465 4002 Table 7-71 Lane Margining at the Receiver Extended Capability 4466 Table 7-72 32.0 GT/s Control Register Header 4003 4004 4467 Table 7-72 Margining Port Capabilities Register 4005 4006 4007 4468 Table 7-73 Margining Port Status Register 4470 Table 7-74 Received Modified TS Data 1 Register 4471 4472 Page 64 Table 7-73 32.0 GT/s Status Register 4469 Table 7-75 Received Modified TS Data 2 Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4472 4008 Table 7-75 Received Modified TS Data 2 Register 4473 4474 4009 4010 Table 7-75 Lane N: Margining Lane Status Register Entry 4011 4012 4476 Table 7-77 Transmitted Modified TS Data 2 Register 4477 Table 7-76 ACS Extended Capability Header 4013 4014 Table 7-76 Transmitted Modified TS Data 1 Register 4475 4478 Table 7-78 32.0 GT/s Lane Equalization Control Register Entry 4479 Table 7-77 ACS Capability Register 4480 Table 7-79 Lane Margining at the Receiver Extended Capability Header 4015 4016 4481 Table 7-78 ACS Control Register 4017 4018 Table 7-79 Egress Control Vector Register Table 7-80 Power Budgeting Extended Capability Header Table 7-81 Power Budgeting Data Register Table 7-82 Power Budgeting Capability Register Table 7-83 LTR Extended Capability Header Table 7-84 Max Snoop Latency Register Table 7-85 Max No-Snoop Latency Register Table 7-86 L1 PM Substates Extended Capability Header Table 7-87 L1 PM Substates Capabilities Register Table 7-88 L1 PM Substates Control 1 Register Table 7-89 L1 PM Substates Control 2 Register Table 7-90 Advanced Error Reporting Extended Capability Header Table 7-91 Uncorrectable Error Status Register Table 7-92 Uncorrectable Error Mask Register Table 7-93 Uncorrectable Error Severity Register Table 7-94 Correctable Error Status Register Table 7-95 Correctable Error Mask Register 4055 Page 65 4500 Table 7-89 Power Budgeting Data Register 4502 Table 7-90 Power Budgeting Capability Register 4504 Table 7-91 LTR Extended Capability Header 4506 Table 7-92 Max Snoop Latency Register 4508 Table 7-93 Max No-Snoop Latency Register 4510 Table 7-94 L1 PM Substates Extended Capability Header 4512 Table 7-95 L1 PM Substates Capabilities Register 4514 Table 7-96 L1 PM Substates Control 1 Register 4516 Table 7-97 L1 PM Substates Control 2 Register 4517 Table 7-96 Advanced Error Capabilities and Control Register 4053 4054 Table 7-88 Power Budgeting Extended Capability Header 4515 4051 4052 4498 4513 4049 4050 Table 7-87 Egress Control Vector Register 4511 4047 4048 4496 4509 4045 4046 Table 7-86 ACS Control Register 4507 4043 4044 4494 4505 4041 4042 Table 7-85 ACS Capability Register 4503 4039 4040 4492 4501 4037 4038 Table 7-84 ACS Extended Capability Header 4499 4035 4036 4490 4497 4033 4034 Table 7-83 Lane N: Margining Lane Status Register Entry 4495 4031 4032 4488 4493 4029 4030 Table 7-82 Lane N: Margining Control Register Entry 4491 4027 4028 4486 4489 4025 4026 Table 7-81 Margining Port Status Register 4487 4023 4024 4484 4485 4021 4022 Table 7-80 Margining Port Capabilities Register 4483 4019 4020 4482 4518 Table 7-98 L1 PM Substates Status Register 4519 Table 7-97 Header Log Register 4520 4521 Table 7-99 Advanced Error Reporting Extended Capability Header /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4055 4521 4056 Table 7-98 Root Error Command Register 4057 4522 Table 7-100 Uncorrectable Error Status Register 4523 4058 Table 7-99 Root Error Status Register 4059 4524 Table 7-101 Uncorrectable Error Mask Register 4525 4060 Table 7-100 Error Source Identification Register 4061 4526 Table 7-102 Uncorrectable Error Severity Register 4527 4062 Table 7-101 TLP Prefix Log Register 4063 4528 Table 7-103 Correctable Error Status Register 4529 4064 Table 7-102 Table 7-98: First DW of Enhanced Allocation 4530 Table 7-104 Correctable Error Mask Register Capability 4065 4066 4531 Table 7-103 Table 7-99: First DW of Each Entry for Enhanced Allocation Capability 4067 4532 Table 7-105 Advanced Error Capabilities and Control Register 4533 4534 4068 Table 7-106 Header Log Register 4535 4536 4069 4070 Table 7-107 Root Error Command Register 4537 Table 7-105 Enhanced Allocation Entry Field Value Definitions for both the Primary Properties and Secondary Properties Fields 4071 4072 Table 7-107 Resizable BAR Capability Register Table 7-108 Resizable BAR Control Register 4542 Table 7-110 TLP Prefix Log Register 4544 Table 7-111 First DW of Enhanced Allocation Capability 4545 Table 7-109 ARI Capability Header 4079 4080 Table 7-109 Error Source Identification Register 4543 4077 4078 4540 4541 4075 4076 Table 7-108 Root Error Status Register 4539 Table 7-106 Resizable BAR Extended Capability Header 4073 4074 4538 4546 Table 7-112 Second DW of Enhanced Allocation Capability 4547 Table 7-110 ARI Capability Register 4548 Table 7-113 First DW of Each Entry for Enhanced Allocation Capability 4081 4082 4549 Table 7-111 ARI Control Register 4083 4084 Table 7-113 PASID Capability Register Table 7-114 Table 7-109: PASID Control Register Table 7-115 FRS Queueing Extended Capability Header Table 7-116 FRS Queueing Capability Register Table 7-117 FRS Queueing Status Register Page 66 Table 7-117 Resizable BAR Control Register 4558 Table 7-118 ARI Extended Capability Header 4560 Table 7-119 ARI Capability Register 4562 Table 7-120 ARI Control Register 4563 Table 7-118 FRS Queueing Control Register 4097 4098 4556 4561 4095 4096 Table 7-116 Resizable BAR Capability Register 4559 4093 4094 4554 4557 4091 4092 Table 7-115 Resizable BAR Extended Capability Header 4555 4089 4090 4552 4553 4087 4088 Table 7-114 Enhanced Allocation Entry Field Value Definitions for both the Primary Properties and Secondary Properties Fields 4551 Table 7-112 PASID Extended Capability Header 4085 4086 4550 4564 Table 7-121 PASID Extended Capability Header 4565 Table 7-119 FRS Message Queue Register 4566 Table 7-122 PASID Capability Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4098 Table 7-119 FRS Message Queue Register 4099 4100 Table 7-120 FPB Capability Header 4568 Table 7-121 FPB Capabilities Register 4570 4572 4574 4576 4578 4580 4582 Table 7-125 FPB RID Vector Control 1 Register 4584 4586 Table 7-132 FPB RID Vector Control 2 Register 4587 4588 4113 Table 7-133 FPB MEM Low Vector Control Register 4589 4590 4114 Table 7-134 FPB MEM High Vector Control 1 Register 4591 4592 4115 Table 7-135 FPB MEM High Vector Control 2 Register 4593 Table 7-128 FPB RID Vector Control 2 Register 4117 4594 Table 7-136 FPB Vector Access Control Register 4595 Table 7-129 FPB MEM Low Vector Control Register 4119 4596 Table 7-137 FPB Vector Access Data Register 4597 4598 4120 Table 7-138 Virtual Channel Extended Capability Header 4599 4600 4121 Table 7-139 Port VC Capability Register 1 4601 4602 4122 Table 7-140 Port VC Capability Register 2 4603 4604 4123 Table 7-141 Port VC Control Register 4605 Table 7-132 FPB MEM High Vector Control 1 Register 4606 Table 7-142 Port VC Status Register 4607 4608 Table 7-143 VC Resource Capability Register 4609 4610 Table 7-144 VC Resource Control Register 4611 4612 Table 7-145 VC Resource Status Register 4613 4614 Page 67 Table 7-131 FPB RID Vector Control 1 Register 4585 4112 4129 Table 7-130 FPB Capabilities Register 4583 4111 4128 Table 7-129 FPB Capability Header 4581 4109 4127 Table 7-128 FRS Message Queue Register 4579 4108 4126 Table 7-127 FRS Queueing Control Register 4577 4107 4125 Table 7-126 FRS Queueing Status Register 4575 4106 4124 Table 7-125 FRS Queueing Capability Register 4573 4105 4118 Table 7-124 FRS Queueing Extended Capability Header 4571 4104 4116 Table 7-123 PASID Control Register 4569 4103 4110 Table 7-122 PASID Capability Register 4567 4101 4102 4566 4615 Table 7-146 Definition of the 4-bit Entries in the VC Arbitration Table /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4129 4615 4130 Table 7-135 FPB MEM High Vector Control 2 Register 4616 Table 7-147 Length of the VC Arbitration Table 4617 4618 4131 Table 7-148 Length of Port Arbitration Table 4619 4620 4132 Table 7-149 MFVC Extended Capability Header 4621 4622 4133 Table 7-150 MFVC Port VC Capability Register 1 4623 4134 Table 7-137 FPB Vector Access Control Register 4135 4624 Table 7-151 MFVC Port VC Capability Register 2 4625 4626 4136 Table 7-152 MFVC Port VC Control Register 4627 4628 4137 4138 Table 7-139 FPB Vector Access Data Register 4139 4630 Table 7-154 MFVC VC Resource Capability Register 4631 4140 Table 7-140 Virtual Channel Extended Capability Header 4141 4632 Table 7-155 MFVC VC Resource Control Register 4633 4142 Table 7-141 Table 7-125: Port VC Capability Register 1 4143 4634 Table 7-156 MFVC VC Resource Status Register 4635 4144 Table 7-142 Port VC Capability Register 2 4145 4636 Table 7-157 Length of Function Arbitration Table 4637 4146 Table 7-143 Port VC Control Register 4147 4638 Table 7-158 Device Serial Number Extended Capability Header 4639 4148 Table 7-144 Table 7-128: Port VC Status Register 4149 4640 Table 7-159 Serial Number Register 4641 4150 Table 7-145 VC Resource Capability Register 4151 4642 Table 7-160 Vendor-Specific Capability 4643 4152 Table 7-146 VC Resource Control Register 4153 4644 Table 7-161 Vendor-Specific Extended Capability Header 4645 4154 Table 7-147 VC Resource Status Register 4155 4156 Table 7-153 MFVC Port VC Status Register 4629 4646 Table 7-162 Vendor-Specific Header 4647 Table 7-148 Definition of the 4-bit Entries in the VC Arbitration Table 4157 4158 Table 7-150 Length of Port Arbitration Table Table 7-151 MFVC Extended Capability Header Table 7-152 MFVC Port VC Capability Register 1 Table 7-153 MFVC Port VC Capability Register 2 4654 Table 7-166 RCRB Header Extended Capability Header 4656 Table 7-167 RCRB Vendor ID and Device ID register 4658 Table 7-168 RCRB Capabilities register 4659 Table 7-154 MFVC Port VC Control Register 4169 4170 Table 7-165 Designated Vendor-Specific Header 2 4657 4167 4168 4652 4655 4165 4166 Table 7-164 Designated Vendor-Specific Header 1 4653 4163 4164 4650 4651 4161 4162 Table 7-163 Designated Vendor-Specific Extended Capability Header 4649 Table 7-149 Length of the VC Arbitration Table 4159 4160 4648 4660 Table 7-169 RCRB Control register 4661 Table 7-155 MFVC Port VC Status Register 4662 Table 7-170 Root Complex Link Declaration Extended Capability Header 4171 Page 68 4663 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4171 4663 4172 Table 7-156 MFVC VC Resource Capability Register 4173 4664 Table 7-171 Element Self Description Register 4665 4174 Table 7-157 MFVC VC Resource Control Register 4175 4666 Table 7-172 Link Description Register 4667 4176 Table 7-158 MFVC VC Resource Status Register 4177 4668 Table 7-173 Link Address for Link Type 1 4669 4178 Table 7-159 Length of Function Arbitration Table 4179 4670 Table 7-174 Root Complex Internal Link Control Extended Capability Header 4671 4180 Table 7-160 Device Serial Number Extended Capability Header 4181 4672 Table 7-175 Root Complex Link Capabilities Register 4673 4182 Table 7-161 Serial Number Register 4183 4674 Table 7-176 Root Complex Link Control Register 4675 4184 Table 7-162 Vendor-Specific Capability 4185 4676 Table 7-177 Root Complex Link Status Register 4677 4186 Table 7-163 Vendor-Specific Extended Capability Header 4187 4678 Table 7-178 Root Complex Event Collector Endpoint Association Extended Capability Header 4679 4188 Table 7-164 Vendor-Specific Header 4189 4680 Table 7-179 RCEC Associated Bus Numbers Register 4681 4190 Table 7-165 Designated Vendor-Specific Extended Capability 4682 Table 7-180 Multicast Extended Capability Header Header 4191 4683 4192 Table 7-166 Designated Vendor-Specific Header 1 4193 4684 Table 7-181 Multicast Capability Register 4685 4194 Table 7-167 Designated Vendor-Specific Header 2 4195 4686 Table 7-182 Multicast Control Register 4687 4196 Table 7-168 Table 7-152: RCRB Header Extended Capability 4688 Table 7-183 MC_Base_Address Register Header 4197 4689 4198 Table 7-169 RCRB Vendor ID and Device ID register 4199 4690 Table 7-184 MC_Receive Register 4691 4200 Table 7-170 RCRB Capabilities register 4201 4692 Table 7-185 MC_Block_All Register 4693 4202 Table 7-171 RCRB Control register 4203 4694 Table 7-186 MC_Block_Untranslated Register 4695 4204 Table 7-172 Root Complex Link Declaration Extended Capability 4696 Table 7-187 MC_Overlay_BAR Register Header 4205 4697 4206 Table 7-173 Element Self Description Register 4207 Table 7-188 DPA Extended Capability Header 4699 4208 Table 7-174 Link Description Register 4209 4700 Table 7-189 DPA Capability Register 4701 4210 Table 7-175 Link Address for Link Type 1 4211 4212 4698 4702 Table 7-190 DPA Latency Indicator Register 4703 Table 7-176 Root Complex Internal Link Control Extended Capability Header 4213 4704 Table 7-191 DPA Status Register 4705 4214 Table 7-177 Table 7-161: Root Complex Link Capabilities Register Page 69 4706 Table 7-192 DPA Control Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4214 Table 7-177 Table 7-161: Root Complex Link Capabilities Register 4215 4707 4216 Table 7-178 Root Complex Link Control Register 4217 Table 7-179 Root Complex Link Status Register 4219 4710 Table 7-194 TPH Requester Extended Capability Header 4711 Table 7-180 Table 7-164: Root Complex Event Collector Endpoint Association Extended Capability Header 4221 4712 Table 7-195 TPH Requester Capability Register 4713 4222 Table 7-181 Multicast Extended Capability Header 4223 4714 Table 7-196 TPH Requester Control Register 4715 4224 Table 7-182 Multicast Capability Register 4225 4716 Table 7-197 TPH ST Table Entry 4717 4226 Table 7-183 Multicast Control Register 4227 4718 Table 7-198 LNR Extended Capability Header 4719 4228 Table 7-184 MC_Base_Address Register 4229 4720 Table 7-199 LNR Capability Register 4721 4230 Table 7-185 MC_Receive Register 4231 4722 Table 7-200 LNR Control Register 4723 4232 Table 7-186 MC_Block_All Register 4233 4724 Table 7-201 DPC Extended Capability Header 4725 4234 Table 7-187 MC_Block_Untranslated Register 4235 4726 Table 7-202 DPC Capability Register 4727 4236 Table 7-188 MC_Overlay_BAR Register 4237 4728 Table 7-203 DPC Control Register 4729 4238 Table 7-189 DPA Extended Capability Header 4239 4730 Table 7-204 DPC Status Register 4731 4240 Table 7-190 DPA Capability Register 4241 4732 Table 7-205 DPC Error Source ID Register 4733 4242 Table 7-191 DPA Latency Indicator Register 4243 4734 Table 7-206 RP PIO Status Register 4735 4244 Table 7-192 DPA Status Register 4245 4736 Table 7-207 RP PIO Mask Register 4737 4246 Table 7-193 DPA Control Register 4247 4248 Table 7-193 Substate Power Allocation Register (0 to Substate_Max) 4709 4218 4220 4708 4738 Table 7-208 RP PIO Severity Register 4739 Table 7-194 Substate Power Allocation Register (0 to Substate_Max) 4249 4250 Table 7-196 TPH Requester Capability Register Table 7-197 TPH Requester Control Register Table 7-198 TPH ST Table 4261 Page 70 Table 7-211 RP PIO Header Log Register 4746 Table 7-212 RP PIO ImpSpec Log Register 4748 Table 7-213 RP PIO TLP Prefix Log Register 4749 Table 7-199 LNR Extended Capability Header 4259 4260 4744 4747 4257 4258 Table 7-210 RP PIO Exception Register 4745 4255 4256 4742 4743 4253 4254 Table 7-209 RP PIO SysError Register 4741 Table 7-195 TPH Requester Extended Capability Header 4251 4252 4740 4750 Table 7-214 PTM Extended Capability Header 4751 Table 7-200 LNR Capability Register 4752 4753 Table 7-215 PTM Capability Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4261 4753 4262 Table 7-201 LNR Control Register 4263 4754 Table 7-216 PTM Control Register 4755 4264 Table 7-202 DPC Extended Capability 4756 Table 7-217 Readiness Time Reporting Extended Capability Header 4265 4757 4266 Table 7-203 DPC Extended Capability Header 4267 Table 7-218 Readiness Time Reporting 1 Register 4759 4268 Table 7-204 DPC Capability Register 4269 4760 Table 7-219 Readiness Time Reporting 2 Register 4761 4270 Table 7-205 DPC Control Register 4271 4762 Table 7-220 Hierarchy ID Extended Capability Header 4763 4272 Table 7-206 DPC Status Register 4273 4764 Table 7-221 Hierarchy ID Status Register 4765 4274 Table 7-207 DPC Error Source ID Register 4275 4766 Table 7-222 Hierarchy ID Data Register 4767 4276 Table 7-208 RP PIO Status Register 4277 4768 Table 7-223 Hierarchy ID GUID 1 Register 4769 4278 Table 7-209 RP PIO Mask Register 4279 4770 Table 7-224 Hierarchy ID GUID 2 Register 4771 4280 Table 7-210 RP PIO Severity Register 4281 4772 Table 7-225 Hierarchy ID GUID 3 Register 4773 4282 Table 7-211 RP PIO SysError Register 4283 4774 Table 7-226 Hierarchy ID GUID 4 Register 4775 4284 Table 7-212 RP PIO Exception Register 4285 4776 Table 7-227 Hierarchy ID GUID 5 Register 4777 4286 Table 7-213 RP PIO Header Log Register 4287 4288 4758 4778 Table 7-228 VPD Address Register 4779 Table 7-214 RP PIO ImpSpec Log Register Table 7-214 RP PIO ImpSpec Log Register 4289 4780 Table 7-229 VPD Data Register 4781 4290 Table 7-215 RP PIO TLP Prefix Log Register 4291 4782 Table 7-230 NPEM Extended Capability Header 4783 4292 Table 7-216 PTM Extended Capability Header 4293 4784 Table 7-231 NPEM Capability Register 4785 4294 Table 7-217 Table 7-200: PTM Capability Register 4295 4786 Table 7-232 NPEM Control Register 4787 4296 Table 7-218 Table 7-201: PTM Control Register 4297 4788 Table 7-233 NPEM Status Register 4789 4298 Table 7-219 Readiness Time Reporting Extended Capability 4790 Table 7-234 Alternate Protocol Extended Capability Header Header 4299 4300 4791 Table 7-220 Readiness Time Reporting 1 Register 4301 4302 Table 7-221 Readiness Time Reporting 2 Register Table 7-222 Hierarchy ID Extended Capability Header 4309 Page 71 Table 7-236 Alternate Protocol Control Register 4796 Table 7-237 Alternate Protocol Data 1 Register 4797 Table 7-223 Hierarchy ID Status Register 4307 4308 4794 4795 4305 4306 Table 7-235 Alternate Protocol Capabilities Register 4793 4303 4304 4792 4798 Table 7-238 Alternate Protocol Data 2 Register 4799 Table 7-224 Hierarchy ID Data Register 4800 4801 Table 7-239 Alternate Protocol Selective Enable Mask Register /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4309 4801 4310 Table 7-225 Hierarchy ID GUID 1 Register 4311 4802 Table 7-240 Advanced Features Capability Header 4803 4312 Table 7-226 Hierarchy ID GUID 2 Register 4313 4804 Table 7-241 AF Capabilities Register 4805 4314 Table 7-227 Hierarchy ID GUID 3 Register 4806 Table 7-242 Conventional PCI Advanced Features Control Register 4315 4807 4316 Table 7-228 Hierarchy ID GUID 4 Register 4317 4808 4318 Table 7-229 Hierarchy ID GUID 5 Register 4319 4810 Table 7-244 SFI Extended Capability Header 4811 4320 Table 7-230 VPD Address Register 4321 4812 Table 7-245 SFI Capability Register 4813 4322 Table 7-231 VPD Data Register 4323 4814 Table 7-246 SFI Control Register 4815 4324 Table 7-232 NPEM Extended Capability Header 4325 4816 Table 7-247 SFI Status Register 4817 4326 Table 7-233 NPEM Capability Register 4327 4818 Table 7-248 SFI CAM Address Register 4819 4328 Table 7-234 NPEM Control Register 4329 4820 Table 7-249 SFI CAM Data Register 4821 4330 Table 7-235 NPEM Status Register 4331 4822 Table 7-250 Subsystem ID and Sybsystem Vendor ID Capability 4823 4332 Table 8-1 Tx Preset Ratios and Corresponding Coefficient 4824 Values Table 8-1 Tx Preset Ratios and Corresponding Coefficient Values 4333 4825 4334 Table 8-2 Preset Measurement Cross Reference Table 4335 4336 Table 7-243 AF Status Register 4809 4826 Table 8-2 Preset Measurement Cross Reference Table 4827 Table 8-3 Cases that the Reference Packages and ps21TX Parameter are Normative 4337 4828 Table 8-3 Cases that the Reference Packages and ps21TX Parameter are Normative 4829 4338 Table 8-4 Recommended De-embedding Cutoff Frequency 4339 4830 Table 8-4 Recommended De-embedding Cutoff Frequency 4831 4340 Table 8-5 Tx Measurement and Post Processing For Different 4832 Refclks 4366 Table 8-5 Tx Measurement and Post Processing For Different Refclks Table 8-18 Jitter Limits for CC Architecture 4367 4858 Table 8-18 Jitter Limits for CC Architecture 4859 4368 Table 8-19 Form Factor Clocking Architecture Requirements 4369 4860 Table 8-19 Form Factor Clocking Architecture Requirements 4861 4370 Table 8-20 Form Factor Common Clock Architecture Details 4371 4862 Table 8-20 Form Factor Common Clock Architecture Details 4863 4372 Table 8-21 Form Factor Clocking Architecture Requirements 4864 Example Table 8-21 Form Factor Clocking Architecture Requirements Example 4373 4865 4374 Table 8-22 Form Factor Common Clock Architecture Details 4866 Example 4375 4867 4868 4869 Page 72 Table 8-22 Form Factor Common Clock Architecture Details Example Table 9-1 VF Routing ID Algorithm /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4869 4870 Table 9-2 SR-IOV VF Migration State Table 4871 4872 Table 9-3 SR-IOV Extended Capability Header 4873 4874 Table 9-4 SR-IOV Capabilities Register 4875 4876 Table 9-5 SR-IOV Control Register 4877 4878 Table 9-6 SR-IOV Status 4879 4880 Table 9-7 BAR Offsets 4881 4882 Table 9-8 VF Migration State Array Offset 4883 4884 Table 9-9 VF Migration State Entry 4885 4886 Table 9-10 VF Migration State Descriptions 4887 4888 Table 9-11 SR-PCIM Initiated VF Migration State Transitions 4889 4890 Table 9-12 MR-PCIM Initiated VF Migration State Transitions 4891 4892 Table 9-13 Command Register Changes 4893 4894 Table 9-14 Status Register Changes 4895 4896 Table 9-15 Device Capabilities Register Changes 4897 4898 Table 9-16 Device Control Register Changes 4899 4900 Table 9-17 Device Status Register Changes 4901 4902 Table 9-18 Link Control Register Changes 4903 4904 Table 9-19 Device Capabilities 2 Register Changes 4905 4906 Table 9-20 Device Control 2 Register Changes 4907 4908 Table 9-21 Link Status 2 Register Changes 4909 4910 Table 9-22 SR-IOV Usage of PCI Standard Capabilities 4911 4912 Table 9-23 SR-IOV Usage of PCI Express Extended Capabilities 4913 4914 Table 9-24 VF Resizable BAR Extended Capability Header 4915 4916 Table 9-25 VF Resizable BAR Control Register 4917 4918 Table 9-26 ACS Capability Register Changes 4919 4920 Page 73 Table 9-27 ARI Capability Register Changes /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4920 Table 9-27 ARI Capability Register Changes 4921 4922 Table 9-28 ATS Capability Register 4923 4924 Table 9-29 ATS Control Register Changes 4925 4926 Table 9-30 Multicast Capability Register Changes 4927 4928 Table 9-31 Multicast Control Register Changes 4929 4930 Table 9-32 Multicast Base Address Register Changes 4931 4932 Table 9-33 Uncorrectable Error Status Register Changes 4933 4934 Table 9-34 Uncorrectable Error Mask Register Changes 4935 4936 Table 9-35 Uncorrectable Error Severity Register Changes 4937 4938 Table 9-36 Correctable Error Status Register Changes 4939 4940 Table 9-37 Correctable Error Mask Register Changes 4941 4942 Table 9-38 Advanced Error Capabilities and Control Register Changes 4943 4944 Table 9-39 Header Log Register changes 4945 4946 Table 9-40 MSI Capability: Message Control 4947 4948 Table 9-41 SR-IOV Power Management Control/Status (PMCSR) 4949 4950 Table 9-42 SR-IOV Power Management Data Register 4951 4376 Table 10-1 Address Type (AT) Field Encodings 4377 4378 Table 10-2 Translation Completion with No Data Status Codes Table 10-3 Translation Completion Data Fields Table 10-4 Examples of Translation Size Using S Field Table 10-5 Page Request Message Data Fields Table 10-6 PRG Response Message Data Fields Table 10-7 Response Codes 4393 Page 74 Table 10-4 Examples of Translation Size Using S Field 4960 Table 10-5 Page Request Message Data Fields 4962 Table 10-6 PRG Response Message Data Fields 4964 Table 10-7 Response Codes 4965 Table 10-8 ATS Extended Capability Header 4391 4392 4958 4963 4389 4390 Table 10-3 Translation Completion Data Fields 4961 4387 4388 4956 4959 4385 4386 Table 10-2 Translation Completion with No Data Status Codes 4957 4383 4384 4954 4955 4381 4382 Table 10-1 Address Type (AT) Field Encodings 4953 4379 4380 4952 4966 Table 10-8 ATS Extended Capability Header 4967 Table 10-9 ATS Capability Register 4968 4969 Table 10-9 ATS Capability Register (Offset 04h) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4393 4969 4394 Table 10-10 ATS Control Register 4395 4970 Table 10-10 ATS Control Register 4971 4396 Table 10-11 Page Request Extended Capability Header 4397 4972 Table 10-11 Page Request Extended Capability Header 4973 4398 Table 10-12 Page Request Control Register 4399 4974 Table 10-12 Page Request Control Register 4975 4400 Table 10-13 Page Request Status Register 4401 4976 Table 10-13 Page Request Status Register 4977 4978 Table A-1 Isochronous Bandwidth Ranges and Granularities 4979 4402 Table B-1 8b/10b Data Symbol Codes 4403 4980 Table B-1 8b/10b Data Symbol Codes 4981 4404 Table B-2 8b/10b Special Character Symbol Codes 4405 4982 Table B-2 8b/10b Special Character Symbol Codes 4983 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 Table F-1 Message Code Usage 4417 Table F-2 PCI-SIG-Defined VDM Subtype Usage 4419 Table G-1 PCI Express Attribute Impact on Protocol Multiplexing Table G-2 PMUX Attribute Impact on PCI Express 4423 Table G-3 PMUX Packet Layout (8b/10b Encoding) 4425 Table G-1 PCI Express Attribute Impact on Protocol Multiplexing 4990 Table G-2 PMUX Attribute Impact on PCI Express 4992 Table G-3 PMUX Packet Layout (8b/10b Encoding) 4993 4436 Table G-9 PMUX Status Register 4437 5004 Table G-9 PMUX Status Register 5005 4438 Table G-10 PMUX Protocol Array Entry 4439 5006 Table G-10 PMUX Protocol Array Entry 5007 Table H-1 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s Mode Operation by Link Width and Max Payload (Symbol Times) 4441 5008 Table H-1 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s Mode Operation by Link Width and Max Payload (Symbol Times) 5009 Table H-2 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s Mode Operation by Link Width and Max Payload (Symbol Times) 4443 5010 Table H-2 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s Mode Operation by Link Width and Max Payload (Symbol Times) 5011 Table H-3 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s Operation by Link Width and Max Payload (Symbol Times) 4445 4446 4988 4991 4424 4444 Table F-2 PCI-SIG-Defined VDM Subtype Usage 4989 4422 4442 4986 4987 4421 4440 Table F-1 Message Code Usage 4985 4418 4420 4984 5012 Table H-3 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s Operation by Link Width and Max Payload (Symbol Times) 5013 Table H-4 Table H-4: Maximum Ack Latency Limit and AckFactor for 2.5 GT/s (Symbol Times) Page 75 5014 Table H-4 Maximum Ack Latency Limit and AckFactor for 2.5 GT/s (Symbol Times) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4446 Table H-4 Table H-4: Maximum Ack Latency Limit and AckFactor for 2.5 GT/s (Symbol Times) 4447 4448 Table H-4 Maximum Ack Latency Limit and AckFactor for 2.5 GT/s (Symbol Times) 5015 Table H-5 Table H-5: Maximum Ack Transmission Latency Limit and AckFactor for 5.0 GT/s (Symbol Times) 4449 4450 5014 5016 Table H-5 Maximum Ack Transmission Latency Limit and AckFactor for 5.0 GT/s (Symbol Times) 5017 Table H-6 Table H-6: Maximum Ack Transmission Latency Limit and AckFactor for 8.0 GT/s (Symbol Times) 5018 4451 5019 4452 5020 4453 5021 4454 5022 5023 4455 4456 4457 Table H-6 Maximum Ack Transmission Latency Limit and AckFactor for 8.0 GT/s (Symbol Times) Status of This Document 5024 Placeholder 5025 5026 This is the published version of the PCI Express Base 5.0 Specification. 5027 5028 5029 5030 The NCB-PCI_Express_Base_5.0r1.0.pdf is normative (i.e., the official specification). It contains no changebars. The CB-PCI_Express_Base_5.0r1.0.pdf is informative. It contains changebars relative to the PCI Express Base 4.0 Specification. The CB9-PCI_Express_Base_5.0r1.0.pdf is informative. It contains changebars relative to the PCI Express Base 5.0 Specification Version 0.9. 5031 5032 5033 A new document processing system is being used for this document. The PCI Express Base 4.0 Specification was converted to the new format to serve as a baseline for further work. 5034 5035 5036 5037 5038 Note High Performance Systems may run out of tags 5039 5040 5041 5042 At 32.0 GT/s, systems with high end-to-end latency, even with 10-bit tags, a single Function may not be able to have enough outstanding requests to obtain full performance. 5043 5044 5045 5046 5047 5048 5049 Page 76 Changes to support more outstanding requests need to interoperate with legacy components, regardless of Link Speed of that component. An ECN against the PCI Express Base 4.0 Specification is being considered to define optional behavior to address this issue. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5049 5050 5051 5052 Note Background on the new Document Process 5053 5054 5055 5056 The new PCISIG document system is a variant of the w3c Respec tool (see https://github.com/w3c/respec/wiki). Respec is a widely used tool written to support the World Wide Web specifications. The PCISIG variant is https://github.com/sglaser/respec. Both Respec and the PCISIG variant are open source (MIT License) Javascript libraries. They operate in the author's browser and provide a rapid edit / review cycle without requiring any special tools be installed. 5057 5058 5059 Respec is built on top of HTML5, the document format for the World Wide Web http://www.w3.org/TR/html5/. HTML is a text-based document format that allows us to deploy tools commonly used for software development (git, continuous integration, build scripts, etc.) to better manage and control the spec development process. 5060 5061 5062 4458 5063 4459 5064 4460 Status of This Document 4461 5065 4462 4463 4464 PCISIG enhancements to Respec support document formatting closer to existing PCISIG practice as well as automatic creation of register figures (eliminating about half of the manually drawn figures). 5066 This specification is intended to become a PCISIG Standard. This particular document is a . Status of this Document Placeholder. 4465 5067 4466 5068 4467 Revision History 5069 4468 5070 4469 5071 4470 Revision History 5072 4471 Revision 4472 5073 Revision 5074 4473 Revision History 5075 4474 5076 4810 5412 4811 5413 4812 5414 4813 Revision History 5415 4814 - - - - - - - Changes to the October 13 2016 4.0 r0.7 5416 Draft PDF- - - 4815 Page 77 - - - - - - - Changes to the October 13 2016 4.0 r0.7 Draft PDF- - - - 5417 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4815 5417 4816 5418 4817 EWG: 4818 5421 Updates to Chapter 9 Single Root I/O Virtualization and Sharing - Electrical Sub-block ( and Figure 9-9 caption) 4821 5422 5424 4823 10/21/16 5425 4824 5426 4825 5427 4826 5428 4827 - - - - - - - Changes to the November 3 2016 4.0 r0.7 5430 Draft PDF- - - - - - - - - - - Changes to the November 3 2016 4.0 r0.7 Draft PDF- - - - 4829 5431 4830 5432 4920 5522 -Updated Chapter 4 Physical Layer Logical Block : Physical Layer Logical Block per PCI_Express_Base_4 0_r0 9_Chapter4_Final_Draft.docx 4922 5523 -Updated Chapter 4 Physical Layer Logical Block : Physical Layer Logical Block per PCI_Express_Base_4 0_r0 9_Chapter4_Final_Draft.docx 5524 4923 5525 4924 -Updated Figures in Chapter 10 ATS Specification : ATS 5526 Specification -Updated Figures in Chapter 10 ATS Specification : ATS Specification 4925 5527 4926 5528 -Added Appendix H Flow Control Update Latency and ACK Update Latency Calculations : Flow Control Update Latency and ACK Update Latency Calculations 4928 5529 -Added Appendix H Flow Control Update Latency and ACK Update Latency Calculations : Flow Control Update Latency and ACK Update Latency Calculations 5530 4929 4930 10/21/16 5429 4828 4927 Updates to Chapter 9 Single Root I/O Virtualization and Sharing - Electrical Sub-block (Section 9.3.3.9 First VF Offset (Offset 14h) and Figure 9-9 caption) 5423 4822 4921 EWG: 5420 4819 4820 5419 5531 -Following items that were marked deleted in the Change Bar version of the April 28th snapshot have been “accepted” to no longer show up: pp 1070: Lane Equalization Control 2 Register (Offset TBD) Comment: Deleted per: PCI_Express_Base_4 0r0 7_PhyLogical_Ch7_Delta_28_Apr_2016.docx pp 1074: Physical Layer 16.0 GT/s Margining Extended Capability section Comment: Deleted per: PCI_Express_Base_4 0r0 7_Phy-Logical_Ch7_Delta_28_Apr_2016.docx Comment: Replaced by Section, “Lane Margining at the Receiver Extended Capability” per Fix3a #83 lane-margining-capability-snapshot-2016-06-16.pdf 4931 5532 -Following items that were marked deleted in the Change Bar version of the April 28th snapshot have been “accepted” to no longer show up: pp 1070: Lane Equalization Control 2 Register (Offset TBD) Comment: Deleted per: PCI_Express_Base_4 0r0 7_PhyLogical_Ch7_Delta_28_Apr_2016.docx pp 1074: Physical Layer 16.0 GT/s Margining Extended Capability section Comment: Deleted per: PCI_Express_Base_4 0r0 7_Phy-Logical_Ch7_Delta_28_Apr_2016.docx Comment: Replaced by Section Lane Margining at the Receiver Extended Capability per Fix3a #83 lane-margining-capability-snapshot-2016-06-16.pdf 5533 4932 5534 4933 -Incorporated: PCIe 4_0 Tag Field scaling 5535 2017-03-31.docx 4934 5536 4935 4936 4937 Page 78 -Incorporated: PCIe 4_0 Tag Field scaling 2017-03-31.docx 5537 -Vital Product Data (VPD) 5538 5539 -Vital Product Data (VPD) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 4937 5539 4938 5540 4939 -Added Section 6.28 Vital Product Data (VPD) 4940 5646 5045 EWG Changes: 5046 5647 5649 5048 -Typo in Equation 8-3; changed 1.6.0 GT/s to 16.0 GT/s 5049 5650 -Typo in Equation 8-3; changed 1.6.0 GT/s to 16.0 GT/s 5651 5050 5652 - Section 8.4.2.1 Procedure for Calibrating a Stressed EH/EW Eye ; corrected references from Table 8-11 to Table 8-10 5052 5653 - Section 8.4.2.1 Procedure for Calibrating a Stressed EH/EW Eye ; corrected references from Table 8-11 to Table 8-10 5654 5053 5655 - Section 8.5.1.3.3 Simulation Tool Outputs & Section 8.5.1.6 Pass/Fail Eye Characteristics (Figure 8-47); changed “median” to “mean” 5055 5656 - Section 8.5.1.3.3 Simulation Tool Outputs & Section 8.5.1.4.3 Pass/Fail Eye Characteristics (Figure 8-47); changed “median” to “mean” 5657 5056 5658 5057 PWG Changes: 5058 5659 PWG Changes: 5660 5059 5661 5060 -Sub-Sub-Bullet before Figure 4-27. Added “or higher” 5662 after 8.0 GT/s -Sub-Sub-Bullet before Figure 4-27. Added “or higher” after 8.0 GT/s 5061 5663 5062 5063 EWG Changes: 5648 5047 5054 -Added Section 6.28 Vital Product Data (VPD) 5542 5044 5051 5541 5664 - Section 5.11 Power Management Events Power Management Events; deleted last two paragraphs and Implementation Note. 5064 5665 - Section 5.11 Power Management Events Power Management Events; deleted last two paragraphs and Implementation Note. 5666 5065 5667 5066 -Updated Acknowledgements section with additional 5668 contacts. 5067 5669 5068 5069 5670 September 29, 2017 5671 5070 5672 5071 5673 5072 5674 5675 5073 5677 5.0 Version 0.3 5678 5679 5075 Summary of intended changes for 5.0. This was a short document, referencing the PCI Express Base Specification but not including it. 5680 5076 5681 Disclaimer 5682 5078 5683 5079 5684 Page 79 September 29, 2017 5676 5074 5077 -Updated Acknowledgements section with additional contacts. 2017-06-01 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5079 5080 5684 PCI-SIG® disclaims all warranties and liability for the use of this document and the information contained herein and assumes no responsibility for any errors that may appear in this document, nor does PCI-SIG make a commitment to update the information contained herein. 5081 5685 5686 5082 5083 Contact the PCI-SIG office to obtain the latest revision of this specification. 5084 Further details on intended changes for 5.0. This was a short document, referencing the PCI Express Base Specification but not including it. 5690 Questions regarding the PCI Express Base Specification or membership in PCI-SIG may be forwarded to: 5087 5691 2017-11-02 5692 5088 5089 5688 5689 5085 5086 Version 0.5 5687 5693 Membership Services www.pcisig.com E-mail: administration@pcisig.com Phone: 503-619-0569 Fax: 503-644-6708 5090 5694 5695 5091 5092 Version 0.7 5696 Technical Support techsupp@pcisig.com 5697 This was the first release of Base 5.0 based on the 4.0 Specification text. The 4.0 specification was converted into HTML format during this process. This conversion process was imperfect but does not impact the new 5.0 material. 5698 5699 5700 2018-06-07 5701 5702 5703 5704 Version 0.9 5705 5706 This includes: 5707 5708 5709 5710 Additional details regarding operating at 32.0 GT/s Corrections to match published Base 4.0 Redrawing of some figures 5711 5712 PCIe_Base_r4_0_Errata_2018-10-04a.pdf 5713 5714 ECN-Thermal-Reporting 2017May18.pdf 5715 5716 ECN-Link-Activation-07-Dec-2017.pdf 5717 5718 5719 5093 5720 5094 5095 Page 80 5721 DISCLAIMER 2018-10-18 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5095 DISCLAIMER 5096 5722 5723 5097 5098 Version 1.0 5724 This PCI Express Base Specification is provided “as is” with no warranties whatsoever, including any warranty of merchantability, noninfringement, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification, or sample. PCI-SIG disclaims all liability for infringement of proprietary rights, relating to use of information in this specification. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted herein. 5099 5725 This includes: 5726 5727 Corrections and clarification for support of the 32.0 GT/ s operation 5728 Editorial Changes: Rewrite misleading / confusing text Update terminology for consistency and accuracy Update grammar for readability Add many hotlinks / cross references 5729 5730 5731 5732 5100 5101 5733 PCI, PCI Express, PCIe, and PCI-SIG are trademarks or registered trademarks of PCI-SIG. 5734 Implement all 4.0 Errata Incorporate Expansion ROM Validation ECN Expansion ROM Validation ECN.pdf Incorporate Enhanced PCIe Precision Time Measurement 5735 5736 5737 (ePTM) ECN 5738 ECN_ePTM_10_January_2019.pdf Incorporate Root Complex Event Collector Bus Number 5739 Association ECN 5740 5741 5742 5743 5744 5745 5746 5747 5748 5749 5750 5102 5751 5103 5104 ECN EventCollector 13Sept2018a.pdf Incorporate PCIe Link Activation ECN ECN Link Activation 07 Dec 2017.pdf Incorporate Advanced Capabilities for Conventional PCI ECN (updated for PCIe) ECN_Conventional_Adv_Caps_27Jul06.pdf Incorporate Async Hot-Plug Updates ECN ECN Async Hot-Plug Updates 2018-11-29.pdf Incorporate ACS Enhanced Capability ECN ECN_ACS_25_Apr_2019_Clean.pdf Incorporate the Subsystem ID and Sybsystem Vendor ID Capability, from the PCI-to-PCI Bridge Architecture Specification, Revision 1.2 (updated for PCIe) ppb12.pdf 5752 All other product names are trademarks, registered trademarks, or servicemarks of their respective owners. 5105 5754 5106 5107 5108 Page 81 5753 5755 Copyright © 2002-2017 PCI-SIG 5756 2019-05-16 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5108 5756 5109 5757 5110 5758 5111 5759 5112 Objective of the Specification 5760 5761 Objective of the PCI Express® Architecture 5762 5763 5764 5113 5765 5114 5115 5766 This specification describes the PCI Express® architecture, interconnect attributes, fabric management, and the programming interface required to design and build systems and peripherals that are compliant with the PCI Express Specification. 5116 5767 5769 The goal is to enable such devices from different vendors to inter-operate in an open architecture. The specification is intended as an enhancement to the PCI™ architecture spanning multiple market segments; clients (desktops and mobile), servers (standard and enterprise), and embedded and communication devices. The specification allows system OEMs and peripheral developers adequate room for product versatility and market differentiation without the burden of carrying obsolete interfaces or losing compatibility. 5770 5119 5771 5120 5772 5121 5773 5122 Document Organization 5124 5775 PCI Express Architecture Specification Organization 5776 5125 5777 The PCI Express Specification is organized as a base specification and a set of companion documents. The PCI Express Base Specification and the PCI Express Card Electromechanical Specification are among those that have been published. As the PCI Express definition evolves, other companion documents will be published. 5127 5778 The PCI Express specifications are organized as a base specification and a set of companion documents. 5779 5128 5129 The goal is to enable such devices from different vendors to inter-operate in an open architecture. The specification is intended as an enhancement to the PCI™ architecture spanning multiple market segments; clients (desktops and mobile), servers (standard and enterprise), and embedded and communication devices. The specification allows system OEMs and peripheral developers adequate room for product versatility and market differentiation without the burden of carrying obsolete interfaces or losing compatibility. 5774 5123 5126 This specification describes the PCI Express® architecture, interconnect attributes, fabric management, and the programming interface required to design and build systems and peripherals that are compliant with the PCI Express Specification. 5768 5117 5118 This document defines the “base” specification for the PCI Express architecture, including the electrical, protocol, platform architecture and programming interface elements required to design and build devices and systems. A key goal of the PCI Express architecture is to enable devices from different vendors to inter-operate in an open architecture, spanning multiple market segments including clients, servers, embedded, and communication devices. The architecture provides a flexible framework for product versatility and market differentiation. 5780 The PCI Express Base Specification contains the technical details of the architecture, protocol, Link Layer, Physical Layer, and software interface. The PCI Express Base Specification is applicable to all variants of PCI Express. 5130 Page 82 5781 5782 The PCI Express Base Specification contains the technical details of the architecture, protocol, Link Layer, Physical Layer, and software interface. The PCI Express Base Specification (this document) is applicable to all variants of PCI Express. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5130 5782 5131 5132 5783 The PCI Express Card Electromechanical Specification focuses on information necessary to implementing an evolutionary strategy with the PCI desktop/server mechanicals as well as electricals. The mechanical chapters of the specification contain a definition of evolutionary PCI Express card edge connectors while the electrical chapters cover auxiliary signals, power delivery, and the Adapter interconnect electrical budget. 5784 5133 5785 5134 5786 5135 5787 5136 5788 5137 Documentation Conventions 5138 Capitalization 5141 Advertise (Credits) 5194 Used in the context of Flow Control, the act of a Receiver sending information regarding its Flow Control Credit availability. Advertise (Credits) 5847 Used in the context of Flow Control, the act of a Receiver sending information regarding its Flow Control Credit availability. 5848 5197 Alternative Routing-ID, ARI 5198 5849 Alternative Routing-ID, ARI 5850 Alternative Routing-ID Interpretation. Applicable to Requester IDs and Completer IDs as well as Routing IDs. 5200 5851 Alternative Routing-ID Interpretation. Applicable to Requester IDs and Completer IDs as well as Routing IDs. 5852 5201 ARI Device 5202 5853 ARI Device 5854 A Device associated with an Upstream Port, whose Functions each contain an ARI Capability structure. 5204 5855 A Device associated with an Upstream Port, whose Functions each contain an ARI Extended Capability structure. 5856 5205 ARI Downstream Port 5206 5857 ARI Downstream Port 5858 A Switch Downstream Port or Root Port that supports ARI Forwarding. 5208 5859 A Switch Downstream Port or Root Port that supports ARI Forwarding. 5860 5209 ARI Forwarding 5210 5861 ARI Forwarding 5862 Functionality that enables the Downstream Port immediately above an ARI Device to access the Devices extended Functions. Enabling ARI Forwarding ensures the logic that determines when to turn a Type 1 Configuration Request into a Type 0 Configuration Request no longer enforces a restriction on the traditional Device Number field being 0. 5212 5863 Functionality that enables the Downstream Port immediately above an ARI Device to access the Devices extended Functions. Enabling ARI Forwarding ensures the logic that determines when to turn a Type 1 Configuration Request into a Type 0 Configuration Request no longer enforces a restriction on the traditional Device Number field being 0. 5864 5213 5293 5845 5846 5196 5211 Capitalization 5794 5193 5207 5792 5793 5142 5203 Documentation Conventions 5791 5140 5199 5789 5790 5139 5195 The companion specifications define a variety of form factors, including mechanical and electrical chapters covering topics including auxiliary signals, power delivery, and the Adapter interconnect electrical budget. Asserted The component of system software responsible for accessing Configuration Space and configuring the PCI/PCIe bus. 5294 Page 83 5865 5945 5946 Asserted The component of system software responsible for accessing Configuration Space and configuring the PCI/PCIe bus. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5294 5946 5295 Configuration Space 5296 5297 Configuration Space 5948 One of the four address spaces within the PCI Express architecture. Packets with a Configuration Space address are used to configure Functions. 5298 5949 One of the four address spaces within the PCI Express architecture. Packets with a Configuration Space address are used to configure Functions. 5950 5299 Configuration-Ready 5300 5301 5947 5951 Configuration-Ready 5952 A Function is “Configuration-Ready” when it is guaranteed that the Function will respond to a valid Configuration Request targeting the Function with a Completion indicating Successful Completion status. 5302 5953 A Function is “Configuration-Ready” when it is guaranteed that the Function will respond to a valid Configuration Request targeting the Function with a Completion indicating Successful Completion status. 5954 5955 Containment Error Recovery, CER 5956 5957 A general error containment and recovery approach supported by Downstream Port Containment (DPC), where with suitable software/firmware support, many uncorrectable errors can be handled without disrupting applications. 5958 5303 Conventional PCI 5304 5305 5959 Behaviors or features originally defined in the PCI Local Bus Specification. The PCI Express Base 4.0 and subsequent specifications incorporate the relevant requirements from the PCI Local Bus Specification. 5306 5961 Behaviors or features originally defined in the PCI Local Bus Specification. The PCI Express Base 4.0 and subsequent specifications incorporate the relevant requirements from the PCI Local Bus Specification. 5962 5307 Conventional Reset 5308 5963 Conventional Reset 5964 5309 A Hot, Warm, or Cold reset. Distinct from Function Level Reset 5965 (FLR). A Hot, Warm, or Cold reset. Distinct from Function Level Reset (FLR). 5310 5966 5311 Data Link Layer 5312 5967 Data Link Layer 5968 5323 deasserted 5324 5979 deasserted 5980 5325 The inactive logical state of a conceptual or actual signal. 5326 5981 The inactive logical state of a conceptual or actual signal. 5982 5327 Design for Testability, DFT 5328 5983 Design for Testability, DFT 5984 5329 Design for Testability. 5330 5985 Design for Testability. 5986 5331 Device (uppercase 'D') 5332 5333 Conventional PCI 5960 5987 Device (uppercase 'D') 5988 A collection of one or more Functions within a single Hierarchy identified by common Bus Number and Device Number. An SR-IOV Device may have additional Functions accessed via additional Bus Numbers and/or Device Numbers configured through one or more SR-IOV Capability structures. 5334 5335 Page 84 5989 A collection of one or more Functions within a single Hierarchy identified by common Bus Number and Device Number. An SR-IOV Device may have additional Functions accessed via additional Bus Numbers and/or Device Numbers configured through one or more SR-IOV Extended Capability structures. 5990 device (lowercase 'd') 5991 device (lowercase 'd') /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5335 5991 device (lowercase 'd') 5336 5337 A physical or logical entity that performs a specific type of 5993 I/O. 5338 5339 A component on either end of a PCI Express Link. A common imprecise synonym for Function, particularly when a device has a single Function. Device Readiness Status, DRS 5343 5998 6064 Flow Control 5409 Device Readiness Status, DRS Flow Control 6065 The method for communicating receive buffer status from a Receiver to a Transmitter to prevent receive buffer overflow and allow Transmitter compliance with ordering rules. 5411 6066 The method for communicating receive buffer status from a Receiver to a Transmitter to prevent receive buffer overflow and allow Transmitter compliance with ordering rules. 6067 5412 6068 Flow Control Packet, FCP 5413 Flow Control Packet, FCP 6069 A DLLP used to send Flow Control information from the Transaction Layer in one component to the Transaction Layer in another component. 5415 6070 A DLLP used to send Flow Control information from the Transaction Layer in one component to the Transaction Layer in another component. 6071 5416 6072 Function 5417 Function 6073 Within a Device, an addressable entity in Configuration Space associated with a single Function Number. Used to refer to one Function of a Multi-Function Device, or to the only Function in a single-Function Device. Specifically included are special types of Functions defined in the I/O Virtualization specifications, notably Physical Functions and Virtual Functions. 5419 6074 Within a Device, an addressable entity in Configuration Space associated with a single Function Number. Used to refer to one Function of a Multi-Function Device, or to the only Function in a Single-Function Device. Specifically included are special types of Functions defined in Chapter 9 Single Root I/O Virtualization and Sharing , notably Physical Functions and Virtual Functions. 6075 5420 6076 Function Group 5421 Function Group 6077 Within an ARI Device, a associated with a single Function optionally serve as the basis for between multiple Functions within configurable set of Functions that are Group Number. Function Groups can VC arbitration or access control the ARI Device. 5423 6078 Within an ARI Device, a associated with a single Function optionally serve as the basis for between multiple Functions within configurable set of Functions that are Group Number. Function Groups can VC arbitration or access control the ARI Device. 6079 5424 Function Level Reset, FLR 5425 5426 A component on either end of a PCI Express Link. A common imprecise synonym for Function, particularly when a device has a single Function. 5999 5408 5422 5995 5997 5342 5418 5994 5996 5341 5414 A physical or logical entity that performs a specific type of I/O. 5340 5410 device (lowercase 'd') 5992 6080 Function Level Reset, FLR 6081 A mechanism for resetting a specific Endpoint Function (see Section 6.6.2 Function Level Reset (FLR) ). 5427 6082 A mechanism for resetting a specific Endpoint Function (see Section 6.6.2 Function Level Reset (FLR) ). 6083 5428 Function Readiness Status, FRS 6084 Function Readiness Status, FRS 5528 Logical Bus 6184 Logical Bus 5529 5530 6185 The logical connection among a collection of Devices that have the same Bus Number in Configuration Space. 5531 Page 85 6186 6187 The logical connection among a collection of Devices that have the same Bus Number in Configuration Space. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5531 6187 5532 Logical Idle 5533 5534 Logical Idle 6189 A period of one or more Symbol Times when no information (TLPs, DLLPs, or any special Symbol) is being transmitted or received. Unlike Electrical Idle, during Logical Idle the Idle data Symbol is being transmitted and received. 5535 6190 A period of one or more Symbol Times when no information (TLPs, DLLPs, or any special Symbol) is being transmitted or received. Unlike Electrical Idle, during Logical Idle the Idle data Symbol is being transmitted and received. 6191 5536 LTR 5537 5538 6188 6192 LTR 6193 Abbreviation for Latency Tolerance ReportingMalformed Packet A TLP that violates specific TLP formation rules as defined in this specification. 6194 Abbreviation for Latency Tolerance Reporting 6195 6196 Malformed Packet 6197 6198 5539 6199 5540 Memory Space 5541 5542 6200 Memory Space 6201 One of the four address spaces of the PCI Express architecture. 5543 6202 One of the four address spaces of the PCI Express architecture. 6203 5544 Message 5545 5546 A TLP that violates specific TLP formation rules as defined in this specification. 6204 Message 6205 A TLP used to communicate information outside of the Memory, I/ O, and Configuration Spaces. 5547 6206 A TLP used to communicate information outside of the Memory, I/ O, and Configuration Spaces. 6207 5548 Message Signaled Interrupt, MSI/MSI-X 6208 Message Signaled Interrupt, MSI/MSI-X 5572 Multicast Window 6232 Multicast Window 5573 5574 6233 A region of Memory Space where Posted Request TLPs that target it will be handled as Multicast TLPs. 5575 Multi-Function Device, MFD 5577 6236 Multi-Function Device, MFD 6237 5578 A Device that has multiple Functions. 5579 6238 A Device that has multiple Functions. 6239 5580 Multi-Root I/O Virtualization, MR-IOV 5581 6240 Multi-Root I/O Virtualization, MR-IOV 6241 A Function that supports the MR-IOV capability. See the MultiRoot I/O Virtualization and Sharing Specification for additional information. 5583 6242 A Function that supports the MR-IOV capability. See [MR-IOV] for additional information. 6243 5584 naturally aligned 5585 5586 A region of Memory Space where Posted Request TLPs that target it will be handled as Multicast TLPs. 6235 5576 5582 6234 6244 naturally aligned 6245 A data payload with a starting address equal to an integer multiple of a power of two, usually a specific power of two. For example, 64-byte naturally aligned means the least significant 6 bits of the byte address are 00 0000b. 5587 5588 Page 86 6246 A data payload with a starting address equal to an integer multiple of a power of two, usually a specific power of two. For example, 64-byte naturally aligned means the least significant 6 bits of the byte address are 00 0000b. 6247 NPEM 6248 NPEM /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5588 NPEM 5589 NPEM 6249 5590 Native PCIe Enclosure Management 5591 6250 Native PCIe Enclosure Management 6251 5592 OBFF 5593 6252 OBFF 6253 5594 Optimized Buffer Flush/Fill 5595 6254 Optimized Buffer Flush/Fill 6255 5596 Operating System 5597 5598 6248 6256 Operating System 6257 Throughout this specification, the terms operating system and system software refer to the combination of power management services, device drivers, user-mode services, and/or kernel mode services. 5599 6258 Throughout this specification, the terms operating system and system software refer to the combination of power management services, device drivers, user-mode services, and/or kernel mode services. 6259 6260 orderly removal 6261 6262 A hot-plug removal model where the OS is notified when a user/ operator wishes to remove an adapter, and the OS has the opportunity to prepare for the event (e.g., quiescing adapter activity) before granting permission for removal. 6263 5600 P2P 5601 Peer-to-peer. 5603 Path 5605 Peer-to-peer. 6268 Path 6269 The flow of data through a Retimer, in either the Upstream Path or the Downstream Path. 5607 6270 The flow of data through a Retimer, in either the Upstream Path or the Downstream Path. 6271 5608 Packet 5609 6272 Packet 6273 5616 PCIe® 5617 6280 PCIe® 6281 5618 PCI Express® 5619 6282 PCI Express® 6283 5620 PCI Bridge 5621 6284 PCI Bridge 6285 5622 See Type 1 Function. 5623 6286 See Type 1 Function. 6287 5624 PCI Software Model 5625 6288 PCI Software Model 6289 The software model necessary to initialize, discover, configure, and use a PCI-compatible device, as specified in the PCI Local Bus Specification, Revision 3.0 , the PCI-X Addendum to the PCI Local Bus Specification, Revision 2.0 , and the PCI Firmware Specification. 5627 6290 The software model necessary to initialize, discover, configure, and use a PCI-compatible device, as specified in [PCI-3.0], [PCI-X-2.0], and [PCI-Firmware]. 6291 5628 Phantom Function Number, PFN 5629 5630 6266 6267 5604 5626 P2P 6265 5602 5606 6264 6292 Phantom Function Number, PFN 6293 An unclaimed Function Number that may be used to expand the number of outstanding transaction identifiers by logically combining the PFN with the Tag identifier to create a unique transaction identifier. Page 87 6294 An unclaimed Function Number that may be used to expand the number of outstanding transaction identifiers by logically combining the PFN with the Tag identifier to create a unique transaction identifier. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5630 An unclaimed Function Number that may be used to expand the 6294 number of outstanding transaction identifiers by logically combining the PFN with the Tag identifier to create a unique transaction identifier. 5631 6295 5632 Physical Function, PF 5633 5634 6296 A PCI Function that supports the SR-IOV capabilities defined in this specification. A PF contains the SR-IOV capability structure. 6298 Physical Lane 5637 6300 See Lane. 5639 6302 Physical Layer 5641 6304 The Layer that directly interacts with the communication medium between two components. 6306 Port 6308 5646 Logically, an interface between a component and a PCI Express 6310 Link. Port Logically, an interface between a component and a PCI Express Link. Physically, a group of Transmitters and Receivers located on the same chip that define a Link. 5648 6311 Physically, a group of Transmitters and Receivers located on the same chip that define a Link. 6312 5649 6313 5650 Power Management 5651 6314 Power Management 6315 Software or Hardware mechanisms used to minimize system power consumption, manage system thermal limits, and maximize system battery life. Power management involves tradeoffs among system speed, noise, battery life, and AC power consumption. 5653 6316 Software or Hardware mechanisms used to minimize system power consumption, manage system thermal limits, and maximize system battery life. Power management involves tradeoffs among system speed, noise, battery life, and AC power consumption. 6317 5654 PMUX Channel 5655 6318 PMUX Channel 6319 A multiplexed channel on a PMUX Link that is configured to transport a specific multiplexed protocol. See Appendix G . 5657 6320 A multiplexed channel on a PMUX Link that is configured to transport a specific multiplexed protocol. See Appendix G Protocol Multiplexing . 6321 5658 PMUX Link 5659 6322 PMUX Link 6323 A Link where Protocol Multiplexing is supported and enabled. See Appendix G . 5661 6324 A Link where Protocol Multiplexing is supported and enabled. See Appendix G Protocol Multiplexing . 6325 5662 PMUX Packet 5663 6326 PMUX Packet 6327 A non-PCI Express Packet transported over a PCI Express Link. See Appendix G . 5665 6328 A non-PCI Express Packet transported over a PCI Express Link. See Appendix G Protocol Multiplexing . 6329 5666 Precision Time Measurement, PTM 5667 5668 The Layer that directly interacts with the communication medium between two components. 6307 5644 5664 Physical Layer 6305 5643 5660 See Lane. 6303 5640 5656 Physical Lane 6301 5638 5652 A PCI Function that contains an SR-IOV Extended Capability structure and supports the SR-IOV capabilities defined in Chapter 9 Single Root I/O Virtualization and Sharing . 6299 5636 5647 Physical Function, PF 6297 5635 5642 An unclaimed Function Number that may be used to expand the number of outstanding transaction identifiers by logically combining the PFN with the Tag identifier to create a unique transaction identifier. 6330 Precision Time Measurement, PTM 6331 Optional capability for communicating precise timing information between components. Page 88 6332 An optional capability for communicating precise timing information between components. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5668 Optional capability for communicating precise timing information between components. 5669 An optional capability for communicating precise timing information between components. 6333 5670 Process Address Space ID, PASID 5671 5672 6332 6334 Process Address Space ID, PASID 6335 The Process Address Space ID, in conjunction with the Requester ID, uniquely identifies the address space associated with a transaction. 5673 6336 The Process Address Space ID, in conjunction with the Requester ID, uniquely identifies the address space associated with a transaction. 6337 6338 Programmed I/O, PIO 6339 6340 A transaction sequence that’s initiated by a host processor, often as the result of executing a single load or store instruction that targets a special address range, but can be generated by other mechanisms such as the PCI-Compatible Configuration Mechanism. Notably, host processor loads or stores targeting an ECAM address range generate Configuration Space transactions. Other memory-mapped ranges typically exist to generate Memory Space and I/O Space transactions. 6341 5674 Pseudo Port 5675 5676 5677 Logically, an interface between a Retimer and a PCI Express Link Segment. Physically, a group of Transmitters and Receivers located on the same Retimer chip that define a Link Segment. 6345 Logically, an interface between a Retimer and a PCI Express Link Segment. Physically, a group of Transmitters and Receivers located on the same Retimer chip that define a Link Segment. 6347 5680 Quality of Service, QoS 5681 6348 Quality of Service, QoS 6349 Attributes affecting the bandwidth, latency, jitter, relative priority, etc., for differentiated classes of traffic. 5683 6350 Attributes affecting the bandwidth, latency, jitter, relative priority, etc., for differentiated classes of traffic. 6351 5700 Re-driver 5701 6368 Re-driver 6369 5702 A non-protocol aware, software transparent, Extension Device. 5703 6370 A non-protocol aware, software transparent, Extension Device. 6371 5704 repeater 5705 6372 repeater 6373 5706 An imprecise term for Extension Device. 5707 6374 An imprecise term for Extension Device. 6375 5708 Reported Error 5709 6376 Reported Error 6377 An error subject to the logging and signaling requirements architecturally defined in this document 5711 6378 An error subject to the logging and signaling requirements architecturally defined in this document. 6379 5712 Request 5713 5714 6344 6346 5679 5710 Pseudo Port 6343 5678 5682 6342 6380 Request 6381 A Packet used to initiate a transaction sequence. A Request includes operation code and, in some cases, address and length, data, or other information. 5715 5716 Page 89 6382 A Packet used to initiate a transaction sequence. A Request includes operation code and, in some cases, address and length, data, or other information. 6383 Requester 6384 Requester /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5716 Requester 5717 5718 6384 Requester 6385 The Function that first introduces a transaction sequence into the PCI Express domain. 5719 6386 The Function that first introduces a transaction sequence into the PCI Express domain. 6387 5720 Requester ID 6388 Requester ID 5764 sideband signaling 6432 sideband signaling 5765 5766 6433 A method for signaling events and conditions using physical signals separate from the signals forming the Link between two components. All mechanisms defined in this document can be implemented using in-band signaling, although in some form factors sideband signaling may be used instead. 5767 single-Function Device, SFD 5769 A device that has a single Function 5771 Single Root I/O Virtualization, SR-IOV 5773 6438 A device that has a single Function 6440 Single Root I/O Virtualization, SR-IOV 6441 A function that supports the SR-IOV capability defined in this specification. 5775 6442 A Function that supports the SR-IOV Extended Capability defined in this specification. 6443 5776 Single Root PCI Manager, SR-PCIM 5777 6444 Single Root PCI Manager, SR-PCIM 6445 Software responsible for configuration and management the SRIOV capability and PF/VF as well as dealing with associated error handling. Multiple implementation options exist; therefore, SR-PCIM implementation is outside the scope of this specification. 5779 6446 Software responsible for configuration and management of the SR-IOV Extended Capability and PF/VF as well as dealing with associated error handling. Multiple implementation options exist; therefore, SR-PCIM implementation is outside the scope of this specification. 6447 5780 SR-IOV Device 5781 6448 SR-IOV Device 6449 A Device containing one or more Functions that have an SR-IOV Capability structure. 5783 6450 A Device containing one or more Functions that have an SR-IOV Extended Capability structure. 6451 5784 SSD 5785 6452 SSD 6453 5786 Solid State Drive 5787 6454 Solid State Drive 6455 5788 Swap, Unconditional Swap 5789 5790 Single-Function Device, SFD 6439 5772 5782 6436 6437 5770 5778 A method for signaling events and conditions using physical signals separate from the signals forming the Link between two components. All mechanisms defined in this document can be implemented using in-band signaling, although in some form factors sideband signaling may be used instead. 6435 5768 5774 6434 6456 Swap, Unconditional Swap 6457 An AtomicOp where a specified value is written to a target location, and the original value of the location is returned. 5791 6458 An AtomicOp where a specified value is written to a target location, and the original value of the location is returned. 6459 5792 Switch 6460 Switch 5800 Symbol Time 6468 Symbol Time 5801 5802 6469 The period of time required to place a Symbol on a Lane (10 times the Unit Interval when using 8b/10b encoding and 8 times the Unit Interval when using 128b/130b encoding). 5803 Page 90 6470 6471 The period of time required to place a Symbol on a Lane (10 times the Unit Interval when using 8b/10b encoding and 8 times the Unit Interval when using 128b/130b encoding). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5803 6471 5804 System Element 5805 5806 A defined Device or collection of devices that operate according to distinct sets of rules. The following System Elements are defined: Root Complex, Endpoint, Switch, and Bridge. System Image, SI 5809 A defined Device or collection of Devices that operate according to distinct sets of rules. The following System Elements are defined: Root Complex, Endpoint, Switch, and Bridge. 6476 System Image, SI 6477 A software component running on a virtual system to which specific Functions, PF, and VF can be assigned. Specification of the behavior and architecture of an SI is outside the scope of this specification. Examples of SIs include guest operating systems and shared/non-shared protected domain device drivers. 5811 6478 A software component running on a virtual system to which specific Functions, PFs, and VFs can be assigned. Specification of the behavior and architecture of an SI is outside the scope of this specification. Examples of SIs include guest operating systems and shared/non-shared protected domain device drivers. 6479 5812 System Software 5813 6480 System Software 6481 Includes System Firmware (BIOS, UEFI), Operating System, VMM, management software, platform vendor’s add-on to the Operating System. 5815 6482 Includes System Firmware (BIOS, UEFI), Operating System, VMM, management software, platform vendor’s add-on to the Operating System. 6483 5816 Tag 5817 5818 6474 6475 5808 5814 System Element 6473 5807 5810 6472 6484 Tag 6485 A number assigned to a given Non-Posted Request to distinguish Completions for that Request from other Requests. 5819 6486 A number assigned to a given Non-Posted Request to distinguish Completions for that Request from other Requests. 6487 5820 TLP Prefix 6488 TLP Prefix 5908 warm reset 6576 warm reset 5909 5910 6577 A Fundamental Reset without cycling main power. 6578 5911 6579 5912 6580 5913 6581 5914 5915 A Fundamental Reset without cycling main power. 6582 Reference Documents 6583 5916 6584 5917 6585 6586 6587 Reference Documents PCI PCI-3.0 6588 6589 PCI Local Bus Specification, Revision 3.0 6590 6591 6592 PCIe PCIe-5.0 6593 6594 PCI Express Base Specification, Revision 5.0 6595 6596 PCIe-4.0 6597 6598 PCI Express Base Specification, Revision 4.0 6599 6600 Page 91 PCIe-3.1 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 6600 6601 PCIe-3.1 PCIe-3.1a 6602 6603 PCI Express Base Specification, Revision 3.1a 6604 6605 PCIe-3.0 6606 6607 PCI Express Base Specification, Revision 3.0 6608 6609 PCIE-2.1 6610 6611 PCI Express Base Specification, Revision 2.1 6612 6613 PCIe-2.0 6614 6615 PCI Express Base Specification, Revision 2.0 6616 6617 PCIe-1.1 6618 6619 PCI Express Base Specification, Revision 1.1 6620 6621 6622 PCIe-1.0 PCIe-1.0a 6623 6624 PCI Express Base Specification, Revision 1.0a 6625 6626 6627 CEM CEM-4.0 6628 5918 PCI Express Card Electromechanical Specification, Revision 4.0 5919 6629 PCI Express Card Electromechanical Specification, Revision 4.0 6630 6631 CEM-3.0 6632 6633 PCI Express Card Electromechanical Specification, Revision 3.0 6634 6635 CEM-2.0 6636 6637 PCI Express Card Electromechanical Specification, Revision 2.0 6638 6639 ECN-CEM-THERMAL 6640 6641 PCIe CEM Thermal Reporting ECN to the PCI Express Card Electromechanical Specification, Revision 3.0 6642 6643 6644 5920 5921 5922 6645 PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0 6646 Page 92 PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0 6647 6648 5923 PCIe-to-PCI-PCI-X-Bridge PCIe-to-PCI-PCI-X-Bridge-1.0 6649 Mini-Card /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5923 6649 5924 PCI Express Mini Card Electromechanical Specification, Revision 6650 2.1 PCI Express Mini Card Electromechanical Specification, Revision 2.1 5925 6651 6652 5926 OCuLink 6653 5927 PCI Express OCuLink Specification, Revision 1.0 5928 6654 PCI Express OCuLink Specification, Revision 1.0 6655 6656 5929 M.2 6657 5930 PCI Express M.2 Specification, Revision 1.1 5931 6658 PCI Express M.2 Specification, Revision 1.1 6659 6660 U.2 SFF-8639 6661 5932 6662 5933 PCI Express External Cabling Specification, Revision 2.0 5934 6663 PCI Express SFF-8639 Module Specification, Revision 3.0, Version 1.0 6664 6665 5935 5936 Ext-Cabling 6666 PCI Express ExpressModule Electromechanical Specification, Revision 1.0 5937 6667 PCI Express External Cabling Specification, Revision 2.0 6668 6669 5938 ExpressModule 6670 5939 PCI-X Addendum to the PCI Local Bus Specification, Revision 2.0 5940 6671 PCI Express ExpressModule Electromechanical Specification, Revision 1.0 6672 6673 PCI-Hot-Plug PCI-Hot-Plug-1.1 6674 5941 6675 5942 PCI Hot-Plug Specification, Revision 1.1 5943 6676 PCI Hot-Plug Specification, Revision 1.1 6677 6678 5944 5945 PCI-PM 6679 PCI Standard Hot-Plug Controller and Subsystem Specification, Revision 1.0 5946 6680 PCI Bus Power Management Interface Specification, Revision 1.2 6681 6682 5947 5948 PCI Code and ID Assignment Specification, Revision 1.9 (or 6684 later) PCI Code and ID Assignment Specification, Revision 1.11 (or later) 5949 6685 6686 5950 Firmware 6687 5951 PCI Firmware Specification, Revision 3.2 5952 6688 PCI Firmware Specification, Revision 3.2 6689 6690 5953 5954 PCI-Code-and-ID 6683 ACPI 6691 Advanced Configuration and Power Interface Specification, Revision 6.2 Page 93 6692 Advanced Configuration and Power Interface Specification, Revision 6.2 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5954 Advanced Configuration and Power Interface Specification, 6692 Revision 6.2 5955 Advanced Configuration and Power Interface Specification, Revision 6.2 6693 6694 UEFI 6695 6696 Unified Extensible Firmware Interface (UEFI) Specification, Version 2.8 6697 6698 EUI-48 EUI-64 6699 6700 6701 Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID) 6702 6703 JEDEC-JESD22-C101 6704 6705 JEDEC JESD22-C101F: Field-Induced Charged-Device Model Test Method for Electrostatic Discharge Withstand Thresholds of Microelectronic Components 6706 6707 JEDEC-JEP155-JEP157 6708 6709 JEDEC JEP155: Recommended ESD Target Levels for HBM/MM Qualification and JEP157 Recommended ESD-CDM Target Levels 6710 6711 ESDA-JEDEC-JS-001-2010 6712 6713 ESDA/JEDEC JS-001-2010: Joint JEDEC/ESDA Standard for Electrostatic Discharge Sensitivity Test - Human Body Model (HBM) Component Level 6714 6715 ITU-T-Rec.-X.667 6716 6717 5956 5957 6718 Unified Extensible Firmware Interface (UEFI) Specification Version 2.7 Errata A 5958 6719 ISO/IEC-9834-8 6720 6721 5959 5960 ITU T-Rec. X.667: Information technology - Procedures for the operation of object identifier registration authorities: Generation of universally unique identifiers and their use in object identifiers ISO/IEC 9834-8: Information technology -- Procedures for the operation of object identifier registration authorities -- Part 8: Generation of universally unique identifiers (UUIDs) and their use in object identifiers 6722 Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority 5961 6723 RFC-4122 6724 6725 IETF RFC-4122: A Universally Unique IDentifier (UUID) URN Namespace 5962 6726 5963 Multi-Root I/O Virtualization and Sharing Specification, Revision 1.0 Page 94 6727 PICMG /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 5963 Multi-Root I/O Virtualization and Sharing Specification, Revision 6727 PICMG 6728 1.0 6729 PICMG 6730 6731 PLUG-PLAY-ISA-1.0a 6732 6733 Plug and Play ISA Specification, Version 1.0a, May 5, 1994 6734 6735 PC-Card 6736 6737 5964 6738 5965 6739 5966 6740 5967 6741 5968 6742 5969 1. Introduction 5970 6746 This chapter presents an overview of the PCI Express architecture and key concepts. PCI Express is a high performance, general purpose I/O interconnect defined for a wide variety of future computing and communication platforms. Key PCI attributes, such as its usage model, load-store architecture, and software interfaces, are maintained, whereas its parallel bus implementation is replaced by a highly scalable, fully serial interface. PCI Express takes advantage of recent advances in point-to-point interconnects, Switch-based technology, and packetized protocol to deliver new levels of performance and features. Power Management, Quality of Service (QoS), Hot-Plug/hot-swap support, data integrity, and error handling are among some of the advanced features supported by PCI Express. 6747 Ability to test electrical compliance via simple connection to test equipment 6818 6045 6819 6046 6820 6047 6821 6048 6822 6049 6823 6050 Ability to test electrical compliance via simple connection to test equipment 6824 6051 1.2 PCI Express Link 6052 6825 1.2 PCI Express Link 6826 6053 6054 1. Introduction 6745 This chapter presents an overview of the PCI Express architecture and key concepts. PCI Express is a high performance, general purpose I/O interconnect defined for a wide variety of future computing and communication platforms. Key PCI attributes, such as its usage model, load-store architecture, and software interfaces, are maintained, whereas its parallel bus implementation is replaced by a highly scalable, fully serial interface. PCI Express takes advantage of recent advances in point-to-point interconnects, Switch-based technology, and packetized protocol to deliver new levels of performance and features. Power Management, Quality of Service (QoS), Hot-Plug/hot-swap support, data integrity, and error handling are among some of the advanced features supported by PCI Express. 5973 6044 6743 6744 5971 5972 PC-Card 6827 A Link represents a dual-simplex communications channel between two components. The fundamental PCI Express Link consists of two, lowvoltage, differentially driven signal pairs: a Transmit pair and a Receive pair as shown in Figure 1-1 PCI Express Link . A PCI Express Link consists of a PCIe PHY as defined in Chapter 4 . 6828 6055 6829 6056 6830 Page 95 A Link represents a dual-simplex communications channel between two components. The fundamental PCI Express Link consists of two, lowvoltage, differentially driven signal pairs: a Transmit pair and a Receive pair as shown in Figure 1-1 PCI Express Link . A PCI Express Link consists of a PCIe PHY as defined in Chapter 4 Physical Layer Logical Block . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 6056 6830 6057 6831 6058 6832 6059 Figure 1-1 PCI Express Link 6833 6060 6834 6061 6835 6062 6836 6063 The primary Link attributes for PCI Express Link are: 6064 6065 6066 6067 6068 6069 6070 6837 The basic Link - PCI Express Link consists of dual unidirectional differential Links, implemented as a Transmit pair and a Receive pair. A data clock is embedded using an encoding scheme (see Chapter 4 Physical Layer Logical Block ) to achieve very high data rates. Signaling rate - Once initialized, each Link must only operate at one of the supported signaling levels. For the first generation of PCI Express technology, there is only one signaling rate defined, which provides an effective 2.5 Gigabits/second/Lane/direction of raw bandwidth. The second generation provides an effective 5.0 Gigabits/ second/Lane/direction of raw bandwidth. The third generation provides an effective 8.0 Gigabits/ second/Lane/direction of raw bandwidth. The fourth generation provides an effective 16.0 Gigabits/ second/Lane/direction of raw bandwidth. 6071 6073 6074 The primary Link attributes for PCI Express Link are: 6838 6839 6840 6841 6842 6843 6844 6845 6072 Figure 1-1 PCI Express Link The basic Link - PCI Express Link consists of dual unidirectional differential Links, implemented as a Transmit pair and a Receive pair. A data clock is embedded using an encoding scheme (see Chapter 4 Physical Layer Logical Block ) to achieve very high data rates. Signaling rate - Once initialized, each Link must only operate at one of the supported signaling levels. For the first generation of PCI Express technology, there is only one signaling rate defined, which provides an effective 2.5 Gigabits/second/Lane/direction of raw bandwidth. The second generation provides an effective 5.0 Gigabits/ second/Lane/direction of raw bandwidth. The third generation provides an effective 8.0 Gigabits/ second/Lane/direction of raw bandwidth. The fourth generation provides an effective 16.0 Gigabits/ second/Lane/direction of raw bandwidth. The fifth generation provides an effective 32.0 Gigabits/ second/Lane/direction of raw bandwidth. 6846 Lanes - A Link must support at least one Lane - each Lane represents a set of differential signal pairs (one pair for transmission, one pair for reception). To scale bandwidth, a Link may aggregate multiple Lanes denoted by xN where N may be any of the supported Link widths. A x8 Link operating at the 2.5 GT/s data rate represents an aggregate bandwidth of 20 Gigabits/second of raw bandwidth in each direction. This specification describes operations for x1, x2, x4, x8, x12, x16, and x32 Lane widths. Initialization - During hardware initialization, each PCI Express Link is set up following a negotiation of Lane widths and frequency of operation by the two agents at each end of the Link. No firmware or operating system software is involved. Symmetry - Each Link must support a symmetric number of Lanes in each direction, i.e., a x16 Link indicates there are 16 differential signal pairs in each direction. 6847 6848 6849 6075 6850 6076 6851 6077 6852 6078 6079 6853 1.3 PCI Express Fabric Topology 6080 6141 Page 96 6854 1.3 PCI Express Fabric Topology 6855 6139 6140 Lanes - A Link must support at least one Lane - each Lane represents a set of differential signal pairs (one pair for transmission, one pair for reception). To scale bandwidth, a Link may aggregate multiple Lanes denoted by xN where N may be any of the supported Link widths. A x8 Link operating at the 2.5 GT/s data rate represents an aggregate bandwidth of 20 Gigabits/second of raw bandwidth in each direction. This specification describes operations for x1, x2, x4, x8, x12, x16, and x32 Lane widths. Initialization - During hardware initialization, each PCI Express Link is set up following a negotiation of Lane widths and frequency of operation by the two agents at each end of the Link. No firmware or operating system software is involved. Symmetry - Each Link must support a symmetric number of Lanes in each direction, i.e., a x16 Link indicates there are 16 differential signal pairs in each direction. 6914 1.3.2.2 PCI Express Endpoint Rules 6915 6916 1.3.2.2 PCI Express Endpoint Rules /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 6141 6142 6143 6144 6145 6146 6147 6148 6149 6150 6151 6152 6916 A PCI Express Endpoint must be a Function with a Type 00h Configuration Space header. A PCI Express Endpoint must support Configuration Requests as a Completer. A PCI Express Endpoint must not depend on operating system allocation of I/O resources claimed through BAR(s). A PCI Express Endpoint must not generate I/O Requests. A PCI Express Endpoint must not support Locked Requests as a Completer or generate them as a Requester. PCI Express-compliant software drivers and applications must be written to prevent the use of lock semantics when accessing a PCI Express Endpoint. A PCI Express Endpoint operating as the Requester of a Memory Transaction is required to be capable of generating addresses greater than 4 GB. A PCI Express Endpoint is required to support MSI or MSI-X or both if an interrupt resource is requested., If MSI is implemented, a PCI Express Endpoint must support the 64-bit Message Address version of the MSI Capability structure. A PCI Express Endpoint requesting memory resources through a BAR must set the BAR’s Prefetchable bit unless the range contains locations with read side-effects or locations in which the Function does not tolerate write merging. See for additional guidance on having the Prefetchable bit Set. 6917 For a PCI Express Endpoint, 64-bit addressing must be supported for all BARs that have the Prefetchable bit Set. 32-bit addressing is permitted for all BARs that do not have the Prefetchable bit Set. The minimum memory address range requested by a BAR is 128 bytes. A PCI Express Endpoint must appear within one of the hierarchy domains originated by the Root Complex. 6925 6918 6919 6920 6921 6922 6923 6924 6926 6927 6153 6928 6154 6929 6155 6930 6156 6931 6157 1.3.2.3 Root Complex Integrated Endpoint Rules 6158 6159 6160 6161 6162 6163 6164 A PCI Express Endpoint must be a Function with a Type 00h Configuration Space header. A PCI Express Endpoint must support Configuration Requests as a Completer. A PCI Express Endpoint must not depend on operating system allocation of I/O resources claimed through BAR(s). A PCI Express Endpoint must not generate I/O Requests. A PCI Express Endpoint must not support Locked Requests as a Completer or generate them as a Requester. PCI Express-compliant software drivers and applications must be written to prevent the use of lock semantics when accessing a PCI Express Endpoint. A PCI Express Endpoint operating as the Requester of a Memory Transaction is required to be capable of generating addresses greater than 4 GB. A PCI Express Endpoint is required to support MSI or MSI-X or both if an interrupt resource is requested., If MSI is implemented, a PCI Express Endpoint must support the 64-bit Message Address version of the MSI Capability structure. A PCI Express Endpoint requesting memory resources through a BAR must set the BAR’s Prefetchable bit unless the range contains locations with read side-effects or locations in which the Function does not tolerate write merging. See Section 7.5.1.2.1 Base Address Registers (Offset 10h - 24h) for additional guidance on having the Prefetchable bit Set. For a PCI Express Endpoint, 64-bit addressing must be supported for all BARs that have the Prefetchable bit Set. 32-bit addressing is permitted for all BARs that do not have the Prefetchable bit Set. The minimum memory address range requested by a BAR is 128 bytes. A PCI Express Endpoint must appear within one of the hierarchy domains originated by the Root Complex. 6932 1.3.2.3 Root Complex Integrated Endpoint Rules 6933 A Root Complex Integrated Endpoint (RCiEP) is implemented on internal logic of Root Complexes that contains the Root Ports. An RCiEP must be a Function with a Type 00h Configuration Space header. An RCiEP must support Configuration Requests as a Completer. An RCiEP must not require I/O resources claimed through BAR(s). An RCiEP must not generate I/O Requests. An RCiEP must not support Locked Requests as a Completer or generate them as a Requester. PCI Express-compliant software drivers and applications must be written to prevent the use of lock semantics when accessing an RCiEP. Page 97 6934 6935 6936 6937 6938 6939 A Root Complex Integrated Endpoint (RCiEP) is implemented on internal logic of Root Complexes that contains the Root Ports. An RCiEP must be a Function with a Type 00h Configuration Space header. An RCiEP must support Configuration Requests as a Completer. An RCiEP must not require I/O resources claimed through BAR(s). An RCiEP must not generate I/O Requests. An RCiEP must not support Locked Requests as a Completer or generate them as a Requester. PCI Express-compliant software drivers and applications must be written to prevent the use of lock semantics when accessing an RCiEP. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 6164 An RCiEP must not support Locked Requests as a Completer or /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html generate them as a Requester. PCI Express-compliant software drivers and 6165 6166 6167 6168 6169 6170 6171 6172 6173 applications must be written to prevent the use of lock semantics when accessing an RCiEP. An RCiEP operating as the Requester of a Memory Transaction is required to be capable of generating addresses equal to or greater than the Host is capable of handling as a Completer. An RCiEP is required to support MSI or MSI-X or both if an interrupt resource is requested. If MSI is implemented, an RCiEP is permitted to support either the 32-bit or 64-bit Message Address version of the MSI Capability structure. An RCiEP is permitted to support 32-bit addressing for Base Address Registers that request memory resources. An RCiEP must not implement Link Capabilities, Link Status, Link Control, Link Capabilities 2, Link Status 2, and Link Control 2 registers in the PCI Express Extended Capability. See Section 7.5.3 PCI Express Capability Structure for more details. An RCiEP must signal PME and error conditions through the same mechanisms used on PCI systems. If a Root Complex Event Collector is implemented, an RCiEP may optionally signal PME and error conditions through a Root Complex Event Collector. In this case, an RCiEP must be associated with no more than one Root Complex Event Collector. An RCiEP does not implement Active State Power Management. An RCiEP may not be hot-plugged independent of the Root Complex as a whole. An RCiEP must not appear in any of the hierarchy domains exposed by the Root Complex. An RCiEP must not appear in Switches. 6939 6940 6941 6942 6943 6944 6945 6946 6947 6948 6949 6174 6950 6175 6951 6176 6952 6177 6953 6178 1.3.3 Switch Endpoints (represented by Type 00h Configuration Space headers) must not appear to configuration software on the Switch’s internal bus as peers of the virtual PCI-to-PCI Bridges representing the Switch Downstream Ports. 6955 6973 6198 6974 6199 6975 6200 6976 6201 1.3.4 Root Complex Event Collector 6203 6205 6206 6207 1.3.3 Switch Endpoints (represented by Type 00h Configuration Space headers) must not appear to configuration software on the Switch’s internal bus as peers of the virtual PCI-to-PCI Bridges representing the Switch Downstream Ports. 6977 6202 6204 An RCiEP does not implement Active State Power Management. An RCiEP may not be hot-plugged independent of the Root Complex as a whole. An RCiEP must not appear in any of the hierarchy domains exposed by the Root Complex. An RCiEP must not appear in Switches. 6954 6179 6197 An RCiEP must not support Locked Requests as a Completer or generate them as a Requester. PCI Express-compliant software drivers and applications must be written to prevent the use of lock semantics when accessing an RCiEP. An RCiEP operating as the Requester of a Memory Transaction is required to be capable of generating addresses equal to or greater than the Host is capable of handling as a Completer. An RCiEP is required to support MSI or MSI-X or both if an interrupt resource is requested. If MSI is implemented, an RCiEP is permitted to support either the 32-bit or 64-bit Message Address version of the MSI Capability structure. An RCiEP is permitted to support 32-bit addressing for Base Address Registers that request memory resources. An RCiEP must not implement Link Capabilities, Link Status, Link Control, Link Capabilities 2, Link Status 2, and Link Control 2 registers in the PCI Express Extended Capability. If an RCiEP is associated with an optional Root Complex Event Collector it must signal PME and error conditions through the Root Complex Event Collector. An RCiEP must not be associated with more than one Root Complex Event Collector. 6978 1.3.4 Root Complex Event Collector 6979 A Root Complex Event Collector provides support for terminating error and PME messages from RCiEPs. A Root Complex Event Collector must follow all rules for an RCiEP. A Root Complex Event Collector is not required to decode any memory or I/O resources. A Root Complex Event Collector is identified by its Device/ Port Type value (see section 7.5.3.2 ). Page 98 6980 6981 6982 6983 A Root Complex Event Collector provides support for terminating error and PME messages from RCiEPs. A Root Complex Event Collector must follow all rules for an RCiEP. A Root Complex Event Collector is not required to decode any memory or I/O resources. A Root Complex Event Collector is identified by its Device/ Port Type value (see Section 7.5.3.2 PCI Express Capabilities Register (Offset 02h) ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 6983 6208 6984 6209 6210 6211 6212 A Root Complex Event Collector has the Base Class 08h, SubClass 07h and Programming Interface 00h. [Footnote: Since an earlier version of this specification used Sub-Class 06h for this purpose, an implementation is still permitted to use Sub-Class 06h, but this is strongly discouraged.] A Root Complex Event Collector resides on the same Logical Bus as the RCiEPs it supports. Multiple Root Complex Event Collectors are permitted to reside on a single Logical Bus. A Root Complex Event Collector explicitly declares supported RCiEPs through the Root Complex Event Collector Endpoint Association Capability. Root Complex Event Collectors are optional. 6985 6986 6987 6213 6988 6214 6989 6215 6990 6216 1.3.5 PCI Express to PCI/PCI-X Bridge 6218 6992 A PCI Express to PCI/PCI-X Bridge provides a connection between a PCI Express fabric and a PCI/PCI-X hierarchy. 6994 6995 6221 6996 6223 6998 6224 1.4 Hardware/Software Model for Discovery, Configuration and 7000 Operation 7001 6227 7002 The PCI/PCIe hardware/software model includes architectural constructs necessary to discover, configure, and use a Function, without needing Function-specific knowledge. Key elements include: 6229 6232 6233 Page 7005 7006 7007 7008 A configuration model which provides system software the means to discover hardware Functions available in a system Mechanisms to perform basic resource allocation for addressable resources such as memory space and interrupts Enable/disable controls for Function response to received Requests, and initiation of Requests Well-defined ordering and flow control models to support the consistent and robust implementation of hardware/software interfaces 7010 The PCI Express configuration model supports two mechanisms: 6237 6239 The PCI/PCIe hardware/software model includes architectural constructs necessary to discover, configure, and use a Function, without needing Function-specific knowledge. Key elements include: 7009 6235 6238 7003 7004 A configuration model which provides system software the means to discover hardware Functions available in a system Mechanisms to perform basic resource allocation for addressable resources such as memory space and interrupts Enable/disable controls for Function response to received Requests, and initiation of Requests Well-defined ordering and flow control models to support the consistent and robust implementation of hardware/software interfaces. 6234 6236 1.4 Hardware/Software Model for Discovery, Configuration and Operation 6226 6231 A PCI Express to PCI/PCI-X Bridge provides a connection between a PCI Express fabric and a PCI/PCI-X hierarchy. 6999 6225 6230 1.3.5 PCI Express to PCI/PCI-X Bridge 6993 6220 6228 Root Complex Event Collectors are optional. 6991 6217 6219 A Root Complex Event Collector is identified by its Device/ Port Type value (see Section 7.5.3.2 PCI Express Capabilities Register (Offset 02h) ). A Root Complex Event Collector has the Base Class 08h, SubClass 07h and Programming Interface 00h. [Footnote: Since an earlier version of this specification used Sub-Class 06h for this purpose, an implementation is still permitted to use Sub-Class 06h, but this is strongly discouraged.] A Root Complex Event Collector resides on a Bus in the Root Complex. Multiple Root Complex Event Collectors are permitted to reside on a single Bus. A Root Complex Event Collector explicitly declares supported RCiEPs through the Root Complex Event Collector Endpoint Association Extended Capability. 7011 The PCI Express configuration model supports two mechanisms: 7012 PCI-compatible configuration mechanism: The PCI-compatible mechanism supports 100% binary compatibility with Conventional PCI aware operating systems and their corresponding bus enumeration and configuration software. PCI Express enhanced configuration mechanism: The enhanced mechanism is provided to increase the size of available Configuration Space and to optimize access mechanisms. 99 7013 7014 PCI-compatible configuration mechanism: The PCI-compatible mechanism supports 100% binary compatibility with Conventional PCI aware operating systems and their corresponding bus enumeration and configuration software. PCI Express enhanced configuration mechanism: The enhanced mechanism is provided to increase the size of available Configuration Space and to optimize access mechanisms. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 6239 PCI Express enhanced configuration mechanism: The enhanced mechanism is provided to increase the size of available Configuration Space and to optimize access mechanisms. 6240 7016 Each PCI Express Link is mapped through a virtual PCI-to-PCI Bridge structure and has a logical PCI bus associated with it. The virtual PCI-to-PCI Bridge structure may be part of a PCI Express Root Complex Port, a Switch Upstream Port, or a Switch Downstream Port. A Root Port is a virtual PCI-to-PCI Bridge structure that originates a PCI Express hierarchy domain from a PCI Express Root Complex. Devices are mapped into Configuration Space such that each will respond to a particular Device Number. 7017 6243 7018 6299 7074 6300 7075 6301 7076 6302 Each PCI Express Link is mapped through a virtual PCI-to-PCI Bridge structure and has a logical PCI bus associated with it. The virtual PCI-to-PCI Bridge structure may be part of a PCI Express Root Complex Port, a Switch Upstream Port, or a Switch Downstream Port. A Root Port is a virtual PCI-to-PCI Bridge structure that originates a PCI Express hierarchy domain from a PCI Express Root Complex. Devices are mapped into Configuration Space such that each will respond to a particular Device Number. 7077 6303 1.5.3 Physical Layer 6304 7078 1.5.3 Physical Layer 7079 6305 6306 PCI Express enhanced configuration mechanism: The enhanced mechanism is provided to increase the size of available Configuration Space and to optimize access mechanisms. 7015 6241 6242 7014 7080 The Physical Layer includes all circuitry for interface operation, including driver and input buffers, parallel-to-serial and serial-to-parallel conversion, PLL(s), and impedance matching circuitry. It also includes logical functions related to interface initialization and maintenance. The Physical Layer exchanges information with the Data Link Layer in an implementation-specific format. This Layer is responsible for converting information received from the Data Link Layer into an appropriate serialized format and transmitting it across the PCI Express Link at a frequency and width compatible with the device connected to the other side of the Link. 6307 7081 The Physical Layer includes all circuitry for interface operation, including driver and input buffers, parallel-to-serial and serial-to-parallel conversion, PLL(s), and impedance matching circuitry. It also includes logical functions related to interface initialization and maintenance. The Physical Layer exchanges information with the Data Link Layer in an implementation-specific format. This Layer is responsible for converting information received from the Data Link Layer into an appropriate serialized format and transmitting it across the PCI Express Link at a frequency and width compatible with the device connected to the other side of the Link. 7082 6308 7083 6309 . 6310 6311 6312 The PCI Express architecture has “hooks” to support future performance enhancements via speed upgrades and advanced encoding techniques. The future speeds, encoding techniques or media may only impact the Physical Layer definition. 7084 6313 7085 6314 7086 6315 7087 6316 6317 7088 1.5.4 Layer Functions and Services 7089 6318 7090 6319 7091 6320 6321 1.5.4 Layer Functions and Services 7092 1.5.4.1 Transaction Layer Services 7093 6592 7364 6593 7365 Page 100 The PCI Express architecture has “hooks” to support future performance enhancements via speed upgrades and advanced encoding techniques. The future speeds, encoding techniques or media may only impact the Physical Layer definition. 1.5.4.1 Transaction Layer Services /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 6593 6594 7365 Certain Memory Transactions can optionally have a PASID TLP Prefix containing the Process Address Space ID (PASID). See Section 6.20 PASID TLP Prefix for details. 7366 6595 7367 6596 7368 6597 7369 6598 7370 6599 2.1.1.2 I/O Transactions 6600 7371 7373 PCI Express supports I/O Space for compatibility with legacy devices which require their use. Future revisions of this specification may deprecate the use of I/O Space. I/O Transactions include the following types: 6603 7374 Read Request/Completion Write Request/Completion 6605 6606 7376 7377 7379 6608 I/O Transactions use a single address format: 6609 7380 Short Address Format: 32-bit address 7382 6611 7383 6612 7384 6628 Short Address Format: 32-bit address 7400 6629 2.1.1.4 Message Transactions 6630 7401 2.1.1.4 Message Transactions 7402 6631 7403 The Message Transactions, or simply Messages, are used to support in-band communication of events between devices. 6633 7404 The Message Transactions, or simply Messages, are used to support in-band communication of events between devices. 7405 6634 7406 In addition to specific Messages defined in this document, PCI Express provides support for vendor-defined Messages using specified Message codes. Except for Vendor-Defined Messages that use the PCI-SIG® Vendor ID (0001h), the definition of specific vendor-defined Messages is outside the scope of this document. 6636 7407 In addition to specific Messages defined in this document, PCI Express provides support for vendor-defined Messages using specified Message codes. Except for Vendor-Defined Messages that use the PCI-SIG® Vendor ID (0001h), the definition of specific vendor-defined Messages is outside the scope of this document. 7408 6637 7409 This specification establishes a standard framework within which vendors can specify their own Vendor-Defined Messages tailored to fit the specific requirements of their platforms (see ). 6639 7410 This specification establishes a standard framework within which vendors can specify their own Vendor-Defined Messages tailored to fit the specific requirements of their platforms (see Section 2.2.8.6 Vendor_Defined Messages ). 7411 6640 6641 I/O Transactions use a single address format: 7381 6610 6638 Read Request/Completion Write Request/Completion 7378 6607 6635 PCI Express supports I/O Space for compatibility with legacy devices that require their use. Future revisions of this specification may deprecate the use of I/O Space. I/O Transactions include the following types: 7375 6604 6632 2.1.1.2 I/O Transactions 7372 6601 6602 Certain Memory Transactions can optionally have a PASID TLP Prefix containing the Process Address Space ID (PASID). See Section 6.20 PASID TLP Prefix for details. 7412 Note that these vendor-defined Messages are not guaranteed to be interoperable with components from different vendors. 7413 6642 7414 6643 7415 6644 7416 Page 101 Note that these vendor-defined Messages are not guaranteed to be interoperable with components from different vendors. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 6644 7416 6645 7417 6646 7418 6647 2.1.2 Packet Format Overview 6648 6737 6738 6739 6740 6741 7419 2.1.2 Packet Format Overview 7420 TD - 1b indicates presence of TLP Digest in the form of a single Double Word (DW) at the end of the TLP (see Section 2.2.3 TLP Digest Rules ) - bit 7 of byte 2 Error Poisoned (EP) - indicates the TLP is poisoned (see Section 2.7 Data Integrity ) - bit 6 of byte 2 Length[9:0] - Length of data payload in DW (see Table 2-4 Length[9:0] Field Encoding ) - bits 1:0 of byte 2 concatenated with bits 7:0 of byte 3 TLP data must be 4-byte naturally aligned and in increments of 4-byte DW. Reserved for TLPs that do not contain or refer to data payloads, including Cpl, CplLk, and Messages (except as specified) 7509 7510 7511 7512 7513 6742 7514 6743 7515 6744 7516 6745 7517 6746 7518 TD - 1b indicates presence of TLP Digest in the form of a single Double Word (DW) at the end of the TLP (see Section 2.2.3 TLP Digest Rules ) - bit 7 of byte 2 Error Poisoned (EP) - indicates the TLP is poisoned (see Section 2.7 Data Integrity ) - bit 6 of byte 2 Length[9:0] - Length of data payload in DW (see Table 2-4 Length[9:0] Field Encoding ) - bits 1:0 of byte 2 concatenated with bits 7:0 of byte 3 TLP data must be 4-byte naturally aligned and in increments of 4-byte DW. Reserved for TLPs that do not contain or refer to data payloads, including Cpl, CplLk, and Messages (except as specified) 6747 6748 6749 Figure 2-5 Fields Present in All TLP Headers 7519 6750 7520 6751 7521 6752 7522 6753 6754 7523 Table 2-2 Fmt[2:0] Field Values 6755 6756 Figure 2-5 Fields Present in All TLP Headers 7524 Table 2-2 Fmt[2:0] Field Values 7525 Fmt[2:0] 6757 7526 Fmt[2:0] 7527 6758 Corresponding TLP Format 7528 Corresponding TLP Format 6900 Configuration Write Type 1 7670 Configuration Write Type 1 6901 7671 6902 7672 6903 6904 7673 TCfgRd 6905 6906 000 7676 1 1011 7678 1 1011 7679 Deprecated TLP Type [Footnote: 4] 7680 6911 7681 6912 7682 Page 102 000 7677 6909 6910 TCfgRd 7675 6907 6908 7674 Deprecated TLP Type [Footnote: Deprecated TLP Types: previously used for Trusted Configuration Space (TCS), which is no longer supported by this specification. If a Receiver does not implement TCS, the Receiver must treat such Requests as Malformed Packets.] /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 6912 7682 6913 7683 6914 TCfgWr 6915 7684 TCfgWr 7685 6916 010 6917 7686 010 7687 6918 1 1011 6919 7688 1 1011 7689 6920 Deprecated TLP Type [Footnote: Deprecated TLP Types: previously used for Trusted Configuration Space (TCS), which is no longer supported by this specification. If a Receiver does not implement TCS, the Receiver must treat such Requests as Malformed Packets.] 7690 Deprecated TLP Type [Footnote: Deprecated TLP Types: previously used for Trusted Configuration Space (TCS), which is no longer supported by this specification. If a Receiver does not implement TCS, the Receiver must treat such Requests as Malformed Packets.] 7013 Compare and Swap AtomicOp Request 7783 Compare and Swap AtomicOp Request 7014 7784 7015 7785 7016 7786 7017 LPrfx 7018 100 7020 7789 0L3L2L1L0 7022 7791 0 L3L2L1L0 7792 Local TLP Prefix - The sub-field L[3:0] specifies the Local TLP Prefix type (see Table 2-35 Local TLP Prefix Types ). 7793 7024 7794 7025 7795 7026 Local TLP Prefix - The sub-field L[3:0] specifies the Local TLP Prefix type (see Table 2-36 Local TLP Prefix Types ). 7796 7027 EPrfx 7028 7797 EPrfx 7798 7029 100 7030 7799 100 7800 7031 1E3E2E1E0 7032 7801 1 E3E2E1E0 7802 End-End TLP Prefix - The sub-field E[3:0] specifies the End-End TLP Prefix type (see Table 2-36 End-End TLP Prefix Types ). 7803 7034 7804 7035 7805 7036 7037 100 7790 7021 7033 LPrfx 7788 7019 7023 7787 End-End TLP Prefix - The sub-field E[3:0] specifies the End-End TLP Prefix type (see Table 2-37 End-End TLP Prefix Types ). 7806 All encodings not shown above are Reserved (see Section 2.3 Handling of Received TLPs ). 7807 7038 7808 7039 7809 7040 7810 7041 7811 7042 7812 7043 7813 7079 7849 7080 7850 7081 7851 7082 7852 7083 7853 Page 103 All encodings not shown above are Reserved (see Section 2.3 Handling of Received TLPs ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7083 7853 7084 7854 7085 7855 7086 2.2.2 TLPs with Data Payloads - Rules 7087 7088 7089 7090 7093 7094 7095 7096 7097 Length is specified as an integral number of DW Length[9:0] is Reserved for all Messages except those which explicitly refer to a data length Refer to the Message Code tables in Section 2.2.8 Message Request Rules . 7102 7103 7859 7860 Length is specified as an integral number of DW Length[9:0] is Reserved for all Messages except those that explicitly refer to a data length Refer to the Message Code tables in Section 2.2.8 Message Request Rules . 7862 7863 7864 7865 7866 7867 The Transmitter of a TLP with a data payload must not allow the data payload length as given by the TLP's Length field to exceed the length specified by the value in the Max_Payload_Size field of the Transmitter's Device Control register taken as an integral number of DW (see Section 7.5.3.4 Device Control Register (Offset 08h) ). For ARI Devices, the Max_Payload_Size is determined solely by the setting in Function 0. The Max_Payload_Size settings in other Functions are ignored. For an Upstream Port associated with a non-ARI MultiFunction Device (MFD) whose Max_Payload_Size settings are identical across all Functions, a transmitted TLP's data payload must not exceed the common Max_Payload_Size setting. For an Upstream Port associated with a non-ARI MFD whose Max_Payload_Size settings are not identical across all Functions, a transmitted TLP's data payload must not exceed a Max_Payload_Size setting whose determination is implementation specific. Transmitter implementations are encouraged to use the Max_Payload_Size setting from the Function that generated the transaction, or else the smallest Max_Payload_Size setting across all Functions. Software should not set the Max_Payload_Size in different Functions to different values unless software is aware of the specific implementation. 7868 Note: Max_Payload_Size applies only to TLPs with data payloads; Memory Read Requests are not restricted in length by Max_Payload_Size. The size of the Memory Read Request is controlled by the Length field. 7100 7101 7858 7861 The Transmitter of a TLP with a data payload must not allow the data payload length as given by the TLP's Length field to exceed the length specified by the value in the Max_Payload_Size field of the Transmitter's Device Control register taken as an integral number of DW (see Section 7.5.3.4 Device Control Register (Offset 08h) ). For ARI Devices, the Max_Payload_Size is determined solely by the setting in Function 0. The Max_Payload_Size settings in other Functions are ignored. For an Upstream Port associated with a non-ARI MultiFunction Device (MFD) whose Max_Payload_Size settings are identical across all Functions, a transmitted TLP's data payload must not exceed the common Max_Payload_Size setting. For an Upstream Port associated with a non-ARI MultiFunction Device whose Max_Payload_Size settings are not identical across all Functions, a transmitted TLP's data payload must not exceed a Max_Payload_Size setting whose determination is implementation specific. Transmitter implementations are encouraged to use the Max_Payload_Size setting from the Function that generated the transaction, or else the smallest Max_Payload_Size setting across all Functions. Software should not set the Max_Payload_Size in different Functions to different values unless software is aware of the specific implementation. 7098 7099 2.2.2 TLPs with Data Payloads - Rules 7857 7091 7092 7856 7869 Note: Max_Payload_Size applies only to TLPs with data payloads; Memory Read Requests are not restricted in length by Max_Payload_Size. The size of the Memory Read Request is controlled by the Length field. 7870 The size of the data payload of a Received TLP as given by the TLP's Length field must not exceed the length specified by the value in the Max_Payload_Size field of the Receiver's Device Control register taken as an integral number of DW (see Section 7.5.3.4 Device Control Register (Offset 08h) ). Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, the TLP is a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 7104 Page 104 7871 7872 7873 7874 The size of the data payload of a Received TLP as given by the TLP's Length field must not exceed the length specified by the value in the Max_Payload_Size field of the Receiver's Device Control register taken as an integral number of DW (see Section 7.5.3.4 Device Control Register (Offset 08h) ). Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, the TLP is a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7104 7105 7106 7107 7108 7109 7874 For ARI Devices, the Max_Payload_Size is determined solely by the setting in Function 0. The Max_Payload_Size settings in other Functions are ignored. For an Upstream Port associated with a non-ARI MultiFunction Device whose Max_Payload_Size settings are identical across all Functions, the Receiver is required to check the TLP's data payload size against the common Max_Payload_Size setting. For an Upstream Port associated with a non-ARI MultiFunction Device whose Max_Payload_Size settings are not identical across all Functions, the Receiver is required to check the TLP's data payload against a Max_Payload_Size setting whose determination is implementation specific. Receiver implementations are encouraged to use the Max_Payload_Size setting from the Function targeted by the transaction, or else the largest Max_Payload_Size setting across all Functions. Software should not set the Max_Payload_Size in different Functions to different values unless software is aware of the specific implementation. 7110 7113 7114 7119 7122 Page 7879 7882 7883 7884 Receiver implementations are encouraged to use the Max_Payload_Size setting from the Function targeted by the transaction, or else the largest Max_Payload_Size setting across all Functions. Software should not set the Max_Payload_Size in different Functions to different values unless software is aware of the specific implementation. For TLPs, that include data, the value in the Length field and the actual amount of data included in the TLP must match. Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, the TLP is a Malformed TLP. This is a Reported Error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 7886 The value in the Length field applies only to data - the TLP Digest is not included in the Length When a data payload is included in a TLP other than an AtomicOp Request or an AtomicOp Completion, the first byte of data following the header corresponds to the byte address closest to zero and the succeeding bytes are in increasing byte address sequence. 7887 Example: For a 16-byte write to location 100h, the first byte following the header would be the byte to be written to location 100h, and the second byte would be written to location 101h, and so on, with the final byte written to location 10Fh. 7889 7120 7121 7878 7885 7116 7118 7877 7881 For TLPs, that include data, the value in the Length field and the actual amount of data included in the TLP must match. Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, the TLP is a Malformed TLP. This is a Reported Error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 7115 7117 7876 For ARI Devices, the Max_Payload_Size is determined solely by the setting in Function 0. The Max_Payload_Size settings in other Functions are ignored. For an Upstream Port associated with a non-ARI MFD whose Max_Payload_Size settings are identical across all Functions, the Receiver is required to check the TLP's data payload size against the common Max_Payload_Size setting. For an Upstream Port associated with a non-ARI MFD whose Max_Payload_Size settings are not identical across all Functions, the Receiver is required to check the TLP's data payload against a Max_Payload_Size setting whose determination is implementation specific. 7880 7111 7112 7875 7888 The value in the Length field applies only to data - the TLP Digest is not included in the Length When a data payload associated with a byte address is included in a TLP other than an AtomicOp Request or an AtomicOp Completion, the first byte of data following the header corresponds to the byte address closest to zero and the succeeding bytes are in increasing byte address sequence. Example: For a 16-byte write to location 100h, the first byte following the header would be the byte to be written to location 100h, and the second byte would be written to location 101h, and so on, with the final byte written to location 10Fh. 7890 The data payload in AtomicOp Requests and AtomicOp Completions must be formatted such that the first byte of data following the TLP header is the least significant byte of the first data value, and subsequent bytes of data are strictly increasing in significance. With Compare And Swap (CAS) Requests, the second data value immediately follows the first data value, and must be in the same format. The endian format used by AtomicOp Completers to read and write data at the target location is implementation specific, and is permitted to be whatever the Completer determines is appropriate for the target memory (e.g., little endian, big endian, etc.) Endian format capability reporting and controls for AtomicOp Completers are outside the 105 scope of this specification. 7891 7892 The data payload in AtomicOp Requests and AtomicOp Completions must be formatted such that the first byte of data following the TLP header is the least significant byte of the first data value, and subsequent bytes of data are strictly increasing in significance. With Compare And Swap (CAS) Requests, the second data value immediately follows the first data value, and must be in the same format. The endian format used by AtomicOp Completers to read and write data at the target location is implementation specific, and is permitted to be whatever the Completer determines is appropriate for the target memory (e.g., little endian, big endian, etc.) Endian format capability reporting and controls for AtomicOp Completers are outside the scope of this specification. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 7122 The endian format used by AtomicOp Completers to read and /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html write data at the target location is implementation specific, and is 7123 7124 permitted to be whatever the Completer determines is appropriate for the target memory (e.g., little endian, big endian, etc.) Endian format capability reporting and controls for AtomicOp Completers are outside the scope of this specification. Little endian example: For a 64-bit (8-byte) Swap Request targeting location 100h with the target memory in little endian format, the first byte following the header is written to location 100h, the second byte is written to location 101h, and so on, with the final byte written to location 107h. Note that before performing the writes, the Completer first reads the target memory locations so it can return the original value in the Completion. The byte address correspondence to the data in the Completion is identical to that in the Request. Big endian example: For a 64-bit (8-byte) Swap Request targeting location 100h with the target memory in big endian format, the first byte following the header is written to location 107h, the second byte is written to location 106h, and so on, with the final byte written to location 100h. Note that before performing the writes, the Completer first reads the target memory locations so it can return the original value in the Completion. The byte address correspondence to the data in the Completion is identical to that in the Request. 7125 7126 7892 7893 7894 7895 Figure 2-6 Examples of Completer Target Memory Access for FetchAdd shows little endian and big endian examples of Completer target memory access for a 64-bit (8-byte) FetchAdd. The bytes in the operands and results are numbered 0-7, with byte 0 being least significant and byte 7 being most significant. In each case, the Completer fetches the target memory operand using the appropriate endian format. Next, AtomicOp compute logic in the Completer performs the FetchAdd operation using the original target memory value and the “add” value from the FetchAdd Request. Finally, the Completer stores the FetchAdd result back to target memory using the same endian format used for the fetch. 7896 7127 7897 7128 7898 7185 7955 7186 2.2.4.1 Address-Based Routing Rules 7188 7190 Figure 2-6 Examples of Completer Target Memory Access for FetchAdd shows little endian and big endian examples of Completer target memory access for a 64-bit (8-byte) FetchAdd. The bytes in the operands and results are numbered 0-7, with byte 0 being least significant and byte 7 being most significant. In each case, the Completer fetches the target memory operand using the appropriate endian format. Next, AtomicOp compute logic in the Completer performs the FetchAdd operation using the original target memory value and the “add” value from the FetchAdd Request. Finally, the Completer stores the FetchAdd result back to target memory using the same endian format used for the fetch. 7956 7187 7189 The endian format used by AtomicOp Completers to read and write data at the target location is implementation specific, and is permitted to be whatever the Completer determines is appropriate for the target memory (e.g., little endian, big endian, etc.) Endian format capability reporting and controls for AtomicOp Completers are outside the scope of this specification. Little endian example: For a 64-bit (8-byte) Swap Request targeting location 100h with the target memory in little endian format, the first byte following the header is written to location 100h, the second byte is written to location 101h, and so on, with the final byte written to location 107h. Note that before performing the writes, the Completer first reads the target memory locations so it can return the original value in the Completion. The byte address correspondence to the data in the Completion is identical to that in the Request. Big endian example: For a 64-bit (8-byte) Swap Request targeting location 100h with the target memory in big endian format, the first byte following the header is written to location 107h, the second byte is written to location 106h, and so on, with the final byte written to location 100h. Note that before performing the writes, the Completer first reads the target memory locations so it can return the original value in the Completion. The byte address correspondence to the data in the Completion is identical to that in the Request. 7957 2.2.4.1 Address-Based Routing Rules 7958 Address routing is used with Memory and I/O Requests. Two address formats are specified, a 64-bit format used with a 4 DW header (see Figure 2-7 64-bit Address Routing ) and a 32-bit format used with a 3 DW header (see Figure 2-8 32-bit Address Routing ). 7959 7960 7191 7961 7192 7962 7193 7963 7194 7964 Address routing is used with Memory and I/O Requests. Two address formats are specified, a 64-bit format used with a 4 DW header (see Figure 2-7 64-bit Address Routing ) and a 32-bit format used with a 3 DW header (see Figure 2-8 32-bit Address Routing ). 7195 7196 7197 Figure 2-7 64-bit Address Routing 7965 7198 7966 7199 7967 Page 106 Figure 2-7 64-bit Address Routing /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7199 7967 7200 7968 7201 7969 7202 7970 7203 7204 7205 Figure 2-8 32-bit Address Routing 7206 7973 For Memory Read, Memory Write, and AtomicOp Requests, the Address Type (AT) field is encoded as shown in Table 10-1 Address Type (AT) Field Encodings . For all other Requests, the AT field is Reserved unless explicitly stated otherwise. LN Reads and LN Writes have special requirements. See Section 6.21.5 LN Protocol Summary . 7974 7975 7209 Address mapping to the TLP header is shown in Table 2-5 Address Field Mapping . 7976 7210 7977 7211 7978 7212 Table 2-5 Address Field Mapping 7214 7980 Address Bits 7216 7982 32-bit Addressing 7984 7218 7985 7302 8069 7303 8070 7304 8071 7305 8072 7306 8073 7307 32-bit Addressing 8074 7308 2.2.4.2 ID Based Routing Rules 7309 7313 Address Bits 7983 7217 7312 Table 2-5 Address Field Mapping 7981 7215 7311 For Memory Read, Memory Write, and AtomicOp Requests, the Address Type (AT) field is encoded as shown in Table 10-1 Address Type (AT) Field Encodings . For all other Requests, the AT field is Reserved unless explicitly stated otherwise. LN Reads and LN Writes have special requirements. See Section 6.21.5 LN Protocol Summary . If TH is Set, the PH field is encoded as shown in Table 2-15 Processing Hint Encoding . If TH is Clear, the PH field is Reserved. Address mapping to the TLP header is shown in Table 2-5 Address Field Mapping . 7979 7213 7310 Figure 2-8 32-bit Address Routing 7972 7207 7208 7971 8075 2.2.4.2 ID Based Routing Rules 8076 ID routing is used with Configuration Requests, with ID Routed Messages, and with Completions. This specification defines several Messages that are ID Routed ( Table F-1 Message Code Usage ). Other specifications are permitted to define additional ID Routed Messages. ID routing uses the Bus, Device, and Function Numbers (as applicable) to specify the destination for the TLP: For non-ARI Routing IDs, Bus, Device, and (3-bit) Function Number to TLP header mapping is shown in . For ARI Routing IDs, the Bus and (8-bit) Function Number to TLP header mapping is shown in . 8077 8078 8079 8080 7314 Page 107 8081 ID routing is used with Configuration Requests, with ID Routed Messages, and with Completions. This specification defines several Messages that are ID Routed ( Table F-1 Message Code Usage ). Other specifications are permitted to define additional ID Routed Messages. ID routing uses the Bus, Device, and Function Numbers (as applicable) to specify the destination for the TLP: For non-ARI Routing IDs, Bus, Device, and (3-bit) Function Number to TLP header mapping is shown in Table 2-6 Header Field Locations for non-ARI ID Routing , Figure 2-9 Non-ARI ID Routing with 4 DW Header , and Figure 2-11 Non-ARI ID Routing with 3 DW Header . For ARI Routing IDs, the Bus and (8-bit) Function Number to TLP header mapping is shown in Table 2-7 Header Field Locations for ARI ID Routing , Figure 2-10 ARI ID Routing with 4 DW Header , and Figure 2-12 ARI ID Routing with 3 DW Header . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7314 7315 7316 8081 Two ID routing formats are specified, one used header (see Figure 2-9 ID Routing with 4 DW Header ) and one 3 DW header (see Figure 2-10 ID Routing with 3 DW Header ). Header field locations are the same for both are given in Table 2-6 Header Field Locations for non-ARI ID Table 2-6 Header Field Locations for non-ARI ID Routing . with a 4 DW used with a 8082 formats, and Routing and 8083 7317 8084 7318 8085 7319 8086 7320 Two ID routing formats are specified, one used with a 4 DW header (see Figure 2-9 Non-ARI ID Routing with 4 DW Header and Figure 2-10 ARI ID Routing with 4 DW Header ) and one used with a 3 DW header (see Figure 2-12 ARI ID Routing with 3 DW Header and Figure 2-10 ARI ID Routing with 4 DW Header ). Header field locations are the same for both formats (see Figure 2-5 Fields Present in All TLP Headers ). 8087 7321 Table 2-6 Header Field Locations for non-ARI ID 8088 Routing 7322 7323 8089 Field 7324 7325 Header Location Field 8092 Header Location 8093 Function Number[7:0] 7365 7366 8090 8091 7326 7364 Table 2-6 Header Field Locations for non-ARI ID Routing 8131 Function Number[7:0] 8132 Bits 7:0 of Byte 9 8133 7367 8134 7368 8135 7369 8136 7370 8137 7371 8138 7372 8139 7373 8140 8141 Bits 7:0 of Byte 9 Figure 2-9 Non-ARI ID Routing with 4 DW Header 8142 8143 7374 8144 7375 7376 8145 Figure 2-9 ID Routing with 4 DW Header 7377 8146 8147 7378 8148 7379 8149 7380 8150 7381 8151 7382 8152 8153 7383 7384 Figure 2-10 ARI ID Routing with 4 DW Header Figure 2-11 Non-ARI ID Routing with 3 DW Header 8154 Figure 2-10 ID Routing with 3 DW Header 8155 8156 8157 8158 8159 7385 8160 7386 8161 Page 108 Figure 2-12 ARI ID Routing with 3 DW Header /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7386 8161 7387 8162 7388 8163 7389 8164 7390 8165 7391 8166 2.2.5 First/Last DW Byte Enables Rules 7392 7393 7394 8168 Byte Enables are included with Memory, I/O, and Configuration Requests. This section defines the corresponding rules. Byte Enables, when present in the Request header, are located in byte 7 of the header (see Figure 2-11 Location of Byte Enables in TLP Header ). For Memory Read Requests that have the TH bit Set, the Byte Enable fields are repurposed to carry the ST[7:0] field (refer to Section 2.2.7.1 TPH Rules for details), and values for the Byte Enables are implied as defined below. The TH bit must only be Set in Memory Read Requests when it is acceptable to complete those Requests as if all bytes for the requested data were enabled. 7395 7396 7397 7398 8169 Byte Enables are included with Memory, I/O, and Configuration Requests. This section defines the corresponding rules. Byte Enables, when present in the Request header, are located in byte 7 of the header (see Figure 2-13 Location of Byte Enables in TLP Header ). For Memory Read Requests that have the TH bit Set, the Byte Enable fields are repurposed to carry the ST[7:0] field (refer to Section 2.2.7.1 TPH Rules for details), and values for the Byte Enables are implied as defined below. The TH bit must only be Set in Memory Read Requests when it is acceptable to complete those Requests as if all bytes for the requested data were enabled. 8170 For Memory Read Requests that have the TH bit Set, the following values are implied for the Byte Enables. See Section 2.2.7 Memory, I/O, and Configuration Request Rules for additional requirements. If the Length field for this Request indicates a length of 1 DW, then the value for the 1st DW Byte Enables is implied to be 1111b and the value for the Last DW Byte Enables is implied to be 0000b. If the Length field for this Request indicates a length of greater than 1 DW, then the value for the 1st DW Byte Enables and the Last DW Byte Enables is implied to be 1111b. 8171 8172 8173 7399 8174 7400 8175 7401 8176 7402 For Memory Read Requests that have the TH bit Set, the following values are implied for the Byte Enables. See Section 2.2.7 Memory, I/O, and Configuration Request Rules for additional requirements. If the Length field for this Request indicates a length of 1 DW, then the value for the First DW Byte Enables is implied to be 1111b and the value for the Last DW Byte Enables is implied to be 0000b. If the Length field for this Request indicates a length of greater than 1 DW, then the value for the First DW Byte Enables and the Last DW Byte Enables is implied to be 1111b. 8177 7403 Implementation Note Read Request with TPH to Non-Prefetchable Space 7404 8178 8179 7405 8180 7406 8181 7407 7408 2.2.5 First/Last DW Byte Enables Rules 8167 Implementation Note Read Request with TPH to Non-Prefetchable Space 8182 Memory Read Requests with the TH bit Set Non-Prefetchable Memory Space should only be issued when guaranteed that completion of such reads will not create effects. See for consideration of certain BARs that may Prefetchable bit Set even though they map some locations effects. and that target it can be undesirable side have the with read side- 8183 7409 8184 7410 8185 7411 8186 7412 8187 7413 8188 7414 7415 Page 109 Memory Read Requests with the TH bit Set and that target Non-Prefetchable Memory Space should only be issued when it can be guaranteed that completion of such reads will not create undesirable side effects. See Section 7.5.1.2.1 Base Address Registers (Offset 10h - 24h) for consideration of certain BARs that may have the Prefetchable bit Set even though they map some locations with read side-effects. 8189 Figure 2-11 Location of Byte Enables in TLP Header 8190 Figure 2-13 Location of Byte Enables in TLP Header /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7415 Figure 2-11 Location of Byte Enables in TLP Header 7416 7419 8192 The 1st DW BE[3:0] field contains Byte Enables for the first (or only) DW referenced by a Request. If the Length field for a Request indicates a length of greater than 1 DW, this field must not equal 0000b. 7420 7421 7422 7423 7426 7427 7430 7433 7434 8196 8197 8198 8200 8201 8202 For each bit of the Byte Enables fields: a value of 0b indicates that the corresponding byte of data must not be written or, if non-prefetchable, must not be read at the Completer. a value of 1b indicates that the corresponding byte of data must be written or read at the Completer. 8204 8205 Non-contiguous Byte Enables (enabled bytes separated by nonenabled bytes) are permitted in the First DW BE field for all Requests with length of 1 DW. Non-contiguous Byte Enable examples: 1010b, 0101b, 1001b, 1011b, 1101b 8206 Non-contiguous Byte Enables are permitted in both Byte Enables fields for Quad Word (QW) aligned Memory Requests with length of 2 DW (1 QW). All non-QW aligned Memory Requests with length of 2 DW (1 QW) and Memory Requests with length of 3 DW or more must enable only bytes that are contiguous with the data between the first and last DW of the Request. Contiguous Byte Enables examples: 7435 8207 8208 8209 Non-contiguous Byte Enables are permitted in both Byte Enables fields for Quad Word (QW) aligned Memory Requests with length of 2 DW (1 QW). All non-QW aligned Memory Requests with length of 2 DW (1 QW) and Memory Requests with length of 3 DW or more must enable only bytes that are contiguous with the data between the first and last DW of the Request. Contiguous Byte Enables examples: 8210 7436 1st DW BE: 1100b, Last DW BE: 0011b 7437 8211 First DW BE: 1100b, Last DW BE: 0011b 8212 7438 8213 7439 1st DW BE: 1000b, Last DW BE: 0111b 8214 7440 8215 7441 8216 7442 7443 The Last DW BE[3:0] field contains Byte Enables for the last DW of a Request. If the Length field for a Request indicates a length of 1 DW, this field must equal 0000b. If the Length field for a Request indicates a length of greater than 1 DW, this field must not equal 0000b. 8203 Non-contiguous Byte Enables (enabled bytes separated by nonenabled bytes) are permitted in the 1st DW BE field for all Requests with length of 1 DW. Non-contiguous Byte Enable examples: 1010b, 0101b, 1001b, 1011b, 1101b 7431 7432 8194 The First DW BE[3:0] field contains Byte Enables for the first (or only) DW referenced by a Request. If the Length field for a Request indicates a length of greater than 1 DW, this field must not equal 0000b. 8199 For each bit of the Byte Enables fields: a value of 0b indicates that the corresponding byte of data must not be written or, if non-prefetchable, must not be read at the Completer. a value of 1b indicates that the corresponding byte of data must be written or read at the Completer. 7428 7429 8193 8195 The Last DW BE[3:0] field contains Byte Enables for the last DW of a Request. If the Length field for a Request indicates a length of 1 DW, this field must equal 0000b. If the Length field for a Request indicates a length of greater than 1 DW, this field must not equal 0000b. 7424 7425 Figure 2-13 Location of Byte Enables in TLP Header 8191 7417 7418 8190 First DW BE: 1000b, Last DW BE: 0111b 8217 Table 2-8 Byte Enables Location and Correspondence shows the correspondence between the bits of the Byte Enables fields, their location in the Request header, and the corresponding bytes of the referenced data. 8218 7444 8219 7445 8220 7446 7447 Page 110 Table 2-8 Byte Enables Location and Correspondence shows the correspondence between the bits of the Byte Enables fields, their location in the Request header, and the corresponding bytes of the referenced data. 8221 Table 2-8 Byte Enables Location and Correspondence 8222 Table 2-8 Byte Enables Location and Correspondence /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7447 Table 2-8 Byte Enables Location and Correspondence 7448 Table 2-8 Byte Enables Location and Correspondence 8223 7449 Byte Enables 7450 8224 Byte Enables 8225 7451 Header Location 7452 7453 8222 8226 Header Location 8227 Affected Data Byte [Footnote: Assuming the data referenced is N bytes in length (Byte 0 to Byte N-1). Note that last DW Byte Enables are used only if the data length is greater than one DW.] 8228 7454 8229 7455 8230 7456 7457 8231 1st DW BE[0] 7458 7459 8232 Bit 0 of Byte 7 8234 Byte 0 8236 8237 7463 8238 7464 8240 Bit 1 of Byte 7 8242 Byte 1 8244 8245 7471 8246 7472 8248 Bit 2 of Byte 7 8250 Byte 2 8252 8253 7479 8254 7480 8256 Bit 3 of Byte 7 8258 Byte 3 8260 8261 7487 8262 7488 7527 8264 Last DW BE[0] 8265 Bit 4 of Byte 7 Zero-Length Write 8266 8302 7528 8303 7529 8304 Page 111 Byte 3 8263 Last DW BE[0] 7490 7491 Bit 3 of Byte 7 8259 7486 7489 First DW BE[3] 8257 7484 7485 Byte 2 8255 1st DW BE[3] 7482 7483 Bit 2 of Byte 7 8251 7478 7481 First DW BE[2] 8249 7476 7477 Byte 1 8247 1st DW BE[2] 7474 7475 Bit 1 of Byte 7 8243 7470 7473 First DW BE[1] 8241 7468 7469 Byte 0 8239 1st DW BE[1] 7466 7467 Bit 0 of Byte 7 8235 7462 7465 First DW BE[0] 8233 7460 7461 Affected Data Byte [Footnote: Assuming the data referenced is N bytes in length (Byte 0 to Byte N-1). Note that last DW Byte Enables are used only if the data length is greater than one DW.] Bit 4 of Byte 7 Zero-Length Write /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7529 8304 7530 7531 8305 A Memory Write Request of 1 DW with no bytes enabled, or “zero-length Write,” may be used by devices under certain protocols, in order to achieve an intended side effect. One example is LN protocol. See Section 6.21 Lightweight Notification (LN) Protocol . 8306 7532 8307 7533 8308 7534 8309 7535 8310 7536 7537 8311 If a Read Request of 1 DW specifies that no bytes are enabled to be read (1st DW BE[3:0] field = 0000b), the corresponding Completion must specify a Length of 1 DW, and include a data payload of 1 DW 7538 7543 7544 If a Read Request of 1 DW specifies that no bytes are enabled to be read (First DW BE[3:0] field = 0000b), the corresponding Completion must specify a Length of 1 DW, and include a data payload of 1 DW 8314 The contents of the data payload within the Completion packet is unspecified and may be any value 7541 7542 8312 8313 7539 7540 A Memory Write Request of 1 DW with no bytes enabled, or “zero-length Write,” may be used by devices under certain protocols, in order to achieve an intended side effect. One example is LN protocol. See Section 6.21 Lightweight Notification (LN) Protocol . 8315 The contents of the data payload within the Completion packet is unspecified and may be any value. 8316 Receiver/Completer behavior is undefined for a TLP violating the Byte Enables rules specified in this section. Receivers may optionally check for violations of the Byte Enables rules specified in this section. If a Receiver implementing such checks determines that a TLP violates one or more Byte Enables rules, the TLP is a Malformed TLP. These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If Byte Enables rules are checked, a violation is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8317 8318 8319 7545 8320 7546 8321 7547 8322 7548 Receiver/Completer behavior is undefined for a TLP violating the Byte Enables rules specified in this section. Receivers may optionally check for violations of the Byte Enables rules specified in this section. If a Receiver implementing such checks determines that a TLP violates one or more Byte Enables rules, the TLP is a Malformed TLP. These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If Byte Enables rules are checked, a violation is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8323 7549 8324 7550 Implementation Note Zero-Length Read 8325 Implementation Note Zero-Length Read 7568 2.2.6.1 Overview 8343 2.2.6.1 Overview 7569 8344 7570 7571 8345 The Transaction Descriptor is a mechanism for carrying Transaction information between the Requester and the Completer. Transaction Descriptors are composed of three fields: 7572 8346 8347 7573 Transaction ID - identifies outstanding Transactions Attributes field - specifies characteristics of the 7574 8348 Traffic Class (TC) field - associates Transaction with type of required service 7576 Page Transaction 8350 Traffic Class (TC) field - associates Transaction with type of required service 8351 7577 7578 Transaction ID - identifies outstanding Transactions Attributes field - specifies characteristics of the 8349 Transaction 7575 The Transaction Descriptor is a mechanism for carrying Transaction information between the Requester and the Completer. Transaction Descriptors are composed of three fields: 8352 Figure 2-12 Transaction Descriptor shows the fields of the Transaction Descriptor. Note that these fields are shown together to highlight their relationship as parts of a single logical entity. The 112 fields are not contiguous in the packet header. 8353 Figure 2-14 Transaction Descriptor shows the fields of the Transaction Descriptor. Note that these fields are shown together to highlight their relationship as parts of a single logical entity. The fields are not contiguous in the packet header. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7578 Figure 2-12 Transaction Descriptor shows the fields of the Transaction Descriptor. Note that these fields are shown together to highlight their relationship as parts of a single logical entity. The fields are not contiguous in the packet header. 8353 Figure 2-14 Transaction Descriptor shows the fields of the Transaction Descriptor. Note that these fields are shown together to highlight their relationship as parts of a single logical entity. The fields are not contiguous in the packet header. 7579 7580 8354 7581 8355 7582 8356 7583 8357 7584 7585 8358 7586 8359 7587 8360 7588 8361 7589 8362 7590 7591 8363 2.2.6.2 Transaction Descriptor - Transaction ID Field 7592 8364 2.2.6.2 Transaction Descriptor - Transaction ID Field 8365 7593 7594 Figure 2-14 Transaction Descriptor Figure 2-12 Transaction Descriptor 8366 The Transaction ID field consists of two major sub-fields: Requester ID and Tag as shown in Figure 2-13 Transaction ID . 8367 The Transaction ID field consists of two major sub-fields: Requester ID and Tag as shown in Figure 2-15 Transaction ID . 7595 7596 8368 7597 8369 7598 8370 7599 8371 8372 7600 7601 Figure 2-13 Transaction ID 7602 8374 7603 8375 7604 7605 8376 10-Bit Tag capability, introduced in PCI Express Base Specification, Revision 4.0, increases the total Tag field size from 8 bits to 10 bits. The two additional Tag bits, Tag[8] and Tag[9] , are not contiguous with other Tag[7:0] bits in the TLP Header. The two additional bits were Reserved in previous versions of this specification. 7606 7607 7608 7609 Page Figure 2-15 Transaction ID 8373 10-Bit Tag capability, introduced in [PCIe-4.0] increases the total Tag field size from 8 bits to 10 bits. The two additional Tag bits, Tag[8] (T8) and Tag[9] (T9), are not contiguous with other Tag[7:0] bits in the TLP Header. The two additional bits were Reserved in previous versions of this specification. 8377 Tag[9:0] is a 10-bit field generated by each Requester, and it must be unique for all outstanding Requests that require a Completion for that Requester. Requesters that do not support 10-Bit Tag Requester capability must set Tag[9:8] to 00b. Functions [Footnote: An exception is PCI Express to PCI/ PCI-X Bridges, since 10-Bit Tag capability is not architected for these Functions.] (including those in Switches) that support 16.0 GT/s data rates or greater must support 10-Bit Tag Completer capability. If a Function supports 10-Bit Tag Completer capability, it may optionally support 10-Bit Tag Requester capability. See Section 7.5.3.15 Device Capabilities 2 Register (Offset 24h) and the "Considerations for Implementing 10-Bit Tag Capabilities" Implementation Note later in this section. RCs containing elements that indicate support for 10Bit Tag Completer capability must handle 10-Bit Tag Requests correctly by 113 all registers and memory regions supported as targets of PCIe Requesters; e.g., host memory targeted by DMA Requests or MMIO regions in RCiEPs. 8378 8379 8380 Tag[9:0] is a 10-bit field generated by each Requester, and it must be unique for all outstanding Requests that require a Completion for that Requester. Requesters that do not support 10-Bit Tag Requester capability must set Tag[9:8] to 00b. Functions [Footnote: An exception is PCI Express to PCI/ PCI-X Bridges, since 10-Bit Tag capability is not architected for these Functions.] (including those in Switches) that support 16.0 GT/s data rates or greater must support 10-Bit Tag Completer capability. If a Function supports 10-Bit Tag Completer capability, it may optionally support 10-Bit Tag Requester capability. See Section 7.5.3.15 Device Capabilities 2 Register (Offset 24h) and the "Considerations for Implementing 10-Bit Tag Capabilities" Implementation Note later in this section. RCs containing elements that indicate support for 10Bit Tag Completer capability must handle 10-Bit Tag Requests correctly by all registers and memory regions supported as targets of PCIe Requesters; e.g., host memory targeted by DMA Requests or MMIO regions in RCiEPs. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7609 7610 7611 RCs containing elements that indicate support for 10Bit Tag Completer capability must handle 10-Bit Tag Requests correctly by all registers and memory regions supported as targets of PCIe Requesters; e.g., host memory targeted by DMA Requests or MMIO regions in RCiEPs. Each RP indicating support must handle such Requests received by its Ingress Port. Each RCiEP indicating support must handle such Requests coming from supported internal paths, including those coming through RPs. 7612 7613 7614 7615 7619 7620 7621 7622 7623 Page 8380 8381 8382 RCs containing elements that indicate support for 10Bit Tag Completer capability must handle 10-Bit Tag Requests correctly by all registers and memory regions supported as targets of PCIe Requesters; e.g., host memory targeted by DMA Requests or MMIO regions in RCiEPs. Each RP indicating support must handle such Requests received by its Ingress Port. Each RCiEP indicating support must handle such Requests coming from supported internal paths, including those coming through RPs. 8383 If an RC contains RCiEPs that indicate support for 10Bit Tag Requester capability, the RC must handle 10-Bit Tag Requests from those RCiEPs correctly by all registers and memory regions supported as targets of those RCiEPs; e.g., host memory targeted by DMA Requests or MMIO regions in RCiEPs. Receivers/Completers must handle 8-bit Tag values correctly regardless of the setting of their Extended Tag Field Enable bit (see Section 7.5.3.4 Device Control Register (Offset 08h) ). Refer to the PCI Express to PCI/PCI-X Bridge Specification for details on the bridge handling of extended tags. Receivers/Completers that support 10-Bit Tag Completer capability must handle 10-Bit Tag values correctly, regardless of their 10-Bit Tag Requester Enable bit setting. See Section 7.5.3.16 Device Control 2 Register (Offset 28h) . 8384 If the 10-Bit Tag Requester Enable bit is Set, the maximum targeting a single Completer is increased up to 768. The Requester is permitted to use all 10 bits of the Tag field when sending 10-Bit Tag Requests to Completers it deems suitable, though the Requester is still permitted to send smaller-Tag Requests to other Completers. The following apply to 10-Bit Tag capable Requesters whose 10-Bit Tag Requester Enable bit is Set. If an Endpoint [Footnote: This includes PCI Express Endpoints, Legacy PCI Express Endpoints, and Root Complex Integrated Endpoints.] supports sending Requests to other Endpoints (as opposed to host memory), the Endpoint must not send 10-Bit Tag Requests to another given Endpoint unless an implementation-specific mechanism determines that the Endpoint supports 10-Bit Tag Completer capability. Not sending 10-Bit Tag Requests to other Endpoints at all may be acceptable for some implementations. More sophisticated mechanisms are outside the scope of this specification. If a PIO Requester has 10-Bit Tag Requester capability, how the Requester determines when to use 10-Bit Tags versus smaller Tags is outside the scope of this specification. With 10-Bit Tags, valid Tag[9:8] values are 01b, 10b, or 11b. 10-Bit Tag values with Tag[9:8] equal to 00b are invalid, and must not be generated by the Requester. This enables a Requester to determine if a Completion it receives that should have a 10-Bit Tag contains an invalid one, usually caused by the Completer not supporting 10-Bit Tag Completer capability. If a Requester sends a 10-Bit Tag Request to a Completer that lacks 10-Bit Completer capability, the returned Completion(s) will have Tags with Tag[9:8] equal to 00b. Since the 114 Requester is forbidden to generate these Tag values for 10-Bit Tags, such Completions will be handled as Unexpected Completions [Footnote: If a Completion has a higher precedence error, that error should be reported instead.] , which by default are Advisory Non-Fatal Errors. The Requester must follow standard PCI Express error handling requirements. 8390 8385 8386 8391 8392 8393 8394 If an RC contains RCiEPs that indicate support for 10Bit Tag Requester capability, the RC must handle 10-Bit Tag Requests from those RCiEPs correctly by all registers and memory regions supported as targets of those RCiEPs; e.g., host memory targeted by DMA Requests or MMIO regions in RCiEPs. Receivers/Completers must handle 8-bit Tag values correctly regardless of the setting of their Extended Tag Field Enable bit (see Section 7.5.3.4 Device Control Register (Offset 08h) ). Refer to the PCI Express to PCI/PCI-X Bridge Specification for details on the bridge handling of extended tags. Receivers/Completers that support 10-Bit Tag Completer capability must handle 10-Bit Tag values correctly, regardless of their 10-Bit Tag Requester Enable bit setting. See Section 7.5.3.16 Device Control 2 Register (Offset 28h) . If the 10-Bit Tag Requester Enable bit is Set, the maximum targeting a single Completer is increased up to 768. The Requester is permitted to use all 10 bits of the Tag field when sending 10-Bit Tag Requests to Completers it deems suitable, though the Requester is still permitted to send smaller-Tag Requests to other Completers. The following apply to 10-Bit Tag capable Requesters whose 10-Bit Tag Requester Enable bit is Set. If an Endpoint [Footnote: This includes PCI Express Endpoints, Legacy PCI Express Endpoints, and Root Complex Integrated Endpoints.] supports sending Requests to other Endpoints (as opposed to host memory), the Endpoint must not send 10-Bit Tag Requests to another given Endpoint unless an implementation-specific mechanism determines that the Endpoint supports 10-Bit Tag Completer capability. Not sending 10-Bit Tag Requests to other Endpoints at all may be acceptable for some implementations. More sophisticated mechanisms are outside the scope of this specification. If a PIO Requester has 10-Bit Tag Requester capability, how the Requester determines when to use 10-Bit Tags versus smaller Tags is outside the scope of this specification. With 10-Bit Tags, valid Tag[9:8] values are 01b, 10b, or 11b. 10-Bit Tag values with Tag[9:8] equal to 00b are invalid, and must not be generated by the Requester. This enables a Requester to determine if a Completion it receives that should have a 10-Bit Tag contains an invalid one, usually caused by the Completer not supporting 10-Bit Tag Completer capability. If a Requester sends a 10-Bit Tag Request to a Completer that lacks 10-Bit Completer capability, the returned Completion(s) will have Tags with Tag[9:8] equal to 00b. Since the Requester is forbidden to generate these Tag values for 10-Bit Tags, such Completions will be handled as Unexpected Completions [Footnote: If a Completion has a higher precedence error, that error should be reported instead.] , which by default are Advisory Non-Fatal Errors. The Requester must follow standard PCI Express error handling requirements. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7623 7624 7625 7626 If a Requester sends a 10-Bit Tag Request to a Completer that lacks 10-Bit Completer capability, the returned Completion(s) will have Tags with Tag[9:8] equal to 00b. Since the Requester is forbidden to generate these Tag values for 10-Bit Tags, such Completions will be handled as Unexpected Completions [Footnote: If a Completion has a higher precedence error, that error should be reported instead.] , which by default are Advisory Non-Fatal Errors. The Requester must follow standard PCI Express error handling requirements. When a Requester handles a Completion with an invalid 10-Bit Tag as an Unexpected Completion, the original Request will likely incur a Completion Timeout. If the Requester handles the Completion Timeout condition in some device-specific manner that avoids data corruption, the Requester is permitted to suppress handling the Completion Timeout by standard PCI Express error handling mechanisms as required otherwise. If a Requester supports sending 10-Bit Tag Requests to some Completers and smaller-Tag Requests to other Completers concurrently, the Requester must honor the Extended Tag Field Enable bit setting for the smaller-Tag Requests. That is, if the bit is Clear, only the lower 5 bits of the Tag field may be non-zero; if the bit is Set, only the lower 8 bits of the Tag field may be non-zero. If a Requester supports sending 10-Bit Tag Requests to some Completers and smaller-Tag Requests to other Completers concurrently, the Requester must ensure that no outstanding 10-Bit Tags can alias to an outstanding smaller Tag if any 10-Bit Tag Request is completed by a Completer that lacks 10-Bit Tag Completer capability. See the "Using 10-Bit Tags and Smaller Tags Concurrently" Implementation Note later in this section. 7627 7628 7629 7630 7633 7634 7635 8395 8396 8397 If a Requester sends a 10-Bit Tag Request to a Completer that lacks 10-Bit Completer capability, the returned Completion(s) will have Tags with Tag[9:8] equal to 00b. Since the Requester is forbidden to generate these Tag values for 10-Bit Tags, such Completions will be handled as Unexpected Completions [Footnote: If a Completion has a higher precedence error, that error should be reported instead.] , which by default are Advisory Non-Fatal Errors. The Requester must follow standard PCI Express error handling requirements. When a Requester handles a Completion with an invalid 10-Bit Tag as an Unexpected Completion, the original Request will likely incur a Completion Timeout. If the Requester handles the Completion Timeout condition in some device-specific manner that avoids data corruption, the Requester is permitted to suppress handling the Completion Timeout by standard PCI Express error handling mechanisms as required otherwise. If a Requester supports sending 10-Bit Tag Requests to some Completers and smaller-Tag Requests to other Completers concurrently, the Requester must honor the Extended Tag Field Enable bit setting for the smaller-Tag Requests. That is, if the bit is Clear, only the lower 5 bits of the Tag field may be non-zero; if the bit is Set, only the lower 8 bits of the Tag field may be non-zero. If a Requester supports sending 10-Bit Tag Requests to some Completers and smaller-Tag Requests to other Completers concurrently, the Requester must ensure that no outstanding 10-Bit Tags can alias to an outstanding smaller Tag if any 10-Bit Tag Request is completed by a Completer that lacks 10-Bit Tag Completer capability. See the "Using 10-Bit Tags and Smaller Tags Concurrently" Implementation Note later in this section. 8398 The default value of the Extended Tag Field Enable bit is implementation specific. The default value of the 10-Bit Tag Requester Enable bit is 0b. Receiver/Completer behavior is undefined if multiple uncompleted Requests are issued non-unique Tag values If Phantom Function Numbers are used to extend the number of outstanding requests, the combination of the Phantom Function Number and the Tag field must be unique for all outstanding Requests that require a Completion for that Requester. 7631 7632 8394 8399 8400 8401 The default value of the Extended Tag Field Enable bit is implementation specific. The default value of the 10-Bit Tag Requester Enable bit is 0b. Receiver/Completer behavior is undefined if multiple uncompleted Requests are issued non-unique Tag values. If Phantom Function Numbers are used to extend the number of outstanding requests, the combination of the Phantom Function Number and the Tag field must be unique for all outstanding Requests that require a Completion for that Requester. 8402 For Posted Requests, the Tag [9:8] field is Reserved. For Posted Requests with the TH bit Set, the Tag[7:0] field is repurposed for the ST[7:0] field (refer to Section 2.2.7.1 TPH Rules for details). For Posted Requests with the TH bit Clear, the Tag[7:0] field is undefined and may contain any value. (Refer to Table F-1 Message Code Usage for exceptions to this rule for certain Vendor_Defined Messages.) For Posted Requests with the TH field Clear, the value in the Tag[7:0] field must not affect Receiver processing of the Request For Posted Requests with the TH bit Set, the value in the ST[7:0] field may affect Completer processing of the Request (refer to 2.2.7.1 for details). 7636 Page 115 8403 8404 8405 8406 8407 For Posted Requests, the Tag [9:8] field is Reserved. For Posted Requests with the TH bit Set, the Tag[7:0] field is repurposed for the ST[7:0] field (refer to Section 2.2.7.1 TPH Rules for details). For Posted Requests with the TH bit Clear, the Tag[7:0] field is undefined and may contain any value. (Refer to Table F-1 Message Code Usage for exceptions to this rule for certain Vendor_Defined Messages.) For Posted Requests with the TH field Clear, the value in the Tag[7:0] field must not affect Receiver processing of the Request. For Posted Requests with the TH bit Set, the value in the ST[7:0] field may affect Completer processing of the Request (refer to 2.2.7.1 for details). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7636 7637 7638 7639 7640 8407 Requester ID and Tag combined form a global identifier, i.e., Transaction ID for each Transaction within a Hierarchy. Transaction ID is included with all Requests and Completions. The Requester ID is a 16-bit value that is unique for every PCI Express Function within a Hierarchy. Functions must capture the Bus and Device Numbers [Footnote: In ARI Devices, Functions are only required to capture the Bus Number. ARI Devices are permitted to retain the captured Bus Number on either a per-Device or a per-Function basis. If the captured Bus Number is retained on a per-Device basis, all Functions are required to update and use the common Bus Number.] supplied with all Type 0 Configuration Write Requests completed by the Function and supply these numbers in the Bus and Device Number fields of the Requester ID [Footnote: An ARI Requester ID does not contain a Device Number field. See Section 2.2.4.2 ID Based Routing Rules .] for all Requests initiated by the Device/ Function. It is recommended that Numbers are captured for successfully completed Requests only. 7641 7642 8416 Note that the Bus Number and Device Number [Footnote: With ARI Devices, only the Bus Number can change.] may be changed at run time, and so it is necessary to re-capture this information with each and every Configuration Write Request. 8419 It is recommended that Configuration Write Requests addressed to unimplemented Functions not affect captured Bus and Device Numbers. 8420 When generating Requests on their own behalf (for example, for error reporting), Switches must use the Requester ID associated with the primary side of the bridge logically associated with the Port (see Section 7.1 Configuration Topology ) causing the Request generation. Prior to the initial Configuration Write to a Function, the Function is not permitted to initiate Non-Posted Requests (A valid Requester ID is required to properly route the resulting completions). Exception: Functions within a Root Complex are permitted to initiate Requests prior to software-initiated configuration for accesses to system boot device(s). 7653 7654 Exception: The assignment of Bus and Device Numbers to the Devices within a Root Complex, and Device Numbers to the Downstream Ports within a Switch, may be done in an implementation specific way. 8418 It is recommended that Configuration Write Requests addressed to unimplemented Functions not affect captured Bus and Device Numbers. 7649 7652 8413 8417 7647 7651 8411 8415 Note that the Bus Number and Device Number [Footnote: With ARI Devices, only the Bus Number can change.] may be changed at run time, and so it is necessary to re-capture this information with each and every Configuration Write Request. 7646 7650 8410 8414 7644 7648 8409 Requester ID and Tag combined form a global identifier, i.e., Transaction ID for each Transaction within a Hierarchy. Transaction ID is included with all Requests and Completions. The Requester ID is a 16-bit value that is unique for every PCI Express Function within a Hierarchy. Functions must capture the Bus and Device Numbers [Footnote: In ARI Devices, Functions are only required to capture the Bus Number. ARI Devices are permitted to retain the captured Bus Number on either a per-Device or a per-Function basis. If the captured Bus Number is retained on a per-Device basis, all Functions are required to update and use the common Bus Number.] supplied with all Type 0 Configuration Write Requests completed by the Function and supply these numbers in the Bus and Device Number fields of the Requester ID [Footnote: An ARI Requester ID does not contain a Device Number field. See Section 2.2.4.2 ID Based Routing Rules .] for all Requests initiated by the Device/ Function. It is recommended that Numbers are captured for successfully completed Requests only. 8412 Exception: The assignment of Bus and Device Numbers to the Devices within a Root Complex, and Device Numbers to the Downstream Ports within a Switch, may be done in an implementation specific way. 7643 7645 8408 8421 8422 8423 When generating Requests on their own behalf (for example, for error reporting), Switches must use the Requester ID associated with the primary side of the bridge logically associated with the Port (see Section 7.1 Configuration Topology ) causing the Request generation. Prior to the initial Configuration Write to a Function, the Function is not permitted to initiate Non-Posted Requests. (A valid Requester ID is required to properly route the resulting completions .) Exception: Functions within a Root Complex are permitted to initiate Requests prior to software-initiated configuration for accesses to system boot device(s). 8424 Note that this rule and the exception are consistent with the existing PCI model for system initialization and configuration. 8425 7655 8426 7656 8427 Page 116 Note that this rule and the exception are consistent with the existing PCI model for system initialization and configuration. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7656 7657 7658 7659 8427 Each Function associated with a Device must be designed to respond to a unique Function Number for Configuration Requests addressing that Device. Note: Each non-ARI Device may contain up to eight Functions. Each ARI Device may contain up to 256 Functions. A Switch must forward Requests without modifying the Transaction ID In some circumstances, a PCI Express to PCI/PCI-X Bridge is required to generate Transaction IDs for requests it forwards from a PCI or PCI-X bus. 8428 8429 8430 7660 8431 7661 8432 7662 7663 7664 8433 Implementation Note Increasing the Number of Outstanding Requests using Phantom Functions 8434 8435 7665 8436 7666 8437 7667 7668 To increase the maximum possible number of outstanding Requests requiring Completion beyond that possible using Tag bits alone, a device may, if the Phantom Functions Enable bit is Set (see Section 7.5.3.4 Device Control Register (Offset 08h) ), use Function Numbers not assigned to implemented Functions to logically extend the Tag identifier. For a single-Function Device, this can allow up to an 8-fold increase in the maximum number of outstanding Requests. 8469 In configurations where a Requester with 10-Bit Tag Requester capability needs to target multiple Completers, one needs to ensure that the Requester sends 10-Bit Tag Requests only to Completers that have 10-Bit Tag Completer capability. This is greatly simplified if all Completers have this capability. 8470 7700 8471 For general industry enablement of 10-Bit Tags, it is highly recommended that all Functions [Footnote: An exception is PCI Express to PCI/PCI-X Bridges, since 10-Bit Tag capability is not architected for these Functions.] support 10-Bit Tag Completer capability. With new implementations, Completers that don't need to operate on higher numbers of NPRs concurrently themselves can generally track 10-Bit Tags internally and return them in Completions with modest incremental investment. 7702 8472 For general industry enablement of 10-Bit Tags, it is highly recommended that all Functions [Footnote: An exception is PCI Express to PCI/PCI-X Bridges, since 10-Bit Tag capability is not architected for these Functions.] support 10-Bit Tag Completer capability. With new implementations, Completers that don't need to operate on higher numbers of NPRs concurrently themselves can generally track 10-Bit Tags internally and return them in Completions with modest incremental investment. 8473 7703 7704 8439 8468 In configurations where a Requester with 10-Bit Tag Requester capability needs to target multiple Completers, one needs to ensure that the Requester sends 10-Bit Tag Requests only to Completers that have 10-Bit Tag Completer capability. This is greatly simplified if all Completers have this capability. 7699 7701 Implementation Note Increasing the Number of Outstanding Requests using Phantom Functions 8438 To increase the maximum possible number of outstanding Requests requiring Completion beyond that possible using Tag bits alone, a device may, if the Phantom Functions Enable bit is Set (see Section 7.5.3.4 Device Control Register (Offset 08h) ), use Function Numbers not assigned to implemented Functions to logically extend the Tag identifier. For a single-Function Device, this can allow up to an 8-fold increase in the maximum number of outstanding Requests. 7697 7698 Each Function associated with a Device must be designed to respond to a unique Function Number for Configuration Requests addressing that Device. Note: Each non-ARI Device may contain up to eight Functions. Each ARI Device may contain up to 256 Functions. A Switch must forward Requests without modifying the Transaction ID. In some circumstances, a PCI Express to PCI/PCI-X Bridge is required to generate Transaction IDs for requests it forwards from a PCI or PCI-X bus. 8474 Completers that actually process higher numbers of NPRs concurrently may require substantial additional hardware resources, but the full performance benefits of 10-Bit Tags generally can't be realized unless Completers actually do process higher numbers of NPRs concurrently. 8475 7705 8476 7706 8477 Page 117 Completers that actually process higher numbers of NPRs concurrently may require substantial additional hardware resources, but the full performance benefits of 10-Bit Tags generally can't be realized unless Completers actually do process higher numbers of NPRs concurrently. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7706 7707 8477 For platforms where the RC supports 10-Bit Tag Completer capability, it is highly recommended for platform firmware or operating software software that configures PCIe hierarchies to Set the 10-Bit Tag Requester Enable bit automatically in Endpoints with 10-Bit Tag Requester capability. This enables the important class of 10-Bit Tag capable adapters that send Memory Read Requests only to host memory. 7708 8480 For Endpoints other than RCiEPs, one can determine if the RC supports 10-Bit Tag Completer capability for each one by checking the 10-Bit Tag Completer Supported bit in its associated RP. RCiEPs have no associated RP, so for this reason they are not permitted to have their 10-Bit Tag Requester Supported bit Set unless the RC supports 10-Bit Tag Completer capability for them. Thus, software does not need to perform a separate check for RCiEPs. 7711 2.2.6.3 Transaction Descriptor - Attributes Field 8513 The Attributes field is used to provide additional information that allows modification of the default handling of Transactions. These modifications apply to different aspects of handling the Transactions within the system, such as: 7744 8514 The Attributes field is used to provide additional information that allows modification of the default handling of Transactions. These modifications apply to different aspects of handling the Transactions within the system, such as: 8515 Ordering Hardware coherency management (snoop) 7747 8516 8517 Ordering Hardware coherency management (snoop) 8518 7748 Page 8511 8512 7742 7749 For configurations where a Requester with 10-Bit Tag Requester capability targets Completers where some do and some do not have 10-Bit Tag Completer capability, how the Requester determines which NPRs include 10-Bit Tags is outside the scope of this specification. 8510 2.2.6.3 Transaction Descriptor - Attributes Field 7741 7746 8487 8488 7739 7745 Switches that lack 10-Bit Tag Completer capability are still able to forward NPRs and Completions carrying 10-Bit Tags correctly, since the two new Tag bits are in TLP Header bits that were formerly Reserved, and Switches are required to forward Reserved TLP Header bits without modification. However, if such a Switch detects an error with an NPR carrying a 10-Bit Tag, and that Switch handles the error by acting as the Completer for the NPR, the resulting Completion will have an invalid 10-Bit Tag. Thus, it is strongly recommended that Switches between any components using 10-Bit Tags support 10-Bit Tag Completer capability. Note that Switches supporting 16.0 GT/s data rates or greater must support 10-Bit Tag Completer capability. 8486 For configurations where a Requester with 10-Bit Tag Requester capability targets Completers where some do and some do not have 10-Bit Tag Completer capability, how the Requester determines which NPRs include 10-Bit Tags is outside the scope of this specification. 7717 7743 8484 8485 7715 7740 For Endpoints other than RCiEPs, one can determine if the RC supports 10-Bit Tag Completer capability for each one by checking the 10-Bit Tag Completer Supported bit in its associated RP. RCiEPs have no associated RP, so for this reason they are not permitted to have their 10-Bit Tag Requester Supported bit Set unless the RC supports 10-Bit Tag Completer capability for them. Thus, software does not need to perform a separate check for RCiEPs. 8483 Switches that lack 10-Bit Tag Completer capability are still able to forward NPRs and Completions carrying 10-Bit Tags correctly, since the two new Tag bits are in TLP Header bits that were formerly Reserved, and Switches are required to forward Reserved TLP Header bits without modification. However, if such a Switch detects an error with an NPR carrying a 10-Bit Tag, and that Switch handles the error by acting as the Completer for the NPR, the resulting Completion will have an invalid 10-Bit Tag. Thus, it is strongly recommended that Switches between any components using 10-Bit Tags support 10-Bit Tag Completer capability. Note that Switches supporting 16.0 GT/s data rates or greater must support 10-Bit Tag Completer capability. 7714 7716 8481 8482 7712 7713 For platforms where the RC supports 10-Bit Tag Completer capability, it is highly recommended for platform firmware or operating software that configures PCIe hierarchies to Set the 10-Bit Tag Requester Enable bit automatically in Endpoints with 10-Bit Tag Requester capability. This enables the important class of 10-Bit Tag capable adapters that send Memory Read Requests only to host memory. 8479 7709 7710 8478 8519 Note that attributes are hints that allow for optimizations in the handling of traffic. Level of support is dependent on target applications of particular PCI Express peripherals and platform building 118 blocks. Refer to PCI-X 2.0 for additional details regarding these attributes. Note that attribute bit 2 is not adjacent to bits 1 and 0 (see Figure 2-15 Request Header Format for 64-bit Addressing of Memory and Figure 2-16 Request Header Format for 32-bit Addressing of Memory ). 8520 Note that attributes are hints that allow for optimizations in the handling of traffic. Level of support is dependent on target applications of particular PCI Express peripherals and platform building blocks. Refer to PCI-X 2.0 for additional details regarding these attributes. Note that attribute bit 2 is not adjacent to bits 1 and 0 (see Figure 2-17 Request Header Format for 64-bit Addressing of Memory and Figure 2-18 Request Header Format for 32-bit Addressing of Memory ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7749 Note that attributes are hints that allow for optimizations in the handling of traffic. Level of support is dependent on target applications of particular PCI Express peripherals and platform building blocks. Refer to PCI-X 2.0 for additional details regarding these attributes. Note that attribute bit 2 is not adjacent to bits 1 and 0 (see Figure 2-15 Request Header Format for 64-bit Addressing of Memory and Figure 2-16 Request Header Format for 32-bit Addressing of Memory ). 8520 7750 8521 7751 8522 7752 8523 7753 8524 7754 Figure 2-14 Attributes Field of Transaction Descriptor 8525 7755 8526 7756 8527 7757 8528 7758 8529 7759 2.2.6.4 Relaxed Ordering and ID-Based Ordering Attributes 7761 8531 8533 Table 2-9 Ordering Attributes defines the states of the Relaxed Ordering and ID-Based Ordering attribute fields. These attributes are discussed in . Note that Relaxed Ordering and ID-Based Ordering attributes are not adjacent in location (see Figure 2-5 Fields Present in All TLP Headers ). 8534 7764 8535 7765 8536 7766 Table 2-9 Ordering Attributes 7768 8538 Table 2-9 Ordering Attributes 8539 7769 Attribute Bit [2] 7770 8540 Attribute Bit [2] 8541 7771 Attribute Bit [1] 7772 8542 Attribute Bit [1] 8543 7773 Ordering Type 7820 8544 Ordering Type 8591 Attribute bit [1] is not applicable and must be Clear for Configuration Requests, I/O Requests, Memory Requests that are Message Signaled Interrupts, and Message Requests (except where specifically permitted). 7822 8592 Attribute bit [1] is not applicable and must be Clear for Configuration Requests, I/O Requests, Memory Requests that are Message Signaled Interrupts, and Message Requests (except where specifically permitted). 8593 7823 8594 Attribute bit [2], IDO, is Reserved for Configuration Requests and I/O Requests. IDO is not Reserved for all Memory Requests, including Message Signaled Interrupts (MSI/MSI-X). IDO is not Reserved for Message Requests unless specifically prohibited. A Requester is permitted to set IDO only if the IDO Request Enable bit in the Device Control 2 register is set. 7825 8595 Attribute bit [2], IDO, is Reserved for Configuration Requests and I/O Requests. IDO is not Reserved for all Memory Requests, including Message Signaled Interrupts (MSI/MSI-X). IDO is not Reserved for Message Requests unless specifically prohibited. A Requester is permitted to Set IDO only if the IDO Request Enable bit in the Device Control 2 register is Set. 8596 7826 7827 Table 2-9 Ordering Attributes defines the states of the Relaxed Ordering and ID-Based Ordering attribute fields. These attributes are discussed in Section 2.4 Transaction Ordering . Note that Relaxed Ordering and ID-Based Ordering attributes are not adjacent in location (see Figure 2-5 Fields Present in All TLP Headers ). 8537 7767 7824 2.2.6.4 Relaxed Ordering and ID-Based Ordering Attributes 8532 7762 7821 Figure 2-16 Attributes Field of Transaction Descriptor 8530 7760 7763 Note that attributes are hints that allow for optimizations in the handling of traffic. Level of support is dependent on target applications of particular PCI Express peripherals and platform building blocks. Refer to PCI-X 2.0 for additional details regarding these attributes. Note that attribute bit 2 is not adjacent to bits 1 and 0 (see Figure 2-17 Request Header Format for 64-bit Addressing of Memory and Figure 2-18 Request Header Format for 32-bit Addressing of Memory ). 8597 The value of the IDO bit must not be considered by Receivers when determining if a TLP is a Malformed Packet. Page 119 8598 The value of the IDO bit must not be considered by Receivers when determining if a TLP is a Malformed Packet. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 7827 The value of the IDO bit must not be considered by Receivers when determining if a TLP is a Malformed Packet. 7828 8600 A Completer is permitted to set IDO only if the IDO Completion Enable bit in the Device Control 2 register is set. It is not required to copy the value of IDO from the Request into the Completion(s) for that Request. If the Completer has IDO enabled, it is recommended that the Completer set IDO for all Completions, unless there is a specific reason not to (see Appendix E ID-Based Ordering Usage ) 7831 8601 8603 A Root Complex that supports forwarding TLPs peer-to-peer between Root Ports is not required to preserve the IDO bit from the Ingress to Egress Port. 8604 7834 8605 7835 8606 7836 8607 7837 2.2.6.5 No Snoop Attribute 8609 7839 8610 7840 8611 7933 8704 7934 8705 7935 2.2.7 Memory, I/O, and Configuration Request Rules 7937 8710 The following rule applies to all Memory, I/O, and Configuration Requests. Additional rules specific to each type of Request follow. 8711 All Memory, I/O, and Configuration Requests include the following fields in addition to the common header fields: Requester ID[15:0] and Tag[9:0], forming the Transaction ID. Last DW BE[3:0] and 1st DW BE[3:0]. For Memory Read Requests and AtomicOp Requests with the TH bit Set, the byte location for the Last DW BE[3:0] and 1st DW BE [3:0] fields in the header are repurposed to carry ST[7:0] field. For Memory Read Requests with the TH bit Clear, see Section 2.2.5 First/Last DW Byte Enables Rules for First/ Last DW Byte Enable Rules. For AtomicOp Requests with TH bit Set, the values for the DW BE fields are implied to be Reserved. For AtomicOp Requests with TH bit Clear, the DW BE fields are Reserved. 8712 8713 8714 7944 8715 7945 8716 7946 All Memory, I/O, and Configuration Requests include the following fields in addition to the common header fields: Requester ID[15:0] and Tag[9:0], forming the Transaction ID. Last DW BE[3:0] and First DW BE[3:0]. For Memory Read Requests and AtomicOp Requests with the TH bit Set, the byte location for the Last DW BE[3:0] and First DW BE [3:0] fields in the header are repurposed to carry ST[7:0] field. For Memory Read Requests with the TH bit Clear, see Section 2.2.5 First/Last DW Byte Enables Rules for First/ Last DW Byte Enable Rules. For AtomicOp Requests with TH bit Set, the values for the DW BE fields are implied to be Reserved. For AtomicOp Requests with TH bit Clear, the DW BE fields are Reserved. 8717 7947 For Memory Requests, the following rules apply: 7948 7949 2.2.7 Memory, I/O, and Configuration Request Rules 8709 The following rule applies to all Memory, I/O, and Configuration Requests. Additional rules specific to each type of Request follow. 7940 7943 8707 8708 7938 7942 2.2.6.5 No Snoop Attribute 8706 7936 7941 A Root Complex that supports forwarding TLPs peer-to-peer between Root Ports is not required to preserve the IDO bit from the Ingress to Egress Port. 8608 7838 7939 A Completer is permitted to Set IDO only if the IDO Completion Enable bit in the Device Control 2 register is Set. It is not required to copy the value of IDO from the Request into the Completion(s) for that Request. If the Completer has IDO enabled, it is recommended that the Completer set IDO for all Completions, unless there is a specific reason not to (see Appendix E ID-Based Ordering Usage ). 8602 7832 7833 The value of the IDO bit must not be considered by Receivers when determining if a TLP is a Malformed Packet. 8599 7829 7830 8598 8718 For Memory Requests, the following rules apply: 8719 Memory Requests route by address, using either 64-bit or 32-bit Addressing (see Figure 2-15 Request Header Format for 64-bit Addressing of Memory and Figure 2-16 Request Header Format for 32-bit Addressing of Memory ). Page 120 8720 Memory Requests route by address, using either 64-bit or 32-bit Addressing (see Figure 2-17 Request Header Format for 64-bit Addressing of Memory and Figure 2-18 Request Header Format for 32-bit Addressing of Memory ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 7949 /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html Memory Requests route by address, using either 64-bit or 32-bit 7950 7951 Addressing (see Figure 2-15 Request Header Format for 64-bit Addressing of Memory and Figure 2-16 Request Header Format for 32-bit Addressing of Memory ). For Memory Read Requests, Length must not exceed the value specified by Max_Read_Request_Size (see Section 7.5.3.4 Device Control Register (Offset 08h) ). For AtomicOp Requests, architected operand sizes and their associated Length field values are specified in Table 2-12 Length Field Values for AtomicOp Requests . If a Completer supports AtomicOps, the following rules apply. The Completer must check the Length field value. If the value does not match an architected value, the Completer must handle the TLP as a Malformed TLP. Otherwise, if the value does not match an operand size that the Completer supports, the Completer must handle the TLP as an Unsupported Request (UR). This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8720 8721 8722 7952 8723 7953 8724 7954 8725 7955 8726 7956 Table 2-12 Length Field Values for AtomicOp Requests 7957 8727 AtomicOp Request 8729 7959 8730 7989 8760 7990 8761 7991 8762 7992 8763 7993 7995 7996 7999 8000 8001 8765 8766 8767 A FetchAdd Request contains one operand, the “add” value. A Swap Request contains one operand, the “swap” value. A CAS Request contains two operands. The first in the data area is the “compare” value, and the second is the “swap” value. 8768 For AtomicOp Requests, the Address must be naturally aligned with the operand size. The Completer must check for violations of this rule. If a TLP violates this rule, the TLP is a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). Requests must not specify an Address/Length combination which causes a Memory Space access to cross a 4-KB boundary. Receivers may optionally check for violations of this rule. If a Receiver implementing this check determines that a TLP violates this rule, the TLP is a Malformed TLP. If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8002 8003 AtomicOp Request 8764 A FetchAdd Request contains one operand, the “add” value. A Swap Request contains one operand, the “swap” value. A CAS Request contains two operands. The first in the data area is the “compare” value, and the second is the “swap” value. 7997 7998 Table 2-12 Length Field Values for AtomicOp Requests 8728 7958 7994 Memory Requests route by address, using either 64-bit or 32-bit Addressing (see Figure 2-17 Request Header Format for 64-bit Addressing of Memory and Figure 2-18 Request Header Format for 32-bit Addressing of Memory ). For Memory Read Requests, Length must not exceed the value specified by Max_Read_Request_Size (see Section 7.5.3.4 Device Control Register (Offset 08h) ). For AtomicOp Requests, architected operand sizes and their associated Length field values are specified in Table 2-12 Length Field Values for AtomicOp Requests . If a Completer supports AtomicOps, the following rules apply. The Completer must check the Length field value. If the value does not match an architected value, the Completer must handle the TLP as a Malformed TLP. Otherwise, if the value does not match an operand size that the Completer supports, the Completer must handle the TLP as an Unsupported Request (UR). This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8769 8770 8771 8772 For AtomicOp Requests, the Address must be naturally aligned with the operand size. The Completer must check for violations of this rule. If a TLP violates this rule, the TLP is a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). Requests must not specify an Address/Length combination that causes a Memory Space access to cross a 4-KB boundary. Receivers may optionally check for violations of this rule. If a Receiver implementing this check determines that a TLP violates this rule, the TLP is a Malformed TLP. If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8773 For AtomicOp Requests, the mandatory Completer check for natural alignment of the Address (see above) already guarantees that the access will not cross a 4-KB boundary, so a separate 4-KB boundary check is not necessary. Page 121 8774 For AtomicOp Requests, the mandatory Completer check for natural alignment of the Address (see above) already guarantees that the access will not cross a 4-KB boundary, so a separate 4-KB boundary check is not necessary. For AtomicOp Requests, the mandatory Completer /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. check for natural alignment of the Address (see above) already guarantees that the /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html access will not cross a 4-KB boundary, so a separate 4-KB boundary check 8003 8004 is not necessary. If a 4-KB boundary check is performed for AtomicOp CAS Requests, this check must comprehend that the TLP Length value is based on the size of two operands, whereas the access to Memory Space is based on the size of one operand. 8774 8775 8005 8776 8006 8777 8007 8778 8008 8779 8009 8780 For AtomicOp Requests, the mandatory Completer check for natural alignment of the Address (see above) already guarantees that the access will not cross a 4-KB boundary, so a separate 4-KB boundary check is not necessary. If a 4-KB boundary check is performed for AtomicOp CAS Requests, this check must comprehend that the TLP Length value is based on the size of two operands, whereas the access to Memory Space is based on the size of one operand. 8781 Figure 2-17 Request Header Format for 64-bit Addressing of Memory 8010 8782 8011 8783 8012 Figure 2-15 Request Header Format for 64-bit Addressing of Memory 8013 8014 8784 8015 8785 8016 8786 8017 8787 8018 Figure 2-18 Request Header Format for 32-bit Addressing of Memory 8019 8020 Figure 2-16 Request Header Format for 32-bit Addressing of Memory 8021 8788 8022 8789 8023 8790 8024 8791 8025 Implementation Note Generation of 64-bit Addresses 8026 8792 8793 8027 8794 8028 8795 8029 8030 8796 It is strongly recommended that PCI Express Endpoints be capable of generating the full range of 64-bit addresses. However, if a PCI Express Endpoint supports a smaller address range, and is unable to reach the full address range required by a given platform environment, the corresponding device driver must ensure that all Memory Transaction target buffers fall within the address range supported by the Endpoint. The exact means of ensuring this is platform and operating system specific, and beyond the scope of this specification. 8797 8031 8798 8032 8799 8033 8800 8034 For I/O Requests, the following rules apply: 8036 8038 8039 It is strongly recommended that PCI Express Endpoints be capable of generating the full range of 64-bit addresses. However, if a PCI Express Endpoint supports a smaller address range, and is unable to reach the full address range required by a given platform environment, the corresponding device driver must ensure that all Memory Transaction target buffers fall within the address range supported by the Endpoint. The exact means of ensuring this is platform and operating system specific, and beyond the scope of this specification. 8801 8035 8037 Implementation Note Generation of 64-bit Addresses 8802 For I/O Requests, the following rules apply: 8803 I/O Requests route by address, using 32-bit Addressing (see Figure 2-17 Request Header Format for I/O Transactions ) I/O Requests have the following restrictions: TC[2:0] must be 000b Page 122 8804 8805 8806 I/O Requests route by address, using 32-bit Addressing (see Figure 2-19 Request Header Format for I/O Transactions ) I/O Requests have the following restrictions: TC[2:0] must be 000b /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 8039 TC[2:0] must be 000b LN is not applicable to I/O Requests and the bit is 8040 8806 Reserved 8041 Reserved TH is not applicable to I/O Request and the bit is 8808 Reserved 8042 8043 8044 8045 8046 TC[2:0] must be 000b LN is not applicable to I/O Requests and the bit is 8807 TH is not applicable to I/O Request and the bit is Reserved Attr[2] is Reserved Attr[1:0] must be 00b AT[1:0] must be 00b. Receivers are not required or encouraged to check this. Length[9:0] must be 00 0000 0001b Last DW BE[3:0] must be 0000b 8047 8809 8810 8811 8812 8813 Attr[2] is Reserved Attr[1:0] must be 00b AT[1:0] must be 00b. Receivers are not required or encouraged to check this. Length[9:0] must be 00 0000 0001b Last DW BE[3:0] must be 0000b 8814 8815 8048 Receivers may optionally check for violations of these rules (but must not check Reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 8049 8050 8816 Receivers may optionally check for violations of these rules (but must not check Reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 8817 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8818 8051 8819 8052 8820 8053 8821 8054 8822 8055 8823 8056 8824 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). Figure 2-19 Request Header Format for I/O Transactions 8057 8058 8059 Figure 2-17 Request Header Format for I/O Transactions 8060 8825 8061 8826 8062 8827 8063 For Configuration Requests, the following rules apply: 8064 8065 8066 8067 8068 8071 8072 8073 8074 8075 For Configuration Requests, the following rules apply: 8829 Configuration Requests route by ID, and use In addition to the header fields included and Configuration Requests and the ID routing fields, Requests contain the following additional fields (see Header Format for Configuration Transactions ). Register Number[5:0] Extended Register Number[3:0] a 3 DW header in all Memory, I/O, Configuration Figure 2-18 Request 8069 8070 8828 8830 8831 8832 8833 Configuration Requests route by ID, and use In addition to the header fields included and Configuration Requests and the ID routing fields, Requests contain the following additional fields (see Header Format for Configuration Transactions ). Register Number[5:0] Extended Register Number[3:0] a 3 DW header. in all Memory, I/O, Configuration Figure 2-20 Request 8834 Configuration Requests have the following restrictions: TC[2:0] must be 000b LN is not applicable to Configuration Requests and the bit is Reserved TH is not applicable to Configuration Requests and the bit is Reserved Attr[2] is Reserved Attr[1:0] must be 00b Page 123 8835 8836 8837 8838 8839 8840 Configuration Requests have the following restrictions: TC[2:0] must be 000b LN is not applicable to Configuration Requests and the bit is Reserved TH is not applicable to Configuration Requests and the bit is Reserved Attr[2] is Reserved Attr[1:0] must be 00b /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 8075 8076 8077 8078 Attr[1:0] must be 00b AT[1:0] must be 00b. Receivers are not required or encouraged to check this. Length[9:0] must be 00 0000 0001b Last DW BE[3:0] must be 0000b 8079 8840 8841 8842 8843 Attr[1:0] must be 00b AT[1:0] must be 00b. Receivers are not required or encouraged to check this. Length[9:0] must be 00 0000 0001b Last DW BE[3:0] must be 0000b 8844 8845 8080 Receivers may optionally check for violations of these rules (but must not check reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 8081 8082 8846 Receivers may optionally check for violations of these rules (but must not check reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 8847 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8848 8083 8849 8084 8850 8085 8851 8086 8852 8087 8853 8088 8854 8089 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). Figure 2-20 Request Header Format for Configuration Transactions 8090 8091 Figure 2-18 Request Header Format for Configuration Transactions 8092 8855 8093 8856 8094 8095 8857 MSI/MSI-X mechanisms use Memory Write Requests to represent interrupt Messages (see Section 6.1.4 MSI and MSI-X Operation ). The Request format used for MSI/MSI-X transactions is identical to the Memory Write Request format defined above, and MSI/MSI-X Requests are indistinguishable from memory writes with regard to ordering, Flow Control, and data integrity. 8858 8096 8859 8097 8860 8098 8861 8099 2.2.7.1 TPH Rules 8100 8101 MSI/MSI-X mechanisms use Memory Write Requests to represent interrupt Messages (see Section 6.1.4 MSI and MSI-X Operation ). The Request format used for MSI/MSI-X transactions is identical to the Memory Write Request format defined above, and MSI/MSI-X Requests are indistinguishable from memory writes with regard to ordering, Flow Control, and data integrity. 8862 2.2.7.1 TPH Rules 8863 Two formats are specified for TPH. The Baseline TPH format (see Figure 2-20 Location of PH[1:0] in a 4 DW Request Header and Figure 2-21 Location of PH[1:0] in a 3 DW Request Header ) must be used for all Requests that provide TPH. The format with the optional TPH TLP Prefix extends the TPH fields (see Figure 2-19 TPH TLP Prefix ) to provide additional bits for the Steering Tag (ST) field. 8864 8102 8865 8103 8866 8104 8867 8105 8106 8107 Page 124 Two formats are specified for TPH. The Baseline TPH format (see Figure 2-22 Location of PH[1:0] in a 4 DW Request Header and Figure 2-23 Location of PH[1:0] in a 3 DW Request Header ) must be used for all Requests that provide TPH. The format with the optional TPH TLP Prefix extends the TPH fields (see Figure 2-21 TPH TLP Prefix ) to provide additional bits for the Steering Tag (ST) field. 8868 Figure 2-19 TPH TLP Prefix 8869 8870 Figure 2-21 TPH TLP Prefix /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 8107 8870 8108 8871 8109 The optional TPH TLP Prefix is used to extend the TPH 8872 fields. 8110 The presence of a TPH TLP Prefix is determined by 8873 decoding byte 0. 8874 8112 8875 8113 8876 8114 8877 8115 Table 2-13 TPH TLP Prefix Bit Mapping 8878 8116 8879 8133 8896 8134 Reserved 8136 8898 Bits 7:0 of byte 3 8900 8138 8901 8139 8902 8140 8903 8141 8145 Bits 7:0 of byte 3 8904 For Requests that target Memory Space, a value of 1b in the TH bit indicates the presence of TPH in the TLP header and optional TPH TLP Prefix (if present). The TH bit must be Set for Requests that provide TPH The TH bit must be Set for Requests with a TPH TLP Prefix The TH bit is not applicable and is Reserved for all other Requests. 8146 8147 Reserved 8899 8137 8144 Table 2-13 TPH TLP Prefix Bit Mapping 8897 8135 8143 The presence of a TPH TLP Prefix is determined by decoding byte 0. 8111 8142 The optional TPH TLP Prefix is used to extend the TPH fields. 8905 8906 8907 8908 8909 For Requests that target Memory Space, a value of 1b in the TH bit indicates the presence of TPH in the TLP header and optional TPH TLP Prefix (if present). The TH bit must be Set for Requests that provide TPH. The TH bit must be Set for Requests with a TPH TLP Prefix. When the TH bit is Clear, the PH field is Reserved. The TH bit and the PH field are not applicable and are Reserved for all other Requests. 8910 The Processing Hints (PH) fields mapping is shown in Figure 2-20 Location of PH[1:0] in a 4 DW Request Header , Figure 2-21 Location of PH[1:0] in a 3 DW Request Header and Table 2-14 Location of PH[1:0] in TLP Header . 8911 8148 8912 8149 8913 8150 8914 8151 8152 8915 Figure 2-20 Location of PH[1:0] in a 4 DW Request Header 8916 8153 8917 8154 8918 8155 8919 8156 8920 8157 8158 8922 8923 8160 8924 8161 8925 8162 Page 125 Figure 2-22 Location of PH[1:0] in a 4 DW Request Header 8921 Figure 2-21 Location of PH[1:0] in a 3 DW Request Header 8159 8163 The Processing Hints (PH) fields mapping is shown in Figure 2-22 Location of PH[1:0] in a 4 DW Request Header , Figure 2-23 Location of PH[1:0] in a 3 DW Request Header and Table 2-14 Location of PH[1:0] in TLP Header . Figure 2-23 Location of PH[1:0] in a 3 DW Request Header 8926 Table 2-14 Location of PH[1:0] in TLP Header 8927 Table 2-14 Location of PH[1:0] in TLP Header /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 8163 Table 2-14 Location of PH[1:0] in TLP Header 8164 PH 8166 8929 PH 8930 8167 32-bit Addressing 8168 8931 32-bit Addressing 8932 8220 11 8221 8984 11 8985 8222 Target with Priority 8223 8986 Target with Priority 8987 Indicates frequent read and/or write access by Host and indicates high temporal locality for accessed data 8988 8225 8989 8226 8990 8227 8991 8228 8992 8229 8230 Table 2-14 Location of PH[1:0] in TLP Header 8928 8165 8224 8927 Indicates frequent read and/or write access by Host and indicates high temporal locality for accessed data 8993 The Steering Tag (ST) fields are mapped to the TLP header as shown in Figure 2-22 Location of ST[7:0] in the Memory Write Request Header , Figure 2-23 Location of ST[7:0] in Memory Read and AtomicOp Request Headers and Table 2-16 Location of ST[7:0] in TLP Headers . 8994 The Steering Tag (ST) fields are mapped to the TLP header as shown in Figure 2-24 Location of ST[7:0] in the Memory Write Request Header , Figure 2-25 Location of ST[7:0] in Memory Read and AtomicOp Request Headers and Table 2-16 Location of ST[7:0] in TLP Headers . 8231 8232 8233 8995 8234 8996 8235 8997 8236 8998 8237 Figure 2-22 Location of ST[7:0] in the Memory Write 8999 Request Header 8238 9000 8239 9001 8240 9002 8241 9003 8242 9004 8243 9005 8244 8245 Figure 2-24 Location of ST[7:0] in the Memory Write Request Header Figure 2-25 Location of ST[7:0] in Memory Read and AtomicOp Request Headers Figure 2-23 Location of ST[7:0] in Memory Read and AtomicOp Request Headers 8246 9006 8247 9007 8248 9008 8249 8250 9009 Table 2-16 Location of ST[7:0] in TLP Headers 8251 8252 ST Bits 8290 Page 126 9012 ST Bits 9013 Memory Write Request 8255 8289 Table 2-16 Location of ST[7:0] in TLP Headers 9011 8253 8254 9010 9014 Memory Write Request 9015 Vendor-Defined Messages Latency Tolerance Reporting (LTR) Messages 9049 9050 Vendor-Defined Messages Latency Tolerance Reporting (LTR) Messages /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 8290 Latency Tolerance Reporting (LTR) Messages Optimized Buffer Flush/Fill (OBFF) Messages Device Readiness Status (DRS) Messages Function Readiness Status (FRS) Messages Precision Time Measurement (PTM) Messages 8291 8292 8293 8294 8295 8300 8301 9052 9053 9054 9056 The following rules apply to all Message Requests. Additional rules specific to each type of Message follow. 8298 8299 9057 9059 9060 9061 All Message Requests use the Msg or MsgD Type field 9063 encoding. 8306 8307 8308 8309 8310 8311 8312 The Message Code field must be fully decoded (Message aliasing is not permitted). The Attr[2] field is not Reserved unless specifically indicated as Reserved. Except as noted, the Attr[1:0] field is Reserved. LN is not applicable to Message Requests and the bit is Reserved. Except as noted, TH is not applicable to Message Requests and the bit is Reserved. AT[1:0] must be 00b. Receivers are not required or encouraged to check this. Except as noted, bytes 8 through 15 are Reserved. Message Requests are posted and do not require Completion. Message Requests follow the same ordering rules as Memory Write Requests. 9064 9065 9066 9067 9068 9069 9070 9071 9072 9073 8314 9074 9075 8315 9076 8316 9077 8317 9078 8318 9080 9081 8321 9082 8322 Page The Message Code field must be fully decoded (Message aliasing is not permitted). The Attr[2] field is not Reserved unless specifically indicated as Reserved. Except as noted, the Attr[1:0] field is Reserved. LN is not applicable to Message Requests and the bit is Reserved. Except as noted, TH is not applicable to Message Requests and the bit is Reserved. AT[1:0] must be 00b. Receivers are not required or encouraged to check this. Except as noted, bytes 8 through 15 are Reserved. Message Requests are posted and do not require Completion. Message Requests follow the same ordering rules as Memory Write Requests. Many types of Messages, including Vendor-Defined Messages, are potentially usable in non-D0 states, and it is strongly recommended that the handling of Messages by Ports be the same when the Port's Bridge Function is in D1, D2, and D3Hot as it is in D0. It is strongly recommended that Type 0 Functions support the generation and reception of Messages in non-D0 states. 9079 Figure 2-24 Message Request Header 8320 8323 All Message Requests use the Msg or MsgD Type field encoding. 8313 8319 All Message Requests include the following fields in addition to the common header fields (see Figure 2-37 PTM ResponseD Message (4 DW header and 1 DW payload) ): Requester ID[15:0] and Tag[9:0], forming the Transaction ID. Message Code[7:0] - Specifies the particular Message embodied in the Request. 9062 8303 8305 The following rules apply to all Message Requests. Additional rules specific to each type of Message follow. 9058 All Message Requests include the following fields in addition to the common header fields (see Figure 2-34 PTM ResponseD Message (4 DW header and 1 DW payload) ): Requester ID[15:0] and Tag[9:0], forming the Transaction ID. Message Code[7:0] - Specifies the particular Message embodied in the Request. 8302 8304 Latency Tolerance Reporting (LTR) Messages Optimized Buffer Flush/Fill (OBFF) Messages Device Readiness Status (DRS) Messages Function Readiness Status (FRS) Messages Precision Time Measurement (PTM) Messages 9051 9055 8296 8297 9050 Figure 2-26 Message Request Header 9083 In addition to address and ID routing, Messages support several other routing mechanisms. These mechanisms are referred to as 127 “implicit” because no address or ID specifies the destination, but rather the destination is implied by the routing type. The following rules cover Message routing mechanisms: 9084 In addition to address and ID routing, Messages support several other routing mechanisms. These mechanisms are referred to as “implicit” because no address or ID specifies the destination, but rather the destination is implied by the routing type. The following rules cover Message routing mechanisms: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 8323 In addition to address and ID routing, Messages support several other routing mechanisms. These mechanisms are referred to as “implicit” because no address or ID specifies the destination, but rather the destination is implied by the routing type. The following rules cover Message routing mechanisms: 8324 9084 9085 8325 Message routing is determined using the r[2:0] sub-field of the 9086 Type field 8326 8327 Message Routing r[2:0] values are defined in Table 2-17 Message Routing Permitted values are defined in the following sections for each Message 9087 9088 9090 8374 100 8375 9135 Local - Terminate at Receiver 8377 9137 Local - Terminate at Receiver 9138 8378 Reserved 9139 8379 9140 8380 9141 8381 Reserved 9142 8382 101 8383 9143 101 9144 Gathered and routed to Root Complex [Footnote: This routing type is used only for PME_TO_Ack, and is described in Section 5.6.4.2.1 .] 8385 9145 Gathered and routed to Root Complex [Footnote: This routing type is used only for PME_TO_Ack, and is described in Section 5.3.3.2.1 PME Synchronization .] 9146 8386 Reserved 9147 8387 9148 8388 9149 8389 Reserved 9150 8390 110 to 111 8391 9151 110 to 111 9152 8392 Reserved - Terminate at Receiver 8393 9153 Reserved - Terminate at Receiver 9154 8394 Reserved 8694 9155 Reserved 9455 The Root Complex must track the state of the four INTx virtual wires independently for each of its Downstream Ports, and map these virtual signals to system interrupt resources. Details of this mapping are system implementation specific. 8697 8698 100 9136 8376 8696 Message Routing r[2:0] values are defined in Table 2-17 Message Routing Permitted values are defined in the following sections for each Message 9089 8329 8695 Message routing is determined using the r[2:0] sub-field of the Type field 8328 8384 In addition to address and ID routing, Messages support several other routing mechanisms. These mechanisms are referred to as “implicit” because no address or ID specifies the destination, but rather the destination is implied by the routing type. The following rules cover Message routing mechanisms: 9456 9457 The Root Complex must track the state of the four INTx virtual wires independently for each of its Downstream Ports, and map these virtual signals to system interrupt resources. Details of this mapping are system implementation specific. 9458 If a Downstream Port of the Root Complex goes to DL_Down status, the INTx virtual wires associated with that Port must be deasserted, and any associated system interrupt resource request(s) must be discarded. 9459 8699 9460 8700 9461 Page 128 If a Downstream Port of the Root Complex goes to DL_Down status, the INTx virtual wires associated with that Port must be deasserted, and any associated system interrupt resource request(s) must be discarded. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 8700 9461 8701 9462 8702 Table 2-19 Bridge Mapping for INTx Virtual Wires 8703 8704 9463 Requester ID[7:3] from the Assert_INTx/ Deassert_INTx Message received on Secondary Side of Bridge (Interrupt Source [Footnote: The Requester ID of an Assert_INTx/Deassert_INTx Message will correspond to the Transmitter of the Message on that Link, and not necessarily to the original source of the interrupt.])] ) If ARI Forwarding is enabled, the value 0 must be used instead of Requester ID[7:3]. 8705 9465 9466 INTx Virtual Wire on Secondary Side of Bridge 8707 9468 Mapping to INTx Virtual Wire on Primary Side of 9470 Bridge 9471 8710 9472 8711 9473 0,4,8,12,16,20,24,28 8713 9474 INTA The implied Device Number for an ARI Device is 0. When ARI-aware software (including BIOS and operating system) enables ARI Forwarding in the Downstream Port immediately above an ARI Device in order to access its Extended Functions, software must comprehend that the Downstream Port will use Device Number 0 for the virtual wire mappings of INTx interrupts coming from all Functions of the ARI Device. If non-ARIaware software attempts to determine the virtual wire mappings for Extended Functions, it can come up with incorrect mappings by examining the traditional Device Number field and finding it to be non-0. 9476 9597 9598 8837 9599 8838 9600 8839 9601 8840 9602 8841 8851 Page 9607 These Messages are used to support PCI Express power management, which is described in detail in Chapter 5 Power Management . The following rules define the Power Management Messages: 9608 8847 8850 2.2.8.2 Power Management Messages 9606 These Messages are used to support PCI Express power management, which is described in detail in Chapter 5 . The following rules define the Power Management Messages: 8846 8849 9604 9605 8844 8848 INTA The implied Device Number for an ARI Device is 0. When ARI-aware software (including BIOS and operating system) enables ARI Forwarding in the Downstream Port immediately above an ARI Device in order to access its Extended Functions, software must comprehend that the Downstream Port will use Device Number 0 for the virtual wire mappings of INTx interrupts coming from all Functions of the ARI Device. If non-ARIaware software attempts to determine the virtual wire mappings for Extended Functions, it can come up with incorrect mappings by examining the traditional Device Number field and finding it to be non-0. 9603 2.2.8.2 Power Management Messages 8843 8845 0,4,8,12,16,20,24,28 9475 8836 8842 Mapping to INTx Virtual Wire on Primary Side of Bridge 8709 8835 INTx Virtual Wire on Secondary Side of Bridge 9469 8708 8714 Requester ID[7:3] from the Assert_INTx/ Deassert_INTx Message received on Secondary Side of Bridge (Interrupt Source [Footnote: The Requester ID of an Assert_INTx/Deassert_INTx Message will correspond to the Transmitter of the Message on that Link, and not necessarily to the original source of the interrupt.] ) If ARI Forwarding is enabled, the value 0 must be used instead of Requester ID[7:3]. 9467 8706 8712 Table 2-19 Bridge Mapping for INTx Virtual Wires 9464 9609 Table 2-20 Power Management Messages defines the Power Management Messages. Power Management Messages do not include a data payload (TLP Type is Msg). The Length field is Reserved. With PM_Active_State_Nak Messages, the Function Number field in the Requester ID must contain the Function Number of the Downstream Port that sent the Message, or else 000b for compatibility 129 with earlier revisions of this specification. 9610 9611 9612 9613 Table 2-20 Power Management Messages defines the Power Management Messages. Power Management Messages do not include a data payload (TLP Type is Msg). The Length field is Reserved. With PM_Active_State_Nak Messages, the Function Number field in the Requester ID must contain the Function Number of the Downstream Port that sent the Message, or else 000b for compatibility with earlier revisions of this specification. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 8851 8852 8853 8854 With PM_Active_State_Nak Messages, the Function Number field in the Requester ID must contain the Function Number of the Downstream Port that sent the Message, or else 000b for compatibility with earlier revisions of this specification. With PME_TO_Ack Messages, the Function Number field in the Requester ID must be Reserved, or else for compatibility with earlier revisions of this specification must contain the Function Number of one of the Functions associated with the Upstream Port. Note that the Function Number field is a different size for non-ARI and ARI Requester IDs. Power Management Messages must use the default Traffic Class designator (TC0). Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 8855 9614 9615 9616 9820 This Message is issued when the Function or Device detects a Fatal, uncorrectable error on the PCI Express interface. 9821 9060 9822 9061 9823 9062 9824 9063 9825 9064 9065 With PM_Active_State_Nak Messages, the Function Number field in the Requester ID must contain the Function Number of the Downstream Port that sent the Message, or else 000b for compatibility with earlier revisions of this specification. With PME_TO_Ack Messages, the Function Number field in the Requester ID must be Reserved, or else for compatibility with earlier revisions of this specification must contain the Function Number of one of the Functions associated with the Upstream Port. Note that the Function Number field is a different size for non-ARI and ARI Requester IDs. Power Management Messages must use the default Traffic Class designator (TC0). Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 9617 9058 9059 9613 This Message is issued when the Function or Device detects a Fatal, uncorrectable error on the PCI Express interface. 9826 The initiator of the Message is identified with the Requester ID of the Message header. The Root Complex translates these error Messages into platform level events. Refer to Section 6.2 Error Signaling and Logging for details on uses for these Messages. 9827 9066 9828 9067 9829 9830 The initiator of the Message is identified with the Requester ID of the Message header. The Root Complex translates these error Messages into platform level events. Refer to Section 6.2 Error Signaling and Logging for details on uses for these Messages. ERR_COR Messages have an ERR_COR Subclass (ECS) field in the Message header that enables different subclasses to be distinguished from each other. See Figure 2-27 ERR_COR Message . ERR_NONFATAL and ERR_FATAL Messages do not have the ECS field. 9831 9832 9833 9834 9835 Figure 2-27 ERR_COR Message 9836 9837 9838 The ERR_COR Subclass (ECS) field is encoded as shown in Table 2-22 ERR_COR Subclass (ECS) Field Encodings , indicating the ERR_COR Message subclass. 9839 9840 9841 9842 Table 2-22 ERR_COR Subclass (ECS) Field Encodings 9843 9844 Page 130 ECS Coding /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9844 ECS Coding 9845 9846 Description 9847 9848 9849 9850 00 9851 9852 ECS Legacy - The value inherently used if a Requester does not support ECS capability. ECS-capable Requesters must not use this value. See see Section 7.5.3.3 Device Capabilities Register (Offset 04h) . 9853 9854 9855 9856 01 9857 9858 ECS SIG_SFW - Must be used by an ECS-capable Requester when signaling a DPC or SFI event with an ERR_COR Message. 9859 9860 9861 9862 10 9863 9864 ECS SIG_OS - Must be used by an ECS-capable Requester when signaling an AER or RP PIO event with an ERR_COR Message. 9865 9866 9867 9868 11 9869 9870 ECS Extended - Intended for possible future use. Requesters must not use this value. Receivers must handle the signal internally the same as ECS SIG_OS. 9871 9872 9873 9874 9875 9068 9876 9069 9877 9070 2.2.8.4 Locked Transactions Support 9071 2.2.8.4 Locked Transactions Support 9879 9072 9073 9878 9880 The Unlock Message is used to support Lock Transaction sequences. Refer to Section 6.5 Locked Transactions for details on Lock Transaction sequences. The following rules apply to the formation of the Unlock Message: 9074 Page 131 The Unlock Message is used to support Lock Transaction sequences. Refer to Section 6.5 Locked Transactions for details on Lock Transaction sequences. The following rules apply to the formation of the Unlock Message: 9882 9075 9076 9881 9883 Table 2-22 Unlock Message defines the Unlock Messages. 9884 Table 2-23 Unlock Message defines the Unlock Messages. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9076 Table 2-22 Unlock Message defines the Unlock Messages. The Unlock Message does not include a data payload (TLP 9077 9884 Type is Msg). 9078 9079 9080 9081 Type is Msg). The Length field is Reserved. With Unlock Messages, the Function Number field in the Requester ID is Reserved. The Unlock Message must use the default Traffic Class designator (TC0). Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 9886 9887 9888 9889 9082 9890 9083 9891 9084 9892 9085 Table 2-22 Unlock Message 9087 9894 Name 9089 9896 Code[7:0] (b) 9091 9898 Routing r[2:0] (b) 9093 9900 Routing r[2:0] (b) 9901 9094 Support 9095 9902 Support 9903 9096 Description/Comments 9904 9128 9936 9129 9937 9130 9938 9131 Description/Comments 9939 9132 2.2.8.5 Slot Power Limit Support 9133 9940 2.2.8.5 Slot Power Limit Support 9941 9134 9942 This Message is used to convey a slot power limitation value from a Downstream Port (of a Root Complex or a Switch) to an Upstream Port of a component (with Endpoint, Switch, or PCI Express-PCI Bridge Functions) attached to the same Link. 9136 9943 This Message is used to convey a slot power limitation value from a Downstream Port (of a Root Complex or a Switch) to an Upstream Port of a component (with Endpoint, Switch, or PCI Express-PCI Bridge Functions) attached to the same Link. 9944 9137 9141 Code[7:0] (b) 9899 9092 9140 Name 9897 9090 9139 Table 2-23 Unlock Message 9895 9088 9138 The Length field is Reserved. With Unlock Messages, the Function Number field in the Requester ID is Reserved. The Unlock Message must use the default Traffic Class designator (TC0). Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 9893 9086 9135 Table 2-23 Unlock Message defines the Unlock Messages. The Unlock Message does not include a data payload (TLP 9885 9945 Table 2-23 Set_Slot_Power_Limit Message defines the Set_Slot_Power_Limit Message. The Set_Slot_Power_Limit Message includes a 1 DW data payload (TLP Type is MsgD). The Set_Slot_Power_Limit Message must use the default Traffic Class designator (TC0). Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 9142 Page 132 9946 9947 9948 9949 9950 Table 2-24 Set_Slot_Power_Limit Message defines the Set_Slot_Power_Limit Message. The Set_Slot_Power_Limit Message includes a 1 DW data payload (TLP Type is MsgD). The Set_Slot_Power_Limit Message must use the default Traffic Class designator (TC0). Receivers must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9142 9950 9143 9951 9144 9952 9145 9146 9953 Table 2-23 Set_Slot_Power_Limit Message 9147 9148 Name Code[7:0] (b) Name 9958 Code[7:0] (b) 9959 Routing r[2:0] (b) 9153 9154 9956 9957 9151 9152 Table 2-24 Set_Slot_Power_Limit Message 9955 9149 9150 9954 9960 Routing r[2:0] (b) 9961 Support 9155 9962 Support 9963 9156 Description/Comments 9964 Description/Comments 9180 tr 9988 tr 9181 9182 9989 r 9183 9184 9990 Set Slot Power Limit in Upstream Port 9992 9185 9993 9186 9994 9187 9995 9188 9996 9189 9190 9193 The Set_Slot_Power_Limit Message includes a one DW data payload. The data payload is copied from the Slot Capabilities register of the Downstream Port and is written into the Device Capabilities register of the Upstream Port on the other side of the Link. Bits 1:0 of Byte 1 of the data payload map to the Slot Power Limit Scale field and bits 7:0 of Byte 0 map to the Slot Power Limit Value field. Bits 7:0 of Byte 3, 7:0 of Byte 2, and 7:2 of Byte 1 of the data payload must all be set to zero by the Transmitter and ignored by the Receiver. This Message must be sent automatically by the Downstream Port (of a Root Complex or a Switch) when one of the following events occurs: 10000 10001 On a Configuration Write to the Slot Capabilities register (see Section 7.5.3.9 Slot Capabilities Register (Offset 14h) ) when the Data Link Layer reports DL_Up status. Any time when a Link transitions from a non-DL_Up status to a DL_Up status (see Section 2.9.2 Transaction Layer Behavior in DL_Up Status ) and the Auto Slot Power Limit Disable bit is Clear in the Slot Control Register. This transmission is optional if the Slot Capabilities register has not yet been initialized. 10002 9195 Page 9998 9999 On a Configuration Write to the Slot Capabilities register (see Section 7.5.3.9 Slot Capabilities Register (Offset 14h) ) when the Data Link Layer reports DL_Up status. Any time when a Link transitions from a non-DL_Up status to a DL_Up status (see Section 2.9.2 Transaction Layer Behavior in DL_Up Status ) and the Auto Slot Power Limit Disable bit is Cleared in the Slot Control Register. This transmission is optional if the Slot Capabilities register has not yet been initialized. 9194 9196 Set Slot Power Limit in Upstream Port 9997 The Set_Slot_Power_Limit Message includes a one DW data payload. The data payload is copied from the Slot Capabilities register of the Downstream Port and is written into the Device Capabilities register of the Upstream Port on the other side of the Link. Bits 1:0 of Byte 1 of the data payload map to the Slot Power Limit Scale field and bits 7:0 of Byte 0 map to the Slot Power Limit Value field. Bits 7:0 of Byte 3, 7:0 of Byte 2, and 7:2 of Byte 1 of the data payload must be Set to all 0 by the Transmitter and ignored by the Receiver. This Message must be sent automatically by the Downstream Port (of a Root Complex or a Switch) when one of the following events occurs: 9191 9192 r 9991 10003 The component on the other side of the Link (with Endpoint, Switch, or Bridge Functions) that receives Set_Slot_Power_Limit Message must copy the values in the data payload into the Device Capabilities register associated with the component's Upstream Port. PCI Express components that are targeted exclusively for integration on the system planar (e.g., system board) as well as components that are targeted for integration on an adapter where power consumption of the entire adapteris 133 below the lowest power limit specified for the adapter form factor (as defined in the corresponding form factor specification) are permitted to hardwire the value of all 0's in the Slot Power Limit Scale and Slot Power Limit Value fields of the Device Capabilities register, and are not required to copy the Set_Slot_Power_Limit Message payload into that register. 10004 The component on the other side of the Link (with Endpoint, Switch, or Bridge Functions) that receives Set_Slot_Power_Limit Message must copy the values in the data payload into the Device Capabilities register associated with the component's Upstream Port. PCI Express components that are targeted exclusively for integration on the system planar (e.g., system board) as well as components that are targeted for integration on an adapter where power consumption of the entire adapter is below the lowest power limit specified for the adapter form factor (as defined in the corresponding form factor specification) are permitted to hardwire the value of all 0's in the Slot Power Limit Scale and Slot Power Limit Value fields of the Device Capabilities register, and are not required to copy the Set_Slot_Power_Limit Message payload into that register. 9196 The component on the other side of the Link (with Endpoint, Switch, or Bridge Functions) that receives Set_Slot_Power_Limit /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. Message must copy the values in the data payload into the Device Capabilities /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html register associated with the component's Upstream Port. PCI Express 10004 components that are targeted exclusively for integration on the system planar (e.g., system board) as well as components that are targeted for integration on an adapter where power consumption of the entire adapteris below the lowest power limit specified for the adapter form factor (as defined in the corresponding form factor specification) are permitted to hardwire the value of all 0's in the Slot Power Limit Scale and Slot Power Limit Value fields of the Device Capabilities register, and are not required to copy the Set_Slot_Power_Limit Message payload into that register. 9197 10005 9198 9199 10006 For more details on Power Limit control mechanism see Section 6.9 Slot Power Limit Control . 10007 9200 10008 9201 10009 9202 10010 9203 2.2.8.6 Vendor_Defined Messages 9205 9211 9212 9215 10015 The Vendor_Defined Messages allow expansion of PCI Express messaging capabilities, either as a general extension to the PCI Express Specification or a vendor-specific extension. This section defines the rules associated with these Messages generically. 10016 The Vendor_Defined Messages (see Table 2-24 Vendor_Defined Messages ) use the header format shown in Figure 2-25 Header for VendorDefined Messages . The Requester ID is implementation specific. It is strongly recommended that the Requester ID field contain the value associated with the Requester. [Footnote: ACS Source Validation (see Section 6.12.1.1 ACS Downstream Ports ) checks the Requester ID on all Requests, including Vendor_Defined Messages. This validation depends on the Requester ID properly identifying the Requester.] If the Route by ID routing is used, bytes 8 and 9 form a 16-bit field for the destination ID otherwise these bytes are Reserved. 9213 9214 2.2.8.6 Vendor_Defined Messages 10014 The Vendor_Defined Messages allow expansion of PCI Express messaging capabilities, either as a general extension to the PCI Express Specification or a vendor-specific extension. This section defines the rules associated with these Messages generically. 9208 9210 10012 10013 9206 9209 For more details on Power Limit control mechanism see Section 6.9 Slot Power Limit Control . 10011 9204 9207 The component on the other side of the Link (with Endpoint, Switch, or Bridge Functions) that receives Set_Slot_Power_Limit Message must copy the values in the data payload into the Device Capabilities register associated with the component's Upstream Port. PCI Express components that are targeted exclusively for integration on the system planar (e.g., system board) as well as components that are targeted for integration on an adapter where power consumption of the entire adapter is below the lowest power limit specified for the adapter form factor (as defined in the corresponding form factor specification) are permitted to hardwire the value of all 0's in the Slot Power Limit Scale and Slot Power Limit Value fields of the Device Capabilities register, and are not required to copy the Set_Slot_Power_Limit Message payload into that register. 10017 10018 10019 10020 The Vendor_Defined Messages (see Table 2-25 Vendor_Defined Messages ) use the header format shown in Figure 2-28 Header for VendorDefined Messages . The Requester ID is implementation specific. It is strongly recommended that the Requester ID field contain the value associated with the Requester. [Footnote: ACS Source Validation (see Section 6.12.1.1 ACS Downstream Ports ) checks the Requester ID on all Requests, including Vendor_Defined Messages. This validation depends on the Requester ID properly identifying the Requester.] If the Route by ID routing is used, bytes 8 and 9 form a 16-bit field for the destination ID otherwise these bytes are Reserved. 10021 Bytes 10 and 11 form a 16-bit field for the Vendor ID, as defined by PCI-SIG®, of the vendor defining the Message. Bytes 12 through 15 are available for vendor definition. 10022 10023 9216 10024 9217 10025 9218 10026 9219 9220 10027 Table 2-24 Vendor_Defined Messages 9221 9222 Page 134 10028 Table 2-25 Vendor_Defined Messages 10029 Name 9223 9224 Bytes 10 and 11 form a 16-bit field for the Vendor ID, as defined by PCI-SIG®, of the vendor defining the Message. Bytes 12 through 15 are available for vendor definition. 10030 Name 10031 Code[7:0] (b) 10032 Code[7:0] (b) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9224 Code[7:0] (b) 9225 10032 Code[7:0] (b) 10033 9226 Routing r[2:0] (b) 9227 10034 Routing r[2:0] (b) 10035 9228 Support 9229 10036 Support 10037 9230 Description/Comments 10038 Description/Comments 9258 0111 1111 10066 0111 1111 9259 10067 9260 000, 010, 011, 100 9261 10068 000, 010, 011, 100 10069 9262 See Note 1. 9263 10070 See Note 1. 10071 9264 Silently discarded by Completer if not 10072 implemented. Silently discarded by Completer if not implemented. 9265 10073 9266 10074 9267 10075 9268 9269 Note 1: Transmission by Endpoint/Root Complex/ Bridge is implementation specific. Switches must forward received Messages using Routing r[2:0] field values of 000b, 010b, and 011b. 10076 9270 10077 9271 10078 9272 10079 9273 10080 9274 10081 9275 10082 9276 10083 9277 10084 10085 9278 10087 Figure 2-25 Header for Vendor-Defined Messages 10088 A data payload may be included with either type of Vendor_Defined Message (TLP type is Msg if no data payload is included or MsgD if a data payload is included). 10089 For both types of Vendor_Defined Messages, the Attr[1:0] and Attr[2] fields are not Reserved. Messages defined by different vendors or by PCI-SIG are distinguished by the value in the Vendor ID field. The further differentiation of Messages defined by a particular vendor is beyond the scope of this document. Support for Messages defined by a particular vendor is implementation specific, and beyond the scope of this document. 9281 9282 9283 9284 9285 9286 9287 A data payload may be included with either type of Vendor_Defined Message (TLP type is Msg if no data payload is included or MsgD if a data payload is included) For both types of Vendor_Defined Messages, the Attr[1:0] and Attr[2] fields are not Reserved. Messages defined by different vendors or by PCI-SIG are distinguished by the value in the Vendor ID field. The further differentiation of Messages defined by a particular vendor is beyond the scope of this document. Support for Messages defined by a particular vendor is implementation specific, and beyond the scope of this document. 9288 9289 9290 Page Figure 2-28 Header for Vendor-Defined Messages 10086 9279 9280 Note 1: Transmission by Endpoint/Root Complex/ Bridge is implementation specific. Switches must forward received Messages using Routing r[2:0] field values of 000b, 010b, and 011b. 10090 10091 10092 10093 Completers silently discard Vendor_Defined Type 1 Messages which they are not designed to receive - this is not an error condition. Completers handle the receipt of an unsupported Vendor_Defined Type 0 Message as an Unsupported Request, and the error is reported according to Section 6.2 Error Signaling and Logging . 135 10094 10095 Completers silently discard Vendor_Defined Type 1 Messages that they are not designed to receive - this is not an error condition. Completers handle the receipt of an unsupported Vendor_Defined Type 0 Message as an Unsupported Request, and the error is reported according to Section 6.2 Error Signaling and Logging . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9290 Completers handle the receipt of an unsupported Vendor_Defined Type 0 Message as an Unsupported Request, and the error is reported according to Section 6.2 Error Signaling and Logging . 9291 10097 PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0 defines additional requirements for Vendor_Defined Messages that are designed to be interoperable with PCI-X Device ID Messages. This includes restrictions on the contents of the Tag[7:0] field and the Length[9:0] field as well as specific use of Bytes 12 through 15 of the message header. Vendor_Defined Messages intended for use solely within a PCI Express environment (i.e., not intended to address targets behind a PCI Express to PCI/PCI-X Bridge) are not subject to the additional rules. Refer to PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0 for details. Refer to Section 2.2.6.2 Transaction Descriptor - Transaction ID Field for considerations regarding 10-Bit Tag capability. 10098 9294 10099 9295 10100 9296 2.2.8.6.1 PCI-SIG-Defined VDMs 9298 9308 9309 PCI-SIG-Defined VDMs are Vendor-Defined Type 1 Messages that use the PCI-SIG® Vendor ID (0001h). As a Vendor-Defined Type 1 Message, each is silently discarded by a Completer if the Completer does not implement it. 10107 Beyond the rules for other Vendor-Defined Type 1 Messages, the following rules apply to the formation of the PCI-SIGDefined VDMs: 9304 9307 10105 10106 9302 9306 2.2.8.6.1 PCI-SIG-Defined VDMs 10104 PCI-SIG-Defined VDMs are Vendor-Defined Type 1 Messages that use the PCI-SIG® Vendor ID (0001h). As a Vendor-Defined Type 1 Message, each is silently discarded by a Completer if the Completer does not implement it. 9301 9305 10102 10103 9299 9303 [PCIe-to-PCI-PCI-X-Bridge-1.0] defines additional requirements for Vendor_Defined Messages that are designed to be interoperable with PCI-X Device ID Messages. This includes restrictions on the contents of the Tag[7:0] field and the Length[9:0] field as well as specific use of Bytes 12 through 15 of the message header. Vendor_Defined Messages intended for use solely within a PCI Express environment (i.e., not intended to address targets behind a PCI Express to PCI/PCI-X Bridge) are not subject to the additional rules. Refer to [PCIe-to-PCI-PCI-X-Bridge-1.0] for details. Refer to Section 2.2.6.2 Transaction Descriptor - Transaction ID Field for considerations regarding 10-Bit Tag capability. 10101 9297 9300 Completers handle the receipt of an unsupported Vendor_Defined Type 0 Message as an Unsupported Request, and the error is reported according to Section 6.2 Error Signaling and Logging . 10096 9292 9293 10095 10108 Beyond the rules for other Vendor-Defined Type 1 Messages, the following rules apply to the formation of the PCI-SIGDefined VDMs: 10109 PCI-SIG-Defined VDMs use the Header format shown in Figure 2-26 Header for PCI-SIG-Defined VDMs . The Requester ID field must contain the value associated with the Requester. The Message Code must be 01111111b. The Vendor ID must be 0001h, which is assigned to the PCI-SIG. The Subtype field distinguishes the specific PCI-SIGDefined VDMs. See Appendix F Message Code Usage for a list of PCI-SIGDefined VDMs. 10110 10111 10112 10113 10114 9310 10115 9311 10116 9312 10117 9313 10118 9314 10119 9315 9316 Figure 2-26 Header for PCI-SIG-Defined VDMs 9317 10120 9318 10121 Page 136 PCI-SIG-Defined VDMs use the Header format shown in Figure 2-29 Header for PCI-SIG-Defined VDMs . The Requester ID field must contain the value associated with the Requester. The Message Code must be 01111111b. The Vendor ID must be 0001h, which is assigned to the PCI-SIG. The Subtype field distinguishes the specific PCI-SIGDefined VDMs. See Appendix F Message Code Usage for a list of PCI-SIGDefined VDMs. Figure 2-29 Header for PCI-SIG-Defined VDMs /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9318 10121 9319 10122 9320 10123 9321 9322 10124 2.2.8.6.2 LN Messages 9323 10127 LN protocol (see Section 6.21 Lightweight Notification (LN) Protocol defines LN Messages, which are PCI-SIG-Defined VDMs. The payload of each Message generally contains the 64-bit Address of a registered cacheline that has been updated or evicted. The single 64-bit address format is used both with 64- and 32-bit addresses. Since each LN Message is a Vendor-Defined Type 1 Message, a Completer that receives a properly formed LN Message is required to silently discard it if the Completer doesn't recognize the Message. 9326 9337 9338 9339 9340 9341 9342 9343 9344 9345 9346 9347 9348 Page 10134 Beyond the rules for other PCI-SIG-Defined VDMs, the following rules apply to the formation of LN Messages: 10135 9333 9336 An LN Message can be directed to a single Endpoint using ID-based routing, or broadcast to all devices below a given Root Port. Whether a broadcast LN Message is sent to all Root Ports in the RC is implementation specific. 10133 Beyond the rules for other PCI-SIG-Defined VDMs, the following rules apply to the formation of LN Messages: 9332 9335 10131 10132 9330 9334 LN protocol (see Section 6.21 Lightweight Notification (LN) Protocol defines LN Messages, which are PCI-SIG-Defined VDMs. The payload of each Message generally contains the 64-bit Address of a registered cacheline that has been updated or evicted. The single 64-bit address format is used both with 64- and 32-bit addresses. Since each LN Message is a Vendor-Defined Type 1 Message, a Completer that receives a properly formed LN Message is required to silently discard it if the Completer doesn't recognize the Message. 10130 An LN Message can be directed to a single Endpoint using ID-based routing, or broadcast to all devices below a given Root Port. Whether a broadcast LN Message is sent to all Root Ports in the RC is implementation specific. 9329 9331 10128 10129 9327 9328 2.2.8.6.2 LN Messages 10126 9324 9325 10125 10136 Table 2-26 LN Messages and Figure 2-27 LN Message define the LN Messages. Each Message must include a 2-DW data payload. The Fmt field must be 011b (4 DW Header, with data). The TLP Type must be MsgD. The Length field must be 2. The TC[2:0] field must be 000b. Attr[2], the ID-Based Ordering (IDO) bit, is not Reserved. Attr[1], the Relaxed Ordering (RO) bit, is not Reserved. Attr[0], the No Snoop bit, is Reserved. The LN bit is Reserved (in contrast, the LN bit must be Set for LN Reads, LN Writes, and LN Completions). The Tag field is Reserved. If the LN Message is the broadcast version, the Destination ID field is Reserved. The Subtype field must be 00h. If the cacheline size in effect for the system is 128 bytes, bit 6 in the Cacheline Address must be Clear. For a Lightweight Notification Requester (LNR) receiving an LN Message, if the LNR CLS bit in the LNR Control register is Set, configuring the LNR for 128-byte cachelines, the LNR must ignore the value of bit 6 in the Cacheline Address. The Notification Reason (NR) field is encoded as shown in Table 2-25 Notification Reason (NR) Field Encodings , indicating the specific reason that the LN Message was sent. These encodings apply to 137 both the directed and broadcast versions of LN Messages. 10137 10138 10139 10140 10141 10142 10143 10144 10145 10146 10147 10148 10149 10150 10151 Table 2-27 LN Messages and Figure 2-30 LN Message define the LN Messages. Each Message must include a 2-DW data payload. The Fmt field must be 011b (4 DW Header, with data). The TLP Type must be MsgD. The Length field must be 2. The TC[2:0] field must be 000b. Attr[2], the ID-Based Ordering (IDO) bit, is not Reserved. Attr[1], the Relaxed Ordering (RO) bit, is not Reserved. Attr[0], the No Snoop bit, is Reserved. The LN bit is Reserved (in contrast, the LN bit must be Set for LN Reads, LN Writes, and LN Completions). The Tag field is Reserved. If the LN Message is the broadcast version, the Destination ID field is Reserved. The Subtype field must be 00h. If the cache line size in effect for the system is 128 bytes, bit 6 in the Cacheline Address must be Clear. For a Lightweight Notification Requester (LNR) receiving an LN Message, if the LNR CLS bit in the LNR Control register is Set, configuring the LNR for 128-byte cachelines, the LNR must ignore the value of bit 6 in the Cacheline Address. The Notification Reason (NR) field is encoded as shown in Table 2-26 Notification Reason (NR) Field Encodings , indicating the specific reason that the LN Message was sent. These encodings apply to both the directed and broadcast versions of LN Messages. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9348 The Notification Reason (NR) field is encoded as shown in Table 2-25 Notification Reason (NR) Field Encodings , indicating the specific reason that the LN Message was sent. These encodings apply to both the directed and broadcast versions of LN Messages. 10151 9349 10152 9350 10153 9351 The Notification Reason (NR) field is encoded as shown in Table 2-26 Notification Reason (NR) Field Encodings , indicating the specific reason that the LN Message was sent. These encodings apply to both the directed and broadcast versions of LN Messages. 10154 9352 Table 2-25 Notification Reason (NR) Field Encodings 9353 10155 Table 2-26 Notification Reason (NR) Field Encodings 10156 9354 NR Coding (b) 9355 10157 NR Coding (b) 10158 9356 Description 10159 9357 10160 9358 10161 9359 Description 10162 9360 00 9361 10163 00 10164 9362 LN Message was sent due to a cacheline update. 9377 10165 LN Message was sent due to a cacheline update. 10180 9378 11 9379 10181 11 10182 9380 Reserved 10183 9381 10184 9382 10185 9383 10186 9384 10187 9385 10188 9386 Reserved 10189 9387 Table 2-26 LN Messages 9388 10190 Table 2-27 LN Messages 10191 9389 Name 9390 10192 Name 10193 9391 Code[7:0] (b) 9392 10194 Code[7:0] (b) 10195 9393 Routing r[2:0] (b) 9394 10196 Routing r[2:0] (b) 10197 9395 Support 9396 10198 Support 10199 9397 Description/Comments 10200 Description/Comments 9439 tr 10242 tr 9440 10243 9441 r 9442 10244 r 10245 9443 RC broadcasts to all devices under a given Root 10246 Port. RC broadcasts to all devices under a given Root Port. 9444 10247 9445 10248 9446 10249 9447 10250 9448 10251 9449 The format of the LN Message is shown in Figure 2-27 LN Message below. Page 138 10252 The format of the LN Message is shown in Figure 2-30 LN Message below. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9449 The format of the LN Message is shown in Figure 2-27 LN 10252 Message below. The format of the LN Message is shown in Figure 2-30 LN Message below. 9450 9451 9452 10253 9453 10254 9454 10255 9455 10256 9456 Figure 2-27 LN Message 10257 9457 10258 9458 10259 9459 10260 9460 10261 9461 10262 9462 2.2.8.6.3 Device Readiness Status (DRS) Message 9463 9474 9475 9476 9477 10272 10273 10274 10275 10276 10277 10278 Table 2-28 DRS Message and Figure 2-31 DRS Message illustrate and define the DRS Message. The TLP Type must be Msg. The TC[2:0] field must be 000b. The Attr[2:0] field is Reserved. The Tag field is Reserved. The Subtype field must be 08h. The Message Routing field must be set to 100b - Local Terminate at Receiver. 10279 9479 10280 Receivers may optionally check for violations of these rules (but must not check reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 9481 9482 Beyond the rules for other PCI-SIG-Defined VDMs, the following rules apply to the formation of DRS Messages: 10271 Table 2-27 Table 2-27: DRS Message and Figure 2-28 DRS Message illustrate and define the DRS Message. The TLP Type must be Msg. The TC[2:0] field must be 000b. The Attr[2:0] field is Reserved. The Tag field is Reserved. The Subtype field must be 08h. The Message Routing field must be set to 100b - Local Terminate at Receiver. 9478 9480 10269 10270 9470 9473 The Device Readiness Status (DRS) protocol (see Section 6.23.1 Device Readiness Status (DRS) ) uses the PCI-SIG-Defined VDM mechanism (see Section 2.2.8.6.1 PCI-SIG-Defined VDMs ). The DRS Message is a PCI-SIG-Defined VDM (Vendor-Defined Type 1 Message) with no payload. 10268 Beyond the rules for other PCI-SIG-Defined VDMs, the following rules apply to the formation of DRS Messages: 9469 9472 10266 10267 9467 9471 2.2.8.6.3 Device Readiness Status (DRS) Message 10265 The Device Readiness Status (DRS) protocol (see Section 6.23.1 Device Readiness Status (DRS) ) uses the PCI-SIG-Defined VDM mechanism (see Section 2.2.8.6.1 PCI-SIG-Defined VDMs ). The DRS Message is a PCI-SIG-Defined VDM (Vendor-Defined Type 1 Message) with no payload. 9466 9468 10263 10264 9464 9465 Figure 2-30 LN Message 10281 Receivers may optionally check for violations of these rules (but must not check reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 10282 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10283 9483 10284 9484 10285 9485 9486 Page 139 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10286 Table 2-27 Table 2-27: DRS Message 10287 Table 2-28 DRS Message /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9486 Table 2-27 Table 2-27: DRS Message 9487 10287 Table 2-28 DRS Message 10288 9488 Name 9489 10289 Name 10290 9490 Code[7:0] (b) 9491 10291 Code[7:0] (b) 10292 9492 Routing r[2:0] (b) 9493 10293 Routing r[2:0] (b) 10294 9494 Support 9495 10295 Support 10296 9496 Description/Comments 10297 Description/Comments 9518 t 10319 t 9519 10320 9520 tr 9521 10321 tr 10322 9522 Device Readiness Status 10323 9523 10324 9524 10325 9525 10326 9526 10327 9527 Device Readiness Status 10328 9528 The format of the DRS Message is shown in Figure 2-28 DRS 10329 Message below: The format of the DRS Message is shown in Figure 2-31 DRS Message below: 9529 10330 9530 10331 9531 10332 9532 10333 10334 9533 9534 10336 9535 Figure 2-28 DRS Message 9536 10337 9537 10338 9538 10339 9539 10340 9540 2.2.8.6.4 Function Readiness Status (FRS) Message 9542 10341 9543 10342 The Function Readiness Status (FRS) protocol (see Section 6.23.2 Function Readiness Status (FRS) ) uses the PCI-SIG-Defined VDM mechanism (see Section 2.2.8.6.1 PCI-SIG-Defined VDMs ). The FRS message is a PCI-SIG-Defined VDM (Vendor-Defined Type 1 Message) with no payload. 9545 The Function Readiness Status (FRS) protocol (see Section 6.23.2 Function Readiness Status (FRS) ) uses the PCI-SIG-Defined VDM mechanism (see Section 2.2.8.6.1 PCI-SIG-Defined VDMs ). The FRS message is a PCI-SIG-Defined VDM (Vendor-Defined Type 1 Message) with no payload. 10345 Beyond the rules for other PCI-SIG-Defined VDMs, the following rules apply to the formation of FRS Messages: 9548 10346 Beyond the rules for other PCI-SIG-Defined VDMs, the following rules apply to the formation of FRS Messages: 10347 9549 9550 10343 10344 9546 9547 2.2.8.6.4 Function Readiness Status Message (FRS Message) 9541 9544 Figure 2-31 DRS Message 10335 10348 Table 2-28 FRS Message and Figure 2-29 FRS Message illustrate and define the FRS Message. Page 140 10349 Table 2-29 FRS Message and Figure 2-32 FRS Message illustrate and define the FRS Message. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9550 Table 2-28 FRS Message and Figure 2-29 FRS Message illustrate and define the FRS Message. 9551 10349 10350 9552 The TLP Type must be Msg. The TC[2:0] field must be 000b. The Attr[2:0] field is Reserved. The Tag field is Reserved. The Subtype field must be 09h. The FRS Reason[3:0] field indicates why the FRS Message 9553 9554 9555 9556 9557 10351 10353 10354 10355 10356 was generated: 9558 10357 9559 0001b: DRS Message Received 9560 0001b: DRS Message Received 10381 The Message Routing field must be Cleared to 000b Routed to Root Complex 9584 10382 The Message Routing field must be Cleared to 000b Routed to Root Complex 10383 9585 10384 Receivers may optionally check for violations of these rules (but must not check reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 9587 9588 10358 10359 9582 9586 The TLP Type must be Msg. The TC[2:0] field must be 000b. The Attr[2:0] field is Reserved. The Tag field is Reserved. The Subtype field must be 09h. The FRS Reason[3:0] field indicates why the FRS Message 10352 was generated: 9583 Table 2-29 FRS Message and Figure 2-32 FRS Message illustrate and define the FRS Message. 10385 Receivers may optionally check for violations of these rules (but must not check reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 10386 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10387 9589 10388 9590 10389 9591 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10390 9592 Table 2-28 FRS Message 9593 10391 Table 2-29 FRS Message 10392 9594 Name 9595 10393 Name 10394 9596 Code[7:0] (b) 9597 10395 Code[7:0] (b) 10396 9598 Routing r[2:0] (b) 9599 10397 Routing r[2:0] (b) 10398 9600 Support 9601 10399 Support 10400 9602 Description/Comments 10401 Description/Comments 9624 t 10423 t 9625 10424 9626 tr 9627 10425 tr 10426 9628 Function Readiness Status 10427 9629 10428 9630 10429 9631 10430 9632 10431 9633 Function Readiness Status 10432 9634 The format of the FRS Message is shown in Figure 2-29 FRS Message below: Page 141 10433 The format of the FRS Message is shown in Figure 2-32 FRS Message below: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9634 The format of the FRS Message is shown in Figure 2-29 FRS 10433 Message below: The format of the FRS Message is shown in Figure 2-32 FRS Message below: 9635 9636 10434 9637 10435 9638 10436 9639 10437 9640 10438 9641 9642 10439 9643 10440 9644 10441 9645 10442 9646 10443 9647 2.2.8.6.5 Hierarchy ID Message 9648 9659 9660 9661 9662 9663 9664 10454 10455 10456 10457 10458 10459 10460 10461 Table 2-30 Hierarchy ID Message and Figure 2-33 Hierarchy ID Message illustrate and define the Hierarchy ID Message. The TLP Type must be MsgD. Each Message must include a 4-DWORD data payload. The Length field must be 4. The TC[2:0] field must be 000b. The Attr[2:0] field is Reserved. The Tag field is Reserved. The Subtype field is 01h. The Message Routing field must be 011b - Broadcast from Root Complex. 10463 Receivers may optionally check for violations of these rules (but must not check reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 9668 10464 Receivers may optionally check for violations of these rules (but must not check reserved bits). These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If a Receiver implementing these checks determines that a TLP violates these rules, the TLP is a Malformed TLP. 10465 9669 10466 1. If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 9671 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10467 9672 9673 10453 10462 9666 9670 Beyond the rules for other PCI-SIG-Defined VDMs, the following rules apply to the formation of Hierarchy ID Messages: 10452 Table 2-29 Hierarchy ID Message and Figure 2-30 Hierarchy ID Message illustrate and define the Hierarchy ID Message. The TLP Type must be MsgD. Each Message must include a 4-DWORD data payload. The Length field must be 4. The TC[2:0] field must be 000b. The Attr[2:0] field is Reserved. The Tag field is Reserved. The Subtype field is 01h. The Message Routing field must be 011b - Broadcast from Root Complex. 9665 9667 10450 10451 9655 9658 Hierarchy ID uses the PCI-SIG-Defined VDM mechanism (see Section 2.2.8.6.1 PCI-SIG-Defined VDMs ). The Hierarchy ID Message is a PCI-SIG-Defined VDM (Vendor-Defined Type 1 Message) with payload (MsgD). 10449 Beyond the rules for other PCI-SIG-Defined VDMs, the following rules apply to the formation of Hierarchy ID Messages: 9654 9657 10447 10448 9652 9656 2.2.8.6.5 Hierarchy ID Message 10446 Hierarchy ID uses the PCI-SIG-Defined VDM mechanism (see Section 2.2.8.6.1 PCI-SIG-Defined VDMs ). The Hierarchy ID Message is a PCI-SIG-Defined VDM (Vendor-Defined Type 1 Message) with payload (MsgD). 9651 9653 10444 10445 9649 9650 Figure 2-32 FRS Message Figure 2-29 FRS Message 10468 The payload of each Hierarchy ID Message contains the lower 128-bits of the System GUID. Page 142 10469 The payload of each Hierarchy ID Message contains the lower 128-bits of the System GUID. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9673 The payload of each Hierarchy ID Message contains the lower 128-bits of the System GUID. 9674 The payload of each Hierarchy ID Message contains the lower 128-bits of the System GUID. 10470 9675 9676 10469 10471 For details of the Hierarchy ID, GUID Authority ID, and System GUID fields see Section 6.26 Hierarchy ID Message . 10472 9677 10473 9678 10474 9679 For details of the Hierarchy ID, GUID Authority ID, and System GUID fields see Section 6.26 Hierarchy ID Message . 10475 9680 Table 2-29 Hierarchy ID Message 9681 10476 Table 2-30 Hierarchy ID Message 10477 9682 Name 9683 10478 Name 10479 9684 Code[7:0] (b) 9685 10480 Code[7:0] (b) 10481 9686 Routing r[2:0] (b) 9687 10482 Routing r[2:0] (b) 10483 9688 Support 9689 10484 Support 10485 9690 Description/Comments 10486 Description/Comments 9712 r 10508 r 9713 10509 9714 tr 9715 10510 9716 Hierarchy ID 10512 9717 10513 9718 10514 9719 10515 9720 10516 9721 9722 Hierarchy ID 10517 The format of the Hierarchy ID Message is shown in Figure 2-30 Hierarchy ID Message below: 10518 9723 10519 9724 10520 9725 10521 9726 The format of the Hierarchy ID Message is shown in Figure 2-33 Hierarchy ID Message below: 10522 9727 Figure 2-30 Hierarchy ID Message 10523 9728 10524 9729 10525 9730 10526 9731 10527 9732 10528 9733 Figure 2-33 Hierarchy ID Message 10529 9734 2.2.8.7 Ignored Messages 9735 10530 2.2.8.7 Ignored Messages 10531 9736 9737 tr 10511 10532 The messages listed in were previously used for a mechanism (Hot-Plug Signaling) that is no longer supported. Transmitters are strongly encouraged not to transmit these messages, but if message transmission is implemented, it must conform to the requirements of the 1.0a version of this specification. Page 143 10533 The messages listed in were previously used for a mechanism (Hot-Plug Signaling) that is no longer supported. Transmitters are strongly encouraged not to transmit these messages, but if message transmission is implemented, it must conform to the requirements of the 1.0a version of this specification. 9737 The messages listed in were previously used for a mechanism /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. are (Hot-Plug Signaling) that is no longer supported. Transmitters strongly encouraged not to transmit these messages, but if message /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html transmission is implemented, it must conform to the requirements of the 10533 1.0a version of this specification. 9738 10534 9739 9740 10535 Receivers are strongly encouraged to ignore receipt of these messages, but are allowed to process these messages in conformance with the requirements of 1.0a version of this specification. 9741 9746 10539 10541 10542 10543 9748 10544 9749 Table 2-30 Ignored Messages 9751 10546 Name 9753 10548 Name 10549 9754 Code[7:0] (b) 9755 10550 Code[7:0] (b) 10551 9756 Routing r[2:0] (b) 9757 10552 Routing r[2:0] (b) 10553 9758 Support 9759 10554 Support 10555 9760 Description/Comments 10556 9830 10626 9831 10627 9832 10628 9833 Description/Comments 10629 9834 2.2.8.8 Latency Tolerance Reporting (LTR) Message 9835 10630 2.2.8.8 Latency Tolerance Reporting (LTR) Message 10631 9836 10632 The LTR Message is optionally used to report device behaviors regarding its tolerance of Read/Write service latencies. Refer to Section 6.18 Latency Tolerance Reporting (LTR) Mechanism for details on LTR. The following rules apply to the formation of the LTR Message: 9838 10633 The LTR Message is optionally used to report device behaviors regarding its tolerance of Read/Write service latencies. Refer to Section 6.18 Latency Tolerance Reporting (LTR) Mechanism for details on LTR. The following rules apply to the formation of the LTR Message: 10634 9839 10635 9840 Table 2-31 LTR Message defines the LTR Message. The LTR Message does not include a data payload (the TLP 10636 The Length field is Reserved. The LTR Message must use the default Traffic Class designator (TC0). Receivers that implement LTR support must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10638 9841 Page 144 Table 2-32 LTR Message defines the LTR Message. The LTR Message does not include a data payload (the TLP 10637 Type is Msg). 9844 Table 2-31 Ignored Messages 10547 9752 9843 The Physical and Data Link Layers must handle these messages identical to handling any other TLP. The Transaction Layer must account for flow control credit but take no other action in response to these messages. 10545 9750 9842 Ignored messages listed in Table 2-31 Ignored Messages are handled by the Receiver as follows: 10540 The Physical and Data Link Layers must handle these messages identical to handling any other TLP. The Transaction Layer must account for flow control credit but take no other action in response to these messages. 9747 9837 Receivers are strongly encouraged to ignore receipt of these messages, but are allowed to process these messages in conformance with the requirements of 1.0a version of this specification. 10538 Ignored messages listed in Table 2-30 Ignored Messages are handled by the Receiver as follows: 9744 9745 10536 10537 9742 9743 The messages listed in were previously used for a mechanism (Hot-Plug Signaling) that is no longer supported. Transmitters are strongly encouraged not to transmit these messages, but if message transmission is implemented, it must conform to the requirements of the 1.0a version of this specification. Type is Msg). 10639 10640 The Length field is Reserved. The LTR Message must use the default Traffic Class designator (TC0). Receivers that implement LTR support must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9844 This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10640 9845 10641 9846 10642 9847 10643 9848 10644 9849 Table 2-31 LTR Message 9850 10645 Table 2-32 LTR Message 10646 9851 Name 9852 10647 Name 10648 9853 Code[7:0] (b) 9854 10649 Code[7:0] (b) 10650 9855 Routing r[2:0] (b) 9856 9857 This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10651 Routing r[2:0] (b) 10652 Support [Footnote: Support for LTR is optional. Functions that support LTR must implement the reporting and enable mechanisms described in Chapter 7 Software Initialization and Configuration .] 9858 9859 10653 10654 Description/Comments 10655 9860 10656 9861 10657 9862 9863 Description/Comments 10658 RC 9864 9865 Support1 10659 RC 10660 Ep 9866 10661 Ep 10662 9867 Sw 10663 Sw 9879 r 10675 r 9880 9881 10676 t 9882 9883 t 10678 tr 9884 9885 10677 10679 tr 10680 Latency Tolerance Reporting 10681 9886 10682 9887 10683 9888 10684 10685 10686 Latency Tolerance Reporting Notes: Support for LTR is optional. Functions that support LTR must implement the reporting and enable mechanisms described in Chapter 7 Software Initialization and Configuration . 10687 9889 10688 9890 10689 9891 10690 9892 10691 9893 10692 9894 9895 10693 Figure 2-31 LTR Message 10694 10695 Page 145 Figure 2-34 LTR Message /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10695 9896 10696 9897 10697 9898 10698 9899 10699 9900 10700 9901 2.2.8.9 Optimized Buffer Flush/Fill (OBFF) Message 9902 10701 10703 The OBFF Message is optionally used to report platform central resource states to Endpoints. This mechanism is described in detail in Section 6.19 Optimized Buffer Flush/Fill (OBFF) Mechanism . 9905 10704 10706 9907 The following rules apply to the formation of the OBFF 10707 Message: The following rules apply to the formation of the OBFF Message: 9908 10708 9909 10709 9910 9911 Table 2-32 OBFF Message defines the OBFF Message. The OBFF Message does not include a data payload (TLP Type 10710 The Length field is Reserved. The Requester ID must be set to the Transmitting Port's 10712 9913 Table 2-33 OBFF Message defines the OBFF Message. The OBFF Message does not include a data payload (TLP Type 10711 is Msg). 9912 is Msg). The Length field is Reserved. The Requester ID must be set to the Transmitting Port's 10713 ID. ID. The OBFF Message must use the default Traffic Class designator (TC0). Receivers that implement OBFF support must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. 9915 9916 The OBFF Message is optionally used to report platform central resource states to Endpoints. This mechanism is described in detail in Section 6.19 Optimized Buffer Flush/Fill (OBFF) Mechanism . 10705 9906 9914 2.2.8.9 Optimized Buffer Flush/Fill (OBFF) Message 10702 9903 9904 Figure 2-34 LTR Message 10714 The OBFF Message must use the default Traffic Class designator (TC0). Receivers that implement OBFF support must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. 10715 This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10716 9917 10717 9918 10718 9919 10719 9920 9921 10720 Table 2-32 OBFF Message 9922 9923 Name Code[7:0] (b) 10723 Name 10725 Code[7:0] (b) 10726 Routing r[2:0] (b) 9928 9929 Table 2-33 OBFF Message 10724 9926 9927 10721 10722 9924 9925 This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10727 Routing r[2:0] (b) 10728 Support1 9930 10729 Support1 10730 9931 Description/Comments 10731 Description/Comments 9951 t 10751 t 9952 9953 10752 r 9954 9955 Page 146 10753 r 10754 tr 10755 tr /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9955 tr 9956 10755 9957 Optimized Buffer Flush/Fill 10757 9958 10758 9959 10759 9960 9961 tr 10756 Optimized Buffer Flush/Fill 10760 Note 1: Support for OBFF is optional. Functions that support OBFF must implement the reporting and enable mechanisms described in Chapter 7 Software Initialization and Configuration , Software Initialization and Configuration. 10761 10762 9962 9963 10763 9964 10764 9965 10765 9966 10766 9967 10767 9968 10768 9969 10769 9970 Notes: Support for OBFF is optional. Functions that support OBFF must implement the reporting and enable mechanisms described in Chapter 7 Software Initialization and Configuration , Software Initialization and Configuration. 10770 9971 Figure 2-32 OBFF Message 10771 9972 10772 9973 10773 9974 10774 9975 10775 9976 Figure 2-35 OBFF Message 10776 9977 2.2.8.10 Precision Time Measurement (PTM) Messages 9978 10777 2.2.8.10 Precision Time Measurement (PTM) Messages 10778 9979 10779 9980 Table 2-33 Precision Time Measurement Messages defines the 10780 PTM Messages. Table 2-34 Precision Time Measurement Messages defines the PTM Messages. 9981 9982 9983 q The PTM Request and PTM Response Messages must use a TLP Type of Msg, and must not include a data payload. The Length field is reserved. 9984 9985 9986 Figure 2-33 PTM Request/Response Message illustrates the format of the PTM Request and Response Messages. 9987 9988 9989 10781 q The PTM ResponseD Message must use a TLP Type of MsgD, and must include a 64 bit PTM Master Time field in bytes 8 through 15 of the TLP header and a 1 DW data payload containing the 32 bit Propagation Delay field. 9990 10782 10783 10784 9991 9992 The PTM Request and PTM Response Messages must use a TLP Type of Msg, and must not include a data payload. The Length field is reserved. Figure 2-36 PTM Request/Response Message illustrates the format of the PTM Request and Response Messages. 10785 Figure 2-34 PTM ResponseD Message (4 DW header and 1 DW payload) illustrates the format of the PTM ResponseD Message. Page 147 10786 The PTM ResponseD Message must use a TLP Type of MsgD, and must include a 64 bit PTM Master Time field in bytes 8 through 15 of the TLP header and a 1 DW data payload containing the 32 bit Propagation Delay field. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 9992 Figure 2-34 PTM ResponseD Message (4 DW header and 1 DW 9993 10786 payload) illustrates the format of the PTM ResponseD Message. Refer to section 6.22.3.2 for details regarding how to populate the PTM ResponseD Message. 9994 10787 10788 10789 9995 q The Requester ID must be set to the Transmitting Port's 10791 ID. The Requester ID must be set to the Transmitting Port's ID. 9997 10792 9998 q A PTM dialog is defined as a matched pair of messages consisting of a PTM Request and the corresponding PTM Response or PTM ResponseD message. 10793 10000 10001 10002 Figure 2-37 PTM ResponseD Message (4 DW header and 1 DW payload) illustrates the format of the PTM ResponseD Message. Refer to Section 6.22.3.2 PTM Responder Role for details regarding how to populate the PTM ResponseD Message. 10790 9996 9999 The PTM ResponseD Message must use a TLP Type of MsgD, and must include a 64 bit PTM Master Time field in bytes 8 through 15 of the TLP header and a 1 DW data payload containing the 32 bit Propagation Delay field. A PTM dialog is defined as a matched pair of messages consisting of a PTM Request and the corresponding PTM Response or PTM ResponseD message. The PTM Messages must use the default Traffic Class designator (TC0). Receivers implementing PTM must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. q The PTM Messages must use the default Traffic Class designator (TC0). Receivers implementing PTM must check for violations of this rule. If a Receiver determines that a TLP violates this rule, it must handle the TLP as a Malformed TLP. 10003 10004 This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10794 10005 10795 10006 10796 10007 This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10797 10008 Table 2-33 Precision Time Measurement Messages 10798 10799 10009 Table 2-34 Precision Time Measurement Messages 10800 10010 Name 10011 10801 Name 10802 10012 TLP Type 10013 10803 TLP Type 10804 10014 Code[7:0] (b) 10015 10805 Code[7:0] (b) 10806 10016 Routing r[2:0] (b) 10017 10807 Routing r[2:0] (b) 10808 10018 Support 10809 Support 10082 tr 10873 tr 10083 10874 10084 Completes current PTM dialog - carries timing 10875 information 10085 10876 10086 10877 10087 10878 10088 10879 10089 10880 10090 10881 10091 10882 Page 148 Completes current PTM dialog - carries timing information /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10091 10882 10092 10883 Figure 2-36 PTM Request/Response Message 10093 10094 Figure 2-33 PTM Request/Response Message 10095 10884 10096 10885 10097 10886 10098 10887 10099 10888 10100 10889 10101 Figure 2-37 PTM ResponseD Message (4 DW header and 1 DW payload) 10102 Figure 2-34 PTM ResponseD Message (4 DW header and 1 DW payload) 10103 10890 10104 10891 10105 10892 10106 10893 10107 10894 10108 10895 10109 2.2.9 Completion Rules 10110 10898 All Read, Non-Posted Write, and AtomicOp Requests require Completion. Completions include a Completion header that, for some types of Completions, will be followed by some number of DW of data. The rules for each of the fields of the Completion header are defined in the following sections. 10113 10114 10115 10118 10119 10120 10123 10124 All Read, Non-Posted Write, and AtomicOp Requests require Completion. Completions include a Completion header that, for some types of Completions, will be followed by some number of DWs of data. The rules for each of the fields of the Completion header are defined in the following sections. 10901 10902 Completions route by ID, and use a 3 DW header. Note that the routing ID fields correspond directly to the Requester ID supplied with the corresponding Request. Thus for Completions these fields will be referred to collectively as the Requester ID instead of the distinct fields used generically for ID routing. 10903 In addition to the header fields included in all TLPs and the ID routing fields, Completions contain the following additional fields (see Figure 2-35 Completion Header Format ): Completer ID[15:0] - Identifies the Completer - described in detail below Completion Status[2:0] - Indicates the status for a Completion (see Table 2-34 Completion Status Field Values ) Rules for determining the value in the Completion Status[2:0] field are in Section 2.3.1 Request Handling Rules . 10121 10122 10899 10900 Completions route by ID, and use a 3 DW header. Note that the routing ID fields correspond directly to the Requester ID supplied with the corresponding Request. Thus for Completions these fields will be referred to collectively as the Requester ID instead of the distinct fields used generically for ID routing. 10116 10117 2.2.9 Completion Rules 10897 10111 10112 10896 10904 10905 10906 10907 In addition to the header fields included in all TLPs and the ID routing fields, Completions contain the following additional fields (see Figure 2-38 Completion Header Format ): Completer ID[15:0] - Identifies the Completer - described in detail below Completion Status[2:0] - Indicates the status for a Completion (see Table 2-35 Completion Status Field Values ) Rules for determining the value in the Completion Status[2:0] field are in Section 2.3.1 Request Handling Rules . 10908 BCM - Byte Count Modified - this bit must not be set by PCI Express Completers, and may only be set by PCI-X completers Byte Count[11:0] - The remaining Byte Count for Request The Byte Count value is specified as a binary number, with 0000 0000 0001b indicating 1 byte, 1111 1111 1111b indicating 4095 bytes, and 0000 0000 0000b indicating 4096 bytes. Page 149 10909 10910 10911 BCM - Byte Count Modified - this bit must not be set by PCI Express Completers, and may only be set by PCI-X completers Byte Count[11:0] - The remaining Byte Count for Request The Byte Count value is specified as a binary number, with 0000 0000 0001b indicating 1 byte, 1111 1111 1111b indicating 4095 bytes, and 0000 0000 0000b indicating 4096 bytes. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 10124 The Byte Count value is specified as a binary number, /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html with 0000 0000 0001b indicating 1 byte, 1111 1111 1111b indicating 4095 10125 10126 10127 bytes, and 0000 0000 0000b indicating 4096 bytes. For Memory Read Completions, Byte Count[11:0] is set according to the rules in Section 2.3.1.1 Data Return for Read Requests . For AtomicOp Completions, the Byte Count value must equal the associated AtomicOp operand size in bytes. For all other types of Completions, the Byte Count value must be 4. 10128 10129 10130 10131 10132 10133 10911 10912 10913 10914 The Byte Count value is specified as a binary number, with 0000 0000 0001b indicating 1 byte, 1111 1111 1111b indicating 4095 bytes, and 0000 0000 0000b indicating 4096 bytes. For Memory Read Completions, Byte Count[11:0] is set according to the rules in Section 2.3.1.1 Data Return for Read Requests . For AtomicOp Completions, the Byte Count value must equal the associated AtomicOp operand size in bytes. For all other types of Completions, the Byte Count value must be 4. 10915 Tag[9:0] - in combination with the Requester ID field, corresponds to the Transaction ID Lower Address[6:0] - lower byte address for starting byte of Completion For Memory Read Completions, the value in this field is the byte address for the first enabled byte of data returned with the Completion (see the rules in Section 2.3.1.1 Data Return for Read Requests ). For AtomicOp Completions, the Lower Address field is Reserved. This field is set to all 0's for all remaining types of Completions. Receivers may optionally check for violations of this rule. See Section 2.3.2 Completion Handling Rules , second bullet, for details. 10916 10917 10918 10919 10920 10134 10921 10135 10922 10136 10923 10137 10924 10138 10925 10139 10926 10140 10927 Tag[9:0] - in combination with the Requester ID field, corresponds to the Transaction ID Lower Address[6:0] - lower byte address for starting byte of Completion For Memory Read Completions, the value in this field is the byte address for the first enabled byte of data returned with the Completion (see the rules in Section 2.3.1.1 Data Return for Read Requests ). For AtomicOp Completions, the Lower Address field is Reserved. This field is set to all 0's for all remaining types of Completions. Receivers may optionally check for violations of this rule. See Section 2.3.2 Completion Handling Rules , second bullet, for details. Figure 2-38 Completion Header Format 10141 10142 Figure 2-35 Completion Header Format 10143 10928 10144 10929 10145 10930 10146 10147 10931 Table 2-34 Completion Status Field Values 10148 10149 10150 Completion Status[2:0] Field Value (b) 10934 10935 10937 10938 10154 10939 10155 10941 000 10942 Successful Completion (SC) 10943 10159 10944 10177 10962 10178 10963 Page 150 Completion Status 10940 000 10157 10158 Cpl. Status[2:0] Field Value (b) 10936 Completion Status 10153 10156 Table 2-35 Completion Status Field Values 10933 10151 10152 10932 Successful Completion (SC) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10178 10963 10179 10964 10180 all others 10181 10965 10182 Reserved 10967 10183 10968 10184 10969 10185 10970 10186 10187 all others 10966 Reserved 10971 The Completer ID[15:0] is a 16-bit value that is unique for every PCI Express Function within a Hierarchy (see Figure 2-36 (Non-ARI) Completer ID and Figure 2-37 ARI Completer ID ) 10972 The Completer ID[15:0] is a 16-bit value that is unique for every PCI Express Function within a Hierarchy (see Figure 2-39 (Non-ARI) Completer ID and Figure 2-40 ARI Completer ID ) 10188 10189 10190 10191 10192 Figure 2-36 (Non-ARI) Completer ID 10193 10973 10194 10974 10195 10975 10196 10976 10977 10197 Figure 2-39 (Non-ARI) Completer ID 10978 10198 Issue 1 10199 10979 10200 10980 10201 Remove whitespace from artwork so it's centered in the page. 10202 10981 10203 10982 10204 10983 Figure 2-40 ARI Completer ID 10205 10206 10207 10208 Figure 2-37 ARI Completer ID 10209 10984 10210 10211 10212 10213 Page 10985 Functions must capture the Bus and Device Numbers [Footnote: With ARI Devices, Functions are only required to capture the Bus Number. ARI Devices are permitted to retain the captured Bus Number on either a per-Device or a per-Function basis. See Section 2.2.6.2 Transaction Descriptor - Transaction ID Field .] supplied with all Type 0 Configuration Write Requests completed by the Function, and supply these numbers in the Bus and Device Number fields of the Completer ID [Footnote: An ARI Completer ID does not contain a Device Number field. See Section 2.2.4.2 ID Based Routing Rules .] for all Completions generated by the Device/Function. If a Function must generate a Completion prior to the initial device Configuration Write Request, 0's must be entered into the Bus Number and Device Number fields Note that Bus Number and Device Number may be changed at run time, and so it is necessary to re-capture this information with each and every Configuration Write Request. 151 10986 10987 10988 Functions must capture the Bus and Device Numbers [Footnote: With ARI Devices, Functions are only required to capture the Bus Number. ARI Devices are permitted to retain the captured Bus Number on either a per-Device or a per-Function basis. See Section 2.2.6.2 Transaction Descriptor - Transaction ID Field .] supplied with all Type 0 Configuration Write Requests completed by the Function, and supply these numbers in the Bus and Device Number fields of the Completer ID [Footnote: An ARI Completer ID does not contain a Device Number field. See Section 2.2.4.2 ID Based Routing Rules .] for all Completions generated by the Device/Function. If a Function must generate a Completion prior to the initial device Configuration Write Request, 0's must be entered into the Bus Number and Device Number fields Note that Bus Number and Device Number may be changed at run time, and so it is necessary to re-capture this information with each and every Configuration Write Request. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10213 10214 Note that Bus Number and Device Number may be changed at run time, and so it is necessary to re-capture this information with each and every Configuration Write Request. Exception: The assignment of Bus Numbers to the Devices within a Root Complex may be done in an implementation specific way. 10215 10216 10217 10220 10989 Note that Bus Number and Device Number may be changed at run time, and so it is necessary to re-capture this information with each and every Configuration Write Request. Exception: The assignment of Bus Numbers to the Devices within a Root Complex may be done in an implementation specific way. 10990 In some cases, a Completion with the UR status may be generated by a Multi-Function Device without associating the Completion with a specific Function within the device - in this case, the Function Number field [Footnote: Note: with an ARI Completer ID, the Function Number field is 8 bits.] is Reserved. Example: A Multi-Function Device receives a Read Request which does not target any resource associated with any of the Functions of the device - the device generates a Completion with UR status and sets a value of all 0's in the Function Number field of the Completer ID. 10218 10219 10988 10991 10992 In some cases, a Completion with UR status may be generated by an MFD without associating the Completion with a specific Function within the device - in this case, the Function Number field [Footnote: Note: with an ARI Completer ID, the Function Number field is 8 bits.] is Reserved. Example: An MFD receives a Read Request that does not target any resource associated with any of the Functions of the device the device generates a Completion with UR status and sets a value of all 0's in the Function Number field of the Completer ID. 10993 Completion headers must supply the same values for the Requester ID, Tag, and Traffic Class as were supplied in the header of the corresponding Request. Completion headers must supply the same values for the Attribute as were supplied in the header of the corresponding Request, except as explicitly allowed when IDO is used (see Section 2.2.6.4 Relaxed Ordering and ID-Based Ordering Attributes ). 10994 10995 10996 10997 Completion headers must supply the same values for the Requester ID, Tag, and Traffic Class as were supplied in the header of the corresponding Request. Completion headers must supply the same values for the Attribute as were supplied in the header of the corresponding Request, except as explicitly allowed: when IDO is used (see Section 2.2.6.4 Relaxed Ordering and ID-Based Ordering Attributes ) when RO is used in a Translation Completion (see Section 10.2.3 Translation Completion 10998 10221 10222 10223 If the Completer is an LN Completer (LNC)and the targeted memory region supports registrations, the following rules apply; otherwise the LN bit must be Clear. If the Completion Status is Successful Completion and the associated Request was an LN Read, the LN bit must be Set. Otherwise the LN bit must be Clear. 10224 10225 10226 10227 10228 10229 10999 11000 11001 If the Completer is an LN Completer (LNC)and the targeted memory region supports registrations, the following rules apply; otherwise the LN bit must be Clear. If the Completion Status is Successful Completion and the associated Request was an LN Read, the LN bit must be Set. Otherwise the LN bit must be Clear. 11002 The TH bit is reserved for Completions. AT[1:0] must be 00b. Receivers are not required or encouraged to check this. The Completion ID field is not meaningful prior to the software initialization and configuration of the completing device (using at least one Configuration Write Request), and for this case the Requester must ignore the value returned in the Completer ID field. A Completion including data must specify the actual amount of data returned in that Completion, and must include the amount of data specified. It is a TLP formation error to include more or less data than specified in the Length field, and the resulting TLP is a Malformed TLP. 11003 11004 11005 11006 11007 10230 11008 10255 11033 10256 11034 10257 11035 Page 152 The TH bit is reserved for Completions. AT[1:0] must be 00b. Receivers are not required or encouraged to check this. The Completion ID field is not meaningful prior to the software initialization and configuration of the completing device (using at least one Configuration Write Request), and for this case the Requester must ignore the value returned in the Completer ID field. A Completion including data must specify the actual amount of data returned in that Completion, and must include the amount of data specified. It is a TLP formation error to include more or less data than specified in the Length field, and the resulting TLP is a Malformed TLP. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10257 11035 10258 2.2.10.1 Local TLP Prefix Processing 10259 11038 10261 The following rules apply to Local TLP Prefixes: 10262 10264 10265 11039 Local TLP Prefix types are determined using the L[3:0] subfield of the Type field Type[4] must be 0b Local TLP Prefix L[3:0] values are defined in Table 2-35 Local TLP Prefix Types 11041 11042 11043 11044 10267 11045 10268 11046 10269 Table 2-35 Local TLP Prefix Types 10271 11048 Local TLP Prefix Type 10273 11050 Local TLP Prefix Type 11051 10274 L[3:0] (b) 10275 11052 L[3:0] (b) 11053 10276 Description 11054 10277 11055 10278 11056 10279 Description 11057 10280 MR-IOV 10281 11058 MR-IOV 11059 10282 0000 10283 11060 0000 11061 MR-IOV TLP Prefix - Refer to the Multi-Root I/O Virtualization and Sharing specification for details. 11062 11063 10286 11064 10287 MR-IOV TLP Prefix - Refer to [MR-IOV] specification for details. 10285 11065 10288 VendPrefixL0 10289 11066 VendPrefixL0 11067 10290 1110 10291 11068 1110 11069 Vendor Defined Local TLP Prefix - Refer to Section 2.2.10.1.1 Vendor Defined Local TLP Prefix for further details. 11070 10293 11071 10294 11072 10308 10310 Table 2-36 Local TLP Prefix Types 11049 10272 10309 Local TLP Prefix types are determined using the L[3:0] subfield of the Type field Type[4] must be 0b Local TLP Prefix L[3:0] values are defined in Table 2-36 Local TLP Prefix Types 11047 10270 10292 The following rules apply to Local TLP Prefixes: 11040 10266 10284 2.2.10.1 Local TLP Prefix Processing 11037 10260 10263 11036 Vendor Defined Local TLP Prefix - Refer to Section 2.2.10.1.1 Vendor Defined Local TLP Prefix for further details. 11086 The size, routing, and flow control rules are specific to each Local TLP Prefix type. It is an error to receive a TLP with a Local TLP Prefix type not supported by the Receiver. If the Extended Fmt Field Supported bit is Set, TLPs in violation of this rule are handled as a Malformed TLP unless explicitly stated differently in another specification. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). If the Extended Fmt Field Supported bit is Clear, behavior is device specific. Page 153 11087 11088 The size, routing, and flow control rules are specific to each Local TLP Prefix type. It is an error to receive a TLP with a Local TLP Prefix type not supported by the Receiver. If the Extended Fmt Field Supported bit is Set, TLPs in violation of this rule are handled as a Malformed TLP unless explicitly stated differently in another specification. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). If the Extended Fmt Field Supported bit is Clear, behavior is device specific. 10310 11088 It is an error to receive a TLP with a Local TLP Prefix type not supported by the Receiver. If the Extended Fmt Field Supported /private/tmp/PCISIG/pcie4_combined-snapshot.html bit is Set, TLPs in violation of this rule are handled as vs. a Malformed TLP unless explicitly stated differently in another specification. This is a /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). If the Extended Fmt Field Supported bit is Clear, behavior is device specific. 10311 11089 No Local TLP Prefixes are protected by ECRC even if the underlying TLP is protected by ECRC. 10312 11090 10313 11091 10314 11092 10315 2.2.10.1.1 Vendor Defined Local TLP Prefix 10316 10321 10322 11096 11098 11099 11100 11101 10324 11102 10325 11103 10326 11104 10327 2.2.10.2 End-End TLP Prefix Processing 10329 11106 2.2.10.2 End-End TLP Prefix Processing 11107 10330 11108 10331 The following rules apply to End-End TLP Prefixes 10332 10335 Components must not send TLPs containing Vendor Defined Local TLP Prefixes unless this has been explicitly enabled (using vendorspecific mechanisms). Components that support any usage of Vendor Defined Local TLP Prefixes must support the 3-bit definition of the Fmt field and have the Extended Fmt Field Supported bit Set (see Section 7.5.3.15 Device Capabilities 2 Register (Offset 24h) ). It is recommended that components be configurable (using vendor-specific mechanisms) so that all vendor defined prefixes can be sent using either of the two Vendor Defined Local TLP Prefix encodings. Such configuration need not be symmetric (for example each end of a Link could transmit the same Prefix using a different encoding). 11105 10328 10334 As described in Table 2-36 Local TLP Prefix Types , Types VendPrefixL0 and VendPrefixL1 are Reserved for use as Vendor Defined Local TLP Prefixes. To maximize interoperability and flexibility the following rules are applied to such prefixes: 11097 Components must not send TLPs containing Vendor Defined Local TLP Prefixes unless this has been explicitly enabled (using vendorspecific mechanisms). Components that support any usage of Vendor Defined Local TLP Prefixes must support the 3-bit definition of the Fmt field and have the Extended Fmt Field Supported bit Set (see Section 7.5.3.15 Device Capabilities 2 Register (Offset 24h) ). It is recommended that components be configurable (using vendor-specific mechanisms) so that all vendor defined prefixes can be sent using either of the two Vendor Defined Local TLP Prefix encodings. Such configuration need not be symmetric (for example each end of a Link could transmit the same Prefix using a different encoding). 10323 10333 2.2.10.1.1 Vendor Defined Local TLP Prefix 11095 As described in Table 2-35 Local TLP Prefix Types , Types VendPrefixL0 and VendPrefixL1 are Reserved for use as Vendor Defined Local TLP Prefixes. To maximize interoperability and flexibility the following rules are applied to such prefixes: 10319 10320 11093 11094 10317 10318 It is an error to receive a TLP with a Local TLP Prefix type not supported by the Receiver. If the Extended Fmt Field Supported bit is Set, TLPs in violation of this rule are handled as a Malformed TLP unless explicitly stated differently in another specification. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). If the Extended Fmt Field Supported bit is Clear, behavior is device specific. No Local TLP Prefixes are protected by ECRC even if the underlying TLP is protected by ECRC. 11109 The following rules apply to End-End TLP Prefixes 11110 End-End TLP Prefix types are determined using the E[3:0] subfield of the Type field Type[4] must be 1b End-End TLP Prefix E[3:0] values are defined in Table 2-36 End-End TLP Prefix Types 11111 11112 11113 10336 11114 10337 11115 10338 11116 10339 10340 11117 Table 2-36 End-End TLP Prefix Types 10341 10342 Page 154 11118 Table 2-37 End-End TLP Prefix Types 11119 End-End TLP Prefix Type 10343 10344 End-End TLP Prefix types are determined using the E[3:0] subfield of the Type field Type[4] must be 1b End-End TLP Prefix E[3:0] values are defined in Table 2-37 End-End TLP Prefix Types 11120 End-End TLP Prefix Type 11121 E[3:0] (b) 11122 E[3:0] (b) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10344 E[3:0] (b) 10345 11122 10346 Description 11124 10347 11125 10348 11126 10349 TPH 10351 11128 0000 10353 11130 TPH - Refer to Section 2.2.10.2 End-End TLP Prefix Processing and 6.17 for further details. 11132 11133 10356 11134 10357 PASID 10359 11136 PASID 11137 10360 0001 10361 11138 0001 11139 10362 PASID - Refer to Section 6.20 PASID TLP Prefix for 11140 further details. 10363 PASID - Refer to Section 6.20 PASID TLP Prefix for further details. 11141 10364 10406 TPH - Refer to Section 2.2.7.1 TPH Rules and Section 6.17 TLP Processing Hints (TPH) for further details. 11135 10358 10405 0000 11131 10355 10404 TPH 11129 10352 10403 Description 11127 10350 10354 E[3:0] (b) 11123 11142 If one Function of an Upstream Port has the End-End TLP Prefix Supported bit Set, all Functions of that Upstream Port must handle the receipt of a Request addressed to them that contains an unsupported End-End TLP Prefix type as an Unsupported Request. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). If one Function of an Upstream Port has the End-End TLP Prefix Supported bit Set, all Functions of that Upstream Port must handle the receipt of a Completion addressed to them that contains an unsupported End-End TLP Prefix type as an Unexpected Completion. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). For Routing Elements, the End-End TLP Prefix Blocking bit in each Egress Port determines whether TLPs containing End-End TLP Prefixes can be transmitted via that Egress Port (see Section 7.5.3.16 Device Control 2 Register (Offset 28h) ). If forwarding is blocked the entire TLP is dropped and a TLP Prefix Blocked Error is reported. If the blocked TLP is a Non-Posted Request, the Egress Port returns a Completion with Unsupported Request Completion Status. The TLP Prefix Blocked Error is a reported error associated with the Egress Port (see Section 6.2 Error Signaling and Logging ). For routing elements where Multicast is enabled (see Section 6.14 Multicast Operations ). End-End TLP Prefixes are replicated in all Multicast copies of a TLP. TLP Prefix Egress Blocking of Multicast packets is performed independently at each Egress Port. 11181 11182 11183 11184 10407 11185 10408 11186 10409 11187 Page 155 If one Function of an Upstream Port has the End-End TLP Prefix Supported bit Set, all Functions of that Upstream Port must handle the receipt of a Request addressed to them that contains an unsupported End-End TLP Prefix type as an Unsupported Request. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). If one Function of an Upstream Port has the End-End TLP Prefix Supported bit Set, all Functions of that Upstream Port must handle the receipt of a Completion addressed to them that contains an unsupported End-End TLP Prefix type as an Unexpected Completion. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). For Routing Elements, the End-End TLP Prefix Blocking bit in each Egress Port determines whether TLPs containing End-End TLP Prefixes can be transmitted via that Egress Port (see Section 7.5.3.16 Device Control 2 Register (Offset 28h) ). If forwarding is blocked the entire TLP is dropped and a TLP Prefix Blocked Error is reported. If the blocked TLP is a Non-Posted Request, the Egress Port returns a Completion with Unsupported Request Completion Status. The TLP Prefix Blocked Error is a reported error associated with the Egress Port (see Section 6.2 Error Signaling and Logging ). For routing elements where Multicast is enabled (see Section 6.14 Multicast Operations ). End-End TLP Prefixes are replicated in all Multicast copies of a TLP. TLP Prefix Egress Blocking of Multicast packets is performed independently at each Egress Port. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10409 11187 10410 2.2.10.2.1 Vendor Defined End-End TLP Prefix 10411 11190 As described in Table 2-36 End-End TLP Prefix Types , Types VendPrefixE0 and VendPrefixE1 are Reserved for use as Vendor Defined End-End TLP Prefixes. To maximize interoperability and flexibility the following rules are applied to such prefixes: 10414 10415 10416 11191 11193 11194 11195 10418 11196 10419 11197 10420 2.2.10.2.2 Root Ports with End-End TLP Prefix Supported 11199 10422 11200 10423 11201 10426 11205 An RC is not required to support End-End TLP Prefix routing between all pairs of Root Ports that have the End-End TLP Prefix Supported bit Set. A Request with End-End TLP Prefixes that would require routing between unsupported pairs of Root Ports must be handled as a UR. A Completion with End-End TLP Prefixes that would require routing between unsupported pairs of Root Ports must be handled as an Unexpected Completion (UC). In both cases, this error is reported by the “sending” Port. 11206 10429 11207 The End-End TLP Prefix Supported bit must be Set for any Root Port that supports forwarding of TLPs with End-End TLP Prefixes initiated by host software or Root Complex Integrated Endpoints (RCiEPs). The End-End TLP Prefix Supported bit must be Set for any Root Ports that support forwarding of TLPs with End-End TLP Prefixes received on their Ingress Port to RCiEPs. 10431 11208 The End-End TLP Prefix Supported bit must be Set for any Root Port that supports forwarding of TLPs with End-End TLP Prefixes initiated by host software or Root Complex Integrated Endpoints (RCiEPs). The End-End TLP Prefix Supported bit must be Set for any Root Ports that support forwarding of TLPs with End-End TLP Prefixes received on their Ingress Port to RCiEPs. 11209 10432 11210 Different Root Ports with the End-End TLP Prefix Supported bit Set are permitted to report different values for Max EndEnd TLP Prefixes. 10434 11211 Different Root Ports with the End-End TLP Prefix Supported bit Set are permitted to report different values for Max EndEnd TLP Prefixes. 11212 10435 10436 2.2.10.2.2 Root Ports with End-End TLP Prefix Supported 11204 An RC is not required to support End-End TLP Prefix routing between all pairs of Root Ports that have the End-End TLP Prefix Supported bit Set. A Request with End-End TLP Prefixes that would require routing between unsupported pairs of Root Ports must be handled as a UR. A Completion with End-End TLP Prefixes that would require routing between unsupported pairs of Root Ports must be handled as an Unexpected Completion (UC). In both cases, this error is reported by the “sending” Port. 10428 10433 Components must not send TLPs containing Vendor Defined End-End TLP Prefixes unless this has been explicitly enabled (using vendor-specific mechanisms). It is recommended that components be configurable (using vendor-specific mechanisms) to use either of the two Vendor Defined EndEnd TLP Prefix encodings. Doing so allows two different Vendor Defined End-End TLP Prefixes to be in use simultaneously within a single PCI Express topology while not requiring that every source understand the ultimate destination of every TLP it sends. 11198 10421 10430 As described in Table 2-37 End-End TLP Prefix Types , Types VendPrefixE0 and VendPrefixE1 are Reserved for use as Vendor Defined End-End TLP Prefixes. To maximize interoperability and flexibility the following rules are applied to such prefixes: 11192 Components must not send TLPs containing Vendor Defined End-End TLP Prefixes unless this has been explicitly enabled (using vendor-specific mechanisms). It is recommended that components be configurable (using vendor-specific mechanisms) to use either of the two Vendor Defined EndEnd TLP Prefix encodings. Doing so allows two different Vendor Defined End-End TLP Prefixes to be in use simultaneously within a single PCI Express topology while not requiring that every source understand the ultimate destination of every TLP it sends. 10417 10427 2.2.10.2.1 Vendor Defined End-End TLP Prefix 11189 10412 10413 11188 11213 An RC that splits a TLP into smaller TLPs when performing peer-to-peer routing between Root Ports must replicate the original TLP's End-End TLP Prefixes in each of the smaller TLPs (see ). Page 156 11214 An RC that splits a TLP into smaller TLPs when performing peer-to-peer routing between Root Ports must replicate the original TLP's End-End TLP Prefixes in each of the smaller TLPs (see Section 1.3.1 Root Complex ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10436 An RC that splits a TLP into smaller TLPs when performing 11214 peer-to-peer routing between Root Ports must replicate the original TLP's End-End TLP Prefixes in each of the smaller TLPs (see ). 10437 11215 10438 11216 10439 11217 10440 11218 10441 11219 10442 11220 10443 11221 10444 2.3 Handling of Received TLPs 10445 10450 10451 10452 10455 10458 10463 10464 11228 11229 11230 Values in Reserved fields must be ignored by the Receiver. If the value in the Fmt field indicates the presence of at least one TLP Prefix: Detect if additional TLP Prefixes are present in the header by checking the Fmt field in the first byte of subsequent DWs until the Fmt field does not match that of a TLP Prefix. Handle all received TLP Prefixes according to TLP Prefix Handling Rules (see Section 2.2.10 TLP Prefix Rules ). 11232 11233 If the Extended Fmt Field Supported bit is Set, Received TLPs that use encodings of Fmt and Type that are Reserved are Malformed TLPs (see Table 2-1 Transaction Types for Different Address Spaces and Table 2-3 Fmt[2:0] and Type[4:0] Field Encodings ). This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11235 11236 If the Extended Fmt Field Supported bit is Clear, processing of Received TLPs that have Fmt[2] Set is undefined. [Footnote: An earlier version of this specification reserved the bit now defined for Fmt[2].] All Received TLPs with Fmt[2] Clear and that use undefined Type field values are Malformed TLPs. 11237 This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10461 10462 11227 11234 If the Extended Fmt Field Supported bit is Clear, processing of Received TLPs that have Fmt[2] Set is undefined. [Footnote: An earlier version of this specification reserved the bit now defined for Fmt[2].] All Received TLPs with Fmt[2] Clear and which use undefined Type field values are Malformed TLPs. 10459 10460 This section describes how all Received TLPs are handled when they are delivered to the Receive Transaction Layer from the Receive Data Link Layer, after the Data Link Layer has validated the integrity of the received TLP. The rules are diagramed in the flowchart shown in Figure 2-41 Flowchart for Handling of Received TLPs . 11231 If the Extended Fmt Field Supported bit is Set, Received TLPs which use encodings of Fmt and Type that are Reserved are Malformed TLPs (see Table 2-1 Transaction Types for Different Address Spaces and Table 2-3 Fmt[2:0] and Type[4:0] Field Encodings ). This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10456 10457 11225 11226 Values in Reserved fields must be ignored by the Receiver. If the value in the Fmt field indicates the presence of at least one TLP Prefix: Detect if additional TLP Prefixes are present in the header by checking the Fmt field in the first byte of subsequent DWs until the Fmt field does not match that of a TLP Prefix. Handle all received TLP Prefixes according to TLP Prefix Handling Rules (see Section 2.2.10 TLP Prefix Rules ). 10453 10454 2.3 Handling of Received TLPs 11224 This section describes how all Received TLPs are handled when they are delivered to the Receive Transaction Layer from the Receive Data Link Layer, after the Data Link Layer has validated the integrity of the received TLP. The rules are diagramed in the flowchart shown in Figure 2-38 Flowchart for Handling of Received TLPs . 10448 10449 11222 11223 10446 10447 An RC that splits a TLP into smaller TLPs when performing peer-to-peer routing between Root Ports must replicate the original TLP's End-End TLP Prefixes in each of the smaller TLPs (see Section 1.3.1 Root Complex ). 11238 This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11239 All Received Malformed TLPs must be discarded. Received Malformed TLPs that are ambiguous with respect to which buffer to release or are mapped to an uninitialized or disabled Virtual Channel must be discarded without updating Receiver Flow Control information. All other Received Malformed TLPs must be discarded, optionally not updating Receiver Flow Control information. Page 157 11240 11241 11242 All Received Malformed TLPs must be discarded. Received Malformed TLPs that are ambiguous with respect to which buffer to release or are mapped to an uninitialized or disabled Virtual Channel must be discarded without updating Receiver Flow Control information. All other Received Malformed TLPs must be discarded, optionally not updating Receiver Flow Control information. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10464 All other Received Malformed TLPs must be discarded, 11242 optionally not updating Receiver Flow Control information. 10465 10466 10467 11243 Otherwise, update Receiver Flow Control tracking information (see Section 2.6 Ordering and Receive Buffer Flow Control ) If the value in the Type field indicates the TLP is a Request, handle according to Request Handling Rules, otherwise, the TLP is a Completion - handle according to Completion Handling Rules (following sections) 11244 11245 10468 11246 10469 11247 10470 11248 10471 Figure 2-38 Flowchart for Handling of Received TLPs 11250 10473 11251 10474 11252 10475 10479 10480 10481 10482 10485 10486 11254 Switches must process both TLPs that address resources within the Switch as well as TLPs that address resources residing outside the Switch. Switches handle all TLPs that address internal resources of the Switch according to the rules above. TLPs that pass through the Switch, or that address the Switch as well as passing through it, are handled according to the following rules (see Figure 2-42 Flowchart for Switch Handling of TLPs ): 11255 If the value in the Type field indicates the TLP is not a Msg or MsgD Request, the TLP must be routed according to the routing mechanism used (see Section 2.2.4.1 Address-Based Routing Rules and Section 2.2.4.2 ID Based Routing Rules ). Switches route Completions using the information in the Requester ID field of the Completion. If the value in the Type field indicates the TLP is a Msg or MsgD Request, route the Request according to the routing mechanism indicated in the r[2:0] sub-field of the Type field If the value in r[2:0] indicates the Msg/MsgD is routed to the Root Complex (000b), the Switch must route the Msg/MsgD to the Upstream Port of the Switch It is an error to receive a Msg/MsgD Request specifying 000b routing at the Upstream Port of a Switch. Switches may check for violations of this rule - TLPs in violation are Malformed TLPs. If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10483 10484 Figure 2-41 Flowchart for Handling of Received TLPs 11253 Switches must process both TLPs which address resources within the Switch as well as TLPs which address resources residing outside the Switch. Switches handle all TLPs which address internal resources of the Switch according to the rules above. TLPs which pass through the Switch, or which address the Switch as well as passing through it, are handled according to the following rules (see Figure 2-39 Flowchart for Switch Handling of TLPs ): 10477 10478 Otherwise, update Receiver Flow Control tracking information (see Section 2.6 Ordering and Receive Buffer Flow Control ). If the value in the Type field indicates the TLP is a Request, handle according to Request Handling Rules, otherwise, the TLP is a Completion - handle according to Completion Handling Rules (following sections). 11249 10472 10476 All other Received Malformed TLPs must be discarded, optionally not updating Receiver Flow Control information. 11256 11257 11258 11259 11260 If the value in the Type field indicates the TLP is not a Msg or MsgD Request, the TLP must be routed according to the routing mechanism used (see Section 2.2.4.1 Address-Based Routing Rules and Section 2.2.4.2 ID Based Routing Rules ). Switches route Completions using the information in the Requester ID field of the Completion. If the value in the Type field indicates the TLP is a Msg or MsgD Request, route the Request according to the routing mechanism indicated in the r[2:0] sub-field of the Type field. If the value in r[2:0] indicates the Msg/MsgD is routed to the Root Complex (000b), the Switch must route the Msg/MsgD to the Upstream Port of the Switch. It is an error to receive a Msg/MsgD Request specifying 000b routing at the Upstream Port of a Switch. Switches may check for violations of this rule - TLPs in violation are Malformed TLPs. If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11261 If the value in r[2:0] indicates the Msg/MsgD is routed by address (001b), the Switch must route the Msg/MsgD in the same way it would route a Memory Request by address If the value in r[2:0] indicates the Msg/MsgD is routed by ID (010b), the Switch must route the Msg/MsgD in the same way it would route a Completion by ID If the value in r[2:0] indicates the Msg/MsgD is a broadcast from the Root Complex (011b), the Switch must route the Msg/ MsgD to all Downstream Ports of the Switch Page 158 11262 11263 11264 If the value in r[2:0] indicates the Msg/MsgD is routed by address (001b), the Switch must route the Msg/MsgD in the same way it would route a Memory Request by address. If the value in r[2:0] indicates the Msg/MsgD is routed by ID (010b), the Switch must route the Msg/MsgD in the same way it would route a Completion by ID. If the value in r[2:0] indicates the Msg/MsgD is a broadcast from the Root Complex (011b), the Switch must route the Msg/ MsgD to all Downstream Ports of the Switch. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 10486 If the value in r[2:0] indicates the Msg/MsgD is a /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html broadcast from the Root Complex (011b), the Switch must route the Msg/ 10487 MsgD to all Downstream Ports of the Switch It is an error to receive a Msg/MsgD Request specifying 011b routing at the Downstream Port of a Switch. Switches may check for violations of this rule - TLPs in violation are Malformed TLPs. If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 10488 10489 10490 10491 11264 11265 11266 If the value in r[2:0] indicates the Msg/MsgD terminates at the Receiver (100b or a Reserved value), or if the Message Code field value is defined and corresponds to a Message which must be comprehended by the Switch, the Switch must process the Message according to the Message processing rules If the value in r[2:0] indicates Gathered and routed to Root Complex (101b), see Section 5.3.3.2.1 PME Synchronization for Message handling rules It is an error to receive any Msg/MsgD Request other than a PME_TO_Ack that specifies 101b routing. It is an error to receive a PME_TO_Ack at the Upstream Port of a Switch. Switches may optionally check for violations of these rules. These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If checked, violations are Malformed TLPs, and are reported errors associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11267 11268 11269 10492 11270 10493 11271 10494 11272 10495 11273 10496 Figure 2-39 Flowchart for Switch Handling of TLPs 11275 10498 11276 10499 11277 10500 11278 10501 2.3.1 Request Handling Rules 10503 11280 2.3.1 Request Handling Rules 11281 10504 11282 This section describes how Received Requests are handled, following the initial processing done with all TLPs. The rules are diagramed in the flowchart shown in Figure 2-40 Flowchart for Handling of Received Request . 10506 10508 Figure 2-42 Flowchart for Switch Handling of TLPs 11279 10502 10507 If the value in r[2:0] indicates the Msg/MsgD terminates at the Receiver (100b or a Reserved value), or if the Message Code field value is defined and corresponds to a Message that must be comprehended by the Switch, the Switch must process the Message according to the Message processing rules. If the value in r[2:0] indicates Gathered and routed to Root Complex (101b), see Section 5.3.3.2.1 PME Synchronization for Message handling rules. It is an error to receive any Msg/MsgD Request other than a PME_TO_Ack that specifies 101b routing. It is an error to receive a PME_TO_Ack at the Upstream Port of a Switch. Switches may optionally check for violations of these rules. These checks are independently optional (see Section 6.2.3.4 Optional Error Checking ). If checked, violations are Malformed TLPs, and are reported errors associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11274 10497 10505 If the value in r[2:0] indicates the Msg/MsgD is a broadcast from the Root Complex (011b), the Switch must route the Msg/ MsgD to all Downstream Ports of the Switch. It is an error to receive a Msg/MsgD Request specifying 011b routing at the Downstream Port of a Switch. Switches may check for violations of this rule - TLPs in violation are Malformed TLPs. If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11283 This section describes how Received Requests are handled, following the initial processing done with all TLPs. The rules are diagramed in the flowchart shown in Figure 2-43 Flowchart for Handling of Received Request . 11284 If the Request Type is not supported (by design or because of configuration settings) by the device, the Request is an Unsupported Request, and is reported according to Section 6.2 Error Signaling and Logging If the Request requires Completion, a Completion Status of UR is returned (see Section 2.2.8.10 Precision Time Measurement (PTM) Messages ) 11285 11286 10509 11287 10510 11288 10511 11289 10512 11290 Page 159 If the Request Type is not supported (by design or because of configuration settings) by the device, the Request is an Unsupported Request, and is reported according to Section 6.2 Error Signaling and Logging If the Request requires Completion, a Completion Status of UR is returned (see Section 2.2.8.10 Precision Time Measurement (PTM) Messages ) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10512 11290 10513 Implementation Note When Requests are Terminated Using Unsupported Request 10514 10515 10524 11302 11305 PCI Express Messages do not exist in conventional PCI, so the above guideline cannot be applied. This specification describes specifically for each type of Message when a device must handle the request as an Unsupported Request. Messages pass through Root and Switch Ports unaffected by conventional PCI control mechanisms including Bus Master Enable and power state setting. 11306 10529 11307 Note that CA, which is the PCI Express equivalent to Target Abort, is used only to indicate a serious error that makes the Completer permanently unable to respond to a request that it would otherwise have normally responded to. Since Target Abort is used in conventional PCI only when a target has asserted DEVSEL#, is incorrect to use a CA for any case where a Conventional PCI target would have ignored a request by not asserting DEVSEL#. 11308 10531 11309 10532 11310 10533 10535 For device Functions with Type 1 headers (Root Ports, Switches and Bridges), the same question can generally be applied, but since the behavior of a conventional PCI bridge is more complicated than that of a Type 0 Function, it is somewhat more difficult to determine the answers. One must consider Root Ports and Switch Ports as if they were actually composed of conventional PCI to PCI bridges, and then at each stage consider the configuration settings of the virtual bridge to determine the correct behavior. 11304 PCI Express Messages do not exist in conventional PCI, so the above guideline cannot be applied. This specification describes specifically for each type of Message when a device must handle the request as an Unsupported Request. Messages pass through Root and Switch Ports unaffected by conventional PCI control mechanisms including Bus Master Enable and power state setting. 10528 10534 Implementation Note When Requests are Terminated Using Unsupported Request 11303 10526 10530 11292 11293 For device Functions with Type 1 headers (Root Ports, Switches and Bridges), the same question can generally be applied, but since the behavior of a conventional PCI bridge is more complicated than that of a Type 0 Function, it is somewhat more difficult to determine the answers. One must consider Root Ports and Switch Ports as if they were actually composed of conventional PCI to PCI bridges, and then at each stage consider the configuration settings of the virtual bridge to determine the correct behavior. 10525 10527 11291 Note that CA, which is the PCI Express equivalent to Target Abort, is used only to indicate a serious error that makes the Completer permanently unable to respond to a request that it would otherwise have normally responded to. Since Target Abort is used in conventional PCI only when a target has asserted DEVSEL#, is incorrect to use a CA for any case where a Conventional PCI target would have ignored a request by not asserting DEVSEL#. 11311 If the Request is a Message, and the Message Code, routing field, or Msg / MsgD indication corresponds to a combination that is undefined, or that corresponds to a Message not supported by the device Function, (other than Vendor_Defined Type 1 which is not treated as an error - see Table F-1 Message Code Usage ), the Request is an Unsupported Request, and is reported according to Section 6.2 Error Signaling and Logging If the Message Code is a supported value, process the Message according to the corresponding Message processing rules; if the Message Code is an Ignored Message and the Receiver is ignoring it, ignore the Message without reporting any error (see Section 2.2.8.7 Ignored Messages ) 10536 11312 11313 11314 11315 11316 Page 160 If the Request is a Message, and the Message Code, routing field, or Msg / MsgD indication corresponds to a combination that is undefined, or that corresponds to a Message not supported by the device Function, (other than Vendor_Defined Type 1, which is not treated as an error - see Table F-1 Message Code Usage ), the Request is an Unsupported Request, and is reported according to Section 6.2 Error Signaling and Logging If the Message Code is a supported value, process the Message according to the corresponding Message processing rules; if the Message Code is an Ignored Message and the Receiver is ignoring it, ignore the Message without reporting any error (see Section 2.2.8.7 Ignored Messages ) If the Request is a Message with a routing field that indicates Routed by ID, and if the Request is received by a device Function with Type 0 headers, it is strongly recommended that the device be treated as the target of the Message regardless of the Bus Number and Device Number specified in the destination ID field of the Request If the Function specified in the destination ID is unimplemented, it is strongly recommended that the Request be handled as an Unsupported Request, and that it is reported as specified in Section 6.2 Error Signaling and Logging /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11316 10537 11317 10538 10539 11318 If the Request is not a Message, and is a supported Type, specific implementations may be optimized based on a defined programming model which ensures that certain types of (otherwise legal) Requests will never occur. Such implementations may take advantage of the following rule: 10540 10541 10542 10543 11319 11320 11322 11323 11324 11325 10545 11326 10546 11327 10547 10549 11329 11330 11331 10551 11332 10552 When a device's programming model restricts (versus what is otherwise permitted in PCI Express) the characteristics of a Request, that device is permitted to return a CA Completion Status for any Request that violates the programming model. Examples include unaligned or wrongsize access to a register block and unsupported size of request to a Memory Space. 11336 Generally, devices are able to assume a restricted programming model when all communication will be between the device's driver software and the device itself. Devices which may be accessed directly by operating system software or by applications which may not comprehend the restricted programming model of the device (typically devices which implement legacy capabilities) should be designed to support all types of Requests which are possible in the existing usage model for the device. If this is not done, the device may fail to operate with existing software. 10557 11337 Generally, devices are able to assume a restricted programming model when all communication will be between the device's driver software and the device itself. Devices that may be accessed directly by operating system software or by applications that may not comprehend the restricted programming model of the device (typically devices that implement legacy capabilities) should be designed to support all types of Requests that are possible in the existing usage model for the device. If this is not done, the device may fail to operate with existing software. 11338 10558 Page 11334 11335 10555 10559 Implementation Note Optimizations Based on Restricted Programming Model 11333 When a device's programming model restricts (versus what is otherwise permitted in PCI Express) the characteristics of a Request, that device is permitted to return a CA Completion Status any Request that violates the programming model. Examples include unaligned or wrongsize access to a register block and unsupported size of request to a Memory Space. 10554 10556 If the Request violates the programming model of the device Function, the Function may optionally treat the Request as a Completer Abort, instead of handling the Request normally If the Request is treated as a Completer Abort, this is a reported error associated with the Function (see Section 6.2 Error Signaling and Logging ) If the Request requires Completion, a Completion Status of CA is returned (see Section 2.2.8.10 Precision Time Measurement (PTM) Messages ) 11328 Implementation Note Optimizations Based on Restricted Programming Model 10550 10553 If the Request is not a Message, and is a supported Type, specific implementations may be optimized based on a defined programming model that ensures that certain types of (otherwise legal) Requests will never occur. Such implementations may take advantage of the following rule: 11321 If the Request violates the programming model of the device Function, the Function may optionally treat the Request as a Completer Abort, instead of handling the Request normally If the Request is treated as a Completer Abort, this is a reported error associated with the Function (see Section 6.2 Error Signaling and Logging ) If the Request requires Completion, a Completion Status of CA is returned (see Section 2.2.8.10 Precision Time Measurement (PTM) Messages ) 10544 10548 If the Function specified in the destination ID is unimplemented, it is strongly recommended that the Request be handled as an Unsupported Request, and that it is reported as specified in Section 6.2 Error Signaling and Logging 11339 If the Request arrives between the time an FLR has been initiated and the completion of the FLR by the targeted Function, the Request is permitted to be silently discarded (following update of flow 161 control credits) without logging or signaling it as an error. It is recommended that the Request be handled as an Unsupported Request (UR). 11340 If the Request arrives between the time an FLR has been initiated and the completion of the FLR by the targeted Function, the Request is permitted to be silently discarded (following update of flow control credits) without logging or signaling it as an error. It is recommended that the Request be handled as an Unsupported Request (UR). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10559 If the Request arrives between the time an FLR has been initiated and the completion of the FLR by the targeted Function, the Request is permitted to be silently discarded (following update of flow control credits) without logging or signaling it as an error. It is recommended that the Request be handled as an Unsupported Request (UR). 11340 10560 11341 10561 11342 10562 11343 10563 Otherwise (supported Request Type, not a Message), process the 11344 Request 10564 10565 If the Completer is permanently unable to process the Request due to a device-specific error condition the Completer must, if possible, handle the Request as a Completer Abort This is a reported error associated with the Receiving Function, if the error can be isolated to a specific Function in the component, or to the Receiving Port if the error cannot be isolated (see Section 6.2 Error Signaling and Logging ) 10566 10567 10568 10569 10570 10573 10574 Otherwise (supported Request Type, not a Message), process the Request 11345 11346 If the Completer is permanently unable to process the Request due to a device-specific error condition the Completer must, if possible, handle the Request as a Completer Abort This is a reported error associated with the Receiving Function, if the error can be isolated to a specific Function in the component, or to the Receiving Port if the error cannot be isolated (see Section 6.2 Error Signaling and Logging ) 11347 For Configuration Requests only, following reset it is possible for a device to terminate the request but indicate that it is temporarily unable to process the Request, but will be able to process the Request in the future - in this case, the Configuration Request Retry Status (CRS) Completion Status is used (see Section 6.6 PCI Express Reset - Rules ). Valid reset conditions after which a device is permitted to return CRS are: Cold, Warm, and Hot Resets FLRs A reset initiated in response to a D3hot to D0uninitialized device state transition. 10571 10572 If the Request arrives between the time an FLR has been initiated and the completion of the FLR by the targeted Function, the Request is permitted to be silently discarded (following update of flow control credits) without logging or signaling it as an error. It is recommended that the Request be handled as an Unsupported Request (UR). 11348 11349 11350 11351 For Configuration Requests only, following reset it is possible for a device to terminate the request but indicate that it is temporarily unable to process the Request, but will be able to process the Request in the future - in this case, the Configuration Request Retry Status (CRS) Completion Status is used (see Section 6.6 PCI Express Reset - Rules ). Valid reset conditions after which a device is permitted to return CRS are: Cold, Warm, and Hot Resets FLRs A reset initiated in response to a D3Hot to D0uninitialized device state transition 11352 A device Function is explicitly not permitted to return CRS following a software-initiated reset (other than an FLR) of the device, e.g., by the device's software driver writing to a devicespecific reset bit. A device Function is not permitted to return CRS after it has indicated that it is Configuration-Ready (see Section 6.23 Readiness Notifications (RN) .) without an intervening valid reset (i.e., FLR or Conventional Reset) condition, or if the Immediate Readiness bit in the Function's Status register is Set. Additionally, a device Function is not permitted to return CRS after having previously returned a Successful Completion without an intervening valid reset (i.e., FLR or Conventional Reset) condition. In the process of servicing the Request, the Completer may determine that the (otherwise acceptable) Request must be handled as an error, in which case the Request is handled according to the type of the error Example: A PCI Express/PCI Bridge may initially accept a Request because it specifies a Memory Space range mapped to the secondary side of the Bridge, but the Request may Master Abort or Target Abort on the PCI side of the Bridge. From the PCI Express perspective, the status of the Request in this case is UR (for Master Abort) or CA (for Target Abort). If the Request requires Completion on PCI Express, the corresponding Completion Status is returned. Page 162 11353 11354 11355 A device Function is explicitly not permitted to return CRS following a software-initiated reset (other than an FLR) of the device, e.g., by the device's software driver writing to a devicespecific reset bit. A device Function is not permitted to return CRS after it has indicated that it is Configuration-Ready (see Section 6.23 Readiness Notifications (RN) .) without an intervening valid reset (i.e., FLR or Conventional Reset) condition, or if the Immediate Readiness bit in the Function's Status register is Set. Additionally, a device Function is not permitted to return CRS after having previously returned a Successful Completion without an intervening valid reset (i.e., FLR or Conventional Reset) condition. In the process of servicing the Request, the Completer may determine that the (otherwise acceptable) Request must be handled as an error, in which case the Request is handled according to the type of the error Example: A PCI Express/PCI Bridge may initially accept a Request because it specifies a Memory Space range mapped to the secondary side of the Bridge, but the Request may Master Abort or Target Abort on the PCI side of the Bridge. From the PCI Express perspective, the status of the Request in this case is UR (for Master Abort) or CA (for Target Abort). If the Request requires Completion on PCI Express, the corresponding Completion Status is returned. 10574 11355 Example: A PCI Express/PCI Bridge may initially accept a Request because it specifies a Memory Space range mapped to the secondary side of the Bridge, but the Request may Master Abort or Target /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. Abort on the PCI side of the Bridge. From the PCI Express perspective, the status of the Request in this case is UR (for Master Abort) or CA /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html (for Target Abort). If the Request requires Completion on PCI Express, the corresponding Completion Status is returned. 10575 11356 10576 10577 10578 10579 11357 If the Request is a type which requires a Completion to be returned, generate a Completion according to the rules for Completion formation (see Section 2.2.9 Completion Rules ) The Completion Status is determined by the result of handling the Request If the Request has an ECRC Check Failed error, then it is implementation-specific whether to return a Completion or not, and if so, which of the architected values to use for its Completion Status. However, it is strongly recommended that the Completer return a Completion with a UR Completion Status. 10580 10581 10582 10583 10584 10585 10586 10587 10590 10591 10592 11358 11359 11360 If the Request is a type that requires a Completion to be returned, generate a Completion according to the rules for Completion formation (see Section 2.2.9 Completion Rules ) The Completion Status is determined by the result of handling the Request If the Request has an ECRC Check Failed error, then it is implementation-specific whether to return a Completion or not, and if so, which of the architected values to use for its Completion Status. However, it is strongly recommended that the Completer return a Completion with a UR Completion Status. 11361 Under normal operating conditions, PCI Express Endpoints and Legacy Endpoints must never delay the acceptance of a Posted Request for more than 10 µs, which is called the Posted Request Acceptance Limit. The device must either (a) be designed to process received Posted Requests and return associated Flow Control credits within the necessary time limit, or (b) rely on a restricted programming model to ensure that a Posted Request is never sent to the device either by software or by other devices while the device is unable to accept a new Posted Request within the necessary time limit. The following are not considered normal operating conditions under which the Posted Request Acceptance Limit applies: The period immediately following a Fundamental Reset (see Section 6.6 PCI Express Reset - Rules ). TLP retransmissions or Link retraining. One or more dropped Flow Control Packets (FCPs). The device being in a diagnostic mode. The device being in a device-specific mode that is not intended for normal use. 10588 10589 Example: A PCI Express/PCI Bridge may initially accept a Request because it specifies a Memory Space range mapped to the secondary side of the Bridge, but the Request may Master Abort or Target Abort on the PCI side of the Bridge. From the PCI Express perspective, the status of the Request in this case is UR (for Master Abort) or CA (for Target Abort). If the Request requires Completion on PCI Express, the corresponding Completion Status is returned. 11362 11363 11364 11365 11366 11367 11368 Under normal operating conditions, PCI Express Endpoints and Legacy Endpoints must never delay the acceptance of a Posted Request for more than 10 μs, which is called the Posted Request Acceptance Limit. The device must either (a) be designed to process received Posted Requests and return associated Flow Control credits within the necessary time limit, or (b) rely on a restricted programming model to ensure that a Posted Request is never sent to the device either by software or by other devices while the device is unable to accept a new Posted Request within the necessary time limit. The following are not considered normal operating conditions under which the Posted Request Acceptance Limit applies: The period immediately following a Fundamental Reset (see Section 6.6 PCI Express Reset - Rules ) TLP retransmissions or Link retraining One or more dropped Flow Control Packets (FCPs) The device being in a diagnostic mode The device being in a device-specific mode that is not intended for normal use 11369 The following are considered normal operating conditions, but any delays they cause do not count against the Posted Request Acceptance Limit: Upstream TLP traffic delaying Upstream FCPs. The Link coming out of a low-power state. Arbitration with traffic on other VCs. 11370 11371 11372 11373 The following are considered normal operating conditions, but any delays they cause do not count against the Posted Request Acceptance Limit: Upstream TLP traffic delaying Upstream FCPs The Link coming out of a low-power state Arbitration with traffic on other VCs 11374 10593 Though not a requirement, it is strongly recommended that RCiEPs also honor the Posted Request Acceptance Limit. 10594 10595 11375 Though not a requirement, it is strongly recommended that RCiEPs also honor the Posted Request Acceptance Limit. 11376 If the device supports being a target for I/O Write Requests, which are Non-Posted Requests, it is strongly recommended that each associated Completion be returned within the same time limit as for Posted Request acceptance, although this is not a requirement. 11377 10596 11378 10597 11379 10598 11380 10599 Page 163 If the device supports being a target for I/O Write Requests, which are Non-Posted Requests, it is strongly recommended that each associated Completion be returned within the same time limit as for Posted Request acceptance, although this is not a requirement. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10599 10600 10601 Implementation Note Restricted Programming Model for Meeting the Posted Request Acceptance Limit 11381 11382 10602 11383 10603 11384 10604 10605 11385 Some hardware designs may not be able to process every Posted Request within the required acceptance time limit. An example is writing to a command queue where commands can take longer than the acceptance time limit to complete. Subsequent writes to such a device when it is currently processing a previous write could experience acceptance delays that exceed the limit. Such devices may rely on a restricted programming model, where the device driver limits the rate of memory writes to the device, the driver polls the device to determine buffer availability before issuing the write transaction, or the driver implements some other software-based flow control mechanism. 11386 10606 11387 10607 11388 10608 11389 10609 11390 10610 11391 10611 10612 11393 11394 10614 11395 10615 11396 10616 10618 11398 11399 11400 10620 11401 10621 Page Figure 2-43 Flowchart for Handling of Received Request 11397 Implementation Note Configuration Request Retry Status 10619 10622 Some hardware designs may not be able to process every Posted Request within the required acceptance time limit. An example is writing to a command queue where commands can take longer than the acceptance time limit to complete. Subsequent writes to such a device when it is currently processing a previous write could experience acceptance delays that exceed the limit. Such devices may rely on a restricted programming model, where the device driver limits the rate of memory writes to the device, the driver polls the device to determine buffer availability before issuing the write transaction, or the driver implements some other software-based flow control mechanism. 11392 Figure 2-40 Flowchart for Handling of Received Request 10613 10617 Implementation Note Restricted Programming Model for Meeting the Posted Request Acceptance Limit Implementation Note Configuration Request Retry Status 11402 Some devices require a lengthy self-initialization sequence to complete before they are able to service Configuration Requests (common with intelligent I/O solutions on PCI). PCI/PCI-X architecture has specified a 225 (PCI) or 226 (PCI-X) clock “recovery time” Trhfa following reset to provide the required self-initialization time for such devices. PCI Express “softens” the need for this time based recovery period by implementing a Configuration Request Retry Status (CRS) Completion Status . A device in receipt of a Configuration Request following a valid reset condition may respond with a CRS Completion Status to terminate the Request, and thus effectively stall the Configuration Request until such time that the subsystem has completed local initialization and is ready to communicate with the host. Note that it is only legal to respond with a CRS Completion Status in response to a Configuration Request. Sending this Completion Status in response to any other Request type is illegal (see Section 2.3.2 Completion Handling Rules ). Readiness Notifications (see Section 6.23 Readiness Notifications (RN) ) and Immediate Readiness (see Section 7.5.1.1.4 Status Register (Offset 06h) and Section 7.5.2.1 Power Management Capabilities Register (Offset 00h) ) also forbid the use of CRS 164 Completion Status in certain situations. 11403 Some devices require a lengthy self-initialization sequence to complete before they are able to service Configuration Requests (common with intelligent I/O solutions on PCI). PCI/PCI-X architecture has specified a 225 (PCI) or 226 (PCI-X) clock “recovery time” Trhfa following reset to provide the required self-initialization time for such devices. Section 6.6.1 Conventional Reset specifies a 1.0 s recovery period for PCIe devices. PCIe architecture also provides an alternative to waiting for this worst-case recovery period via the Configuration Request Retry Status (CRS) Completion Status mechanism. A device in receipt of a Configuration Request following a valid reset condition may respond with a CRS Completion Status to terminate the Request, and thus effectively stall the Configuration Request until such time that the subsystem has completed local initialization and is ready to communicate with the host. Note that it is only legal to respond with a CRS Completion Status in response to a Configuration Request. Sending this Completion Status in response to any other Request type is illegal (see Section 2.3.2 Completion Handling Rules ). Readiness Notifications (see Section 6.23 Readiness Notifications (RN) ) and Immediate Readiness (see Section 7.5.1.1.4 Status Register (Offset 06h) and Section 7.5.2.1 Power Management Capabilities Register (Offset 00h) ) also forbid the use of CRS Completion Status in certain situations. (CRS) Completion Status . A device in receipt of a Configuration Request following a valid reset condition may respond with a CRS Completion Status to terminate the Request, and thus effectively stall the Configuration Request until such time that the subsystem has completed local initialization and is ready to communicate with the host. Note that it is only legal to respond with a CRS Completion Status in response to a Configuration Request. Sending this Completion Status in response to any /private/tmp/PCISIG/pcie4_combined-snapshot.html vs.Handling other Request type is illegal (see Section 2.3.2 Completion Rules ). Readiness Notifications (see Section 6.23 Readiness /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html Notifications (RN) ) and Immediate Readiness (see Section 7.5.1.1.4 Status Register (Offset 06h) and Section 7.5.2.1 Power Management Capabilities Register (Offset 00h) ) also forbid the use of CRS Completion Status in certain situations. 10623 11404 10624 10625 11405 Receipt by the Requester of a Completion with CRS Completion Status terminates the Configuration Request on PCI Express. Further action by the Root Complex regarding the original Configuration Request is specified in Section 2.3.2 Completion Handling Rules . 10626 11409 11411 When used in systems including PCI Express to PCI/PCI-X Bridges, system software and/or the Root Complex must comprehend the limit Trhfa for PCI/PCI-X agents as described in Section 2.8 Completion Timeout Mechanism and Section 6.6 PCI Express Reset - Rules . Similarly, systems using PCI Express components which require additional self initialization time beyond the minimum guaranteed must provide some mechanism for re-issuing Configuration Requests terminated with CRS status. In systems running legacy PCI/PCI-X based software, the Root Complex must re-issue the Configuration Request using a hardware mechanism to ensure proper enumeration of the system. 10632 11412 To avoid misbehaviors in systems that contain PCI Express to PCI/PCI-X Bridges, system software and/or the Root Complex should comprehend the limit Trhfa for PCI/PCI-X agents as described in Section 2.8 Completion Timeout Mechanism and Section 6.6 PCI Express Reset Rules . Similarly, systems that contain PCIe components whose selfinitialization time may require them to return a CRS Completion Status (by the rules in Section 6.6 PCI Express Reset - Rules ) should provide some mechanism for re-issuing Configuration Requests terminated with CRS status. In systems running legacy PCI/PCI-X based software, the Root Complex must re-issue the Configuration Request using a hardware mechanism to ensure proper enumeration of the system. 11413 10633 11414 Refer to Section 6.6 PCI Express Reset - Rules for more information on reset. 11415 10635 11416 10636 11417 10637 11418 10638 11419 10639 Refer to Section 6.6 PCI Express Reset - Rules for more information on reset. 11420 10640 2.3.1.1 Data Return for Read Requests 10641 10646 Root Complexes that implement CRS Software Visibility have the ability to report the receipt of CRS Completion Status to software, enabling software to attend to other tasks rather than being stalled while the device completes its self-initialization. Software that intends to take advantage of this mechanism must ensure that the first access made to a device following a valid reset condition is a Configuration Read Request accessing both bytes of the Vendor ID field in the device's Configuration Space header. For this case only, the Root Complex, if enabled, will synthesize a special read-data value for the Vendor ID field to indicate to software that CRS Completion Status has been returned by the device. For other Configuration Requests, or when CRS Software Visibility is not enabled, the Root Complex will generally re-issue the Configuration Request until it completes with a status other than CRS as described in Section 2.3.2 Completion Handling Rules . 11410 10630 10634 Receipt by the Requester of a Completion with CRS Completion Status terminates the Configuration Request on PCI Express. Further action by the Root Complex regarding the original Configuration Request is specified in Section 2.3.2 Completion Handling Rules . 11408 Root Complexes that implement CRS Software Visibility have the ability to report the receipt of CRS Completion Status to software, enabling software to attend to other tasks rather than being stalled while the device completes its self-initialization. Software that intends to take advantage of this mechanism must ensure that the first access made to a device following a valid reset condition is a Configuration Read Request accessing both bytes of the Vendor ID field in the device's Configuration Space header. For this case only, the Root Complex, if enabled, will synthesize a special read-data value for the Vendor ID field to indicate to software that CRS Completion Status has been returned by the device. For other Configuration Requests, or when CRS Software Visibility is not enabled, the Root Complex will generally re-issue the Configuration Request until it completes with a status other than CRS as described in Section 2.3.2 Completion Handling Rules . 10629 10631 11406 11407 10627 10628 alternative to waiting for this worst-case recovery period via the Configuration Request Retry Status (CRS) Completion Status mechanism. A device in receipt of a Configuration Request following a valid reset condition may respond with a CRS Completion Status to terminate the Request, and thus effectively stall the Configuration Request until such time that the subsystem has completed local initialization and is ready to communicate with the host. Note that it is only legal to respond with a CRS Completion Status in response to a Configuration Request. Sending this Completion Status in response to any other Request type is illegal (see Section 2.3.2 Completion Handling Rules ). Readiness Notifications (see Section 6.23 Readiness Notifications (RN) ) and Immediate Readiness (see Section 7.5.1.1.4 Status Register (Offset 06h) and Section 7.5.2.1 Power Management Capabilities Register (Offset 00h) ) also forbid the use of CRS Completion Status in certain situations. 11421 2.3.1.1 Data Return for Read Requests 11422 A Completion with status other than Successful Completion terminates the Completions for a single Read Request Page 165 11427 A Completion with status other than Successful Completion terminates the Completions for a single Read Request /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10646 10647 A Completion with Completion terminates the Completions In this case, undefined, and must be ignored by the status other than Successful for a single Read Request the value in the Length field is Receiver 11427 11428 10648 11429 10649 11430 10650 10651 10652 11432 11433 11434 10654 11435 10655 10659 10660 10661 11437 11439 11440 11441 11442 11443 10663 11444 10664 11445 10665 For all other System Elements, RCB is 128 bytes 10669 10672 10673 10674 Note: Bridges and Endpoints may implement a corresponding command bit that may be set by system software to indicate the RCB value for the Root Complex, allowing the Bridge or Endpoint to optimize its behavior when the Root Complex's RCB is 128 bytes. 11449 For all other System Elements, RCB is 128 bytes. 11450 Completions for Requests which do not cross the naturally aligned address boundaries at integer multiples of RCB bytes must include all data specified in the Request Requests which do cross the address boundaries at integer multiples of RCB bytes are permitted to be completed using more than one Completion subject to the following rules: The first Completion must start with the address specified in the Request, and if successful must end at one of the following: The address that satisfies the entire Request An address boundary between the start and end of the Request at an integer multiple of RCB bytes 10675 10676 11447 11448 10668 10671 Memory Read Requests may be completed with one, or in some cases, multiple Completions Read Completion Boundary (RCB) determines the naturally aligned address boundaries on which a Completer is permitted to break up the response for a single Read Request into multiple Completions. For a Root Complex, RCB is 64 bytes or 128 bytes. This value is reported in the Link Control register (see Section 7.5.3.7 Link Control Register (Offset 10h) ). 11446 Note: Bridges and Endpoints may implement a corresponding command bit which may be set by system software to indicate the RCB value for the Root Complex, allowing the Bridge or Endpoint to optimize its behavior when the Root Complex's RCB is 128 bytes. 10667 10670 Note: This is simply a specific case of the rules that apply to all TLPs with data payloads 11438 Memory Read Requests may be completed with one, or in some cases, multiple Completions Read Completion Boundary (RCB) determines the naturally aligned address boundaries on which a Completer is permitted to break up the response for a single Read Request into multiple Completions. For a Root Complex, RCB is 64 bytes or 128 bytes This value is reported in the Link Control register (see Section 7.5.3.7 Link Control Register (Offset 10h) ) 10662 10666 Completions must not include more data than permitted by Max_Payload_Size. Receivers must check for violations of this rule. Refer to Section 2.2 Transaction Layer Protocol - Packet Definition . 11436 Note: This is simply a specific case of the rules which apply to all TLPs with data payloads 10657 10658 status other than Successful for a single Read Request the value in the Length field is Receiver 11431 Completions must not include more data than permitted by Max_Payload_Size. Receivers must check for violations of this rule. Refer to Section 2.2 Transaction Layer Protocol - Packet Definition . 10653 10656 A Completion with Completion terminates the Completions In this case, undefined, and must be ignored by the 11451 11452 11453 11454 11455 Completions for Requests that do not cross the naturally aligned address boundaries at integer multiples of RCB bytes must include all data specified in the Request. Requests that do cross the address boundaries at integer multiples of RCB bytes are permitted to be completed using more than one Completion subject to the following rules: The first Completion must start with the address specified in the Request, and if successful must end at one of the following: The address that satisfies the entire Request An address boundary between the start and end of the Request at an integer multiple of RCB bytes 11456 If the final Completion is sucessful, it must end at the address that satisfies the entire Request Page 166 11457 If the final Completion is sucessful, it must end at the address that satisfies the entire Request /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10676 If the final Completion is sucessful, it must end at 10677 the address that satisfies the entire Request All Completions between, but not including, the first and final Completions must be an integer multiple of RCB bytes in length 10678 10679 10680 10683 10684 10685 10686 10689 10690 11463 11464 11465 11466 11467 Multiple Memory Read Completions for a single Read Request must return data in increasing address order. If all the Memory Read Completions for a single Read Request have a Successful Completion Status, the sum of their payloads must equal the size requested. For each Memory Read Completion, the Byte Count field must indicate the remaining number of bytes required to complete the Request including the number of bytes returned with the Completion, except when the BCM bit is Set. [Footnote: Only PCI-X completers Set the BCM bit. PCI Express completers are not permitted to set the BCM bit.] The total number of bytes required to complete a Memory Read Request is calculated as shown in Table 2-38 Calculating Byte Count from Length and Byte Enables . If a Memory Read Request is completed using multiple Completions, the Byte Count value for each successive Completion is the value indicated by the preceding Completion minus the number of bytes returned with the preceding Completion. 11469 11470 11471 The Completion Data area begins at the DW address specified by the Request. In the first or only Data DW of the first or only Completion, only the bytes configured as active in the First BE field in the Request contain valid data. Bytes configured as inactive in the First BE field in the Request will return undefined content. In the last Data DW of the last successful Completion, only the bytes configured as active in the Last BE field in the Request contain valid data. Bytes configured as inactive in the Last BE field in the Request will return undefined content. All the Completion Data bytes, including those with undefined content, are included in all CRC calculations. 11472 Figure 2-41 Example Completion Data when some Byte Enables are 0b presents an example of the above. The example assumes a single Completion TLP is returned: 10693 10694 10695 10696 10697 Issue 2 10698 10699 10700 11461 Receivers may optionally check for violations of RCB. If a Receiver implementing this check determines that a Completion violates this rule, it must handle the Completion as a Malformed TLP. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11468 The Completion Data area begins at the DW address specified by the Request. In the first or only Data DW of the first or only Completion, only the bytes configured as active in the First BE field in the Request contain valid data. Bytes configured as inactive in the First BE field in the Request will return undefined content. In the last Data DW of the last successful Completion, only the bytes configured as active in the Last BE field in the Request contain valid data. Bytes configured as inactive in the Last BE field in the Request will return undefined content. All the Completion Data bytes, including those with undefined content, are included in all CRC calculations. 10691 10692 11460 11462 Multiple Memory Read Completions for a single Read Request must return data in increasing address order. If all the Memory Read Completions for a single Read Request have a Successful Completion Status, the sum of their payloads must equal the size requested. For each Memory Read Completion, the Byte Count field must indicate the remaining number of bytes required to complete the Request including the number of bytes returned with the Completion, except when the BCM bit is Set. [Footnote: Only PCI-X completers Set the BCM bit. PCI Express completers are not permitted to set the BCM bit.] The total number of bytes required to complete a Memory Read Request is calculated as shown in Table 2-37 Calculating Byte Count from Length and Byte Enables If a Memory Read Request is completed using multiple Completions, the Byte Count value for each successive Completion is the value indicated by the preceding Completion minus the number of bytes returned with the preceding Completion. 10687 10688 11458 If the final Completion is sucessful, it must end at the address that satisfies the entire Request All Completions between, but not including, the first and final Completions must be an integer multiple of RCB bytes in length 11459 Receivers may optionally check for violations of RCB. If a Receiver implementing this check determines that a Completion violates this rule, it must handle the Completion as a Malformed TLP This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ) 10681 10682 11457 ERROR: Unknown Art File alt="Example-Completion-Datawhen-some-Byte-Enables-are-0b" Page 167 11473 Figure 2-44 Example Completion Data when some Byte Enables are 0b presents an example of the above. The example assumes a single Completion TLP is returned. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10700 ERROR: Unknown Art File alt="Example-Completion-Datawhen-some-Byte-Enables-are-0b" 10701 10702 10703 11474 10704 11475 10705 11476 10706 11477 10707 Figure 2-41 Example Completion Data when some Byte 11478 Enables are 0b 10708 11479 10709 11480 10710 11481 10711 11482 10712 Implementation Note BCM Bit Usage 10713 11483 11484 10714 11485 10715 11486 10716 10717 11488 To satisfy certain PCI-X protocol constraints, a PCI-X Bridge or PCI-X Completer for a PCI-X burst read in some cases will set the Byte Count field in the first PCI-X transaction of the Split Completion sequence to indicate the size of just that first transaction instead of the entire burst read. When this occurs, the PCI-X Bridge/PCIX Completer will also Set the BCM bit in that first PCI-X transaction, to indicate that the Byte Count field has been modified from its normal usage. Refer to the [ PCI-X-2.0] for further details. 11489 10719 11490 A PCI Express Memory Read Requester needs to correctly handle the case when a PCI-X Bridge/PCI-X Completer sets the BCM bit. When this occurs, the first Read Completion packet returned to the Requester will have the BCM bit Set, indicating that the Byte Count field reports the size of just that first packet instead of the entire remaining Byte Count. The Requester should not conclude at this point that other packets of the Read Completion are missing. 10721 11491 A PCI Express Memory Read Requester needs to correctly handle the case when a PCI-X Bridge/PCI-X Completer sets the BCM bit. When this occurs, the first Read Completion packet returned to the Requester will have the BCM bit Set, indicating that the Byte Count field reports the size of just that first packet instead of the entire remaining Byte Count. The Requester should not conclude at this point that other packets of the Read Completion are missing. 11492 10722 10723 Implementation Note BCM Bit Usage 11487 To satisfy certain PCI-X protocol constraints, a PCI-X Bridge or PCI-X Completer for a PCI-X burst read in some cases will set the Byte Count field in the first PCI-X transaction of the Split Completion sequence to indicate the size of just that first transaction instead of the entire burst read. When this occurs, the PCI-X Bridge/PCIX Completer will also Set the BCM bit in that first PCI-X transaction, to indicate that the Byte Count field has been modified from its normal usage. Refer to the [[PCI-X Addendum to the PCI Local Bus Specification, Revision 2.0]] for further details. 10718 10720 Figure 2-44 Example Completion Data when some Byte Enables are 0b 11493 The BCM bit will never be Set in subsequent packets of the Read Completion, so the Byte Count field in those subsequent packets will alw ays indicate the remaining Byte Count in each instance. Thus, the Requester can use the Byte Count field in these packets to determine if other packets of the Read Completion are missing. 10724 11496 PCI Express Completers will never Set the BCM bit. 11497 10727 11498 10728 11499 10729 11500 10730 11501 Page 168 The BCM bit will never be Set in subsequent packets of the Read Completion, so the Byte Count field in those subsequent packets will always indicate the remaining Byte Count in each instance. Thus, the Requester can use the Byte Count field in these packets to determine if other packets of the Read Completion are missing. 11495 10725 10726 11494 PCI Express Completers will never Set the BCM bit. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10730 11501 10731 11502 10732 Table 2-37 Calculating Byte Count from Length and Byte 11503 Enables 10733 11504 10734 1st DW BE[3:0] (b) 10735 11505 Last DW BE[3:0] (b) 10737 11507 Total Byte Count 11509 10739 11510 10740 11511 10741 1xx1 10743 11513 1xx1 11514 0000 [Footnote: Note that Last DW BE of 0000b is permitted only with a Length of 1 DW.] 10949 11515 0000 [Footnote: Note that Last DW BE of 0000b is permitted only with a Length of 1 DW.] 11720 10950 1000 10951 11721 1000 11722 10952 0001 10953 11723 0001 11724 10954 (Length * 4) - 6 11725 10955 11726 10956 11727 10957 11728 10958 10961 Total Byte Count 11512 10742 10960 Last DW BE[3:0] (b) 11508 10738 10959 First DW BE[3:0] (b) 11506 10736 10744 Table 2-38 Calculating Byte Count from Length and Byte Enables (Length * 4) - 6 11729 For all Memory Read Completions, the Lower Address field must indicate the lower bits of the byte address for the first enabled byte of data returned with the Completion For the first (or only) Completion, the Completer can generate this field from the least significant 5 bits of the address of the Request concatenated with 2 bits of byte-level address formed as shown in Table 2-38 Calculating Lower Address from 1st DW BE . For any subsequent Completions, the Lower Address field will always be zero except for Completions generated by a Root Complex with an RCB value of 64 bytes. In this case the least significant 6 bits of the Lower Address field will always be zero and the most significant bit of the Lower Address field will toggle according to the alignment of the 64-byte data payload. 11730 11731 11732 10962 11733 10963 11734 10964 11735 10965 10966 11736 Table 2-38 Calculating Lower Address from 1st DW BE 10967 10968 11737 1st DW BE[3:0] (b) 11739 First DW BE[3:0] (b) 11740 Lower Address[1:0] (b) 11741 10971 11742 10972 11743 Page 169 Table 2-39 Calculating Lower Address from First DW BE 11738 10969 10970 For all Memory Read Completions, the Lower Address field must indicate the lower bits of the byte address for the first enabled byte of data returned with the Completion. For the first (or only) Completion, the Completer can generate this field from the least significant 5 bits of the address of the Request concatenated with 2 bits of byte-level address formed as shown in Table 2-39 Calculating Lower Address from First DW BE . For any subsequent Completions, the Lower Address field will always be zero except for Completions generated by a Root Complex with an RCB value of 64 bytes. In this case the least significant 6 bits of the Lower Address field will always be zero and the most significant bit of the Lower Address field will toggle according to the alignment of the 64-byte data payload. Lower Address[1:0] (b) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 10972 11743 10973 11744 10974 0000 10975 11745 10976 00 11747 10977 11748 10978 11749 10999 11 11771 11001 11772 11002 11773 11003 11774 11004 11006 11007 This Completion is the final Completion for the The Completer must not transmit additional Completions for this Request. Example: Completer split the Request into four parts for servicing; the second Completion had a Completer Abort Completion Status; the Completer terminated servicing for the Request, and did not Transmit the remaining two Completions. 11012 11778 11780 11782 11785 11786 11787 11017 11788 11018 11789 11019 11021 11791 11792 11793 11023 11794 11024 Page Example: Completer split the Request into four parts for servicing; the second Completion had a Completer Abort Completion Status; the Completer terminated servicing for the Request, and did not Transmit the remaining two Completions. The Byte Count field must indicate the remaining number of bytes that would be required to complete the Request (as if the Completion Status were Successful Completion) The Lower Address field must indicate the lower bits of the byte address for the first enabled byte of data that would have been returned with the Completion if the Completion Status were Successful Completion 11790 Implementation Note Restricted Programming Model 11022 11025 This Completion is the final Completion for the Request The Completer must not transmit additional Completions for this Request 11784 The Byte Count field must indicate the remaining number of bytes that would be required to complete the Request (as if the Completion Status were Successful Completion) The Lower Address field must indicate the lower bits of the byte address for the first enabled byte of data that would have been returned with the Completion if the Completion Status were Successful Completion 11016 11020 When a Read Completion is generated with a Completion Status other than Successful Completion: No data is included with the Completion The Cpl (or CplLk) encoding is used instead of CplD (or CplDLk) 11783 11013 11015 11777 11781 Request. 11014 11776 11779 11009 11011 11 11775 When a Read Completion is generated with a Completion Status other than Successful Completion: No data is included with the Completion The Cpl (or CplLk) encoding is used instead of CplD (or CplDLk) 11008 11010 00 11770 11000 11005 0000 11746 Implementation Note Restricted Programming Model 11795 When a device's programming model restricts (vs. what is otherwise permitted in PCI Express) the size and/or alignment of Read Requests directed to the device, that device is permitted to use a Completer Abort Completion Status for Read Requests which violate the programming model. An implication of this is that such devices, generally devices where all communication will be between the device's driver software and the device itself, need not necessarily implement the buffering required to generate Completions of length RCB. However, in all 170 cases, the boundaries specified by RCB must be respected for all reads which the device will complete with Successful Completion status. 11796 When a device's programming model restricts (vs. what is otherwise permitted in PCI Express) the size and/or alignment of Read Requests directed to the device, that device is permitted to use a Completer Abort Completion Status for Read Requests that violate the programming model. An implication of this is that such devices, generally devices where all communication will be between the device's driver software and the device itself, need not necessarily implement the buffering required to generate Completions of length RCB. However, in all cases, the boundaries specified by RCB must be respected for all reads that the device will complete with Successful Completion status. 11025 11796 When a device's programming model restricts (vs. what is otherwise permitted in PCI Express) the size and/or alignment of Read /private/tmp/PCISIG/pcie4_combined-snapshot.html Requests directed to the device, that device is permitted vs. to use a Completer Abort Completion Status for Read Requests which violate the /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html programming model. An implication of this is that such devices, generally devices where all communication will be between the device's driver software and the device itself, need not necessarily implement the buffering required to generate Completions of length RCB. However, in all cases, the boundaries specified by RCB must be respected for all reads which the device will complete with Successful Completion status. 11026 11797 11027 11798 11028 Examples: 11799 11029 11800 11030 11801 11031 11032 11803 11805 11035 192 -or- 128, 64 -or- 64, 128 -or- 64, 64, 64 11806 11069 11840 11070 11841 11071 11842 11072 11843 11073 11844 11074 11845 11075 11846 11076 2.3.2 Completion Handling Rules 11078 11082 11848 2.3.2 Completion Handling Rules 11849 When a device receives a Completion which does not match the Transaction ID for any of the outstanding Requests issued by that device, the Completion is called an “Unexpected Completion”. If a received Completion matches the Transaction ID of an outstanding Request, but in some other way does not match the corresponding Request (e.g., a problem with Attributes, Traffic Class, Byte Count, Lower Address, etc.), it is strongly recommended for the Receiver to handle the Completion as a Malformed TLP. The Completer must not check the IDO Attribute (Attribute Bit 2) in the Completion, since the Requester is not required to copy the value of IDO from the Request into the Completion for that request as stated in Section 2.2.6.4 Relaxed Ordering and ID-Based Ordering Attributes and Section 2.2.9 Completion Rules . However, if the Completion is otherwise properly formed, it is permitted [Footnote: For the case where only the Byte Count or Lower Address fields mismatch the expected values for a Memory Read Request, it is actually recommended for the Receiver to handle the Completion as an Unexpected Completion, since the mismatch might be caused by a previous Completion being misrouted.] for the Receiver to handle the Completion as an Unexpected Completion. 11083 11084 192 -or- 128, 64 -or- 64, 128 -or- 64, 64, 64 11847 11077 11081 Memory Read Request with Address of 1 0000h and Length of C0h bytes (192 decimal) could be completed by a Root Complex with an RCB value of 64 bytes with one of the following combinations of Completions (bytes): 11804 11034 11080 Examples: 11802 Memory Read Request with Address of 1 0000h and Length of C0h bytes (192 decimal) could be completed by a Root Complex with an RCB value of 64 bytes with one of the following combinations of Completions (bytes): 11033 11079 When a device's programming model restricts (vs. what is otherwise permitted in PCI Express) the size and/or alignment of Read Requests directed to the device, that device is permitted to use a Completer Abort Completion Status for Read Requests that violate the programming model. An implication of this is that such devices, generally devices where all communication will be between the device's driver software and the device itself, need not necessarily implement the buffering required to generate Completions of length RCB. However, in all cases, the boundaries specified by RCB must be respected for all reads that the device will complete with Successful Completion status. 11850 11851 11852 11853 When a device receives a Completion that does not match the Transaction ID for any of the outstanding Requests issued by that device, the Completion is called an “Unexpected Completion”. If a received Completion matches the Transaction ID of an outstanding Request, but in some other way does not match the corresponding Request (e.g., a problem with Attributes, Traffic Class, Byte Count, Lower Address, etc.), it is strongly recommended for the Receiver to handle the Completion as a Malformed TLP. The Completer must not check the IDO Attribute (Attribute Bit 2) in the Completion, since the Requester is not required to copy the value of IDO from the Request into the Completion for that request as stated in Section 2.2.6.4 Relaxed Ordering and ID-Based Ordering Attributes and Section 2.2.9 Completion Rules . However, if the Completion is otherwise properly formed, it is permitted [Footnote: For the case where only the Byte Count or Lower Address fields mismatch the expected values for a Memory Read Request, it is actually recommended for the Receiver to handle the Completion as an Unexpected Completion, since the mismatch might be caused by a previous Completion being misrouted.] for the Receiver to handle the Completion as an Unexpected Completion. 11854 When an Ingress Port of a Switch receives a Completion which cannot be forwarded, that Ingress Port must handle the Completion as an Unexpected Completion. This includes Completions that target: Page 171 11855 When an Ingress Port of a Switch receives a Completion that cannot be forwarded, that Ingress Port must handle the Completion as an Unexpected Completion. This includes Completions that target: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11084 When an Ingress Port of a Switch receives a Completion which 11085 11086 11087 11088 cannot be forwarded, that Ingress Port must handle the Completion as an Unexpected Completion. This includes Completions that target: a non-existent Function in the Device associated with the Upstream Port, a non-existent Device on the Bus associated with the Upstream Port, a non-existent Device or Function on the internal switching fabric, or a Bus Number within the Upstream Port's Bus Number aperture but not claimed by any Downstream Port. 11089 11090 11091 11092 11855 11856 11857 11858 11859 11860 Receipt of an Unexpected Completion is an error and must be handled according to the following rules: The agent receiving an Unexpected Completion must discard the Completion. An Unexpected Completion is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11861 11862 11863 11093 11864 11094 11865 11104 11105 11106 11107 11108 11109 11877 11878 11879 11880 Root Complex handling of a Completion with Configuration Request Retry Status for a Configuration Request is implementation specific, except for the period following system reset (see Section 6.6 PCI Express Reset - Rules ). For Root Complexes that support CRS Software Visibility, the following rules apply: If CRS Software Visibility is not enabled, the Root Complex must re-issue the Configuration Request as a new Request. If CRS Software Visibility is enabled (see below): For a Configuration Read Request that includes both bytes of the Vendor ID field of a device Function's Configuration Space Header, the Root Complex must complete the Request to the host by returning a read-data value of 0001h for the Vendor ID field and all ‘1’s for any additional bytes included in the request. This read-data value has been reserved specifically for this use by the PCI-SIG and does not correspond to any assigned Vendor ID. For a Configuration Write Request or for any other Configuration Read Request, the Root Complex must re-issue the Configuration Request as a new Request. 11882 A Root Complex implementation may choose to limit the number of Configuration Request/CRS Completion Status loops before determining that something is wrong with the target of the Request and taking appropriate action, e.g., complete the Request to the host as a failed transaction. 11883 11113 Page 11876 11881 A Root Complex implementation may choose to limit the number of Configuration Request/CRS Completion Status loops before determining that something is wrong with the target of the Request and taking appropriate action, e.g., complete the Request to the host as a failed transaction. 11112 11114 Receipt of an Unexpected Completion is an error and must be handled according to the following rules: The agent receiving an Unexpected Completion must discard the Completion. An Unexpected Completion is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11875 Root Complex handling of a Completion with Configuration Request Retry Status for a Configuration Request is implementation specific, except for the period following system reset (see Section 6.6 PCI Express Reset - Rules ). For Root Complexes that support CRS Software Visibility, the following rules apply: If CRS Software Visibility is not enabled, the Root Complex must re-issue the Configuration Request as a new Request. If CRS Software Visibility is enabled (see below): For a Configuration Read Request that includes both bytes of the Vendor ID field of a device Function's Configuration Space Header, the Root Complex must complete the Request to the host by returning a read-data value of 0001h for the Vendor ID field and all ‘1’s for any additional bytes included in the request. This read-data value has been reserved specifically for this use by the PCI-SIG and does not correspond to any assigned Vendor ID. For a Configuration Write Request or for any other Configuration Read Request, the Root Complex must re-issue the Configuration Request as a new Request. 11110 11111 When an Ingress Port of a Switch receives a Completion that cannot be forwarded, that Ingress Port must handle the Completion as an Unexpected Completion. This includes Completions that target: a non-existent Function in the Device associated with the Upstream Port, a non-existent Device on the Bus associated with the Upstream Port, a non-existent Device or Function on the internal switching fabric, or a Bus Number within the Upstream Port's Bus Number aperture but not claimed by any Downstream Port. 11884 CRS Software Visibility may be enabled through the CRS Software Visibility Enable bit in the Root Control register (see Section 7.5.3.12 Root Control Register (Offset 1Ch) ) to control Root Complex behavior on an individual Root Port basis. Alternatively, Root Complex behavior may be managed through the CRS Software Visibility Enable bit in the RCRB Control register as described in Section 7.9.7.4 172 RCRB Control register (Offset 0Ch) , permitting the behavior of one or more Root Ports or RCiEPs to be controlled by a single Enable bit. For this alternate case, each Root Port or RCiEP declares its association with a particular Enable bit via an RCRB header association in a Root Complex Link Declaration Capability (see Section 7.9.8 Root Complex Link Declaration Extended Capability ). Each Root Port or RCiEP is permitted to be controlled by at most one Enable bit. Thus, for example, it is prohibited for a Root Port whose Root Control register contains an Enable bit to declare an RCRB header association to an RCRB that also includes 11885 CRS Software Visibility may be enabled through the CRS Software Visibility Enable bit in the Root Control register (see Section 7.5.3.12 Root Control Register (Offset 1Ch) ) to control Root Complex behavior on an individual Root Port basis. Alternatively, Root Complex behavior may be managed through the CRS Software Visibility Enable bit in the Root Complex Register Block (RCRB) Control register as described in Section 7.9.7.4 RCRB Control register (Offset 0Ch) , permitting the behavior of one or more Root Ports or RCiEPs to be controlled by a single Enable bit. For this alternate case, each Root Port or RCiEP declares its association with a particular Enable bit via an RCRB header association in a Root Complex Link Declaration Capability (see Section 7.9.8 Root Complex Link Declaration Extended Capability ). Each Root Port or RCiEP is permitted to be controlled by at most one Enable bit. Thus, for example, it is prohibited for a Root Port whose Root Control register contains an Enable bit to declare an RCRB header 11114 CRS Software Visibility may be enabled through /private/tmp/PCISIG/pcie4_combined-snapshot.html the CRS Software Visibility Enable bit in the Root Controlvs. register (see Section 7.5.3.12 Root Control Register (Offset 1Ch) ) to control Root /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html Complex behavior on an individual Root Port basis. Alternatively, Root 11885 Complex behavior may be managed through the CRS Software Visibility Enable bit in the RCRB Control register as described in Section 7.9.7.4 RCRB Control register (Offset 0Ch) , permitting the behavior of one or more Root Ports or RCiEPs to be controlled by a single Enable bit. For this alternate case, each Root Port or RCiEP declares its association with a particular Enable bit via an RCRB header association in a Root Complex Link Declaration Capability (see Section 7.9.8 Root Complex Link Declaration Extended Capability ). Each Root Port or RCiEP is permitted to be controlled by at most one Enable bit. Thus, for example, it is prohibited for a Root Port whose Root Control register contains an Enable bit to declare an RCRB header association to an RCRB that also includes an Enable bit in its RCRB Header Capability. The presence of an Enable bit in a Root Port or RCRB Header Capability is indicated by the corresponding CRS Software Visibility bit (see Section 7.5.3.13 Root Capabilities Register (Offset 1Eh) and , respectively). 11115 11886 11116 11887 11117 11118 11119 11888 Completions with a Configuration Request Retry Status in response to a Request other than a Configuration Request are illegal. Receivers may optionally report these violations as Malformed TLPs This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ) 11120 11121 11122 11123 11126 11127 11130 11131 11893 11894 Completions with a Reserved Completion Status value are treated as if the Completion Status was Unsupported Request (UR). Completions with a Completion Status of Unsupported Request or Completer Abort are reported using the conventional PCI reporting mechanisms (see Section 7.5.1.1.4 Status Register (Offset 06h) ). Note that the error condition that triggered the generation of such a Completion is reported by the Completer as described in Section 6.2 Error Signaling and Logging . 11896 11897 11898 When a Read Completion or an AtomicOp Completion is received with a Completion Status other than Successful Completion: No data is included with the Completion The Cpl (or CplLk) encoding is used instead of CplD (CplDLk) 11900 11901 11902 This Completion is the final Completion for the Request The Requester must consider the Request terminated, and not expect additional Completions Handling of partial Completions Received earlier is implementation specific 11903 11133 Page 11892 11899 This Completion is the final Completion for the Request. The Requester must consider the Request terminated, and not expect additional Completions. Handling of partial Completions Received earlier is implementation specific. 11132 11134 11890 Completions with a Configuration Request Retry Status in response to a Request other than a Configuration Request are illegal. Receivers may optionally report these violations as Malformed TLPs. This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11895 When a Read Completion or an AtomicOp Completion is received with a Completion Status other than Successful Completion: No data is included with the Completion The Cpl (or CplLk) encoding is used instead of CplD (CplDLk) 11128 11129 11889 11891 Completions with a Reserved Completion Status value are treated as if the Completion Status was Unsupported Request (UR) Completions with a Completion Status of Unsupported Request or Completer Abort are reported using the conventional PCI reporting mechanisms (see Section 7.5.1.1.4 Status Register (Offset 06h) ) Note that the error condition that triggered the generation of such a Completion is reported by the Completer as described in Section 6.2 Error Signaling and Logging 11124 11125 CRS Software Visibility may be enabled through the CRS Software Visibility Enable bit in the Root Control register (see Section 7.5.3.12 Root Control Register (Offset 1Ch) ) to control Root Complex behavior on an individual Root Port basis. Alternatively, Root Complex behavior may be managed through the CRS Software Visibility Enable bit in the Root Complex Register Block (RCRB) Control register as described in Section 7.9.7.4 RCRB Control register (Offset 0Ch) , permitting the behavior of one or more Root Ports or RCiEPs to be controlled by a single Enable bit. For this alternate case, each Root Port or RCiEP declares its association with a particular Enable bit via an RCRB header association in a Root Complex Link Declaration Capability (see Section 7.9.8 Root Complex Link Declaration Extended Capability ). Each Root Port or RCiEP is permitted to be controlled by at most one Enable bit. Thus, for example, it is prohibited for a Root Port whose Root Control register contains an Enable bit to declare an RCRB header association to an RCRB that also includes an Enable bit in its RCRB Header Capability. The presence of an Enable bit in a Root Port or RCRB Header Capability is indicated by the corresponding CRS Software Visibility bit (see Section 7.5.3.13 Root Capabilities Register (Offset 1Eh) and Section 7.9.7.3 RCRB Capabilities register (Offset 08h) , respectively). 11904 Example: The Requester received 32 bytes of Read data for a 128-byte Read Request it had issued, then a Completion with the Completer Abort Completion Status. The Requester then must free the internal resources which had been allocated for that particular Read Request. 173 11905 Example: The Requester received 32 bytes of Read data for a 128-byte Read Request it had issued, then it receives a Completion with the Completer Abort Completion Status. The Requester then must free the internal resources that had been allocated for that particular Read Request. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 11134 Example: The Requester received 32 bytes of Read /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html data for a 128-byte Read Request it had issued, then a Completion with 11905 the Completer Abort Completion Status. The Requester then must free the internal resources which had been allocated for that particular Read Request. 11135 11906 11136 11907 11137 11908 11138 11909 11139 11910 11140 11911 11141 Implementation Note Read Data Values with UR Completion Status 11142 11912 11913 11143 11914 11144 11915 11151 11922 11152 11923 11153 11925 2.4 Transaction Ordering 11155 11926 11156 11927 11157 11929 2.4.1 Transaction Ordering Rules 11159 11931 Table 2-39 Ordering Rules Summary defines the ordering requirements for PCI Express Transactions. The rules defined in this table apply uniformly to all types of Transactions on PCI Express including Memory, I/O, Configuration, and Messages. The ordering rules defined in this table apply within a single Traffic Class (TC). There is no ordering requirement among transactions with different TC labels. Note that this also implies that there is no ordering required between traffic that flows through different Virtual Channels since transactions with the same TC label are not allowed to be mapped to multiple VCs on any PCI Express Link. 11162 11932 Table 2-40 Ordering Rules Summary defines the ordering requirements for PCI Express Transactions. The rules defined in this table apply uniformly to all types of Transactions on PCI Express including Memory, I/O, Configuration, and Messages. The ordering rules defined in this table apply within a single Traffic Class (TC). There is no ordering requirement among transactions with different TC labels. Note that this also implies that there is no ordering required between traffic that flows through different Virtual Channels since transactions with the same TC label are not allowed to be mapped to multiple VCs on any PCI Express Link. 11933 11163 11934 For Table 2-39 Ordering Rules Summary , a first issued transaction and the rows represent a transaction. The table entry indicates the ordering the two transactions. The table entries are defined the columns represent subsequently issued relationship between as follows: 11165 11935 For Table 2-40 Ordering Rules Summary , a first issued transaction and the rows represent a transaction. The table entry indicates the ordering the two transactions. The table entries are defined the columns represent subsequently issued relationship between as follows: 11936 11166 11937 11167 Yes 11168 11938 Yes 11939 The second transaction (row) must be allowed to pass the first (column) to avoid deadlock. (When blocking occurs, the second transaction is required to pass the first transaction. Fairness must be comprehended to prevent starvation.) 11170 11940 The second transaction (row) must be allowed to pass the first (column) to avoid deadlock. (When blocking occurs, the second transaction is required to pass the first transaction. Fairness must be comprehended to prevent starvation.) 11941 11171 Y/N 11172 11173 2.4.1 Transaction Ordering Rules 11930 11160 11169 2.4 Transaction Ordering 11928 11158 11164 Implementation Note Read Data Values with UR Completion Status 11924 11154 11161 Example: The Requester received 32 bytes of Read data for a 128-byte Read Request it had issued, then it receives a Completion with the Completer Abort Completion Status. The Requester then must free the internal resources that had been allocated for that particular Read Request. 11942 Y/N 11943 There are no requirements. The second transaction may optionally pass the first transaction or be blocked by it. Page 174 11944 There are no requirements. The second transaction may optionally pass the first transaction or be blocked by it. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11173 There are no requirements. The second transaction may optionally pass the first transaction or be blocked by it. 11174 There are no requirements. The second transaction may optionally pass the first transaction or be blocked by it. 11945 11175 11946 No 11176 11177 11944 No 11947 The second transaction must not be allowed to pass the first transaction. This is required to support the producer/consumer strong ordering model. 11948 11178 11949 11179 11950 11180 11181 11951 Table 2-39 Ordering Rules Summary 11182 11183 11952 Row Pass Column? 11954 Posted Request (Col 2) 11186 11956 11188 11959 11962 11190 11964 11191 11965 11192 11194 11967 11970 11196 11972 11197 11973 11198 11200 11202 11975 11209 11979 11981 Yes 11983 a) Y/N b) Yes 11985 11986 11987 11211 11988 11212 11214 Page 175 Yes Yes 11984 11210 11213 a) No b) Y/N 11982 11207 11208 11978 11980 Yes 11205 11206 Posted Request (Row A) 11977 a) No b) Y/N 11203 11204 NPR with Data (Col 4) 11974 Posted Request (Row A) 11976 11201 Read Request (Col 3) 11969 NPR with Data (Col 4) 11971 11199 Completion (Col 5) 11966 Read Request (Col 3) 11968 11195 Non-Posted Request 11961 Completion (Col 5) 11963 11193 Posted Request (Col 2) 11958 Non-Posted Request 11960 11189 Row Pass Column? 11955 11957 11187 Table 2-40 Ordering Rules Summary 11953 11184 11185 The second transaction must not be allowed to pass the first transaction. This is required to support the producer/consumer strong ordering model. a) Y/N b) Yes 11989 Non-Posted Request 11990 11991 Non-Posted Request /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11214 11991 11215 Read Request (Row B) 11992 Read Request (Row B) 11993 11216 11994 11217 a) No b) Y/N 11218 11219 11995 a) No b) Y/N 11996 11997 11220 Y/N 11221 11998 Y/N 11999 11222 Y/N 11223 12000 Y/N 12001 11224 Y/N 12002 11225 12003 11226 12004 11227 Y/N 12005 11228 NPR with Data (Row C) 12006 NPR with Data (Row C) 12007 11229 12008 11230 a) No b) Y/N 11231 11232 12009 a) No b) Y/N 12010 12011 11233 Y/N 11234 12012 Y/N 12013 11235 Y/N 11236 12014 Y/N 12015 11237 Y/N 12016 11238 12017 11239 12018 11240 Y/N 12019 11241 Completion (Row D) 12020 Completion (Row D) 12021 11242 12022 11243 a) No b) Y/N 11244 11245 12023 12025 11246 Yes 11247 12026 Yes 12027 11248 Yes 11249 12028 Yes 12029 11250 a) Y/N b) No 11251 12030 12032 11253 12033 11254 12034 11255 12035 11256 a) Y/N b) No 12031 11252 11257 a) No b) Y/N 12024 12036 Explanation of the row and column headers in Table 2-39 Ordering Rules Summary : 11258 12037 Explanation of the row and column headers in Table 2-40 Ordering Rules Summary : 12038 11259 12039 11260 A Posted Request is a Memory Write Request or a Message Request. Page 176 12040 A Posted Request is a Memory Write Request or a Message Request. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11260 A Posted Request is a Memory Write Request or a Message 12040 Request. 11261 12041 11262 11263 12042 A Read Request is a Configuration Read Request, an I/O Read Request, or a Memory Read Request. 11264 12043 12045 An NPR (Non-Posted Request) with Data is a Configuration Write Request, an I/O Write Request, or an AtomicOp Request. 11267 12046 12048 11269 A Non-Posted Request is a Read Request or an NPR with Data. 11270 12049 12051 11272 Explanation of the entries in Table 2-39 Ordering Rules 12052 Summary : 12053 11274 12054 11275 A2a 11276 A Posted Request must not pass another Posted Request unless A2b applies. A2a 12057 A Posted Request must not pass another Posted Request unless A2b applies. 12058 11279 A2b 11280 12059 A2b 12060 A Posted Request with RO [Footnote: In this section, “RO” is an abbreviation for the Relaxed Ordering Attribute field.] Set is permitted to pass another Posted Request. [Footnote: Some usages are enabled by not implementing this passing (see the No RO-enabled PR-PR Passing bit in ).] A Posted Request with IDO Set is permitted to pass another Posted Request if the two Requester IDs are different or if both Requests contain a PASID TLP Prefix and the two PASID values are different. 11282 12061 A Posted Request with RO [Footnote: In this section, “RO” is an abbreviation for the Relaxed Ordering Attribute field.] Set is permitted to pass another Posted Request. [Footnote: Some usages are enabled by not implementing this passing (see the No RO-enabled PR-PR Passing bit in Section 7.5.3.15 Device Capabilities 2 Register (Offset 24h) ).] A Posted Request with IDO Set is permitted to pass another Posted Request if the two Requester IDs are different or if both Requests contain a PASID TLP Prefix and the two PASID values are different. 12062 11283 A3, A4 11284 12063 A3, A4 12064 A Posted Request must be able to pass Non-Posted Requests to avoid deadlocks. 11286 12065 A Posted Request must be able to pass Non-Posted Requests to avoid deadlocks. 12066 11287 A5a 11288 12067 A5a 12068 A Posted Request is permitted to pass a Completion, but is not required to be able to pass Completions unless A5b applies. 11290 12069 A Posted Request is permitted to pass a Completion, but is not required to be able to pass Completions unless A5b applies. 12070 11291 11333 12055 12056 11278 11289 Explanation of the entries in Table 2-40 Ordering Rules Summary : 11273 11285 A Non-Posted Request is a Read Request or an NPR with Data. 12050 11271 11281 An NPR (Non-Posted Request) with Data is a Configuration Write Request, an I/O Write Request, or an AtomicOp Request. 12047 11268 11277 A Read Request is a Configuration Read Request, an I/O Read Request, or a Memory Read Request. 12044 11265 11266 A Posted Request is a Memory Write Request or a Message Request. A5b Completions with different Transaction IDs are permitted to pass each other. 11334 11335 11336 Page 177 12071 12113 A5b Completions with different Transaction IDs are permitted to pass each other. 12114 D5b 12115 12116 D5b /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11336 11337 12116 Completions with the same Transaction ID must not pass each other. This ensures that multiple Completions associated with a single Memory Read Request will remain in ascending address order. 11338 12119 11340 Additional Rules: 11341 11343 11344 Completions with the same Transaction ID must not pass each other. This ensures that multiple Completions associated with a single Memory Read Request will remain in ascending address order. 12118 11339 11342 12117 12120 Additional Rules: 12121 PCI Express Switches are permitted to allow a Memory Write or Message Request with the Relaxed Ordering bit set to pass any previously posted Memory Write or Message Request moving in the same direction. Switches must forward the Relaxed Ordering attribute unmodified. The Root Complex is also permitted to allow data bytes within the Request to be written to system memory in any order. (The bytes must be written to the correct system memory locations. Only the order in which they are written is unspecified). For Root Complex and Switch, Memory Write combining (as defined in the [[PCI Local Bus Specification]]) is prohibited. Note: This is required so that devices can be permitted to optimize their receive buffer and control logic for Memory Write sizes matching their natural expected sizes, rather than being required to support the maximum possible Memory Write payload size. 12122 12123 12124 PCI Express Switches are permitted to allow a Memory Write or Message Request with the Relaxed Ordering bit set to pass any previously posted Memory Write or Message Request moving in the same direction. Switches must forward the Relaxed Ordering attribute unmodified. The Root Complex is also permitted to allow data bytes within the Request to be written to system memory in any order. (The bytes must be written to the correct system memory locations. Only the order in which they are written is unspecified). For Root Complex and Switch, Memory Write combining (as defined in the [ PCI ]) is prohibited. Note: This is required so that devices can be permitted to optimize their receive buffer and control logic for Memory Write sizes matching their natural expected sizes, rather than being required to support the maximum possible Memory Write payload size. 12125 11345 11346 11347 11348 11349 11350 11351 Combining of Memory Read Requests, and/or Completions for different Requests is prohibited. The No Snoop bit does not affect the required ordering behavior. For Root Ports and Switch Downstream Ports, acceptance of a Posted Request or Completion must not depend upon the transmission of a Non-Posted Request within the same traffic class. [Footnote: Satisfying the above rules is a necessary, but not sufficient condition to ensure deadlock free operation. Deadlock free operation is dependent upon the system topology, the number of Virtual Channels supported and the configured Traffic Class to Virtual Channel mappings. Specification of platform and system constraints to ensure deadlock free operation is outside the scope of this specification (see Appendix D Request Dependencies for a discussion of relevant issues).] For Switch Upstream Ports, acceptance of a Posted Request or Completion must not depend upon the transmission on a Downstream Port of Non-Posted Request within the same traffic class. [Footnote: 34] For Endpoint, Bridge, and Switch Upstream Ports, the acceptance of a Posted Request must not depend upon the transmission of any TLP from that same Upstream Port within the same traffic class. [Footnote: 34] For Endpoint, Bridge, and Switch Upstream Ports, the acceptance of a Non-posted Request must not depend upon the transmission of a Non-Posted Request from that same Upstream Port within the same traffic class. [Footnote: 34] For Endpoint, Bridge, and Switch Upstream Ports, the acceptance of a Completion must not depend upon the transmission of any TLP from that same Upstream Port within the same traffic class. [Footnote: 34] Page 178 12126 12127 12128 12129 12130 Combining of Memory Read Requests, and/or Completions for different Requests is prohibited. The No Snoop bit does not affect the required ordering behavior. For Root Ports and Switch Downstream Ports, acceptance of a Posted Request or Completion must not depend upon the transmission of a Non-Posted Request within the same traffic class. [Footnote: Satisfying the above rules is a necessary, but not sufficient condition to ensure deadlock free operation. Deadlock free operation is dependent upon the system topology, the number of Virtual Channels supported and the configured Traffic Class to Virtual Channel mappings. Specification of platform and system constraints to ensure deadlock free operation is outside the scope of this specification (see Appendix D Request Dependencies for a discussion of relevant issues).] For Switch Upstream Ports, acceptance of a Posted Request or Completion must not depend upon the transmission on a Downstream Port of Non-Posted Request within the same traffic class. [Footnote: Satisfying the above rules is a necessary, but not sufficient condition to ensure deadlock free operation. Deadlock free operation is dependent upon the system topology, the number of Virtual Channels supported and the configured Traffic Class to Virtual Channel mappings. Specification of platform and system constraints to ensure deadlock free operation is outside the scope of this specification (see Appendix D Request Dependencies for a discussion of relevant issues).] For Endpoint, Bridge, and Switch Upstream Ports, the acceptance of a Posted Request must not depend upon the transmission of any TLP from that same Upstream Port within the same traffic class. [Footnote: Satisfying the above rules is a necessary, but not sufficient condition to ensure deadlock free operation. Deadlock free operation is dependent upon the system topology, the number of Virtual Channels supported and the configured Traffic Class to Virtual Channel mappings. Specification of platform and system constraints to ensure deadlock free operation is outside the scope of this specification (see Appendix D Request Dependencies for a discussion of relevant issues).] /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 11351 For Endpoint, Bridge, and Switch Upstream Ports, the /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html acceptance of a Completion must not depend upon the transmission of any 12130 TLP from that same Upstream Port within the same traffic class. [Footnote: 34] 12131 12132 For Endpoint, Bridge, and Switch Upstream Ports, the acceptance of a Posted Request must not depend upon the transmission of any TLP from that same Upstream Port within the same traffic class. [Footnote: Satisfying the above rules is a necessary, but not sufficient condition to ensure deadlock free operation. Deadlock free operation is dependent upon the system topology, the number of Virtual Channels supported and the configured Traffic Class to Virtual Channel mappings. Specification of platform and system constraints to ensure deadlock free operation is outside the scope of this specification (see Appendix D Request Dependencies for a discussion of relevant issues).] For Endpoint, Bridge, and Switch Upstream Ports, the acceptance of a Non-posted Request must not depend upon the transmission of a Non-Posted Request from that same Upstream Port within the same traffic class. [Footnote: Satisfying the above rules is a necessary, but not sufficient condition to ensure deadlock free operation. Deadlock free operation is dependent upon the system topology, the number of Virtual Channels supported and the configured Traffic Class to Virtual Channel mappings. Specification of platform and system constraints to ensure deadlock free operation is outside the scope of this specification (see Appendix D Request Dependencies for a discussion of relevant issues).] For Endpoint, Bridge, and Switch Upstream Ports, the acceptance of a Completion must not depend upon the transmission of any TLP from that same Upstream Port within the same traffic class. [Footnote: Satisfying the above rules is a necessary, but not sufficient condition to ensure deadlock free operation. Deadlock free operation is dependent upon the system topology, the number of Virtual Channels supported and the configured Traffic Class to Virtual Channel mappings. Specification of platform and system constraints to ensure deadlock free operation is outside the scope of this specification (see Appendix D Request Dependencies for a discussion of relevant issues).] 12133 11352 11353 12134 Note that Endpoints are never permitted to block acceptance of a Completion. 11354 11355 11356 Note that Endpoints are never permitted to block acceptance of a Completion. 12136 Completions issued for Non-Posted requests must be returned in the same Traffic Class as the corresponding Non-Posted request. Root Complexes that support peer-to-peer operation and Switches must enforce these transaction ordering rules for all forwarded traffic. 11357 12137 12138 Completions issued for Non-Posted requests must be returned in the same Traffic Class as the corresponding Non-Posted request. Root Complexes that support peer-to-peer operation and Switches must enforce these transaction ordering rules for all forwarded traffic. 12139 11358 11359 12135 12140 To ensure deadlock-free operation, devices should not forward traffic from one Virtual Channel to another. The specification of constraints used to avoid deadlock in systems where devices forward or translate transactions between Virtual Channels is outside the scope of this document (see Appendix D Request Dependencies for a discussion of relevant issues). 12141 11360 12142 11361 12143 11362 11363 11364 12144 Implementation Note Large Memory Reads vs. Multiple Smaller Memory Reads 12145 12146 11365 12147 11366 12148 Page 179 To ensure deadlock-free operation, devices should not forward traffic from one Virtual Channel to another. The specification of constraints used to avoid deadlock in systems where devices forward or translate transactions between Virtual Channels is outside the scope of this document (see Appendix D Request Dependencies for a discussion of relevant issues). Implementation Note Large Memory Reads vs. Multiple Smaller Memory Reads /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11366 12148 11367 11368 12149 Note that the rule associated with entry D5b in Table 2-39 Ordering Rules Summary ensures that for a single Memory Read Request serviced with multiple Completions, the Completions will be returned in address order. However, the rule associated with entry D5a permits that different Completions associated with distinct Memory Read Requests may be returned in a different order than the issue order for the Requests. For example, if a device issues a single Memory Read Request for 256 bytes from location 1000h, and the Request is returned using two Completions (see Section 2.3.1.1 Data Return for Read Requests ) of 128 bytes each, it is guaranteed that the two Completions will return in the following order: 11369 12152 11371 1st Completion returned: Data from 1000h to 107Fh. 11372 2nd Completion returned: Data from 1080h to 10FFh. 11375 12156 2nd Completion returned: Data from 1080h to 10FFh. 12157 11376 12158 However, if the device issues two Memory Read Requests for 128 bytes each, first to location 1000h, then to location 1080h, the two Completions may return in either order: 11378 12159 However, if the device issues two Memory Read Requests for 128 bytes each, first to location 1000h, then to location 1080h, the two Completions may return in either order: 12160 11447 12229 The Virtual Channel (VC) mechanism provides support for carrying, throughout the fabric, traffic that is differentiated using TC labels. The foundations of VCs are independent fabric resources (queues/ buffers and associated control logic). These resources are used to move information across Links with fully independent Flow Control between different VCs. This is key to solving the problem of flow-control induced blocking where a single traffic flow may create a bottleneck for all traffic within the system. 11449 12230 The Virtual Channel (VC) mechanism provides support for carrying, throughout the fabric, traffic that is differentiated using TC labels. The foundations of VCs are independent fabric resources (queues/ buffers and associated control logic). These resources are used to move information across Links with fully independent Flow Control between different VCs. This is key to solving the problem of flow-control induced blocking where a single traffic flow may create a bottleneck for all traffic within the system. 12231 11450 12232 Traffic is associated with VCs by mapping packets with particular TC labels to their corresponding VCs. The VC and MultiFunction Virtual Channel (MFVC) mechanisms allow flexible mapping of TCs onto the VCs. In the simplest form, TCs can be mapped to VCs on a 1:1 basis. To allow performance/cost tradeoffs, PCI Express provides the capability of mapping multiple TCs onto a single VC. Section 2.5.2 TC to VC Mapping covers details of TC to VC mapping. 11452 12233 Traffic is associated with VCs by mapping packets with particular TC labels to their corresponding VCs. The VC and MultiFunction Virtual Channel (MFVC) mechanisms allow flexible mapping of TCs onto the VCs. In the simplest form, TCs can be mapped to VCs on a 1:1 basis. To allow performance/cost tradeoffs, PCI Express provides the capability of mapping multiple TCs onto a single VC. Section 2.5.2 TC to VC Mapping covers details of TC to VC mapping. 12234 11453 11454 1st Completion returned: Data from 1000h to 107Fh. 12155 11374 11451 12153 12154 11373 11448 Note that the rule associated with entry D5b in Table 2-40 Ordering Rules Summary ensures that for a single Memory Read Request serviced with multiple Completions, the Completions will be returned in address order. However, the rule associated with entry D5a permits that different Completions associated with distinct Memory Read Requests may be returned in a different order than the issue order for the Requests. For example, if a device issues a single Memory Read Request for 256 bytes from location 1000h, and the Request is returned using two Completions (see Section 2.3.1.1 Data Return for Read Requests ) of 128 bytes each, it is guaranteed that the two Completions will return in the following order: 12151 11370 11377 12150 12235 A Virtual Channel is established when one or multiple TCs are associated with a physical VC resource designated by Virtual Channel Identification (VC ID). This process is controlled by configuration software as described in Section 6.3 Virtual Channel Support , Section 7.9.1 Virtual Channel Extended Capability , and Section 7.9.2 MultiFunction Virtual Channel Extended Capability . Page 180 12236 A Virtual Channel is established when one or multiple TCs are associated with a physical VC resource designated by Virtual Channel Identification (VC ID). This process is controlled by configuration software as described in Section 6.3 Virtual Channel Support , Section 7.9.1 Virtual Channel Extended Capability , and Section 7.9.2 MultiFunction Virtual Channel Extended Capability . 11454 A Virtual Channel is established when one or multiple TCs are 12236 associated with a physical VC resource designated by Virtual /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. Channel Identification (VC ID). This process is controlled by configuration /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html software as described in Section 6.3 Virtual Channel Support , Section 7.9.1 Virtual Channel Extended Capability , and Section 7.9.2 MultiFunction Virtual Channel Extended Capability . 11455 12237 11456 11457 12238 Support for TCs and VCs beyond default TC0/VC0 pair is optional. The association of TC0 with VC0 is fixed, i.e., “hardwired”, and must be supported by all components. Therefore the baseline TC/VC setup does not require any VC-specific hardware or software configuration. In order to ensure interoperability, components that do not implement the optional Virtual Channel Capability structure or MultiFunction Virtual Channel Capability structure must obey the following rules: 11458 11459 11460 11461 12241 12242 12243 A Requester must only generate requests with TC0 label. (Note that if the Requester initiates requests with a TC label other than TC0, the requests may be treated as malformed by the component on the other side of the Link that implements the extended VC capability and applies TC Filtering.) A Completer must accept requests with TC label other than TC0, and must preserve the TC label . That is, any completion that it generates must have the same TC label as the label of the request. A Switch must map all TCs to VC0 and must forward all transactions regardless of the TC label. 12245 A Device containing Functions capable of generating Requests with TC labels other than TC0 must implement suitable VC or MFVC Capability structures (as applicable), even if it only supports the default VC. Example Function types are Endpoints and Root Ports. This is required in order to enable mapping of TCs beyond the default configuration. It must follow the TC/VC mapping rules according to the software programming of the VC and MFVC Capability structures. 11465 12246 A Device containing Functions capable of generating Requests with TC labels other than TC0 must implement suitable VC or MFVC Capability structures (as applicable), even if it only supports the default VC. Example Function types are Endpoints and Root Ports. This is required in order to enable mapping of TCs beyond the default configuration. It must follow the TC/VC mapping rules according to the software programming of the VC and MFVC Capability structures. 12247 11466 12248 Figure 2-42 Virtual Channel Concept - An Illustration illustrates the concept of Virtual Channel. Conceptually, traffic that flows through VCs is multiplexed onto a common physical Link resource on the Transmit side and de-multiplexed into separate VC paths on the Receive side. 12249 11468 12250 11469 12251 11470 12252 11471 Figure 2-45 Virtual Channel Concept - An Illustration illustrates the concept of Virtual Channel. Conceptually, traffic that flows through VCs is multiplexed onto a common physical Link resource on the Transmit side and de-multiplexed into separate VC paths on the Receive side. 12253 11472 Figure 2-42 Virtual Channel Concept - An Illustration 12254 11473 12255 11474 12256 11475 11476 Support for TCs and VCs beyond the default TC0/VC0 pair is optional. The association of TC0 with VC0 is fixed, i.e., “hardwired”, and must be supported by all components. Therefore the baseline TC/VC setup does not require any VC-specific hardware or software configuration. In order to ensure interoperability, components that do not implement the optional Virtual Channel Capability structure or MultiFunction Virtual Channel Capability structure must obey the following rules: 12244 11463 11467 12239 12240 A Requester must only generate requests with TC0 label. (Note that if the Requester initiates requests with a TC label other than TC0, the requests may be treated as malformed by the component on the other side of the Link that implements the extended VC capability and applies TC Filtering.) A Completer must accept requests with TC label other than TC0, and must preserve the TC label, i.e. , any completion that it generates must have the same TC label as the label of the request. A Switch must map all TCs to VC0 and must forward all transactions regardless of the TC label. 11462 11464 A Virtual Channel is established when one or multiple TCs are associated with a physical VC resource designated by Virtual Channel Identification (VC ID). This process is controlled by configuration software as described in Section 6.3 Virtual Channel Support , Section 7.9.1 Virtual Channel Extended Capability , and Section 7.9.2 MultiFunction Virtual Channel Extended Capability . Figure 2-45 Virtual Channel Concept - An Illustration 12257 Internal to the Switch, every Virtual Channel requires dedicated phys Figure 2-43 Virtual Channel Concept - Switch Internals (Upstream Flow) shows conceptually the VC resources within the Switch (shown in Figure 2-42 Virtual Channel Concept - An Illustration ) that are required to support traffic flow in the Upstream direction. Page 181 12258 Internal to the Switch, every Virtual Channel requires dedicated phys Figure 2-46 Virtual Channel Concept - Switch Internals (Upstream Flow) shows conceptually the VC resources within the Switch (shown in Figure 2-45 Virtual Channel Concept - An Illustration ) that are required to support traffic flow in the Upstream direction. 11476 Internal to the Switch, every Virtual Channel requires /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. dedicated phys Figure 2-43 Virtual Channel Concept - Switch Internals (Upstream Flow) shows conceptually the VC resources within the Switch /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12258 (shown in Figure 2-42 Virtual Channel Concept - An Illustration ) that are required to support traffic flow in the Upstream direction. 11477 12259 11478 12260 11479 12261 11480 11481 12262 Figure 2-43 Virtual Channel Concept - Switch Internals (Upstream Flow) 12263 11482 12264 11483 12265 11484 11485 12267 12268 11487 12269 11488 Implementation Note VC and VC Buffering Considerations 11490 12271 12272 11491 12273 11492 12274 11493 12276 The amount of buffering beyond the architectural minimums per supported VC is implementation-specific. 12277 11496 12278 Buffering beyond the architectural minimums is not required to be identical across all VCs on a given Link, i.e. , an implementation may provide greater buffer depth for selected VCs as a function of implementation usage models and other Link attributes, e.g., Link width and signaling. 11498 12279 Buffering beyond the architectural minimums is not required to be identical across all VCs on a given Link . That is, an implementation may provide greater buffer depth for selected VCs as a function of implementation usage models and other Link attributes, e.g., Link width and signaling. 12280 11499 12281 Implementations may adjust their buffering per VC based on implementation-specific policies derived from configuration and VC enablement, e.g. , if a four VC implementation has only two VCs enabled, the implementation may assign the non-enabled VC buffering to the enabled VCs to improve fabric efficiency/performance by reducing the probability of fabric backpressure due to Link-level flow control. 11501 12282 Implementations may adjust their buffering per VC based on implementation-specific policies derived from configuration and VC enablement . For example, if a four VC implementation has only two VCs enabled, the implementation may assign the non-enabled VC buffering to the enabled VCs to improve fabric efficiency/performance by reducing the probability of fabric backpressure due to Link-level flow control. 12283 11502 11503 Implementation Note VC and VC Buffering Considerations 12275 The amount of buffering beyond the architectural minimums per supported VC is implementation-specific. 11495 11500 An MFD may implement Virtual Channel resources similar to a subset of those in a Switch, for the purpose of managing the Quality of Service (QoS) for Upstream requests from the different Functions to the device's Upstream Egress Port. 12270 11489 11497 Figure 2-46 Virtual Channel Concept - Switch Internals (Upstream Flow) 12266 A Multi-Function Device may implement Virtual Channel resources similar to a subset of those in a Switch, for the purpose of managing the Quality of Service (QoS) for Upstream requests from the different Functions to the device's Upstream Egress Port. 11486 11494 Internal to the Switch, every Virtual Channel requires dedicated phys Figure 2-46 Virtual Channel Concept - Switch Internals (Upstream Flow) shows conceptually the VC resources within the Switch (shown in Figure 2-45 Virtual Channel Concept - An Illustration ) that are required to support traffic flow in the Upstream direction. 12284 The number of VCs supported, and the associated buffering per VC per Port, are not required to be the same for all Ports of a multi-Port component (a Switch or Root Complex). 12285 11504 12286 11505 12287 11506 12288 11507 12289 11508 11509 11510 Page 182 The number of VCs supported, and the associated buffering per VC per Port, are not required to be the same for all Ports of a multi-Port component (a Switch or Root Complex). 12290 2.5.1 Virtual Channel Identification (VC ID) 12291 12292 2.5.1 Virtual Channel Identification (VC ID) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11510 12292 11511 11512 12293 PCI Express Ports can support 1 to 8 Virtual Channels - each Port is independently configured/managed therefore allowing implementations to vary the number of VCs supported per Port based on usage model-specific requirements. These VCs are uniquely identified using the VC ID mechanism. 11513 12296 Note that while DLLPs contain VC ID information for Flow Control accounting, TLPs do not. The association of TLPs with VC ID for the purpose of Flow Control accounting is done at each Port of the Link using TC to VC mapping as discussed in Section 2.5.2 TC to VC Mapping . 11516 11521 11522 11523 12300 All Ports that support more than VC0 must provide at least one VC Capability structure according to the definition in Section 7.9.1 Virtual Channel Extended Capability . An MFD is permitted to implement the MFVC Capability structure, as defined in Section 7.9.2 Multi-Function Virtual Channel Extended Capability . Providing these extended structures is optional for Ports that support only the default TC0/VC0 configuration. Configuration software is responsible for configuring Ports on both sides of the Link for a matching number of VCs. This is accomplished by scanning the hierarchy and using VC or MFVC Capability registers associated with Ports (that support more than default VC0) to establish the number of VCs for the Link. Rules for assigning VC ID to VC hardware resources within a Port are as follows: 12301 VC ID assignment must be unique per Port - The same VC ID cannot be assigned to different VC hardware resources within the same Port. VC ID assignment must be the same (matching in the terms of numbers of VCs and their IDs) for the two Ports on both sides of a Link. If a Multi-Function Device implements an MFVC Capability structure, its VC hardware resources are distinct from the VC hardware resources associated with any VC Capability structures of its Functions. The VC ID uniqueness requirement (first bullet above) still applies individually for the MFVC and any VC Capability structures. In addition, the VC ID cross-Link matching requirement (second bullet above) applies for the MFVC Capability structure, but not the VC Capability structures of the Functions. VC ID 0 is assigned and fixed to the default VC. 12302 12303 12304 12305 11524 12306 11525 12307 11526 12308 11527 VC ID assignment must be unique per Port - The same VC ID cannot be assigned to different VC hardware resources within the same Port. VC ID assignment must be the same (matching in the terms of numbers of VCs and their IDs) for the two Ports on both sides of a Link. If an MFD implements an MFVC Capability structure, its VC hardware resources are distinct from the VC hardware resources associated with any VC Capability structures of its Functions. The VC ID uniqueness requirement (first bullet above) still applies individually for the MFVC and any VC Capability structures. In addition, the VC ID cross-Link matching requirement (second bullet above) applies for the MFVC Capability structure, but not the VC Capability structures of the Functions. VC ID 0 is assigned and fixed to the default VC. 12309 11528 2.5.2 TC to VC Mapping 11529 12310 2.5.2 TC to VC Mapping 12311 11530 11531 Note that while DLLPs contain VC ID information for Flow Control accounting, TLPs do not. The association of TLPs with VC ID for the purpose of Flow Control accounting is done at each Port of the Link using TC to VC mapping as discussed in Section 2.5.2 TC to VC Mapping . 12299 All Ports that support more than VC0 must provide at least one VC Capability structure according to the definition in Section 7.9.1 Virtual Channel Extended Capability . A Multi-Function Device is permitted to implement the MFVC Capability structure, as defined in Section 7.9.2 Multi-Function Virtual Channel Extended Capability . Providing these extended structures is optional for Ports that support only the default TC0/VC0 configuration. Configuration software is responsible for configuring Ports on both sides of the Link for a matching number of VCs. This is accomplished by scanning the hierarchy and using VC or MFVC Capability registers associated with Ports (that support more than default VC0) to establish the number of VCs for the Link. Rules for assigning VC ID to VC hardware resources within a Port are as follows: 11519 11520 12297 12298 11517 11518 PCI Express Ports can support 1 to 8 Virtual Channels - each Port is independently configured/managed therefore allowing implementations to vary the number of VCs supported per Port based on usage model-specific requirements. These VCs are uniquely identified using the VC ID mechanism. 12295 11514 11515 12294 12312 Every Traffic Class that is supported must be mapped to one of the Virtual Channels. The mapping of TC0 to VC0 is fixed. Page 183 12313 Every Traffic Class that is supported must be mapped to one of the Virtual Channels. The mapping of TC0 to VC0 is fixed. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11531 Every Traffic Class that is supported must be mapped to one of the Virtual Channels. The mapping of TC0 to VC0 is fixed. 11532 12315 The mapping of TCs other than TC0 is system software specific. However, the mapping algorithm must obey the following rules: 11535 11536 11537 11538 12316 12318 12319 12320 One or multiple TCs can be mapped to a VC. One TC must not be mapped to multiple VCs in any Port or Endpoint Function. TC/VC mapping must be identical for Ports on both sides of a Link. 12321 11540 12322 Table 2-40 TC to VC Mapping Example provides an example of TC to VC mapping. 12323 11542 12324 11543 12325 11544 Table 2-41 TC to VC Mapping Example provides an example of TC to VC mapping. 12326 11545 Table 2-40 TC to VC Mapping Example 11546 12327 Table 2-41 TC to VC Mapping Example 12328 11547 Supported VC Configurations 11548 12329 Supported VC Configurations 12330 11549 TC/VC Mapping Options 12331 11550 12332 11551 12333 11552 TC/VC Mapping Options 12334 11553 12335 VC0 11554 VC0 12336 11555 TC(0-7)/VC0 11588 12337 TC(0-7)/VC0 12370 11589 TC[n:m]/VC[n:m] 11590 12371 TC[n:m]/VC[n:m] 12372 11591 TCn/VCn, TCn+1/ VCn+1, ..., TCm/VCm 12373 11592 12374 11593 12375 11594 12376 11595 12377 11596 12378 11597 11598 The mapping of TCs other than TC0 is system software specific. However, the mapping algorithm must obey the following rules: 12317 One or multiple TCs can be mapped to a VC. One TC must not be mapped to multiple VCs in any Port or Endpoint Function. TC/VC mapping must be identical for Ports on both sides of a Link. 11539 11541 Every Traffic Class that is supported must be mapped to one of the Virtual Channels. The mapping of TC0 to VC0 is fixed. 12314 11533 11534 12313 TCn/VCn, TCn+1/ VCn+1, ..., TCm/VCm 12379 Figure 2-44 An Example of TC/VC Configurations provides a graphical illustration of TC to VC mapping in several different Link configurations. For additional considerations on TC/VC, refer to Section 6.3 Virtual Channel Support . 12380 11599 12381 11600 12382 11601 12383 11602 11603 12384 Figure 2-44 An Example of TC/VC Configurations 12385 11604 12386 11605 12387 Page 184 Figure 2-47 An Example of TC/VC Configurations provides a graphical illustration of TC to VC mapping in several different Link configurations. For additional considerations on TC/VC, refer to Section 6.3 Virtual Channel Support . Figure 2-47 An Example of TC/VC Configurations /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11605 12387 11606 12388 11607 12389 11608 12390 11609 2.5.3 VC and TC Rules 11610 12391 11611 12393 11612 Here is a summary of key rules associated with the TC/VC 12394 mechanism: 11615 11616 11617 11618 11619 11620 11621 11622 11623 11624 11625 12395 All devices must support the general purpose I/O Traffic Class, i.e., TC0 and must implement the default VC0. Each Virtual Channel (VC) has independent Flow Control. There are no ordering relationships required between different TCs. There are no ordering relationships required between different VCs. A Switch's peer-to-peer capability applies to all Virtual Channels supported by the Switch. A Multi-Function Device's peer-to-peer capability between different Functions applies to all Virtual Channels supported by the Multi-Function Device. Transactions with a TC that is not mapped to any enabled VC in an Ingress Port are treated as Malformed TLPs by the receiving device. For Switches, transactions with a TC that is not mapped to any of the enabled VCs in the target Egress Port are treated as Malformed TLPs. For a Root Port, transactions with a TC that is not mapped to any of the enabled VCs in the target RCRB are treated as Malformed TLPs. For Multi-Function Devices with an MFVC Capability structure, any transaction with a TC that is not mapped to an enabled VC in the MFVC Capability structure is treated as a Malformed TLP. Switches must support independent TC/VC mapping configuration for each Port. A Root Complex must support independent TC/VC mapping configuration for each RCRB, the associated Root Ports, and any RCiEPs. 11626 12396 12397 12398 12399 12400 12401 12402 12403 12404 12405 12406 12407 12410 12411 11630 12412 11631 12413 11632 12414 11633 12416 2.6 Ordering and Receive Buffer Flow Control 12417 11636 Page For more details on the VC and TC mechanisms, including configuration, mapping, and arbitration, refer to Section 6.3 Virtual Channel Support . 12415 2.6 Ordering and Receive Buffer Flow Control 11635 11637 Transactions with a TC that is not mapped to any enabled VC in an Ingress Port are treated as Malformed TLPs by the receiving device. For Switches, transactions with a TC that is not mapped to any of the enabled VCs in the target Egress Port are treated as Malformed TLPs. For a Root Port, transactions with a TC that is not mapped to any of the enabled VCs in the target RCRB are treated as Malformed TLPs. For MFDs with an MFVC Capability structure, any transaction with a TC that is not mapped to an enabled VC in the MFVC Capability structure is treated as a Malformed TLP. Switches must support independent TC/VC mapping configuration for each Port. A Root Complex must support independent TC/VC mapping configuration for each RCRB, the associated Root Ports, and any RCiEPs. 12409 For more details on the VC and TC mechanisms, including configuration, mapping, and arbitration, refer to Section 6.3 Virtual Channel Support . 11629 11634 All devices must support the general purpose I/O Traffic Class, i.e., TC0 and must implement the default VC0. Each Virtual Channel (VC) has independent Flow Control. There are no ordering relationships required between different TCs. There are no ordering relationships required between different VCs. A Switch's peer-to-peer capability applies to all Virtual Channels supported by the Switch. An MFD's peer-to-peer capability between different Functions applies to all Virtual Channels supported by the MFD. 12408 11627 11628 Here is a summary of key rules associated with the TC/VC mechanism: 11613 11614 2.5.3 VC and TC Rules 12392 12418 Flow Control (FC) is used to prevent overflow of Receiver buffers and to enable compliance with the ordering rules defined in . 185 Note that the Flow Control mechanism is used by the Requester to track the queue/buffer space available in the agent across the Link as shown in Figure 2-45 Relationship Between Requester and Ultimate Completer . That is, Flow Control is point-to-point (across a Link) and not end-to-end. Flow Control does not imply that a Request has reached its ultimate Completer. 12419 Flow Control (FC) is used to prevent overflow of Receiver buffers and to enable compliance with the ordering rules defined in Section 2.4 Transaction Ordering . Note that the Flow Control mechanism is used by the Requester to track the queue/buffer space available in the agent across the Link as shown in Figure 2-48 Relationship Between Requester and Ultimate Completer . That is, Flow Control is point-topoint (across a Link) and not end-to-end. Flow Control does not imply that a Request has reached its ultimate Completer. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11637 Flow Control (FC) is used to prevent overflow of Receiver buffers and to enable compliance with the ordering rules defined in . Note that the Flow Control mechanism is used by the Requester to track the queue/buffer space available in the agent across the Link as shown in Figure 2-45 Relationship Between Requester and Ultimate Completer . That is, Flow Control is point-to-point (across a Link) and not end-to-end. Flow Control does not imply that a Request has reached its ultimate Completer. 12419 11638 12420 11639 12421 11640 12422 11641 12423 11642 Figure 2-45 Relationship Between Requester and Ultimate 12424 Completer 12425 11644 12426 11645 12427 Flow Control is orthogonal to the data integrity mechanisms used to implement reliable information exchange between Transmitter and Receiver. Flow Control can treat the flow of TLP information from Transmitter to Receiver as perfect, since the data integrity mechanisms ensure that corrupted and lost TLPs are corrected through retransmission (see Section 3.6 Data Integrity ). 11647 Each Virtual Channel maintains an independent Flow Control credit pool. The FC information is conveyed between two sides of the Link using DLLPs. The VC ID field of the DLLP is used to carry the VC ID that is required for proper Flow Control credit accounting. 12433 Flow Control mechanisms used internally within a Multi-Function Device are outside the scope of this specification. 11653 12434 Flow Control mechanisms used internally within an MFD are outside the scope of this specification. 12435 11654 12436 Flow Control is handled by the Transaction Layer in cooperation with the Data Link Layer. The Transaction Layer performs Flow Control accounting functions for Received TLPs and “gates” TLP Transmissions based on available credits for transmission even if those TLPs are eventually nullified.. 11656 12437 Flow Control is handled by the Transaction Layer in cooperation with the Data Link Layer. The Transaction Layer performs Flow Control accounting functions for Received TLPs and “gates” TLP Transmissions based on available credits for transmission even if those TLPs are eventually nullified.. 12438 11657 11658 12431 12432 11651 11655 Flow Control is orthogonal to the data integrity mechanisms used to implement reliable information exchange between Transmitter and Receiver. Flow Control can treat the flow of TLP information from Transmitter to Receiver as perfect, since the data integrity mechanisms ensure that corrupted and lost TLPs are corrected through retransmission (see Section 3.6 Data Integrity Mechansisms ). 12430 Each Virtual Channel maintains an independent Flow Control credit pool. The FC information is conveyed between two sides of the Link using DLLPs. The VC ID field of the DLLP is used to carry the VC ID that is required for proper Flow Control credit accounting. 11650 11652 12428 12429 11648 11649 Figure 2-48 Relationship Between Requester and Ultimate Completer 11643 11646 Flow Control (FC) is used to prevent overflow of Receiver buffers and to enable compliance with the ordering rules defined in Section 2.4 Transaction Ordering . Note that the Flow Control mechanism is used by the Requester to track the queue/buffer space available in the agent across the Link as shown in Figure 2-48 Relationship Between Requester and Ultimate Completer . That is, Flow Control is point-topoint (across a Link) and not end-to-end. Flow Control does not imply that a Request has reached its ultimate Completer. 12439 Note: Flow Control is a function of the Transaction Layer and, therefore, the following types of information transmitted on the interface are not associated with Flow Control Credits: LCRC, Packet Framing Symbols, other Special Symbols, and Data Link Layer to Data Link Layer inter-communication packets. An implication of this fact is that these types of information must be processed by the Receiver at the rate they arrive (except as explicitly noted in this specification). 12440 11659 12441 11660 12442 Page 186 Note: Flow Control is a function of the Transaction Layer and, therefore, the following types of information transmitted on the interface are not associated with Flow Control Credits: LCRC, Packet Framing Symbols, other Special Symbols, and Data Link Layer to Data Link Layer inter-communication packets. An implication of this fact is that these types of information must be processed by the Receiver at the rate they arrive (except as explicitly noted in this specification). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11660 11661 12442 Also, any TLPs transferred from the Transaction Layer to the Data Link and Physical Layers must have first passed the Flow Control “gate”. Thus, both Transmit and Receive Flow Control mechanisms are unaware if the Data Link Layer transmits a TLP repeatedly due to errors on the Link. 12443 11662 12444 11663 12445 11664 12446 11665 2.6.1 Flow Control Rules 11666 11671 11672 11673 11674 11675 11678 11679 11680 11681 11684 11685 12452 12453 12454 12455 12456 12457 Flow Control information is transferred using Flow Control Packets (FCPs), which are a type of DLLP (see Section 3.5 Data Link Layer Packets (DLLPs) ). The unit of Flow Control credit is 4 DW for data. For headers: The unit of Flow Control credit for Receivers that do not support TLP Prefixes is the sum of one maximum-size Header and TLP Digest. The unit of Flow Control credits for Receivers that support End-End TLP Prefixes is the sum of one maximum-size Header, TLP Digest, and the maximum number of End-End TLP Prefixes permitted in a TLP. The management of Flow Control for Receivers that support Local TLP Prefixes is dependent on the Local TLP Prefix type. 12459 12460 12461 12462 12463 Each Virtual Channel has independent Flow Control. Flow Control distinguishes three types of TLPs (note relationship to ordering rules - see Section 2.4 Transaction Ordering ): Posted Requests (P) - Messages and Memory Writes Non-Posted Requests (NP) - All Reads, I/O Writes, Configuration Writes, and AtomicOps Completions (Cpl) - Associated with corresponding NP Requests 12464 In addition, Flow Control distinguishes the following types of TLP information within each of the three types: Headers (H) Data (D) 11686 11687 In this and other sections of this specification, rules are described using conceptual “registers” that a device could use in order to implement a compliant implementation. This description does not imply or require a particular implementation and is used only to clarify the requirements. 12458 Each Virtual Channel has independent Flow Control Flow Control distinguishes three types of TLPs (note relationship to ordering rules - see ): Posted Requests (P) - Messages and Memory Writes Non-Posted Requests (NP) - All Reads, I/O Writes, Configuration Writes, and AtomicOps Completions (Cpl) - Associated with corresponding NP Requests 11682 11683 12450 12451 Flow Control information is transferred using Flow Control Packets (FCPs), which are a type of DLLP (see Section 3.5 Data Link Layer Packets (DLLPs) ) The unit of Flow Control credit is 4 DW for data For headers: The unit of Flow Control credit for Receivers that do not support TLP Prefixes is the sum of one maximum-size Header and TLP Digest. The unit of Flow Control credits for Receivers that support End-End TLP Prefixes is the sum of one maximum-size Header, TLP Digest, and the maximum number of End-End TLP Prefixes permitted in a TLP. The management of Flow Control for Receivers that support Local TLP Prefixes is dependent on the Local TLP Prefix type. 11676 11677 2.6.1 Flow Control Rules 12449 In this and other sections of this specification, rules are described using conceptual “registers” that a device could use in order to implement a compliant implementation. This description does not imply or require a particular implementation and is used only to clarify the requirements. 11669 11670 12447 12448 11667 11668 Also, any TLPs transferred from the Transaction Layer to the Data Link and Physical Layers must have first passed the Flow Control “gate”. Thus, both Transmit and Receive Flow Control mechanisms are unaware if the Data Link Layer transmits a TLP repeatedly due to errors on the Link. 12465 12466 12467 In addition, Flow Control distinguishes the following types of TLP information within each of the three types: Headers (H) Data (D) 12468 Thus, there are six types of information tracked by Flow Control for each Virtual Channel, as shown in Table 2-41 Flow Control Credit Types . 11688 Page 187 12469 12470 Thus, there are six types of information tracked by Flow Control for each Virtual Channel, as shown in Table 2-42 Flow Control Credit Types . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11688 12470 11689 12471 11690 12472 11691 Table 2-41 Flow Control Credit Types 11692 12473 11693 Credit Type 11694 12475 Applies to This Type of TLP Information 12477 11696 12478 11697 12479 11698 Applies to This Type of TLP Information 12480 11699 12481 PH 11700 PH 12482 11701 Posted Request headers 12483 11726 12508 11727 12509 11728 Posted Request headers 12510 11729 CplD 11730 12511 CplD 12512 11731 Completion Data payload 12513 11732 12514 11733 12515 11734 12516 11735 Completion Data payload 12517 TLPs consume Flow Control credits as shown in Table 2-42 TLP Flow Control Credit Consumption . 12518 11737 12519 11738 12520 11739 TLPs consume Flow Control credits as shown in Table 2-43 TLP Flow Control Credit Consumption . 12521 11740 Table 2-42 TLP Flow Control Credit Consumption 11741 12522 Table 2-43 TLP Flow Control Credit Consumption 12523 11742 TLP 11743 11744 Credit Type 12476 11695 11736 Table 2-42 Flow Control Credit Types 12474 12524 TLP 12525 Credit Consumed [Footnote: Each header credit implies the ability to accept a TLP Digest along with the corresponding TLP.] 12526 11745 12527 11746 12528 11747 Credit Consumed [Footnote: Each header credit implies the ability to accept a TLP Digest along with the corresponding TLP.] 12529 11748 Memory, I/O, Configuration Read Request 11749 12530 Memory, I/O, Configuration Read Request 12531 11750 1 NPH unit 11810 1 CplH unit + 1 CplD unit 11811 12532 1 NPH unit 12592 1 CplH unit + 1 CplD unit 12593 11812 12594 11813 Note: size of data returned is never more than 4 12595 (aligned) DWs. 11814 12596 11815 12597 11816 12598 11817 12599 11818 12600 Page 188 Note: size of data returned is never more than 4 (aligned) DWs. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11818 11819 11820 11821 12600 Components must implement independent Flow Control for all Virtual Channels that are supported by that component. Flow Control is initialized autonomously by hardware only for the default Virtual Channel (VC0) VC0 is initialized when the Data Link Layer is in the DL_Init state following reset (see Section 3.2 Data Link Control and Management State Machine and Section 3.4 Flow Control Initialization Protocol ) 11822 11823 11824 12601 12602 12603 12604 When other Virtual Channels are enabled by software, each newly enabled VC will follow the Flow Control initialization protocol (see Section 3.4 Flow Control Initialization Protocol ) Software enables a Virtual Channel by setting the VC Enable bits for that Virtual Channel in both components on a Link (see Section 7.9.1 Virtual Channel Extended Capability and Section 7.9.2 MultiFunction Virtual Channel Extended Capability ) 12605 12606 11825 12607 11826 12608 11827 11828 11831 11834 11835 11836 12612 12613 12615 12616 12617 12618 Software disables a Virtual Channel by clearing the VC Enable bits for that Virtual Channel in both components on a Link. Disabling a Virtual Channel for a component resets the Flow Control tracking mechanisms for that Virtual Channel in that component. InitFC1 and InitFC2 FCPs are used only for Flow Control initialization (see Section 3.4 Flow Control Initialization Protocol ). An InitFC1, InitFC2, or UpdateFC FCP that specifies a Virtual Channel that is disabled is discarded without effect. During FC initialization for any Virtual Channel, including the default VC initialized as a part of Link initialization, Receivers must initially advertise VC credit values equal to or greater than those shown in Table 2-44 Minimum Initial Flow Control Advertisements . If Scaled Flow Control is not supported or supported but not activated, use the values in the "Scale Factor 1" column. 12619 If Scaled Flow Control is supported and activated, use the values in the column for the scaling factor associated with that credit type (see Section 3.4.2 Scaled Flow Control ). 12620 11839 12621 11840 12622 11841 11842 Note: It is possible for multiple VCs to be following the Flow Control initialization protocol simultaneously - each follows the initialization protocol as an independent process. 12614 InitFC1 and InitFC2 FCPs are used only for Flow Control initialization (see Section 3.4 Flow Control Initialization Protocol ) An InitFC1, InitFC2, or UpdateFC FCP that specifies a Virtual Channel that is disabled is discarded without effect During FC initialization for any Virtual Channel, including the default VC initialized as a part of Link initialization, Receivers must initially advertise VC credit values equal to or greater than those shown in Table 2-43 Minimum Initial Flow Control Advertisements . If Scaled Flow Control is not supported or supported but not activated, use the values in the "Scale Factor 1" column. 11837 11838 12610 12611 Software disables a Virtual Channel by clearing the VC Enable bits for that Virtual Channel in both components on a Link Disabling a Virtual Channel for a component resets the Flow Control tracking mechanisms for that Virtual Channel in that component 11832 11833 When other Virtual Channels are enabled by software, each newly enabled VC will follow the Flow Control initialization protocol (see Section 3.4 Flow Control Initialization Protocol ). Software enables a Virtual Channel by setting the VC Enable bits for that Virtual Channel in both components on a Link (see Section 7.9.1 Virtual Channel Extended Capability and Section 7.9.2 MultiFunction Virtual Channel Extended Capability ). 12609 Note: It is possible for multiple VCs to be following the Flow Control initialization protocol simultaneously - each follows the initialization protocol as an independent process 11829 11830 Components must implement independent Flow Control for all Virtual Channels that are supported by that component. Flow Control is initialized autonomously by hardware only for the default Virtual Channel (VC0). VC0 is initialized when the Data Link Layer is in the DL_Init state following reset (see Section 3.2 Data Link Control and Management State Machine and Section 3.4 Flow Control Initialization Protocol ). If Scaled Flow Control is supported and activated, use the values in the column for the scaling factor associated with that credit type (see Section 3.4.2 Scaled Flow Control ). 12623 Table 2-43 Minimum Initial Flow Control Advertisements [Footnote: PCI Express to PCI/PCI-X Bridge requirements are addressed in the PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0.] 11843 11844 Page 189 12624 Table 2-44 Minimum Initial Flow Control Advertisements [Footnote: PCI Express to PCI/PCI-X Bridge requirements are addressed in [PCIe-to-PCI-PCI-X-Bridge-1.0].] 12625 Credit Type 12626 Credit Type /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11844 Credit Type 11845 11846 12626 Minimum Advertisement 12628 11847 12629 11848 12630 11849 11850 11851 12632 12635 Scale Factor 16 12637 12638 11856 12639 11857 1 unit - credit value of 01h. 12643 4 Units - credit value of 01h. 12645 16 Units - credit value of 01h. 12647 12648 11866 12649 11867 4 Units - credit value of 01h. 16 Units - credit value of 01h. 12650 PD 11869 12651 PD 12652 11870 11871 1 unit - credit value of 01h. 12646 11865 11868 PH 12644 11863 11864 12641 12642 11861 11862 Scale Factor 16 12640 PH 11859 11860 Scale Factor 4 12636 11855 11858 No Scaling or Scale Factor 1 12634 Scale Factor 4 11853 11854 Minimum Advertisement 12631 No Scaling or Scale Factor 1 12633 11852 Credit Type 12627 12653 Largest possible setting of the Max_Payload_Size for the component divided by FC Unit Size. For a Multi-Function Device, this includes all Functions in the device. Largest possible setting of the Max_Payload_Size for the component divided by FC Unit Size. For an MFD, this includes all Functions in the device. 11872 11873 11874 12654 Example: If the largest Max_Payload_Size value supported is 1024 bytes, the smallest permitted initial credit value would be 040h. 12655 11875 12656 11876 12657 11877 11878 12658 Ceiling(Largest Max_Payload_Size / (FC Unit Size * 4)) + 1. For a Multi-Function Device, this includes all Functions in the device. Example: If the largest Max_Payload_Size value supported is 1024 bytes, the smallest permitted initial credit value would be 040h. Ceiling(Largest Max_Payload_Size / (FC Unit Size * 4)) + 1. For an MFD, this includes all Functions in the device. 11879 11880 11881 12659 Example: If the largest Max_Payload_Size value supported is 1024 bytes, the smallest permitted initial credit value would be 011h. 12660 11882 12661 11883 12662 11884 11885 Page 12663 Ceiling(Largest Max_Payload_Size / (FC Unit Size * 16)) + 1. For a Multi-Function Device, this includes all Functions in the device. 190 Example: If the largest Max_Payload_Size value supported is 1024 bytes, the smallest permitted initial credit value would be 011h. Ceiling(Largest Max_Payload_Size / (FC Unit Size * 16)) + 1. For an MFD, this includes all Functions in the device. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11885 12663 Ceiling(Largest Max_Payload_Size / (FC Unit Size * 16)) + 1. For a Multi-Function Device, this includes all Functions in the device. Ceiling(Largest Max_Payload_Size / (FC Unit Size * 16)) + 1. For an MFD, this includes all Functions in the device. 11886 11887 11888 12664 Example: If the largest Max_Payload_Size value supported is 1024 bytes, the smallest permitted initial credit value would be 005h. 12665 11889 12666 11890 12667 11891 12668 11892 Example: If the largest Max_Payload_Size value supported is 1024 bytes, the smallest permitted initial credit value would be 005h. 12669 11893 NPH 11894 12670 NPH 12671 11895 1 unit - credit value of 01h. 11896 12672 1 unit - credit value of 01h. 12673 11897 4 Units - credit value of 01h. 11898 12674 4 Units - credit value of 01h. 12675 11899 16 Units - credit value of 01h. 12676 11900 12677 11901 12678 11902 16 Units - credit value of 01h. 12679 11903 NPD 11904 12680 NPD 12681 11905 11906 Receiver that supports AtomicOp routing capability or any AtomicOp Completer capability: 2 units - credit value of 002h 11907 12682 Receiver that supports AtomicOp routing capability or any AtomicOp Completer capability: 2 units - credit value of 002h 12683 11908 11909 All other Receivers: 1 unit - credit value of 12684 001h. All other Receivers: 1 unit - credit value of 001h. 11910 12685 11911 12686 11912 11913 Receiver that supports AtomicOp routing capability or any AtomicOp Completer capability: 8 units - credit value of 002h 11914 12687 Receiver that supports AtomicOp routing capability or any AtomicOp Completer capability: 8 units - credit value of 002h 12688 11915 11916 All other Receivers: 4 units - credit value of 12689 001h. All other Receivers: 4 units - credit value of 001h. 11917 12690 11918 12691 11919 11920 Receiver that supports AtomicOp routing capability or any AtomicOp Completer capability: 32 units - credit value of 002h 11921 12692 Receiver that supports AtomicOp routing capability or any AtomicOp Completer capability: 32 units - credit value of 002h 12693 11922 11923 All other Receivers: 16 units - credit value of 12694 001h. 11924 12695 11925 12696 Page 191 All other Receivers: 16 units - credit value of 001h. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11925 12696 11926 12697 11927 12698 11928 CplH 11929 12699 CplH 12700 11930 11931 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: 1 FC unit - credit value of 01h 11932 12701 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: 1 FC unit - credit value of 01h 12702 11933 11934 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. [Footnote: This value is interpreted as infinite by the Transmitter, which will, therefore, never throttle.] 12703 11935 12704 11936 12705 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. [Footnote: This value is interpreted as infinite by the Transmitter, which will, therefore, never throttle.] 11937 11938 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: 4 FC units - credit value of 01h 11939 12706 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: 4 FC units - credit value of 01h 12707 11940 11941 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. [Footnote: This value is interpreted as infinite by the Transmitter, which will, therefore, never throttle.] 12708 11942 12709 11943 12710 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. [Footnote: This value is interpreted as infinite by the Transmitter, which will, therefore, never throttle.] 11944 11945 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: 16 FC units - credit value of 01h 11946 12711 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: 16 FC units - credit value of 01h 12712 11947 11948 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. [Footnote: This value is interpreted as infinite by the Transmitter, which will, therefore, never throttle.] 12713 11949 12714 11950 12715 11951 12716 11952 12717 11953 CplD 11954 12718 CplD 12719 11955 11956 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. [Footnote: This value is interpreted as infinite by the Transmitter, which will, therefore, never throttle.] 12720 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: Largest possible setting of the Max_Payload_Size for the component divided by FC Unit Size., Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: Largest possible setting of the Max_Payload_Size for the component divided by FC Unit Size. 11957 11958 11959 12721 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. Page 192 12722 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 11959 Root Complex (not supporting peer-to-peer traffic /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html between all Root Ports) and Endpoint: infinite FC units - initial credit 12722 value of all 0s. 11960 12723 11961 12724 11962 11963 12725 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: Ceiling(Largest Max_Payload_Size / (FC Unit Size * 4)) + 1. , Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: Ceiling(Largest Max_Payload_Size / (FC Unit Size * 4)) + 1. 11964 11965 11966 12726 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. 12727 11967 12728 11968 12729 11969 11970 12730 Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: Ceiling(Largest Max_Payload_Size / (FC Unit Size * 16)) + 1. , Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. Root Complex (supporting peer-to-peer traffic between all Root Ports) and Switch: Ceiling(Largest Max_Payload_Size / (FC Unit Size * 16)) + 1. 11971 11972 11973 12731 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. 12732 11974 12733 11975 12734 11976 12735 11977 12736 11978 11979 11980 11981 11982 11983 Root Complex (not supporting peer-to-peer traffic between all Root Ports) and Endpoint: infinite FC units - initial credit value of all 0s. 12737 A Root Complex that supports no peer-to-peer traffic between Root Ports must advertise infinite Completion credits on every Root Port. A Root Complex that supports peer-to-peer traffic between some or all of its Root Ports may optionally advertise non-infinite Completion credits on those Root Ports. In this case, the Root Complex must ensure that deadlocks are avoided and forward progress is maintained for completions directed towards the Root Complex. Note that temporary stalls of completion traffic (due to a temporary lack of credit) are possible since Non-Posted requests forwarded by the RC may not have explicitly allocated completion buffer space. A Receiver that does not support Scaled Flow Control must never cumulatively issue more than 2047 outstanding unused credits to the Transmitter for data payload or 127 for header. A Receiver that supports Scaled Flow Control must never cumulatively issue more outstanding unused data or header to the Transmitter than the Max Credits values shown in Table 3-2 Scaled Flow Control Scaling Factors . Components may optionally check for violations of this rule. If a component implementing this check determines a violation of this rule, the violation is a Flow Control Protocol Error (FCPE). If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ) 12738 12739 12740 12741 12742 11984 12743 11985 12744 Page 193 A Root Complex that supports no peer-to-peer traffic between Root Ports must advertise infinite Completion credits on every Root Port. A Root Complex that supports peer-to-peer traffic between some or all of its Root Ports may optionally advertise non-infinite Completion credits on those Root Ports. In this case, the Root Complex must ensure that deadlocks are avoided and forward progress is maintained for completions directed towards the Root Complex. Note that temporary stalls of completion traffic (due to a temporary lack of credit) are possible since Non-Posted requests forwarded by the RC may not have explicitly allocated completion buffer space. A Receiver that does not support Scaled Flow Control must never cumulatively issue more than 2047 outstanding unused credits to the Transmitter for data payload or 127 for header. A Receiver that supports Scaled Flow Control must never cumulatively issue more outstanding unused data or header to the Transmitter than the Max Credits values shown in Table 3-2 Scaled Flow Control Scaling Factors . Components may optionally check for violations of this rule. If a component implementing this check determines a violation of this rule, the violation is a Flow Control Protocol Error (FCPE). If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 11985 11986 11987 11988 12744 If an Infinite Credit advertisement (value of 00h or 000h) has been made during initialization, no Flow Control updates are required following initialization. If UpdateFC DLLPs are sent, the credit value fields must be Clear and must be ignored by the Receiver. The Receiver may optionally check for non-zero update values (in violation of this rule). If a component implementing this check determines a violation of this rule, the violation is a Flow Control Protocol Error (FCPE) If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ) 11989 11992 11993 11998 12750 12751 12752 12754 If Scaled Flow Control is activated, the HdrScale and DataScale fields in the UpdateFCs must match the values advertised during initialization (see Section 3.4.2 Scaled Flow Control ). The Receiver may optionally check for violations of this rule. If a Receiver implementing this check determines a violation of this rule, the violation is a Flow Control Protocol Error (FCPE). If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 11999 12755 12756 12757 12759 12001 A received TLP using a VC that is not enabled is a Malformed 12760 TLP 12003 12004 VC0 is always enabled For VCs 1-7, a VC is considered enabled when the corresponding VC Enable bit in the VC Resource Control register has been Set, and once FC negotiation for that VC has exited the FC_INIT1 state and progressed to the FC_INIT2 state (see Section 3.4 Flow Control Initialization Protocol ) This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ) 12005 12006 If Scaled Flow Control is activated, the HdrScale and DataScale fields in the UpdateFCs must match the values advertised during initialization (see Section 3.4.2 Scaled Flow Control ). The Receiver may optionally check for violations of this rule. If a Receiver implementing this check determines a violation of this rule, the violation is a Flow Control Protocol Error (FCPE). If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 12758 12000 12002 If only the Data or header advertisement (but not both) for a given type (P, NP, or Cpl) has been made with infinite credits during initialization, the transmission of UpdateFC DLLPs is still required, but the credit field corresponding to the Data/header (advertised as infinite) must be set to zero and must be ignored by the Receiver. The Receiver may optionally check for non-zero update values (in violation of this rule). If a Receiver implementing this check determines a violation of this rule, the violation is a Flow Control Protocol Error (FCPE). If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 12753 11995 11997 12747 12749 If only the Data or header advertisement (but not both) for a given type (P, NP, or Cpl) has been made with infinite credits during initialization, the transmission of UpdateFC DLLPs is still required, but the credit field corresponding to the Data/header (advertised as infinite) must be set to zero and must be ignored by the Receiver. The Receiver may optionally check for non-zero update values (in violation of this rule). If a Receiver implementing this check determines a violation of this rule, the violation is a Flow Control Protocol Error (FCPE) If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ) 11994 11996 12746 If an Infinite Credit advertisement (value of 00h or 000h) has been made during initialization, no Flow Control updates are required following initialization. If UpdateFC DLLPs are sent, the credit value fields must be Clear and must be ignored by the Receiver. The Receiver may optionally check for non-zero update values (in violation of this rule). If a component implementing this check determines a violation of this rule, the violation is a Flow Control Protocol Error (FCPE) If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ) 12748 11990 11991 12745 A received TLP using a VC that is not enabled is a Malformed TLP. 12761 12762 12763 VC0 is always enabled. For VCs 1-7, a VC is considered enabled when the corresponding VC Enable bit in the VC Resource Control register has been Set, and once FC negotiation for that VC has exited the FC_INIT1 state and progressed to the FC_INIT2 state (see Section 3.4 Flow Control Initialization Protocol ). This is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 12764 TLP transmission using any VC 0-7 is not permitted until initialization for that VC has completed by exiting FC_INIT2 state 12765 12007 12766 12008 12767 Page 194 TLP transmission using any VC 0-7 is not permitted until initialization for that VC has completed by exiting FC_INIT2 state. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12008 12009 12767 For VCs 1-7, software must use the VC Negotiation Pending bit in the VC Resource Status register to ensure that a VC is not used until negotiation has completed by exiting the FC_INIT2 state in both components on a Link. 12010 12770 The [Field Size] parameter used in the following sections is described in Table 2-44 [Field Size] Values (see Section 3.4.2 Scaled Flow Control ). 12771 12013 12772 12014 12773 12015 Table 2-44 [Field Size] Values 12017 12775 Scaled Flow Control Supported 12777 12778 12019 HdrScale or DataScale 12021 12780 HdrScale or DataScale 12781 12022 [Field Size] for PH, NPH, CplH 12782 12783 12023 [Field Size] for PH, NPH, CplH 12784 12024 [Field Size] for PD, NPD, CplD 12785 12786 12025 12787 12026 12788 12027 [Field Size] for PD, NPD, CplD 12789 12028 No 12029 12790 No 12791 12030 x 12031 12792 x 12793 12032 8 12033 12794 8 12795 12034 12 12796 12076 12838 12077 12839 12078 12840 12079 12841 12080 12 12842 12081 2.6.1.1 FC Information Tracked by Transmitter 12082 12843 2.6.1.1 FC Information Tracked by Transmitter 12844 For each type of information tracked, there are two quantities tracked for Flow Control TLP Transmission gating: 12084 12087 Scaled Flow Control Supported 12779 12020 12086 Table 2-45 [Field Size] Values 12776 12018 12085 The [Field Size] parameter used in the following sections is described in Table 2-45 [Field Size] Values (see Section 3.4.2 Scaled Flow Control ). 12774 12016 12083 For VCs 1-7, software must use the VC Negotiation Pending bit in the VC Resource Status register to ensure that a VC is not used until negotiation has completed by exiting the FC_INIT2 state in both components on a Link. 12769 12011 12012 12768 12845 For each type of information tracked, there are two quantities tracked for Flow Control TLP Transmission gating: 12846 CREDITS_CONSUMED Count of the total number of FC units consumed by TLP Transmissions made since Flow Control initialization, modulo 2 [Field Size] (where [Field Size] is defined in Table 2-44 [Field Size] Values ). Set to all 0's at interface initialization Page 195 12847 12848 12849 CREDITS_CONSUMED Count of the total number of FC units consumed by TLP Transmissions made since Flow Control initialization, modulo 2[Field Size] (where [Field Size] is defined in Table 2-45 [Field Size] Values ). Set to all 0's at interface initialization /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12087 12088 Set to all 0's at interface initialization Updated for each TLP the Transaction Layer allows to pass the Flow Control gate for Transmission 12849 12850 Set to all 0's at interface initialization Updated for each TLP the Transaction Layer allows to pass the Flow Control gate for Transmission as shown: 12089 12090 Updated as shown: 12091 12851 12092 CREDITS_CONSUMED:= (CREDITS_CONSUMED + Increment) 12852 mod 2 [Field Size] 12093 CREDITS_CONSUMED:= (CREDITS_CONSUMED + Increment) mod 2[Field Size] 12853 12854 Equation 2-1 CREDITS_CONSUMED 12855 12856 12857 12858 12094 12095 12859 Where Increment is the size in FC credits of the corresponding part of the TLP passed through the gate, and [Field Size] is defined in Table 2-44 [Field Size] Values ) 12096 12860 12097 12098 12099 12100 12101 12102 12103 12861 CREDIT_LIMIT The most recent number of FC units legally advertised by the Receiver. This quantity represents the total number of FC credits made available by the Receiver since Flow Control initialization, modulo 2 [Field Size] (where [Field Size] is defined in Table 2-44 [Field Size] Values ). Undefined at interface initialization Set to the value indicated during Flow Control initialization For each FC update received, if CREDIT_LIMIT is not equal to the update value, set CREDIT_LIMIT to the update value 12862 12863 12864 12865 12866 12867 12104 12868 12105 12869 12106 12107 12108 12109 Page (Where Increment is the size in FC credits of the corresponding part of the TLP passed through the gate, and [Field Size] is defined in Table 2-45 [Field Size] Values ) CREDIT_LIMIT The most recent number of FC units legally advertised by the Receiver. This quantity represents the total number of FC credits made available by the Receiver since Flow Control initialization, modulo 2[Field Size] (where [Field Size] is defined in Table 2-45 [Field Size] Values ). Undefined at interface initialization Set to the value indicated during Flow Control initialization For each FC update received, if CREDIT_LIMIT is not equal to the update value, set CREDIT_LIMIT to the update value 12870 If a Transmitter detects that a TLP it is preparing to transmit is malformed, it is strongly recommended that the Transmitter discard the TLP and handle the condition as an Uncorrectable Internal Error. If a Transmitter detects that a TLP it is preparing to transmit appears to be properly formed but with bad ECRC, it is strongly recommended that the Transmitter transmit the TLP and update its internal Flow Control credits accordingly. The Transmitter gating function must determine if sufficient credits have been advertised to permit the transmission of a given TLP. If the Transmitter does not have enough credits to transmit the TLP, it must block the transmission of the TLP, possibly stalling other TLPs that are using the same Virtual Channel. The Transmitter must follow the ordering and deadlock avoidance rules specified in , which require that certain types of TLPs must bypass other specific types of 196 TLPs when the latter are blocked. Note that TLPs using different Virtual Channels have no ordering relationship, and must not block each other. 12871 12872 12873 If a Transmitter detects that a TLP it is preparing to transmit is malformed, it is strongly recommended that the Transmitter discard the TLP and handle the condition as an Uncorrectable Internal Error. If a Transmitter detects that a TLP it is preparing to transmit appears to be properly formed but with bad ECRC, it is strongly recommended that the Transmitter transmit the TLP and update its internal Flow Control credits accordingly. The Transmitter gating function must determine if sufficient credits have been advertised to permit the transmission of a given TLP. If the Transmitter does not have enough credits to transmit the TLP, it must block the transmission of the TLP, possibly stalling other TLPs that are using the same Virtual Channel. The Transmitter must follow the ordering and deadlock avoidance rules specified in Section 2.4 Transaction Ordering , which require that certain types of TLPs must bypass other specific types of TLPs when the latter are blocked. Note that TLPs using different Virtual Channels have no ordering relationship, and must not block each other. 12109 12873 The Transmitter gating function must determine if sufficient credits have been advertised to permit the transmission of a /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. given TLP. If the Transmitter does not have enough credits to transmit the TLP, it must block the transmission of the TLP, possibly stalling /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html other TLPs that are using the same Virtual Channel. The Transmitter must follow the ordering and deadlock avoidance rules specified in , which require that certain types of TLPs must bypass other specific types of TLPs when the latter are blocked. Note that TLPs using different Virtual Channels have no ordering relationship, and must not block each other. 12110 The Transmitter gating function test is performed as 12874 follows: 12111 For each required type of credit, the number of credits required is calculated as: 12112 12113 12875 The Transmitter gating function must determine if sufficient credits have been advertised to permit the transmission of a given TLP. If the Transmitter does not have enough credits to transmit the TLP, it must block the transmission of the TLP, possibly stalling other TLPs that are using the same Virtual Channel. The Transmitter must follow the ordering and deadlock avoidance rules specified in Section 2.4 Transaction Ordering , which require that certain types of TLPs must bypass other specific types of TLPs when the latter are blocked. Note that TLPs using different Virtual Channels have no ordering relationship, and must not block each other. The Transmitter gating function test is performed as follows: For each required type of credit, the number of credits required is calculated as: 12876 CUMULATIVE_CREDITS_REQUIRED = (CREDITS_CONSUMED + credit units required for pending TLP) mod 2 [Field Size] 12114 12877 CUMULATIVE_CREDITS_REQUIRED = (CREDITS_CONSUMED + credit units required for pending TLP) mod 2[Field Size] 12878 12879 Equation 2-2 CUMULATIVE_CREDITS_REQUIRED 12880 12115 12116 12881 Unless CREDIT_LIMIT was specified as “infinite” during Flow Control initialization, the Transmitter is permitted to Transmit a TLP if, for each type of information in the TLP, the following equation is satisfied (using unsigned arithmetic): 12117 12118 12884 12886 12887 12123 12888 12889 Note that some types of Transactions require more than one type of credit. (For example, Memory Write requests require PH and PD credits.) 12125 12127 12128 12129 Equation 2-3 Transmitter Gate If CREDIT_LIMIT was specified as “infinite” during Flow Control initialization, then the gating function is unconditionally satisfied for that type of credit. 12122 12126 (CREDIT_LIMIT - CUMULATIVE_CREDITS_REQUIRED) mod 2[Field Size] ≤ 2[Field Size]/2 12885 12120 12124 Unless CREDIT_LIMIT was specified as “infinite” during Flow Control initialization, the Transmitter is permitted to Transmit a TLP if, for each type of information in the TLP, the following equation is satisfied (using unsigned arithmetic): 12883 (CREDIT_LIMIT - CUMULATIVE_CREDITS_REQUIRED) mod 2 [Field Size] ≤ 2 [Field Size] / 2 12119 12121 12882 12890 If CREDIT_LIMIT was specified as “infinite” during Flow Control initialization, then the gating function is unconditionally satisfied for that type of credit. Note that some types of Transactions require more than one type of credit. (For example, Memory Write requests require PH and PD credits.) 12891 When accounting for credit use and return, information from different TLPs is never mixed within one credit. When some TLP is blocked from Transmission by a lack of FC Credit, Transmitters must follow the ordering rules specified in when determining what types of TLPs must be permitted to bypass the stalled TLP. The return of FC credits for a Transaction must not be interpreted to mean that the Transaction has completed or achieved system visibility. Flow Control credit return is used for receive buffer management only, and agents must not make any judgment about the Completion status or system visibility of a Transaction based on the return or lack of return of Flow Control information. 12130 Page 197 12892 12893 12894 12895 12896 When accounting for credit use and return, information from different TLPs is never mixed within one credit. When some TLP is blocked from Transmission by a lack of FC Credit, Transmitters must follow the ordering rules specified in Section 2.4 Transaction Ordering when determining what types of TLPs must be permitted to bypass the stalled TLP. The return of FC credits for a Transaction must not be interpreted to mean that the Transaction has completed or achieved system visibility. Flow Control credit return is used for receive buffer management only, and agents must not make any judgment about the Completion status or system visibility of a Transaction based on the return or lack of return of Flow Control information. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12130 12131 12896 When a Transmitter sends a nullified TLP, the Transmitter does not modify CREDITS_CONSUMED for that TLP (see Section 3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter) ). 12897 12132 12898 12133 12899 12134 12900 12135 12901 12136 2.6.1.2 FC Information Tracked by Receiver 12137 12138 12141 12142 12143 12144 For each type of information tracked, the following quantities are tracked for Flow Control TLP Receiver accounting: 2.6.1.2 FC Information Tracked by Receiver 12904 For each type of information tracked, the following quantities are tracked for Flow Control TLP Receiver accounting: 12905 CREDITS_ALLOCATED Count of the total number of credits granted to the Transmitter since initialization, modulo 2 [Field Size] (where [Field Size] is defined in Table 2-44 [Field Size] Values ) Initially set according to the buffer size and allocation policies of the Receiver This value is included in the InitFC and UpdateFC DLLPs (see Section 3.5 Data Link Layer Packets (DLLPs) ) Incremented as the Receiver Transaction Layer makes additional receive buffer space available by processing Received TLPs 12145 12906 12907 12908 12909 12910 CREDITS_ALLOCATED Count of the total number of credits granted to the Transmitter since initialization, modulo 2[Field Size] (where [Field Size] is defined in Table 2-45 [Field Size] Values ) Initially set according to the buffer size and allocation policies of the Receiver This value is included in the InitFC and UpdateFC DLLPs (see Section 3.5 Data Link Layer Packets (DLLPs) ) Incremented as the Receiver Transaction Layer makes additional receive buffer space available by processing Received TLPs 12911 12146 Updated as shown: 12147 12912 Updated as shown: 12913 12148 12149 12902 12903 12139 12140 When a Transmitter sends a nullified TLP, the Transmitter does not modify CREDITS_CONSUMED for that TLP (see Section 3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter) ). 12914 CREDITS_ALLOCATED:= CREDITS_ALLOCATED + Increment) mod 2 [Field Size] 12915 CREDITS_ALLOCATED:= (CREDITS_ALLOCATED + Increment) mod 2[Field Size] 12916 12917 12150 12151 12152 12919 Where Increment corresponds to the credits made available, and [Field Size] is defined in Table 2-44 [Field Size] Values 12920 12921 12153 12922 12154 12923 12155 CREDITS_RECEIVED (Optional - for optional error check 12925 described below) 12158 12159 Count of the total number of FC units consumed by valid TLPs Received since Flow Control initialization, modulo 2 [Field Size] (where [Field Size] is defined in Table 2-44 [Field Size] Values Set to all 0's at interface initialization Updated as shown: 12160 12161 (Where Increment corresponds to the credits made available, and [Field Size] is defined in Table 2-45 [Field Size] Values ) 12924 12156 12157 Equation 2-4 CREDITS_ALLOCATED 12918 CREDITS_RECEIVED (Optional - for optional error check described below) 12926 12927 12928 Count of the total number of FC units consumed by valid TLPs Received since Flow Control initialization, modulo 2[Field Size] (where [Field Size] is defined in Table 2-45 [Field Size] Values ) Set to all 0's at interface initialization Updated as shown: 12929 CREDITS_RECEIVED:= (CREDITS_RECEIVED + Increment) mod 2 [Field Size] 12162 Page 198 12930 12931 CREDITS_RECEIVED:= (CREDITS_RECEIVED + Increment) mod 2[Field Size] /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12162 12931 12932 12163 12164 Equation 2-5 CREDITS_RECEIVED 12933 (Where Increment is the size in FC units of the corresponding part of the received TLP, and [Field Size] is defined in Table 2-44 [Field Size] Values 12165 12934 12166 12935 12167 for each Received TLP, provided that TLP: 12936 12168 12937 12169 12938 (Where Increment is the size in FC units of the corresponding part of the received TLP, and [Field Size] is defined in Table 2-45 [Field Size] Values ) 12939 for each Received TLP, provided that TLP: 12940 12170 12171 12172 passes the Data Link Layer integrity checks is not malformed or (optionally) is malformed and is not ambiguous with respect to which buffer to release and is mapped to an initialized Virtual Channel does not consume more credits than have been allocated (see following rule) 12941 For a TLP with an ECRC Check Failed error, but which otherwise is unambiguous with respect to which buffer to release, it is strongly recommended that CREDITS_RECEIVED be updated. 12944 12942 12943 passes the Data Link Layer integrity checks is not malformed or (optionally) is malformed and is not ambiguous with respect to which buffer to release and is mapped to an initialized Virtual Channel does not consume more credits than have been allocated (see following rule) 12173 12174 12175 12945 12176 12946 For a TLP with an ECRC Check Failed error, but which otherwise is unambiguous with respect to which buffer to release, it is strongly recommended that CREDITS_RECEIVED be updated. 12947 12177 12178 If a Receiver implements the CREDITS_RECEIVED counter, then when a nullified TLP is received, the Receiver does not modify CREDITS_RECEIVED for that TLP (see Section 3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter) ) A Receiver may optionally check for Receiver Overflow errors (TLPs exceeding CREDITS_ALLOCATED), by checking the following equation, using unsigned arithmetic: 12179 12180 12948 12949 If a Receiver implements the CREDITS_RECEIVED counter, then when a nullified TLP is received, the Receiver does not modify CREDITS_RECEIVED for that TLP (see Section 3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter) ) A Receiver may optionally check for Receiver Overflow errors (TLPs exceeding CREDITS_ALLOCATED), by checking the following equation, using unsigned arithmetic: 12950 (CREDITS_ALLOCATED - CREDITS_RECEIVED) mod 2 [Field Size] ≥ 2 [Field Size] /2 12951 (CREDITS_ALLOCATED - CREDITS_RECEIVED) mod 2[Field Size] ≥ 2s[Field Size]/2 12952 12953 Equation 2-6 Receiver Overflow Error Check 12954 12181 12955 12182 12183 12956 If the check is implemented and this equation evaluates as true, the Receiver must: 12184 12957 If the check is implemented and this equation evaluates as true, the Receiver must: 12958 12185 discard the TLP(s) without modifying the 12959 CREDITS_RECEIVED 12186 de-allocate any resources which it had allocated for 12960 the TLP(s) 12187 Page 199 discard the TLP(s) without modifying the CREDITS_RECEIVED de-allocate any resources that it had allocated for the TLP(s) 12961 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12187 12961 12188 12189 12962 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 12190 12965 Note: Following a Receiver Overflow error, Receiver behavior is undefined, but it is encouraged that the Receiver continues to operate, processing Flow Control updates and accepting any TLPs which do not exceed allocated credits. 12193 12194 12195 12196 12197 12198 12201 12202 12203 Note: Following a Receiver Overflow error, Receiver behavior is undefined, but it is encouraged that the Receiver continues to operate, processing Flow Control updates and accepting any TLPs that do not exceed allocated credits. 12968 12969 12970 12971 12972 For non-infinite NPH, NPD, PH, and CplH types, an UpdateFC FCP must be scheduled for Transmission each time the following events occur: when scaled flow control is not activated and the number of available FC credits of a particular type is zero and one or more units of that type are made available by TLPs processed, when scaled flow control is not activated, the NPD credit drops below 2, the Receiver supports either the AtomicOp routing capability or the 128-bit CAS Completer capability, and one or more NPD credits are made available by TLPs processed, when scaled flow control is activated and the number of available FC credits of a particular type is zero or is below the scaled threshold and one or more units of that type are made available by TLPs processed so that the number of available credits is equal to or greater than the scaled threshold, which is 0 for HdrScale or Data Scale of 01b, 4 for HdrScale or DataScale of 10b, and 16 for HdrScale or DataScale of 11b. when scaled flow control is activated, the DataScale used for NPD is 01b, the NPD credit drops below 2, the Receiver supports either the AtomicOp routing capability or the 128-bit CAS Completer capability, and one or more NPD credits are made available by TLPs processed. 12973 For non-infinite PD and CplD types, when the number of available credits is less than Max_Payload_Size, an UpdateFC FCP must be scheduled for Transmission each time one or more units of that type are made available by TLPs processed For ARI Devices, the Max_Payload_Size is determined solely by the setting in Function 0. The Max_Payload_Size settings in other Functions are ignored. For a non-ARI Multi-Function Device whose Max_Payload_Size settings are identical across all Functions, the common Max_Payload_Size setting or larger must be used. For a non-ARI Multi-Function Device whose Max_Payload_Size settings are not identical across all Functions, the selected Max_Payload_Size setting is implementation specific, but it is recommended to use the largest Max_Payload_Size setting across all Functions. 12204 12205 12966 12967 For non-infinite NPH, NPD, PH, and CplH types, an UpdateFC FCP must be scheduled for Transmission each time the following events occur: when scaled flow control is not activated and the number of available FC credits of a particular type is zero and one or more units of that type are made available by TLPs processed, when scaled flow control is not activated, the NPD credit drops below 2, the Receiver supports either the AtomicOp routing capability or the 128-bit CAS Completer capability, and one or more NPD credits are made available by TLPs processed, when scaled flow control is activated and the number of available FC credits of a particular type is below the scaled threshold and one or more units of that type are made available by TLPs processed so that the number of available credits is equal to or greater than the scaled threshold. Where the scaled threshold is 0 for HdrScale or Data Scale of 01b, 4 for HdrScale or DataScale of 10b, and 16 for HdrScale or DataScale of 11b. when scaled flow control is activated, the DataScale used for NPD is 01b, the NPD credit drops below 2, the Receiver supports either the AtomicOp routing capability or the 128-bit CAS Completer capability, and one or more NPD credits are made available by TLPs processed. 12199 12200 If checked, this is a reported error associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 12964 12191 12192 12963 12974 12975 12976 12977 For non-infinite PD and CplD types, when the number of available credits is less than Max_Payload_Size, an UpdateFC FCP must be scheduled for Transmission each time one or more units of that type are made available by TLPs processed For ARI Devices, the Max_Payload_Size is determined solely by the setting in Function 0. The Max_Payload_Size settings in other Functions are ignored. For a non-ARI MFD whose Max_Payload_Size settings are identical across all Functions, the common Max_Payload_Size setting or larger must be used. For a non-ARI MFD whose Max_Payload_Size settings are not identical across all Functions, the selected Max_Payload_Size setting is implementation specific, but it is recommended to use the largest Max_Payload_Size setting across all Functions. 12978 UpdateFC FCPs may be scheduled for Transmission more frequently than is required Page 200 12979 UpdateFC FCPs may be scheduled for Transmission more frequently than is required /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12205 12206 12207 12208 12209 12210 12211 UpdateFC FCPs may be scheduled for Transmission more frequently than is required When the Link is in the L0 or L0s Link state, Update FCPs for each enabled type of non-infinite FC credit must be scheduled for transmission at least once every 30 µs (-0%/+50%), except when the Extended Synch bit of the Link Control register is Set, in which case the limit is 120 µs (-0%/+50%). A timeout mechanism may optionally be implemented. If implemented, such a mechanism must: be active only when the Link is in the L0 or L0s Link state use a timer with a limit of 200 µs (-0%/+50%), where the timer is reset by the receipt of any Init or Update FCP. Alternately, the timer may be reset by the receipt of any DLLP (see Section 3.5 Data Link Layer Packets (DLLPs) ) upon timer expiration, instruct the Physical Layer to retrain the Link (via the LTSSM Recovery state, Section 4.2.6.4 Recovery ) if an Infinite Credit advertisement has been made during initialization for all three Flow Control classes, this timeout mechanism must be disabled 12212 12213 12979 12980 12981 12982 12983 12984 12985 12986 Note: The implementation of this optional mechanism is strongly encouraged. Future revisions of this specification may change this mechanism from optional to required. 12214 12987 12988 12215 12989 12216 12990 12217 12991 12218 12992 12219 12220 12221 12994 12995 12996 12223 12997 12224 12998 12226 13000 12227 13001 12228 13002 12229 13003 12230 12232 13005 13006 13007 12234 13008 12235 Page Implementation Note Use of “Infinite” FC Advertisement 13004 Implementation Note Flow Control Update Latency 12233 12236 Note: The implementation of this optional mechanism is strongly encouraged. Future revisions of this specification may change this mechanism from optional to required. 12993 Implementation Note Use of “Infinite” FC Advertisement 12222 12231 UpdateFC FCPs may be scheduled for Transmission more frequently than is required When the Link is in the L0 or L0s Link state, Update FCPs for each enabled type of non-infinite FC credit must be scheduled for transmission at least once every 30 μs (-0%/+50%), except when the Extended Synch bit of the Link Control register is Set, in which case the limit is 120 μs (-0%/+50%). A timeout mechanism may optionally be implemented. If implemented, such a mechanism must: be active only when the Link is in the L0 or L0s Link state use a timer with a limit of 200 μs (-0%/+50%), where the timer is reset by the receipt of any Init or Update FCP. Alternately, the timer may be reset by the receipt of any DLLP (see Section 3.5 Data Link Layer Packets (DLLPs) ) upon timer expiration, instruct the Physical Layer to retrain the Link (via the LTSSM Recovery state, Section 4.2.6.4 Recovery ) if an Infinite Credit advertisement has been made during initialization for all three Flow Control classes, this timeout mechanism must be disabled Implementation Note Flow Control Update Latency 13009 For components subject to receiving streams of TLPs, it is desirable to implement receive buffers larger than the minimum size required to prevent Transmitter throttling due to lack of available credits. Likewise, it is desirable to transmit UpdateFC FCPs such that 201 the time required to send, receive and process the UpdateFC prevents Transmitter throttling. Recommended maximum values for UpdateFC transmission latency during normal operation are shown in Table 2-45 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s (Symbol Times) , Table 2-46 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) , Table 2-47 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s (Symbol Times) , and Table 2-48 Maximum UpdateFC Transmission Latency Guidelines for 16.0 GT/s (Symbol Times) . 13010 For components subject to receiving streams of TLPs, it is desirable to implement receive buffers larger than the minimum size required to prevent Transmitter throttling due to lack of available credits. Likewise, it is desirable to transmit UpdateFC FCPs such that the time required to send, receive and process the UpdateFC prevents Transmitter throttling. Recommended maximum values for UpdateFC transmission latency during normal operation are shown in Table 2-46 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s (Symbol Times) , Table 2- 47 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) , and Table 2-48 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s and Higher Data Rates (Symbol Times) . Note that the values given in in these tables do not account for any /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12236 For components subject to receiving streams of TLPs, it 13010 is desirable to implement receive buffers larger than the minimum size required to prevent Transmitter throttling due to lack of available credits. Likewise, it is desirable to transmit UpdateFC FCPs such that the time required to send, receive and process the UpdateFC prevents Transmitter throttling. Recommended maximum values for UpdateFC transmission latency during normal operation are shown in Table 2-45 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s (Symbol Times) , Table 2-46 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) , Table 2-47 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s (Symbol Times) , and Table 2-48 Maximum UpdateFC Transmission Latency Guidelines for 16.0 GT/s (Symbol Times) . Note that the values given in in these tables do not account for any delays caused by the Receiver or Transmitter being in L0s, in Recovery, or for any delays caused by Retimers (see Section 4.3.8 Retimer Latency ) . For improved performance and/or power-saving, it may be desirable to use a Flow Control update policy that is more sophisticated than a simple timer. Any such policy is implementation specific, and beyond the scope of this document. 12237 13011 12238 12239 13012 The values in the Tables are measured starting from when the Receiver Transaction Layer makes additional receive buffer space available by processing a received TLP, to when the first Symbol of the corresponding UpdateFC DLLP is transmitted. 13013 12240 13014 12241 13015 12242 12243 The values in the Tables are measured starting from when the Receiver Transaction Layer makes additional receive buffer space available by processing a received TLP, to when the first Symbol of the corresponding UpdateFC DLLP is transmitted. 13016 Table 2-45 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s (Symbol Times) 12244 13017 Table 2-46 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s (Symbol Times) 13018 12245 Link Operating Width 13019 12246 13020 12247 13021 12248 Link Operating Width 13022 12249 x1 12250 13023 x1 13024 12251 x2 12252 13025 x2 13026 12253 x4 12369 13027 x4 13143 12370 534 12371 13144 534 13145 12372 276 13146 12373 13147 12374 13148 12375 13149 12376 13150 12377 13151 12378 12379 For components subject to receiving streams of TLPs, it is desirable to implement receive buffers larger than the minimum size required to prevent Transmitter throttling due to lack of available credits. Likewise, it is desirable to transmit UpdateFC FCPs such that the time required to send, receive and process the UpdateFC prevents Transmitter throttling. Recommended maximum values for UpdateFC transmission latency during normal operation are shown in Table 2-46 Maximum UpdateFC Transmission Latency Guidelines for 2.5 GT/s (Symbol Times) , Table 2- 47 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) , and Table 2-48 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s and Higher Data Rates (Symbol Times) . Note that the values given in in these tables do not account for any delays caused by the Receiver or Transmitter being in L0s, in Recovery, or for any delays caused by Retimers (see Section 4.3.8 Retimer Latency ) . For improved performance and/or power-saving, it may be desirable to use a Flow Control update policy that is more sophisticated than a simple timer. Any such policy is implementation specific, and beyond the scope of this document. 276 13152 Table 2-46 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) Page 202 13153 Table 2-47 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12379 Table 2-46 Maximum UpdateFC Transmission Latency 13153 Guidelines for 5.0 GT/s (Symbol Times) 12380 13154 12381 Link Operating Width 13155 12382 13156 12383 13157 12384 Link Operating Width 13158 12385 x1 12386 13159 x1 13160 12387 x2 12388 13161 x2 13162 12389 x4 12505 13163 x4 13279 12506 585 12507 13280 585 13281 12508 327 13282 12509 13283 12510 13284 12511 13285 12512 13286 12513 13287 12514 12515 Table 2-47 Maximum UpdateFC Transmission Latency Guidelines for 5.0 GT/s (Symbol Times) 327 13288 Table 2-47 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s (Symbol Times) 12516 12517 Link Operating Width 12518 12519 12520 12521 x1 12522 12523 x2 12524 12525 x4 12526 12527 x8 12528 12529 x12 12530 12531 x16 12532 12533 x32 12534 12535 12536 12537 12538 Max_Payload_Size (bytes) 12539 12540 128 12541 12542 12543 Page 203 333 13289 Table 2-48 Maximum UpdateFC Transmission Latency Guidelines for 8.0 GT/s and Higher Data Rates (Symbol Times) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12543 12544 224 12545 12546 169 12547 12548 163 12549 12550 154 12551 12552 144 12553 12554 129 12555 12556 12557 12558 256 12559 12560 512 12561 12562 313 12563 12564 214 12565 12566 203 12567 12568 186 12569 12570 168 12571 12572 141 12573 12574 12575 12576 512 12577 12578 655 12579 12580 385 12581 12582 250 12583 12584 182 12585 12586 205 12587 12588 182 12589 12590 12591 12592 12593 Page 204 148 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12593 12594 1024 12595 12596 1167 12597 12598 641 12599 12600 378 12601 12602 246 12603 12604 290 12605 12606 246 12607 12608 180 12609 12610 12611 12612 2048 12613 12614 2191 12615 12616 1153 12617 12618 634 12619 12620 374 12621 12622 461 12623 12624 374 12625 12626 244 12627 12628 12629 12630 4096 12631 12632 4239 12633 12634 2177 12635 12636 1146 12637 12638 630 12639 12640 802 12641 12642 12643 Page 205 630 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12643 12644 372 12645 12646 12647 12648 12649 12650 12651 Table 2-48 Maximum UpdateFC Transmission Latency Guidelines for 16.0 GT/s (Symbol Times) 12652 13290 12653 Link Operating Width 13291 12654 13292 12655 13293 12656 13294 12657 x1 12658 13295 x2 12660 13297 x4 In some cases, the data in a TLP payload is known to be corrupt at the time the TLP is generated, or may become corrupted while passing through an intermediate component, such as a Switch. In these cases, error forwarding, also known as data poisoning, can be used to indicate the corruption to the device consuming the data. 13299 13436 12799 13437 12800 13438 12801 2.7.1 ECRC Rules 12803 12810 12811 2.7.1 ECRC Rules 13442 The capability to generate and check ECRC is reported to software, and the ability to do so is enabled by software (see Section 7.8.4.7 Advanced Error Capabilities and Control Register (Offset 18h) ). 12806 12809 13440 13441 12804 12808 x4 In some cases, the data in a TLP payload is known to be corrupt at the time the TLP is generated, or may become corrupted while passing through an intermediate component, such as a Switch. In these cases, error forwarding, also known as data poisoning, can be used to indicate the corruption to the device consuming the data. 13439 12802 12807 x2 13298 12661 12805 x1 13296 12659 12798 Link Operating Width 13443 The capability to generate and check ECRC is reported to software, and the ability to do so is enabled by software (see Section 7.8.4.7 Advanced Error Capabilities and Control Register (Offset 18h) ). 13444 If a device Function is enabled to generate ECRC, it must calculate and apply ECRC for all TLPs originated by the Function Switches must pass TLPs with ECRC unchanged from the Ingress Port to the Egress Port [Footnote: 40] 13445 If a device supports ECRC generation/checking, at least one of its Functions must support Advanced Error Reporting (AER) (see Section 6.2 Error Signaling and Logging ) If a device Function is enabled to check ECRC, it must do so for all TLPs with ECRC where the device is the ultimate PCI Express Receiver Note that it is still possible for the Function to receive TLPs without ECRC, and these are processed normally - this is not an error 13447 12812 Page 206 13446 13448 13449 13450 If a device Function is enabled to generate ECRC, it must calculate and apply ECRC for all TLPs originated by the Function Switches must pass TLPs with ECRC unchanged from the Ingress Port to the Egress Port [Footnote: An exception is a Multicast TLP that an Egress Port is modifying due to the MC_Overlay mechanism. See Section 6.14.5 MC_Overlay Mechanism .] If a device supports ECRC generation/checking, at least one of its Functions must support Advanced Error Reporting (AER) (see Section 6.2 Error Signaling and Logging ) If a device Function is enabled to check ECRC, it must do so for all TLPs with ECRC where the device is the ultimate PCI Express Receiver Note that it is still possible for the Function to receive TLPs without ECRC, and these are processed normally - this is not an error /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 12812 13450 12813 13451 12814 12815 13452 Note that a Switch may optionally perform ECRC checking on TLPs passing through the Switch. ECRC Errors detected by the Switch are reported as described in Table 6-5 Transaction Layer Error List , but do not alter the TLPs' passage through the Switch. [Footnote: 40] 12816 13455 A 32-bit ECRC is calculated for the TLP (End-End TLP Prefixes, header, and data payload) using the following algorithm and appended to the end of the TLP (see Figure 2-3 Generic TLP Format ): 12819 12820 12821 12822 12823 12824 12825 12826 12829 13456 13458 13459 13460 13461 13462 13463 13464 13466 13467 13468 13025 13663 13026 ECRC calculation starts with bit 0 of byte 0 and proceeds from bit 0 to bit 7 of each byte of the TLP The result of the ECRC calculation is complemented, and the complemented result bits are mapped into the 32-bit TLP Digest field as shown in Table 2-49 Mapping of Bits into ECRC Field . 13664 13027 31 13028 13665 31 13666 13029 24 13667 13030 13668 13031 13669 13032 13670 13033 13035 The ECRC value is calculated using the following algorithm (see Figure 2-49 Calculation of 32-bit ECRC for TLP End to End Data Integrity Protection ) The polynomial used has coefficients expressed as 04C1 1DB7h The seed value (initial value for ECRC storage registers) is FFFF FFFFh All header fields, all End-End TLP Prefixes (if present), and the entire data payload (if present) are included in the ECRC calculation. All bits in Variant fields must be Set for ECRC calculations. Bit 0 of the Type field in a TLP header is Variant [Footnote: Bit 0 of the Type field changes when a Configuration Request is changed from Type 1 to Type 0.] . This bit in an End-End TLP Prefix is invariant. The EP bit is Variant All other fields are Invariant 13465 ECRC calculation starts with bit 0 of byte 0 and proceeds from bit 0 to bit 7 of each byte of the TLP The result of the ECRC calculation is complemented, and the complemented result bits are mapped into the 32-bit TLP Digest field as shown in Table 2-49 Mapping of Bits into ECRC Field . 12830 13034 A 32-bit ECRC is calculated for the TLP (End-End TLP Prefixes, header, and data payload) using the following algorithm and appended to the end of the TLP (see Figure 2-3 Generic TLP Format ): 13457 The ECRC value is calculated using the following algorithm (see Figure 2-46 Calculation of 32-bit ECRC for TLP End to End Data Integrity Protection ) The polynomial used has coefficients expressed as 04C1 1DB7h The seed value (initial value for ECRC storage registers) is FFFF FFFFh All header fields, all End-End TLP Prefixes (if present), and the entire data payload (if present) are included in the ECRC calculation. All bits in Variant fields must be Set for ECRC calculations. Bit 0 of the Type field in a TLP header is Variant [Footnote: Bit 0 of the Type field changes when a Configuration Request is changed from Type 1 to Type 0.] . This bit in an End-End TLP Prefix is invariant. The EP bit is Variant all other fields are Invariant 12827 12828 Note that a Switch may optionally perform ECRC checking on TLPs passing through the Switch. ECRC Errors detected by the Switch are reported as described in Table 6-5 Transaction Layer Error List , but do not alter the TLPs' passage through the Switch. [Footnote: An exception is a Multicast TLP that an Egress Port is modifying due to the MC_Overlay mechanism. See Section 6.14.5 MC_Overlay Mechanism .] 13454 12817 12818 13453 24 13671 The 32-bit ECRC value is placed in the TLP Digest field at the end of the TLP (see Figure 2-3 Generic TLP Format ) For TLPs including a TLP Digest field used for an ECRC value, Receivers which support end-to-end data integrity checking, check the ECRC value in the TLP Digest field by: Page 207 13672 13673 The 32-bit ECRC value is placed in the TLP Digest field at the end of the TLP (see Figure 2-3 Generic TLP Format ) For TLPs including a TLP Digest field used for an ECRC value, Receivers that support end-to-end data integrity checking check the ECRC value in the TLP Digest field by: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13035 For TLPs including a TLP Digest field used for an ECRC value, 13036 13037 Receivers which support end-to-end data integrity checking, check the ECRC value in the TLP Digest field by: applying the same algorithm used for ECRC calculation (above) to the received TLP, not including the 32-bit TLP Digest field of the received TLP comparing the calculated result with the value in the TLP Digest field of the received TLP 13038 13039 13674 13675 13677 13679 Beyond the stated error reporting semantics contained elsewhere in this specification, how ultimate PCI Express Receivers make use of the end-to-end data integrity check provided through the ECRC is beyond the scope of this document. Intermediate Receivers are still required to forward TLPs whose ECRC checks fail. A PCI Express-to-PCI/ PCI-X Bridge is classified as an ultimate PCI Express Receiver with regard to ECRC checking. 13680 13043 13681 13044 13682 13045 13683 13046 13685 13686 13049 13687 13050 13688 13051 Figure 2-49 Calculation of 32-bit ECRC for TLP End to End Data Integrity Protection 13689 13052 Implementation Note Protection of TD Bit Inside Switches 13053 13690 13691 13054 13692 13055 13693 13056 Implementation Note Protection of TD Bit Inside Switches 13694 It is of utmost importance that Switches insure and maintain the integrity of the TD bit in TLPs that they receive and forward (i.e., by applying a special internal protection mechanism), since corruption of the TD bit will cause the ultimate target device to misinterpret the presence or absence of the TLP Digest field. 13695 13073 13711 13074 13712 13075 13713 13076 13714 13077 It is of utmost importance that Switches insure and maintain the integrity of the TD bit in TLPs that they receive and forward (i.e., by applying a special internal protection mechanism), since corruption of the TD bit will cause the ultimate target device to misinterpret the presence or absence of the TLP Digest field. 13715 13078 2.7.2 Error Forwarding 13079 13716 2.7.2 Error Forwarding 13717 13080 13081 Beyond the stated error reporting semantics contained elsewhere in this specification, how ultimate PCI Express Receivers make use of the end-to-end data integrity check provided through the ECRC is beyond the scope of this document. Intermediate Receivers are still required to forward TLPs whose ECRC checks fail. A PCI Express-to-PCI/ PCI-X Bridge is classified as an ultimate PCI Express Receiver with regard to ECRC checking. 13684 Figure 2-46 Calculation of 32-bit ECRC for TLP End to End Data Integrity Protection 13048 13057 Receivers that support end-to-end data integrity checks report violations as an ECRC Error. This reported error is associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 13678 13041 13047 For TLPs including a TLP Digest field used for an ECRC value, Receivers that support end-to-end data integrity checking check the ECRC value in the TLP Digest field by: applying the same algorithm used for ECRC calculation (above) to the received TLP, not including the 32-bit TLP Digest field of the received TLP, and then comparing the calculated result with the value in the TLP Digest field of the received TLP. 13676 Receivers which support end-to-end data integrity checks report violations as an ECRC Error. This reported error is associated with the Receiving Port (see Section 6.2 Error Signaling and Logging ). 13040 13042 13673 13718 Error Forwarding (also known as data poisoning), is indicated by Setting the EP bit. The rules for doing this are specified in Section 2.7.2.2 Rules For Use of Data Poisoning . Here are some examples of cases where Error Forwarding might be used: Page 208 13719 Error Forwarding (also known as data poisoning), is indicated by Setting the EP bit. The rules for doing this are specified in Section 2.7.2.2 Rules For Use of Data Poisoning . Here are some examples of cases where Error Forwarding might be used: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 13081 Error Forwarding (also known as data poisoning), is indicated /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html by Setting the EP bit. The rules for doing this are specified in Section 13719 2.7.2.2 Rules For Use of Data Poisoning . Here are some examples of cases where Error Forwarding might be used: 13082 13720 13083 Example #1: A read from main memory encounters uncorrectable 13721 error 13084 13722 or cache. or cache. 13724 13087 13725 13088 13726 2.7.2.1 Error Forwarding Usage Model 13090 13092 13093 13100 13103 13104 13105 Error Forwarding is only used for Read Completion Data, AtomicOp Completion Data, AtomicOp Request Data, or Write Data, never for the cases when the error is in the “header” (request phase, address/ command, etc.). Requests/Completions with header errors cannot be forwarded in general since true destination cannot be positively known and, therefore, forwarding may cause direct or side effects such as data corruption, system failures, etc. Error Forwarding is used for controlled propagation of errors through the system, system diagnostics, etc. Note that Error forwarding does not cause Link Layer Retry - Poisoned TLPs will be retried only if there are transmission errors on the Link as determined by the TLP error detection mechanisms in the Data Link Layer. 2.7.2.2 Rules For Use of Data Poisoning 13108 13109 13110 Page 2.7.2.1 Error Forwarding Usage Model 13729 13730 13731 13738 Error Forwarding is only used for Read Completion Data, AtomicOp Completion Data, AtomicOp Request Data, or Write Data, never for the cases when the error is in the “header” (request phase, address/ command, etc.). Requests/Completions with header errors cannot be forwarded in general since true destination cannot be positively known and, therefore, forwarding may cause direct or side effects such as data corruption, system failures, etc. Error Forwarding is used for controlled propagation of errors through the system, system diagnostics, etc. Note that Error forwarding does not cause Link Layer Retry - Poisoned TLPs will be retried only if there are transmission errors on the Link as determined by the TLP error detection mechanisms in the Data Link Layer. 2.7.2.2 Rules For Use of Data Poisoning 13739 Support for TLP poisoning in a Transmitter is optional. Data poisoning applies only to the data within a Write Request (Posted or Non-Posted), a Message with Data, an AtomicOp Request, a Read Completion, or an AtomicOp Completion. Poisoning of a TLP is indicated by a Set EP bit. Transmitters are permitted to Set the EP bit only for TLPs that include a data payload. The behavior of the Receiver is not specified if the EP bit is set for any TLP that does not include a data payload. 13106 13107 13727 13728 13101 13102 Example #2: Parity error on a PCI write to main memory Example #3: Data integrity error on an internal data buffer 13723 13086 13091 Example #1: A read from main memory encounters an uncorrectable error Example #2: Parity error on a PCI write to main memory Example #3: Data integrity error on an internal data buffer 13085 13089 Error Forwarding (also known as data poisoning), is indicated by Setting the EP bit. The rules for doing this are specified in Section 2.7.2.2 Rules For Use of Data Poisoning . Here are some examples of cases where Error Forwarding might be used: 13740 13741 13742 13743 Support for TLP poisoning in a Transmitter is optional. Data poisoning applies only to the data within a Write Request (Posted or Non-Posted), a Message with Data, an AtomicOp Request, a Read Completion, or an AtomicOp Completion. Poisoning of a TLP is indicated by a Set EP bit. Transmitters are permitted to Set the EP bit only for TLPs that include a data payload. The behavior of the Receiver is not specified if the EP bit is Set for any TLP that does not include a data payload. 13744 If a Transmitter supports data poisoning, TLPs that are known to the Transmitter to include bad data must use the poisoning mechanism defined above. If a Downstream Port supports Poisoned TLP Egress Blocking, the Poisoned TLP Egress Blocking Enable bit is Set, and a poisoned TLP targets going out the Egress Port, the Port must handle the TLP as a Poisoned TLP Egress Blocked error unless there is a higher precedence error. See Section 6.2.3.2.3 Error Pollution , Section 6.2.5 Sequence of Device Error Signaling and Logging Operations , and Section 7.9.15.2 DPC Capability Register (Offset 04h) . Further: The Port must not transmit the TLP. If the Poisoned TLP Egress Blocked error is unmasked and Downstream Port Containment (DPC) is enabled, DPC must be triggered and the Port must behave as described in Section 2.9.3 Transaction Layer Behavior During Downstream Port Containment . 209 13745 13746 13747 13748 If a Transmitter supports data poisoning, TLPs that are known to the Transmitter to include bad data must use the poisoning mechanism defined above. If a Downstream Port supports Poisoned TLP Egress Blocking, the Poisoned TLP Egress Blocking Enable bit is Set, and a poisoned TLP targets going out the Egress Port, the Port must handle the TLP as a Poisoned TLP Egress Blocked error unless there is a higher precedence error. See Section 6.2.3.2.3 Error Pollution , Section 6.2.5 Sequence of Device Error Signaling and Logging Operations , and Section 7.9.15.2 DPC Capability Register (Offset 04h) . Further: The Port must not transmit the TLP. If DPC is not triggered and the TLP is a Non-Posted Request, the Port must return a Completion with Unsupported Request Completion Status. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13110 If the Poisoned TLP Egress Blocked error is unmasked 13111 and Downstream Port Containment (DPC) is enabled, DPC must be triggered and the Port must behave as described in Section 2.9.3 Transaction Layer Behavior During Downstream Port Containment . If DPC is not triggered and the TLP is a Non-Posted Request, the Port must return a Completion the same as if the TLP had triggered DPC. See Section 2.9.3 Transaction Layer Behavior During Downstream Port Containment . 13112 13113 13114 13115 13116 13748 13749 If DPC is not triggered and the TLP is a Non-Posted Request, the Port must return a Completion with Unsupported Request Completion Status. If DPC is triggered the Port must behave as described in Section 2.9.3 Transaction Layer Behavior During Downstream Port Containment . 13750 The following Requests with Poisoned data must not modify the value of the target location: Configuration Write Request Any of the following that target a control register or control structure in the Completer: I/O Write Request, Memory Write Request, or non-vendor-defined Message with data AtomicOp Request 13117 13751 13752 13753 13754 The following Requests with Poisoned data must not modify the value of the target location: Configuration Write Request Any of the following that target a control register or control structure in the Completer: I/O Write Request, Memory Write Request, or non-vendor-defined Message with data AtomicOp Request 13755 13756 13118 Unless there is a higher precedence error, a Completer must handle these Requests as a Poisoned TLP Received error [Footnote: Due to ambiguous language in earlier versions of this specification, a component is permitted to handle this error as an Unsupported Request, but this is strongly discouraged.] , and the Completer must also return a Completion with a Completion Status of Unsupported Request (UR) if the Request is Non-Posted (see Section 6.2.3.2.3 Error Pollution , Section 6.2.3.2.4 Advisory Non-Fatal Error Cases , and Section 6.2.5 Sequence of Device Error Signaling and Logging Operations ). Regardless of the severity of the reported error, the reported error must be handled as an uncorrectable error, not an Advisory Non-Fatal Error. 13119 Unless there is a higher precedence error, a Completer must handle these Requests as a Poisoned TLP Received error [Footnote: Due to ambiguous language in earlier versions of this specification, a component is permitted to handle this error as an Unsupported Request, but this is strongly discouraged.] , and the Completer must also return a Completion with a Completion Status of Unsupported Request (UR) if the Request is Non-Posted (see Section 6.2.3.2.3 Error Pollution , Section 6.2.3.2.4 Advisory Non-Fatal Error Cases , and Section 6.2.5 Sequence of Device Error Signaling and Logging Operations ). Regardless of the severity of the reported error, the reported error must be handled as an uncorrectable error, not an Advisory Non-Fatal Error. 13758 13759 13120 13121 13757 13760 A Switch must route the Request the same way it would route the same Request if it were not poisoned, unless the Request targets a location in the Switch itself, in which case the Switch is the Completer for the Request and must follow the above rules. A Switch must route the Request the same way it would route the same Request if it were not poisoned, unless the Request targets a location in the Switch itself, in which case the Switch is the Completer for the Request and must follow the above rules. 13761 13122 13762 13123 13763 13124 13125 13126 13764 For some applications it may be desirable for the Completer to use poisoned data in Write Requests which do not target control registers or control structures - such use is not forbidden. Similarly, it may be desirable for the Requester to use data marked poisoned in Completions - such use is also not forbidden. The appropriate use of poisoned information is application specific, and is not discussed in this document. 13127 13765 13128 13129 For some applications it may be desirable for the Completer to use poisoned data in Write Requests that do not target control registers or control structures - such use is not forbidden. Similarly, it may be desirable for the Requester to use data marked poisoned in Completions - such use is also not forbidden. The appropriate use of poisoned information is application specific, and is not discussed in this document. 13766 This document does not define any mechanism for determining which part or parts of the data payload of a Poisoned TLP are actually corrupt and which, if any, are not corrupt. Page 210 13767 This document does not define any mechanism for determining which part or parts of the data payload of a Poisoned TLP are actually corrupt and which, if any, are not corrupt. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 13129 This document does not define any mechanism for determining /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html which part or parts of the data payload of a Poisoned TLP are actually 13767 corrupt and which, if any, are not corrupt. 13130 13768 13131 13769 13132 13770 13133 13771 13134 13772 13135 13773 13136 2.8 Completion Timeout Mechanism 13141 13142 PCI Express device Functions that issue Requests requiring Completions must implement the Completion Timeout mechanism. An exception is made for Configuration Requests (see below). The Completion Timeout mechanism is activated for each Request that requires one or more Completions when the Request is transmitted. Since Switches do not autonomously initiate Requests that need Completions, the requirement for Completion Timeout support is limited only to Root Complexes, PCI Express-PCI Bridges, and Endpoints. 13780 PCI Express device Functions that issue Requests requiring Completions must implement the Completion Timeout mechanism. An exception is made for Configuration Requests (see below). The Completion Timeout mechanism is activated for each Request that requires one or more Completions when the Request is transmitted. Since Switches do not autonomously initiate Requests that need Completions, the requirement for Completion Timeout support is limited only to Root Complexes, PCI Express-PCI Bridges, and Endpoints. 13782 The Completion Timeout mechanism may be disabled by configuration software. The Completion Timeout limit is set in the Completion Timeout Value field of the Device Control 2 register. A Completion Timeout is a reported error associated with the Requester Function (see Section 6.2 Error Signaling and Logging ). 13146 13783 The Completion Timeout mechanism may be disabled by configuration software. The Completion Timeout limit is set in the Completion Timeout Value field of the Device Control 2 register. A Completion Timeout is a reported error associated with the Requester Function (see Section 6.2 Error Signaling and Logging ). 13784 13147 13785 Note: A Memory Read Request for which there are multiple Completions must be considered completed only when all Completions have been received by the Requester. If some, but not all, requested data is returned before the Completion Timeout timer expires, the Requester is permitted to keep or to discard the data that was returned prior to timer expiration. 13149 13786 Note: A Memory Read Request for which there are multiple Completions must be considered completed only when all Completions have been received by the Requester. If some, but not all, requested data is returned before the Completion Timeout timer expires, the Requester is permitted to keep or to discard the data that was returned prior to timer expiration. 13787 13150 13151 2.8 Completion Timeout Mechanism 13781 13144 13148 13774 13779 13143 13145 This document does not define any mechanism for determining which part or parts of the data payload of a Poisoned TLP are actually corrupt and which, if any, are not corrupt. 13788 Completion Timeouts for Configuration Requests have special requirements for the support of PCI Express to PCI/PCI Express bridges. PCI Express to PCI/PCI-X Bridges, by default, are not enabled to return Configuration Request Retry Status (CRS) for Configuration Requests to a PCI/PCI-X device behind the Bridge. This may result in lengthy completion delays that must be comprehended by the Completion Timeout value in the Root Complex. System software may enable PCI Express to PCI/PCI-X Bridges to return Configuration Request Retry Status by setting the Bridge Configuration Retry Enable bit in the Device Control register, subject to the restrictions noted in the PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0 . 13789 13152 13790 13153 13791 13154 13155 13156 13157 Page 211 Completion Timeouts for Configuration Requests have special requirements for the support of PCI Express to PCI/PCI Express bridges. PCI Express to PCI/PCI-X Bridges, by default, are not enabled to return Configuration Request Retry Status (CRS) for Configuration Requests to a PCI/PCI-X device behind the Bridge. This may result in lengthy completion delays that must be comprehended by the Completion Timeout value in the Root Complex. System software may enable PCI Express to PCI/PCI-X Bridges to return CRS by setting the Bridge Configuration Retry Enable bit in the Device Control register, subject to the restrictions noted in the [PCIeto-PCI-PCI-X-Bridge-1.0]. 13792 Implementation Note Completion Timeout Prefix/Header Log Capable 13793 13794 13795 Implementation Note Completion Timeout Prefix/Header Log Capable /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13157 13795 13158 13796 13159 13160 13797 The prefix/header of the Request TLP associated with a Completion Timeout may optionally be recorded by Requesters that implement the AER Capability. Support for recording of the prefix/header is indicated by the value of the Completion Timeout Prefix/Header Log Capable bit in the Advanced Error Capabilities and Control register. 13161 13800 A Completion Timeout may be the result of improper configuration, system failure, or Async Removal (see Section 6.7.5 Async Removal ). In order for host software to distinguish a Completion Timeout error after which continued normal operation is not possible (e.g., after one caused by improper configuration or a system failure) from one where continued normal operation is possible (e.g., after an Async Removal), it is strongly encouraged that Requesters log the Request TLP prefix/header associated with the Completion Timeout. 13801 13164 13802 13165 13803 13166 13804 13167 13805 13168 13806 13169 13170 13808 13809 13172 13810 13173 13811 13175 13813 13176 Page 13817 For a Port with DL_Down status, the Transaction Layer is not required to accept received TLPs from the Data Link Layer, provided that these TLPs have not been acknowledged by the Data Link Layer. Such TLPs do not modify receive Flow Control credits. 13819 For a Downstream Port, DL_Down status is handled by: 13183 13185 DL_Down status indicates that there is no connection with another component on the Link, or that the connection with the other component has been lost and is not recoverable by the Physical or Data Link Layers. This section specifies the Transaction Layer's behavior if DPC has not been triggered and the Data Link Layer reports DL_Down status to the Transaction Layer, indicating that the Link is non-operational. Section 2.9.3 Transaction Layer Behavior During Downstream Port Containment specifies the behavior if DPC has been triggered. 13818 13181 13184 13815 13816 For a Port with DL_Down status, the Transaction Layer is not required to accept received TLPs from the Data Link Layer, provided that these TLPs have not been acknowledged by the Data Link Layer. Such TLPs do not modify receive Flow Control credits. 13180 13182 2.9 Link Status Dependencies 13814 DL_Down status indicates that there is no connection with another component on the Link, or that the connection with the other component has been lost and is not recoverable by the Physical or Data Link Layers. This section specifies the Transaction Layer's behavior if DPC has not been triggered and the Data Link Layer reports DL_Down status to the Transaction Layer, indicating that the Link is non-operational. Section 2.9.3 Transaction Layer Behavior During Downstream Port Containment specifies the behavior if DPC has been triggered. 13178 13179 A Completion Timeout may be the result of improper configuration, system failure, or Async Removal (see Section 6.7.6 Async Removal ). In order for host software to distinguish a Completion Timeout error after which continued normal operation is not possible (e.g., after one caused by improper configuration or a system failure) from one where continued normal operation is possible (e.g., after an Async Removal), it is strongly encouraged that Requesters log the Request TLP prefix/header associated with the Completion Timeout. 13807 2.9 Link Status Dependencies 13171 13177 The prefix/header of the Request TLP associated with a Completion Timeout may optionally be recorded by Requesters that implement the AER Capability. Support for recording of the prefix/header is indicated by the value of the Completion Timeout Prefix/Header Log Capable bit in the Advanced Error Capabilities and Control register. 13799 13162 13163 13798 13820 For a Downstream Port, DL_Down status is handled by: 13821 initializing back to their default state any buffers or internal states associated with outstanding requests transmitted Downstream Note: Port configuration registers must not be affected, except as required to update status associated with the transition to DL_Down 212 13822 13823 Initializing back to their default state any buffers or internal states associated with outstanding requests transmitted Downstream Note: Port configuration registers must not be affected, except as required to update status associated with the transition to DL_Down. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13185 Note: Port configuration registers must not be affected, except as required to update status associated with the transition to DL_Down 13186 13187 13188 13189 13823 Note: Port configuration registers must not be affected, except as required to update status associated with the transition to DL_Down. 13824 for Non-Posted Requests, forming completions for any Requests submitted by the device core for Transmission, returning Unsupported Request Completion Status, then discarding the Requests This is a reported error associated with the Function for the (virtual) Bridge associated with the Port (see Section 6.2 Error Signaling and Logging ). For Root Ports, the reporting of this error is optional. Non-Posted Requests already being processed by the Transaction Layer, for which it may not be practical to return Completions, are discarded. 13190 13825 13826 13827 For Non-Posted Requests, forming completions for any Requests submitted by the device core for Transmission, returning Unsupported Request Completion Status, then discarding the Requests This is a reported error associated with the Function for the (virtual) Bridge associated with the Port (see Section 6.2 Error Signaling and Logging ). For Root Ports, the reporting of this error is optional. Non-Posted Requests already being processed by the Transaction Layer, for which it may not be practical to return Completions, are discarded. 13828 13191 13192 13193 Note: This is equivalent to the case where the Request had been Transmitted but not yet Completed before the Link status became DL_Down. 13194 13195 Note: This is equivalent to the case where the Request had been Transmitted but not yet Completed before the Link status became DL_Down. 13830 These cases are handled by the Requester using the Completion Timeout mechanism. 13196 13831 These cases are handled by the Requester using the Completion Timeout mechanism. 13832 13197 13198 13829 13833 Note: The point at which a Non-Posted Request becomes “uncompletable” is implementation specific. 13199 13834 Note: The point at which a Non-Posted Request becomes “uncompletable” is implementation specific. 13835 13836 13200 13201 13202 13203 13204 The Port must terminate any PME_Turn_Off handshake Requests targeting the Port in such a way that the Port is considered to have acknowledged the PME_Turn_Off request (see the Implementation Note in Section 5.3.3.2.1 PME Synchronization ). The Port must handle Vendor Defined Message Requests as described in Table F-1 (e.g., silently discard Vendor Defined Type 1 Messages Requests that it is not designed to receive) since the DL_Down prevents the Request from reaching its targeted Function. 13837 for all other Posted Requests, discarding the Requests This is a reported error associated with the Function for the (virtual) Bridge associated with the Port (see Section 6.2 Error Signaling and Logging ), and must be reported as an Unsupported Request. For Root Ports, the reporting of this error is optional. For a Posted Request already being processed by the Transaction Layer, the Port is permitted not to report the error. 13839 13205 13838 13840 13841 The Port must terminate any PME_Turn_Off handshake Requests targeting the Port in such a way that the Port is considered to have acknowledged the PME_Turn_Off request (see the Implementation Note in Section 5.3.3.2.1 PME Synchronization ). The Port must handle Vendor Defined Message Requests as described in Section 2.2.8.6 Vendor_Defined Messages (e.g., silently discard Vendor Defined Type 1 Messages Requests that it is not designed to receive) since the DL_Down prevents the Request from reaching its targeted Function. For all other Posted Requests, discarding the Requests This is a reported error associated with the Function for the (virtual) Bridge associated with the Port (see Section 6.2 Error Signaling and Logging ), and must be reported as an Unsupported Request. For Root Ports, the reporting of this error is optional. For a Posted Request already being processed by the Transaction Layer, the Port is permitted not to report the error. 13842 13206 13207 13208 Note: This is equivalent to the case where the Request had been Transmitted before the Link status became DL_Down 13209 Page 213 13843 13844 Note: This is equivalent to the case where the Request had been Transmitted before the Link status became DL_Down /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13209 13844 13210 13845 13846 13211 Note: The point at which a Posted Request becomes “unreportable” is implementation specific. 13212 13213 13847 13848 Discarding all Completions submitted by the device core for Transmission 13214 13849 13851 13216 For an Upstream Port, DL_Down status is handled as a reset 13852 by: 13220 For an Upstream Port, DL_Down status is handled as a reset by: 13217 13219 Discarding all Completions submitted by the device core for Transmission 13850 13215 13218 Note: The point at which a Posted Request becomes “unreportable” is implementation specific. 13853 Returning all PCI Express-specific registers, state machines and externally observable state to the specified default or initial conditions (except for registers defined as sticky - see Section 7.4 Configuration Register Types ) Discarding all TLPs being processed For Switch and Bridge propagating hot reset to all associated Downstream Ports. In Switches that support Link speeds greater than 5.0 GT/s, the Upstream Port must direct the LTSSM of each Downstream Port to the Hot Reset state, but not hold the LTSSMs in that state. This permits each Downstream Port to begin Link training immediately after its hot reset completes. This behavior is recommended for all Switches. 13854 13855 13856 13221 13857 13222 13858 13223 13859 13224 Returning all PCI Express-specific registers, state machines and externally observable state to the specified default or initial conditions (except for registers defined as sticky - see Section 7.4 Configuration Register Types ) Discarding all TLPs being processed For Switch and Bridge propagating hot reset to all associated Downstream Ports. In Switches that support Link speeds greater than 5.0 GT/s, the Upstream Port must direct the LTSSM of each Downstream Port to the Hot Reset state, but not hold the LTSSMs in that state. This permits each Downstream Port to begin Link training immediately after its hot reset completes. This behavior is recommended for all Switches. 13860 13225 2.9.2 Transaction Layer Behavior in DL_Up Status 13226 13861 2.9.2 Transaction Layer Behavior in DL_Up Status 13862 13863 13227 DL_Up status indicates that a connection has been established with another component on the associated Link. This section specifies the Transaction Layer's behavior when the Data Link Layer reports entry to the DL_Up status to the Transaction Layer, indicating that the Link is operational. The Transaction Layer of a Port with DL_Up status must accept received TLPs that conform to the other rules of this specification. 13228 DL_Up status indicates that a connection has been established with another component on the associated Link. This section specifies the Transaction Layer's behavior when the Data Link Layer reports entry to the DL_Up status to the Transaction Layer, indicating that the Link is operational. The Transaction Layer of a Port with DL_Up status must accept received TLPs that conform to the other rules of this specification. 13865 13229 13866 13230 For a Downstream Port on a Root Complex or a Switch: 13231 13232 13864 13867 For a Downstream Port on a Root Complex or a Switch: 13868 When transitioning from a non-DL_Up status to a DL_Up status and the Auto Slot Power Limit Disable bit is Cleared in the Slot Control Register, the Port must initiate the transmission of a Set_Slot_Power_Limit Message to the other component on the Link to convey the value programmed in the Slot Power Limit Scale and Value fields of the Slot Capabilities register. This Transmission is optional if the Slot Capabilities register has not yet been initialized. 13869 13233 13870 13234 13871 Page 214 When transitioning from a non-DL_Up status to a DL_Up status and the Auto Slot Power Limit Disable bit is Clear in the Slot Control Register, the Port must initiate the transmission of a Set_Slot_Power_Limit Message to the other component on the Link to convey the value programmed in the Slot Power Limit Scale and Value fields of the Slot Capabilities register. This Transmission is optional if the Slot Capabilities register has not yet been initialized. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13234 13871 13235 13872 13236 13873 13237 2.9.3 Transaction Layer Behavior During Downstream Port 13874 Containment 13238 13875 13239 13240 13876 During Downstream Port Containment (DPC), the LTSSM associated with the Downstream Port is directed to the Disabled state. Once it reaches the Disabled state, it remains there as long as the DPC Trigger Status bit in the DPC Status register is Set. See Section 6.2.10 Downstream Port Containment (DPC) for requirements on how long software must leave the Downstream Port in DPC. This section specifies the Transaction Layer's behavior once DPC has been triggered, and as long as the Downstream Port remains in DPC. 13241 13242 13250 13251 13254 13255 Once DPC has been triggered, no additional (Upstream) TLPs are accepted from the Data Link Layer. 13883 The Downstream Port handles (Downstream) TLPs submitted by the device core in the following manner. 13884 If the condition that triggered DPC was associated with a Downstream TLP, any prior Downstream TLPs are permitted to be dropped silently or transmitted before the Link goes down. Otherwise, the following rules apply. For each Non-Posted Request, the Port must return a Completion and discard the Request silently. The Completer ID field must contain the value associated with the Downstream Port. If the DPC Completion Control bit is Set in the DPC Control register, then Completions are generated with Unsupported Request (UR) Completion Status. If the DPC Completion Control bit is Clear, Completions are generated with Completer Abort (CA) Completion Status. 13252 13253 13879 13882 The Downstream Port handles (Downstream) TLPs submitted by the device core in the following manner. 13247 13249 During Downstream Port Containment (DPC), the LTSSM associated with the Downstream Port is directed to the Disabled state. Once it reaches the Disabled state, it remains there as long as the DPC Trigger Status bit in the DPC Status Register is Set. See Section 6.2.10 Downstream Port Containment (DPC) for requirements on how long software must leave the Downstream Port in DPC. This section specifies the Transaction Layer's behavior once DPC has been triggered, and as long as the Downstream Port remains in DPC. 13881 13245 13248 13877 13878 Once DPC has been triggered, no additional (Upstream) TLPs are accepted from the Data Link Layer. 13244 13246 2.9.3 Transaction Layer Behavior During Downstream Port Containment 13885 13886 13887 13888 If the condition that triggered DPC was associated with a Downstream TLP, any prior Downstream TLPs are permitted to be dropped silently or transmitted before the Link goes down. Otherwise, the following rules apply. For each Non-Posted Request, the Port must return a Completion and discard the Request silently. The Completer ID field must contain the value associated with the Downstream Port. If the DPC Completion Control bit is Set in the DPC Control Register, then Completions are generated with Unsupported Request (UR) Completion Status. If the DPC Completion Control bit is Clear, Completions are generated with Completer Abort (CA) Completion Status. 13889 The Port must terminate any PME_Turn_Off handshake Requests targeting the Port in such a way that the Port is considered to have acknowledged the PME_Turn_Off Request (see the Implementation Note in Section 5.3.3.2.1 PME Synchronization ). The Port must handle Vendor Defined Message Requests as described in Table F-1. (e.g., silently discard Vendor Defined Type 1 Message Requests that it is not designed to receive) since the DL_Down prevents the Request from reaching its targeted Function. 13890 For all other Posted Requests and Completions, the Port must silently discard the TLP. 13892 13891 13256 13893 13257 13894 The Port must terminate any PME_Turn_Off handshake Requests targeting the Port in such a way that the Port is considered to have acknowledged the PME_Turn_Off Request (see the Implementation Note in Section 5.3.3.2.1 PME Synchronization ). The Port must handle Vendor Defined Message Requests as described in Section 2.2.8.6 Vendor_Defined Messages . (e.g., silently discard Vendor Defined Type 1 Message Requests that it is not designed to receive) since the DL_Down prevents the Request from reaching its targeted Function. For all other Posted Requests and Completions, the Port must silently discard the TLP. 13895 13258 Page For any outstanding Non-Posted Requests where DPC being triggered prevents their associated Completions from being returned, the following apply: 215 13896 For any outstanding Non-Posted Requests where DPC being triggered prevents their associated Completions from being returned, the following apply: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13258 For any outstanding Non-Posted Requests where DPC being triggered prevents their associated Completions from being returned, the following apply: 13259 13260 13261 13896 13897 For Root Ports that support RP Extensions for DPC, the Root Port may track certain Non-Posted Requests, and when DPC is triggered, synthesize a Completion for each tracked Request. This helps avoid Completion Timeouts that would otherwise occur as a side-effect of DPC being triggered. Each synthesized Completion must have a UR or CA Completion Status as determined by the DPC Completion Control bit. The set of Non-Posted Requests that get tracked is implementation-specific, but it is strongly recommended that all Non-Posted Requests that are generated by host processor instructions (e.g., “read”, “write”, “load”, “store”, or one that corresponds to an AtomicOp) be tracked. Other candidates for tracking include peer-to-peer Requests coming from other Root Ports and Requests coming from RCiEPs. Otherwise, the associated Requesters may encounter Completion Timeouts. The software solution stack should comprehend and account for this possibility. 13898 13899 13262 13900 13263 13901 13264 13902 13265 13903 13266 13904 13267 13272 For any outstanding Non-Posted Requests where DPC being triggered prevents their associated Completions from being returned, the following apply: For Root Ports that support RP Extensions for DPC, the Root Port may track certain Non-Posted Requests, and when DPC is triggered, synthesize a Completion for each tracked Request. This helps avoid Completion Timeouts that would otherwise occur as a side-effect of DPC being triggered. Each synthesized Completion must have a UR or CA Completion Status as determined by the DPC Completion Control bit. The set of Non-Posted Requests that get tracked is implementation-specific, but it is strongly recommended that all Non-Posted Requests that are generated by host processor instructions (e.g., “read”, “write”, “load”, “store”, or one that corresponds to an AtomicOp) be tracked. Other candidates for tracking include peer-to-peer Requests coming from other Root Ports and Requests coming from RCiEPs. Otherwise, the associated Requesters may encounter Completion Timeouts. The software solution stack should comprehend and account for this possibility. 13905 The Data Link Layer acts as an intermediate stage between the Transaction Layer and the Physical Layer. Its primary responsibility is to provide a reliable mechanism for exchanging Transaction Layer Packets (TLPs) between the two components on a Link. 13910 13273 13911 13274 13912 13275 The Data Link Layer acts as an intermediate stage between the Transaction Layer and the Physical Layer. Its primary responsibility is to provide a reliable mechanism for exchanging Transaction Layer Packets (TLPs) between the two components on a Link. 13913 13276 3.1 Data Link Layer Overview 13914 13277 13915 13278 13916 13279 13917 13280 13918 13281 13919 3.1 Data Link Layer Overview 13282 13283 Figure 3-1 Layering Diagram Highlighting the Data Link Layer 13920 13284 13921 13285 13922 13286 13287 Figure 3-1 Layering Diagram Highlighting the Data Link Layer 13923 The Data Link Layer is responsible for reliably conveying TLPs supplied by the Transaction Layer across a PCI Express Link to the other component's Transaction Layer. Services provided by the Data Link Layer include: 13288 13291 Page 216 The Data Link Layer is responsible for reliably conveying TLPs supplied by the Transaction Layer across a PCI Express Link to the other component's Transaction Layer. Services provided by the Data Link Layer include: 13925 13289 13290 13924 13926 Data Exchange: 13927 13928 Data Exchange: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13291 13928 13292 Accept TLPs for transmission from the Transmit Transaction Layer and convey them to the Transmit Physical Layer 13929 Accept TLPs for transmission from the Transmit Transaction Layer and convey them to the Transmit Physical Layer 13313 used for Link Management functions including TLP acknowledgement, power management, and exchange of Flow Control information. transferred between Data Link Layers of the two directly connected components on a Link 13950 used for Link Management functions including TLP acknowledgement, power management, and exchange of Flow Control information. transferred between Data Link Layers of the two directly connected components on a Link 13314 13315 13952 13316 13317 13953 DLLPs are sent point-to-point, between the two components on one Link. TLPs are routed from one component to another, potentially through one or more intermediate components. 13318 Data integrity checking for DLLPs and TLPs is done using a CRC included with each packet sent across the Link. DLLPs use a 16-bit CRC and TLPs (which can be much longer than DLLPs) use a 32-bit LCRC. TLPs additionally include a sequence number, which is used to detect cases where one or more entire TLPs have been lost. 13959 Received DLLPs which fail the CRC check are discarded. The mechanisms which use DLLPs may suffer a performance penalty from this loss of information, but are self-repairing such that a successive DLLP will supersede any information lost. 13324 13960 Received DLLPs that fail the CRC check are discarded. The mechanisms that use DLLPs may suffer a performance penalty from this loss of information, but are self-repairing such that a successive DLLP will supersede any information lost. 13961 13325 13962 TLPs which fail the data integrity checks (LCRC and sequence number), or which are lost in transmission from one component to another, are re-sent by the Transmitter. The Transmitter stores a copy of all TLPs sent, re-sending these copies when required, and purges the copies only when it receives a positive acknowledgement of error-free receipt from the other component. If a positive acknowledgement has not been received within a specified time period, the Transmitter will automatically start re-transmission. The Receiver can request an immediate re-transmission using a negative acknowledgement. 13327 13963 TLPs that fail the data integrity checks (LCRC and sequence number), or that are lost in transmission from one component to another, are re-sent by the Transmitter. The Transmitter stores a copy of all TLPs sent, re-sending these copies when required, and purges the copies only when it receives a positive acknowledgement of error-free receipt from the other component. If a positive acknowledgement has not been received within a specified time period, the Transmitter will automatically start re-transmission. The Receiver can request an immediate re-transmission using a negative acknowledgement. 13964 13328 13329 13957 13958 13322 13326 DLLPs are sent point-to-point, between the two components on one Link. TLPs are routed from one component to another, potentially through one or more intermediate components. 13956 Data integrity checking for DLLPs and TLPs is done using a CRC included with each packet sent across the Link. DLLPs use a 16-bit CRC and TLPs (which can be much longer than DLLPs) use a 32-bit LCRC. TLPs additionally include a sequence number, which is used to detect cases where one or more entire TLPs have been lost. 13321 13323 13954 13955 13319 13320 13951 13965 The Data Link Layer appears as an information conduit with varying latency to the Transaction Layer. On any given individual Link all TLPs fed into the Transmit Data Link Layer (1 and 3) will appear at the output of the Receive Data Link Layer (2 and 4) in the same order at a later time, as illustrated in Figure 3-1 Layering Diagram Highlighting the Data Link Layer . The latency will depend on a number of factors, including pipeline latencies, width and operational frequency of the Link, transmission of electrical signals across the Link, and delays caused by Data Link Layer Retry. As a result of these delays, the Transmit Data Link Layer (1 and 3) can apply backpressure to the Transmit Transaction Layer, and the Receive Data Link Layer (2 and 4) communicates the presence or absence of valid information to the Receive Transaction Layer. Page 217 13966 The Data Link Layer appears as an information conduit with varying latency to the Transaction Layer. On any given individual Link all TLPs fed into the Transmit Data Link Layer (1 and 3) will appear at the output of the Receive Data Link Layer (2 and 4) in the same order at a later time, as illustrated in Figure 3-1 Layering Diagram Highlighting the Data Link Layer . The latency will depend on a number of factors, including pipeline latencies, width and operational frequency of the Link, transmission of electrical signals across the Link, and delays caused by Data Link Layer Retry. As a result of these delays, the Transmit Data Link Layer (1 and 3) can apply backpressure to the Transmit Transaction Layer, and the Receive Data Link Layer (2 and 4) communicates the presence or absence of valid information to the Receive Transaction Layer. all TLPs fed into the Transmit Data Link Layer (1 and 3) will appear at the output of the Receive Data Link Layer (2 and 4) in the same order at a later time, as illustrated in Figure 3-1 Layering Diagram Highlighting the Data Link Layer . The latency will depend on a number of factors, including pipeline latencies, width and operational frequency of the Link, transmission of electrical signals across the Link, and delays caused by Data Link Layer Retry. As a result of these delays, the Transmit Data Link Layer (1 and 3) can apply backpressure vs. to the Transmit /private/tmp/PCISIG/pcie4_combined-snapshot.html Transaction Layer, and the Receive Data Link Layer (2 and 4) communicates /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html the presence or absence of valid information to the Receive Transaction Layer. all TLPs fed into the Transmit Data Link Layer (1 and 3) will appear at the output of the Receive Data Link Layer (2 and 4) in the same order at a later time, as illustrated in Figure 3-1 Layering Diagram Highlighting the Data Link Layer . The latency will depend on a number of factors, including pipeline latencies, width and operational frequency of the Link, transmission of electrical signals across the Link, and delays caused by Data Link Layer Retry. As a result of these delays, the Transmit Data Link Layer (1 and 3) can apply backpressure to the Transmit Transaction Layer, and the Receive Data Link Layer (2 and 4) communicates the presence or absence of valid information to the Receive Transaction Layer. 13330 13967 13331 13968 13332 13969 13333 13970 13334 3.2 Data Link Control and Management State Machine 13335 13973 13340 States: 13341 13343 13344 13345 DL_Inactive - Physical Layer reporting Link is non-operational or nothing is connected to the Port DL_Feature (optional) - Physical Layer reporting Link is operational, perform the Data Link Feature Exchange DL_Init - Physical Layer reporting Link is operational, initialize Flow Control for the default Virtual Channel DL_Active - Normal operation mode States: 13979 13980 13981 13982 DL_Inactive - Physical Layer reporting Link is non-operational or nothing is connected to the Port DL_Feature (optional) - Physical Layer reporting Link is operational, perform the Data Link Feature Exchange DL_Init - Physical Layer reporting Link is operational, initialize Flow Control for the default Virtual Channel DL_Active - Normal operation mode 13983 13347 13984 13348 Status Outputs: 13349 13351 13977 13978 13346 13350 3.2 Data Link Control and Management State Machine 13972 13336 13342 13971 13985 Status Outputs: 13986 DL_Down - The Data Link Layer is not communicating with the component on the other side of the Link. DL_Up - The Data Link Layer is communicating with the component on the other side of the Link. 13352 13987 13988 13353 DL_Down - The Data Link Layer is not communicating with the component on the other side of the Link. 13989 13990 13354 13991 13355 13992 13356 13993 13357 DL_Up - The Data Link Layer is communicating with the component on the other side of the Link. 13994 13358 Figure 3-2 Data Link Control and Management State Machine 13995 13359 13996 13360 13997 13361 13998 13362 Figure 3-2 Data Link Control and Management State Machine 13999 13363 3.2.1 Data Link Control and Management State Machine Rules 13364 14000 3.2.1 Data Link Control and Management State Machine Rules 14001 13365 14002 13366 Rules per state: 13367 14003 Rules per state: 14004 14005 13368 13369 13370 DL_Inactive Initial state following PCI Express hot, warm, or cold reset (see Section 6.6 PCI Express Reset - Rules ). Note that DL states are unaffected by an FLR (see Section 6.6 PCI Express Reset - Rules ). Upon entry to DL_Inactive Page 218 14006 14007 14008 DL_Inactive Initial state following PCI Express hot, warm, or cold reset (see Section 6.6 PCI Express Reset - Rules ). Note that DL states are unaffected by an FLR (see Section 6.6 PCI Express Reset - Rules ). Upon entry to DL_Inactive /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13370 Upon entry to DL_Inactive Reset all Data Link Layer state information to default 13371 14008 values 13372 13373 values If the Port supports the optional Data Link Feature Exchange, the Remote Data Link Feature Supported, and Remote Data Link Feature Supported Valid fields must be cleared. Discard the contents of the Data Link Layer Retry Buffer (see Section 3.6 Data Integrity ) 13374 13375 13376 14010 14011 14013 14014 14016 Discard TLP information from the Transaction and 14018 Physical Layers 13381 Do not generate or accept DLLPs Exit to DL_Feature if: The Port supports the optional Data Link Feature Exchange, the Data Link Feature Exchange Enable bit is Set, the Transaction Layer indicates that the Link is not disabled by software, and the Physical Layer reports Physical LinkUp = 1b Do not generate or accept DLLPs 14021 14022 Exit to DL_Feature if: The Port supports the optional Data Link Feature Exchange, the Data Link Feature Exchange Enable bit is Set, the Transaction Layer indicates that the Link is not disabled by software, and the Physical Layer reports Physical LinkUp = 1b 14023 Exit to DL_Init if: The Port does not support the optional Data Link Feature Exchange, the Transaction Layer indicates that the Link is not disabled by software and the Physical Layer reports Physical LinkUp = 1b 13388 14024 14025 Exit to DL_Init if: The Port does not support the optional Data Link Feature Exchange, the Transaction Layer indicates that the Link is not disabled by software and the Physical Layer reports Physical LinkUp = 1b 14026 13389 or 13390 13391 14019 14020 13385 13387 Discard TLP information from the Transaction and Physical Layers 13382 13386 Note: This will cause the Transaction Layer to discard any outstanding transactions and to terminate internally any attempts to transmit a TLP. For a Downstream Port, this is equivalent to a “Hot-Remove”. For an Upstream Port, having the Link go down is equivalent to a hot reset (see Section 2.9 Link Status Dependencies ). 14017 13380 13384 While in DL_Inactive: Report DL_Down status to the Transaction Layer as well as to the rest of the Data Link Layer 14015 Note: This will cause the Transaction Layer to discard any outstanding transactions and to terminate internally any attempts to transmit a TLP. For a Downstream Port, this is equivalent to a “Hot-Remove”. For an Upstream Port, having the Link go down is equivalent to a hot reset (see Section 2.9 Link Status Dependencies ). 13379 13383 If the Port supports the optional Data Link Feature Exchange, the Remote Data Link Feature Supported, and Remote Data Link Feature Supported Valid fields must be cleared. Discard the contents of the Data Link Layer Retry Buffer (see Section 3.6 Data Integrity Mechansisms ) 14012 While in DL_Inactive: Report DL_Down status to the Transaction Layer as well as to the rest of the Data Link Layer 13377 13378 Upon entry to DL_Inactive Reset all Data Link Layer state information to default 14009 14027 or 14028 The Port supports the optional Data Link Feature Exchange, the Data Link Feature Exchange Enable bit is Clear, the Transaction Layer indicates that the Link is not disabled by software, and the Physical Layer reports Physical LinkUp = 1b 14029 13392 14030 13393 14031 The Port supports the optional Data Link Feature Exchange, the Data Link Feature Exchange Enable bit is Clear, the Transaction Layer indicates that the Link is not disabled by software, and the Physical Layer reports Physical LinkUp = 1b 14032 13394 13395 13396 13397 13398 DL_Feature While in DL_Feature: Perform the Data Link Feature Exchange protocol as described in Section 3.3 Data Link Feature Exchange Report DL_Down status The Data Link Layer of a Port with DL_Down status is permitted to discard any received TLPs provided that it does not acknowledge those TLPs by sending one or more Ack DLLPs Page 219 14033 14034 14035 14036 14037 DL_Feature While in DL_Feature: Perform the Data Link Feature Exchange protocol as described in Section 3.3 Data Link Feature Exchange Report DL_Down status The Data Link Layer of a Port with DL_Down status is permitted to discard any received TLPs provided that it does not acknowledge those TLPs by sending one or more Ack DLLPs /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 13398 The Data Link Layer of a Port with DL_Down status is /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html permitted to discard any received TLPs provided that it does not 14037 acknowledge those TLPs by sending one or more Ack DLLPs 13399 13400 13401 14038 Exit to DL_Init if: Data Link Feature Exchange completes successfully, and the Physical Layer continues to report Physical LinkUp = 1b, 13402 or 13404 13408 14040 Exit to DL_Init if: Data Link Feature Exchange completes successfully, and the Physical Layer continues to report Physical LinkUp = 1b, 14042 or 14043 Data Link Feature Exchange determines that the remote Data Link Layer does not support the optional Data Link Feature Exchange protocol, and the Physical Layer continues to report Physical LinkUp = 1b 13406 13407 14039 14041 13403 13405 The Data Link Layer of a Port with DL_Down status is permitted to discard any received TLPs provided that it does not acknowledge those TLPs by sending one or more Ack DLLPs 14044 Data Link Feature Exchange determines that the remote Data Link Layer does not support the optional Data Link Feature Exchange protocol, and the Physical Layer continues to report Physical LinkUp = 1b 14045 Terminate the Data Link Feature Exchange protocol and exit to DL_Inactive if: Physical Layer reports Physical LinkUp = 0b 14046 14047 13409 14048 13410 14049 Terminate the Data Link Feature Exchange protocol and exit to DL_Inactive if: Physical Layer reports Physical LinkUp = 0b 14050 13411 13412 13413 13414 13415 DL_Init While in DL_Init: Initialize Flow Control for the default Virtual Channel, VC0, following the Flow Control initialization protocol described in Section 3.4 Flow Control Initialization Protocol Report DL_Down status while in state FC_INIT1; DL_Up status in state FC_INIT2 The Data Link Layer of a Port with DL_Down status is permitted to discard any received TLPs provided that it does not acknowledge those TLPs by sending one or more Ack DLLPs 13416 13417 13418 13421 14052 14053 14054 14055 DL_Init While in DL_Init: Initialize Flow Control for the default Virtual Channel, VC0, following the Flow Control initialization protocol described in Section 3.4 Flow Control Initialization Protocol Report DL_Down status while in state FC_INIT1; DL_Up status in state FC_INIT2 The Data Link Layer of a Port with DL_Down status is permitted to discard any received TLPs provided that it does not acknowledge those TLPs by sending one or more Ack DLLPs 14056 Exit to DL_Active if: Flow Control initialization completes successfully, and the Physical Layer continues to report Physical LinkUp = 1b 13419 13420 14051 14057 14058 Exit to DL_Active if: Flow Control initialization completes successfully, and the Physical Layer continues to report Physical LinkUp = 1b 14059 Terminate attempt to initialize Flow Control for VC0 and exit to DL_Inactive if: Physical Layer reports Physical LinkUp = 0b 14060 14061 13422 14062 13423 14063 Terminate attempt to initialize Flow Control for VC0 and exit to DL_Inactive if: Physical Layer reports Physical LinkUp = 0b 14064 13424 13425 13426 13427 13428 13429 DL_Active DL_Active is referred to as the normal operating state While in DL_Active: Accept and transfer TLP information with the Transaction and Physical Layers as specified in this chapter Generate and accept DLLPs as specified in this chapter Report DL_Up status to the Transaction and Data Link Layers 13430 13431 Page 220 14065 14066 14067 14068 14069 14070 DL_Active DL_Active is referred to as the normal operating state While in DL_Active: Accept and transfer TLP information with the Transaction and Physical Layers as specified in this chapter Generate and accept DLLPs as specified in this chapter Report DL_Up status to the Transaction and Data Link Layers 14071 Exit to DL_Inactive if: 14072 Exit to DL_Inactive if: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13431 13432 13433 Exit to DL_Inactive if: Physical Layer reports Physical LinkUp = 0b Downstream Ports that are Surprise Down Error Reporting Capable (see Section 7.5.3.6 Link Capabilities Register (Offset 0Ch) ) must treat this transition from DL_Active to DL_Inactive as a Surprise Down error, except in the following cases where this error detection is blocked: 14072 If the Secondary Bus Reset bit in the Bridge Control register has been Set by software, then the subsequent transition to DL_Inactive must not be considered an error. If the Link Disable bit has been Set by software, then the subsequent transition to DL_Inactive must not be considered an error. If a Switch Downstream Port transitions to DL_Inactive due to an event above that Port, that transition to DL_Inactive must not be considered an error. Example events include the Switch Upstream Port propagating Hot Reset, the Switch Upstream Link transitioning to DL_Down, and the Secondary Bus Reset bit in the Switch Upstream Port being Set. If a PME_Turn_Off Message has been sent through this Port, then the subsequent transition to DL_Inactive must not be considered an error. Note that the DL_Inactive transition for this condition will not occur until a power off, a reset, or a request to restore the Link is sent to the Physical Layer. Note also that in the case where the PME_Turn_Off/ PME_TO_Ack handshake fails to complete successfully, a Surprise Down error may be detected. If the Port is associated with a hot-pluggable slot (the Hot-Plug Capable bit in the Slot Capabilities register Set), and the HotPlug Surprise bit in the Slot Capabilities register is Set, then any transition to DL_Inactive must not be considered an error. If the Port is associated with a hot-pluggable slot (HotPlug Capable bit in the Slot Capabilities register Set), and Power Controller Control bit in Slot Control register is Set (Power-Off), then any transition to DL_Inactive must not be considered an error. 14075 14073 14074 Exit to DL_Inactive if: Physical Layer reports Physical LinkUp = 0b Downstream Ports that are Surprise Down Error Reporting Capable (see Section 7.5.3.6 Link Capabilities Register (Offset 0Ch) ) must treat this transition from DL_Active to DL_Inactive as a Surprise Down error, except in the following cases where this error detection is blocked: 13434 13435 13436 13437 13438 13439 13440 13441 13442 14076 14077 14078 14079 14080 14081 14082 13443 If the Secondary Bus Reset bit in the Bridge Control register has been Set by software, then the subsequent transition to DL_Inactive must not be considered an error. If the Link Disable bit has been Set by software, then the subsequent transition to DL_Inactive must not be considered an error. If a Switch Downstream Port transitions to DL_Inactive due to an event above that Port, that transition to DL_Inactive must not be considered an error. Example events include the Switch Upstream Port propagating Hot Reset, the Switch Upstream Link transitioning to DL_Down, and the Secondary Bus Reset bit in the Switch Upstream Port being Set. If a PME_Turn_Off Message has been sent through this Port, then the subsequent transition to DL_Inactive must not be considered an error. Note that the DL_Inactive transition for this condition will not occur until a power off, a reset, or a request to restore the Link is sent to the Physical Layer. Note also that in the case where the PME_Turn_Off/PME_TO_Ack handshake fails to complete successfully, a Surprise Down error may be detected. If the Port is associated with a hot-pluggable slot (the Hot-Plug Capable bit in the Slot Capabilities register Set), and the Hot-Plug Surprise bit in the Slot Capabilities register is Set, then any transition to DL_Inactive must not be considered an error. If the Port is associated with a hot-pluggable slot (Hot-Plug Capable bit in the Slot Capabilities register Set), and Power Controller Control bit in Slot Control register is Set (Power-Off), then any transition to DL_Inactive must not be considered an error. 14083 14084 13444 Error blocking initiated by one or more of the above cases must remain in effect until the Port exits DL_Active and subsequently returns to DL_Active with none of the blocking cases in effect at the time of the return to DL_Active. 13445 14087 Note that the transition out of DL_Active is simply the expected transition as anticipated per the error detection blocking condition. 13448 14088 Note that the transition out of DL_Active is simply the expected transition as anticipated per the error detection blocking condition. 14089 13449 13450 Error blocking initiated by one or more of the above cases must remain in effect until the Port exits DL_Active and subsequently returns to DL_Active with none of the blocking cases in effect at the time of the return to DL_Active. 14086 13446 13447 14085 14090 If implemented, this is a reported error associated with the detecting Port (see Section 6.2 Error Signaling and Logging ). Page 221 14091 If implemented, this is a reported error associated with the detecting Port (see Section 6.2 Error Signaling and Logging ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13450 If implemented, this is a reported error associated with the detecting Port (see Section 6.2 Error Signaling and Logging ). 14091 13451 13452 14092 13453 14093 13454 14094 13455 14095 If implemented, this is a reported error associated with the detecting Port (see Section 6.2 Error Signaling and Logging ). 14096 14097 13456 Implementation Note Physical Layer Throttling 13457 14098 13458 14100 13459 14101 13460 13461 14102 Note that there are conditions where the Physical Layer may be temporarily unable to accept TLPs and DLLPs from the Data Link Layer. The Data Link Layer must comprehend this by providing mechanisms for the Physical Layer to communicate this condition, and for TLPs and DLLPs to be temporarily blocked by the condition. 14103 13462 14104 13463 14105 13464 14106 13465 14107 13484 13485 13486 13489 13490 13491 13492 13495 13496 14127 14128 On entry to DL_Feature: The Remote Data Link Feature Supported and Remote Data Link Feature Supported Valid fields must be Cleared 14129 While in DL_Feature: Transaction Layer must block transmission of TLPs Transmit the Data Link Feature DLLP The transmitted Feature Supported field must equal the Local Data Link Feature Supported field. The transmitted Feature Ack bit must equal the Remote Data Link Feature Supported Valid bit. 13493 13494 Note that there are conditions where the Physical Layer may be temporarily unable to accept TLPs and DLLPs from the Data Link Layer. The Data Link Layer must comprehend this by providing mechanisms for the Physical Layer to communicate this condition, and for TLPs and DLLPs to be temporarily blocked by the condition. 14126 On entry to DL_Feature: The Remote Data Link Feature Supported and Remote Data Link Feature Supported Valid fields must be Cleared 13487 13488 Implementation Note Physical Layer Throttling 14099 14130 14131 14132 14133 14134 While in DL_Feature: Transaction Layer must block transmission of TLPs Transmit the Data Link Feature DLLP The transmitted Feature Supported field must equal the Local Data Link Feature Supported field. The transmitted Feature Ack bit must equal the Remote Data Link Feature Supported Valid bit. 14135 The Data Link Feature DLLP must be transmitted at least once every 34 µs. Time spent in the Recovery or Configuration LTSSM states does not contribute to this limit. Process received Data Link Feature DLLPs: If the Remote Data Link Feature Supported Valid bit is Clear, record the Feature Supported field from the received Data Link Feature DLLP in the Remote Data Link Feature Supported field and Set the Remote Data Link Feature Supported Valid bit. 13497 14136 14137 14138 The Data Link Feature DLLP must be transmitted at least once every 34 μs. Time spent in the Recovery or Configuration LTSSM states does not contribute to this limit. Process received Data Link Feature DLLPs: If the Remote Data Link Feature Supported Valid bit is Clear, record the Feature Supported field from the received Data Link Feature DLLP in the Remote Data Link Feature Supported field and Set the Remote Data Link Feature Supported Valid bit. 14139 13498 14140 13499 Exit DL_Feature if: An InitFC1 DLLP has been received. An MR-IOV MRInit DLLP (encoding 0000 0001b) has been 13500 13501 14141 14143 received. 13502 Page 222 Exit DL_Feature if: An InitFC1 DLLP has been received. An MR-IOV MRInit DLLP (encoding 0000 0001b) has been 14142 received. 14144 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13502 14144 13503 14145 or 13504 13556 14198 13557 The rules for this process are given in the following section. 14199 13558 14200 13559 14201 13560 3.4.1 Flow Control Initialization State Machine Rules 13562 13564 13565 13566 13567 14203 If at any time during initialization for VCs 1-7 the VC is disabled, the flow control initialization process for the VC is terminated Rules for state FC_INIT1: Entered when initialization of a VC (VCx) is required Entrance to DL_Init state (VCx = VC0) When a VC (VCx = VC1-7) is enabled by software (see Section 7.9.1 and Section 7.9.2 ) 14205 14206 14207 14208 14209 While in FC_INIT1: Transaction Layer must block transmission of TLPs using 14211 Transmit the following three InitFC1 DLLPs for VCx in the following relative order: InitFC1-P (first) InitFC1-NP (second) InitFC1-Cpl (third) 14213 13570 13574 VCx 13575 14214 14215 14216 The three InitFC1 DLLPs must be transmitted at least 14218 once every 34 µs. 13578 Time spent in the Recovery or Configuration LTSSM states does not contribute to this limit. It is strongly encouraged that the InitFC1 DLLP transmissions are repeated frequently, particularly when there are no other TLPs or DLLPs available for transmission. 13579 13580 13581 13582 13583 Transmit the following three InitFC1 DLLPs for VCx in the following relative order: InitFC1-P (first) InitFC1-NP (second) InitFC1-Cpl (third) 14217 13576 13577 While in FC_INIT1: Transaction Layer must block transmission of TLPs using 14212 VCx 13573 If at any time during initialization for VCs 1-7 the VC is disabled, the flow control initialization process for the VC is terminated Rules for state FC_INIT1: Entered when initialization of a VC (VCx) is required When the DL_Init state is entered (VCx = VC0) When a VC (VCx = VC1-7) is enabled by software (see Section 7.9.1 Virtual Channel Extended Capability and Section 7.9.2 Multi-Function Virtual Channel Extended Capability ) 14210 13569 13572 3.4.1 Flow Control Initialization State Machine Rules 14204 13568 13571 The rules for this process are given in the following section. 14202 13561 13563 or 14146 The three InitFC1 DLLPs must be transmitted at least once every 34 μs. 14219 14220 Time spent in the Recovery or Configuration LTSSM states does not contribute to this limit. It is strongly encouraged that the InitFC1 DLLP transmissions are repeated frequently, particularly when there are no other TLPs or DLLPs available for transmission. 14221 If Scaled Flow Control is activated on the Link, set the HdrScale and DataScale fields in the InitFC1 DLLPs to 01b, 10b, or 11b to indicate the scaling factor it is using on the corresponding HdrFC and DataFC values. If the Transmitter does not support Scaled Flow Control or if Scaled Flow Control is not activated on the Link, set the HdrScale and DataScale fields to 00b. Except as needed to ensure at least the required frequency of InitFC1 DLLP transmission, the Data Link Layer must not block other transmissions. Note that this includes all Physical Layer initiated transmissions (for example, Ordered Sets), Ack and Nak DLLPs (when applicable), and TLPs using VCs that have previously completed initialization (when applicable) Page 223 14222 14223 14224 14225 If Scaled Flow Control is activated on the Link, set the HdrScale and DataScale fields in the InitFC1 DLLPs to 01b, 10b, or 11b to indicate the scaling factor it is using on the corresponding HdrFC and DataFC values. If the Transmitter does not support Scaled Flow Control or if Scaled Flow Control is not activated on the Link, set the HdrScale and DataScale fields to 00b. Except as needed to ensure at least the required frequency of InitFC1 DLLP transmission, the Data Link Layer must not block other transmissions. Note that this includes all Physical Layer initiated transmissions (for example, Ordered Sets), Ack and Nak DLLPs (when applicable), and TLPs using VCs that have previously completed initialization (when applicable) Note that this includes all Physicalvs. Layer /private/tmp/PCISIG/pcie4_combined-snapshot.html initiated transmissions (for example, Ordered Sets), Ack and Nak DLLPs /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html (when applicable), and TLPs using VCs that have previously completed 13583 14225 initialization (when applicable) 13584 14226 13585 Process received InitFC1 and InitFC2 DLLPs: Record the indicated HdrFC and DataFC values 13586 13593 14227 14236 13595 Rules for state FC_INIT2: While in FC_INIT2: Transaction Layer must block transmission of TLPs using 14237 Transmit the following three InitFC2 DLLPs for VCx in the following relative order: InitFC2-P (first) InitFC2-NP (second) InitFC2-Cpl (third) 14240 13596 13597 13600 13601 14239 VCx 13602 14241 14242 14243 The three InitFC2 DLLPs must be transmitted at least 14245 once every 34 µs. 13605 13608 13609 13610 Time spent in the Recovery or Configuration LTSSM states does not contribute to this limit. It is strongly encouraged that the InitFC2 DLLP transmissions are repeated frequently, particularly when there are no other TLPs or DLLPs available for transmission. 14246 14247 14249 14250 14251 14252 Process received InitFC1 and InitFC2 DLLPs: Ignore the received HdrFC, HdrScale, DataFC, and 13613 14254 DataScale values DataScale values 14283 13642 14284 13643 14285 13644 Process received InitFC1 and InitFC2 DLLPs: Ignore the received HdrFC, HdrScale, DataFC, and 14255 13641 14286 3.4.2 Scaled Flow Control 13646 14287 3.4.2 Scaled Flow Control 14288 13647 Page If Scaled Flow Control is activated on the Link, set the HdrScale and DataScale fields in the InitF2 DLLPs to 01b, 10b, or 11b to indicate the scaling factor it is using on the corresponding HdrFC and DataFC values. If the Transmitter does not support Scaled Flow Control or if Scaled Flow Control is not activated on the Link, set the HdrScale and DataScale fields to 00b. Except as needed to ensure at least the required frequency of InitFC2 DLLP transmission, the Data Link Layer must not block other transmissions Note that this includes all Physical Layer initiated transmissions (for example, Ordered Sets), Ack and Nak DLLPs (when applicable), and TLPs using VCs that have previously completed initialization (when applicable) 14253 13612 13648 Time spent in the Recovery or Configuration LTSSM states does not contribute to this limit. It is strongly encouraged that the InitFC2 DLLP transmissions are repeated frequently, particularly when there are no other TLPs or DLLPs available for transmission. 14248 If Scaled Flow Control is activated on the Link, set the HdrScale and DataScale fields in the InitF2 DLLPs to 01b, 10b, or 11b to indicate the scaling factor it is using on the corresponding HdrFC and DataFC values. If the Transmitter does not support Scaled Flow Control or if Scaled Flow Control is not activated on the Link, set the HdrScale and DataScale fields to 00b. Except as needed to ensure at least the required frequency of InitFC2 DLLP transmission, the Data Link Layer must not block other transmissions Note that this includes all Physical Layer initiated transmissions (for example, Ordered Sets), Ack and Nak DLLPs (when applicable), and TLPs using VCs that have previously completed initialization (when applicable) 13611 13645 The three InitFC2 DLLPs must be transmitted at least once every 34 μs. 13606 13607 Transmit the following three InitFC2 DLLPs for VCx in the following relative order: InitFC2-P (first) InitFC2-NP (second) InitFC2-Cpl (third) 14244 13603 13604 Rules for state FC_INIT2: While in FC_INIT2: Transaction Layer must block transmission of TLPs using 14238 VCx 13599 Process received InitFC1 and InitFC2 DLLPs: Record the indicated HdrFC and DataFC values 14228 14235 13594 13598 Note that this includes all Physical Layer initiated transmissions (for example, Ordered Sets), Ack and Nak DLLPs (when applicable), and TLPs using VCs that have previously completed initialization (when applicable) 14289 Link performance can be affected when there are insufficient flow control credits available to account for t he Link round trip time. This effect becomes more noticeable at higher Link speeds and the limitation of 127 header credits and 2047 data credits can limit 224 performance. The Scaled Flow Control mechanism is designed to address this limitation. 14290 Link performance can be affected when there are insufficient flow control credits available to account for the Link round trip time. This effect becomes more noticeable at higher Link speeds and the limitation of 127 header credits and 2047 data credits can limit performance. The Scaled Flow Control mechanism is designed to address this limitation. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13648 Link performance can be affected when there are insufficient 14290 flow control credits available to account for t he Link round trip time. This effect becomes more noticeable at higher Link speeds and the limitation of 127 header credits and 2047 data credits can limit performance. The Scaled Flow Control mechanism is designed to address this limitation. 13649 14291 13650 13651 14292 All Ports are permitted to support Scaled Flow Control. Ports that support 16.0 GT/s must support Scaled Flow Control. Scaled Flow Control activation does not affect the ability to operate at 16.0 GT/s . 13652 13657 13658 13665 13666 14298 14299 14300 The InitFC1, InitFC2, and UpdateFC DLLPs must contain 00b in the HdrScale and DataScale fields. The HdrFC counter is 8 bits wide and the HdrFC DLLP field includes all bits of the counter. The DataFC counter is 12 bits wide and the DataFC DLLP field includes all bits of the counter. 14302 The following rules apply when Scaled Flow Control is activated for the Link: 13662 13664 The following rules apply when Scaled Flow Control is not activated for the Link: 14301 13660 13663 14296 14297 The InitFC1, InitFC2, and UpdateFC DLLPs must contain 00b in the HdrScale and DataScale fields. The HdrFC counter is 8 bits wide and the HdrFC DLLP field includes all bits of the counter. The DataFC counter is 12 bits wide and the DataFC DLLP field includes all bits of the counter. 13659 13661 All Ports are permitted to support Scaled Flow Control. Ports that support 16.0 GT/s and higher data rates must support Scaled Flow Control. Scaled Flow Control activation does not affect the ability to operate at 16.0 GT/s and higher data rates. 14295 The following rules apply when Scaled Flow Control is not activated for the Link: 13655 13656 14293 14294 13653 13654 Link performance can be affected when there are insufficient flow control credits available to account for the Link round trip time. This effect becomes more noticeable at higher Link speeds and the limitation of 127 header credits and 2047 data credits can limit performance. The Scaled Flow Control mechanism is designed to address this limitation. 14303 The following rules apply when Scaled Flow Control is activated for the Link: 14304 The InitFC1 and InitFC2 DLLPs must contain 01b, 10b, or 11b in the HdrScale field. The value is determined by the maximum number of header credits that will be outstanding of the indicated credit type as defined in Table 3-2 Scaled Flow Control Scaling Factors . The InitFC1 and InitFC2 DLLPs must contain 01b, 10b, or 11b in the DataScale field. The value is determined by the maximum number of data payload credits that will be outstanding of the indicated credit type as defined in Table 3-2 Scaled Flow Control Scaling Factors . If the received HdrScale and DataScale values recorded in state FC_INIT1 were non-zero, then Scaled Flow Control is enabled on this VC and UpdateFC DLLPs must contain 01b, 10b, or 11b in the HdrScale and DataScale fields. If the received HdrScale and DataScale values recorded in state FC_INIT1 were zero, then Scaled Flow Control is not enabled on this VC and UpdateFC DLLPs must contain 00b in the HdrScale and DataScale fields. 14305 14306 14307 14308 13667 14309 13668 14310 13669 13670 14311 Table 3-2 Scaled Flow Control Scaling Factors 13671 13672 Page 225 14312 Table 3-2 Scaled Flow Control Scaling Factors 14313 Scale Factor 13673 13674 The InitFC1 and InitFC2 DLLPs must contain 01b, 10b, or 11b in the HdrScale field. The value is determined by the maximum number of header credits that will be outstanding of the indicated credit type as defined in Table 3-2 Scaled Flow Control Scaling Factors . The InitFC1 and InitFC2 DLLPs must contain 01b, 10b, or 11b in the DataScale field. The value is determined by the maximum number of data payload credits that will be outstanding of the indicated credit type as defined in Table 3-2 Scaled Flow Control Scaling Factors . If the received HdrScale and DataScale values recorded in state FC_INIT1 were non-zero, then Scaled Flow Control is enabled on this VC and UpdateFC DLLPs must contain 01b, 10b, or 11b in the HdrScale and DataScale fields. If the received HdrScale and DataScale values recorded in state FC_INIT1 were zero, then Scaled Flow Control is not enabled on this VC and UpdateFC DLLPs must contain 00b in the HdrScale and DataScale fields. 14314 14315 Scaled Flow Control Supported Scale Factor /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13674 Scaled Flow Control Supported 13675 13676 Header Credits 13677 13678 Data Credits 13679 13680 13681 13682 Min Credits 13683 13684 Max Credits 13685 13686 14316 HdrFC Width 14317 14318 14319 13687 13688 14320 HdrFC DLLP field 13689 13690 Scaled Flow Control Supported 14321 14322 Credit Type Min Credits 13691 13692 Max Credits 13693 13694 14323 DataFC Width 14324 14325 13695 13696 14326 DataFC DLLP Field 14327 14328 13697 14331 13698 14333 Transmitted 14335 Received 13703 14336 Transmitted 13705 13706 14337 Received 14339 14340 13708 14341 13709 Received 14342 00b 13711 13712 Transmitted 14338 13707 13710 FC DLLP field 14334 13701 13704 Field Width 14332 13699 13702 Max Credits 14329 14330 13700 Min Credits 14343 00b 14344 No 13713 14345 No 14346 14347 Hdr 14348 13714 13715 Page 226 1 14349 14350 1 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13715 13716 14350 127 13717 13718 8 bits 14353 8 bits 14354 HdrFC 13721 13722 127 14352 13719 13720 14351 14355 HdrFC 14356 HdrFC 13723 14357 HdrFC 14358 14359 14360 14361 Data 14362 13724 1 13725 13726 2047 12 bits 14367 DataFC 14369 DataFC 14371 14372 13734 14373 13735 DataFC DataFC 14374 01b 13737 13738 12 bits 14370 13733 13736 2,047 14368 13731 13732 14365 14366 13729 13730 1 14364 13727 13728 14363 14375 01b 14376 Yes 13739 14377 Yes 14378 14379 Hdr 14380 13740 1 13741 13742 127 8 bits 127 14385 8 bits 14386 HdrFC 13747 13748 14383 14384 13745 13746 1 14382 13743 13744 14381 14387 HdrFC 14388 HdrFC 13749 14389 HdrFC 14390 14391 14392 14393 Data 14394 13750 1 13751 13752 2047 Page 227 14397 2,047 14398 12 bits 13755 13756 1 14396 13753 13754 14395 14399 12 bits 14400 DataFC 14401 DataFC /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13756 DataFC 13757 13758 14401 DataFC 14403 13759 14404 13760 14405 13761 13762 DataFC 14406 10b 13763 13764 DataFC 14402 14407 10b 14408 Yes 13765 14409 Yes 14410 14411 Hdr 14412 13766 4 13767 13768 508 10 bits 508 14417 10 bits 14418 HdrFC>>2 13773 13774 14415 14416 13771 13772 4 14414 13769 13770 14413 14419 HdrFC >> 2 14420 HdrFC<<2 13775 14421 HdrFC << 2 14422 14423 14424 14425 Data 14426 13776 4 13777 13778 8188 14 bits 14431 DataFC>>2 14433 DataFC<<2 14435 14436 13786 14437 13787 DataFC >> 2 DataFC << 2 14438 11b 13789 13790 14 bits 14434 13785 13788 8,188 14432 13783 13784 14429 14430 13781 13782 4 14428 13779 13780 14427 14439 11b 14440 Yes 13791 14441 Yes 14442 14443 Hdr 14444 13792 16 13793 13794 2032 Page 228 14447 2,032 14448 12 bits 13797 13798 16 14446 13795 13796 14445 14449 12 bits 14450 HdrFC>>4 14451 HdrFC >> 4 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13798 HdrFC>>4 13799 14451 HdrFC >> 4 14452 13800 HdrFC<<4 13801 14453 HdrFC << 4 14454 14455 14456 14457 Data 14458 13802 16 13803 14459 13804 32,752 13805 14461 16 bits 13807 14463 DataFC>>4 13809 14465 DataFC<<4 14467 13811 14468 13816 14473 13817 14474 13818 3.5 Data Link Layer Packets (DLLPs) 13820 14476 3.5 Data Link Layer Packets (DLLPs) 14477 13821 14478 13822 The following DLLPs are used to support Link operations: 13823 14479 The following DLLPs are used to support Link operations: 14480 Ack DLLP: TLP Sequence Number acknowledgement; used to indicate successful receipt of some number of TLPs Nak DLLP: TLP Sequence Number negative acknowledgement; used to initiate a Data Link Layer Retry InitFC1, InitFC2, and UpdateFC DLLPs: For Flow Control DLLPs used for Power Management 14481 14482 14483 14484 13828 14485 13829 14486 13830 Ack DLLP: TLP Sequence Number acknowledgement; used to indicate successful receipt of some number of TLPs Nak DLLP: TLP Sequence Number negative acknowledgement; used to initiate a Data Link Layer Retry InitFC1, InitFC2, and UpdateFC DLLPs; used for Flow Control DLLPs used for Power Management 14487 13831 3.5.1 Data Link Layer Packet Rules 13832 14488 3.5.1 Data Link Layer Packet Rules 14489 13833 13834 DataFC << 4 14475 13819 13827 DataFC >> 4 14466 13810 13826 16 bits 14464 13808 13825 32,752 14462 13806 13824 16 14460 14490 All DLLP fields marked Reserved (sometimes abbreviated as R) must be filled with all 0's when a DLLP is formed. Values in such fields must be ignored by Receivers. The handling of Reserved values in encoded fields is specified for each case. 14491 13835 14492 13836 14493 13955 14612 13956 13957 14613 1110 0v2v1v0 13958 13959 13960 Page 229 All DLLP fields marked Reserved (sometimes abbreviated as R) must be filled with all 0's when a DLLP is formed. Values in such fields must be ignored by Receivers. The handling of Reserved values in encoded fields is specified for each case. 14614 1110 0v2v1v0 14615 InitFC2-Cpl 14616 14617 InitFC2-Cpl /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 13960 14617 13961 14618 13962 14619 13963 1111 0v2v1v0 13964 14620 13965 MRInitFC2 - See the MR-IOV Specification44 14622 13966 14623 13967 14624 13968 1000 0v2v1v0 13970 14626 UpdateFC-P 14628 13972 14629 13973 14630 13974 1001 0v2v1v0 13979 14632 14637 13981 1010 0v2v1v0 13982 14638 1010 0v2v1v0 14639 13983 UpdateFC-Cpl 14640 13984 14641 13985 14642 13986 UpdateFC-Cpl 14643 13987 1011 0v2v1v0 13988 14644 1011 0v2v1v0 14645 13989 MRUpdateFC - See the MR-IOV Specification44 14646 13990 14647 13991 14648 13992 MRUpdateFC - See the MR-IOV Specification [Footnote: The MR-IOV protocol uses these encodings after the successful completion of MRInit negotiation.] 14649 13993 All other encodings 13994 14650 All other encodings 14651 13995 Reserved 14652 13996 14653 13997 14654 13998 14655 13999 Reserved 14656 For Ack and Nak DLLPs (see Figure 3-5 Data Link Layer Packet Format for Ack and Nak ): The AckNak_Seq_Num field is used to indicate what TLPs are affected Transmission and reception is handled by the Data Link Layer according to the rules provided in Section 3.6 Data Integrity . 14003 14005 1001 0v2v1v0 14636 13980 14004 UpdateFC-P 14631 13975 14002 1000 0v2v1v0 14627 13971 14001 MRInitFC2 - See the MR-IOV Specification [Footnote: The MR-IOV protocol uses these encodings after the successful completion of MRInit negotiation.] 14625 13969 14000 1111 0v2v1v0 14621 14657 14658 14659 For Ack and Nak DLLPs (see Figure 3-5 Data Link Layer Packet Format for Ack and Nak ): The AckNak_Seq_Num field is used to indicate what TLPs are affected Transmission and reception is handled by the Data Link Layer according to the rules provided in Section 3.6 Data Integrity Mechansisms . 14660 For InitFC1, InitFC2, and UpdateFC DLLPs: The HdrFC field contains the credit value for headers of the indicated type (P, NP, or Cpl). Page 230 14661 14662 For InitFC1, InitFC2, and UpdateFC DLLPs: The HdrFC field contains the credit value for headers of the indicated type (P, NP, or Cpl). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14005 14006 14007 14008 14009 14010 14011 14012 14013 The HdrFC field contains the credit value for headers of the indicated type (P, NP, or Cpl). The DataFC field contains the credit value for payload Data of the indicated type (P, NP, or Cpl). The HdrScale field contains the scaling factor for headers of the indicated type. Encodings are defined in Table 3-4 HdrScale and DataScale Encodings . The DataScale field contains the scaling factor for payload data of the indicated type. Encodings are defined in Table 3-4 HdrScale and DataScale Encodings . If Scaled Flow Control is activated, the HdrScale and DataScale fields must be set to 01b, 10b, or 11b in all InitFC1, InitFC2, and UpdateFC DLLPs transmitted. In UpdateFCs, a Transmitter is only permitted to send non-zero values in the HdrScale and DataScale fields if it supports Scaled Flow Control and it received non-zero values for HdrScale and DataScale in the InitFC1s and InitFC2s it received for this VC. The packet formats are shown in Figure 3-7 Data Link Layer Packet Format for InitFC1 , Figure 3-8 Data Link Layer Packet Format for InitFC2 , and Figure 3-9 Figure 3-9: Data Link Layer Packet Format for UpdateFC . Transmission is triggered by the Data Link Layer when initializing Flow Control for a Virtual Channel (see Section 3.4 Flow Control Initialization Protocol ), and following Flow Control initialization by the Transaction Layer according to the rules in Section 2.6 Ordering and Receive Buffer Flow Control . Checked for integrity on reception by the Data Link Layer and if correct, the information content of the DLLP is passed to the Transaction Layer. If the check fails, the information is discarded. 14014 14662 14663 14664 14665 14666 14667 14668 14669 14670 The HdrFC field contains the credit value for headers of the indicated type (P, NP, or Cpl). The DataFC field contains the credit value for payload Data of the indicated type (P, NP, or Cpl). The HdrScale field contains the scaling factor for headers of the indicated type. Encodings are defined in Table 3-4 HdrScale and DataScale Encodings . The DataScale field contains the scaling factor for payload data of the indicated type. Encodings are defined in Table 3-4 HdrScale and DataScale Encodings . If Scaled Flow Control is activated, the HdrScale and DataScale fields must be set to 01b, 10b, or 11b in all InitFC1, InitFC2, and UpdateFC DLLPs transmitted. In UpdateFCs, a Transmitter is only permitted to send non-zero values in the HdrScale and DataScale fields if it supports Scaled Flow Control and it received non-zero values for HdrScale and DataScale in the InitFC1s and InitFC2s it received for this VC. The packet formats are shown in Figure 3-7 Data Link Layer Packet Format for InitFC1 , Figure 3-8 Data Link Layer Packet Format for InitFC2 , and Figure 3-9 Data Link Layer Packet Format for UpdateFC . Transmission is triggered by the Data Link Layer when initializing Flow Control for a Virtual Channel (see Section 3.4 Flow Control Initialization Protocol ), and following Flow Control initialization by the Transaction Layer according to the rules in Section 2.6 Ordering and Receive Buffer Flow Control . Checked for integrity on reception by the Data Link Layer and if correct, the information content of the DLLP is passed to the Transaction Layer. If the check fails, the information is discarded. 14671 14015 Note: InitFC1 and InitFC2 DLLPs are used only for VC 14672 initialization 14016 14673 14017 14674 14018 14675 14019 14676 14020 14021 14677 Table 3-4 HdrScale and DataScale Encodings 14022 14023 14678 HdrScale or DataScale Value 14024 14680 14683 14685 14026 14028 14687 Scaling Factor 14689 HdrFC DLLP Field 14690 14691 Page 231 Scaled Flow Control Supported 14686 Scaling Factor 14688 14029 HdrScale or DataScale Value 14682 Scaled Flow Control Supported 14684 14027 Table 3-4 HdrScale and DataScale Encodings 14679 14681 14025 Note: InitFC1 and InitFC2 DLLPs are used only for VC initialization HdrFC DLLP Field /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14691 14030 14031 DLLP Field 14692 DataFC DLLP Field 14693 DataFC DLLP Field 14694 14032 14695 14033 14696 14034 14035 14697 00b 14036 14037 No 1 HdrFC[7:0] 16 14704 HdrFC[11:4] DataFC[15:4] 14742 14744 14082 14745 14083 14089 14090 14747 14748 14749 For Power Management (PM) DLLPs (see Figure 3-10 PM Data Link Layer Packet Format ): Transmission is triggered by the component's power management logic according to the rules in Chapter 5 Power Management Checked for integrity on reception by the Data Link Layer, then passed to the component's power management logic 14750 Vendor-specific DLLP (see Figure 3-11 Vendor-specific Data Link Layer Packet Format ) It is recommended that receivers silently ignore Vendor Specific DLLPs unless enabled by implementation specific mechanisms. It is recommended that transmitters not send Vendor Specific DLLPs unless enabled by implementation specific mechanisms. 14091 14092 DataFC[15:4] 14746 Power Management (PM) DLLPs (see Figure 3-10 PM Data Link Layer Packet Format ): Transmission is triggered by the component's power management logic according to the rules in Chapter 5 Power Management Checked for integrity on reception by the Data Link Layer, then passed to the component's power management logic 14087 14088 HdrFC[11:4] 14741 14081 14086 16 14740 14743 14085 HdrFC[7:0] 14738 14080 14084 1 14739 14078 14079 14702 14737 14076 14077 No 14703 14074 14075 14700 14701 14040 14041 00b 14699 14038 14039 14698 14751 14752 14753 For Vendor-specific DLLPs (see Figure 3-11 Vendor-specific Data Link Layer Packet Format ) It is recommended that receivers silently ignore Vendor Specific DLLPs unless enabled by implementation specific mechanisms. It is recommended that transmitters not send Vendor Specific DLLPs unless enabled by implementation specific mechanisms. 14754 NOP DLLP (see Figure 3-6 NOP Data Link Layer Packet Format ) 14755 For NOP DLLPs (see Figure 3-6 NOP Data Link Layer Packet Format ) 14093 Receivers shall discard this DLLP without action after checking it for data integrity. [Footnote: This is a special case of the more general rule for unsupported DLLP Type encodings (see Section 3.6.2.2 Handling of Received DLLPs ).] 14094 14095 14096 14097 Page 14756 Receivers shall discard this DLLP without action after checking it for data integrity. [Footnote: This is a special case of the more general rule for unsupported DLLP Type encodings (see Section 3.6.2.2 Handling of Received DLLPs ).] 14757 Data Link Feature (see Figure 3-12 Data Link Feature DLLP ) The Feature Ack bit is set to indicate that the transmitting Port has received a Data Link Feature DLLP. The Feature Supported bits indicate the features supported by the transmitting Port. These bits equal the value of the Local Data Link Feature Supported field (see Section 7.7.4.2 Data Link Feature Capabilities Register (Offset 04h) ) 232 14758 14759 14760 For Data Link Feature DLLPs (see Figure 3-12 Data Link Feature DLLP Format ) The Feature Ack bit is set to indicate that the transmitting Port has received a Data Link Feature DLLP. The Feature Supported bits indicate the features supported by the transmitting Port. These bits equal the value of the Local Data Link Feature Supported field (see Section 7.7.4.2 Data Link Feature Capabilities Register (Offset 04h) ). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14097 The Feature Supported bits indicate the features 14760 supported by the transmitting Port. These bits equal the value of the Local Data Link Feature Supported field (see Section 7.7.4.2 Data Link Feature Capabilities Register (Offset 04h) ) 14098 14761 14099 14762 14100 14763 14101 14764 14102 The Feature Supported bits indicate the features supported by the transmitting Port. These bits equal the value of the Local Data Link Feature Supported field (see Section 7.7.4.2 Data Link Feature Capabilities Register (Offset 04h) ). 14765 14103 Figure 3-5 Data Link Layer Packet Format for Ack and Nak 14766 14104 14767 14105 14768 14106 14769 14107 14770 14108 14771 14109 14772 Figure 3-5 Data Link Layer Packet Format for Ack and Nak 14110 14111 Figure 3-6 NOP Data Link Layer Packet Format 14773 14112 14774 14113 14775 14114 14776 14115 14777 14116 14778 14117 14779 Figure 3-6 NOP Data Link Layer Packet Format 14118 14119 Figure 3-7 Data Link Layer Packet Format for InitFC1 14780 14120 14781 14121 14782 14122 14783 14123 14784 14124 14785 14125 14786 Figure 3-7 Data Link Layer Packet Format for InitFC1 14126 14127 Figure 3-8 Data Link Layer Packet Format for InitFC2 14787 14128 14788 14129 14789 14130 14790 14131 14791 14132 14792 14133 14793 14134 14794 14135 Figure 3-8 Data Link Layer Packet Format for InitFC2 Figure 3-9 Data Link Layer Packet Format for UpdateFC Figure 3-9 Figure 3-9: Data Link Layer Packet Format for UpdateFC 14136 14795 14137 14796 14138 14797 14139 14798 14140 14141 14799 Figure 3-10 PM Data Link Layer Packet Format 14800 14142 14801 14143 14802 14144 14803 14145 14804 Page 233 Figure 3-10 PM Data Link Layer Packet Format /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14145 14804 14146 14805 14147 Figure 3-11 Vendor-specific Data Link Layer Packet Format 14806 14148 14807 14149 14808 14150 14809 14151 14810 14152 14811 14153 14812 14154 14813 14155 14814 14157 14815 14158 14816 The following are the characteristics and rules associated with Data Link Layer Packets (DLLPs): 14160 14161 14162 14163 14164 14165 14817 The following are the characteristics and rules associated with Data Link Layer Packets (DLLPs): 14818 DLLPs are differentiated from TLPs when they are presented to, or received from, the Physical Layer. DLLP data integrity is protected using a 16-bit CRC The CRC value is calculated using the following rules (see Figure 3-13 Diagram of CRC Calculation for DLLPs ): The polynomial used for CRC calculation has a coefficient expressed as 100Bh The seed value (initial value for CRC storage registers) is FFFFh 14819 14820 14821 14822 14823 14277 14935 14278 14936 14279 DLLPs are differentiated from TLPs when they are presented to, or received from, the Physical Layer. DLLP data integrity is protected using a 16-bit CRC The CRC value is calculated using the following rules (see Figure 3-13 Diagram of CRC Calculation for DLLPs ): The polynomial used for CRC calculation has a coefficient expressed as 100Bh The seed value (initial value for CRC storage registers) is FFFFh 14937 14280 Figure 3-13 Diagram of CRC Calculation for DLLPs 14938 14281 14939 14282 14940 14283 14941 14284 14942 14285 14943 14286 Figure 3-13 Diagram of CRC Calculation for DLLPs 14944 14287 3.6 Data Integrity 14945 14288 14946 14289 14947 14290 3.6 Data Integrity Mechansisms 14948 14291 3.6.1 Introduction 14292 14949 3.6.1 Introduction 14950 14293 14294 Figure 3-12 Data Link Feature DLLP Format Figure 3-12 Data Link Feature DLLP 14156 14159 Figure 3-11 Vendor-specific Data Link Layer Packet Format 14951 The Transaction Layer provides TLP boundary information to the Data Link Layer. This allows the Data Link Layer to apply a TLP Sequence Number and a Link CRC (LCRC) for error detection to the TLP. The Receive Data Link Layer validates received TLPs by checking the TLP Sequence Number, LCRC code and any error indications from the Receive Physical Layer. In case any of these errors are in a TLP, Data Link Layer Retry is used for recovery. Page 234 14952 The Transaction Layer provides TLP boundary information to the Data Link Layer. This allows the Data Link Layer to apply a TLP Sequence Number and a Link CRC (LCRC) for error detection to the TLP. The Receive Data Link Layer validates received TLPs by checking the TLP Sequence Number, LCRC code and any error indications from the Receive Physical Layer. In case any of these errors are in a TLP, Data Link Layer Retry is used for recovery. 14294 14952 The Transaction Layer provides TLP boundary information to the Data Link Layer. This allows the Data Link Layer to apply a TLP Sequence Number and a Link CRC (LCRC) for error detection to the TLP. The Receive Data Link Layer validates received TLPs by checking /private/tmp/PCISIG/pcie4_combined-snapshot.html vs.the TLP Sequence Number, LCRC code and any error indications from the Receive /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html Physical Layer. In case any of these errors are in a TLP, Data Link Layer Retry is used for recovery. 14295 14953 14296 14297 14954 The format of a TLP with the TLP Sequence Number and LCRC code applied is shown in Figure 3-14 TLP with LCRC and TLP Sequence Number Applied . 14307 14955 14966 On Ports that do not support Protocol Multiplexing, Symbol +0, bits 7:4 are Reserved. 14967 14310 14968 14311 14969 14312 14970 14313 3.6.2 LCRC, Sequence Number, and Retry Management (TLP 14972 Transmitter) 14973 14316 14974 The TLP transmission path through the Data Link Layer (paths labeled 1 and 3 in Figure 3-1 Layering Diagram Highlighting the Data Link Layer ) prepares each TLP for transmission by applying a sequence number, then calculating and appending a Link CRC (LCRC) which is used to ensure the integrity of TLPs during transmission across a Link from one component to another. TLPs are stored in a retry buffer, and are re-sent unless a positive acknowledgement of receipt is received from the other component. If repeated attempts to transmit a TLP are unsuccessful, the Transmitter will determine that the Link is not operating correctly, and instruct the Physical Layer to retrain the Link (via the LTSSM Recovery state, Section 4.2.6 Link Training and Status State Rules ). If Link retraining fails, the Physical Layer will indicate that the Link is no longer up, causing the DLCMSM to move to the DL_Inactive state. 14318 14975 14977 The mechanisms used to determine the TLP LCRC and the Sequence Number and to support Data Link Layer Retry are described in terms of conceptual “counters” and “flags”. This description does not imply nor require a particular implementation and is used only to clarify the requirements. 14978 14321 14979 14322 14980 14323 3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter) 14325 14982 3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter) 14983 14326 14984 The following counters and timer are used to explain the remaining rules in this section: 14340 14985 The following counters and timer are used to explain the remaining rules in this section: 14998 14341 14343 The mechanisms used to determine the TLP LCRC and the Sequence Number and to support Data Link Layer Retry are described in terms of conceptual “counters” and “flags”. This description does not imply nor require a particular implementation and is used only to clarify the requirements. 14981 14324 14342 The TLP transmission path through the Data Link Layer (paths labeled 1 and 3 in Figure 3-1 Layering Diagram Highlighting the Data Link Layer ) prepares each TLP for transmission by applying a sequence number, then calculating and appending a Link CRC (LCRC), which is used to ensure the integrity of TLPs during transmission across a Link from one component to another. TLPs are stored in a retry buffer, and are re-sent unless a positive acknowledgement of receipt is received from the other component. If repeated attempts to transmit a TLP are unsuccessful, the Transmitter will determine that the Link is not operating correctly, and will instruct the Physical Layer to retrain the Link (via the LTSSM Recovery state, Section 4.2.6 Link Training and Status State Rules ). If Link retraining fails, the Physical Layer will indicate that the Link is no longer up, causing the DLCMSM to move to the DL_Inactive state. 14976 14319 14327 3.6.2 LCRC, Sequence Number, and Retry Management (TLP Transmitter) 14315 14320 On Ports that do not support Protocol Multiplexing, Symbol +0, bits 7:4 are Reserved. 14971 14314 14317 The format of a TLP with the TLP Sequence Number and LCRC code applied is shown in Figure 3-14 TLP with LCRC and TLP Sequence Number Applied . 14965 14308 14309 The Transaction Layer provides TLP boundary information to the Data Link Layer. This allows the Data Link Layer to apply a TLP Sequence Number and a Link CRC (LCRC) for error detection to the TLP. The Receive Data Link Layer validates received TLPs by checking the TLP Sequence Number, LCRC code and any error indications from the Receive Physical Layer. In case any of these errors are in a TLP, Data Link Layer Retry is used for recovery. 14999 The following timer is used: REPLAY_TIMER - Counts time that determines when a replay is required, according to the following rules: Page 235 15000 15001 The following timer is used: REPLAY_TIMER - Counts time that determines when a replay is required, according to the following rules: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14343 REPLAY_TIMER - Counts time that determines when a replay 14344 14345 14346 14347 is required, according to the following rules: Started at the last Symbol of any TLP transmission or retransmission, if not already running For each replay, reset and restart REPLAY_TIMER when sending the last Symbol of the first TLP to be retransmitted Resets and restarts for each Ack DLLP received while there are more unacknowledged TLPs outstanding, if, and only if, the received Ack DLLP acknowledges some TLP in the retry buffer. Note: This ensures that REPLAY_TIMER is reset only when forward progress is being made 14348 14349 14350 14351 14352 15001 15002 15003 15004 15005 15006 Reset and hold until restart conditions are met for each Nak received (except during a replay) or when the REPLAY_TIMER expires Not advanced during Link retraining (holds its value when the LTSSM is in the Recovery or Configuration state). Refer to Section 4.2.5.3 and Section 4.2.5.4 . 15007 If Protocol Multiplexing is supported, optionally not advanced during the reception of PMUX Packets (see Appendix G Protocol Multiplexing ). Resets and holds when there are no outstanding unacknowledged TLPs 15009 15008 15010 14353 15011 14354 15012 14355 15013 14356 14357 14360 14363 14364 14365 15015 The following rules describe how a TLP is prepared for transmission before being passed to the Physical Layer: 15016 The Transaction Layer indicates the start and end of the TLP to the Data Link Layer while transferring the TLP The Data Link Layer treats the TLP as a “black box” and does not process or modify the contents of the TLP 14361 14362 Reset and hold until restart conditions are met for each Nak received (except during a replay) or when the REPLAY_TIMER expires Not advanced during Link retraining (holds its value when the LTSSM is in the Recovery or Configuration state). Refer to Section 4.2.5.3 Configuration Overview and Section 4.2.5.4 Recovery Overview . If Protocol Multiplexing is supported, optionally not advanced during the reception of PMUX Packets (see Appendix G Protocol Multiplexing ). Resets and holds when there are no outstanding unacknowledged TLPs 15014 The following rules describe how a TLP is prepared for transmission before being passed to the Physical Layer: 14358 14359 REPLAY_TIMER - Counts time that determines when a replay is required, according to the following rules: Started at the last Symbol of any TLP transmission or retransmission, if not already running For each replay, reset and restart REPLAY_TIMER when sending the last Symbol of the first TLP to be retransmitted Resets and restarts for each Ack DLLP received while there are more unacknowledged TLPs outstanding, if, and only if, the received Ack DLLP acknowledges some TLP in the retry buffer. Note: This ensures that REPLAY_TIMER is reset only when forward progress is being made 15017 15018 The Transaction Layer indicates the start and end of the TLP to the Data Link Layer while transferring the TLP The Data Link Layer treats the TLP as a “black box” and does not process or modify the contents of the TLP 15019 Each TLP is assigned a 12-bit sequence number when it is accepted from the Transmit side of Transaction Layer Upon acceptance of the TLP from the Transaction Layer, the packet sequence number is applied to the TLP by: prepending the 12-bit value in NEXT_TRANSMIT_SEQ to the TLP prepending 4 Reserved bits to the TLP, preceding the sequence number (see Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits ) 14366 14367 14370 15021 15022 15023 15025 Page 236 If the equation: 15026 (NEXT_TRANSMIT_SEQ - ACKD_SEQ) mod 4096 >= 2048 15027 (NEXT_TRANSMIT_SEQ - ACKD_SEQ) mod 4096 >= 2048 15028 15029 14371 Each TLP is assigned a 12-bit sequence number when it is accepted from the Transmit side of the Transaction Layer Upon acceptance of the TLP from the Transaction Layer, the packet sequence number is applied to the TLP by: prepending the 12-bit value in NEXT_TRANSMIT_SEQ to the TLP prepending 4 Reserved bits to the TLP, preceding the sequence number (see Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits ) 15024 If the equation: 14368 14369 15020 15030 Equation 3-1 Tx SEQ Stall /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14371 14372 15030 is true, the Transmitter must cease accepting TLPs from the Transaction Layer until the equation is no longer true 14373 15031 14374 15032 15033 is true, the Transmitter must cease accepting TLPs from the Transaction Layer until the equation is no longer true 15034 14375 Following the application of NEXT_TRANSMIT_SEQ to a TLP accepted from the Transmit side of the Transaction Layer, NEXT_TRANSMIT_SEQ is incremented (except in the case where the TLP is nullified): 14376 15035 Following the application of NEXT_TRANSMIT_SEQ to a TLP accepted from the Transmit side of the Transaction Layer, NEXT_TRANSMIT_SEQ is incremented (except in the case where the TLP is nullified): 15036 14377 NEXT_TRANSMIT_SEQ := (NEXT_TRANSMIT_SEQ + 1) mod 4096 15037 14378 NEXT_TRANSMIT_SEQ := (NEXT_TRANSMIT_SEQ + 1) mod 4096 15038 15039 Equation 3-2 Tx SEQ Update 15040 15041 15042 14379 15043 14380 15044 14381 15045 14382 14383 15046 Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits 14384 14387 14388 14389 14390 14391 14392 14393 Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits 15048 14385 14386 15047 15049 TLP data integrity is protected during transfer between Data Link Layers using a 32-bit LCRC The LCRC value is calculated using the following mechanism (see Figure 3-16 Figure 3-16: Calculation of LCRC ): The polynomial used has coefficients expressed as 04C1 1DB7h The seed value (initial value for LCRC storage registers) is FFFF FFFFh The LCRC is calculated using the TLP following sequence number application (see Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits ) LCRC calculation starts with bit 0 of byte 0 (bit 8 of the TLP sequence number) and proceeds from bit 0 to bit 7 of each successive byte. Note that LCRC calculation uses all bits of the TLP, regardless of field type, including Reserved fields The remainder of the LCRC calculation is complemented, and the complemented result bits are mapped into the 32-bit LCRC field as shown in Table 3-6 Mapping of Bits into LCRC Field . 15050 15051 15052 15053 15054 15055 15056 15057 14394 15058 14395 15059 14396 15060 14397 15061 Page 237 TLP data integrity is protected during transfer between Data Link Layers using a 32-bit LCRC The LCRC value is calculated using the following mechanism (see Figure 3-16 Calculation of LCRC ): The polynomial used has coefficients expressed as 04C1 1DB7h The seed value (initial value for LCRC storage registers) is FFFF FFFFh The LCRC is calculated using the TLP following sequence number application (see Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits ) LCRC calculation starts with bit 0 of byte 0 (bit 8 of the TLP sequence number) and proceeds from bit 0 to bit 7 of each successive byte. Note that LCRC calculation uses all bits of the TLP, regardless of field type, including Reserved fields The remainder of the LCRC calculation is complemented, and the complemented result bits are mapped into the 32-bit LCRC field as shown in Table 3-6 Mapping of Bits into LCRC Field . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14397 15061 14592 31 14593 15256 14594 24 15258 14595 15259 14596 15260 14597 15261 14598 15262 14599 15263 14600 15264 14601 14602 15266 15268 14605 Figure 3-16 Figure 3-16: Calculation of LCRC 14606 15269 15270 14607 15272 To support cut-through routing of TLPs, a Transmitter is permitted to modify a transmitted TLP to indicate that the Receiver must ignore that TLP (“nullify” the TLP). 14610 14613 14614 15276 15277 15278 A Transmitter is permitted to nullify a TLP being transmitted. To do this in a way that will robustly prevent misinterpretation or corruption, the Transmitter must do the following: Transmit all DWs of the TLP when the Physical Layer is using 128b/130b encoding (see Section 4.2.2.3.1 Framing Tokens ) Use the remainder of the calculated LCRC value without inversion (the logical inverse of the value normally used) Indicate to the Transmit Physical Layer that the TLP is nullified 15280 When this is done, the Transmitter does not increment NEXT_TRANSMIT_SEQ 15282 The following rules describe the operation of the Data Link Layer Retry Buffer, from which TLPs are re-transmitted when necessary: 14620 15283 The following rules describe the operation of the Data Link Layer Retry Buffer, from which TLPs are re-transmitted when necessary: 15284 Copies of Transmitted TLPs must be stored in the Data Link Layer Retry Buffer, except for nullified TLPs. 14622 15285 Copies of Transmitted TLPs must be stored in the Data Link Layer Retry Buffer, except for nullified TLPs. 15286 14623 14624 15275 15281 14618 14621 To support cut-through routing of TLPs, a Transmitter is permitted to modify a transmitted TLP to indicate that the Receiver must ignore that TLP (“nullify” the TLP). 15279 When this is done, the Transmitter does not increment NEXT_TRANSMIT_SEQ 14617 14619 15273 15274 A Transmitter is permitted to nullify a TLP being transmitted; to do this in a way which will robustly prevent misinterpretation or corruption, the Transmitter must do the following: transmit all DWs of the TLP when the Physical Layer is using 128b/130b encoding (see Section 4.2.2.3.1 Framing Tokens ) use the remainder of the calculated LCRC value without inversion (the logical inverse of the value normally used) indicate to the Transmit Physical Layer that the TLP is nullified 14615 14616 The 32-bit LCRC field is appended to the TLP following the bytes received from the Transaction Layer (see Figure 3-14 TLP with LCRC and TLP Sequence Number Applied ). 15271 14608 14612 Figure 3-16 Calculation of LCRC 15267 14604 14611 24 15265 The 32-bit LCRC field is appended to the TLP following the bytes received from the Transaction Layer (see Figure 3-14 TLP with LCRC and TLP Sequence Number Applied ). 14603 14609 31 15257 15287 When a replay is initiated, either due to reception of a Nak or due to REPLAY_TIMER expiration, the following rules describe the sequence of operations that must be followed: Page 238 15288 When a replay is initiated, either due to reception of a Nak or due to REPLAY_TIMER expiration, the following rules describe the sequence of operations that must be followed: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 14624 When a replay is initiated, either due to reception of a /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html Nak or due to REPLAY_TIMER expiration, the following rules describe the 15288 sequence of operations that must be followed: 14625 14626 14627 14628 15289 If all TLPs transmitted have been acknowledged (the Retry Buffer is empty), terminate replay, otherwise continue. Increment REPLAY_NUM. When the replay is initiated by the reception of a Nak which acknowledged some TLPs in the retry buffer, REPLAY_NUM is reset. It is then permitted (but not required) to be incremented. If REPLAY_NUM rolls over from 11b to 00b, the Transmitter signals the Physical Layer to retrain the Link, and waits for the completion of retraining before proceeding with the replay. This is a reported error associated with the Port (see Section 6.2 Error Signaling and Logging ). 14629 14630 15290 15291 15292 15294 15296 Block acceptance of new TLPs from the Transmit Transaction 15298 Layer. 14635 Complete transmission of any TLP currently being Retransmit unacknowledged TLPs, starting with the oldest unacknowledged TLP and continuing in original transmission order Reset and restart REPLAY_TIMER when sending the last Symbol of the first TLP to be retransmitted 14651 15299 14657 14658 14659 15300 15301 Retransmit unacknowledged TLPs, starting with the oldest unacknowledged TLP and continuing in original transmission order Reset and restart REPLAY_TIMER when sending the last Symbol of the first TLP to be retransmitted 15316 A replay can be initiated by the expiration of REPLAY_TIMER, or by the receipt of a Nak. The following rule covers the expiration of REPLAY_TIMER: 14654 14656 Complete transmission of any TLP currently being transmitted. 15315 14652 14655 Block acceptance of new TLPs from the Transmit Transaction Layer. transmitted. 14653 If REPLAY_NUM does not roll over from 11b to 00b, continue with the replay. 15297 14634 14637 Note that Data Link Layer state, including the contents of the Retry Buffer, are not reset by this action unless the Physical Layer reports Physical LinkUp = 0b (causing the Data Link Control and Management State Machine to transition to the DL_Inactive state). 15295 If REPLAY_NUM does not roll over from 11b to 00b, continue with the replay. 14633 14636 If all TLPs transmitted have been acknowledged (the Retry Buffer is empty), terminate replay, otherwise continue. Increment REPLAY_NUM. When the replay is initiated by the reception of a Nak that acknowledged some TLPs in the retry buffer, REPLAY_NUM is reset. It is then permitted (but not required) to be incremented. If REPLAY_NUM rolls over from 11b to 00b, the Transmitter signals the Physical Layer to retrain the Link, and waits for the completion of retraining before proceeding with the replay. This is a reported error associated with the Port (see Section 6.2 Error Signaling and Logging ). 15293 Note that Data Link Layer state, including the contents of the Retry Buffer, are not reset by this action unless the Physical Layer reports Physical LinkUp = 0b (causing the Data Link Control and Management State Machine to transition to the DL_Inactive state). 14631 14632 When a replay is initiated, either due to reception of a Nak or due to REPLAY_TIMER expiration, the following rules describe the sequence of operations that must be followed: 15317 A replay can be initiated by the expiration of REPLAY_TIMER, or by the receipt of a Nak. The following rule covers the expiration of REPLAY_TIMER: 15318 If the Transmit Retry Buffer contains TLPs for which no Ack or Nak DLLP has been received, and (as indicated by REPLAY_TIMER) no Ack or Nak DLLP has been received for a period exceeding the REPLAY_TIMER Limit, the Transmitter initiates a replay. Simplified REPLAY_TIMER Limits are: A value from 24,000 to 31,000 Symbol Times when the Extended Synch bit is Clear. A value from 80,000 to 100,000 Symbol Times when the Extended Synch bit is Set. If the Extended Synch bit changes state while unacknowledged TLPs are outstanding, implementations are permitted to adjust their REPLAY_TIMER Limit when the Extended Synch bit changes state or the next time the REPLAY_TIMER is reset. 14660 Page 239 15319 15320 15321 15322 15323 15324 If the Transmit Retry Buffer contains TLPs for which no Ack or Nak DLLP has been received, and (as indicated by REPLAY_TIMER) no Ack or Nak DLLP has been received for a period exceeding the REPLAY_TIMER Limit, the Transmitter initiates a replay. Simplified REPLAY_TIMER Limits are: A value from 24,000 to 31,000 Symbol Times when the Extended Synch bit is Clear. A value from 80,000 to 100,000 Symbol Times when the Extended Synch bit is Set. If the Extended Synch bit changes state while unacknowledged TLPs are outstanding, implementations are permitted to adjust their REPLAY_TIMER Limit when the Extended Synch bit changes state or the next time the REPLAY_TIMER is reset. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14660 14661 14662 15324 Implementations that support 16.0 GT/s must use the Simplified REPLAY_TIMER Limits for operation at all data rates. Implementations that only support data rates less than 16.0 GT/s are strongly recommended to use the Simplified REPLAY_TIMER Limits for operation at all data rates, but they are permitted to use the REPLAY_TIMER Limits described in the PCI Express Base Specification, Revision 3.1 . 15325 15326 14663 15327 14664 15328 14665 14666 15329 This is a Replay Timer Timeout error and it is a reported error associated with the Port (see Section 6.2 Error Signaling and Logging ). 15330 14667 15331 14668 15332 14669 Implementation Note Determining REPLAY_TIMER Limit Values 14671 15334 15335 14672 15336 14673 15337 14674 15339 15340 14677 15341 14678 15342 14679 15344 TLP Transmitters and compliance tests must base replay timing as measured at the Port of the TLP Transmitter. Timing starts with either the last Symbol of a transmitted TLP, or else the last Symbol of a received Ack DLLP, whichever determines the oldest unacknowledged TLP. Timing ends with the First Symbol of TLP retransmission. 15345 14682 15346 When measuring replay timing to the point when TLP retransmission begins, compliance tests must allow for any other TLP or DLLP transmission already in progress in that direction (thus preventing the TLP retransmission). 14684 15347 When measuring replay timing to the point when TLP retransmission begins, compliance tests must allow for any other TLP or DLLP transmission already in progress in that direction (thus preventing the TLP retransmission). 15348 14685 14714 Replays are initiated primarily with a Nak DLLP, and the REPLAY_TIMER serves as a secondary mechanism. Since it is a secondary mechanism, the REPLAY_TIMER Limit has a relatively small effect on the average time required to convey a TLP across a Link. The Simplified REPLAY_TIMER Limits have been defined so that no adjustments are required for ASPM L0s, Retimers, or other items as in previous revisions of this specification. 15343 TLP Transmitters and compliance tests must base replay timing as measured at the Port of the TLP Transmitter. Timing starts with either the last Symbol of a transmitted TLP, or else the last Symbol of a received Ack DLLP, whichever determines the oldest unacknowledged TLP. Timing ends with the First Symbol of TLP retransmission. 14681 14683 Implementation Note Determining REPLAY_TIMER Limit Values 15338 Replays are initiated primarily with a Nak DLLP, and the REPLAY_TIMER serves as a secondary mechanism. Since it is a secondary mechanism, the REPLAY_TIMER Limit has a relatively small effect on the average time required to convey a TLP across a Link. The Simplified REPLAY_TIMER Limits have been defined so that no adjustments are required for ASPM L0s, Retimers, or other items as in previous revisions of the PCI Express Base Specification. 14676 14680 This is a Replay Timer Timeout error and it is a reported error associated with the Port (see Section 6.2 Error Signaling and Logging ). 15333 14670 14675 Implementations that support 16.0 GT/s or higher data rates must use the Simplified REPLAY_TIMER Limits for operation at all data rates. Implementations that only support data rates less than 16.0 GT/s are strongly recommended to use the Simplified REPLAY_TIMER Limits for operation at all data rates, but they are permitted to use the REPLAY_TIMER Limits described in the [PCIe-3.1]. 15349 Since Ack/Nak and Flow Control DLLPs affect TLPs flowing in the opposite direction across the Link, the TLP transmission mechanisms in the Data Link Layer are also responsible for Ack/Nak and Flow Control DLLPs received from the other component on the Link. These DLLPs are processed according to the following rules (see Figure 3-17 Received DLLP Error Check Flowchart ): Page 240 15378 Since Ack/Nak and Flow Control DLLPs affect TLPs flowing in the opposite direction across the Link, the TLP transmission mechanisms in the Data Link Layer are also responsible for Ack/Nak and Flow Control DLLPs received from the other component on the Link. These DLLPs are processed according to the following rules (see Figure 3-17 Received DLLP Error Check Flowchart ): 14714 Since Ack/Nak and Flow Control DLLPs affect TLPs flowing in 15378 the opposite direction across the Link, the TLP transmission /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. mechanisms in the Data Link Layer are also responsible for Ack/Nak and Flow Control /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html DLLPs received from the other component on the Link. These DLLPs are processed according to the following rules (see Figure 3-17 Received DLLP Error Check Flowchart ): 14715 14716 14717 14718 14719 14720 15379 If the Physical Layer indicates a Receiver Error, discard any DLLP currently being received and free any storage allocated for the DLLP. Note that reporting such errors to software is done by the Physical Layer (and, therefore, are not reported by the Data Link Layer). For all received DLLPs, the CRC value is checked by: applying the same algorithm used for calculation of transmitted DLLPs to the received DLLP, not including the 16-bit CRC field of the received DLLP comparing the calculated result with the value in the CRC field of the received DLLP if not equal, the DLLP is corrupt 14721 14722 14725 14726 15380 15381 15382 15383 15384 15386 15388 15389 15390 15391 14728 15392 14729 15393 14730 Figure 3-17 Received DLLP Error Check Flowchart 14732 14737 14738 14739 Figure 3-17 Received DLLP Error Check Flowchart 15397 Received NOP DLLPs are discarded Received FC DLLPs are passed to the Transaction Layer Received PM DLLPs are passed to the component's power management control logic For Ack and Nak DLLPs, the following steps are followed (see Figure 3-18 Ack/Nak DLLP Processing Flowchart ): If the Sequence Number specified by the AckNak_Seq_Num does not correspond to an unacknowledged TLP, or to the value in ACKD_SEQ, the DLLP is discarded This is a Data Link Protocol Error which is a reported error associated with the Port (see Section 6.2 Error Signaling and Logging ). 14740 14741 15395 15396 14733 14736 A received DLLP that is not corrupt, but that uses unsupported DLLP Type encodings is discarded without further action. This is not considered an error. Non-zero values in Reserved fields are ignored. Receivers must process all DLLPs received at the rate they are received 15394 14731 14735 A corrupt received DLLP is discarded. This is a Bad DLLP error and is a reported error associated with the Port (see Section 6.2 Error Signaling and Logging ). 15387 A received DLLP which is not corrupt, but which uses unsupported DLLP Type encodings is discarded without further action. This is not considered an error. Non-zero values in Reserved fields are ignored. Receivers must process all DLLPs received at the rate they are received 14727 14734 If the Physical Layer indicates a Receiver Error, discard any DLLP currently being received and free any storage allocated for the DLLP. Note that reporting such errors to software is done by the Physical Layer (and, therefore, are not reported by the Data Link Layer). For all received DLLPs, the CRC value is checked by: Applying the same algorithm used for calculation of transmitted DLLPs to the received DLLP, not including the 16-bit CRC field of the received DLLP Comparing the calculated result with the value in the CRC field of the received DLLP If not equal, the DLLP is corrupt 15385 A corrupt received DLLP is discarded. This is a Bad DLLP error and is a reported error associated with the Port (see Section 6.2 Error Signaling and Logging ). 14723 14724 Since Ack/Nak and Flow Control DLLPs affect TLPs flowing in the opposite direction across the Link, the TLP transmission mechanisms in the Data Link Layer are also responsible for Ack/Nak and Flow Control DLLPs received from the other component on the Link. These DLLPs are processed according to the following rules (see Figure 3-17 Received DLLP Error Check Flowchart ): 15398 15399 15400 15401 15402 15403 Received NOP DLLPs are discarded Received FC DLLPs are passed to the Transaction Layer Received PM DLLPs are passed to the component's power management control logic For Ack and Nak DLLPs, the following steps are followed (see Figure 3-18 Ack/Nak DLLP Processing Flowchart ): If the Sequence Number specified by the AckNak_Seq_Num does not correspond to an unacknowledged TLP, or to the value in ACKD_SEQ, the DLLP is discarded This is a Data Link Protocol Error, which is a reported error associated with the Port (see Section 6.2 Error Signaling and Logging ). 15404 Note that it is not an error to receive an Ack DLLP when there are no outstanding unacknowledged TLPs, including the time between reset and the first TLP transmission, as long as the specified Sequence Number matches the value in ACKD_SEQ. 15405 14742 15406 14743 15407 Page 241 Note that it is not an error to receive an Ack DLLP when there are no outstanding unacknowledged TLPs, including the time between reset and the first TLP transmission, as long as the specified Sequence Number matches the value in ACKD_SEQ. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 14743 14744 14745 14746 14747 15407 If the AckNak_Seq_Num does not specify the Sequence Number of the most recently acknowledged TLP, then the DLLP acknowledges some TLPs in the retry buffer: Purge from the retry buffer all TLPs from the oldest to the one corresponding to the AckNak_Seq_Num Load ACKD_SEQ with the value in the AckNak_Seq_Num field Reset REPLAY_NUM and REPLAY_TIMER 14748 14749 15408 15409 15410 15411 15412 If the DLLP is a Nak, initiate a replay (see above) 15413 14868 15532 14869 15533 14870 15534 14871 14872 14877 14878 14879 14880 14881 14882 14883 14886 15540 15541 15542 15543 15544 15545 15546 15547 A TLP Receiver must schedule an Ack DLLP such that it will be transmitted no later than when all of the following conditions are true: The Data Link Control and Management State Machine is in the DL_Active state TLPs have been forwarded to the Receive Transaction Layer, but not yet acknowledged by sending an Ack DLLP The AckNak_LATENCY_TIMER reaches or exceeds the value specified in Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol Times) for 2.5 GT/s mode operation, Table 3-8 Maximum Ack Latency Limits for 5.0 GT/s (Symbol Times) for 5.0 GT/s mode operation, Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s and higher data rates (Symbol Times) for 8.0 GT/s and higher mode operation The Link used for Ack DLLP transmission is already in L0 or has transitioned to L0 Note: if not already in L0, the Link must transition to L0 in order to transmit the Ack DLLP Another TLP or DLLP is not currently being transmitted on the Link used for Ack DLLP transmission The NAK_SCHEDULED flag is clear Note: The AckNak_LATENCY_TIMER must be restarted from 0 each time an Ack or Nak DLLP is scheduled for transmission 15549 15550 Data Link Layer Ack DLLPs may be scheduled for transmission more frequently than required Data Link Layer Ack and Nak DLLPs specify the value (NEXT_RCV_SEQ - 1) in the AckNak_Seq_Num field 15551 14888 Page 15539 15548 Data Link Layer Ack DLLPs may be scheduled for transmission more frequently than required Data Link Layer Ack and Nak DLLPs specify the value (NEXT_RCV_SEQ - 1) in the AckNak_Seq_Num field 14887 14889 Figure 3-19 Receive Data Link Layer Handling of TLPs 15538 A TLP Receiver must schedule an Ack DLLP such that it will be transmitted no later than when all of the following conditions are true: The Data Link Control and Management State Machine is in the DL_Active state TLPs have been forwarded to the Receive Transaction Layer, but not yet acknowledged by sending an Ack DLLP The AckNak_LATENCY_TIMER reaches or exceeds the value specified in Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol Times) for 2.5 GT/s mode operation, Table 3-8 Maximum Ack Latency Limits for 5.0 GT/s (Symbol Times) for 5.0 GT/s mode operation, Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s (Symbol Times) for 8.0 GT/s mode operation, and Table 3-10 Maximum Ack Latency Limits for 16.0 GT/s (Symbol Times) for 16.0 GT/s mode operation The Link used for Ack DLLP transmission is already in L0 or has transitioned to L0 Note: if not already in L0, the Link must transition to L0 in order to transmit the Ack DLLP Another TLP or DLLP is not currently being transmitted on the Link used for Ack DLLP transmission The NAK_SCHEDULED flag is clear Note: The AckNak_LATENCY_TIMER must be restarted from 0 each time an Ack or Nak DLLP is scheduled for transmission 14884 14885 15536 15537 14874 14876 If the DLLP is a Nak, initiate a replay (see above) 15535 Figure 3-19 Receive Data Link Layer Handling of TLPs 14873 14875 If the AckNak_Seq_Num does not specify the Sequence Number of the most recently acknowledged TLP, then the DLLP acknowledges some TLPs in the retry buffer: Purge from the retry buffer all TLPs from the oldest to the one corresponding to the AckNak_Seq_Num Load ACKD_SEQ with the value in the AckNak_Seq_Num field Reset REPLAY_NUM and REPLAY_TIMER 15552 Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol Times) , Table 3-8 Maximum Ack Latency Limits for 5.0 GT/s (Symbol Times) , and Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s (Symbol Times) , and Table 3-10 Maximum Ack Latency Limits for 16.0 GT/s (Symbol Times) define the threshold values for the AckNak_LATENCY_TIMER, which for any specific case is called the Ack Latency Limit. 242 15553 Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol Times) , Table 3-8 Maximum Ack Latency Limits for 5.0 GT/s (Symbol Times) , and Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s and higher data rates (Symbol Times) define the threshold values for the AckNak_LATENCY_TIMER, which for any specific case is called the Ack Latency Limit. Table 3-7 Maximum Ack Latency Limits for 2.5vs. GT/s (Symbol /private/tmp/PCISIG/pcie4_combined-snapshot.html Times) , Table 3-8 Maximum Ack Latency Limits for 5.0 GT/s (Symbol Times) /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html , and Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s (Symbol Times) , 14889 15553 and Table 3-10 Maximum Ack Latency Limits for 16.0 GT/s (Symbol Times) define the threshold values for the AckNak_LATENCY_TIMER, which for any specific case is called the Ack Latency Limit. 14890 15554 14891 14892 15555 TLP Receivers and compliance tests must base Ack Latency timing as measured at the Port of the TLP Receiver, starting with the time the last Symbol of a TLP is received to the first Symbol of the Ack DLLP being transmitted. 14893 TLP Receivers and compliance tests must base Ack Latency timing as measured at the Port of the TLP Receiver, starting with the time the last Symbol of a TLP is received to the first Symbol of the Ack DLLP being transmitted. 15558 When measuring until the Ack DLLP is transmitted, compliance tests must allow for any TLP or other DLLP transmission already in progress in that direction (thus preventing the Ack DLLP transmission). If L0s is enabled, compliance tests must allow for the L0s exit latency of the Link in the direction that the Ack DLLP is being transmitted. If the Extended Synch bit of the Link Control register is Set, compliance tests must also allow for its effect on L0s exit latency. 14896 15559 When measuring until the Ack DLLP is transmitted, compliance tests must allow for any TLP or other DLLP transmission already in progress in that direction (thus preventing the Ack DLLP transmission). If L0s is enabled, compliance tests must allow for the L0s exit latency of the Link in the direction that the Ack DLLP is being transmitted. If the Extended Synch bit of the Link Control register is Set, compliance tests must also allow for its effect on L0s exit latency. 15560 14897 14898 15556 15557 14894 14895 Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol Times) , Table 3-8 Maximum Ack Latency Limits for 5.0 GT/s (Symbol Times) , and Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s and higher data rates (Symbol Times) define the threshold values for the AckNak_LATENCY_TIMER, which for any specific case is called the Ack Latency Limit. 15561 TLP Receivers are not required to adjust their Ack DLLP scheduling based upon L0s exit latency or the value of the Extended Synch bit. 14899 15562 TLP Receivers are not required to adjust their Ack DLLP scheduling based upon L0s exit latency or the value of the Extended Synch bit. 15563 15164 15828 15165 585 15166 15829 585 15830 15167 327 15831 15168 15832 15169 15833 15170 15834 15171 15835 15172 15836 15173 327 15837 15174 Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s (Symbol Times) 15175 15176 Link Operating Width 15177 15178 15179 15180 x1 15181 15182 x2 15183 15184 x4 15185 15186 x8 15187 15188 Page 243 x12 15838 Table 3-9 Maximum Ack Latency Limits for 8.0 GT/s and higher data rates (Symbol Times) /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 15188 x12 15189 15190 x16 15191 15192 x32 15193 15194 15195 15196 15197 Max_Payload_Size (bytes) 15198 15199 128 15200 15201 333 15202 15203 224 15204 15205 169 15206 15207 163 15208 15209 154 15210 15211 144 15212 15213 129 15214 15215 15216 15217 256 15218 15219 512 15220 15221 313 15222 15223 214 15224 15225 203 15226 15227 186 15228 15229 168 15230 15231 141 15232 15233 15234 15235 512 15236 15237 15238 Page 244 655 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 15238 15239 385 15240 15241 250 15242 15243 182 15244 15245 205 15246 15247 182 15248 15249 148 15250 15251 15252 15253 1024 15254 15255 1167 15256 15257 641 15258 15259 378 15260 15261 246 15262 15263 290 15264 15265 246 15266 15267 180 15268 15269 15270 15271 2048 15272 15273 2191 15274 15275 1153 15276 15277 634 15278 15279 374 15280 15281 461 15282 15283 374 15284 15285 244 15286 15287 15288 15289 Page 245 4096 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 15289 4096 15290 15291 4239 15292 15293 2177 15294 15295 1146 15296 15297 630 15298 15299 802 15300 15301 630 15302 15303 372 15304 15305 15306 15307 15308 15309 15310 Table 3-10 Maximum Ack Latency Limits for 16.0 GT/s (Symbol Times) 15311 15312 15839 Link Operating Width 15840 15313 15841 15314 15842 15315 15316 15843 x1 15317 15318 x2 15846 x4 15848 The Physical Layer isolates the Transaction and Data Link Layers from the signaling technology used for Link data interchange. The Physical Layer is divided into the logical and electrical sub-blocks (see Figure 4-1 Layering Diagram Highlighting Physical Layer ). 16017 16018 15491 16019 15492 16020 15493 16022 16023 15496 16024 15497 Page x4 The Physical Layer isolates the Transaction and Data Link Layers from the signaling technology used for Link data interchange. The Physical Layer is divided into the logical and electrical sub-blocks (see Figure 4-1 Layering Diagram Highlighting Physical Layer ). 16021 Figure 4-1 Layering Diagram Highlighting Physical Layer 15495 15498 x2 16016 15490 15494 x1 15847 15488 15489 15844 15845 15319 15320 Link Operating Width Figure 4-1 Layering Diagram Highlighting Physical Layer 16025 Chapter 4 Physical Layer Logical Block describes the logical sub-block and Chapter 9 Single Root I/O Virtualization and Sharing describes the electrical sub-block. [Footnote: Prior to the PCI Express Base Specification, Revision 4.0, Chapter 4 Physical Layer Logical Block described both logical and electrical sub-blocks. With PCI Express Base Specification, Revision 4.0 the following reorganization occurred:Missing 246 text.] 16026 Chapter 4 Physical Layer Logical Block describes the logical sub-block and Chapter 8 Electrical Sub-Block describes the electrical sub-block. [Footnote: Prior to [PCIe-4.0] Chapter 4 Physical Layer Logical Block described both logical and electrical sub-blocks. With [PCIe-4.0], section 4.3 was moved to a new Chapter 8 Electrical Sub-Block and a new section 4.3 was added containing Retimer information.] Chapter 4 Physical Layer Logical Block describesvs. the logical /private/tmp/PCISIG/pcie4_combined-snapshot.html sub-block and Chapter 9 Single Root I/O Virtualization and Sharing /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html describes the electrical sub-block. [Footnote: Prior to the PCI Express 15498 16026 Base Specification, Revision 4.0, Chapter 4 Physical Layer Logical Block described both logical and electrical sub-blocks. With PCI Express Base Specification, Revision 4.0 the following reorganization occurred:Missing text.] 15499 16027 15500 16028 15501 16029 15502 16030 15503 4.2 Logical Sub-block 15504 16031 16033 The logical sub-block has two main sections: a Transmit section that prepares outgoing information passed from the Data Link Layer for transmission by the electrical sub-block, and a Receiver section that identifies and prepares received information before passing it to the Data Link Layer. 16034 15507 16035 15508 16036 15546 Figure 4-4 Bit Transmission Order on Physical Lanes - 16075 x4 Example Figure 4-4 Bit Transmission Order on Physical Lanes x4 Example 15548 16076 15549 16077 15550 16078 15551 16079 15552 16080 15553 4.2.1.1.2 Special Symbols for Framing and Link Management 16081 (K Codes) 4.2.1.1.2 Special Symbols for Framing and Link Management (K Codes) 15554 16082 15555 16083 The 8b/10b encoding scheme provides Special Symbols that are distinct from the Data Symbols used to represent Characters. These Special Symbols are used for various Link Management mechanisms described later in this chapter. Special Symbols are also used to frame DLLPs and TLP [Footnote: In Chapter 4 Physical Layer Logical Block , PMUX packets follow the TLP framing rules.] s, using distinct Special Symbols to allow these two types of Packets to be quickly and easily distinguished. 15557 16084 The 8b/10b encoding scheme provides Special Symbols that are distinct from the Data Symbols used to represent Characters. These Special Symbols are used for various Link Management mechanisms described later in this chapter. Special Symbols are also used to frame DLLPs and TLPs [Footnote: In Chapter 4 Physical Layer Logical Block , PMUX packets follow the TLP framing rules.] , using distinct Special Symbols to allow these two types of Packets to be quickly and easily distinguished. 16085 15558 15559 The logical sub-block has two main sections: a Transmit section that prepares outgoing information passed from the Data Link Layer for transmission by the electrical sub-block, and a Receiver section that identifies and prepares received information before passing it to the Data Link Layer. 16074 15547 15556 4.2 Logical Sub-block 16032 15505 15506 Chapter 4 Physical Layer Logical Block describes the logical sub-block and Chapter 8 Electrical Sub-Block describes the electrical sub-block. [Footnote: Prior to [PCIe-4.0] Chapter 4 Physical Layer Logical Block described both logical and electrical sub-blocks. With [PCIe-4.0], section 4.3 was moved to a new Chapter 8 Electrical Sub-Block and a new section 4.3 was added containing Retimer information.] 16086 Table 4-1 shows the Special Symbols used for PCI Express and provides a brief description for each. These Symbols will be discussed in greater detail in following sections. Each of these Special Symbols, as well as the data Symbols, must be interpreted by looking at the 10-bit Symbol in its entirety. 16087 for PCI will be Special looking 15560 16088 15561 16089 15562 15563 16090 Table 4-1 Special Symbols 15564 15565 15566 Page 247 Table 4-1 Special Symbols shows the Special Symbols used Express and provides a brief description for each. These Symbols discussed in greater detail in following sections. Each of these Symbols, as well as the data Symbols, must be interpreted by at the 10-bit Symbol in its entirety. 16091 Table 4-1 Special Symbols 16092 Encoding 16093 16094 Encoding /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 15566 16094 15567 Symbol 15568 16095 15569 Name 16097 15827 16355 15828 16356 15829 16357 15830 15831 Symbol 16096 Name 16358 For more information on scrambling, see Appendix C Physical Layer Appendix . 16359 15832 16360 15833 16361 15834 16362 15835 16363 15836 16364 For more information on scrambling, see Appendix C Physical Layer Appendix . 15837 15838 Figure 4-10 LFSR with 8b/10b Scrambling Polynomial 16365 15839 16366 15840 16367 15841 16368 15842 16369 15843 16370 15844 16371 15845 4.2.2 Encoding for 8.0 GT/s and Higher Data Rates 16372 15846 16373 15847 16374 15900 16427 15901 4.2.2.2.1 Block Alignment 15903 16429 4.2.2.2.1 Block Alignment 16430 15904 16431 During Link training, the 130 bits of the Electrical Idle Exit Ordered Set (EIEOS) are a unique bit pattern that Receivers use to determine the location of the Block Sync Headers in the received bit stream. Conceptually, Receivers can be in three different phases of Block alignment: Unaligned, Aligned, and Locked. These phases are defined to illustrate the required behavior, but are not meant to specify a required implementation. 15906 16432 During Link training, the 130 bits of the Electrical Idle Exit Ordered Set (EIEOS) are a unique bit pattern that Receivers use to determine the location of the Block Sync Headers in the received bit stream. Conceptually, Receivers can be in three different phases of Block alignment: Unaligned, Aligned, and Locked. These phases are defined to illustrate the required behavior, but are not meant to specify a required implementation. 16433 15907 16434 15908 Unaligned Phase 15909 15910 4.2.2 Encoding for 8.0 GT/s and Higher Data Rates 16428 15902 15905 Figure 4-10 LFSR with 8b/10b Scrambling Polynomial 16435 Unaligned Phase 16436 Receivers enter this phase after a period of Electrical Idle, such as when the data rate is changed to one that uses 128b/130b encoding or when they exit a low-power Link state, or if directed . In this phase, Receivers monitor the received bit stream for the EIEOS bit pattern. When one is detected, they adjust their alignment to it and proceed to the Aligned phase. 15911 15912 15913 Page 248 16437 Receivers enter this phase after a period of Electrical Idle, such as when the data rate is changed to one that uses 128b/130b encoding or when they exit a low-power Link state, or if directed (by an implementation specific method). In this phase, Receivers monitor the received bit stream for the EIEOS bit pattern. When one is detected, they adjust their alignment to it and proceed to the Aligned phase. 16438 Aligned Phase 16439 16440 Aligned Phase /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 15913 15914 16440 Receivers monitor the received bit stream for the EIEOS bit pattern and the received Blocks for a Start of Data Stream (SDS) Ordered Set. If an EIEOS bit pattern is detected on an alignment that does not match the current alignment, Receivers must adjust their alignment to the newly received EIEOS bit pattern. If an SDS Ordered Set is received, Receivers proceed to the Locked phase. Receivers are permitted to return to the Unaligned phase if an undefined Sync Header (00b or 11b) is received. 15915 Locked Phase 15917 16443 Receivers must not adjust their Block alignment while in this phase. Data Blocks are expected to be received after an SDS Ordered Set, and adjusting the Block alignment would interfere with the processing of these Blocks. Receivers must return to the Unaligned or Aligned phase if an undefined Sync Header is received. 16445 16446 15920 16447 15926 16454 16455 15929 16456 15930 16457 15931 Additional Requirements: 15933 15936 The sequence of EIEOS and TS Ordered Sets transmitted during training sequences will cause misaligned Receivers to detect an undefined Sync Header. 16458 15932 15935 Receivers must not adjust their Block alignment while in this phase. Data Blocks are expected to be received after an SDS Ordered Set, and adjusting the Block alignment would interfere with the processing of these Blocks. Receivers must return to the Unaligned or Aligned phase if an undefined Sync Header is received. 16453 The sequence of EIEOS and TS Ordered Sets transmitted during training sequences will cause misaligned Receivers to detect an undefined Sync Header. 15928 15934 Locked Phase 16444 15919 15927 Receivers monitor the received bit stream for the EIEOS bit pattern and the received Blocks for a Start of Data Stream (SDS) Ordered Set. If an EIEOS bit pattern is detected on an alignment that does not match the current alignment, Receivers must adjust their alignment to the newly received EIEOS bit pattern. If an SDS Ordered Set is received, Receivers proceed to the Locked phase. Receivers are permitted to return to the Unaligned phase if an undefined Sync Header (00b or 11b) is received. 16442 15916 15918 16441 16459 Additional Requirements: 16460 While in the Aligned or Locked phase, Receivers must adjust their alignment as necessary when a SKP Ordered Set is received. See Section 4.2.7 Clock Tolerance Compensation for more information on SKP Ordered Sets. After any LTSSM transition to Recovery, Receivers must ignore all received TS Ordered Sets until they receive an EIEOS. Conceptually, receiving an EIEOS validates the Receiver’s alignment and allows TS Ordered Set processing to proceed. If a received EIEOS initiates an LTSSM transition from L0 to Recovery, Receivers are permitted to process any TS Ordered Sets that follow the EIEOS or ignore them until another EIEOS is received after entering Recovery. Receivers are permitted to be directed from the Locked phase to the Unaligned or Aligned phase as long as Data Stream processing is stopped. See Section 4.2.2.3 Data Blocks for more information on Data Stream requirements. 16461 16462 16463 While in the Aligned or Locked phase, Receivers must adjust their alignment as necessary when a SKP Ordered Set is received. See Section 4.2.7 Clock Tolerance Compensation for more information on SKP Ordered Sets. After any LTSSM transition to Recovery, Receivers must ignore all received TS Ordered Sets until they receive an EIEOS. Conceptually, receiving an EIEOS validates the Receiver’s alignment and allows TS Ordered Set processing to proceed. If a received EIEOS initiates an LTSSM transition from L0 to Recovery, Receivers are permitted to process any TS Ordered Sets that follow the EIEOS or ignore them until another EIEOS is received after entering Recovery. Receivers are permitted to transition from the Locked phase to the Unaligned or Aligned phase as long as Data Stream processing is stopped. See Section 4.2.2.3 Data Blocks for more information on Data Stream requirements. 16464 15937 Loopback Masters: While in Loopback.Entry, Masters must be capable of adjusting their Receiver’s Block alignment to received EIEOS bit patterns. While in Loopback.Active, Masters are permitted to transmit an EIEOS and adjust their Receiver’s Block alignment to the looped back bit stream. 16465 16466 Page 249 Loopback Masters: While in Loopback.Entry, Masters must be capable of adjusting their Receiver’s Block alignment to received EIEOS bit patterns. While in Loopback.Active, Masters are permitted to transmit an EIEOS and adjust their Receiver’s Block alignment to the looped back bit stream. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16466 15938 Loopback Slaves: While in Loopback.Entry, Slaves must be capable of adjusting their Receiver’s Block alignment to received EIEOS bit patterns. While in Loopback.Active, Slaves must not adjust their Receiver’s Block alignment. Conceptually, the Receiver is directed to the Locked phase when the Slave starts to loop back the received bit stream. 16467 15939 15940 16468 15941 16469 15942 16470 15943 16471 15944 4.2.2.3 Data Blocks 16472 15945 16473 15946 16474 15947 16137 16138 16139 16140 The payload of Data Blocks is a stream of Symbols defined as a “Data Stream” that consists of Framing Tokens, TLPs, and DLLPs. Each Symbol of the Data Stream is placed on a single Lane of the Link, and the stream of Symbols is striped across all Lanes of the Link and spans Block boundaries. All optional error checks and error reports in this section are independently optional (see Section 6.2.3.4 Optional Error Checking ). When an STP Token is received: Receivers must calculate the Frame CRC and Frame Parity of the received TLP Length field and compare the results to the received Frame CRC and Frame Parity fields. A Frame CRC or Frame Parity mismatch is a Framing Error. An STP Token with Framing Error is not considered part of a TLP for the purpose of reporting to the Data Link Layer. 16143 16144 16145 16146 16147 16476 The payload of Data Blocks is a stream of Symbols defined as a “Data Stream” that consists of Framing Tokens, TLPs, and DLLPs. Each Symbol of the Data Stream is placed on a single Lane of the Link, and the stream of Symbols is striped across all Lanes of the Link and spans Block boundaries. 16666 All optional error checks and error reports in this section are independently optional (see Section 6.2.3.4 Optional Error Checking ). When an STP Token is received: Receivers must calculate the Frame CRC and Frame Parity of the received TLP Length field and compare the results to the received Frame CRC and Frame Parity fields. A Frame CRC or Frame Parity mismatch is a Framing Error. An STP Token with Framing Error is not considered part of a TLP for the purpose of reporting to the Data Link Layer. 16667 16668 16669 If the TLP Length field is 1, the Symbols are not an STP Token and are instead evaluated to determine whether they are an EDS Token. Receivers are permitted to check whether the TLP Length field has a value of 0. If checked, receiving a TLP Length field of 0 is a Framing Error. Receivers are permitted to check whether the TLP Length field has a value of 2, 3, or 4. If checked, receiving such a TLP Length field is a Framing Error. Receivers are permitted to check whether the TLP Length field has a value between 1152 and 1535 (inclusive). If checked, receiving such a TLP Length field is a Framing Error. Receivers on Ports that do not support Protocol Multiplexing are permitted to check whether the TLP Length field has a value greater than 1535. If checked, receiving such a TLP Length field is a Framing Error. 16670 Receivers on Ports that support Protocol Multiplexing, shall process STP Tokens with a TLP Length field that is greater than 1535 as the start of a PMUX Packet as defined in Appendix G. 16676 Page 250 4.2.2.3 Data Blocks 16475 16141 16142 Loopback Slaves: While in Loopback.Entry, Slaves must be capable of adjusting their Receiver’s Block alignment to received EIEOS bit patterns. While in Loopback.Active, Slaves must not adjust their Receiver’s Block alignment. Conceptually, the Receiver is directed to the Locked phase when the Slave starts to loop back the received bit stream. 16671 16672 16673 16674 16675 If the TLP Length field is 1, the Symbols are not an STP Token and are instead evaluated to determine whether they are an EDS Token. Receivers are permitted to check whether the TLP Length field has a value of 0. If checked, receiving a TLP Length field of 0 is a Framing Error. Receivers are permitted to check whether the TLP Length field has a value of 2, 3, or 4. If checked, receiving such a TLP Length field is a Framing Error. Receivers are permitted to check whether the TLP Length field has a value between 1152 and 1535 (inclusive). If checked, receiving such a TLP Length field is a Framing Error. Receivers on Ports that do not support Protocol Multiplexing are permitted to check whether the TLP Length field has a value greater than 1535. If checked, receiving such a TLP Length field is a Framing Error. Receivers on Ports that support Protocol Multiplexing, shall process STP Tokens with a TLP Length field that is greater than 1535 as the start of a PMUX Packet as defined in Appendix G Protocol Multiplexing . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. Receivers on Ports that support Protocol Multiplexing, shall process STP Tokens with a TLP Length field that is /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html greater than 1535 as the start of a PMUX Packet as defined in Appendix 16147 16676 G. 16148 16149 The Symbol immediately following the last DW of the TLP is the next Token to be processed. Receivers must evaluate the Symbol immediately following the last DW of the TLP and determine whether it is the first Symbol of an EDB Token and therefore whether the TLP is nullified. See the EDB Token requirements. 16677 16678 Receivers on Ports that support Protocol Multiplexing, shall process STP Tokens with a TLP Length field that is greater than 1535 as the start of a PMUX Packet as defined in Appendix G Protocol Multiplexing . The next Token to be processed begins with the Symbol immediately following the last DW of the TLP, as determined by the TLP Length field. Receivers must evaluate this Symbol and determine whether it is the first Symbol of an EDB Token and therefore whether the TLP is nullified. See the EDB Token requirements. 16679 16150 Receivers are permitted to check whether more than one STP Token is received in a single Symbol Time. If checked, receiving more than one STP Token in a single Symbol Time is a Framing Error 16151 16152 16153 16154 16155 16158 16159 16160 16163 16164 16167 16168 Page 16683 16684 16685 When an EDB Token is received: If an EDB Token is received immediately following a TLP (there are no Symbols between the last Symbol of the TLP and the first Symbol of the EDB Token), receivers must inform the Data Link Layer that an EDB Token has been received. Receivers are permitted to inform the Data Link Layer that an EDB Token has been received after processing the first Symbol of the EDB Token or after processing any or all of the remaining Symbols of the EDB Token. Regardless of when they inform the Data Link Layer of a received EDB Token, Receivers must check all Symbols of the EDB Token. Receiving a Symbol that does not match the definition of an EDB Token is a Framing Error. Receiving an EDB Token at any time other than immediately following a TLP is a Framing Error. The next Token to be processed begins with the Symbol immediately following the EDB Token . 16687 16688 16689 16690 When an EDS Token is received in the last four Symbols of the Data Block across the Link: Receivers must stop processing the Data Stream. Receiving an Ordered Set other than SKP, EIOS, or EIEOS in the Block following the EDS Token is a Framing Error. If a SKP Ordered Set is received in the Block following the EDS Token, Receivers resume Data Stream processing with the first Symbol of the Data Block that follows the SKP Ordered Set unless a Framing Error has been detected. 16691 When an SDP Token is received: The Symbol immediately following the last Symbol of the DLLP is the next Token to be processed. Receivers are permitted to check whether more than one SDP Token is received in a single Symbol Time. If checked, receiving more than one SDP Token in a single Symbol Time is a Framing Error. 16165 16166 16682 16686 When an EDS Token is received in the last four Symbols of the Data Block across the Link: Receivers must stop processing the Data Stream. Receiving an Ordered Set other than SKP, EIOS, or EIEOS in the Block following the EDS Token is a Framing Error. If a SKP Ordered Set is received in the Block following the EDS Token, Receivers resume Data Stream processing with the first Symbol of the Data Block that follows the SKP Ordered Set unless a Framing Error has been detected. 16161 16162 Receivers are permitted to check whether more than one STP Token is received in a single Symbol Time. If checked, receiving more than one STP Token in a single Symbol Time is a Framing Error 16681 When an EDB Token is received: If an EDB Token is received immediately following a TLP (there are no Symbols between the last Symbol of the TLP and the first Symbol of the EDB Token), receivers must inform the Data Link Layer that an EDB Token has been received. Receivers are permitted to inform the Data Link Layer that an EDB Token has been received after processing the first Symbol of the EDB Token or after processing any or all of the remaining Symbols of the EDB Token. Regardless of when they inform the Data Link Layer of a received EDB Token, Receivers must check all Symbols of the EDB Token. Receiving a Symbol that does not match the definition of an EDB Token is a Framing Error. Receiving an EDB Token at any time other than immediately following a TLP is a Framing Error. The Symbol immediately following the EDB Token is the next Token to be processed. 16156 16157 16680 16692 16693 16694 When an SDP Token is received: The next Token to be processed begins with the Symbol immediately following the last Symbol of the DLLP . Receivers are permitted to check whether more than one SDP Token is received in a single Symbol Time. If checked, receiving more than one SDP Token in a single Symbol Time is a Framing Error. 16695 When an IDL Token is received: For a x1 Link, the next Token to be processed is the next Symbol received. For a x2 Link, the next Token to be processed is the Symbol received in Lane 0 of the next Symbol Time. It is strongly recommended that Receivers check whether the Symbol received in Lane 1, if it did not receive IDL, after an IDL Token was received in Lane 0 is also IDL and report an error for Lane 1 in the Lane Error Status 251 Register. If checked, receiving a Symbol other than IDL is a Framing Error. 16696 16697 16698 When an IDL Token is received: For a x1 Link, the next Token to be processed begins with the next Symbol received. For a x2 Link, the next Token to be processed begins with the Symbol received in Lane 0 of the next Symbol Time. It is strongly recommended that Receivers check whether the Symbol received in Lane 1, if it did not receive IDL, after an IDL Token was received in Lane 0 is also IDL and report an error for Lane 1 in the Lane Error Status Register. If checked, receiving a Symbol other than IDL is a Framing Error. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 16168 For a x2 Link, the next Token to be processed is the /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html Symbol received in Lane 0 of the next Symbol Time. It is strongly 16169 16170 recommended that Receivers check whether the Symbol received in Lane 1, if it did not receive IDL, after an IDL Token was received in Lane 0 is also IDL and report an error for Lane 1 in the Lane Error Status Register. If checked, receiving a Symbol other than IDL is a Framing Error. For a x4 Link, the next Token to be processed is the Symbol received in Lane 0 of the next Symbol Time. It is strongly recommended that Receivers check whether the Symbols received in Lanes 1-3, after an IDL Token was received in Lane 0 are also IDL and report an error for the Lane(s) that did not receive IDL, in the Lane Error Status Register. If checked, receiving a Symbol other than IDL is a Framing Error. For x8, x12, x16, and x32 Links, the next Token to be processed is the Symbol received in the next DW aligned Lane following the IDL Token. For example, if an IDL Token is received in Lane 4 of a x16 Link, the next Token location is Lane 8 of the same Symbol Time. However, if an IDL Token is received on Lane 4 of a x8 Link, the next Token location is Lane 0 of the following Symbol Time. It is strongly recommended that Receivers check whether the Symbols received between the IDL Token and the next Token location are also IDL and report an error for the Lane(s) that did not receive IDL, in the Lane Error Status Register. If checked, receiving a Symbol other than IDL is a Framing Error. 16171 16172 16177 16178 16179 Page 16700 16702 Note: The only Tokens expected to be received in the same Symbol Time following an IDL Token are additional IDL Tokens or an EDS Token. 16703 16174 16176 16699 For a x2 Link, the next Token to be processed begins with the Symbol received in Lane 0 of the next Symbol Time. It is strongly recommended that Receivers check whether the Symbol received in Lane 1, if it did not receive IDL, after an IDL Token was received in Lane 0 is also IDL and report an error for Lane 1 in the Lane Error Status Register. If checked, receiving a Symbol other than IDL is a Framing Error. For a x4 Link, the next Token to be processed begins with the Symbol received in Lane 0 of the next Symbol Time. It is strongly recommended that Receivers check whether the Symbols received in Lanes 1-3, after an IDL Token was received in Lane 0 are also IDL and report an error for the Lane(s) that did not receive IDL, in the Lane Error Status Register. If checked, receiving a Symbol other than IDL is a Framing Error. For x8, x12, x16, and x32 Links, the next Token to be processed begins with the Symbol received in the next DW aligned Lane following the IDL Token. For example, if an IDL Token is received in Lane 4 of a x16 Link, the next Token location begins with Lane 8 of the same Symbol Time. However, if an IDL Token is received on Lane 4 of a x8 Link, the next Token location begins with Lane 0 of the following Symbol Time. It is strongly recommended that Receivers check whether the Symbols received between the IDL Token and the next Token location are also IDL and report an error for the Lane(s) that did not receive IDL, in the Lane Error Status Register. If checked, receiving a Symbol other than IDL is a Framing Error. 16701 Note: The only Tokens expected to be received in the same Symbol Time following an IDL Token are additional IDL Tokens or an EDS Token. 16173 16175 16698 16704 While processing the Data Stream, Receivers must also check the Block type received by each Lane, after accounting for Lane-toLane de-skew, for the following conditions: Receiving an Ordered Set Block on any Lane immediately following an SDS Ordered Set is a Framing Error. Receiving a Block with an undefined Block type (a Sync Header of 11b or 00b) is a Framing Error. It is strongly recommended that Receivers of a multi-Lane Link report an error for any Lane that received the undefined Block type in the Lane Error Status register. Receiving an Ordered Set Block on any Lane without receiving an EDS token in the preceding Block is a Framing Error. For example, receiving a SKP Ordered Set without a preceding EDS Token is a Framing Error. In addition, receiving a SKP Ordered Set followed immediately by another Ordered Set Block (including another SKP Ordered Set) within a Data Stream is a Framing Error. It is strongly recommended that if the first Symbol of the Ordered Set is SKP, Receivers of a multiLane Link report an error for the Lane(s) in the Lane Error Status register if the received Symbol number 1 through 4N does not match the corresponding Symbol in Table 4-16: . Receiving a Data Block on any Lane block contained an EDS Token is a Framing Error. It is recommended that Receivers of a multi-Lane Link report 252 Lane(s) that received the Data Block in the Lane Error when the previous strongly an error for the Status register. 16705 16706 16707 16708 16709 While processing the Data Stream, Receivers must also check the Block type received by each Lane, after accounting for Lane-toLane de-skew, for the following conditions: Receiving an Ordered Set Block on any Lane immediately following an SDS Ordered Set is a Framing Error. Receiving a Block with an undefined Block type (a Sync Header of 11b or 00b) is a Framing Error. It is strongly recommended that Receivers of a multi-Lane Link report an error for any Lane that received the undefined Block type in the Lane Error Status register. Receiving an Ordered Set Block on any Lane without receiving an EDS token in the preceding Block is a Framing Error. For example, receiving a SKP Ordered Set without a preceding EDS Token is a Framing Error. In addition, receiving a SKP Ordered Set followed immediately by another Ordered Set Block (including another SKP Ordered Set) within a Data Stream is a Framing Error. It is strongly recommended that if the first Symbol of the Ordered Set is SKP, Receivers of a multiLane Link report an error for the Lane(s) in the Lane Error Status register if the received Symbol number 1 through 4N does not match the corresponding Symbol in Table 4-22 Standard SKP Ordered Set with 128b/ 130b Encoding or Table 4-23 Control SKP Ordered Set with 128b/130b Encoding . Receiving a Data Block on any Lane when the previous block contained an EDS Token is a Framing Error. It is strongly recommended that Receivers of a multi-Lane Link report an error for the Lane(s) that received the Data Block in the Lane Error Status register. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16179 16180 Receiving a Data Block on any Lane when the previous block contained an EDS Token is a Framing Error. It is strongly recommended that Receivers of a multi-Lane Link report an error for the Lane(s) that received the Data Block in the Lane Error Status register. Receivers are permitted to check for different Ordered Sets on different Lanes. For example, Lane 0 receives a SKP Ordered Set and Lane 1 receives an EIOS. If checked, receiving different Ordered Sets is a Framing Error. 16709 16710 16181 16711 16182 16712 16183 16713 16184 16714 16185 16715 16186 4.2.2.3.4 Recovery from Framing Errors 16187 16192 16193 16194 4.2.2.3.4 Recovery from Framing Errors 16718 If a receiver detects a Framing Error while processing the Data Stream, it must: 16190 16191 16716 16717 16188 16189 Receiving a Data Block on any Lane when the previous block contained an EDS Token is a Framing Error. It is strongly recommended that Receivers of a multi-Lane Link report an error for the Lane(s) that received the Data Block in the Lane Error Status register. Receivers are permitted to check for different Ordered Sets on different Lanes. For example, Lane 0 receives a SKP Ordered Set and Lane 1 receives an EIOS. If checked, receiving different Ordered Sets is a Framing Error. 16719 If a receiver detects a Framing Error while processing the Data Stream, it must: 16720 Report a Receiver Error as described in Section 4.2.4.7 Link Error Recovery . Stop processing the Data Stream. Processing of a new Data Stream is initiated when the next SDS Ordered Set is received as previously described. Initiate the error recovery process as described in Section 4.2.4.7 Link Error Recovery . If the LTSSM state is L0, direct the LTSSM to Recovery. If the LTSSM state is Configuration.Complete or Configuration.Idle when the Framing Error is detected, the error recovery process is satisfied by either a transition from Configuration.Idle to Recovery.RcvrLock due to the specified timeout, or a directed transition from L0 to Recovery . If the LTSSM state is Recovery.RcvrCfg or Recovery.Idle when the Framing Error is detected, the error recovery process is satisfied by either a transition from Recovery.Idle to Recovery.RcvrLock due to the specified timeout, or a directed transition from L0 to Recovery. If the LTSSM substate is either Recovery.RcvrLock or Configuration.Linkwidth.Start, the error recovery process is satisfied upon exit from these substates and no direction of the LTSSM to Recovery is required; Note: The framing error recovery mechanism is not expected to directly cause any Data Link Layer initiated recovery action such as NAK. 16721 16722 16723 16724 16195 16725 16196 16726 16197 16727 16198 Report a Receiver Error as described in Section 4.2.4.8 Link Error Recovery . Stop processing the Data Stream. Processing of a new Data Stream is initiated when the next SDS Ordered Set is received as previously described. Initiate the error recovery process as described in Section 4.2.4.8 Link Error Recovery . If the LTSSM state is L0, direct the LTSSM to Recovery. If the LTSSM state is Configuration.Complete or Configuration.Idle when the Framing Error is detected, the error recovery process is satisfied by either a transition from Configuration.Idle to Recovery.RcvrLock due to the specified timeout, or a transition to Recovery through L0. If the LTSSM state is Recovery.RcvrCfg or Recovery.Idle when the Framing Error is detected, the error recovery process is satisfied by either a transition from Recovery.Idle to Recovery.RcvrLock due to the specified timeout, or a directed transition from L0 to Recovery. If the LTSSM substate is either Recovery.RcvrLock or Configuration.Linkwidth.Start, the error recovery process is satisfied upon exit from these substates and no direction of the LTSSM to Recovery is required. Note: The framing error recovery mechanism is not expected to directly cause any Data Link Layer initiated recovery action such as NAK. 16728 16199 Implementation Note Time Spent in Recovery Due to Detection of a Framing 16200 16729 Error Error 16201 16731 16202 16732 16203 16733 Page 253 Implementation Note Time Spent in Recovery Due to Detection of a Framing 16730 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16203 16231 16232 16233 16234 16235 16236 16237 16238 16239 16733 All 16 Symbols of a Start of Data Stream (SDS) Ordered Set bypass scrambling. All 16 Symbols of an Electrical Idle Ordered Set (EIOS) bypass scrambling. All Symbols of a SKP Ordered Set bypass scrambling. Transmitters advance their LFSR for all Symbols of all Ordered Sets except for the SKP Ordered Set. The LFSR is not advanced for any Symbols of a SKP Ordered Set. Receivers evaluate Symbol 0 of Ordered Set Blocks to determine whether to advance their LFSR. If Symbol 0 of the Block is SKP (see Section 4.2.7.2 SKP Ordered Set for 128b/130b Encoding ), then the LFSR is not advanced for any Symbol of the Block. Otherwise, the LFSR is advanced for all Symbols of the Block. All 16 Symbols of a Data Block are scrambled and advance the scrambler. For Symbols that need to be scrambled, the least significant bit is scrambled first and the most significant bit is scrambled last. The seed value of the LFSR is dependent on the Lane number assigned to the Lane when the Link first entered Configuration.Idle (i.e., having gone through Polling from Detect with LinkUp = 0b). The seed values for Lane number modulo 8 are: 16240 16761 16762 16763 16764 16765 16766 16767 16768 16769 All 16 Symbols of a Start of Data Stream (SDS) Ordered Set bypass scrambling. All 16 Symbols of an Electrical Idle Ordered Set (EIOS) bypass scrambling. All Symbols of a SKP Ordered Set bypass scrambling. Transmitters advance their LFSR for all Symbols of all Ordered Sets except for the SKP Ordered Set. The LFSR is not advanced for any Symbols of a SKP Ordered Set. Receivers evaluate Symbol 0 of Ordered Set Blocks to determine whether to advance their LFSR. If Symbol 0 of the Block is SKP (see Section 4.2.7.2 SKP Ordered Set for 128b/130b Encoding ), then the LFSR is not advanced for any Symbol of the Block. Otherwise, the LFSR is advanced for all Symbols of the Block. All 16 Symbols of a Data Block are scrambled and advance the scrambler. For Symbols that need to be scrambled, the least significant bit is scrambled first and the most significant bit is scrambled last. The seed value of the LFSR is dependent on the Lane number assigned to the Lane when the Link first entered Configuration.Idle (i.e., having gone through Polling from Detect with LinkUp = 0b). The seed values for Lane number modulo 8 are: 16770 16771 16772 Lane 16773 16774 Seed 16775 16776 16777 16241 0 16242 16243 16778 0 16779 1DBFBCh 16244 16780 1DBFBCh 16781 16782 16783 16245 1 16246 16247 16784 1 16785 0607BBh 16248 16786 0607BBh 16787 16788 16789 16249 2 16250 16251 16790 2 16791 1EC760h 16252 16792 1EC760h 16793 16794 16795 16253 16254 Page 254 3 16796 16797 3 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16254 16797 16255 18C0DBh 16256 16798 18C0DBh 16799 16800 16801 16257 4 16258 16802 4 16803 16259 010F12h 16260 16804 010F12h 16805 16806 16807 16261 5 16262 16808 5 16809 16263 19CFC9h 16264 16810 19CFC9h 16811 16812 16813 16265 6 16266 16814 6 16815 16267 0277CEh 16268 16816 0277CEh 16817 16818 16819 16269 7 16270 16820 7 16821 16271 1BB807h 16822 16272 16823 16273 16824 16274 16825 16275 16826 16276 16827 1BB807h 16828 16829 16830 16277 Implementation Note Scrambling Pseudo-code 16278 16831 16832 16279 16833 16280 16834 16281 16282 16835 The pseudo-code for the scrambler along with examples is provided in Section C.2 128b/130b Data Scrambling Example of Appendix C. 16836 16283 16837 16284 16838 16285 16286 16287 Implementation Note Scrambling Pseudo-code The pseudo-code for the scrambler along with examples is provided in Section C.2 128b/130b Data Scrambling Example of Appendix C Physical Layer Appendix . 16839 The seed value of the LFSR does not change while LinkUp=1. Link reconfiguration through the LTSSM Configuration state does not modify the initial Lane number assignment as long as the LinkUp remains 1 (even though the Lane assignment may change during Configuration). Scrambling cannot be disabled in Configuration.Complete when using 128b/130b encoding. Page 255 16840 16841 The seed value of the LFSR does not change while LinkUp=1. Link reconfiguration through the LTSSM Configuration state does not modify the initial Lane number assignment as long as the LinkUp remains 1 (even though the Lane assignment may change during Configuration). Scrambling cannot be disabled in Configuration.Complete when using 128b/130b encoding. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 16287 /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html Scrambling cannot be disabled in Configuration.Complete 16288 when using 128b/130b encoding. A Loopback Slave must not descramble or scramble the looped-back bit stream. 16841 16842 16289 16843 16290 16844 16291 16845 16292 16846 16306 16860 16307 16861 16308 16862 16309 Scrambling cannot be disabled in Configuration.Complete when using 128b/130b encoding. A Loopback Slave must not descramble or scramble the looped-back bit stream. 16863 16310 Figure 4-19 Alternate Implementation of the LFSR for 16864 Descrambling 16311 16865 16312 16866 16313 16867 16314 16868 16315 16316 Figure 4-19 Alternate Implementation of the LFSR for Descrambling 16869 4.2.2.5 Loopback with 128b/130b Code 16870 4.2.2.5 Precoding 16871 16872 16873 A Receiver may request precoding from its transmitter for operating at data rates of 32.0 GT/s or higher. The precoding rules are as follows: 16874 16875 16876 16877 16878 16879 Page 256 A Port or Pseudo-Port must request precoding on all configured Lanes of the Link. Behavior is undefined if precoding is requested on some Lanes but not others by a Port or Pseudo-Port. A Port or Pseudo-Port may request precoding independent of other Ports or Pseudo-Ports. For example, it is possible that precoding may be turned on only in the Upstream Port in the case with no Retimers in Figure 4-35 Receiver Number Assignment , or on all the Lanes in Tx(A) and Tx(E) in the two Re-timer example in Figure 4-35 Receiver Number Assignment . Precoding is turned off for all data rates 32.0 GT/s and higher when the LTSSM is in the Detect state. Precoding request, if any, must be made prior to entering the 32.0 GT/s or higher data rate by setting the appropriate bit in the EQ TS2 Ordered Sets or the 128b/130b EQ TS2 Ordered Sets. A precoding request must be made by setting Transmitter Precode Request in the EQ TS2 or 128b/130b EQ TS2 Ordered sets prior to the transition to Recovery.Speed for the target data rate where the precoding will be turned on. For each data rate above 32.0 GT/s, the precoding request must be made independently. If the Link operates at 32.0 GT/s or higher data rate without performing equalization through the No Equalization Needed mechanism it negotiation in the (modified) TS1/TS2 Ordered Sets, the precoding requests from the last equalization results that are being used must be enforced. Thus each (pseudo) Port must store the precoding request along with the Tx Eq values in each Lanes, if it advertises the No Equalization Needed mechanism. If no equalization has ever been performed on the Link (prior to the current Link up), then precoding will not be turned on. 16879 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16880 16881 16882 16883 16884 16885 16886 If the Link operates at 32.0 GT/s or higher data rate without performing equalization through the No Equalization Needed mechanism it negotiation in the (modified) TS1/TS2 Ordered Sets, the precoding requests from the last equalization results that are being used must be enforced. Thus each (pseudo) Port must store the precoding request along with the Tx Eq values in each Lanes, if it advertises the No Equalization Needed mechanism. If no equalization has ever been performed on the Link (prior to the current Link up), then precoding will not be turned on. If Transmitter Precode Request is set to 1b in each of the received eight consecutive EQ TS2 or 128b/130b EQ TS2 Ordered Sets during Recovery.RcvrCfg prior to entry to Recovery.Speed, the Transmitter must turn on the precoding for the target data rate at which the Link will operate on exit from Recovery.Speed if the target data rate is 32.0 GT/s or higher. Once turned on, the precoding will be in effect for that target data rate until the Transmitter receives another set of eight consecutive EQ TS2 or 128b/130b EQ TS2 Ordered Sets during Recovery.RcvrCfg prior to entry to Recovery.Speed for the same target data rate. A Transmitter must not turn on precoding for any data rates lower than 32.0 GT/s. For data rates of 32.0 GT/s or higher, a Transmitter must set the Transmitter Precoding On bit in the TS1 Ordered Set in Recovery state to 1b if the precoding is on; else the bit must be set to 0b. Only scrambled bits are precoded, when precoding is turned on. The “previous bit” used for precoding is set to 1b on every block boundary and gets updated by the last scrambled and precoded bit transmitted within the current block boundary. When precoding is turned on, for symbols that are scrambled, Receivers must first decode the precoded bits before sending them to the descrambler. A Transmitter that has turned on precoding for 32.0 GT/s data rate on Lane 0, must set the Transmitter Precoding On bit to 1b in the 32.0 GT/s Status Register; else it must set the bit to 0b. A Receiver that has requested or will request to turn on precoding at 32.0 GT/s data rate, must set Transmitter Precode Request to 1b in the 32.0 GT/s Status Register; else it must set the bit to 0b. 16887 16888 16889 16890 16891 16892 16893 Figure 4-20 Precoding working the scrambler/ descrambler 16894 16895 16896 16897 16898 Implementation Note Parity in the SKP Ordered Set when Precoding is turned 16899 on 16900 16901 16902 16903 Page 257 As per the rules of Section 4.2.4.1 Training Sequences and Section 4.2.7.2 SKP Ordered Set for 128b/130b Encoding , when precoding is turned on, the parity in the SKP Ordered Sets should be calculated before precoding is applied on the Transmit side. Thus, the order in the Transmitter is: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16903 As per the rules of Section 4.2.4.1 Training Sequences and Section 4.2.7.2 SKP Ordered Set for 128b/130b Encoding , when precoding is turned on, the parity in the SKP Ordered Sets should be calculated before precoding is applied on the Transmit side. Thus, the order in the Transmitter is: 16904 16905 scrambling, followed by parity bit calculation, followed by precoding for the scrambled bits. 16906 16907 16908 16909 16910 Accordingly, in the Receiver, the order is: 16911 16912 precoding (if turned on by the Transmitter), followed by parity bit calculation, followed by descrambling. 16913 16914 16915 16916 16917 The rationale for this order is that in a Link with one or two Retimers, different Link segments may have the precoding on or off. Let us consider an example system with one retimer between the Root Port and End Point to illustrate this. In the upstream direction, the End Point has precoding on in its Transmitter Lanes since the Retimer Receiver needs it but the Retimer to Root Port Link segment has the precoding off since the Root Port does not need precoding at its Receiver. Since the Retimer does not change the parity bit, the Root Port would get a parity error if the parity calculation was done by the Transmitter (of the End Point) after precoding. 16918 16919 16920 16921 16922 16923 Implementation Note Loopback Master behavior if Precoding is on in any Link 16924 Segment 16925 16926 16927 16928 16929 16930 16931 16932 Page 258 As per the rules of precoding mentioned in this section and Section 4.2.6.4 Recovery , a Loopback Master operating at a data rate of 32.0 GT/s or higher should account for precoding to be on on some link segments and off in other link segments. This is particularly relevant when the Loopback Slave transitions from sending TS1 Ordered Sets to looping back the bits. This is where the precoding on the receiver of the Loopback Master may switch (between precoding on and off). The Loopback Master is permitted to use implementation specific mechanisms to handle this scenario. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16932 16933 16934 16935 Implementation Note TS1/TS2 Ordered Sets when Precoding is turned on 16936 16937 16938 16939 As per the rules in this section, when precoding is turned on, the ‘previous bit’ used for precoding is 1b for the first bit of Symbol 1 since Symbol 0 is not scrambled and the ‘previous bit’ gets set to 1b at the block boundary. 16940 16941 16942 16943 16944 16945 16946 16317 16318 16319 16948 When using 128b/130b encoding, Loopback Masters must transmit Blocks with the defined 01b and 10b Sync Headers. However, they are not required to transmit an SDS Ordered Set when transitioning from Ordered Set Blocks to Data Blocks, nor are they required to transmit an EDS Token when transitioning from Data Blocks to Ordered Set Blocks. Masters must transmit SKP Ordered Sets periodically as defined in Section 4.2.7 Clock Tolerance Compensation , and they must be capable of processing received (looped-back) SKP Ordered Sets of varying length. Masters are permitted to transmit Electrical Idle Exit Ordered Sets (EIEOS) as defined in Section 4.2.2.2.1 Block Alignment . Masters are permitted to transmit any payload in Data Blocks and Ordered Set Blocks that they expect to be looped-back. If the Loopback Master transmits an Ordered Set Block whose first symbol matches the first symbol of SKP OS, EIEOS, or EIOS, that Ordered Set Block must be a complete and valid SKP OS, EIEOS, or EIOS. 16320 16949 When using 128b/130b encoding, Loopback Masters must transmit Blocks with the defined 01b and 10b Sync Headers. However, they are not required to transmit an SDS Ordered Set when transitioning from Ordered Set Blocks to Data Blocks, nor are they required to transmit an EDS Token when transitioning from Data Blocks to Ordered Set Blocks. Masters must transmit SKP Ordered Sets periodically as defined in Section 4.2.7 Clock Tolerance Compensation , and they must be capable of processing received (looped-back) SKP Ordered Sets of varying length. Masters are permitted to transmit Electrical Idle Exit Ordered Sets (EIEOS) as defined in Section 4.2.2.2.1 Block Alignment . Masters are permitted to transmit any payload in Data Blocks and Ordered Set Blocks that they expect to be looped-back. If the Loopback Master transmits an Ordered Set Block whose first symbol matches the first symbol of SKP OS, EIEOS, or EIOS, that Ordered Set Block must be a complete and valid SKP OS, EIEOS, or EIOS. 16950 16321 16322 4.2.2.6 Loopback with 128b/130b Code 16947 16951 When using 128b/130b encoding, Loopback Slaves must retransmit all bits received without modification, except for SKP Ordered Sets which can be adjusted as needed for clock compensation. If clock compensation is required, slaves must add or remove 4 SKP Symbols per Ordered Set. The modified SKP Ordered Set must meet the definition of Section 4.2.7.2 SKP Ordered Set for 128b/130b Encoding (i.e., it must have between 4 to 20 SKP Symbols followed by the SKP_END Symbol and the three Symbols that follow it as transmitted by the Loopback Master). If a slave is unable to obtain Block alignment or it is misaligned, it may be unable to perform clock compensation and therefore unable to loop-back all bits received. In this case, it is permitted to add or remove Symbols as necessary to continue operation. Slaves must not check for a received SDS Ordered Set when a transition from Ordered Set Blocks to Data Blocks is detected, and they must not check for a received EDS Token when a transition from Data Blocks to Ordered Set Blocks is detected. Page 259 16952 When using 128b/130b encoding, Loopback Slaves must retransmit all bits received without modification, except for SKP Ordered Sets which can be adjusted as needed for clock compensation. If clock compensation is required, slaves must add or remove 4 SKP Symbols per Ordered Set. The modified SKP Ordered Set must meet the definition of Section 4.2.7.2 SKP Ordered Set for 128b/130b Encoding (i.e., it must have between 4 to 20 SKP Symbols followed by the SKP_END Symbol and the three Symbols that follow it as transmitted by the Loopback Masters. If a slave is unable to obtain Block alignment or it is misaligned, it may be unable to perform clock compensation and therefore unable to loop-back all bits received. In this case, it is permitted to add or remove Symbols as necessary to continue operation. Slaves must not check for a received SDS Ordered Set when a transition from Ordered Set Blocks to Data Blocks is detected, and they must not check for a received EDS Token when a transition from Data Blocks to Ordered Set Blocks is detected. compensation is required, slaves must add or remove 4 SKP Symbols per Ordered Set. The modified SKP Ordered Set must meet the definition of Section 4.2.7.2 SKP Ordered Set for 128b/130b Encoding (i.e., it must have between 4 to 20 SKP Symbols followed by the SKP_END Symbol and the three Symbols that follow it as transmitted by the Loopback Master). If a slave is unable to obtain Block alignment or it is misaligned, it may be unable to perform clock compensation and therefore unable to loop-back /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. all bits received. In this case, it is permitted to add or remove Symbols as necessary to continue operation. Slaves must not check for a received /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html SDS Ordered Set when a transition from Ordered Set Blocks to Data Blocks is detected, and they must not check for a received EDS Token when a transition from Data Blocks to Ordered Set Blocks is detected. compensation is required, slaves must add or remove 4 SKP Symbols per Ordered Set. The modified SKP Ordered Set must meet the definition of Section 4.2.7.2 SKP Ordered Set for 128b/130b Encoding (i.e., it must have between 4 to 20 SKP Symbols followed by the SKP_END Symbol and the three Symbols that follow it as transmitted by the Loopback Masters. If a slave is unable to obtain Block alignment or it is misaligned, it may be unable to perform clock compensation and therefore unable to loop-back all bits received. In this case, it is permitted to add or remove Symbols as necessary to continue operation. Slaves must not check for a received SDS Ordered Set when a transition from Ordered Set Blocks to Data Blocks is detected, and they must not check for a received EDS Token when a transition from Data Blocks to Ordered Set Blocks is detected. 16323 16953 16324 16954 16325 16955 16326 16956 16327 16957 16328 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher 16958 Data Rates 16329 16959 16330 16331 16960 The Link equalization procedure enables components to adjust the Transmitter and the Receiver setup of each Lane to improve the signal quality and meet the requirements specified in Chapter 8 Electrical SubBlock , when operating at 8.0 GT/s and higher data rates. All the Lanes that are associated with the LTSSM (i.e., those Lanes that are currently operational or may be operational in the future due to Link Upconfigure) must participate in the Equalization procedure. The procedure must be executed during the first data rate change to 8.0 GT/s as well as the first change to all data rates greater than 8.0 GT/s . Components must arrive at the appropriate Transmitter setup for all the operating conditions and data rates that they will encounter in the future when LinkUp=1b. Components must not require that the equalization procedure be repeated at any data rate for reliable operation, although there is provision to repeat the procedure. Components must store the Transmitter setups that were agreed to during the equalization procedures and use them for future operation at 8.0 GT/s and higher data rates. Components are permitted to fine-tune their Receiver setup even after the equalization procedure is complete as long as doing so does not cause the Link to be unreliable (i.e., does not meet the requirements in Chapter 8 Electrical Sub-Block ) or go to Recovery. 16332 16964 The Link equalization procedure is not required for any data rates and can be completely bypassed if all components in the Link have advertised that no equalization is needed in its TS1/TS2 Ordered Sets or modified TS1/TS2 Ordered Sets (see Table 4-6 TS1 Ordered Set , Table 4-7 TS2 Ordered Set , and Table 4-8 Modified TS1/TS2 Ordered Set (8b/10b encoding) ). A component may choose to advertise that it does not need equalization at any rates above 5.0 GT/s if it supports 32.0 GT/s or higher data rates and can either operate reliably with equalization settings stored from a prior equalization procedure or does not need equalization for reliable operation. 16965 16336 Page The Link equalization procedure enables components to adjust the Transmitter and the Receiver setup of each Lane to improve the signal quality and meet the requirements specified in Chapter 8 Electrical SubBlock , when operating at 8.0 GT/s and higher data rates. All the Lanes that are associated with the LTSSM (i.e., those Lanes that are currently operational or may be operational in the future due to Link Upconfigure) must participate in the equalization procedure. The procedure must be executed during the first data rate change to any data rate at 8.0 GT/s or above, unless all components in the Link have advertised that no equalization is needed. Components must arrive at the appropriate Transmitter setup for all the operating conditions and data rates that they will encounter in the future when LinkUp=1b. Components must not require that the equalization procedure be repeated at any data rate for reliable operation, although there is provision to repeat the procedure. Components must store the Transmitter setups that were agreed to during the equalization procedures and use them for future operation at 8.0 GT/s and higher data rates. Components are permitted to fine-tune their Receiver setup even after the equalization procedure is complete as long as doing so does not cause the Link to be unreliable (i.e., does not meet the requirements in Chapter 8 Electrical Sub-Block ) or go to Recovery. 16963 The equalization procedure can be initiated either autonomously or by software. It is strongly recommended that components use the autonomous mechanism. However, a component that chooses not to participate in the autonomous mechanism must have its associated software ensure that the software based mechanism is applied. 16335 16337 16961 16962 16333 16334 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates 16966 The autonomous mechanism is executed if both components advertise that they are capable of at least the 8.0 GT/s data rate (via the TS1 and TS2 Ordered Sets) during the initial Link negotiation (when LinkUp is set to 1b). If both components advertised support for 8.0 GT/s and 16.0 GT/s, the Downstream Port may choose to only perform the 8.0 GT/ s equalization procedure using the autonomous mechanism. If both components advertised support for 16.0 GT/s but only the 8.0 GT/s 260 equalization procedure is performed using the autonomous mechanism, the software based mechanism must be executed in order to perform the 16.0 GT/s equalization procedure. After entering L0, irrespective of the current Link speed, neither component must transmit any DLLP if the equalization procedure must be performed and until the equalization procedure completes. The equalization procedure is considered complete once the Transmitter and Receiver setup of each Lane has been adjusted for each common data rate supported above 5.0 GT/s for which the Downstream Port intends to perform equalization using the autonomous 16967 The equalization procedure can be initiated either autonomously or by software. It is strongly recommended that components use the autonomous mechanism for all the data rates above 5.0 GT/s that they intend to operate in. However, a component that chooses not to participate in the autonomous mechanism for all the data rates above 5.0 GT/s must have its associated software ensure that the software based mechanism is applied to the data rates above 5.0 GT/s where the autonomous mechanism was not applied, prior to operating at that data rate. 16337 The autonomous mechanism is executed if both components advertise that they are capable of at least the 8.0 GT/s data rate (via /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. the TS1 and TS2 Ordered Sets) during the initial Link negotiation (when LinkUp is set to 1b). If both components advertised support for 8.0 GT/s /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html and 16.0 GT/s, the Downstream Port may choose to only perform the 8.0 GT/ s equalization procedure using the autonomous mechanism. If both components advertised support for 16.0 GT/s but only the 8.0 GT/s equalization procedure is performed using the autonomous mechanism, the software based mechanism must be executed in order to perform the 16.0 GT/s equalization procedure. After entering L0, irrespective of the current Link speed, neither component must transmit any DLLP if the equalization procedure must be performed and until the equalization procedure completes. The equalization procedure is considered complete once the Transmitter and Receiver setup of each Lane has been adjusted for each common data rate supported above 5.0 GT/s for which the Downstream Port intends to perform equalization using the autonomous mechanism. The Downstream Port is required to make the transition from L0 to Recovery to change the data rate to 8.0 GT/s and perform the equalization procedure; the Upstream Port is permitted, but not required, to make the transition from L0 to Recovery autonomously. The Downstream Port must not advertise 16.0 GT/s support in Recovery if it entered Recovery with the intention of performing an 8.0 GT/s equalization procedure. This applies to the autonomous equalization procedure as well as the software initiated equalization procedure, or any subsequent equalization redo. The Downstream Port must not advertise 16.0 GT/s support in Recovery until the 8.0 GT/s equalization procedure has been successfully executed. The 8.0 GT/s equalization procedure is deemed to have been successfully executed if the Equalization 8.0 GT/s Phase 3 Successful bit and Equalization 8.0 GT/s Complete bit of the Link Status 2 register are both set to 1b. Immediately following the transition from Recovery to L0, after the initial data rate change to 8.0 GT/s, the Downstream Port is required to transition from L0 to Recovery, advertise 16.0 GT/s data rate support, change the data rate to 16.0 GT/s and perform the 16.0 GT/s equalization procedure if both components advertised that they are capable of 16.0 GT/s during the initial Link negotiation, neither component detected problems with its 8.0 GT/s equalization settings and it intends to perform a 16.0 GT/s equalization procedure using the autonomous mechanism. If the Downstream Port detected 8.0 GT/s equalization problems or the Upstream Port made an 8.0 GT/s equalization redo request (by setting the Request Equalization bit to 1b and the Equalization Request Data Rate to 0b in the TS2s it sent in Recovery.RcvrCfg) the Downstream Port may redo 8.0 GT/s equalization prior to proceeding to the 16.0 GT/s equalization procedure. The number of 8.0 GT/s equalization redos initiated prior to the 16.0 GT/s equalization is implementation specific but must be finite. If at the conclusion of the initial or subsequent 8.0 GT/s equalization process and the execution of an implementation specific number of equalization redo’s, the Link is not able to operate reliably at the 8.0 GT/s data rate, then it must revert back to 2.5 GT/s or 5.0 GT/s Data Rate. Speed changes to the 16.0 GT/s data rate and subsequent 16.0 GT/s equalization process must not be attempted regardless of whether both Link partners ever advertised support for 16.0 GT/s unless a subsequent equalization redo at the 8.0 GT/s data rate is successful. 16967 16968 16969 16970 Normally, equalization is performed at a higher data rate only if equalization has successfully completed at all lower data rates above 5.0 GT/s. For example, a Link will complete equalization successfully at 8.0 GT/s, followed by 16.0 GT/s, followed by 32.0 GT/s. However, an optional mechanism to skip over equalization to the highest common data rate of 32.0 GT/s or higher is permitted if all components support data rates of 32.0 GT/s or higher and the mechanism is supported by all components in the Link, as advertised in the TS1/TS2 Ordered sets or modified TS1/TS2 Ordered Sets. When this optional mechanism is enabled and successfully negotiated between the components, equalization is not performed at any other rate except the highest common data rate. For all the data rates above 5.0 GT/s where equalization is not performed, the expectation is that the Link must not operate in those data rates. For example, a Link may train to L0 in 2.5 GT/s, enter Recovery and perform equalization at 32.0 GT/s, skipping equalization at 8.0 GT/s and 16.0 GT/ s. In this case, the intended data rates of operation of the Link are 2.5 GT/s, 5.0 GT/s, or 32.0 GT/s. If the equalization procedure at the highest common data rate is unsuccessful even after re-equalization attempts and the Link needs to equalize at lower data rates, the Downstream Port must stop advertising Equalization bypass to highest rate support and ensure that the Link returns to operation at 2.5 GT/s or 5.0 GT/s. The required equalization procedures are then performed as they would have been if the optional mechanism to skip over equalization to the highest common data rate was never supported. If the equalization procedure at the lower data rates is driven by software, it must set the Equalization bypass to highest rate Disable and No Equalization Needed Disable register bits to 1b each; set the target Link speed such that the Link will be operational at 2.5 GT/s or 5.0 GT/s; and then set the target Link speed to equalize at the lower rates starting with 8.0 GT/s onwards. A port must not advertise the Equalization bypass to highest rate support if the Equalization bypass to highest rate Disable bit is set to 1b. 16971 16972 16973 16974 Page 261 The equalization procedure can be initiated either autonomously or by software. It is strongly recommended that components use the autonomous mechanism for all the data rates above 5.0 GT/s that they intend to operate in. However, a component that chooses not to participate in the autonomous mechanism for all the data rates above 5.0 GT/s must have its associated software ensure that the software based mechanism is applied to the data rates above 5.0 GT/s where the autonomous mechanism was not applied, prior to operating at that data rate. Another optional mechanism to skip the entire equalization process and go directly to the highest common data rate of 32.0 GT/s or higher is permitted if all components support data rates of 32.0 GT/s or higher and the No Equalization Needed mechanism is supported by all components in the Link, as advertised in the TS1/TS2 or modified TS1/TS2 Ordered sets. This is done if a component is either able to retrieve the equalization and other circuit settings at all the data rates from a prior equalization that will work for the component or it does not need equalization at all in the all data rates above 5.0 GT/s. A component must not advertise this capability if the Equalization bypass to highest rate Disable bit is set to 1b. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16974 16975 16976 If one direction of the Link is advertising No Equalization Needed and the other side is advertising Equalization bypass to highest rate support in the TS1/TS2 Ordered Sets, the Link will operate in the Equalization bypass to highest rate support since the No Equalization Needed bit also indicates that the device is capable of bypassing Equalization to the highest data rate. In the modified TS1/TS2 Ordered Sets, a device that sets No Equalization Needed bit to 1b must also set the Equalization bypass to highest rate support to 1b. If one direction of the Link is advertising No Equalization Needed bit and the other side is advertising Equalization bypass to highest rate support only in the modified TS1/TS2 Ordered Sets, the Link will operate in the Equalization bypass to highest rate support. Link operation is undefined if a device advertises No Equalization Needed bit as 1b and Equalization bypass to highest rate support to 0b in the modified TS1/TS2 Ordered Sets it transmits. 16977 16978 16979 The autonomous mechanism is executed if both components advertise that they are capable of at least the 8.0 GT/s data rate (via the TS1 and TS2 Ordered Sets) during the initial Link negotiation (when LinkUp is set to 1b) and the Downstream Port chooses to perform the equalization procedure at the intended data rates of operation above 5.0 GT/s. While not recommended, the Downstream Port may choose to perform the autonomous mechanism only on a subset of the intended data rates of operation above 5.0 GT/s. In that case, the software based mechanism must be executed in order to perform the equalization procedure for the intended data rates of operation above 5.0 GT/s, not covered by the autonomous mechanism. For example, if both components advertised 8.0 GT/ s, 16.0 GT/s, and 32.0 GT/s Data Rates but autonomous equalization was performed for only 8.0 GT/s and 16.0 GT/s Data Rates, then software based mechanism must be adopted for equalization at 32.0 GT/s Data Rate. 16980 16981 16982 In the autonomous mechanism, after entering L0, irrespective of the current Link speed, neither component must transmit any DLLP if the equalization procedure must be performed and until the equalization procedure completes. The equalization procedure is considered complete once the Transmitter and Receiver setup of each Lane has been adjusted for each common data rate supported above 5.0 GT/s for which the Downstream Port intends to perform equalization using the autonomous mechanism. The Downstream Port is required to initiate the speed change to the data rate where the equalization needs to be performed. During any equalization (autonomous or software initiated or re-equalization), the Downstream Port must not advertise support for any data rate above the data rate for which equalization needs to be performed in Recovery. The following example is provided to illustrate the equalization flow. 16983 16984 16985 Page 262 Example: Consider a Link where equalization needs to be performed autonomously at 8.0 GT/s, and 16.0 GT/s. The Downstream Port enters Recovery to perform equalization at 8.0 GT/s by not advertising any data rates above 8.0 GT/s. The 8.0 GT/s equalization procedure is deemed to have been successfully executed if the Equalization 8.0 GT/s Phase 3 Successful bit and Equalization 8.0 GT/s Complete bit of the Link Status 2 register are both set to 1b. Immediately following the transition from Recovery to L0, after the initial data rate change to 8.0 GT/s, the Downstream Port is required to transition from L0 to Recovery, advertise 16.0 GT/s data rate support (but not advertise support for 32.0 GT/s, even if it is capable of supporting 32.0 GT/s), change the data /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16985 Example: Consider a Link where equalization needs to be performed autonomously at 8.0 GT/s, and 16.0 GT/s. The Downstream Port enters Recovery to perform equalization at 8.0 GT/s by not advertising any data rates above 8.0 GT/s. The 8.0 GT/s equalization procedure is deemed to have been successfully executed if the Equalization 8.0 GT/s Phase 3 Successful bit and Equalization 8.0 GT/s Complete bit of the Link Status 2 register are both set to 1b. Immediately following the transition from Recovery to L0, after the initial data rate change to 8.0 GT/s, the Downstream Port is required to transition from L0 to Recovery, advertise 16.0 GT/s data rate support (but not advertise support for 32.0 GT/s, even if it is capable of supporting 32.0 GT/s), change the data rate to 16.0 GT/s and perform the 16.0 GT/s equalization procedure. 16986 16987 16988 16338 16989 16339 16340 16990 Components using the autonomous mechanism must not initiate any autonomous Link width downsizing until the equalization procedure completes. An Upstream Port must not transmit any DLLP until it receives a DLLP from the Downstream Port. If the Downstream Port performs equalization again, it must not transmit any DLLP until it completes the equalization procedure. A Downstream Port may perform equalization again based on its own needs or based on the request from the Upstream Port, if it can meet its system requirements. Executing equalization multiple times may interfere with software determination of Link and device status, as described in Section 6.6 PCI Express Reset - Rules . 16991 16341 16992 16342 16993 16343 16344 16345 16995 16996 16997 16347 16998 16348 Page Components using the autonomous mechanism must not initiate any autonomous Link width downsizing until the equalization procedure completes. An Upstream Port must not transmit any DLLP until it receives a DLLP from the Downstream Port. If the Downstream Port performs equalization again, it must not transmit any DLLP until it completes the equalization procedure. A Downstream Port may perform equalization again based on its own needs or based on the request from the Upstream Port, if it can meet its system requirements. Executing equalization multiple times may interfere with software determination of Link and device status, as described in Section 6.6 PCI Express Reset - Rules . 16994 Implementation Note DLLP Blocking During Autonomous Equalization 16346 16349 If the Downstream Port detects equalization problems or the Upstream Port made an equalization redo request (by setting the Request Equalization bit to 1b) the Downstream Port may redo equalization prior to proceeding to operate at the data rate where the equalization failed or performing equalization at a higher data rate. The number of back-toback equalization redos at a given data rate is implementation specific but must be finite. If at the conclusion of the initial or subsequent equalization process and the execution of an implementation specific number of equalization redo’s, the Link is not able to operate reliably at the data rate where equalization was performed, then it must revert back to a lower data rate of operation. Implementation Note DLLP Blocking During Autonomous Equalization 16999 When using the autonomous mechanism for equalization at 8.0 GT/s or higher data rates, the Downstream Port is required to block the transmission of DLLPs until equalization has completed, and the Upstream Port is required to block the transmission of DLLPs until a DLLP is received from the Downstream Port. If both components advertise that they are capable of the 16.0 GT/s data rate but the Downstream Port only uses the autonomous mechanism for equalization at 8.0 GT/s, the Downstream Port is only required to block DLLP transmission until 8.0 GT/ 263 s equalization has completed. If the Downstream Port delays entering Recovery from L0 while DLLP transmission is blocked, either the L0 Inferred Electrical Idle timeout (see Section 4.2.4.3 Inferring Electrical Idle ) or the DLLP timeout (see Section 2.6.1.2 FC Information Tracked by Receiver ) may expire in the Upstream or Downstream Ports. If either of these two timeouts occurs, it will result in the initiation of an entry to Recovery to perform Link retraining. Neither of these two timeouts is a reportable error condition, and the resulting Link 17000 When using the autonomous mechanism for equalization at 8.0 GT/s or higher data rates, the Downstream Port is required to block the transmission of DLLPs until equalization has completed, and the Upstream Port is required to block the transmission of DLLPs until a DLLP is received from the Downstream Port. If both components advertise that they are capable of the 16.0 GT/s (or 32.0 GT/s) data rate but the Downstream Port only uses the autonomous mechanism for equalization at 8.0 GT/s, the Downstream Port is only required to block DLLP transmission until 8.0 GT/s equalization has completed. Similarly, if both components advertise that they are capable of the 32.0 GT/s data rate but the Downstream Port only uses the autonomous mechanism for equalization at 16.0 GT/s, the Downstream Port is only required to block DLLP transmission until 16.0 GT/s equalization has completed. If the Downstream Port delays entering Recovery from L0 while DLLP transmission is blocked, either the L0 Inferred Electrical Idle timeout (see Section 4.2.4.4 Inferring Electrical Idle ) or the DLLP timeout (see Section 16349 17000 When using the autonomous mechanism for equalization at 8.0 GT/s or higher data rates, the Downstream Port is required to block the transmission of DLLPs until equalization has completed, /private/tmp/PCISIG/pcie4_combined-snapshot.html vs.and the Upstream Port is required to block the transmission of DLLPs until a DLLP /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html is received from the Downstream Port. If both components advertise that they are capable of the 16.0 GT/s data rate but the Downstream Port only uses the autonomous mechanism for equalization at 8.0 GT/s, the Downstream Port is only required to block DLLP transmission until 8.0 GT/ s equalization has completed. If the Downstream Port delays entering Recovery from L0 while DLLP transmission is blocked, either the L0 Inferred Electrical Idle timeout (see Section 4.2.4.3 Inferring Electrical Idle ) or the DLLP timeout (see Section 2.6.1.2 FC Information Tracked by Receiver ) may expire in the Upstream or Downstream Ports. If either of these two timeouts occurs, it will result in the initiation of an entry to Recovery to perform Link retraining. Neither of these two timeouts is a reportable error condition, and the resulting Link retraining has no impact on proper Link operation. When using the autonomous mechanism for equalization at 8.0 GT/s or higher data rates, the Downstream Port is required to block the transmission of DLLPs until equalization has completed, and the Upstream Port is required to block the transmission of DLLPs until a DLLP is received from the Downstream Port. If both components advertise that they are capable of the 16.0 GT/s (or 32.0 GT/s) data rate but the Downstream Port only uses the autonomous mechanism for equalization at 8.0 GT/s, the Downstream Port is only required to block DLLP transmission until 8.0 GT/s equalization has completed. Similarly, if both components advertise that they are capable of the 32.0 GT/s data rate but the Downstream Port only uses the autonomous mechanism for equalization at 16.0 GT/s, the Downstream Port is only required to block DLLP transmission until 16.0 GT/s equalization has completed. If the Downstream Port delays entering Recovery from L0 while DLLP transmission is blocked, either the L0 Inferred Electrical Idle timeout (see Section 4.2.4.4 Inferring Electrical Idle ) or the DLLP timeout (see Section 2.6.1.2 FC Information Tracked by Receiver ) may expire in the Upstream or Downstream Ports. If either of these two timeouts occurs, it will result in the initiation of an entry to Recovery to perform Link retraining. Neither of these two timeouts is a reportable error condition, and the resulting Link retraining has no impact on proper Link operation. 17001 17002 17003 16350 17004 17005 16351 17006 17007 17008 16352 Page 8.0 GT/s: Equalization 8.0 GT/s Phase 3 Successful bit and Equalization 8.0 GT/s Complete bit of the Link Status 2 register are both set to 1b; 16.0 GT/s: Equalization 16.0 GT/s Phase 3 Successful bit and Equalization 16.0 GT/s Complete bit of the 16.0 GT/s Status Register are both set to 1b. 17009 16353 16354 When using the software based mechanism, software must guarantee that there will be no side-effects for transactions in flight (e.g., no timeout), if any, due to the Link undergoing the equalization procedure. Software can write 1b to the Perform Equalization bit in the Link Control 3 Register, followed by a write to the Target Link Speed field in the Link Control 2 register to enable the Link to run at 8.0 GT/ s or higher, followed by a write of 1b to the Retrain Link bit in the Link Control register of the Downstream Port to perform equalization. Software must not enable the Link to run at a data rate above 8.0 GT/s during a software initiated equalization procedure if the equalization procedure at all the lower data rates starting with 8.0 GT/s have not been successfully executed and the Link is not capable of bypassing equalization to higher data rate(s) (i.e., either Equalization bypass to highest rate Supported is 0b or Equalization bypass to highest rate Disable is 1b). The equalization procedure is deemed successful as follows for the following data rates: 17010 When using the software based mechanism, software must guarantee that there will be no side-effects for transactions in flight (e.g., no timeout), if any, due to the Link undergoing the equalization procedure. Software can write 1b to the Perform Equalization bit in the Link Control 3 register, followed by a write to the Target Link Speed field in the Link Control 2 register to enable the Link to run at 8.0 GT/ s or higher, followed by a write of 1b to the Retrain Link bit in the 264 Link Control register of the Downstream Port to perform equalization. Software must not enable the Link to run at 16.0 GT/s during a software initiated equalization procedure if the 8.0 GT/s equalization procedure has not been successfully executed. The 8.0 GT/s equalization procedure is deemed to have been successfully executed if the Equalization 8.0 GT/s Phase 3 Successful bit and Equalization 8.0 GT/s Complete bit of the Link Status 2 register are both set to 1b. Software may set the Hardware Autonomous Width Disable of the Link Control register in both components 17011 Software may set the Hardware Autonomous Width Disable of the Link Control register in both components or use some other mechanism to ensure that the Link is in its full functional width prior to setting the Perform Equalization bit in the Downstream Port. The component that had initiated the autonomous width downsizing is responsible to upconfigure the Link to go to its full functional width by initiating the transition to Recovery and Configuration within 1 ms of the Hardware Autonomous Width Disable bit being set to 1b. If an Upstream Port does not advertise the 8.0 GT/s data rate, the 16.0 GT/s data rate, or the 32.0 GT/s data rate initially and did not participate in the autonomous equalization mechanism for the non-advertised rates, its associated software must ensure there will be no side-effects for transactions in flight, if any, during equalization, before it instructs the Upstream Port to go to Recovery and advertise the previously non-advertised data rates and initiate a speed change. The Downstream Port subsequently initiates the 16354 When using the software based mechanism, software must 17011 guarantee that there will be no side-effects for transactions /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. in flight (e.g., no timeout), if any, due to the Link undergoing the equalization /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html procedure. Software can write 1b to the Perform Equalization bit in the Link Control 3 register, followed by a write to the Target Link Speed field in the Link Control 2 register to enable the Link to run at 8.0 GT/ s or higher, followed by a write of 1b to the Retrain Link bit in the Link Control register of the Downstream Port to perform equalization. Software must not enable the Link to run at 16.0 GT/s during a software initiated equalization procedure if the 8.0 GT/s equalization procedure has not been successfully executed. The 8.0 GT/s equalization procedure is deemed to have been successfully executed if the Equalization 8.0 GT/s Phase 3 Successful bit and Equalization 8.0 GT/s Complete bit of the Link Status 2 register are both set to 1b. Software may set the Hardware Autonomous Width Disable of the Link Control register in both components or use some other mechanism to ensure that the Link is in its full functional width prior to setting the Perform Equalization bit in the Downstream Port. The component that had initiated the autonomous width downsizing is responsible to upconfigure the Link to go to its full functional width by initiating the transition to Recovery and Configuration within 1 ms of the Hardware Autonomous Width Disable bit being set to 1b. If an Upstream Port does not advertise the 8.0 GT/s data rate, the 16.0 GT/s data rate, or both the 8.0 GT/s and 16.0 GT/s data rates initially and did not participate in the autonomous equalization mechanism for the non-advertised rates, its associated software must ensure there will be no side-effects for transactions in flight, if any, during equalization, before it instructs the Upstream Port to go to Recovery and advertise the previously non-advertised data rates and initiate a speed change. The Downstream Port subsequently initiates the equalization procedure during the initial speed change to the data rate advertised by the Upstream Port when it transitions to Recovery. If the Upstream Port advertises support for both 8.0 GT/s and 16.0 GT/s data rates after advertising support for less than 8.0 GT/s initially, the Downstream Port must advertise 8.0 GT/s support only and perform an 8.0 GT/s speed change and equalization procedure prior to performing speed changes and equalization procedures at the higher data rate. Upon completion of the 8.0 GT/s speed change and equalization, the Downstream Port must advertise its next highest data rate supported and, if the same rate is supported by the Upstream Port, transition from L0 to Recovery in order to perform a speed change to the higher data rate and initiate equalization at that speed. The 16.0 GT/s equalization procedure must be initiated when operating at 8.0 GT/s. 16355 17012 16356 16357 Page Software may set the Hardware Autonomous Width Disable of the Link Control register in both components or use some other mechanism to ensure that the Link is in its full functional width prior to setting the Perform Equalization bit in the Downstream Port. The component that had initiated the autonomous width downsizing is responsible to upconfigure the Link to go to its full functional width by initiating the transition to Recovery and Configuration within 1 ms of the Hardware Autonomous Width Disable bit being set to 1b. If an Upstream Port does not advertise the 8.0 GT/s data rate, the 16.0 GT/s data rate, or the 32.0 GT/s data rate initially and did not participate in the autonomous equalization mechanism for the non-advertised rates, its associated software must ensure there will be no side-effects for transactions in flight, if any, during equalization, before it instructs the Upstream Port to go to Recovery and advertise the previously non-advertised data rates and initiate a speed change. The Downstream Port subsequently initiates the equalization procedure during the initial speed change to the data rate advertised by the Upstream Port when it transitions to Recovery. 17013 Upstream Ports are required to check for equalization setting problems in the Recovery.RcvrLock state (see Section 4.2.6.4.1 Recovery.RcvrLock ). However, both Downstream and Upstream Ports are permitted to use implementation-specific methods to detect equalization problems at any time. A Port that detects a problem with its 8.0 GT/s data rate equalization settings must set the Link Equalization Request 8.0 GT/s bit in its Link Status 2 register to 1b, and a Port that detects a problem with its 16.0 GT/s data rate equalization settings must set the Link Equalization Request 16.0 GT/s bit in its 16.0 GT/s Status register to 1b. In addition to setting the appropriate Link Equalization Request bit, an Upstream Port must initiate a transition to Recovery (if necessary) and request equalization at the appropriate data rate in the Recovery.RcvrCfg state by setting the Request Equalization bit of its 265 transmitted TS2 Ordered Sets to 1b and the Equalization Request Data Rate bit to the data rate of the detected problem. If it requests equalization, it must request equalization for each detected problem only once. When requesting equalization, the Upstream Port is also permitted, but not required, to set the Quiesce Guarantee bit to 1b to inform the Downstream Port that an equalization process initiated within 1 ms will not cause any side-effects to its operation. 17014 Upstream Ports are required to check for equalization setting problems in the Recovery.RcvrLock state (see Section 4.2.6.4.1 Recovery.RcvrLock ). However, both Downstream and Upstream Ports are permitted to use implementation-specific methods to detect equalization problems at any time. A Port that detects a problem with its equalization settings is required to undertake the following actions, for each the following data rates: Upstream Ports are required to check for equalization setting problems in the Recovery.RcvrLock state (see Section 4.2.6.4.1 Recovery.RcvrLock ). However, both Downstream and Upstream Ports are permitted to use implementation-specific methods to detect equalization problems at any time. A Port that detects a problem with its 8.0 GT/s data rate equalization settings must set the Link Equalization Request 8.0 GT/s bit in its Link Status 2 register to 1b, and a Port that detects a problem with its 16.0 GT/s data rate equalization settings must set the /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. Link Equalization Request 16.0 GT/s bit in its 16.0 GT/s Status register to 1b. In addition to setting the appropriate Link Equalization Request /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html bit, an Upstream Port must initiate a transition to Recovery (if necessary) and request equalization at the appropriate data rate in the Recovery.RcvrCfg state by setting the Request Equalization bit of its transmitted TS2 Ordered Sets to 1b and the Equalization Request Data Rate bit to the data rate of the detected problem. If it requests equalization, it must request equalization for each detected problem only once. When requesting equalization, the Upstream Port is also permitted, but not required, to set the Quiesce Guarantee bit to 1b to inform the Downstream Port that an equalization process initiated within 1 ms will not cause any side-effects to its operation. 16358 17015 17016 17017 17018 16359 16360 17019 When a Downstream Port receives an equalization request from an Upstream Port (when it is in the Recovery.RcvrCfg state and receives 8 consecutive TS2 Ordered Sets with the Request Equalization bit set to 1b), it must either initiate an equalization process at the requested data rate (as defined by the received Equalization Request Data Rate bit) within 1 ms of completing the next Recovery to L0 transition, or it must set the appropriate Link Equalization Request 8.0 GT/s in its Link Status 2 register or Link Equalization Request 16.0 GT/s bit in its 16.0 GT/s Statusregister. It should initiate an equalization process only if it can guarantee that executing the equalization process will not cause any side-effects to either its operation or the Upstream Port's operation. The Downstream Port is permitted, but not required, to use the received Quiesce Guarantee bit to determine the Upstream Port's ability to execute an equalization process without side-effects. 16361 17020 17021 16362 16363 Page 8.0 GT/s: Link Equalization Request 8.0 GT/s bit in the Link Status 2 register is set to 1b; 16.0 GT/s: Link Equalization Request 16.0 GT/s bit in the 16.0 GT/s Status Register is set to 1b 32.0 GT/s: Link Equalization Request 32.0 GT/s bit in its 32.0 GT/s Status Register is set to 1b. In addition to setting the appropriate Link Equalization Request bit to 1b, an Upstream Port must initiate a transition to Recovery (if necessary) and request equalization at the appropriate data rate in the Recovery.RcvrCfg state by setting the Request Equalization bit of its transmitted TS2 Ordered Sets to 1b and the Equalization Request Data Rate bits to the data rate of the detected problem. If it requests equalization, it must request equalization for each detected problem only once. When requesting equalization, the Upstream Port is also permitted, but not required, to set the Quiesce Guarantee bit to 1b to inform the Downstream Port that an equalization process initiated within 1 ms will not cause any side-effects to its operation. 17022 If a Downstream Port wants to initiate an equalization process and can guarantee that it will not cause side-effects to its own operation but is unable to directly determine whether the equalization process will cause side-effects to the Upstream Port's operation, then it is permitted to request that the Upstream Port initiate an equalization request. The Downstream Port does so by transitioning to Recovery and in the Recovery.RcvrCfg state setting the Request Equalization bit of its transmitted TS2 Ordered Sets to 1b, the Equalization Request Data Rate 266 bit to the desired data rate, and the Quiesce Guarantee bit to 1b. When an Upstream Port receives such an equalization request from a Downstream Port (when it is in the Recovery.RcvrCfg state and receives 8 consecutive TS2 Ordered Sets with the Request Equalization and Quiesce Guarantee bits set to 1b), it is permitted, but not required, to quiesce its operation and prepare to execute an equalization process at the data rate requested by the Downstream Port, and then request equalization at that same data rate (using the method described previously for reporting equalization 17023 17024 When a Downstream Port receives an equalization request from an Upstream Port (when it is in the Recovery.RcvrCfg state and receives 8 consecutive TS2 Ordered Sets with the Request Equalization bit set to 1b), it must either initiate an equalization process at the requested data rate (as defined by the received Equalization Request Data Rate bits) within 1 ms of completing the next Recovery to L0 transition, or it must set the appropriate Link Equalization Request 8.0 GT/s in its Link Status 2 register or Link Equalization Request 16.0 GT/s bit in its 16.0 GT/s Status Register or Link Equalization Request 32.0 GT/s bit in its 32.0 GT/s Status Register. It should initiate an equalization process only if it can guarantee that executing the equalization process will not cause any side-effects to either its operation or the Upstream Port's operation. The Downstream Port is permitted, but not required, to use the received Quiesce Guarantee bit to determine the Upstream Port's ability to execute an equalization process without side-effects. 16363 If a Downstream Port wants to initiate an equalization process and can guarantee that it will not cause side-effects to its own operation but is unable to directly determine whether the equalization /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. process will cause side-effects to the Upstream Port's operation, then it is permitted to request that the Upstream Port initiate an equalization /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html request. The Downstream Port does so by transitioning to Recovery and in the Recovery.RcvrCfg state setting the Request Equalization bit of its transmitted TS2 Ordered Sets to 1b, the Equalization Request Data Rate bit to the desired data rate, and the Quiesce Guarantee bit to 1b. When an Upstream Port receives such an equalization request from a Downstream Port (when it is in the Recovery.RcvrCfg state and receives 8 consecutive TS2 Ordered Sets with the Request Equalization and Quiesce Guarantee bits set to 1b), it is permitted, but not required, to quiesce its operation and prepare to execute an equalization process at the data rate requested by the Downstream Port, and then request equalization at that same data rate (using the method described previously for reporting equalization setting problems) and with the Quiesce Guarantee bit set to 1b. There is no time limit on how long the Upstream Port can take to respond, but it should attempt to do so as quickly as possible. If a Downstream Port makes a request and receives such a response from the Upstream Port, then it must either initiate an equalization process at the agreed-upon data rate within 1 ms of completing the next Recovery to L0 transition if it can still guarantee that executing the equalization process will not cause any side-effects to its operation, or it must set the appropriate Link Equalization Request 8.0 GT/s in its Link Status 2 register or Link Equalization Request 16.0 GT/s bit in its 16.0 GT/s Status register . 17024 17025 17026 17027 16364 17028 16365 17029 16366 16367 16368 17031 17032 17033 16370 17034 16371 Page If a Downstream Port wants to initiate an equalization process and can guarantee that it will not cause side-effects to its own operation but is unable to directly determine whether the equalization process will cause side-effects to the Upstream Port's operation, then it is permitted to request that the Upstream Port initiate an equalization request. The Downstream Port does so by transitioning to Recovery and in the Recovery.RcvrCfg state setting the Request Equalization bit of its transmitted TS2 Ordered Sets to 1b, the Equalization Request Data Rate bits to the desired data rate, and the Quiesce Guarantee bit to 1b. When an Upstream Port receives such an equalization request from a Downstream Port (when it is in the Recovery.RcvrCfg state and receives 8 consecutive TS2 Ordered Sets with the Request Equalization and Quiesce Guarantee bits set to 1b), it is permitted, but not required, to quiesce its operation and prepare to execute an equalization process at the data rate requested by the Downstream Port, and then request equalization at that same data rate (using the method described previously for reporting equalization setting problems) and with the Quiesce Guarantee bit set to 1b. There is no time limit on how long the Upstream Port can take to respond, but it should attempt to do so as quickly as possible. If a Downstream Port makes a request and receives such a response from the Upstream Port, then it must either initiate an equalization process at the agreed-upon data rate within 1 ms of completing the next Recovery to L0 transition if it can still guarantee that executing the equalization process will not cause any side-effects to its operation, or it must set the appropriate Link Equalization Request 8.0 GT/s in its Link Status 2 register or Link Equalization Request 16.0 GT/s bit in its 16.0 GT/s Status Register or Link Equalization Request 32.0 GT/s bit in its 32.0 GT/s Status Register. 17030 Implementation Note Using Quiesce Guarantee Mechanism 16369 16372 When a Downstream Port receives an equalization request from an Upstream Port (when it is in the Recovery.RcvrCfg state and receives 8 consecutive TS2 Ordered Sets with the Request Equalization bit set to 1b), it must either initiate an equalization process at the requested data rate (as defined by the received Equalization Request Data Rate bits) within 1 ms of completing the next Recovery to L0 transition, or it must set the appropriate Link Equalization Request 8.0 GT/s in its Link Status 2 register or Link Equalization Request 16.0 GT/s bit in its 16.0 GT/s Status Register or Link Equalization Request 32.0 GT/s bit in its 32.0 GT/s Status Register. It should initiate an equalization process only if it can guarantee that executing the equalization process will not cause any side-effects to either its operation or the Upstream Port's operation. The Downstream Port is permitted, but not required, to use the received Quiesce Guarantee bit to determine the Upstream Port's ability to execute an equalization process without side-effects. Implementation Note Using Quiesce Guarantee Mechanism 17035 Side-effects due to executing equalization after the Data Link Layer is in DL_Active can occur at the Port, Device, or system level. For example, the time required to execute the equalization process could cause a Completion Timeout error to occur - possibly in a different 267 system component. The Quiesce Guarantee information can help Ports decide whether to execute a requested equalization or not. 17036 Side-effects due to executing equalization after the Data Link Layer is in DL_Active can occur at the Port, Device, or system level. For example, the time required to execute the equalization process could cause a Completion Timeout error to occur - possibly in a different system component. The Quiesce Guarantee information can help Ports decide whether to execute a requested equalization or not. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 16372 Side-effects due to executing equalization after the Data /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17036 Link Layer is in DL_Active can occur at the Port, Device, or system level. For example, the time required to execute the equalization process could cause a Completion Timeout error to occur - possibly in a different system component. The Quiesce Guarantee information can help Ports decide whether to execute a requested equalization or not. 16373 17037 16374 17038 16375 17039 16376 16377 Side-effects due to executing equalization after the Data Link Layer is in DL_Active can occur at the Port, Device, or system level. For example, the time required to execute the equalization process could cause a Completion Timeout error to occur - possibly in a different system component. The Quiesce Guarantee information can help Ports decide whether to execute a requested equalization or not. 17040 A component may operate at a lower data rate after reporting its equalization problems, either by timing out through Recovery.Speed or by initiating a data rate change to a lower data rate. Any data rate change required to perform the equalization procedure is exempt from the 200 ms requirement in Section 6.11 Link Speed Management . If the Downstream Port wants to redo equalization at 8.0 GT/s and the current data rate is either 2.5 GT/s or 5.0 GT/s, the Downstream Port must request speed change through Equalization (EQ) TS1 Ordered Sets in Recovery.RcvrLock to inform the Upstream Port that it intends to redo equalization. An Upstream Port should advertise 8.0 GT/s data rate in Recovery if it receives EQ TS1 Ordered Sets with speed change bit set to 1b and if it intends to operate at 8.0 GT/s data rate in the future. If the Downstream Port wants to redo equalization at 16.0 GT/s and the current data rate is either 2.5 GT/s or 5.0 GT/s, the Downstream Port must first initiate a speed change to 8.0 GT/s (the 8.0 GT/s equalization procedure will not be executed unless necessary). If the Downstream Port wants to redo equalization at 16.0 GT/s and the current data rate is 8.0 GT/s, the Downstream Port must request speed change through TS1 Ordered Sets in Recovery.RcvrLock with the Equalization Redo bit set to 1b to inform the Upstream Port that it intends to redo equalization. An Upstream Port should advertise 16.0 GT/s data rate in Recovery if it receives TS1 Ordered Sets with speed change bit set to 1b, Equalization Redo bit set to 1b and it intends to operate at 16.0 GT/s data rate in the future. The equalization procedure can be performed at most once in each trip through the Recovery state. 17041 A component may operate at a lower data rate after reporting its equalization problems, either by timing out through Recovery.Speed or by initiating a data rate change to a lower data rate. Any data rate change required to perform the equalization procedure is exempt from the 200 ms requirement in Section 6.11 Link Speed Management . Table 4-3 Equalization requirements under different conditions describes the mechanism for performing redo Equalization. Sometimes it may be necessary to perform a speed change to an intermediate data rate to redo equalization. For example, if the Downstream Port wants to redo equalization at 16.0 GT/s, bypass equalization is not supported, and the current data rate is either 2.5 GT/s or 5.0 GT/s, the Downstream Port must first initiate a speed change to 8.0 GT/s (the 8.0 GT/s equalization procedure will not be executed unless necessary) from which it will launch the redo equalization for 16.0 GT/s . The equalization procedure can be performed at most once in each trip through the Recovery state. 17042 17043 17044 17045 Table 4-3 Equalization requirements under different conditions 17046 17047 From 2.5 GT/s or 5.0 GT/s to 8.0 GT/s Equalization 17048 17049 17050 The mechanisms described here are identical for all flavors of equalization: initial or redo equalization; autonomous or software initiated. 17051 17052 17053 The Downstream Port communicates the Transmitter preset values and the Receiver preset hints, if applicable, for each Lane to the Upstream Port using 8b/10b encoding. These values are communicated using the EQ TS2 Ordered Sets (defined in Section 4.2.4.1 Training Sequences ) in Recovery.RcvrCfg, when a data rate change to the higher data rate has been negotiated, prior to transitioning to the higher data rate to perform equalization. The preset values sent in the EQ TS2 Ordered Sets are derived as follows: 17054 17055 17056 17057 Page 268 For equalization at 8.0 GT/s: Upstream Port 8.0 GT/s Transmitter Preset and Upstream Port 8.0 GT/s Receiver Preset Hint fields of each Lane Equalization Control Register Entry. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17057 17058 After the data rate change to the higher data rate where equalization needs to be performed, the Upstream Port transmits TS1 Ordered Sets with the preset values it received. The preset values must be within the operable range defined in Section 8.3.3.3 Tx Equalization Presets if reduced swing will be used by the Transmitter. 17059 17060 17061 After the data rate change to the higher data rate where equalization needs to be performed, the Downstream Port transmits TS1 Ordered Sets with the preset values as follows with the assumption that the preset values must be within the operable range defined in Section 8.3.3.3 Tx Equalization Presets if reduced swing will be used by the Transmitter: 17062 17063 For equalization at 8.0 GT/s: Downstream Port 8.0 GT/ s Transmitter Preset and optionally Downstream Port 8.0 GT/s Receiver Preset Hint fields of each Lane Equalization Control Register Entry. 17064 17065 17066 To perform redo equalization, the Downstream Port must request speed change through EQ TS1 Ordered Sets in Recovery.RcvrLock at 2.5 GT/s or 5.0 GT/s to inform the Upstream Port that it intends to redo equalization at the higher data rate. An Upstream Port should advertise the higher data rate in Recovery if it receives EQ TS1 Ordered Sets with speed change bit set to 1b and if it intends to operate at the higher data rate in the future. 17067 17068 17069 17070 17071 17072 17073 From 8.0 GT/s to 16.0 GT/s equalization OR from 16.0 GT/s to 32.0 GT/s equalization 17074 17075 17076 The mechanisms described here are identical for all flavors of equalization: initial or redo equalization; autonomous or software initiated. 17077 17078 17079 When negotiating to the higher data rate, the Downstream Port communicates the Transmitter preset values for each Lane to the Upstream Port using 128b/130b encoding. These values are communicated using 128b/130b EQ TS2 Ordered Sets (defined in Section 4.2.4.1 Training Sequences ) in Recovery.RcvrCfg, when a data rate change to the higher data rate has been negotiated, prior to transitioning to the higher data rate. The preset values sent in the 128b/130b EQ TS2 Ordered Sets are derived as follows: 17080 17081 Page 269 For equalization at 16.0 GT/s: Upstream Port 16.0 GT/ s Transmitter Preset field of the 16.0 GT/s Lane Equalization Control Register Entry corresponding to the Lane. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17081 17082 For equalization at 16.0 GT/s: Upstream Port 16.0 GT/ s Transmitter Preset field of the 16.0 GT/s Lane Equalization Control Register Entry corresponding to the Lane. For equalization at 32.0 GT/s: Upstream Port 32.0 GT/s Transmitter Preset field of the 32.0 GT/s Lane Equalization Control Register Entry corresponding to the Lane. 17083 17084 17085 Optionally, the Upstream Port communicates initial Transmitter preset settings to the Downstream Port using the 128b/130b EQ TS2 Ordered Sets sent in Recovery.RcvrCfg, when a data rate change to the higher data rate has been negotiated, prior to transitioning to the higher data rate at which equalization needs to be performed. These preset values are determined by implementation specific means. After the data rate change to the higher data rate, the Upstream Port transmits TS1 Ordered Sets with the preset values it received. If the Downstream Port did not receive preset values in Recovery.RcvrCfg, after the data rate change to the higher data rate, it transmits TS1 Ordered Sets with the presets as follows: 17086 17087 17088 For equalization at 16.0 GT/s: Downstream Port 16.0 GT/s Transmitter Preset field of the 16.0 GT/s Lane Equalization Control Register Entry corresponding to the Lane. For equalization at 32.0 GT/s: Downstream Port 32.0 GT/s Transmitter Preset field of the 32.0 GT/s Lane Equalization Control Register Entry corresponding to the Lane. 17089 17090 17091 The preset values must be within the operable range defined in Section 8.3.3.3 Tx Equalization Presets if reduced swing will be used by the Transmitter. 17092 17093 17094 To perform redo equalization, the Downstream Port must request speed change through TS1 Ordered Sets in Recovery.RcvrLock with the Equalization Redo bit set to 1b to inform the Upstream Port that it intends to redo equalization. An Upstream Port should advertise the higher data rate in Recovery if it receives TS1 Ordered Sets with speed change bit set to 1b, Equalization Redo bit set to 1b and it intends to operate at the higher data rate in the future. 17095 17096 17097 17098 17099 From 2.5 GT/s or 5.0 GT/s to 32.0 GT/s Equalization 17100 17101 17102 Page 270 Equalization to 32.0 GT/s or higher data rate from 2.5 GT/s or 5.0 GT/s is possible only if the Link is capable of bypassing equalization to higher data rate(s) (i.e., Equalization bypass to highest rate Supported in 32.0 GT/s Capabilities register is 1b and Equalization bypass to highest rate Disable in the 32.0 GT/s Control Register is 0b). /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17102 Equalization to 32.0 GT/s or higher data rate from 2.5 GT/s or 5.0 GT/s is possible only if the Link is capable of bypassing equalization to higher data rate(s) (i.e., Equalization bypass to highest rate Supported in 32.0 GT/s Capabilities register is 1b and Equalization bypass to highest rate Disable in the 32.0 GT/s Control Register is 0b). 17103 17104 17105 The mechanisms described here are identical for all flavors of equalization: initial or redo equalization; autonomous or software initiated. 17106 17107 17108 The Downstream Port communicates the Transmitter preset values and the Receiver preset hints, if applicable, for each Lane to the Upstream Port using 8b/10b encoding. These values are communicated using the EQ TS2 Ordered Sets (defined in Section 4.2.4.1 Training Sequences ) in Recovery.RcvrCfg, when a data rate change to the higher data rate has been negotiated, prior to transitioning to the higher data rate to perform equalization. The preset values sent in the EQ TS2 Ordered Sets are derived as follows: 17109 17110 For equalization at 32.0 GT/s: Upstream Port 32.0 GT/ s Transmitter Preset field of the 32.0 GT/s Lane Equalization Control Register Entry corresponding to the Lane. The Receiver Preset Hint field must be set to 000b. 17111 17112 17113 After the data rate change to the higher data rate where equalization needs to be performed, the Upstream Port transmits TS1 Ordered Sets with the preset values it received. The preset values must be within the operable range defined in Section 8.3.3.3 Tx Equalization Presets if reduced swing will be used by the Transmitter. 17114 17115 17116 After the data rate change to the higher data rate where equalization needs to be performed, the Downstream Port transmits TS1 Ordered Sets with the preset values as follows with the assumption that the preset values must be within the operable range defined in Section 8.3.3.3 Tx Equalization Presets if reduced swing will be used by the Transmitter: 17117 17118 For equalization at 32.0 GT/s: Downstream Port 32.0 GT/s Transmitter Preset field of the 32.0 GT/s Lane Equalization Control Register Entry corresponding to the Lane. 17119 17120 17121 17122 Page 271 To perform redo equalization, the Downstream Port must request speed change through EQ TS1 Ordered Sets in Recovery.RcvrLock at 2.5 GT/s or 5.0 GT/s to inform the Upstream Port that it intends to redo equalization at the higher data rate. An Upstream Port should advertise the higher data rate in Recovery if it receives EQ TS1 Ordered Sets with speed change bit set to 1b and if it intends to operate at the higher data rate in the future. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17122 17123 17124 17125 17126 17127 Equalization at a data rate from a data rate equal to the target equalization data rate 17128 17129 17130 17131 This is only possible with a redo equalization. The combinations covered here are: 8.0 GT/s equalization from 8.0 GT/s data rate, 16.0 GT/s equalization from 16.0 GT/s data rate, and 32.0 GT/s equalization from 32.0 GT/s data rate. 17132 17133 17134 In this case, the initial preset used during equalization is equal to the initial preset used during the last time the equalization was performed at the data rate where equalization is being performed. 17135 17136 17137 17138 16378 17139 16379 16380 17140 The equalization procedure consists of up to four Phases, as described below. When operating at 8.0 GT/s or higher data rates, the Phase information is transmitted using the Equalization Control (EC) field in the TS1 Ordered Sets. 16381 17143 Phase 0: When negotiating to 8.0 GT/s, the Downstream Port communicates the 8.0 GT/s Transmitter preset values and the 8.0 GT/s Receiver preset hints for each Lane to the Upstream Port using 8b/10b encoding. These values are communicated using the EQ TS2 Ordered Sets (defined in Section 4.2.4.1 Training Sequences ) in Recovery.RcvrCfg, when a data rate change to 8.0 GT/s has been negotiated, prior to transitioning to 8.0 GT/s data rate. These preset values are derived from the Upstream Port 8.0 GT/s Transmitter Preset and Upstream Port 8.0 GT/s Receiver Preset Hint fields of each Lane’s Equalization Control register. After the data rate change to 8.0 GT/s, the Upstream Port transmits TS1 Ordered Sets with the preset values it received. The preset values must be within the operable range defined in Section 8.3.3.3 Tx Equalization Presets if reduced swing will be used by the Transmitter. 16384 17144 17146 17148 Page Phase 0 17145 This phase is executed while negotitating (and prior to) to the data rate where equalization would be performed. The preset to be used for equalization is determined as described in Table 4-3 Equalization requirements under different conditions . 17147 16385 16386 The equalization procedure consists of up to four Phases, as described below. When operating at 8.0 GT/s or higher data rates, the Phase information is transmitted using the Equalization Control (EC) field in the TS1 Ordered Sets. 17142 16382 16383 17141 17149 When negotiating to 16.0 GT/s, the Downstream Port communicates the 16.0 GT/s Transmitter preset values for each Lane to the Upstream Port using 128b/130b encoding. These values are communicated using 8GT EQ TS2 Ordered Sets (defined in Section 4.2.4.1 Training Sequences ) in Recovery.RcvrCfg, when a data rate change to 16.0 GT/s has 272 been negotiated, prior to transitioning to 16.0 GT/s data rate. These preset values are derived from the Upstream Port 16.0 GT/s Transmitter Preset field of the 16.0 GT/s Lane Equalization Control Register entry corresponding to the Lane. Optionally, the Upstream Port communicates initial 16.0 GT/s Transmitter preset settings to the Downstream Port using the 8GT EQ TS2 Ordered Sets sent in Recovery.RcvrCfg, when a data rate change to 16.0 GT/s has been negotiated, prior to transitioning to 16.0 GT/s data rate. These preset values are determined by implementation Phase 1 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 16386 When negotiating to 16.0 GT/s, the Downstream Port /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html communicates the 16.0 GT/s Transmitter preset values for each Lane to the Upstream Port using 128b/130b encoding. These values are communicated using 8GT EQ TS2 Ordered Sets (defined in Section 4.2.4.1 Training Sequences ) in Recovery.RcvrCfg, when a data rate change to 16.0 GT/s has been negotiated, prior to transitioning to 16.0 GT/s data rate. These preset values are derived from the Upstream Port 16.0 GT/s Transmitter Preset field of the 16.0 GT/s Lane Equalization Control Register entry corresponding to the Lane. Optionally, the Upstream Port communicates initial 16.0 GT/s Transmitter preset settings to the Downstream Port using the 8GT EQ TS2 Ordered Sets sent in Recovery.RcvrCfg, when a data rate change to 16.0 GT/s has been negotiated, prior to transitioning to 16.0 GT/s data rate. These preset values are determined by implementation specific means. After the data rate change to 16.0 GT/s, the Upstream Port transmits TS1 Ordered Sets with the preset values it received. If the Downstream Port received preset values in Recovery.RcvrCfg, after the data rate change to 16.0 GT/s, it transmits TS1 Ordered Sets with those preset values. The preset values must be within the operable range defined in Section 8.3.3.3 Tx Equalization Presets if reduced swing will be used by the Transmitter. 16387 17150 17151 16388 16389 17152 Phase 1: Both components make the Link operational enough at the current data rate to be able to exchange TS1 Ordered Sets to complete the remaining phases for the fine-tuning of their Transmitter/Receiver pairs. It is expected that the Link will operate at a BER of less than 10-4 before the component is ready to move on to the next Phase. 16390 17153 17154 16391 16392 Page Both components make the Link operational enough at the current data rate to be able to exchange TS1 Ordered Sets to complete the remaining phases for the fine-tuning of their Transmitter/Receiver pairs. It is expected that the Link will operate at a BER of less than 10-4 before the component is ready to move on to the next Phase. Each Transmitter uses the preset values as described in Table 4-3 Equalization requirements under different conditions . 17155 The Downstream Port initiates Phase 1 by transmitting TS1 Ordered Sets with EC=01b (indicating Phase 1) to the Upstream Port using the preset values received from the Upstream Port in Recovery.RcvrCfg if the current data rate of operation is 16.0 GT/s and eight consecutive 8GT EQ TS2 Ordered Sets were received in Recovery.RcvrCfg. Otherwise, the Downstream Port uses the preset values in the Downstream Port Transmitter Preset field of each Lane’s Equalization Control register applicable to the current data rate of operation. The Upstream Port, after adjusting its Receiver, if necessary, to ensure that it can progress with the equalization process, receives these TS1 Ordered Sets and transitions to 273 Phase 1 (where it transmits TS1 Ordered Sets with EC=01b). The Downstream Port ensures that it can reliably receive the bit stream from the Upstream Port to continue through the rest of the Phases when it receives TS1 Ordered Sets from the Upstream Port with EC=01b before it moves on to Phase 2. The Downstream Port initiates Phase 1 by transmitting TS1 Ordered Sets with EC=01b (indicating Phase 1). The Upstream Port, after adjusting its Receiver, if necessary, to ensure that it can progress with the equalization process, receives these TS1 Ordered Sets and transitions to Phase 1 (where it transmits TS1 Ordered Sets with EC=01b). The Downstream Port ensures that it can reliably receive the bit stream from the Upstream Port to continue through the rest of the Phases when it receives TS1 Ordered Sets from the Upstream Port with EC=01b before it moves on to Phase 2. 16392 The Downstream Port initiates Phase 1 by transmitting TS1 Ordered Sets with EC=01b (indicating Phase 1) to the Upstream Port using the preset values received from the Upstream Port in Recovery.RcvrCfg if the current data rate of operation is 16.0 GT/s and eight consecutive 8GT EQ TS2 Ordered Sets were received in Recovery.RcvrCfg. Otherwise, the /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. Downstream Port uses the preset values in the Downstream Port Transmitter Preset field of each Lane’s Equalization Control register applicable to /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html the current data rate of operation. The Upstream Port, after adjusting its Receiver, if necessary, to ensure that it can progress with the equalization process, receives these TS1 Ordered Sets and transitions to Phase 1 (where it transmits TS1 Ordered Sets with EC=01b). The Downstream Port ensures that it can reliably receive the bit stream from the Upstream Port to continue through the rest of the Phases when it receives TS1 Ordered Sets from the Upstream Port with EC=01b before it moves on to Phase 2. 16393 17156 17157 16394 16395 Phase 2: In this Phase the Upstream Port adjusts the Transmitter setting of the Downstream Port along with its own Receiver setting, independently, on each Lane, to ensure it receives the bit stream compliant with the requirements in Chapter 8 Electrical Sub-Block (e.g., all operational Downstream Lanes have a BER is less than 10-12). The Downstream Port initiates the move to Phase 2 by transmitting TS1 Ordered Sets with EC=10b to the Upstream Port. The Downstream Port advertises the Transmitter coefficients and the preset it is using per the rules below in Phase 1 for preset only and in Phase 2 for preset and coefficients. The Upstream Port receives these Ordered Sets and may request different coefficient or preset settings and continue to evaluate each setting until it arrives at the best setting for operating the Downstream Lanes. After the Upstream Port has completed this Phase, it moves the Link to Phase 3 by transmitting TS1 Ordered Sets with EC=11b to the Downstream Port. 16396 17159 17161 Phase 3: In this Phase the Downstream Port adjusts the Transmitter setting of the Upstream Port along with its own Receiver setting, independently, on each Lane, using a handshake and evaluation process similar to Phase 2 with the exception that EC=11b. The Downstream Port signals the end of Phase 3 (and the equalization procedure) by transmitting TS1 Ordered Sets with EC=00b. In this Phase the Downstream Port adjusts the Transmitter setting of the Upstream Port along with its own Receiver setting, independently, on each Lane, using a handshake and evaluation process similar to Phase 2 with the exception that EC=11b. The Downstream Port signals the end of Phase 3 (and the equalization procedure) by transmitting TS1 Ordered Sets with EC=00b. 17165 The algorithm used by a component to adjust the transmitter of its Link partner and the evaluation of that Transmitter set-up with its Receiver set-up is implementation-specific. A component may request changes to any number of Lanes and can request different settings for each Lane. Each requested setting can be a preset or a set of coefficients that meets the requirements defined in Section 4.2.3.1 Rules for Transmitter Coefficients . Each component is responsible for ensuring that at the end of the fine-tuning (Phase 2 for Upstream Ports and Phase 3 for Downstream Ports), its Link partner has the Transmitter setting in each Lane that will cause the Link to meet the requirements in Chapter 8 Electrical Sub-Block . 16402 17166 The algorithm used by a component to adjust the transmitter of its Link partner and the evaluation of that Transmitter set-up with its Receiver set-up is implementation-specific. A component may request changes to any number of Lanes and can request different settings for each Lane. Each requested setting can be a preset or a set of coefficients that meets the requirements defined in Section 4.2.3.1 Rules for Transmitter Coefficients . Each component is responsible for ensuring that at the end of the fine-tuning (Phase 2 for Upstream Ports and Phase 3 for Downstream Ports), its Link partner has the Transmitter setting in each Lane that will cause the Link to meet the requirements in Chapter 8 Electrical Sub-Block . 17167 16403 Page 17163 17164 16400 16404 Phase 3 17162 16399 16401 In this Phase the Upstream Port adjusts the Transmitter setting of the Downstream Port along with its own Receiver setting, independently, on each Lane, to ensure it receives the bit stream compliant with the requirements in Chapter 8 Electrical Sub-Block (e.g., each operational Downstream Lane has a BER less than 10-12). The Downstream Port initiates the move to Phase 2 by transmitting TS1 Ordered Sets with EC=10b to the Upstream Port. The Downstream Port advertises the Transmitter coefficients and the preset it is using per the rules below in Phase 1 for preset only and in Phase 2 for preset and coefficients. The Upstream Port receives these Ordered Sets and may request different coefficient or preset settings and continue to evaluate each setting until it arrives at the best setting for operating the Downstream Lanes. After the Upstream Port has completed this Phase, it moves the Link to Phase 3 by transmitting TS1 Ordered Sets with EC=11b to the Downstream Port. 17160 16397 16398 Phase 2 17158 17168 A Link partner receiving the request to adjust its Transmitter must evaluate the request and act on it. If a valid preset value is requested and the Transmitter is operating in full-swing mode, 274 it must be reflected in the Transmitter set-up and subsequently in the preset and coefficient fields of the TS1 Ordered Set that the Link partner transmits. If a preset value is requested, the Transmitter is operating in reduced-swing mode, and the requested preset is supported as defined in Section 8.3.3.3 Tx Equalization Presets it must be reflected in the Transmitter set-up and subsequently in the preset and coefficient fields of the TS1 Ordered Set that the Link partner transmits. Transmitters operating in reduced-swing mode are permitted to reject 17169 A Link partner receiving the request to adjust its Transmitter must evaluate the request and act on it. If a valid preset value is requested and the Transmitter is operating in full-swing mode, it must be reflected in the Transmitter set-up and subsequently in the preset and coefficient fields of the TS1 Ordered Set that the Link partner transmits. If a preset value is requested, the Transmitter is operating in reduced-swing mode, and the requested preset is supported as defined in Section 8.3.3.3 Tx Equalization Presets it must be reflected in the Transmitter set-up and subsequently in the preset and coefficient fields of the TS1 Ordered Set that the Link partner transmits. Transmitters operating in reduced-swing mode are permitted to reject /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16404 A Link partner receiving the request to adjust its Transmitter must evaluate the request and act on it. If a valid preset value is requested and the Transmitter is operating in full-swing mode, it must be reflected in the Transmitter set-up and subsequently in the preset and coefficient fields of the TS1 Ordered Set that the Link partner transmits. If a preset value is requested, the Transmitter is operating in reduced-swing mode, and the requested preset is supported as defined in Section 8.3.3.3 Tx Equalization Presets it must be reflected in the Transmitter set-up and subsequently in the preset and coefficient fields of the TS1 Ordered Set that the Link partner transmits. Transmitters operating in reduced-swing mode are permitted to reject preset requests that are not supported as defined in Section 8.3.3.3 Tx Equalization Presets . A request for adjusting the coefficients may be accepted or rejected. If the set of coefficients requested for a Lane is accepted, it must be reflected in the Transmitter set-up and subsequently in the transmitted TS1 Ordered Sets. If the set of coefficients requested for a Lane is rejected, the Transmitter set-up is not changed, but the transmitted TS1 Ordered Sets must reflect the requested coefficients along with the Reject Coefficient bit set to 1b. In either case of responding to a coefficient request, the preset field of the transmitted TS1 Ordered Sets is not changed from the last preset value that was transmitted. A request for adjusting the coefficients may be rejected by the Link partner only if the set of coefficients requested is not compliant with the rules defined in Section 4.2.3.1 Rules for Transmitter Coefficients . 16405 17171 When performing equalization of a crosslink, the component that played the role of the Downstream Port during the earlier crosslink initialization at the lower data rate also assumes the responsibility of the Downstream Port for equalization. 16408 17175 If a Lane receives a Transmitter Preset value (from TS1 or TS2 sequences) with a Reserved or unsupported value in Polling.Compliance, Loopback, or Phase 0 or Phase 1 of Recovery.Equalization, then the Lane is permitted to use any supported Transmitter preset setting in an implementation-specific manner. The Reserved or unsupported Transmitter preset value is transmitted in any subsequent Compliance Patterns or Ordered Sets, and not the implementation-specific preset value chosen by the Lane. For example, if a Lane of an Upstream Port receives a Transmitter preset value 1111b (Reserved) with the EQ TS2 Ordered Sets it receives in Recovery.RcvrCfg, it is permitted to use any supported Transmitter preset value for its transmitter setting after changing the data rate to 8.0 GT/s, but it must transmit 1111b as its Transmitter preset value in the TS1 Ordered Sets it transmits in Phase 0 and Phase 1 of Recovery.Equalization. 17176 16412 Page When performing equalization of a crosslink, the component that played the role of the Downstream Port during the earlier crosslink initialization at the lower data rate also assumes the responsibility of the Downstream Port for equalization. 17174 If a Lane is directed to use a Reserved or unsupported Transmitter preset value in Polling.Compliance, Loopback, or Phase 0 or Phase 1 of Recovery.Equalization, then the Lane is permitted to use any supported Transmitter preset setting in an implementation-specific manner. The Reserved or unsupported Transmitter preset value is transmitted in any subsequent Compliance Patterns or Ordered Sets, and not the implementation-specific preset value chosen by the Lane. For example, if a Lane of an Upstream Port is directed to use Transmitter preset value 1111b (Reserved) with the EQ TS2 Ordered Sets it receives in Recovery.RcvrCfg, it is permitted to use any supported Transmitter preset value for its transmitter setting after changing the data rate to 8.0 GT/ s, but it must transmit 1111b as its Transmitter preset value in the TS1 Ordered Sets it transmits in Phase 0 and Phase 1 of Recovery.Equalization. 16411 16413 17172 17173 16409 16410 A Link partner receiving the request to adjust its Transmitter must evaluate the request and act on it. If a valid preset value is requested and the Transmitter is operating in full-swing mode, it must be reflected in the Transmitter set-up and subsequently in the preset and coefficient fields of the TS1 Ordered Set that the Link partner transmits. If a preset value is requested, the Transmitter is operating in reduced-swing mode, and the requested preset is supported as defined in Section 8.3.3.3 Tx Equalization Presets it must be reflected in the Transmitter set-up and subsequently in the preset and coefficient fields of the TS1 Ordered Set that the Link partner transmits. Transmitters operating in reduced-swing mode are permitted to reject preset requests that are not supported as defined in Section 8.3.3.3 Tx Equalization Presets . A request for adjusting the coefficients may be accepted or rejected. If the set of coefficients requested for a Lane is accepted, it must be reflected in the Transmitter set-up and subsequently in the transmitted TS1 Ordered Sets. If the set of coefficients requested for a Lane is rejected, the Transmitter set-up is not changed, but the transmitted TS1 Ordered Sets must reflect the requested coefficients along with the Reject Coefficient bit set to 1b. In either case of responding to a coefficient request, the preset field of the transmitted TS1 Ordered Sets is not changed from the last preset value that was transmitted. A request for adjusting the coefficients may be rejected by the Link partner only if the set of coefficients requested is not compliant with the rules defined in Section 4.2.3.1 Rules for Transmitter Coefficients . 17170 16406 16407 17169 17177 In the Loopback state, the Loopback Master is responsible for communicating the Transmitter and Receiver settings it wants the Slave to use through the EQ TS1 Ordered Sets it transmits in the 2.5 GT/s or 5.0 GT/s data rate, and the preset or coefficient settings it wants the 275 device under test to operate under in the TS1 Ordered Sets it transmits in the 8.0 GT/s or higher data rate. Similarly, if the Polling.Compliance state for 8.0 GT/s or higher Data Rates is entered through TS1 Ordered Sets, the entity that is performing the test is required to send the appropriate EQ TS1 Ordered Sets and coefficients for the device under test to operate with, according to the mechanism defined in Section 4.2.6.2 Polling . 17178 In the Loopback state, the Loopback Master is responsible for communicating the Transmitter and Receiver settings it wants the Slave to use through the EQ TS1 Ordered Sets it transmits in the 2.5 GT/s or 5.0 GT/s data rate, and the preset or coefficient settings it wants the device under test to operate under in the TS1 Ordered Sets it transmits in the 8.0 GT/s or higher data rate. Similarly, if the Polling.Compliance state for 8.0 GT/s or higher Data Rates is entered through TS1 Ordered Sets, the entity that is performing the test is required to send the appropriate EQ TS1 Ordered Sets and coefficients for the device under test to operate with, according to the mechanism defined in Section 4.2.6.2 Polling . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. 16413 In the Loopback state, the Loopback Master is responsible for /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17178 communicating the Transmitter and Receiver settings it wants the Slave to use through the EQ TS1 Ordered Sets it transmits in the 2.5 GT/s or 5.0 GT/s data rate, and the preset or coefficient settings it wants the device under test to operate under in the TS1 Ordered Sets it transmits in the 8.0 GT/s or higher data rate. Similarly, if the Polling.Compliance state for 8.0 GT/s or higher Data Rates is entered through TS1 Ordered Sets, the entity that is performing the test is required to send the appropriate EQ TS1 Ordered Sets and coefficients for the device under test to operate with, according to the mechanism defined in Section 4.2.6.2 Polling . 16414 17179 16415 17180 16416 17181 16417 Implementation Note Equalization Example 16418 17182 17183 16419 17184 16420 17185 16421 16422 In the Loopback state, the Loopback Master is responsible for communicating the Transmitter and Receiver settings it wants the Slave to use through the EQ TS1 Ordered Sets it transmits in the 2.5 GT/s or 5.0 GT/s data rate, and the preset or coefficient settings it wants the device under test to operate under in the TS1 Ordered Sets it transmits in the 8.0 GT/s or higher data rate. Similarly, if the Polling.Compliance state for 8.0 GT/s or higher Data Rates is entered through TS1 Ordered Sets, the entity that is performing the test is required to send the appropriate EQ TS1 Ordered Sets and coefficients for the device under test to operate with, according to the mechanism defined in Section 4.2.6.2 Polling . Implementation Note Equalization Example 17186 The following diagram is an example illustrating how two devices may complete the equalization procedure. If the maximum common data rate supported by both Ports is 8.0 GT/s, the equalization procedure is complete at the conclusion of the 8.0 GT/s equalization procedure. If the maximum common data rate supported by both Ports is 16.0 GT/s, the 8.0 GT/s equalization procedure is followed by the 16.0 GT/s equalization procedure. If either the 8.0 GT/s or 16.0 GT/s equalization procedure is repeated and is performed while the Link is in 8.0 GT/s data rate (for the 8.0 GT/s equalization) or in 16.0 GT/s (for the 16.0 GT/s equalization), Phase 0 may be skipped since there is no need for the Link to go back to 2.5 GT/s or 5.0 GT/s (for the 8.0 GT/s equalization) or 8.0 GT/s (for the 16.0 GT/s equalization) to resend the same EQ TS2 Ordered Sets to convey the presets. A Downstream Port may choose to skip Phase 2 and Phase 3 if it determines that fine-tuning of the Transmitter is not needed based on the channel and components in the platform. 17187 16423 17188 16424 17189 16425 17190 16426 16427 The following diagram is an example illustrating how two devices may complete the equalization procedure. If the maximum common data rate supported by both Ports is 8.0 GT/s, the equalization procedure is complete at the conclusion of the 8.0 GT/s equalization procedure. If the maximum common data rate supported by both Ports is 16.0 GT/s, the 8.0 GT/s equalization procedure is followed by the 16.0 GT/s equalization procedure. If either the 8.0 GT/s or 16.0 GT/s equalization procedure is repeated and is performed while the Link is in 8.0 GT/s data rate (for the 8.0 GT/s equalization) or in 16.0 GT/s (for the 16.0 GT/s equalization), Phase 0 may be skipped since there is no need for the Link to go back to 2.5 GT/s or 5.0 GT/s (for the 8.0 GT/s equalization) or 8.0 GT/s (for the 16.0 GT/s equalization) to resend the same EQ TS2 Ordered Sets to convey the presets. A Downstream Port may choose to skip Phase 2 and Phase 3 if it determines that fine-tuning of the Transmitter is not needed based on the channel and components in the platform. 17191 Figure 4-20 8.0 GT/s Equalization Flow 17192 Figure 4-21 8.0 GT/s Equalization Flow 17193 17194 17195 16428 17196 16429 17197 17198 16430 17199 16431 17200 16432 16433 Figure 4-22 16.0 GT/s Equalization Flow 17201 Figure 4-21 16.0 GT/s Equalization Flow 17202 17203 17204 17205 17206 Page 276 Implementation Note Equalization Bypass Example /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17206 Equalization Bypass Example 17207 17208 17209 17210 The following flow-chart provides an example flow where a Link may bypass equalization at lower Data Rates and go to the highest support data rate for equalization. For example, when n=5, the Link can train to L0 in Gen 1 data rate, establish that all components (including Retimers, if any) can bypass equalization to Gen 5, change the data rate to Gen 5 and just perform equalization at Gen 5. 17211 17212 17213 17214 17215 16434 17216 16435 17217 16436 17218 16437 17219 16438 17220 16439 16440 17221 4.2.3.1 Rules for Transmitter Coefficients 16441 17222 4.2.3.1 Rules for Transmitter Coefficients 17223 16442 16443 Figure 4-23 Equalization Bypass Example 17224 The explanation of the coefficients and the FIR filter it represents are provided in Section 8.3.3.1 2.5 and 5.0 GT/s Transmitter Equalization . The following rules apply to both the advertised as well as requested coefficient settings. 16444 17225 The explanation of the coefficients and the FIR filter it represents are provided in Section 8.3.3.1 2.5 and 5.0 GT/s Transmitter Equalization . The following rules apply to both the advertised as well as requested coefficient settings. 17226 17227 16445 16446 16447 16448 C-1 and C+1 are the coefficients used in the FIR equation and represent the pre-cursor and post-cursor, respectively. The pre-cursor and post-cursor values communicated in the TS1 Ordered Sets represent their absolute values. C0 represents the cursor coefficient setting and is a positive entity. The sum of the absolute values of the coefficients defines the FS (Full Swing; FS = |C-1|+C0+|C+1|). FS is advertised to the Link partner in Phase 1. The Transmitter FS range is defined below: FS ∈ {24, …, 63} (i.e., FS must have a value from 24 through 63) for full swing mode. FS ∈ {12, …, 63} for reduced swing mode. 16449 16450 16451 Page 17228 17229 17230 17231 C-1 and C+1 are the coefficients used in the FIR equation and represent the pre-cursor and post-cursor, respectively. The precursor and post-cursor values communicated in the TS1 Ordered Sets represent their absolute values. C0 represents the cursor coefficient setting and is a positive entity. The sum of the absolute values of the coefficients defines the FS (Full Swing; FS = |C-1|+C0+|C+1|). FS is advertised to the Link partner in Phase 1. The Transmitter FS range is defined below: FS ∈ {24, …, 63} (i.e., FS must have a value from 24 through 63) for full swing mode. FS ∈ {12, …, 63} for reduced swing mode. 17232 A Transmitter advertises its LF (Low Frequency) value during Phase 1. This corresponds to the minimum differential voltage that can be generated by the Transmitter which is LF/FS times the Transmitters maximum differential voltage. The Transmitter must ensure that when equation c) below equals LF it must meet the electrical requirements defined in Section 8.3.3.9 EIEOS and VTX-EIEOS-FS and VTX-EIEOS-RS Limits for VTX-EIEOS-FS and VTX-EIEOS-RS. The following rules must be satisfied before a set of coefficients can be requested of the Link partner’s Transmitter. Upon reception of an update request for TX coefficient settings, a Port must verify that the new request meets the following conditions and reject the 277 request if any of following conditions are violated: 17233 17234 A Transmitter advertises its LF (Low Frequency) value during Phase 1. This corresponds to the minimum differential voltage that can be generated by the Transmitter which is LF/FS times the Transmitters maximum differential voltage. The Transmitter must ensure that when equation c) below equals LF it must meet the electrical requirements defined in Section 8.3.3.9 EIEOS and VTX-EIEOS-FS and VTX-EIEOS-RS Limits for VTX-EIEOS-FS and VTX-EIEOS-RS. The following rules must be satisfied before a set of coefficients can be requested of the Link partner’s Transmitter. Upon reception of an update request for TX coefficient settings, a Port must verify that the new request meets the following conditions and reject the request if any of following conditions are violated: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16451 The following rules must be satisfied before a set of 16452 16453 16454 coefficients can be requested of the Link partner’s Transmitter. Upon reception of an update request for TX coefficient settings, a Port must verify that the new request meets the following conditions and reject the request if any of following conditions are violated: |C-1| <= Floor (FS/4) |C-1|+C0+|C+1| = FS (Do not allow peak power to change with adaptation.) C0 -|C-1|-|C+1 |>= LF 17234 17235 17236 17237 16455 17238 16456 17239 16457 17240 16458 17241 16459 17242 16460 4.2.3.2 Encoding of Presets 16461 17243 17245 Definition of the Transmitter and Receiver Preset Hints appears in Chapter 8 Electrical Sub-Block . The encoding for the Transmitter Preset and Receiver Preset Hint are provided in Table 4-3 Transmitter Preset Encoding and Table 4-4 Receiver Preset Hint Encoding for 8.0 GT/s . Receiver Preset Hints are optional and only defined for the 8.0 GT/s data rate. 17246 16464 17247 16465 17248 16466 Definition of the Transmitter and Receiver Preset Hints appears in Chapter 8 Electrical Sub-Block . The encoding for the Transmitter Preset and Receiver Preset Hint are provided in Table 4-4 Transmitter Preset Encoding and Table 4-5 Receiver Preset Hint Encoding for 8.0 GT/s . Receiver Preset Hints are optional and only defined for the 8.0 GT/s data rate. 17249 16467 Table 4-3 Transmitter Preset Encoding 16468 17250 Table 4-4 Transmitter Preset Encoding 17251 16469 Encoding 16470 16471 4.2.3.2 Encoding of Presets 17244 16462 16463 The following rules must be satisfied before a set of coefficients can be requested of the Link partner’s Transmitter. Upon reception of an update request for TX coefficient settings, a Port must verify that the new request meets the following conditions and reject the request if any of following conditions are violated: |C-1| ≤ Floor (FS/4) |C-1|+C0+|C+1| = FS (Do not allow peak power to change with adaptation ) C0 -|C-1|-|C+1| ≥ LF 17252 Encoding 17253 Preset Number in Table 8-1 Tx Preset Ratios and Corresponding Coefficient Values 17254 16472 17255 16473 17256 16474 16475 17257 0000b 16476 16477 P0 17260 1011b through 1111b 17324 Reserved 17326 17327 16545 17328 16546 17329 16547 17330 16548 17331 16549 16553 Page 278 1011b through 1111b Reserved 17332 Table 4-4 Receiver Preset Hint Encoding for 8.0 GT/s 16551 16552 P0 17325 16544 16550 0000b 17323 16542 16543 17258 17259 16540 16541 Preset Number in Table 8-1 Tx Preset Ratios and Corresponding Coefficient Values 17333 Table 4-5 Receiver Preset Hint Encoding for 8.0 GT/s 17334 Encoding 17335 17336 Encoding /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16553 17336 16554 Receiver Preset Value 17337 16555 17338 16556 17339 16557 17340 16558 000b 16559 17341 -6 dB 16638 Lane-to-Lane de-skew within a multi-Lane Link. 17343 17421 16639 17422 16640 17423 16641 4.2.4.1 Training Sequences 16643 4.2.4.1 Training Sequences 17427 Training sequences are composed of Ordered Sets used for initializing bit alignment, Symbol alignment and to exchange Physical Layer parameters. When the data rate is 2.5 GT/s or 5.0 GT/s, Ordered Sets are never scrambled but are always 8b/10b encoded. When the data rate is 8.0 GT/s or higher, the 128b/130b encoding is used and Symbols may or may not be scrambled, according to the rules in Section 4.2.2.4 Scrambling . 16646 17428 Training sequences are composed of Ordered Sets used for initializing bit alignment, Symbol alignment and to exchange Physical Layer parameters. When the data rate is 2.5 GT/s or 5.0 GT/s, Ordered Sets are never scrambled but are always 8b/10b encoded. When the data rate is 8.0 GT/s or higher, the 128b/130b encoding is used and Symbols may or may not be scrambled, according to the rules in Section 4.2.2.4 Scrambling . 17429 16647 17430 Training sequences (TS1 or TS2 ) are transmitted consecutively and can only be interrupted by SKP Ordered Sets (see Section 4.2.7 Clock Tolerance Compensation ) or, for data rates other than 2.5 GT/s, EIEOS Ordered Sets (see Section 4.2.4.2 Electrical Idle Sequences ). 16649 17431 Training sequences (TS1 or TS2 or Modified TS1 or Modified TS2) are transmitted consecutively and can only be interrupted by SKP Ordered Sets (see Section 4.2.7 Clock Tolerance Compensation ) or, for data rates other than 2.5 GT/s, EIEOS Ordered Sets (see Section 4.2.4.3 Electrical Idle Sequences (EIOS) ). 17432 16650 17433 When 8.0 GT/s or higher data rates are supported, a TS1 (or TS2) Ordered Set using 8b/10b encoding (i.e., 2.5 or 5.0 GT/s data rate) can be either a standard TS1 (or TS2) Ordered Set (i.e., Symbol 6 is D10.2 for a TS1 Ordered Set or D5.2 for a TS2 Ordered Set) or an EQ TS1 (or EQ TS2 ) (i.e., Symbol 6 bit 7 is 1b). The ability to transmit EQ TS1 Ordered Sets is implementation-specific. Ports supporting 8.0 GT/s or higher data rates must accept either TS1 (or TS2) type in the LTSSM states unless explicitly required to look for a specific type. Ports that do not support the 8.0 GT/s data rate are permitted, but not required, to accept EQ TS1 (or TS2) Ordered Sets. 16652 17434 When 8.0 GT/s or higher data rates are supported, a TS1 (or TS2) Ordered Set using 8b/10b encoding (i.e., 2.5 or 5.0 GT/s data rate) can be either a standard TS1 (or TS2) Ordered Set (i.e., Symbol 6 is D10.2 for a TS1 Ordered Set or D5.2 for a TS2 Ordered Set) or an EQ TS1 Ordered Set (or EQ TS2 Ordered Set) (i.e., Symbol 6 bit 7 is 1b). The ability to transmit EQ TS1 Ordered Sets is implementation-specific. Ports supporting 8.0 GT/s or higher data rates must accept either TS1 (or TS2) type in the LTSSM states unless explicitly required to look for a specific type. Ports that do not support the 8.0 GT/s data rate are permitted, but not required, to accept EQ TS1 (or TS2) Ordered Sets. 17435 16653 16654 17425 17426 16644 16651 -6 dB Lane-to-Lane de-skew within a multi-Lane Link. 17424 16642 16648 000b 17342 16560 16645 Receiver Preset Value 17436 When the 16.0 GT/s data rate is supported, a TS2 using 128b/130b encoding (i.e. 8.0 or 16.0 GT/s data rate) can be either a standard TS2 Ordered Set (i.e., Symbol 7 is 45h) or an 8GT EQ TS2 (i.e., Symbol 7 bit 7 is 1b). Ports supporting the 16.0 GT/s data rate must accept either TS2 type in the LTSSM states unless explicitly required to look for a specific type. Ports that do not support the 16.0 GT/s data rate are permitted, but not required, to accept 8GT EQ TS2 Ordered Sets. Page 279 17437 When the 16.0 GT/s and higher data rate is supported, a TS2 using 128b/130b encoding (i.e. 8.0 or higher data rate) can be either a standard TS2 Ordered Set (i.e., Symbol 7 is 45h) or an 128b/130b EQ TS2 (i.e., Symbol 7 bit 7 is 1b). Ports supporting the 16.0 GT/s or higher data rate must accept either TS2 type in the LTSSM states unless explicitly required to look for a specific type. Ports that do not support the 16.0 GT/s data rate are permitted, but not required, to accept 128b/130b EQ TS2 Ordered Sets. 17437 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16655 17438 16656 16657 When the 16.0 GT/s and higher data rate is supported, a TS2 using 128b/130b encoding (i.e. 8.0 or higher data rate) can be either a standard TS2 Ordered Set (i.e., Symbol 7 is 45h) or an 128b/130b EQ TS2 (i.e., Symbol 7 bit 7 is 1b). Ports supporting the 16.0 GT/s or higher data rate must accept either TS2 type in the LTSSM states unless explicitly required to look for a specific type. Ports that do not support the 16.0 GT/s data rate are permitted, but not required, to accept 128b/130b EQ TS2 Ordered Sets. 17439 When using 8b/10b encoding, TS1 or TS2 Ordered Sets are considered consecutive only if Symbol 6 matches the Symbol 6 of the previous TS1 or TS2 Ordered Set. 17440 16658 17441 16659 17442 17443 When using 8b/10b encoding, TS1 or TS2 Ordered Sets are considered consecutive only if Symbol 6 matches the Symbol 6 of the previous TS1 or TS2 Ordered Set. Components that intend to either negotiate alternate protocols or pass a Training Set Message must use Modified TS1/TS2 Ordered Sets instead of standard TS1/TS2 Ordered Sets in Configuration.Lanenum.Wait, Configuration.Lanenum.Accept, and Configuration.Complete substates. In order to be eligible to send the Modified TS1/TS2 Ordered Sets, components must set the Enhanced Link behavior Control bits (bit 7:6 of Symbol 5) in TS1 and TS2 Ordered Sets to 11b in Polling.Active, Polling.Configuration, Configuration.Linkwidth.Start, and Configuration.Linkwidth.Accept substates and follow through the steps outlined on transition to Configuration.Lanenum.Wait substate when LinkUp=0b. If the Link partner does not support Modified TS1/TS2 Ordered Sets, then starting with Configuration.LaneNum.Wait, the standard TSes should stop sending 11b in the Enhanced Link Behavior Control field and switch to the appropriate encodings. 17444 17445 17446 When using 8b/10b encoding, modified TS1 or modified TS2 Ordered Sets are considered consecutive only if all Symbols matches the corresponding Symbols of the previous modified TS1 or modified TS2 Ordered Sets and the parity in Symbol 15 matches with the expected value. Symbols 8-14 must be identical in each Modified TS1/TS2 Ordered Sets across all Lanes of a Link. 17447 17448 16660 When using 128b/130b encoding, TS1 or TS2 Ordered Sets are considered consecutive only if Symbols 6-9 match Symbols 6-9 of the previous TS1 or TS2 Ordered Set, with Reserved bits treated as described below. 16661 17449 17450 16662 17451 16663 Reserved bits in TS1 and TS2 Ordered Sets must be handled 17452 as follows: 16664 16665 16666 16667 16668 16669 Page When using 128b/130b encoding, TS1 or TS2 Ordered Sets are considered consecutive only if Symbols 6-9 match Symbols 6-9 of the previous TS1 or TS2 Ordered Set, with Reserved bits treated as described below. Reserved bits in TS1 and TS2 Ordered Sets must be handled as follows: 17453 The Transmitter must transmit 0s for Reserved bits. The Receiver: must not determine that a TS1 or TS2 Ordered Set is invalid based on the received value of Reserved bits must use the received value of Reserved bits for the purpose of a parity computation if the Reserved bits are included in a parity calculation may optionally compare the received value of Reserved bits within Symbols that are explicitly called out as being required to be identical in TS1 or TS2 Ordered Sets to determine if they are consecutive 280 17454 17455 17456 17457 17458 The Transmitter must transmit 0s for Reserved bits. The Receiver: must not determine that a TS1 or TS2 Ordered Set is invalid based on the received value of Reserved bits must use the received value of Reserved bits for the purpose of a parity computation if the Reserved bits are included in a parity calculation may optionally compare the received value of Reserved bits within Symbols that are explicitly called out as being required to be identical in TS1 or TS2 Ordered Sets to determine if they are consecutive /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16669 may optionally compare the received value of Reserved 16670 bits within Symbols that are explicitly called out as being required to be identical in TS1 or TS2 Ordered Sets to determine if they are consecutive must not otherwise take any functional action based on the value of any received Reserved bits 17458 17459 16671 17460 16672 17461 16673 16674 17462 When using 128b/130b encoding, Transmitters are required to track the running DC Balance of the bits transmitted on the wire (after scrambling ) that constitute the TS1 and TS2 Ordered Sets only. The running DC Balance is the difference between the number of 1s transmitted and the number of 0s transmitted. Each Lane must track its running DC Balance independently and be capable of tracking a difference of at least 511 bits in either direction: 511 more 1s than 0s, and 511 more 0s than 1s. Any counters used must saturate at their limit (not roll-over) and continue to track reductions after their limit is reached. For example, a counter that can track a difference of 511 bits will saturate at 511 if a difference of 513 is detected, and then change to 509 if the difference is reduced by 2 in the future. 16675 16684 The running DC Balance is set to 0 by two events: 1) The Transmitter exiting Electrical Idle; 2) Transmission of an EIEOS following a Data Block. 17468 For every TS1 or TS2 Ordered Set transmitted, Transmitters must evaluate the running DC Balance and transmit one of the DC Balance Symbols defined for Symbols 14 and 15 as defined by the algorithm below. If the number of 1s needs to be reduced, the DC Balance Symbols 20h (for Symbol 14) and 08h (for Symbol 15) are transmitted. If the number of 0s needs to be reduced, the DC Balance Symbols DFh (for Symbol 14) and F7h (for Symbol 15) are transmitted. If no change is required, the appropriate TS1 or TS2 Identifier Symbol is transmitted. Any DC Balance Symbols transmitted for Symbols 14 or 15 bypass scrambling, while TS1 and TS2 Identifier Symbols follow the standard scrambling rules. The following algorithm must be used to control the DC Balance: 16681 16683 17466 17467 16679 16682 When using 128b/130b encoding, Transmitters are required to track the running DC Balance of the bits transmitted on the wire (after scrambling and precoding, if turned on) that constitute the TS1 and TS2 Ordered Sets only. The running DC Balance is the difference between the number of 1s transmitted and the number of 0s transmitted. Each Lane must track its running DC Balance independently and be capable of tracking a difference of at least 511 bits in either direction: 511 more 1s than 0s, and 511 more 0s than 1s. Any counters used must saturate at their limit (not roll-over) and continue to track reductions after their limit is reached. For example, a counter that can track a difference of 511 bits will saturate at 511 if a difference of 513 is detected, and then change to 509 if the difference is reduced by 2 in the future. 17465 The running DC Balance is set to 0 by two events: 1) The Transmitter exiting Electrical Idle; 2) Transmission of an EIEOS following a Data Block. 16678 16680 17463 17464 16676 16677 may optionally compare the received value of Reserved bits within Symbols that are explicitly called out as being required to be identical in TS1 or TS2 Ordered Sets to determine if they are consecutive must not otherwise take any functional action based on the value of any received Reserved bits 17469 For every TS1 or TS2 Ordered Set transmitted, Transmitters must evaluate the running DC Balance and transmit one of the DC Balance Symbols defined for Symbols 14 and 15 as defined by the algorithm below. If the number of 1s needs to be reduced, the DC Balance Symbols 20h (for Symbol 14) and 08h (for Symbol 15) are transmitted. If the number of 0s needs to be reduced, the DC Balance Symbols DFh (for Symbol 14) and F7h (for Symbol 15) are transmitted. If no change is required, the appropriate TS1 or TS2 Identifier Symbol is transmitted. Any DC Balance Symbols transmitted for Symbols 14 or 15 bypass scrambling, while TS1 and TS2 Identifier Symbols follow the standard scrambling rules. The following algorithm must be used to control the DC Balance: 17470 If the running DC Balance is > 31 at the end of Symbol 11 of the TS Ordered Set, transmit DFh for Symbol 14 and F7h for Symbol 15 to reduce the number of 0s, or 20h for Symbol 14 and 08h for Symbol 15 to reduce the number of 1s. Else, if the running DC Balance is > 15 at the end of Symbol 11 of the TS Ordered Set, transmit F7h for Symbol 15 to reduce the number of 0s, or 08h for Symbol 15 to reduce the number of 1s. Transmit the normal TS Identifier Symbol (scrambled) for Symbol 14. Else, transmit the normal TS Identifier Symbol (scrambled) for Symbols 14 and 15. 17471 17472 17473 16685 17474 16686 17475 Page 281 If the running DC Balance is > 31 at the end of Symbol 11 of the TS Ordered Set, transmit DFh for Symbol 14 and F7h for Symbol 15 to reduce the number of 0s, or 20h for Symbol 14 and 08h for Symbol 15 to reduce the number of 1s. Else, if the running DC Balance is > 15 at the end of Symbol 11 of the TS Ordered Set, transmit F7h for Symbol 15 to reduce the number of 0s, or 08h for Symbol 15 to reduce the number of 1s. Transmit the normal TS Identifier Symbol (scrambled) for Symbol 14. Else, transmit the normal TS Identifier Symbol (scrambled) for Symbols 14 and 15. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16686 16687 17475 Receivers are permitted, but not required, to check Symbols 14 and 15 for the following values when determining whether a TS1 or TS2 Ordered Set is valid: The appropriate TS Identifier Symbol after descrambling, or a valid DC Balance Symbol of DFh or 20h before descrambling for Symbol 14, or a valid DC Balance Symbol of F7h or 08h before de-scrambling for Symbol 15. 17476 16688 17477 16689 17478 17479 Receivers are permitted, but not required, to check Symbols 14 and 15 for the following values when determining whether a TS1 or TS2 Ordered Set is valid: The appropriate TS Identifier Symbol after descrambling, or a valid DC Balance Symbol of DFh or 20h before descrambling for Symbol 14, or a valid DC Balance Symbol of F7h or 08h before de-scrambling for Symbol 15. If a Reciever receives a DC balance pattern in Symbol 14, it is possible that the pattern is scrambled (and precoded). Thus if the Receiver is performing this optional check, it must keep descrambler and receive precoding running for checking Symbol 15, which can be either scrambled (and precoded) or the DC balance pattern. 17480 17481 16690 17482 16691 Implementation Note Sync Header and DC Balance 16692 17483 17484 16693 17485 16694 17486 16695 16696 17487 Block Sync Header bits and the first Symbol of TS1 and TS2 Ordered Sets do not affect the running DC Balance, because they have equal number of 1s and 0s. 17488 16697 17489 16698 17490 16699 17491 16700 16701 Block Sync Header bits and the first Symbol of TS1 and TS2 Ordered Sets do not affect the running DC Balance, because they have equal number of 1s and 0s. 17492 The Training control bits for Hot Reset , Disable Link , and Enable Loopback are mutually exclusive, only one of these bits is permitted to be set at a time as well as transmitted on all Lanes in a configured (all Lanes that were in L0) or possible (all Lanes in Configuration) Link. If more than one of the Hot Reset , Disable Link , or Enable Loopback bits are Set at the same time, the Link behavior is undefined. 16702 17493 The Training control bits Hot Reset bit, Disable Link bit, and Loopback bit are mutually exclusive, only one of these bits is permitted to be set at a time as well as transmitted on all Lanes in a configured (all Lanes that were in L0) or possible (all Lanes in Configuration) Link. If more than one of Hot Reset bit, Disable Link bit, or Loopback bit are Set at the same time, the Link behavior is undefined. 17494 16703 16704 Implementation Note Sync Header and DC Balance 17495 The TS1 Ordered Set’s Retimer Equalization Extend bit is always set to 0b when transmitted by an Upstream Port or Downstream Port. Retimers set the bit to 1b as described in Section 4.3.7.2 Link Equalization Rules . 17496 16705 17497 16706 17498 16707 16708 17499 Table 4-5 TS1 Ordered Set 16709 16710 16713 Page 282 17500 Table 4-6 TS1 Ordered Set 17501 Symbol Number 16711 16712 The TS1 Ordered Set's Retimer Equalization Extend bit is always set to 0b when transmitted by an Upstream Port or Downstream Port. Retimers set the bit to 1b as described in Section 4.3.7.2 Link Equalization Rules . 17502 Symbol Number 17503 Description 17504 17505 Description /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16713 17505 16714 17506 16715 17507 16716 17508 0 16717 0 17509 16718 16719 When operating at 2.5 or 5.0 GT/s: COM (K28.5) 17510 for Symbol alignment. When operating at 2.5 or 5.0 GT/s: COM (K28.5) for Symbol alignment. 16720 16721 16722 When operating at 8.0 GT/s or above: Encoded as 17511 1Eh (TS1 Ordered Set). When operating at 8.0 GT/s or above: Encoded as 1Eh (TS1 Ordered Set). 16723 17512 16724 17513 16725 17514 16726 17515 16727 17516 1 16728 1 17517 16729 17518 16730 Link Number. 16731 17519 Link Number. 17520 16732 16733 Ports that do not support 8.0 GT/s or above: 17521 0-255, PAD. Ports that do not support 8.0 GT/s or above: 0-255, PAD. 16734 16735 16736 Downstream Ports that support 8.0 GT/s or above: 17522 0-31, PAD. Downstream Ports that support 8.0 GT/s or above: 0-31, PAD. 16737 16738 16739 Upstream Ports that support 8.0 GT/s or above: 17523 0-255, PAD. Upstream Ports that support 8.0 GT/s or above: 0-255, PAD. 16740 16741 16742 When operating at 2.5 or 5.0 GT/s: PAD is encoded 17524 as K23.7. When operating at 2.5 or 5.0 GT/s: PAD is encoded as K23.7. 16743 16744 16745 When operating at 8.0 GT/s or above: PAD is 17525 encoded as F7h. When operating at 8.0 GT/s or above: PAD is encoded as F7h. 16746 17526 16747 17527 16748 17528 16749 17529 16750 17530 2 16751 2 17531 16752 17532 16753 Lane Number within Link. 16754 17533 Lane Number within Link. 17534 16755 16756 When operating at 2.5 or 5.0 GT/s: 0-31, PAD. PAD is encoded as K23.7. Page 283 17535 When operating at 2.5 or 5.0 GT/s: 0-31, PAD. PAD is encoded as K23.7. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16756 When operating at 2.5 or 5.0 GT/s: 0-31, PAD. PAD 17535 is encoded as K23.7. When operating at 2.5 or 5.0 GT/s: 0-31, PAD. PAD is encoded as K23.7. 16757 16758 16759 When operating at 8.0 GT/s or above: 0-31, PAD. 17536 PAD is encoded as F7h. 16760 17537 16761 17538 16762 17539 16763 17540 16764 17541 3 16765 16766 When operating at 8.0 GT/s or above: 0-31, PAD. PAD is encoded as F7h. 3 17542 N_FTS. The number of Fast Training Sequences required by the Receiver: 0-255. 17543 16767 17544 16768 17545 16769 N_FTS. The number of Fast Training Sequences required by the Receiver: 0-255. 17546 16770 17547 4 16771 4 17548 16772 17549 16773 Data Rate Identifier 16774 17550 Data Rate Identifier 17551 16775 17552 16776 Bit 0 - Reserved for future Data Rate. 17553 Bit 0 16777 16778 17554 16779 Bit 1 - 2.5 GT/s Data Rate Supported. Must be set 17555 Reserved for future Data Rate. to 1b. 16780 17556 17557 16781 16782 Bit 1 17558 Bit 2 - 5.0 GT/s Data Rate Supported. Must be set to 1b if Bit 3 is 1b. See Section 8.2 Interoperability Criteria . 16783 17559 2 .5 GT/s Data Rate Supported. Must be set to 1b . 17560 17561 16784 Bit 2 17562 16785 Bit 3 - 8.0 GT/s Data Rate Supported. Must be set 17563 to 1b if Bit 4 is 1b. 16786 5.0 GT/s Data Rate Supported. Must be set to 1b if Bit 3 is 1b. See Section 8.2 Interoperability Criteria . 17564 17565 16787 Bit 3 17566 16788 Bit 4 - 16.0 GT/s Data Rate Supported. 17567 8.0 GT/s Data Rate Supported. Must be set to 1b if Bit 4 is 1b. 16789 17568 17569 16790 Bit 4 17570 16791 Bit 5 - Reserved for future Data Rate. 17571 16.0 GT/s Data Rate Supported. Must be set to 1b if Bit 5 is 1b. 16792 17572 17573 16793 Bit 5 17574 16794 Bit 6 - Autonomous Change/Selectable Deemphasis. Page 284 17575 32.0 GT/s Data Rate Supported. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16794 Bit 6 - Autonomous Change/Selectable De- 17575 32.0 GT/s Data Rate Supported. emphasis. 16795 17576 17577 16796 17579 16797 Bit 6 17578 Downstream Ports: This bit is defined for use in the following LTSSM states: Polling.Active, Configuration.Linkwidth.Start, and Loopback.Entry. In all other LTSSM states, it is Reserved. 17580 Upstream Ports: This bit is defined for use in the following LTSSM states: Polling.Active, Configuration, Recovery, and Loopback.Entry. In all other LTSSM states, it is Reserved. 17581 Autonomous Change/Selectable De-emphasis. Downstream Ports: This bit is defined for use in the following LTSSM states: Polling.Active, Configuration.Linkwidth.Start, and Loopback.Entry. In all other LTSSM states, it is Reserved. 16798 16799 16800 16801 17582 16802 16803 Upstream Ports: This bit is defined for use in the following LTSSM states: Polling.Active, Configuration, Recovery, and Loopback.Entry. In all other LTSSM states, it is Reserved. 17583 Bit 7 - speed_change. This bit can be set to 1b only in the Recovery.RcvrLock LTSSM state. In all other LTSSM states, it is Reserved. 17584 17586 16804 17587 16805 17588 16806 17589 16807 16808 17591 5 17592 16810 17593 Training Control 16812 17594 Training Control 17595 16813 16814 speed_change. This bit can be set to 1b only in the Recovery.RcvrLock LTSSM state. In all other LTSSM states, it is Reserved. 17590 5 16809 16811 Bit 7 17585 17596 Bit 0 - Hot Reset 17597 Bit 0 17598 17599 Hot Reset bit 17600 17601 0b 17602 17603 Deassert 17604 17605 1b 17606 17607 Assert 17608 17609 17610 Bit 1 17611 17612 Disable Link bit 17613 17614 17615 Page 285 0b /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17615 17616 Deassert 17617 17618 1b 17619 17620 Assert 17621 16815 17622 17623 16816 16817 Bit 2 17624 Bit 0 = 0b, Deassert Bit 0 = 1b, Assert 16818 17625 Loopback bit 17626 17627 16819 16820 0b 17628 Bit 1 - Disable Link 16821 17629 Deassert 17630 17631 16822 16823 Bit 1 = 0b, Deassert Bit 1 = 1b, Assert 16824 17633 Assert 17634 16825 16826 1b 17632 17635 Bit 2 - Loopback 16827 17636 Bit 3 17637 17638 Disable Scrambling bit (2.5 GT/s and 5.0 GT/s data rates) 16828 16829 17639 Bit 2 = 0b, Deassert Bit 2 = 1b, Assert 16830 17640 17642 16831 16832 Bit 3 - Disable Scrambling in 2.5 GT/s and 5.0 GT/s data rates; Reserved in other data rates 17644 17647 16834 Assert Reserved (other data rates) 17648 Bit 3 = 0b, Deassert Bit 3 = 1b, Assert 16836 17649 Bit 4 17650 17651 16837 Compliance Receive bit (5.0 GT/s and above data rates, optional at 2.5 GT/s) 17652 Bit 4 - Compliance Receive 16839 17653 0b 17654 17655 16840 16841 1b 17645 17646 16838 Deassert 17643 16833 16835 0b 17641 Deassert 17656 Bit 4 = 0b, Deassert Bit 4 = 1b, Assert 17657 1b 17658 17659 16842 16843 16844 Page Assert 17660 17661 Ports that support 5.0 GT/s and above data rate(s) must implement the Compliance Receive bit. Ports that support 286 only 2.5 GT/s data rate may optionally implement the Compliance Receive bit. If not implemented, the bit is Reserved. 17662 Ports that support 5.0 GT/s and above data rate(s) must implement the Compliance Receive bit. Ports that support only 2.5 GT/s data rate may optionally implement the Compliance Receive bit. If not implemented, the bit is Reserved. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16844 Ports that support 5.0 GT/s and above data rate(s) must implement the Compliance Receive bit. Ports that support only 2.5 GT/s data rate may optionally implement the Compliance Receive bit. If not implemented, the bit is Reserved. 16845 17662 Ports that support 5.0 GT/s and above data rate(s) must implement the Compliance Receive bit. Ports that support only 2.5 GT/s data rate may optionally implement the Compliance Receive bit. If not implemented, the bit is Reserved. 17663 16846 17664 16847 Bit 5:7 - Reserved 16848 17665 Bit 5 17666 17667 16849 Transmit Modified Compliance Pattern in Loopback. This bit is defined for use in Loopback by the Loopback Master when 32.0 GT/s or higher data rates are supported. See Section 4.2.6.10.1 Loopback.Entry . In all other cases, this bit is Reserved. 17668 17669 16850 Bit 7:6 17670 17671 16851 Enhanced Link Behavior Control 17672 16852 17673 6 16853 00b 17674 17675 Full Equalization required Modified TS1/TS2 Ordered Sets not 17676 supported. 16854 17677 16855 When operating at 2.5 or 5.0 GT/s: 16856 17678 01b 17679 17680 Equalization bypass to highest rate support 17681 Modified TS1/TS2 Ordered Sets not supported. 17682 16857 16858 Indicates intention to perform 32.0 GT/s equalization when set by Loopback Master. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates and Section 4.2.6.10.1 Loopback.Entry . 17683 Standard TS1 Ordered Sets encode this Symbol as a TS1 Identifier, D10.2 (4Ah). 16859 17684 10b 17685 17686 No Equalization Needed Modified TS1/TS2 Ordered Sets not 17687 supported 17688 16860 A device advertising this capability must support Equalization bypass to highest rate. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates . 17689 16861 EQ TS1 Ordered Sets encode this Symbol as 17690 11b follows: 16862 17691 17692 Modified TS1/TS2 Ordered Sets supported Equalization bypass options specified in 17693 Modified TS1/TS2 Ordered Sets. 16863 Page 287 17694 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16863 16864 17694 Bit 2:0 - Receiver Preset Hint. See Section 4.2.3.2 Encoding of Presets . 16865 17695 17696 16866 These bits are defined for use in Polling and Configuration when LinkUp=0b and 32.0 GT/s or higher data rates are supported and in Loopback by the Loopback Master when 32.0 GT/s or higher data rates are supported. In all other cases, these bits are Reserved. 17697 16867 Bit 6:3 - Transmitter Preset. See Section 4.2.3.2 Encoding of Presets . 16868 17698 16869 17699 16870 Bit 7 - Set to 1b. 16871 17700 16872 17701 16873 When operating at 8.0 GT/s or 16.0 GT/s: 16874 17704 Bit 1:0 - Equalization Control (EC). This field is only used in the Recovery.Equalization and Loopback LTSSM states. See Section 4.2.6.4.2 Recovery.Equalization and Section 4.2.6.10 Loopback . In all other LTSSM states, it must be set to 00b. 16877 17705 When operating at 2.5 or 5.0 GT/s: 17706 17707 16878 16879 6 17703 16875 16876 17702 Standard TS1 Ordered Sets encode this Symbol as a TS1 Identifier, D10.2 (4Ah). 17708 Bit 2 - Reset EIEOS Interval Count. This bit is defined for use in the Recovery.Equalization LTSSM state. See Section 4.2.6.4.2 Recovery.Equalization and Section 4.2.4.2 Electrical Idle Sequences . In all other LTSSM states, it is Reserved. 16880 17709 EQ TS1 Ordered Sets encode this Symbol as follows: 17710 For Equalization at 8.0 GT/s Data Rate: 17711 17712 16881 16882 Bits 2:0 17713 Bit 6:3 - Transmitter Preset. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates and Section 4.2.6 Link Training and Status State Rules . 16883 17714 Receiver Preset Hint. See Section 4.2.3.2 Encoding of Presets . 17715 17716 16884 16885 Bit 6:3 17717 Bit 7 - Use Preset/Equalization Redo. This bit is defined for use in the Recovery.Equalization, Recovery.RcvrLock and Loopback LTSSM states. See Section 4.2.6.4.1 Recovery.RcvrLock , Section 4.2.6.4.2 Recovery.Equalization and Section 4.2.6.10 Loopback . In all other LTSSM states, it is Reserved. 16886 17718 Transmitter Preset. See Section 4.2.3.2 Encoding of Presets . 17719 17720 16887 Bit 7 17721 17722 16888 Set to 1b. 17723 17724 Page 288 For Equalization at 32.0 GT/s or higher Data Rate: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17724 For Equalization at 32.0 GT/s or higher Data Rate: 16889 17725 16890 17726 7 16891 17728 16892 16893 Bit 0 17727 Transmitter Precode Request - See Section 4.2.2.5 Precoding . This bit has no defined usage in receivers at this time. 17729 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). 17730 Bit 2:1 17731 17732 16894 Reserved 17733 17734 16895 Bit 6:3 17735 16896 When operating at 8.0 GT/s or 16.0 GT/s: 17736 Transmitter Preset. See Section 4.2.3.2 Encoding of Presets . 16897 17737 17738 16898 16899 Bit 5:0 - FS when the EC field of Symbol 6 is 01b (see Section 4.2.3.1 Rules for Transmitter Coefficients ). Otherwise, Pre-cursor Coefficient for the current data rate of operation. 16900 17740 Set to 1b. 17741 16901 17742 16902 Bit 6 - Reserved. 16903 17743 16904 16905 Bit 7 17739 17744 Bit 7 - Retimer Equalization Extend. This bit is defined for use in the Recovery.Equalization LTSSM state when operating at 16.0 GT/s. In all other LTSSM states and when operating at 8.0 GT/s, it is Reserved. 17745 16906 17746 16907 17747 17748 16908 16909 16911 Bit 1:0 17749 17750 16910 When operating at 8.0 GT/s or higher data rate: Equalization Control (EC). These bits are only used in the Recovery.Equalization and Loopback LTSSM states. See Section 4.2.6.4.2 Recovery.Equalization and Section 4.2.6.10 Loopback . In all other LTSSM states, they must be set to 00b. 17751 8 17752 Bit 2 17753 17754 Reset EIEOS Interval Count. This bit is defined for use in the Recovery.Equalization LTSSM state. See Section 4.2.6.4.2 Recovery.Equalization and Section 4.2.4.3 Electrical Idle Sequences (EIOS) . In all other LTSSM states, it is Reserved. 17755 17756 Bit 6:3 17757 17758 Page 289 Transmitter Preset. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates and Section 4.2.6 Link Training and Status State Rules . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17758 Transmitter Preset. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates and Section 4.2.6 Link Training and Status State Rules . 17759 17760 Bit 7 17761 17762 Use Preset/Equalization Redo. This bit is defined for use in the Recovery.Equalization, Recovery.RcvrLock and Loopback LTSSM states. See Section 4.2.6.4.1 Recovery.RcvrLock , Section 4.2.6.4.2 Recovery.Equalization and Section 4.2.6.10 Loopback . In all other LTSSM states, it is Reserved. 17763 17764 17765 17766 17767 16912 16913 7 17768 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). 17769 17770 16914 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). When operating at 8.0 GT/s or higher: 17771 17772 16915 Bit 5:0 17773 16916 When operating at 8.0 GT/s or 16.0 GT/s: 16917 17774 FS when the EC field of Symbol 6 is 01b (see Section 4.2.3.1 Rules for Transmitter Coefficients ). Otherwise, Pre-cursor Coefficient for the current data rate of operation. 17775 17776 16918 16919 Bit 6 17777 Bit 5:0 - LF when the EC field of Symbol 6 is 01b (see Section 4.2.3.1 Rules for Transmitter Coefficients ). Otherwise, Cursor Coefficient for the current data rate of operation. 16920 17778 Transmitter Precoding on. This bit is defined for use in the Recovery state for use at 32.0 GT/s or higher. See Section 4.2.2.5 Precoding . In all the other cases, it is Reserved. 17779 17780 16921 16922 Bit 7:6 - Reserved. 17782 16923 17783 16924 17784 16925 17785 16926 Retimer Equalization Extend bit. This bit is defined for use in the Recovery.Equalization LTSSM state when operating at 16.0 GT/s or higher data rate. In all other LTSSM states and when operating at 8.0 GT/s, it is Reserved. 17786 16927 9 16928 17787 17788 16929 16930 Bit 7 17781 8 17789 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). 17790 17791 16931 17792 17793 Page 290 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). When operating at 8.0 GT/s or higher data rate: Bit 5:0 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17793 16932 Bit 5:0 17794 16933 When operating at 8.0 GT/s or 16.0 GT/s: 16934 17795 LF when the EC field of Symbol 6 is 01b (see Section 4.2.3.1 Rules for Transmitter Coefficients ). Otherwise, Cursor Coefficient for the current data rate of operation. 17796 17797 16935 Bit 7:6 17798 16936 Bit 5:0 - Post-cursor Coefficient for the current 17799 Reserved. data rate of operation. 16937 17800 16938 16939 17801 Bit 6 - Reject Coefficient Values. This bit can only be set to 1b in specific Phases of the Recovery.Equalization LTSSM State. See Section 4.2.6.4.2 Recovery.Equalization . In all other LTSSM states, it must be set to 0b. 16940 17802 16941 16942 17803 Bit 7 - Parity (P). This bit is the even parity of all bits of Symbols 6, 7, and 8 and bits 6:0 of Symbol 9. Receivers must calculate the parity of the received bits and compare it to the received Parity bit. Received TS1 Ordered Sets are valid only if the calculated and received Parity match. 16943 17804 17805 16944 9 17806 17807 17808 16945 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). When operating at 8.0 GT/s or higher data rate: 17809 17810 16946 Bit 5:0 17811 16947 10 - 13 17812 Post-cursor Coefficient for the current data rate of operation. 16948 17813 17814 16949 16950 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). 16951 17816 Reject Coefficient Values bit. This bit can only be set to 1b in specific Phases of the Recovery.Equalization LTSSM State. See Section 4.2.6.4.2 Recovery.Equalization . In all other LTSSM states, it must be set to 0b. 17817 17818 16952 16953 Bit 6 17815 Bit 7 17819 When operating at 8.0 GT/s or above: TS1 Identifier. Encoded as 4Ah. 17820 16954 17821 16955 17822 Page 291 Parity (P). This bit is the even parity of all bits of Symbols 6, 7, and 8 and bits 6:0 of Symbol 9. Receivers must calculate the parity of the received bits and compare it to the received Parity bit. Received TS1 Ordered Sets are valid only if the calculated and received Parity match. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16955 17822 16956 17823 16957 17824 16958 14 - 15 16959 17825 17826 16960 16961 10 - 13 17827 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). 17828 17829 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). When operating at 8.0 GT/s or above: TS1 Identifier. Encoded as 4Ah. 17830 17831 16962 17832 16963 17833 17834 14 - 15 17835 17836 16964 When operating at 8.0 GT/s or above: TS1 Identifier (encoded as 4Ah) or a DC Balance Symbol. 17837 16965 17838 16966 17839 16967 17840 16968 17841 16969 17842 16970 17843 16971 When operating at 2.5 or 5.0 GT/s: TS1 Identifier. Encoded as D10.2 (4Ah). When operating at 8.0 GT/s or above: TS1 Identifier (encoded as 4Ah) or a DC Balance Symbol. 17844 16972 Table 4-6 TS2 Ordered Set 16973 17845 Table 4-7 TS2 Ordered Set 17846 16974 Symbol Number 16975 17847 Symbol Number 17848 16976 Description 17849 16977 17850 16978 17851 16979 Description 17852 16980 17853 0 16981 0 17854 16982 16983 When operating at 2.5 or 5.0 GT/s: COM (K28.5) 17855 for Symbol alignment. When operating at 2.5 or 5.0 GT/s: COM (K28.5) for Symbol alignment. 16984 16985 16986 When operating at 8.0 GT/s or above: Encoded as 17856 2Dh (TS2 Ordered Set). 16987 17857 16988 17858 16989 17859 16990 16991 16992 Page 292 When operating at 8.0 GT/s or above: Encoded as 2Dh (TS2 Ordered Set). 17860 1 17861 17862 1 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 16992 17862 16993 17863 16994 Link Number. 16995 17864 Link Number. 17865 16996 16997 Ports that do not support 8.0 GT/s or above: 17866 0-255, PAD. Ports that do not support 8.0 GT/s or above: 0-255, PAD. 16998 16999 17000 Downstream Ports that support 8.0 GT/s or above: 17867 0-31, PAD. Downstream Ports that support 8.0 GT/s or above: 0-31, PAD. 17001 17002 17003 Upstream Ports that support 8.0 GT/s or above: 17868 0-255, PAD. Upstream Ports that support 8.0 GT/s or above: 0-255, PAD. 17004 17005 17006 When operating at 2.5 or 5.0 GT/s: PAD is encoded 17869 as K23.7. When operating at 2.5 or 5.0 GT/s: PAD is encoded as K23.7. 17007 17008 17009 When operating at 8.0 GT/s or above: PAD is 17870 encoded as F7h. When operating at 8.0 GT/s or above: PAD is encoded as F7h. 17010 17871 17011 17872 17012 17873 17013 17874 17014 17875 2 17015 2 17876 17016 17877 17017 Lane Number within Link. 17018 17878 Lane Number within Link. 17879 17019 17020 When operating at 2.5 or 5.0 GT/s: 0-31, PAD. PAD 17880 is encoded as K23.7. When operating at 2.5 or 5.0 GT/s: 0-31, PAD. PAD is encoded as K23.7. 17021 17022 17023 When operating at 8.0 GT/s or above: 0-31, PAD. 17881 PAD is encoded as F7h. 17024 17882 17025 17883 17026 17884 17027 17885 17028 3 17029 17030 When operating at 8.0 GT/s or above: 0-31, PAD. PAD is encoded as F7h. 17886 3 17887 N_FTS. The number of Fast Training Sequences required by the Receiver: 0-255. 17888 17031 17889 17032 17890 17033 17034 Page 293 N_FTS. The number of Fast Training Sequences required by the Receiver: 0-255. 17891 4 17892 4 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17034 17892 4 17035 4 17893 17036 17894 17037 Data Rate Identifier 17038 17895 Data Rate Identifier 17896 17039 17897 17040 Bit 0 - Reserved for future Data Rate 17898 Bit 0 17899 17900 17041 Reserved for future Data Rate 17901 17902 17042 Bit 1 17903 17043 Bit 1 - 2.5 GT/s Data Rate Supported. Must be set 17904 to 1b. 2.5 GT/s Data Rate Supported. Must be set to 1b. 17044 17905 17906 17045 17046 Bit 2 17907 Bit 2 - 5.0 GT/s Data Rate Supported. Must be set to 1b if Bit 3 is 1b. See Section 8.2 Interoperability Criteria . 17047 17908 5.0 GT/s Data Rate Supported. Must be set to 1b if Bit 3 is 1b. See Section 8.2 Interoperability Criteria . 17909 17910 17048 Bit 3 17911 17049 Bit 3 - 8.0 GT/s Data Rate Supported. Must be set 17912 to 1b if Bit 4 is 1b. 8.0 GT/s Data Rate Supported. Must be set to 1b if Bit 4 is 1b. 17050 17913 17914 17051 Bit 4 17915 17052 Bit 4 - 16.0 GT/s Data Rate Supported 17916 16.0 GT/s Data Rate Supported. Must be set to 1b if Bit 5 is 1b. 17053 17917 17918 17054 Bit 5 17919 17055 Bit 5 - Reserved for future Data Rate 17056 17920 32.0 GT/s Data Rate Supported 17921 17922 17057 17058 Bit 6 17923 Bit 6 - Autonomous Change/Selectable De-emphasis/ Link Upconfigure Capability. This bit is defined for use in the following LTSSM states: Polling.Configuration, Configuration.Complete, and Recovery. In all other LTSSM states, it is Reserved. 17059 17924 Autonomous Change/Selectable De-emphasis/Link Upconfigure Capability. This bit is defined for use in the following LTSSM states: Polling.Configuration, Configuration.Complete, and Recovery. In all other LTSSM states, it is Reserved. 17925 17926 17060 17061 Bit 7 17927 Bit 7 - speed_change. This bit can be set to 1b only in the Recovery.RcvrCfg LTSSM state. In all other LTSSM states, it is Reserved. 17928 17062 17929 17063 17930 17064 17931 17065 17066 Page 294 speed_change. This bit can be set to 1b only in the Recovery.RcvrCfg LTSSM state. In all other LTSSM states, it is Reserved. 17932 5 17933 5 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17066 17933 5 17067 17068 17935 17069 Training Control 17070 17936 17938 17072 Bit 0 - Hot Reset 17073 17939 Bit 0 17940 17941 17074 Hot Reset bit 17942 17075 Bit 0 = 0b, Deassert Bit 0 = 1b, Assert 17076 17943 0b 17944 17945 17077 Deassert 17946 17078 Bit 1 - Disable Link 17079 17947 1b 17948 17949 17080 Assert 17950 17081 Bit 1 = 0b, Deassert Bit 1 = 1b, Assert 17082 17951 17952 17083 Bit 1 17953 17084 Bit 2 - Loopback 17085 17954 Disable Link bit 17955 17956 17086 0b 17957 17087 Bit 2 = 0b, Deassert Bit 2 = 1b, Assert 17088 17958 Deassert 17959 17960 17089 1b 17961 Bit 3 - Disable Scrambling in 2.5 GT/s and 5.0 GT/s data rates; Reserved in other data rates 17091 17962 Assert 17963 17092 17964 17093 Bit 3 = 0b, Deassert Bit 3 = 1b, Assert 17094 17965 Bit 2 17966 17967 17095 17096 Training Control 17937 17071 17090 5 17934 Loopback bit 17968 Bit 4 - Retimer Present in 2.5 GT/s data rate. Reserved in other data rates. 17097 17969 17970 17971 17098 17099 Bit 4 = 0b, No Retimers present 17973 17975 Page 295 Assert 17976 Bit 4 = 1b, One or more Retimers present 17977 17978 17104 1b 17974 17101 17103 Deassert 17972 17100 17102 0b 17979 Bit 3 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17104 17105 17979 Bit 5 - Two Retimers Present in 2.5 GT/s data rate. Reserved in other data rates. Ports that support 16.0 GT/s data rate or higher must implement this bit. Ports that support only 8.0 GT/s data rate or lower are permitted to implement this bit. 17106 17980 17981 17982 17107 0b 17983 17108 Bit 5 = 0b, Zero or one Retimers present 17109 17984 Deassert 17985 17986 17110 1b 17987 17111 Bit 5 = 1b, Two or more Retimers present 17112 17988 Assert 17989 17113 17990 17114 Bit 6:7 - Reserved 17115 17991 Bit 4 17992 17993 17116 Retimer Present bit in 2.5 GT/s data rate. Reserved in other data rates. 17994 17995 17117 0b 17996 17997 17118 No Retimers present 17998 17119 17999 6 17120 1b 18000 18001 17121 One or more Retimers present 18002 17122 When operating at 2.5 or 5.0 GT/s: 17123 18003 18004 17124 17125 Disable Scrambling bit in 2.5 GT/s and 5.0 GT/s data rates; Reserved in other data rates Bit 5 18005 Standard TS2 Ordered Sets encode this Symbol as a TS2 Identifier, D5.2 (45h). 18006 Two Retimers Present bit in 2.5 GT/s data rate. Reserved in other data rates. Ports that support 16.0 GT/s data rate or higher must implement this bit. Ports that support only 8.0 GT/s data rate or lower are permitted to implement this bit. 18007 18008 0b 18009 18010 Zero or one Retimers present 18011 18012 1b 18013 18014 Two or more Retimers present 18015 18016 18017 Bit 7:6 18018 18019 Enhanced Link Behavior Control 18020 18021 Page 296 00b /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18021 00b 18022 18023 Full Equalization required, Modified TS1/TS2 Ordered Sets not 18024 supported. 18025 18026 17126 01b 18027 18028 Equalization bypass to highest rate support 18029 Modified TS1/TS2 Ordered Sets not supported. 18030 17127 See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates . 18031 18032 10b 18033 18034 18035 18036 No Equalization Needed, A device advertising this capability must support Equalization bypass to highest rate. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates . Modified TS1/TS2 Ordered Sets not supported 18037 18038 11b 18039 18040 Modified TS1/TS2 Ordered Sets supported, Equalization bypass options specified in 18041 Modified TS1/TS2 Ordered Sets. 18042 18043 18044 These bits defined for use in Polling and Configuration when LinkUp=0 and 32.0 GT/s or higher data rate is supported. In all other cases, Bits 7:6 are Reserved. 18045 18046 18047 18048 18049 18050 6 18051 18052 18053 17128 EQ TS2 Ordered Sets encode this Symbol as 18054 follows: 18055 17129 When operating at 2.5 or 5.0 GT/s: Standard TS2 Ordered Sets encode this Symbol as a TS2 Identifier, D5.2 (45h). EQ TS2 Ordered Sets encode this Symbol as follows: For Equalization at 8.0 GT/s Data Rate: 18056 18057 17130 17131 Bit 2:0 18058 Bit 2:0 - 8.0 GT/ s Receiver Preset Hint. See Section 4.2.3.2 Encoding of Presets . Page 297 18059 Receiver Preset Hint. See Section 4.2.3.2 Encoding of Presets . /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17131 Bit 2:0 - 8.0 GT/ s Receiver Preset Hint. See Section 4.2.3.2 Encoding of Presets . 17132 18059 Receiver Preset Hint. See Section 4.2.3.2 Encoding of Presets . 18060 18061 17133 17134 Bit 6:3 18062 Bit 6:3 - 8.0 GT/ s Transmitter Preset. See Section 4.2.3.2 Encoding of Presets . 17135 18063 Transmitter Preset. See Section 4.2.3.2 Encoding of Presets . 18064 18065 17136 Bit 7 18066 17137 Bit 7 -Set to 1b. 17138 18067 Set to 1b. 18068 18069 For Equalization at 32.0 GT/s or higher Data Rate: 17139 18070 17140 When operating at 8.0 GT/s or 16.0 GT/ s: 17141 18071 Bit 0 18072 18073 Transmitter Precode Request. See Section 4.2.2.5 Precoding . 17142 18074 17143 Bit 4:0 - Reserved. 17144 18075 Bit 2:1 18076 18077 17145 17146 Reserved 18078 Bit 5 - Equalization Request Data Rate. A value of 0b indicates 8.0 GT/s Data Rate and 1b indicates 16.0 GT/s Data Rate. This bit is defined for use in the Recovery.RcvrCfg LTSSM state. In all other LTSSM states, it is Reserved. 17147 18079 Bit 6:3 18080 18081 Transmitter Preset. See Section 4.2.3.2 Encoding of Presets . 17148 17149 18082 Bit 6 - Quiesce Guarantee. This bit is defined for use in the Recovery.RcvrCfg LTSSM state. In all other LTSSM states, it is Reserved. 17150 18083 Bit 7 18084 18085 17151 17152 Bit 7 - Request Equalization. This bit is defined for use in the Recovery.RcvrCfg LTSSM state. In all other LTSSM states, it is Reserved. 17153 18087 17154 18088 18089 17155 When operating at 8.0 GT/s or higher Data Rate: 18090 18091 17156 Bit 3:0 18092 17157 7 17158 18093 Reserved. 18094 18095 17159 17160 Set to 1b. 18086 Bit 5:4 18096 When operating at 2.5 or 5.0 GT/s: TS2 Identifier. Encoded as D5.2 (45h). Page 298 18097 Equalization Request Data Rate. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17160 When operating at 2.5 or 5.0 GT/s: TS2 Identifier. Encoded as D5.2 (45h). 17161 18097 Equalization Request Data Rate. 18098 18099 17162 00b 18100 17163 When operating at 8.0 GT/s or above: 18101 8.0 GT/s 18102 18103 10b 18104 18105 16.0 GT/s 18106 18107 01b 18108 18109 32.0 GT/s 18110 18111 11b 18112 18113 Reserved 18114 18115 18116 17164 18117 17165 18118 These bits are defined for use in the Recovery.RcvrCfg LTSSM state. In all other LTSSM states, they are Reserved. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates for usage and recognize that these bits are nonsequentially encoded for purposes of backwards compatibility 18119 Bit 6 18120 18121 Quiesce Guarantee. This bit is defined for use in the Recovery.RcvrCfg LTSSM state. In all other LTSSM states, it is Reserved. 18122 18123 Bit 7 18124 18125 Request Equalization. This bit is defined for use in the Recovery.RcvrCfg LTSSM state. In all other LTSSM states, it is Reserved. 18126 18127 18128 18129 18130 18131 7 18132 18133 When operating at 2.5 or 5.0 GT/s: TS2 Identifier. Encoded as D5.2 (45h). 18134 17166 Standard TS2 Ordered Sets encode this Symbol as a When operating at 8.0 GT/s or above: Standard TS2 Ordered Sets encode this Symbol as 18135 TS2 Identifier, 45h. a TS2 Identifier, 45h. 18136 Page 299 128b/130b EQ TS2 Ordered Sets encode this Symbol as follows: /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18136 128b/130b EQ TS2 Ordered Sets encode this Symbol as follows: 17167 18137 18138 17168 Bit 0 18139 17169 8GT EQ TS2 Ordered Sets encode this Symbol as 18140 follows: 17170 Transmitter Precode Request for operating at 32.0 GT/s or higher Data Rate. See Section 4.2.2.5 Precoding . This bit is Reserved if the 128b/130b EQ TS2 is sent for equalization at data rates of 8.0 GT/s or 16.0 GT/s. 18141 18142 17171 Bit 2:1 18143 17172 Bit 2:0 - Reserved 17173 18144 Reserved 18145 18146 17174 17175 Bit 6:3 18147 Bit 6:3 - 16.0 GT/s Transmitter Preset. See Section 4.2.3.2 Encoding of Presets . 17176 18148 128b/130b Transmitter Preset. See Section 4.2.3.2 Encoding of Presets . 18149 18150 17177 17178 Bit 7 - Set to 1b. 17179 18152 Set to 1b. 18153 17180 17181 Bit 7 18151 18154 This definition is only valid in the Recovery.RcvrCfg LTSSM state when Preset values are being communicated. 18155 17182 18156 17183 18157 17184 18158 17185 18159 This definition is only valid in the Recovery.RcvrCfg LTSSM state when Preset values are being communicated. 18160 18161 17186 8 - 13 17187 18162 8 - 13 18163 18164 When operating at 2.5 or 5.0 GT/s: TS2 Identifier. Encoded as D5.2 (45h). 18165 When operating at 8.0 GT/s or above: TS2 Identifier. Encoded as 45h. 18166 18167 18168 18169 18170 17188 17189 When operating at 2.5 or 5.0 GT/s: TS2 Identifier. Encoded as D5.2 (45h). 18172 17190 18174 17191 18175 When operating at 8.0 GT/s or above: TS2 Identifier. Encoded as 45h. Page 300 When operating at 2.5 or 5.0 GT/s: TS2 Identifier. Encoded as D5.2 (45h). 18173 17192 14-15 18171 When operating at 8.0 GT/s or above: TS2 Identifier (encoded as 45h) or a DC Balance Symbol. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17192 When operating at 8.0 GT/s or above: TS2 Identifier. Encoded as 45h. 17193 18176 17194 18177 17195 18178 17196 18179 17197 14-15 17198 18180 18181 Table 4-8 Modified TS1/TS2 Ordered Set (8b/10b encoding) 17199 17200 18182 When operating at 2.5 or 5.0 GT/s: TS2 Identifier. Encoded as D5.2 (45h). 18183 Symbol Number 18184 18185 17201 17202 17203 Description 18186 18187 When operating at 8.0 GT/s or above: TS2 Identifier (encoded as 45h) or a DC Balance Symbol. 18188 18189 0 18190 18191 COM (K28.5) for Symbol alignment. 18192 18193 18194 18195 1 18196 18197 18198 Link Number. 18199 18200 18201 Downstream Ports: 0-31, PAD (K23.7). 18202 18203 18204 Upstream Ports: 0-255, PAD (K23.7). 18205 18206 18207 18208 18209 2 18210 18211 Lane Number within Link : 0-31, PAD. PAD is encoded as K23.7. 18212 18213 18214 18215 3 18216 18217 18218 18219 18220 Page 301 N_FTS. The number of Fast Training Sequences required by the Receiver: 0-255. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18220 18221 4 18222 18223 18224 Data Rate Identifier 18225 18226 18227 Bit 0 18228 18229 Reserved for future Data Rate. 18230 18231 Bit 1 18232 18233 2.5 GT/s Data Rate Supported. Must be set to 1b. 18234 18235 Bit 2 18236 18237 5.0 GT/s Data Rate Supported. Must be set to 1b if Bit 3 is 1b. See Section 8.2 Interoperability Criteria . 18238 18239 Bit 3 18240 18241 8.0 GT/s Data Rate Supported. Must be set to 1b if Bit 4 is 1b. 18242 18243 Bit 4 18244 18245 16.0 GT/s Data Rate Supported. Must be set to 1b if Bit 5 is 1b. 18246 18247 Bit 5 18248 18249 32.0 GT/s Data Rate Supported. 18250 18251 Bit 6 18252 18253 Link Upconfigure Capability 18254 18255 Bit 7 18256 18257 Reserved. 18258 18259 18260 18261 18262 5 18263 18264 18265 18266 Page 302 Training/ Equalization Control /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18266 18267 18268 Bit 0 18269 18270 Equalization bypass to highest rate support. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates 18271 18272 Bit 1 18273 18274 No Equalization Needed bit. See Section 4.2.3 Link Equalization Procedure for 8.0 GT/s and Higher Data Rates 18275 18276 Bit 3:2 18277 18278 Reserved 18279 18280 Bit 4 18281 18282 Retimer Present bit 18283 18284 0b 18285 18286 No Retimers present 18287 18288 1b 18289 18290 One Retimer is present 18291 18292 18293 Bit 5 18294 18295 Two or more Retimers Present 18296 18297 Bit 6 18298 18299 1b 18300 18301 Bit 7 18302 18303 1b 18304 18305 18306 18307 18308 6 18309 18310 18311 For Modified TS1: TS1 Identifier, encoded as D10.2 18312 Page 303 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18312 18313 18314 For Modified TS2: TS2 Identifier, encoded as D5.2 18315 18316 18317 18318 18319 7 18320 18321 18322 For Modified TS1: TS1 Identifier, encoded as D10.2 18323 18324 18325 For Modified TS2: TS2 Identifier, encoded as D5.2 18326 18327 18328 18329 18330 8-9 18331 18332 18333 Bits 2:0 18334 18335 Modified TS Usage 18336 18337 000b 18338 18339 PCIe protocol only 18340 18341 001b 18342 18343 PCIe protocol only with vendor defined Training Set Messages 18344 18345 010b 18346 18347 Alternate Protocol Negotiation 18348 18349 011b through 111b 18350 18351 Reserved 18352 18353 18354 18355 Page 304 The values advertised in these bits must be consistent with the Modified TS Usage Mode Selected field of the 32.0 GT/ s Control register and the capabilities of the device. These are bits[2:0] of Symbol 8. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18355 18356 18357 Bits 15:3 18358 18359 Modified TS Information 1 18360 18361 If Modified TS Usage = 001b or 010b; else Reserved. 18362 18363 18364 18365 18366 18367 10-11 18368 18369 18370 Training Set Message Vendor ID if Modified TS Usage = 001b. 17204 18371 17205 18372 18373 Alternate Protocol Vendor ID if Modified TS Usage = 010b. 17206 18374 17207 18375 18376 17208 18377 17209 18378 17210 18379 17211 18380 17212 4.2.4.2 Electrical Idle Sequences 17213 12-14 18383 Before a Transmitter enters Electrical Idle, it must always send an Electrical Idle Ordered Set Sequence (EIOSQ), unless otherwise specified. An Electrical Idle Ordered Set Sequence (EIOSQ) is defined as one EIOS if the current Data Rate is 2.5 GT/s, 8.0 GT/s or 16.0 GT/s Data Rate, or two consecutive EIOSs if the current Data Rate is 5.0 GT/s. 17216 18384 If Modified TS Usage = 001b or 010b, Modified TS Information 2 18385 17217 17218 18381 18382 17214 17215 Reserved for other cases. 18386 When using 8b/10b encoding, an EIOS is a K28.5 (COM) followed by three K28.3 (IDL) Symbols. Transmitters must transmit all Symbols of an EIOS. An EIOS is received when the COM and two of the three IDL Symbols are received. When using 128b/130b encoding, an EIOS is an Ordered Set block, as defined in Table 4-8 Electrical Idle Ordered Set (EIOS) for 8.0 GT/s and Above Data Rates . Transmitters must transmit all Symbols of an EIOS if additional EIOSs are to be transmitted following it. Transmitters must transmit Symbols 0-13 of an EIOS, but are permitted to terminate the EIOS anywhere in Symbols 14 or 15, when transitioning to Electrical Idle after it. An EIOS is considered received when Symbols 0-3 of an Ordered Set Block match the definition of an EIOS. 18387 18389 18390 18391 18392 15 18393 18394 18395 18396 Page 305 Else, Reserved 18388 Bit-wise even parity of Symbols 4 through 14. . For example: Bit 0 = Symbol 4 Bit [0] ^ Symbol 5 Bit [0] ^ …. ^ Symbol 14 Bit [0], … , Bit [7] = Symbol 4 Bit [7] ^ Symbol 5 Bit [7] ^ …. ^ Symbol 14 Bit [7] /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18396 18397 18398 18399 18400 Fields in the Modified TS1/TS2 Ordered Sets that extend over multiple Symbols use the little endian format using all the bits over those multiple Symbols. For example, Symbols 8 and 9 of the Modified TS1/TS2 comprise 16 bits. The Modified TS Usage field goes in bits [2:0] of Symbol 8 with the bit 0 of Modified TS Usage field placed in bit 0 of Symbol 8, bit 1 of Modified TS Usage field placed in bit 1 of Symbol 8, and bit 2 of Modified TS Usage field placed in bit 2 of Symbol 8. Similarly, bit 12 of the 13 bits of Modified TS Information 1 field is placed in bit 7 of Symbol 9 where as bit 0 of Modified TS Information 1 is placed in bit 3 of Symbol 8. 18401 18402 18403 18404 18405 4.2.4.2 Alternate Protocol Negotiation 18406 18407 18408 In addition to the decision to skip equalization, alternate protocols can also be negotiated during the Configuration.Lanenum.Wait, Configuration.Lanenum.Accept, and Configuration.Complete substates, while LinkUp=0b, through the exchange of Modified TS1/TS2 Ordered sets in the 8b/10b encoding. 18409 18410 18411 Alternate protocol(s) may be supported with PCIe PHY in 128b/130b encoding. An alternate protocol is defined to be a non-PCIe protocol using the PCIe PHY layer. One may choose to run PCIe protocol in addition to one or multiple alternate protocols in the alternate protocol mode. The Ordered Set blocks are used as-is, along with the rules governing SKP Ordered Set insertion and the transition between Ordered Set and Data Blocks. The contents of the Data Blocks, however, may be modified according to the rules of the alternate protocol. 18412 18413 18414 18415 18416 Implementation Note Alternate Protocols should have an EDS Token Equivalent 18417 18418 18419 18420 18421 Page 306 The EDS Token is used in PCI Express to indicate a switch from Data Blocks to Ordered Set blocks. This additional "redundant" information ensures that a random bit error in the 2 bit block header isn't incorrectly interpreted as the end of a data stream. This is one mechanism used by PCI Express to accomplish an undected data error Hamming Distance of 4. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18421 18422 18423 Alternate protocols should have an equivalent mechansim. 18424 18425 18426 18427 18428 The following diagram represents the states where alternate protocol and equalization bypass negotiation occurs: 18429 18430 18431 18432 18433 Figure 4-24 Alternate Protocol Negotiation and Equalization Bypass LTSSM States 18434 18435 18436 18437 Downstream Ports manage Alternate Protocol Negotiation and Training Set Messages based on the value of the Modified TS Usage Mode Selected field when the Port is in Configuration.Lanenum.Wait, Configuration.Lanenum.Accept, and Configuration.Complete substates with LinkUp = 0. 18438 18439 18440 Upstream Ports must respond to unsupported Modified TS Usage values by transmitting Modified TS Usage 000b. 18441 18442 18443 If Modified TS Usage Mode Selected is: 18444 18445 18446 000b 18447 18448 No Alternate Protocol Negotiation or Training Set Message occurs. The link will operate as a PCI Express Link. 18449 18450 001b 18451 18452 Training Set Messages are enabled. Modified TS Information 1 and Modified TS Information 2 fields carry the vendor specific messages defined by the Training Set Message Vendor ID field. 18453 18454 010b 18455 18456 Page 307 Alternate Protocol Negotiation is enabled. Modified TS Information 1 and Modified TS Information 2 fields carry the alternate protocol details defined by the Alternate Protocol Vendor ID field. A protocol request or response is associated with the protocol determined by Alternate Protocol Details and Alternate Protocol Vendor ID. A protocol request or response is associated with the protocol defined by the Alternate Protocol Vendor ID field. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18456 Alternate Protocol Negotiation is enabled. Modified TS Information 1 and Modified TS Information 2 fields carry the alternate protocol details defined by the Alternate Protocol Vendor ID field. A protocol request or response is associated with the protocol determined by Alternate Protocol Details and Alternate Protocol Vendor ID. A protocol request or response is associated with the protocol defined by the Alternate Protocol Vendor ID field. 18457 18458 The Alternate Protocol Negotiation Status field indicates the progress of the negotiation protocol. 18459 18460 18461 others 18462 18463 Reserved 18464 18465 18466 A Downstream Port that supports Alternate Protocol Negotiation will start the negotiation process when it first enters Configuration.Lanenum.Wait, LinkUp = 0, and Modified TS Usage Mode Selected field is 010b. Starting negotiation consists of sending Modified TS1/TS2 Ordered Sets with Modified TS Usage = 010b. 18467 18468 18469 18470 Table 4-9 Modified TS Information 1 field in Modified TS1/TS2 Ordered Sets if Modified TS Usage = 010b (Alternate Protocol) 18471 18472 Bits 18473 18474 Field 18475 18476 Description 18477 18478 18479 18480 4:3 18481 18482 Alternate Protocol Negotiation Status 18483 18484 For Modified TS1 Ordered Sets: 18485 18486 00b 18487 18488 18489 DP 18490 18491 18492 Indicates a protocol request from the Downstream Port asking whether the Upstream Port supports a particular alternate protocol. 18493 18494 18495 18496 Page 308 UP /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18496 18497 18498 Indicates that the Upstream Port does not have an answer for a protocol request yet. This occurs either when it is evaluating the protocol request or it has not received two consecutive Modified TS1s to perform the evaluation. In the former case, Alternate Protocol Vendor ID and Alternate Protocol Details reflect what it received, while Modified TS Information 2 is protocol specific. In the latter case, all 3 fields must be 0. 18499 18500 18501 18502 01b 18503 18504 18505 DP 18506 18507 Reserved 18508 18509 UP 18510 18511 18512 Indicates that the Upstream Port does not support the requested protocol. Alternate Protocol Vendor ID and Alternate Protocol Details reflect what it received. Modified TS Information 2 must be all 0s. 18513 18514 18515 18516 10b 18517 18518 18519 DP 18520 18521 Reserved 18522 18523 UP 18524 18525 18526 Indicates that the Upstream Port supports the requested protocol. Alternate Protocol Vendor ID and Alternate Protocol Details reflect what it received, while Modified TS Information 2 field is protocol specific. 18527 18528 18529 18530 11b 18531 18532 18533 18534 Page 309 Reserved /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18534 18535 For Modified TS2 Ordered Sets: 18536 18537 18538 00b 18539 18540 18541 Indicates a protocol confirmation from the Downstream Port as well as the Upstream Port. Behavior is undefined if the Downstream Port had not earlier received status 10b for this protocol in this instance of protocol negotiation during the Modified TS1 Ordered Sets. Similarly, behavior is undefined if the Upstream Port had not earlier transmitted status 10b for this protocol in this instance of protocol negotiation during the Modified TS1 Ordered Sets. 18542 18543 18544 No protocol is selected unless the Downstream Port sends and receives a protocol confirmation in the Modified TS2 Ordered Sets. If the Downstream Port decides not to use any Alternate Protocol, it may optionally indicate this by transmitting Modified TS2 Ordered Set with Modified TS Usage of 000b. 18545 18546 18547 01b, 10b, 11b 18548 18549 Reserved 18550 18551 18552 18553 18554 15:5 18555 18556 Alternate Protocol Details 18557 18558 18559 Alternate Protocol Details is Modified TS Usage = 010b. 18560 18561 18562 18563 18564 18565 18566 If Modified TS Usage = 001b, then Modified TS Information 1 and Modified TS Information 2 contain details of the training set messages. 18567 18568 18569 Page 310 Alternate Protocol Negotiation must be concurrent with the Lane number negotiation. The DP is responsible for ensuring that they arrive at a consensus on the Alternate Protocol Negotiation prior to transitioning to Configuration.Complete substate. It is permitted to fall back to PCIe protocol if the Alternate Protocol Negotiation does not arrive at a consensus. On a successful negotiation to alternate protocol, the Link moves to L0 at 2.5 GT/s, switches the data rate to the higher data rates, performing equalization, if needed and enters L0 at the higest data rate desired. After transmitting the SDS Ordered Set in the highest data rate after equalization has been performed, the Data Blocks will carry the alternate protocol and the Link will be under the control of the alternate protocol. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18569 Alternate Protocol Negotiation must be concurrent with the Lane number negotiation. The DP is responsible for ensuring that they arrive at a consensus on the Alternate Protocol Negotiation prior to transitioning to Configuration.Complete substate. It is permitted to fall back to PCIe protocol if the Alternate Protocol Negotiation does not arrive at a consensus. On a successful negotiation to alternate protocol, the Link moves to L0 at 2.5 GT/s, switches the data rate to the higher data rates, performing equalization, if needed and enters L0 at the higest data rate desired. After transmitting the SDS Ordered Set in the highest data rate after equalization has been performed, the Data Blocks will carry the alternate protocol and the Link will be under the control of the alternate protocol. 18570 18571 18572 18573 18574 4.2.4.3 Electrical Idle Sequences (EIOS) 18575 18576 18577 Before a Transmitter enters Electrical Idle, it must always send an Electrical Idle Ordered Set Sequence (EIOSQ), unless otherwise specified. An Electrical Idle Ordered Set Sequence (EIOSQ) is defined as one EIOS if the current Data Rate is 2.5 GT/s, 8.0 GT/s, 16.0 GT/s, or 32.0 GT/s Data Rate, or two consecutive EIOSs if the current Data Rate is 5.0 GT/s. 18578 18579 18580 17219 18581 17220 18582 17221 18583 17222 Implementation Note Truncation of EIOS Ordered Set 17223 18584 18585 17224 18586 17225 18587 17226 17227 When using 8b/10b encoding, an EIOS is a K28.5 (COM) followed by three K28.3 (IDL) Symbols. Transmitters must transmit all Symbols of an EIOS. An EIOS is received when the COM and two of the three IDL Symbols are received. When using 128b/130b encoding, an EIOS is an Ordered Set block, as defined in Table 4-11 Electrical Idle Ordered Set (EIOS) for 8.0 GT/s and Above Data Rates . Transmitters must transmit all Symbols of an EIOS if additional EIOSs are to be transmitted following it. Transmitters must transmit Symbols 0-13 of an EIOS, but are permitted to terminate the EIOS anywhere in Symbols 14 or 15, when transitioning to Electrical Idle after it. An EIOS is considered received when Symbols 0-3 of an Ordered Set Block match the definition of an EIOS. Implementation Note Truncation of EIOS Ordered Set 18588 Truncation in the last EIOS is allowed to help implementations where a transmitter may terminate on an internal clock boundary that may not align on a Symbol boundary due to 128b/130b encoding. Truncation is okay since Receivers will just look at the first four Symbols to conclude it is an EIOS. 18589 17228 18590 17229 18591 Page 311 Truncation in the last EIOS is allowed to help implementations where a transmitter may terminate on an internal clock boundary that may not align on a Symbol boundary due to 128b/130b encoding. Truncation is okay since Receivers will just look at the first four Symbols to conclude it is an EIOS. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17229 18591 17230 18592 17231 17232 18593 After transmitting the last Symbol of the last Electrical Idle Ordered Set, the Transmitter must be in a valid Electrical Idle state as specified by TTX-IDLE-SET-TO-IDLE (see Table 8-7 Data Rate Independent Tx Parameters ). 18594 17233 18595 17234 18596 17235 17236 18597 Table 4-7 Electrical Idle Ordered Set (EIOS) for 2.5 GT/s and 5.0 GT/s Data Rates 17237 18598 Table 4-10 Electrical Idle Ordered Set (EIOS) for 2.5 GT/s and 5.0 GT/s Data Rates 18599 17238 Symbol Number 17239 18600 Symbol Number 18601 17240 Encoded Values 17241 18602 Encoded Values 18603 17242 Description 18604 17243 18605 17244 18606 17245 Description 18607 17246 0 17271 18608 0 18633 17272 K28.3 17273 18634 K28.3 18635 17274 IDL 18636 17275 18637 17276 18638 17277 18639 17278 18640 17279 18641 17280 17281 After transmitting the last Symbol of the last Electrical Idle Ordered Set, the Transmitter must be in a valid Electrical Idle state as specified by TTX-IDLE-SET-TO-IDLE (see Table 8-7 Data Rate Independent Tx Parameters ). IDL 18642 Table 4-8 Electrical Idle Ordered Set (EIOS) for 8.0 GT/s and Above Data Rates 17282 17283 18645 Value 18647 Description 18649 18650 17289 18651 17290 18653 66h 18655 66h 18656 EIOS Identifier and Payload 18657 17296 18658 17297 18659 17298 18660 Page 312 0-15 18654 17294 17295 Description 18652 0-15 17292 17293 Value 18648 17288 17291 Symbol Numbers 18646 17286 17287 Table 4-11 Electrical Idle Ordered Set (EIOS) for 8.0 GT/s and Above Data Rates 18644 Symbol Numbers 17284 17285 18643 EIOS Identifier and Payload /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17298 18660 17299 18661 17300 18662 17301 18663 17302 Table 4-9 Electrical Idle Exit Ordered Set (EIEOS) for 18664 5.0 GT/s Data Rate 17303 18665 17304 Symbol Number 17305 18666 Encoded Values 17307 18668 Description 18670 17309 18671 17310 18672 17311 Description 18673 17312 0 17335 18674 0 18697 Notes: This symbol is not scrambled. Previous versions of this specification were less clear and some implementations may have incorrectly scrambled this symbol. It is recommended that devices be tolerant of receiving EIEOS in which this symbol is scrambled. 18698 18699 17338 18700 17339 18701 17340 18702 17341 18703 17342 18704 17343 18705 17344 17345 Encoded Values 18669 17308 17337 Symbol Number 18667 17306 17336 Table 4-12 Electrical Idle Exit Ordered Set (EIEOS) for 5.0 GT/s Data Rate Notes: This symbol is not scrambled. Previous versions of this specification were less clear and some implementations may have incorrectly scrambled this symbol. It is recommended that devices be tolerant of receiving EIEOS in which this symbol is scrambled. 18706 Table 4-10 Electrical Idle Exit Ordered Set (EIEOS) for 8.0 GT/s Data Rates 17346 18707 Table 4-13 Electrical Idle Exit Ordered Set (EIEOS) for 8.0 GT/s Data Rates 18708 17347 Symbol Numbers 17348 18709 Symbol Numbers 18710 17349 Value 17350 18711 Value 18712 17351 Description 18713 17352 18714 17353 18715 17354 Description 18716 17355 0, 2, 4, 6, 8, 10, 12, 14 17369 18717 0, 2, 4, 6, 8, 10, 12, 14 18731 17370 FFh 17371 18732 FFh 18733 17372 A low frequency pattern that alternates between 18734 eight 0s and eight 1s. 17373 18735 17374 18736 17375 18737 17376 18738 17377 18739 Page 313 A low frequency pattern that alternates between eight 0s and eight 1s. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17377 18739 17378 17379 18740 Table 4-11 Electrical Idle Exit Ordered Set (EIEOS) for 16.0 GT/s Data Rate 17380 18741 18742 17381 Symbol Numbers 17382 18743 Symbol Numbers 18744 17383 Value 17384 18745 Value 18746 17385 Description 18747 17386 18748 17387 18749 17388 Description 18750 17389 0, 1, 4, 5, 8, 9, 12, 13 17403 18751 0, 1, 4, 5, 8, 9, 12, 13 18765 17404 FFh 17405 17406 Table 4-14 Electrical Idle Exit Ordered Set (EIEOS) for 16.0 GT/s Data Rate 18766 FFh 18767 A low frequency pattern that alternates between sixteen 0s and sixteen 1s. 18768 17407 18769 17408 18770 17409 18771 17410 18772 17411 18773 17412 18774 18775 A low frequency pattern that alternates between sixteen 0s and sixteen 1s. Table 4-15 Electrical Idle Exit Ordered Set (EIEOS) for 32.0 GT/s Data Rate 18776 18777 Symbol Numbers 18778 18779 Value 18780 18781 Description 18782 17413 17414 18783 Figure 4-22 Electrical Idle Exit Ordered Set for 8.0 GT/s and Above Data Rates 18784 18785 0, 1, 2, 3, 8, 9, 10, 11 18786 18787 00h 18788 18789 18790 Symbol 0: EIEOS Identifier 18791 18792 18793 A low frequency pattern that alternates between thirty-two 0s and thirty-two 1s. 18794 18795 18796 18797 18798 Page 314 4, 5, 6, 7, 12, 13, 14, 15 /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 18798 4, 5, 6, 7, 12, 13, 14, 15 18799 18800 FFh 18801 18802 A low frequency pattern that alternates between thirty-two 0s and thirty-two 1s. 18803 18804 18805 18806 18807 18808 18809 18810 18811 18812 17415 18813 17416 18814 17417 17418 18815 The Electrical Idle Exit Ordered Set (EIEOS) is transmitted only when operating at speeds other than 2.5 GT/s. It is a low frequency pattern transmitted periodically to help ensure that receiver Electrical Idle exit circuitry can detect an exit from Electrical Idle. When using 128b/130b encoding, it is also used for Block Alignment as described in Section 4.2.2.2.1 Block Alignment . 17419 18816 The Electrical Idle Exit Ordered Set (EIEOS) is transmitted only when operating at speeds other than 2.5 GT/s. It is a low frequency pattern transmitted periodically to help ensure that receiver Electrical Idle exit circuitry can detect an exit from Electrical Idle. When using 128b/130b encoding, it is also used for Block Alignment as described in Section 4.2.2.2.1 Block Alignment . 18817 17420 17421 Figure 4-25 Electrical Idle Exit Ordered Set for 8.0 GT/s and Above Data Rates (EIEOS) 18818 When using 8b/10b encoding and operating at 5.0 GT/s, an EIEOS, as defined in Table 4-9 Electrical Idle Exit Ordered Set (EIEOS) for 5.0 GT/s Data Rate , is transmitted in the following situations: 18819 An Electrical Idle Exit Ordered Set Sequence (EIEOSQ) comprises of two consecutive EIEOS for data rates of 32.0 GT/s and above and one EIEOS for 5.0 GT/s, 8.0 GT/s, and 16.0 GT/s. The two EIEOS at 32.0 GT/s must be back to back and uniterrupted in order to be considered consecutive and form an EIEOSQ. Irrespective of the length of the EIEOSQ, block alignment still occurs on an EIEOS. 18820 18821 18822 17422 17423 17424 17425 17426 17427 When using 8b/10b encoding and operating at 5.0 GT/s, an EIEOSQ, as defined in Table 4-12 Electrical Idle Exit Ordered Set (EIEOS) for 5.0 GT/s Data Rate , is transmitted in the following situations: 18823 Before the first TS1 Ordered Set after entering the LTSSM Configuration.Linkwidth.Start state. Before the first TS1 Ordered Set after entering the LTSSM Recovery.RcvrLock state. After every 32 TS1 or TS2 Ordered Sets are transmitted in the LTSSM Configuration.Linkwidth.Start, Recovery.RcvrLock, and Recovery.RcvrCfg states. The TS1/TS2 count is set to 0 when: An EIEOS is transmitted. The first TS2 Ordered Set is received while in the LTSSM Recovery.RcvrCfg state. 17428 Page 315 18824 18825 18826 18827 18828 18829 Before the first TS1 Ordered Set after entering the LTSSM Configuration.Linkwidth.Start state. Before the first TS1 Ordered Set after entering the LTSSM Recovery.RcvrLock state. After every 32 TS1 or TS2 Ordered Sets are transmitted in the LTSSM Configuration.Linkwidth.Start, Recovery.RcvrLock, and Recovery.RcvrCfg states. The TS1/TS2 count is set to 0 when: An EIEOS is transmitted. The first TS2 Ordered Set is received while in the LTSSM Recovery.RcvrCfg state. /private/tmp/PCISIG/pcie4_combined-snapshot.html vs. /private/tmp/PCISIG/NCB-PCI_Express_Base_5.0r1.0-2019-05-22.html 17428 18829 17429 18830 17430 17431 18831 When using 128b/130b encoding, an EIEOS, as defined in Table 4-10 Electrical Idle Exit Ordered Set (EIEOS) for 8.0 GT/s Data Rates and Figure 4-22 Electrical Idle Exit Ordered Set for 8.0 GT/s and Above Data Rates , is transmitted in the following situations: 17432 17433 17434 17435 17436 17437 17438 17439 17440 17441 17444 18835 18836 18837 18838 18839 18840 18841 18842 Before the first TS1 Ordered Set after entering the LTSSM Configuration.Linkwidth.Start substate. Before the first TS1 Ordered Set after entering the LTSSM Recovery.RcvrLock substate. Immediately following an EDS Framing Token when ending a Data Stream and not transmitting an EIOS and not entering the LTSSM Recovery.RcvrLock substate. After every 32 TS1 or TS2 Ordered Sets are transmitted in all LTSSM states which require transmission of TS1 or TS2 Ordered Sets. The TS1/TS2 count is set to 0 when: An EIEOS is transmitted. The first TS2 Ordered Set is received while in the LTSSM Recovery.RcvrCfg state. The first TS2 Ordered Set is received while in the LTSSM Configuration.Complete state. A Downstream Port is in Phase 2 of the LTSSM Recovery.Equalization state and two consecutive TS1 Ordered Sets are received on any Lane with the Reset EIEOS Interval Count bit set. An Upstream Port is in Phase 3 of the LTSSM Recovery.Equalization state and two consecutive TS1 Ordered Sets are received on any Lane with the Reset EIEOS Interval Count bit set. 18844 18845 After every 65,536 TS1 Ordered Sets are transmitted in the LTSSM Recovery.Equalization state if the Reset EIEOS Interval Count bit has prevented it from being transmitted for that interval. Implementations are permitted to satisfy this requirement by transmitting an EIEOSQ within two TS1 Ordered Sets of when the scrambling LFSR matches its seed value. As part of an FTS Ordered Set, Compliance Pattern, or Modified Compliance pattern as described in the relevant sections. 18846 17446 Page 18834 18843 After every 65,536 TS1 Ordered Sets are transmitted in the LTSSM Recovery.Equalization state if the Reset EIEOS Interval Count bit has prevented it from being transmitted for that interval. Implementations are permitted to satisfy this requirement by transmitting an EIEOS within two TS1 Ordered Sets of when the scrambling LFSR matches its seed value. As part of an FTS Ordered Set, Compliance Pattern, or Modified Compliance pattern as described in the relevant sections. 17445 17447 When using 128b/130b encoding, an EIEOSQ, as defined in Table 4-13 Electrical Idle Exit Ordered Set (EIEOS) for 8.0 GT/s Data Rates through Table 4-15 Electrical Idle Exit Ordered Set (EIEOS) for 32.0 GT/s Data Rate and Figure 4-25 Electrical Idle Exit Ordered Set for 8.0 GT/s and Above Data Rates (EIEOS) , is transmitted in the following situations: 18833 Before the first TS1 Ordered Set after entering the LTSSM Configuration.Linkwidth.Start substate. Before the first TS1 Ordered Set after entering the LTSSM Recovery.RcvrLock substate. Immediately following an EDS Framing Token when ending a Data Stream and not transmitting an EIOS and not entering the LTSSM Recovery.RcvrLock substate. After every 32 TS1 or TS2 Ordered Sets are transmitted in all LTSSM states which require transmission of TS1 or TS2 Ordered Sets. The TS1/TS2 count is set to 0 when: An EIEOS is transmitted. The first TS2 Ordered Set is received while in the LTSSM Recovery.RcvrCfg state. The first TS2 Ordered Set is received while in the LTSSM Configuration.Complete state. A Downstream Port is in Phase 2 of the LTSSM Recovery.Equalization state and two consecutive TS1 Ordered Sets are received on any Lane with the Reset EIEOS Interval Count bit set. An Upstream Port is in Phase 3 of the LTSSM Recovery.Equalization state and two consecutive TS1 Ordered Sets are received on any Lane with the Reset EIEOS Interval Count bit set. 17442 17443 18832 18847 Example: An LTSSM enters Recovery.RcvrLock from L0 in 5.0 GT/s data rate. It transmits an EIEOS followed by TS1 Ordered Sets. It transmits 32 TS1 Ordered Sets following which it transmits the second EIEOS. Subsequently it sends two more TS1 Ordered Sets and enters Recovery.RcvrCfg where it transmits the third EIEOS after transmitting 30 TS2 Ordered Sets. It transmits 31 more TS2 Ordered Sets (after the first 30 TS2 Ordered Sets) in Recovery.RcvrCfg when it receives a TS2 Ordered Set. Since it receives its first TS2 Ordered Set, it will reset its EIEOS interval count to 0 and keep transmitting another 16 TS2 Ordered Sets before transitioning to Recovery.Idle. Thus, it did not send an EIEOS in the midst of the last 47 TS2 Ordered Sets since the EIEOS interval count 316 got reset to 0b. From Recovery.Idle, the LTSSM transitions to Configuration.Linkwidth.Start and transmits an EIEOS after which it starts transmitting the TS1 Ordered Sets. 18848 Example: An LTSSM enters Recovery.RcvrLock from L0 in 5.0 GT/s data rate. It transmits an EIEOS followed by TS1 Ordered Sets. It transmits 32 TS1 Ordered Sets following which it transmits the second EIEOS. Subsequently it sends two more TS1 Ordered Sets and enters Recovery.RcvrCfg where it transmits the third EIEOS after transmitting 30 TS2 Ordered Sets. It transmits 31 more TS2 Ordered Sets (after the first 30 TS2 Ordered Sets) in Recovery.RcvrCfg when it receives a TS2 Ordered Set. Since it receives its first TS2 Ordered Set, it will reset its EIEOS interval count to 0 and keep transmitting another 16 TS2 Ordered Sets before transitioning to Recovery.Idle. Thus, it did not send an EIEOS in the midst

CB-PCI Express Base 5.0r1.0-2019-05-22

Related documents

Products

Support

CB-PCI Express Base 5.0r1.0-2019-05-22

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib