User Profile
VenT_Altera
Frequent ContributorJoined 4 years ago
User Widgets
Contributions
Re: Can an Application Ignore PCIe flow Control Credits?
Hi corestar, Thank you for your feedback and suggestion to improve the user guide for better clarity and readability. I appreciate you taking the time to share your suggestion. I will relay your suggestion to the internal team for their consideration and review in future documentation updates. Thanks. Best Regards, Ven3Views0likes0CommentsRe: Can an Application Ignore PCIe flow Control Credits?
Hi corestar, As there are no further inquiries, I will transition this thread to community support. If you have a new question, feel free to open a new thread to get support from Altera experts. Have a great day! Thanks. Best Regards, Ven2Views0likes0CommentsRe: How to handle tx_st_ready for Cyclone V PCIe
Hi corestar, As there are no further inquiries, I will transition this thread to community support. If you have a new question, feel free to open a new thread to get support from Altera experts. Have a great day! Thanks. Best Regards, Ven5Views0likes0CommentsRe: Can an Application Ignore PCIe flow Control Credits?
Hi corestar, My apologies on the delayed response. Yes, the flow control signal (tx_cred_*) can be ignored and honoring tx_st_ready is sufficient. The Hard IP performs the mandatory PCIe credit check on every TLP internally; if credits are short it blocks the TLP (and all following ones) and expresses that back-pressure solely by deasserting tx_st_ready. The flow control signals are needed to track credits to optimize the throughput, which is optional. Regarding the credit limits, the Avalon-ST TX datapath does expose them. The six credit limit signals tx_cred_hdrfcp/datafcp, tx_cred_hdrfcnp/datafcnp, tx_cred_hdrfccp/datafccp carry the current per-type credit limits; the tx_cred_fchipcons strobes each credit the Hard IP consumes; and tx_cred_fc_infinite flags infinite types. Thanks. Best Regards, Ven7Views0likes0CommentsRe: How to handle tx_st_ready for Cyclone V PCIe
Hi corestar, Thank you for the updates, and I apologize for the delayed response. Yes, the tx_st_valid should reassert within 2 cycles after the tx_st_ready goes high again, assuming a readyLatency of 2 cycles. Thanks. Best Regards, Ven Ting4Views0likes0CommentsRe: PCIe Root Complex on DK-A5E013BM16AEA
Hi hmitani, I am glad to hear that the information was helpful and helped you get started. I will transition this thread to community support. If you have a new question, feel free to open a new thread to get support from Altera experts. Have a great day! Thanks. Best Regards, Ven9Views1like0CommentsRe: PCIe Root Complex on DK-A5E013BM16AEA
Hi hmitani, Thank you for your questions. Let me address a couple of points first, then walk through the implementation path. Quick correction on the CPU core: The Agilex 5 HPS does not contain a Cortex-A78. The Agilex 5 HPS features a dual-core Arm Cortex-A76 and dual-core Arm Cortex-A55 processor. Your architecture is correct. J14’s PCIe x1 goes to the FPGA GTS (bank 1A, lane 0). Path: configure the PCIe Hard IP as Root Port in the fabric, then use LWH2F/H2F for control/enumeration and F2H and/or F2SDRAM for data-plane DMA into memory. Key implementation points: PCIe Hard IP: Use GTS AXI Streaming IP for PCI Express, the supported interface is PCIe Gen3 x1 on this Dev Kit. System PLL required: Connect a System PLL IP to the PCIe Hard IP for the fabric/application clock. Root Port stack: Use GTS AXI Streaming IP for PCI Express in Root Port mode, paired with GTS AXI Multichannel DMA IP (Configuration Slave, BAM, BAS). That is the documented HPS Root Port host stack. HPS bridges LWH2F / H2F — HPS → fabric for CSR access and control/enumeration (and downstream MMIO via MCDMA BAS). F2H (+ ACE5-Lite CCT) — fabric → HPS/DDR for endpoint DMA (non-coherent or IO-coherent). F2SDRAM — optional high-bandwidth non-coherent path straight to SDRAM Recommended starting point: 013B GSRD/GHRD (HPS and board baseline): https://github.com/altera-fpga/agilex5e-ed-gsrd Agilex 5 E-Series 065B HPS PCIe Root Port system example (architecture, memory map, Linux flow to port): https://altera-fpga.github.io/rel-26.1/embedded-designs/agilex-5/e-series/modular-065b/pcie-rp/ug-pcie_rp-agx5e-modular-065b/, https://github.com/altera-fpga/agilex5-ed-pcie-rp GTS AXI Streaming IP for PCI Express User Guide: https://docs.altera.com/r/docs/813754/current GTS AXI Multichannel DMA IP for PCI Express User Guide: https://docs.altera.com/r/docs/847470/current Hard Processor System Component Reference Manual: Agilex 5 SoCs: https://docs.altera.com/r/docs/813752/current Thanks. Best Regards. Ven5Views1like0CommentsRe: DisplayPort Sink (Quartus 18.1) – horizontal pixel offset.
Hi vilem, My apologies for the delayed reply, and thanks for the update — the CRC reset restoring alignment is a very useful finding. Regarding a newer CRC on Quartus 18.1, the Clock Recovery Core is delivered with the design example for that Quartus release and is not supported as a standalone upgrade from a newer Quartus into 18.1. As a runtime workaround, automating the CRC reset you already validated (when the alignment is wrong). I have the following questions to clarify: What is the device family/OPN, link rate and lane count set? When the image is shifted, do MSA values (HSTART, HTOTAL, HWIDTH) stay the same, or do they change? Also, do msa_lock / rx_vid_locked / BER counters glitch at that moment? While the image is shifted, does the DP Sink still declare video lock (rx_vid_locked asserted)? On the extender: try a lower negotiated link rate or fewer lanes, check the firmware, since the failure only appears with the extender. Thanks. Best Regards, Ven14Views0likes1Comment