User Profile

hcom

Occasional Contributor

Joined 4 years ago

44 Posts5 Solutions

View All Badges

User Widgets

Contributions

Re: Broken links in documentation
@Ash_R_Intel It worked for a few days, now it's even more dead than before:
3 years ago Place Quartus® Prime
879Views
0likes
0Comments
Re: Sections missing from fPLL documentation
Thank you for pointing out this other document. It's strange that this information is distributed across so many different documents. Unfortunately, that document doesn't contain the missing sections I mentioned (or the equivalent information). But nonetheless, there's some useful information for me to read. I had tried using the "Resource and Documentation Center", but a search for "fPLL" doesn't show any useful results on at least the first 5 or so pages. A search for "Cyclone 10 GX fPLL" only shows the "Core Fabric Handbook" halfway through the 2nd page of results, so I don't think the search algorithm is very sophisticated.
3 years ago Place IP & Transceiver
884Views
0likes
0Comments
Sections missing from fPLL documentation
As far as I can tell, there is no dedicated documentation for fPLLs (e.g. in Cyclone 10 GX and Arria 10). Therefore, I am forced to use the limited scraps of information scattered around the Transceiver PHY user guides. The Cyclone 10 GX Transceiver PHY User Guide is especially lacking. Section 3.1.3 looks somewhat similar to that section in the Arria 10 Transceiver PHY User Guide, except sections 3.1.3.1 ("Instantiating the fPLL IP Core") and 3.1.3.2 ("fPLL IP Core") are mysteriously missing. Should I assume the Arria 10 sections apply also to Cyclone 10 GX? This seems like an altogether unsafe assumption, as there are many subtle differences between the two device families. Needless to say, I am absolutely shocked by the state of the Intel FPGA documentation in general. It is an absolute mess. I have wasted many days of effort as a direct result of Intel's disorganized and incomplete documentation.
3 years ago Place IP & Transceiver
915Views
0likes
3Comments
Broken links in documentation
I very regularly see this error page when I click links in Quartus / Intel FPGA articles and documents: Usually, if I search for long enough, I can eventually find the missing document somewhere in a dark corner of the internet. However, the only version of this spreadsheet that I can find (cached by google) doesn't seem to be correct: https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-10/arria_10_cyclone_10gx_pre_emphasis_and_output_swing_settings.xlsx This spreadsheet is linked for example, from this article: https://www.intel.com/content/www/us/en/support/programmable/articles/000077353.html?wapkw=Arria%2010%20%2F%20Cyclone%2010%20GX%20Pre-Emphasis%20and%20Output%20Swing and on p. 275 of this user guide: https://cdrdv2.intel.com/v1/dl/getContent/666347?fileName=ug_cyclone10_xcvr_phy-683054-666347.pdf Therefore, I have 2 questions: Where can I find this specific spreadsheet? Is there something I can do in general to more easily access all the broken links that Intel provides?
3 years ago Place Quartus® Prime
945Views
0likes
3Comments
Re: How to constrain a source-synchronous FPGA input?
The timing requirements can be met using PHY Lite. Unfortunately, the PHY Lite documentation is atrocious. This led to a protracted nightmare of failed Intel "support" here and then here. Eventually, my company was somehow able to contact an engineer at Intel, who solved the problem immediately. In summary: The refclk and strb pins (two FPGA pins) must both be driven by the same external clock. There is a bug in all versions of Quartus up to and including 21.4, which prevents the IO delay chains from being configured correctly. Therefore, the design will typically fail timing, even if everything has been configured correctly. As a workaround (until the bug is fixed in Quartus 22.1), the IO delay chains can be configured manually (see details below). Here is the content of the (excellent) E-mail: Quartus should automatically change the IO delay chain settings such that each IO is optimized for both setup and hold however there appears to be a problem with the automatic delay chain calculation algorithm in 21.3 which is why you are seeing lots of hold violations while your setup looks good. I have checked in 21.4 and can confirm that the same issue exists in that version too. I can however confirm that this issue has been resolved in the latest internal release of 22.1 which is due for release very soon. As a temporary solution (prior to the release of 22.1) you can manually set the IO delay chain values using the assignment below. set_instance_assignment -name IO_12_LANE_INPUT_DATA_DELAY_CHAIN 60 -to InData You can apply this to all InData pins (as in the assignment above) however to get the optimum solution you will need to apply different values on a per-pin basis which is also supported. I am looking at what specific settings are required to close timing and will update you in due course. You can see the delay chain values used in the "Delay Chain Summary" section of the Route Stage report. I tested the assignment above in 21.3 and the interface closed timing. With regard to the refclk versus the strobe, ideally these should both originate from the same clock source such that they are PPM aligned. This will prevent the internal FIFO within the PHYLITE IP from overflowing/underflowing. The simplest solution is to connect the same clock on your board to both the strobe and refclk pins of the device. We applied these changes in our project and it met timing. Correct behavior has been confirmed in simulation.
3 years ago Place FPGA Device
1.6KViews
0likes
0Comments
Re: How to migrate source-synchronous GPIO to Intel PHY Lite IP?
I reopened this topic here, but still received no useful help from the "community" staff. My company was somehow able to contact an engineer at Intel, who solved the problem immediately. In summary: The refclk and strb pins (two FPGA pins) must both be driven by the same external clock. There is a bug in all versions of Quartus up to and including 21.4, which prevents the IO delay chains from being configured correctly. Therefore, the design will typically fail timing, even if everything has been configured correctly. As a workaround (until the bug is fixed in Quartus 22.1), the IO delay chains can be configured manually (see details below). Here is the content of the (excellent) E-mail: Quartus should automatically change the IO delay chain settings such that each IO is optimized for both setup and hold however there appears to be a problem with the automatic delay chain calculation algorithm in 21.3 which is why you are seeing lots of hold violations while your setup looks good. I have checked in 21.4 and can confirm that the same issue exists in that version too. I can however confirm that this issue has been resolved in the latest internal release of 22.1 which is due for release very soon. As a temporary solution (prior to the release of 22.1) you can manually set the IO delay chain values using the assignment below. set_instance_assignment -name IO_12_LANE_INPUT_DATA_DELAY_CHAIN 60 -to InData You can apply this to all InData pins (as in the assignment above) however to get the optimum solution you will need to apply different values on a per-pin basis which is also supported. I am looking at what specific settings are required to close timing and will update you in due course. You can see the delay chain values used in the "Delay Chain Summary" section of the Route Stage report. I tested the assignment above in 21.3 and the interface closed timing. With regard to the refclk versus the strobe, ideally these should both originate from the same clock source such that they are PPM aligned. This will prevent the internal FIFO within the PHYLITE IP from overflowing/underflowing. The simplest solution is to connect the same clock on your board to both the strobe and refclk pins of the device. We applied these changes in our project and it met timing. Correct behavior has been confirmed in simulation.
3 years ago Place IP & Transceiver
2.4KViews
0likes
0Comments
Re: How to migrate source-synchronous GPIO to Intel PHY Lite IP?
My company was somehow able to contact an engineer at Intel, who solved the problem immediately. In summary: The refclk and strb pins (two FPGA pins) must both be driven by the same external clock. There is a bug in all versions of Quartus up to and including 21.4, which prevents the IO delay chains from being configured correctly. Therefore, the design will typically fail timing, even if everything has been configured correctly. As a workaround (until the bug is fixed in Quartus 22.1), the IO delay chains can be configured manually (see details below). Here is the content of the (excellent) E-mail: Quartus should automatically change the IO delay chain settings such that each IO is optimized for both setup and hold however there appears to be a problem with the automatic delay chain calculation algorithm in 21.3 which is why you are seeing lots of hold violations while your setup looks good. I have checked in 21.4 and can confirm that the same issue exists in that version too. I can however confirm that this issue has been resolved in the latest internal release of 22.1 which is due for release very soon. As a temporary solution (prior to the release of 22.1) you can manually set the IO delay chain values using the assignment below. set_instance_assignment -name IO_12_LANE_INPUT_DATA_DELAY_CHAIN 60 -to InData You can apply this to all InData pins (as in the assignment above) however to get the optimum solution you will need to apply different values on a per-pin basis which is also supported. I am looking at what specific settings are required to close timing and will update you in due course. You can see the delay chain values used in the "Delay Chain Summary" section of the Route Stage report. I tested the assignment above in 21.3 and the interface closed timing. With regard to the refclk versus the strobe, ideally these should both originate from the same clock source such that they are PPM aligned. This will prevent the internal FIFO within the PHYLITE IP from overflowing/underflowing. The simplest solution is to connect the same clock on your board to both the strobe and refclk pins of the device. We applied these changes in our project and it met timing. Correct behavior has been confirmed in simulation.
3 years ago Place IP & Transceiver
1.6KViews
0likes
0Comments
Re: Fitter was unable to place an EMIF with a differential clock
@AdzimZM_Intel My understanding from the documentation is that disabling all the on-chip termination damages performance. Since it is so difficult to get clear and reliable information from Intel (and so much time has already been wasted in this pursuit), we decided to redesign our hardware to use a single-ended reference clock.
3 years ago Place IP & Transceiver
3.5KViews
0likes
0Comments
Re: Arria 10 (speed grade 3) has worse timing performance than Cyclone 10 GX (speed grade 5)
As confirmed by @RichardTanSY_Altera , this is expected behavior. Although it is totally baffling that a more expensive device family, combined with a superior speed grade leads to worse timing performance, I am satisfied that my question has been answered.
3 years ago Place FPGA Device
2.2KViews
0likes
0Comments
Re: Arria 10 (speed grade 3) has worse timing performance than Cyclone 10 GX (speed grade 5)
@RichardTanSY_Altera If this is expected behavior, then there would be no sense in addressing your two questions. Wouldn't it just be a waste of time? Also, my past experience with Intel employees on this forum is that they ask me to provide a project, I spend hours removing sensitive information and uploading the project, then they never bother to look at it. You can easily create your own project. It doesn't seem to matter what is in the project - timing behavior is significantly worse in the more expensive device.
3 years ago Place FPGA Device
2.2KViews
0likes
0Comments