Spec

Specifications and Tasks

  • Level of abststraction: PV (Programmer's View)
  • Extensible to model PCI-like buses (e.g. subset of PCIe).
  • Transaction container
      • Transaction Layer implementation (Section 2.1 PCI Express spec), including:
          • Transaction types
            • Memory
            • I/O
            • Configuration
            • Message
          • Addressing
            • Short address format
            • Long address format
  • Router
      • ID-based routing (configuration and message requests)
      • Address-based routing (I/O and memory requests: note, need separate memory spaces!)
  • User API (PV) (Requestor, Completer)
      • API for sending (memory, I/O, interrupts, messages)
      • Define interfaces
        • Boilerplate code for common PCIe tasks
        • C++ interfaces for target implementation (i.e., receiving) of Configuration, Message, Memory, and I/O transactions

Special Transaction Container

Extends Transaction Container with quarks concerning to the fields of the PCIe packets:

Transaction Layer Packets need the following quarks. The data types are fast datatypes (unsigned int (gs_unit32) and bool) where possible.

See table in document TableFields.doc.

Notes
Fields Length, LastDWByteEnable, FirstDWByteEnable: PCIe does use DW (4 byte) submission and gives the opportunity to disable bytes in the first and last datawords. We send data byte wise so we do not need byte enable fields.

Field Requester ID (Bus and Device Number) is not mapped to a Quark because the MID may be used to route back transactions.

Phases for PCIe fields

For PV we need no phases because of blocking calls.

PCIe Command Types

Types for command enum (for quark mPCIeCmd): MRd, IORd, CfgRd0, CfgRd1, IOWr, CfgWr0, CfgWr1, MWr, Msg, MsgD, MRdLk

Communication flow ReadOrWriteWithCompletion

Type field (reads): MRd, IORd, CfgRd0, CfgRd1
(each with Completion and CompletionError)

Type field (writes): IOWr, CfgWr0, CfgWr1
(each with Completion and CompletionError)

Communication flow SimpleWrite Type field: MWr
(without Completion)

Communication flow Message Type field: Msg, MsgD
(without Completion)

Communication flow Locked Type field: MRdLk
(with Completion and CompletionError)

Addressing and Lengths

PCIe submits the byte addressing addresses without LSBs (a 32/64 bit address is submitted with only 30/62 bits). So only DWs can be addressed and are submitted in 4 byte pieces. The valid bytes are set with LastDWByteEnable and FirstDWByteEnable.

We transfer bytes, not DWs so we do not need Byte Enables and can address byte-aligned. The User API has to calculate the correct address and length.

Problem: under special conditions there may be non-contiguous Byte Enables. TODO: For these cases we could submit the two xDWByteEnable-fields to submit this information to the receiving API which may present the data in the original way to the receiver device.

Routing, Addressing

Both ways of addressing are done with the field mAddr. If the field has to be interpreted as ID for ID based routing the field mIsIDbasedRouting is true.
Alternative: process mPCIeCmdand mMessageType if Msg and conclude the addressing type (huge switch case in each router!)

ID based routing:

 ID based routing is used for
 all Completions and for Configuration Requests: <br>

 We need no routing for completions because they are transactions which automatically return to the initiator.

 We need ID based routing for the types
    • CfgRd0, CfgRd1, CfgWr0, CfgWr1.
    • optionally Vendor_Defined Messages

Address based routing:

 Address based routing is used for Memory and I/O Requests:
  • MRd, MWr, IORd, IOWr, MRdLk: phase Request

Restrictions in our PCI Express model

We do
  • no timing

At this first approach we do

  • no ordering (see field AttributeRelaxedOrdering)
  • no ECRC (in initiator, target, routers): Not needed for error detection in the local simulation. Maybe later for poisoning (error simulation).
  • no poisoning (see field 'ECRC poisoned' (EP))
  • no different behavior of different traffic classes (since we have anyway no time modeled)
  • no change of IDs during runtime (see p.63)
  • no Completion Timeout Mechanism (2.8, p.129) (add later in API)
  • no Flow Control (TL with DLL) between components.

Open questions:

  • Do we need Virtual Channels in the beginning? No, they are optional anyway (p. 106) and irrelevant at PV.
  • Link Status (2.9, p.130): non-DL_up to DL_up: send Set_Slot_Power_limit Message needed?
  • Do we need PCIe Error Reporting (with setting error bits at function's registers and with Error Collection in the Root Complex) or is it sufficient to print out errors at the terminal?

Configuration Mechanism

PCI Express provides a configuration mechanism which allows reading and writing registers in the PCIe functions (in the devices). The first (low-level) API could support access to these function's configuration space memory mapped without semantic information. A second (high-level) API which is attached to the first one may then present convenience methods access these registers.

The configuration tags which affect communication have to be treated separately: the low-level API has to read out these registers and behave like they are set:

  • Extended Tag Field Supported (p. 446) (1 bit) This tag sets if the device is able to handle 32 (=0b) or 256 (=1b) outstanding requests.
  • Error Reporting capabilities?? (pp. 448ff.)
  • Completion Timeout Value of Device Control 2 register (2.8/p.129 and 7.8.16)
  • Virtual Channels? (see p. 106)

ARE THERE ANY MORE?

In the first version the user has to care that the generated transactions match the stored tags. E.g.:

  • Max_Read_Request_Size (p. 453)
  • Device Status Register (p. 455) for Errors (and p. 495-509)

Posted January 8th, 2008 by MarkBurton