User Profile
Wincent_Altera
Regular ContributorJoined 5 years ago
User Widgets
Contributions
Re: AXE5-Falcon using the J8/J9 MIPI connectors?
Good questions — let me address both parts separately. MIPI Reference Design for AXE5-Falcon J8/J9 The available documentation doesn't include a dedicated MIPI reference design specifically for the AXE5-Falcon board's J8/J9 MIPI connectors. Worth noting: in the context of the Agilex 5 E-Series 065B Premium Development Kit, J8 is documented as an HSIO bank SMA connector for 1PPS_OUT2 (or LVDS_SMA_TXP) Agilex™ 5 FPGA E-Series 065B Premium Development Kit User Guide and J9 is an HVIO bank IO header (10-pins) Agilex™ 5 FPGA E-Series 065B Premium Development Kit User Guide — so the connector assignments in the available user guide material are specific to the Premium Dev Kit, not the AXE5-Falcon form factor. I'd point you to Altera's Example Design Hub (referenced in the kit product briefs) as the best place to check for published MIPI design examples. RZQ_GROUP Error with B2A Differential Ref Clock / DP58 (RZQ_B_2A) The root cause here is a pin-function conflict. The RZQ pin (in your case DP58/RZQ_B_2A) is a dedicated OCT calibration reference pin for its I/O bank. Quartus enforces an RZQ_GROUP rule that prevents this pin from being assigned to any other function — including use as a differential reference clock input — because doing so would break the OCT calibration for the entire bank group. You essentially cannot use RZQ_B_2A as your B2A differential reference clock pin. For the GTS transceiver reference clock, there are two types of clock lines in the reference clock network — local and regional — and for every GTS transceiver bank there are two independent differential reference clock input pins. Reference Clock Network You need to assign your reference clock to one of those dedicated differential refclk pins in the GTS transceiver bank, not to the RZQ pin. Additionally, on the same side as the GTS transceiver bank there is an HVIO bank, and there are single-ended input reference clock pins in that HVIO bank that can be used by the system PLL as a secondary option for the reference clock input source. Reference Clock Network The fix is to re-assign your differential reference clock to a proper local or regional refclk pin for the GTS bank, or one of the dedicated HVIO SYSPLLREFCLK pins, and leave DP58/RZQ_B_2A unassigned (or assigned only to OCT). Check the Agilex 5 device pin-out files to identify the correct refclk-capable pin in the B2A bank area.33Views1like0CommentsRe: R-TILE PIPE DIRECT MODE SIMULATION PHY STATUS ISSUE IN RESET RELEASE SEQUENCE
Hi pradeep_12 , The guide shows txdetectrx_i being asserted while the lane is in P1 and the transmitter is electrically idle; it must not simply be held at an arbitrary level after PCS reset. Your waveform appears to leave the lane in P1 and does not show the complete detect-command/deassertion sequence. Main issues visible in your waveform powerdown_i appears to remain at 2'b10/P1. You must transition it to P0 after receiver detection. txelecidle_i is not shown. Drive it to 4'hF during P1 receiver detection. Do not assert rxstandby_i during bring-up; that requests RX standby and prevents normal receiver activity. The PHY reports standby through rxstandbystatus_o. txdetectrx_i should be treated as a receiver-detect command and then returned inactive after the phystatus/rxstatus response. Use a sticky debug latch for phystatus, because a one-cycle pulse can easily be missed in a wide Questasim waveform view After the receiver-detect pulse, you will only see cdrlockstatus_o, cdrlock2data_o, RX clock, and reset_status_n_o become active if the simulation includes a valid serial link partner or loopback data. Regards, Wincent_Altera22Views0likes0CommentsRe: PCIe Simulation using Quartus Pro 25.1.1
Hi amolkumar , From the fail scenario, I will assume that will be compatible problem between your simulator version --> Quartus version Since Quartus v26.1 working well , I would suggest you to go with v26.1 directly Regards, Wincent_Altera48Views0likes3CommentsRe: VVP Protocol Converter Not work
Hi JLee25 , Based on what you provided, most likely remaining cause is that the MM writes are not reaching the compiled Protocol Converter instance correctly— for example, wrong base address/offset, incorrect byte addressing, or an inactive control-interface clock/reset domain. Can you please check from there ? Regards, Wincent_Altera29Views0likes0CommentsRe: Agilex 7 R-Tile PIPE Direct endpoint receives Set_Slot_Power_Limit, but no Config TLPs
Hi Dexter22 , Some of your question, you may get the answer from PCI specification. But I can try my best understanding to help you answer, hope that can be a good reference point for you. 1. IF refer to PCI Express Base Specification Revision 6.2, Section 2.9.2, “Transaction Layer Behavior in DL_Up Status”. The guide mentioned : “When transitioning from a non-DL_Up status to a DL_Up status and the Auto Slot Power Limit Disable bit is Clear in the Slot Control Register, the Port must initiate the transmission of a Set_Slot_Power_Limit Message to the other component on the Link to convey the value programmed in the Slot Power Limit Scale and Slot Power Limit Value fields of the Slot Capabilities Register.” Hence I would said the spec ties this message to the DL_Up transition, not to completion of Configuration Reads, so seeing Set_Slot_Power_Limit before the first CfgRd0 is normal. 2. IF refer to PCI Express Base Specification Rev. 4.0 Version 1.0, Section 2.2.8, “Message Request Rules”. “Message Requests are posted and do not require Completion.” “The component on the other side of the Link (with Endpoint, Switch, or Bridge Functions) that receives Set_Slot_Power_Limit Message must copy the values in the data payload into the Device Capabilities register associated with the component's Upstream Port.” So your endpoint should not send Cpl/CplD for this message. The required behavior is normal DLL reliability handling plus, functionally, capturing the payload into the appropriate slot-power-limit fields if your implementation exposes that capability behavior. 3. I never try such customization before, but ideally it shall be yes , because PCIe DLL reliability depends on valid ACK/NAK, sequence tracking, replay buffering, and timeout/replay behavior; if ACKs are unusable, forward progress can stall and link recovery behavior can follow. 4. If refer to R-Tile Avalon® Streaming Intel® FPGA IP for PCI Express User Guide, Section 2.4, “PIPE Direct Mode”. “When implementing a Soft IP Controller using the R-tile IP for PCI Express in PIPE Direct mode, the FPGA device must be fully configured in order to start the link training sequence since the Controller is in the FPGA fabric” “The soft IP controller must release the per-lane lnX_pipe_direct_pld_pcs_rst_n_i signal out of reset after the per-lane lnX_pipe_direct_tx_transfer_en_o signal is asserted.” “There is only one PERST# pin ( pin_perst_n) on the R-tile. Therefore, toggling pin_perst_n will affect the entire R-tile. This pin also resets the EMIB interface.” 5. Since you already capture LTSSM, DLL, replay, LCRC, and raw PIPE data, the most useful additional captures are the tx_transfer_en_o to lane-reset relationship, unused-lane powerdown_i handling, and PERST# / EMIB / refclk sequencing, because those are the guide-called-out controls most likely to block clean bring-up before Config traffic ever becomes stable. 6. based on my understanding , due to PCIe flow control is separate by traffic type and separate for header/data, so a bad Completion-credit advertisement can block progress even though the InitFC1/2 exchange itself finished. But that is just my assumption based on my own experience, please treat that as reference purpose. 7. You may refer to below chart, those are proven sequence of Pin Perst , timing of other signal to be work well for PIPE direct mode https://docs.altera.com/r/docs/683501/26.1/r-tile-avalon-streaming-ip-for-pci-express-user-guide/pipe-direct-reset-sequence https://docs.altera.com/r/docs/683501/26.1/r-tile-avalon-streaming-ip-for-pci-express-user-guide/pipe-direct-speed-change Regards, Wincent_Altera1View0likes0CommentsRe: Cyclone IV GX PCIe Hard IP behaves differently on Intel Core I7 vs Xeon root complexes
Hi SharmaUmesh278 , Thanks for your response, you are most welcome, do file a new thread whenever you need any help. We will be there for you. Looking forward to see you again in the future. Regards, Wincent_Altera25Views0likes0Comments