Recent Discussions
Arria 10 DDR4 IP - Using Hyperlynx DDRx Batch Wizard With Failed Simulation Results
Hello, Device: 10AX066K2F40E1HG We are designing a DDR4 LRDIMM interface for the above device using the EMIF IP. We have a board layout, and we are attempting to complete simulation to verify the PCB. We have been using this guide for simulation: https://community.intel.com/t5/FPGA-Wiki/Arria-10-EMIF-Simulation-Guidance/ta-p/735201 Under the "System-level timing closure" heading, we see the following statement: "Note: Please do not use any simulation tool to perform system-level timing closure. Use simulation software to obtain channel loss and board skew data. Quartus will close the system level timing for you once you have entered accurate Memory Timing and Board timing information in the IP." We are using Hyperlynx to extract the channel loss/crosstalk values used for the Quartus IP parameters. Our issue is that some of the nets (BA0, ODT0 specifically), are failing timing in the Hyperlynx DDRx batch wizard. Due to these failures which I have chosen to ignore following the above quote, the Channel Loss Calculation Tool from the Simulation Guidance is failing (I have already worked with Mentor Graphics on this, we are certain that the failing nets (ODT, BA0) are causing the excel channel loss tool to fail). If we delete the failing net rows from the DDRx Wizard results, then the channel loss tool completes. My question is: Should I be ignoring the timing failures from Hyperlynx, relying on the Arria 10 IP to close the timing? If so, how do I properly pass the DDRx batch results through the calculation tool such that I get good results? Note: The example data given with the calculation tool have no failing nets, indicating that all nets passed the Hyperlynx DDRx Wizard at the time they were produced. Attached is the DDR report from the Hyperlynx Batch Wizard. Inside there is a .exe file which will open an explorer for the simulation results. The failed lines can be seen on the address tab.
GTS JESD204C IP Evaluation Mode not working
Using Quartus Pro 25.3 I can't generate time limited sof for GTS JESD204C. I have reviewed Licensing 'know-How' Guild. I found and corrected an issue with the LM_LICENSE_FILE variable. I have verified that IP Evaluation Mode is enabled within Quartus. I'm working with the GTS JESD204C Example Design generated with Platform Designer selecting the "Agilex 5 E-Series 065b Premium Development Kit". I'm also using the GTS JESD204C IP Design Example User Guild. When I compile the design I get Message ID 23714 "Can not generate programming files", 115005 "Unlicensed IP: JESD204C (6AF7 0146)", and 115004 "Unlicensed encrypted design file". At this time, I'm only interested in evaluating the GTS JESD204C IP. Does this IP support evaluation mode? If so, any suggestions as to why Quartus Pro will not generate time-limited sof files?
About the System PLL in Agilex 5
Regarding the System PLL in Agilex 5, the reference clock input can be supplied not only from the dedicated transceiver input pins but also from HVIO pins. However, when assigning the pins, the following Critical Warning occurs. Critical Warning(24190): User has specified a QSF location assignment to drive XPIN_GTS_CLK[0] using PIN_BK19. The PIN_BK19 is on HVIO bank and is not optimal for HSSI PLL refclk usage. Try to use the HSSI native local/global refclk IO instead. Additionally, this HVIO location assignment could cause the Reset Sequencer to be placed into a invalid shoreline. To avoid this, besides the PLL refclk, you must also specify location assignment for the UX native refclk. Is the operation acceptable, and what are the jitter characteristics? Also, are there specific ways to address the Critical Warning?
Stratix 10 fPLL is cascade source mode doesn't lock
Hello everyone. I use fPLL cascading with Stratix 10 FPGA: fPLL in cascade source mode is connected to fPLL in transceiver mode. In my design reference clock for fPLL in cascade source mode is not stable after power-up and I apply user recalibration to it. But after user recalibration when reference clock is stable, fPLL doesn't set lock signal. After some investigation of the issue, I found that my design works fine with Quartus Pro 21.2 but doesn't work with newer versions like Quartus Pro 23.4/25.1/26.1. Is there any known issue about fPLL is cascade source mode? Any suggestions about how to overcome this issue are welcomed.Cascaded Avalon Stream Multiplexer in Platform Design does not forward valid data packets
Hello community, I have a DSP system with 32 independent 256-bit output channels using Avalon-ST (or AXI-Stream) on an AGX FPGA. To transfer packetized data to the HPS, I implemented a cascaded Avalon Streaming Multiplexer architecture. The 32 channels are divided into two groups of 16. Each group connects to a 16-to-1 Avalon-ST Multiplexer IP. The outputs of these two multiplexers are then connected to a final 2-to-1 Avalon-ST Multiplexer IP, forming an overall 32-to-1 mux structure. At the output of the final 2-to-1 mux, I also added another 2-to-1 Avalon-ST mux with a selectable input for a data packet emulator. Using the emulator path, I verified that the FPGA-to-HPS data path is functioning correctly. However, after switching from the emulator path to the DSP output path, I only receive packets from channel 0. No packets from the other DSP channels are observed by the HPS. For debugging, I intentionally generated valid packets on non-zero channels. In SignalTap, I observed that channel 28 was asserting valid packet data (valid = 1) while ready = 0. This capture was taken at the input of the second 16-to-1 mux, since channel 28 belongs to the upper 16-channel group. Next, I changed the SignalTap trigger condition to the rising edge of the output valid signal of the second 16-to-1 mux. However, the trigger condition was never met, even after repeated acquisitions. The ready signals throughout the mux stages remain asserted, which suggests there is no downstream backpressure from the FIFO path to HPS. The downstream FIFO status also indicates that it is empty. The confusing part is the following: After enabling channel 0 again, both channel 0 and channel 28 should have had valid packets simultaneously. In this case, packets from channel 0 were forwarded correctly to the HPS. I verified this by reading 8 words from the memory FIFO and reconstructing the original packet; all received packets contained the channel ID corresponding to channel 0. However, after disabling channel 0 again, no new packets were received from any channel, including channel 28. Based on these observations, it appears that the internal round-robin scheduler of the Avalon-ST mux may not be operating correctly. The two 16-to-1 muxes and the final 2-to-1 mux are all configured identically in Platform Designer. Does anyone have suggestions on what could cause this issue, or recommendations on how to further debug the Avalon-ST mux behavior? I noticed an interesting behavior on channel 28 related to the Avalon-ST handshake. The ready signal for channel 28 remains asserted during idle cycles, but it becomes deasserted exactly when valid is asserted. In other words: | Cycle | valid | ready | | ---------- | ----- | ----- | | Idle | 0 | 1 | | Data cycle | 1 | 0 | | Next cycle | 0 | 1 | This differs from channel 0, where both valid and ready are asserted simultaneously, forming a successful Avalon-ST handshake. My DSP source currently only pulses `valid` for one cycle when data is available. Could the Avalon-ST Multiplexer scheduling size setting (Scheduling Size = 2) contribute to this behavior? Specifically, can the mux arbitration latency caused by the scheduling configuration prevent non-zero channels from completing a handshake if valid is only asserted for one cycle? Thank you very much.
R_Tile PCIE
I am using Quartus 26.1 and Questa 2024.1 to simulate the PCIe IP example. The selected IP is R-Tile Avalon Streaming IP for PCI Express. The example design is generated in PIPE mode. I slightly modified the example driver to make the EP transmit 100 MWr TLPs with 128-byte payload each and 100 MRd TLPs with 128-byte payload each. Currently issues occur with the CplD responses from the RP. In the 100-packet test, 96 out of 100 CplD packets have correct payload data, while 4 packets show data mismatch. The faulty packets are not fully corrupted. Their first three payload beats are valid, yet the final 256-bit beat turns into all zeros. There is another issue. When modifying the EP to send MWr TLPs longer than 128 bytes to the RP in the example design, no CplD frames will be responded by the RP after transmitting subsequent MRd TLPs.
Why the Error Response Slave IP cannot work for Agilex 5 SOC FPGA?
I test the GHRD and corresponding linux image on Terasic DE25-Nano board， however, when I access the FPGA peripheral device, like SW, I use md.l 0x20010060 1 command in U-Boot console, it reports the register value; when I use md.l 0x2fffffff 1 (the H2F ummapped address) or md.l 0x4fffffff 1 (the LWH2F ummapped address), the system will hang up, report Please reset the board! then I added a Error Response Slave IP and tested, but it still report the same message, then, I need reboot my system every time. I set the IP as follows: after this, I added two Error Response Slave IPs in the system, one is for H2F, another is for LWH2F: Unfortunately, the problem still remains unsolved.
Agilex 7 F-Tile 200G hard IP de-feature clarification
There is a point in the Agilex 7 known issues list in UG-683584 for some silicon revisions The F-Tile Ethernet 200G Hard IP block is de-featured and cannot beused in production devices with OPNs that have no suffix (blank) or "B" suffix Does this mean that 200G "bonded" hard-IP is not supported in those older OPNs, such as 200GE-4 / 200GE-8 ? Or does it mean that all parts of 200G hard IP is de-featured? For example would FEC/PCS/MAC still work in 10/25/50GE-1 configurations?