BrianSune_Froum
ContributorJoined 4 years ago
User Profile
Contributor
User Widgets
Contributions
Re: Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
CheepinC_altera No the PCIE hard IP cannot modify from user side it is a must on CMU PLL while this limits the use of fPLL placement on remains channels when >= 18.0 Quartus. The report from the your link only mentioned the TX wrong data and did not clearly mentioned it is on PCIe side or custom channels so this is a bit hard to understand if only CMU PLL is introducing possible issue on remains channel why fPLL would be blocked to use in the first place. Unless the CMU PLL introduce wrong data to hard PCIe as well. CheepinC_altera A table maybe clear up things more better: PCIe Hard PLL PCIe GEN PCIe xN Remain channels Remain PLL Remain xN Reconfig Quartus Result CMU 1 4 2 fPLL 2 Shared 17.1 Pass CMU 1 4 2 fPLL 2 Shared 18.1 Fit Error CMU 1 4 2 fPLL 2 Shared 20.1 Fit Error CheepinC_altera Meantime, the reconfiguration also successfully tested on our side with modification of Vod and Pre-emphasis first post-tap. Which these two are the most important in most use cases. The recfg shows no issue on register read return status. Functional-wise also show normal behavior on real hardware. CheepinC_altera - Waiting on your internal investigations result. So back to the original question, what actually the report really referring to? The CMU PLL creates wrong data along with CH1 / CH4? And why only PCIe x1 use case not x2 x4? So the report is referring to the channel NOT the PCIe itself but custom or other protocol use case on those remains channel. However fPLL is complete isolated with the CMU PLL generated clock both // & ser. so there are no possible correlation on wrong data latching between xN x1 x6 clock lanes. How could this even possible to restrict the use and fit for fPLL use cases? Make zero sense, unless the Mbps and MHz both fPLL and CMU PLL is the same or sub ordering that could introduce "harmonic spurious" or "high jitter" that violates the timing setup hold slacks. Cannot understand why >= 18.0 ban user to fit channel that is possible to use in first place. 😞😞😞 Thanks, BrianRe: Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
CheepinC_altera I am very confused. If there internal original discussion only related to CMU PLL case then why block and forbidden the fittering to place fPLL in the first place? This make no sense. For Quartus 17.1 I simply do a very basic placement on fPLL + hard PCIe like what you had done in 20.1 and no fittering issue. So I move onto real design project and simply roll back all IP via tcl script and regenerate necessary rbf and loaded via HPS. So real system shows no issue on both custom protocol and PCIe via NVMe testing see the log. However The PCIe RP itself is very slow which bandwidth can only achieve 400MB/s under x4 GEN 1. Either how it is still working properly under 17.1 via fPLL and shared reconfiguration as we both discussed in this long conversation. I had also enclosed the placement image that you can see the top fPLL is used along side the with big hard PCIe block. Thanks, BrianRe: Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
CheepinC_altera I have one unconfirmed information from: https://community.altera.com/kb/knowledge-base/why-does-the-transceiver-tx-simplex-sends-wrong-data-when-the-cmu-pll-of-pciex1-/342679 The wrong data is only affected by the CMU PLL or not affected when fPLL is used? This require your internal database info. Thanks CheepinC_altera I still need a confirmation on the CMU PLL wrong data situation it is only introduced via CMU PLL or both fPLL case? Yes 17.1 shows a huge different on fittering CH4 now can place and fit with the previous debug project. CheepinC_altera Final result rolling back the entire project from 18.1 or 20.1 to 17.1 and boot via HPS + RBF shows success result on custom protocol via f-PLL and 4 channel PCIe However due to the inherent bottlenecking the 4 channel performance is not great in the first place. I enclosed a log for reference.Re: Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
CheepinC_altera Need time on my side to under go this testing. Please hold onto this ticket. As for your reply do you mean it cannot override this error fail like the PCIe soft reset force setup via qsys or ip file change "xxx=True" ? ThanksRe: Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
CheepinC_altera According to the passage, if i use 17.0 or older version i can override this? If the custom protocol can error corrects or subject to wrong data it is still possible to use all channel while not under version 18.0 or above? Thanks, BrianRe: Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
CheepinC_altera Did not answer the question WHY? Hard IP require a full global clock route or any other major reason it is introducing such limitation. We all now know that it is restricted but WHY? Please do answer or give out the possible reasons!Re: Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
CheepinC_altera Just to check with you if you are observing a similar error on your side? From day ONE i am having this atrocious meaningless fail report. As I search into our internal database, this appears this restriction imposed by the PCIe Hard IP. Specifically, the TX channel within the same transceiver (XCVR) pair associated with a CMU PLL cannot be used. WHY? WHY PIPE vs hard placement have such huge different? A potential workaround would be using the PIPE PHY and interfacing it with a third-party PHY MAC/controller in the fabric to build a complete PCIe solution. I cannot see setting from the IP via soft core implementation like DPHY MEMORY IP etc. Thanks, Brian CheepinC_altera I am still holding onto the possible way to use hard PCIe under all channel placement. ThanksRe: Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
CheepinC_altera I remember I read handbook that mentioned the placement restriction when using PCIe hard core that must follow otherwise it will not fit. This include placement restriction. Meantime, PIPE had nothing to do with root port and endpoint different. And PIPE also did not mention any form of hard core PCIE placement or not. Possible the PIPE only work in soft PCIe Core not hard? It will be very hard to convince the original IDEA of full PCIe "HARD Core" placement with full remain channel placement possibility. The PHY it self only handle the lane speed and FIFO // to serial conversion and analog control. While a real PCIe Core placement if you compare do shows a very different fittering in the first place. If you open the Chip Planner you do see the full placement from your project: The green shaded shows no real usage to the channel. vs This placement is only able to place CH5 CH3 and CH2 on custom it will always success no issue. Pay very close attention to the right BIG brown box!!. And the Cyan placement. Thanks, Brian
