User Profile
VenT_Altera
Frequent ContributorJoined 4 years ago
User Widgets
Contributions
Re: [PCIE_DESIGN_EXAMPLE][AGILEX7][QUARTUS25.3.0] - failed at elaboration process
Hi Frederic, Thank you for the update. The Questa Altera FE edition simulator is unlikely to be supported for simulation of the Data Mover Only - External Descriptor Controller Example Design) in future Quartus version. It is recommended to use the full version of QuestaSim to run the simulation, which is supported in Quartus Prime Pro Edition v25.3.0. When using the full version of QuestaSim, you may enable the PIPE option to accelerate the simulation. Additionally, the vsim-3008 and vsim-3043 errors you encountered previously with PIPE mode enabled can be resolved by switching to the full version of QuestaSim. Please note that you may also need to apply the suppress 2732/10000 workaround described in the KDB (https://community.altera.com/kb/knowledge-base/why-does-simulation-of-the-f-tile-multi-channel-dma-fpga-ip-for-pci-express-erro/338491) before proceeding with the simulation. Thanks. Best Regards, Ven1View0likes0CommentsRe: Agilex-7 AXI MCDMA for PCIe hang
Hi Mikhail_a, Could you please confirm the Design Example variant, user mode, application test, and the exact steps/commands you used to reproduce the error? This will help me to set up the same environment and replicate the error. It would also be helpful if you could provide the log that captures all the commands and their outputs. Thanks. Best Regards, Ven19Views0likes0CommentsRe: [PCIE_DESIGN_EXAMPLE][AGILEX7][QUARTUS25.3.0] - failed at elaboration process
Hi Frederic, Thanks for reaching out. The suppress 2732/10000 workaround you applied addresses a separate, known issue with the F-Tile Multi Channel DMA IP simulation in Quartus Prime Pro 25.3 when using Riviera Pro or Siemens Questa*: https://community.altera.com/kb/knowledge-base/why-does-simulation-of-the-f-tile-multi-channel-dma-fpga-ip-for-pci-express-erro/338491 The vsim-3008/vsim-3043 errors you are seeing are not targeted in this workaround. Could you please let me know if you are using F-Tile MCDMA IP, and which Questa FE simulator version? Additionally, could you disable the PIPE mode in your design example generation if your flow does not strictly require this mode? Note that, the Table 38. Supported Simulators for F-Tile MCDMA IP in https://docs.altera.com/r/docs/683517/25.3.1/multi-channel-dma-ip-for-pci-express-design-example-user-guide/supported-simulators MCDMA Design Example user guide confirms that the External Descriptor Controller Design Example (Data Mover Only mode) does not support Questa - Altera FPGA Edition and requires the full QuestaSIM instead. Please switch to the full QuestaSIM instead of Questa FE if you are using the F-Tile MCDMA IP. Thanks. Best Regards, Ven6Views0likes0CommentsRe: DisplayPort Sink (Quartus 18.1) – horizontal pixel offset.
Hi vilem, As there are no further questions, I will transition this thread to the community. If you have any new questions, please feel free to open a new thread and the Altera experts will be happy to assist. Thanks. Best Regards, Ven9Views0likes0CommentsRe: DisplayPort Sink (Quartus 18.1) – horizontal pixel offset.
Hi vilem, I would like to follow up regarding the update below. As there are currently no plans to backport the fix to Quartus versions earlier than v25.1, please let me know if you have any further questions or concerns regarding this issue. Thanks. Best Regards, Ven13Views0likes1CommentRe: DisplayPort Sink (Quartus 18.1) – horizontal pixel offset.
Hi vilem, Thank you for your updates. Unfortunately, there are no plans to backport this fix to Quartus versions earlier than v25.1. The fix was implemented starting from Quartus v25.1, and therefore an upgrade to Quartus v25.1 or a later release would be required to obtain the fix. Thank you for your understanding. Thanks. Best Regards, Ven23Views0likes2CommentsRe: DisplayPort Sink (Quartus 18.1) – horizontal pixel offset.
Hi vilem, I sincerely apologize for the delayed response. May I know which FPGA device family you are using (e.g., Arria 10, Cyclone V, etc.)? As a workaround, would it be possible to implement the auto-reset CRC on glitch? I understand that migrating your design from Quartus v18.1 to the latest Quartus v26.1.1 may not be feasible in your scenario. Based on your observations, I noticed that a new FIFO_ADDR_WIDTH parameter was added to the Clock Recovery Core in Quartus v25.1 (https://docs.altera.com/r/docs/683273/25.3/displayport-ip-user-guide/clock-recovery-core-parameters). If feasible, you may create a simplified test design and increase the FIFO_ADDR_WIDTH from its default value of 9 to 10 using Quartus v25.1. This increases the depth of the input FIFO in the Clock Recovery Core and help to accommodate higher-jitter input sources. Prior to Quartus v25.1, the FIFO was fixed to value of 9. Starting from Quartus v25.1, this parameter was exposed at the top level of the bitec_clkrec module, allowing users to increase the FIFO depth when dealing with higher-jitter input sources. Thanks. Best Regards, Ven12Views0likes4CommentsRe: 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, Ven22Views0likes0CommentsRe: 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, Ven8Views0likes0Comments