User Profile
CheepinC_altera
Joined 7 years ago
User Widgets
Contributions
Re: [Test] Agilex 7 F-Tile PCIe mode supports
Hi, Here's a summary of the PCIe modes and configurations supported by the Agilex 7 F-Tile: Supported PCIe Generations F-Tile supports configurations up to PCIe 4.0 x16, with PCIe Gen3 and Gen4 natively supported. Agilex 7 · PCIe Supported Interface Modes F-Tile supports Endpoint (EP), Root Port (RP), and Transaction Layer (TL) Bypass modes. Agilex 7 · PCIe Supported Link Width Configurations F-Tile supports up to one Gen4 x16, two Gen4 x8, or four Gen4 x4 PCIe hard IP configurations. Agilex 7 · Transceiver/PHY More specifically, the supported configurations are: 1x PCIe x16 — Root Port or Endpoint (upstream or downstream port) PCIe® Hard IP 2x PCIe x8 — Endpoint only (various upstream/downstream port combinations) PCIe® Hard IP 1x PCIe x8 — Root Port or Endpoint PCIe® Hard IP 4x PCIe x4 — Root Port only (upstream or downstream port) PCIe® Hard IP 2x PCIe x4 — Root Port or Endpoint PCIe® Hard IP 1x PCIe x4 — Root Port or Endpoint PCIe® Hard IP Port Bifurcation The PHY channel assignments per bifurcation mode are: 1x16: lanes 0–15 on port 0 2x8: lanes 0–7 on port 0, lanes 8–15 on port 1 4x4: lanes 0–3 on port 0, lanes 4–7 on port 2, lanes 8–11 on port 1, lanes 12–15 on port 3 PMA/PCS Additional Topology Notes (recent additions) A PCIe 1x4 configuration (Topology R) for Root Port mode was introduced in IP v12.1.0, allowing implementation of a PCIe 1x4 Root Port while unused F-Tile FGT channels can be used for Ethernet and other protocols. Agilex 7 · PCIe A PCIe 2x8 configuration (Topology S) for Root Port mode was introduced in IP v12.3.0. Agilex 7 · PCIe Independent refclk support for 2x4 Hard IP mode is also available, allowing connection to two discrete x4 PCIe endpoints where an independent refclk source is required. Agilex 7 · PCIe Hard IP Layers Two hard IP modes are supported: Full Hard IP (Transaction Layer, Data Link Layer, and PHY Layer all hardened) and TLP Bypass mode (Transaction Layer Lite + Data Link Layer + PHY Layer). PCIe® Hard IP0Views0likes0CommentsRe: [Test] Agilex 5 TX PLL sharing
Good question — let me clarify how TX PLL sharing works in the Agilex 5 GTS transceiver architecture, because the TX PLL and the System PLL play distinct roles here. TX PLL — No sharing needed (or possible) across channels In Agilex 5, each channel has its own TX PLL, and one system PLL is available per bank. Agilex 5 · Config/RSU Because of this per-channel TX PLL architecture, no TX PLL sharing is required across channels. If multiple channels use the same rate, each channel is driven by its own TX PLL sharing the same REFCLK source. Agilex 5 · Config/RSU So the concept of "sharing a TX PLL between PCIe and non-PCIe channels" doesn't apply — each channel independently owns its TX PLL. The real restriction is on the System PLL The constraint you need to watch is at the System PLL level, not the TX PLL level. Each GTS transceiver bank has one system PLL, which is the primary clock source for hard IP blocks (Ethernet MAC, PCS, FEC, and PCIe) and the core interface bridging the FPGA core and the GTS transceivers. Agilex 5 · Clock The critical rule: different interface protocols operating at different line rates can share a system PLL, except for PCIe. Agilex 5 · Clock This means if you need both PCIe and non-PCIe protocols in the same GTS transceiver bank, and both require a system PLL, you must use two system PLLs. Since there is only one system PLL in a GTS transceiver bank, a second or third system PLL can be used from the neighboring GTS transceiver banks. Agilex 5 · Clock A concrete example from the docs: if channels 0 and 1 in GTS transceiver bank 1A are configured for PCIe, and channels 2 and 3 are configured for Ethernet, then the system PLL in GTS transceiver bank 1A can be configured for PCIe, and the system PLL from GTS transceiver bank 1B can be configured for Ethernet. Running PCIe® and Non- PCIe® Protocols in a GTS Transceiver Bank Additional bonding rule If you are bonding multiple lanes to a single link, there is one more constraint: when bonded channels use a system PLL, they must all use the same system PLL. Agilex 5 · Transceiver/PHY PCIe reference clock timing There is also a timing requirement specific to PCIe: PCIe must have its system PLL's reference clock ready by the time of device configuration for PCIe link-up compliance. Agilex 5 · PCIe This is an exception to the general reference clock availability model. Summary TX PLL: one per channel, no sharing across channels — the question of PCIe vs. non-PCIe TX PLL sharing doesn't arise. System PLL: PCIe cannot share the system PLL with non-PCIe protocols. You must use a separate system PLL (borrowed from a neighboring bank) for the non-PCIe side. Bonded channels using a system PLL must all use the same system PLL.0Views0likes1CommentRe: Arria 10 Native PHY 66:64 RX wrong word with valid asserted
Hi, Thanks for your update. I took a closer look at the user guide for the case where the PCS/PMA width is configured as 66/64. In the RX direction, the soft gearbox repacks the 66-bit PCS blocks into 64-bit words toward the fabric. Because the two widths are unequal, the rates do not line up evenly: for every 32 input blocks (32 × 66 = 2112 bits), the gearbox produces 33 output words (33 × 64 = 2112 bits). As a result, one out of every 33 output cycles carries no valid data — which in your case, you would need the fabric logic needs to accommodate. If you would prefer a continuous, non-backpressured stream, my understanding is that you can configure a matched (even) PCS/PMA width ratio so that no gap cycle is required. Please let me know if you have any further questions. Thank you.1View0likes0Comments