Contributor
Regular ContributorHi Brian,
Thank you for the update.
I checked the internal case associated with the KDB and did not find any references to the fPLL. Based on the available information, the internal discussions appear to focus exclusively on the CMU PLL.
Could you please share more details regarding your note with fPLL in previous response ie source of information? This would help me investigate further and clarify.
I look forward to your response.
ContributorI 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,
Brian
Regular ContributorHi Brian,
Thank you for the update.
If I understand your previous note correctly, you have tested the PCIe HIP design using the fPLL, and the design is able to pass Fitter and operate successfully on CV hardware. To ensure we are aligned, would you mind sharing the QAR for the test project? Having a look at the design will help me better understand the configuration and setup used in your test.
I believe the test design I previously provided was using the CMU PLL for the PCIe HIP, so it would be helpful to compare the two implementations.
Thank you, and I look forward to your response.
ContributorNo 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.
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 |
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,
Brian
