we're designing a scan rate converter and scaler with an Intel Cyclone 10 FPGA. The output pixel clock shall be configurable, and we've solved a bit of the puzzle, but not all of it yet.
As the official Cyclone 10 datasheet is not complete on this topic (doesn't tell what each of the 144 bits does, only a global description) and has various small errors and omissions (I still don't really know if the PLL is sampling the serial-data on rising or falling edge as they don't tell!). And the recommended application note for PLL reconfiguration has the wrong bit order in the table for one of the values. And it only explains the purpose of about 130 of the 144 config bits.
Maybe I'm missing a more up-to-date application note, but I really spent considerable time to search for a proper description. Oh, and if someone within Intel will be assigned to the job of writing a complete document about the topic, it would be nice to get info on how to calculate all the values, so a truly variable output pixel clock is possible for my project.
Are you referring to latest
Also Refer below links which may help you
Let me know if this has helped resolve the issue you are facing or if you need any further assistance.
Anand Raj Shankar
(This message was posted on behalf of Intel Corporation)
Thanks - that covers exactly, well, zero of my questions.
AN-661 also uses the PLL_RECONFIG block, but does NOT explain the 144 bits that flow between that and the PLL (which is the interface we use). The Appnote does however have a link to a pll_calculator for calculating the charge pump and filters. This sounds like a handy tool - if only the link would not end up in a 404 error.
Our goal is to calculate these 144 bits for a user-given target frequency in order to match that "as close as possible". We don't want to switch between two or three frequencies, but probably at least 20 - and we don't want to keep that many discrete configurations.
Please note that we've been designing with Altera FPGAs since 2002, the days of the Acex 1k series. There's quite a bit of experience in this company, and we would not be asking this question if we had not searched many other sources. So I kindly ask for a little bit more effort - we do have about 130 of these bits explained from a number of sources (including a bit of reverse engineering), but there's still a gap in documentation.
kind regards from Germany,
The exact part number is 10CL006YU256C8G. We've bought a 4-digit quantity through Arrow Germany already, planning to buy a lot more if this re-configurable PLL topic is solved - possibly the slightly-bigger version 10CL010YU256C8G because it has a few more multipliers (RFQ is currently ongoing through Arrow).
I understand that the PLL block is identical between these two, so our decision for the smaller or bigger part does not affect this request for documentation.
RSree, thanks for calling me yesterday. Although I am not a native speaker, I must say that your English will only need a few more years of practise, and you will be able to hold a free conversation. So after 18 minutes, you've found what I already wrote here: The pll reconfiguration calculator link from AN661 is dead:
You even wrote another message, confirming that you do not have access to the file in your internal documentation library. I have now done some Googling, and found the file, referenced from yet another Intel page:
I just love how Intel respects the valuable time of customers.
Will report back here if the excel sheet answers a few more questions. Right now, Libre office does not show me the source code of the output cells, but that's probably just a setting.
OK, this is starting to get *really* annoying. The document requires a password for the formulas to be viewed. Do I really need to crack the password myself, or are you posting the password here, showing that you actually want to give an answer to a paying customer?
Removing the password and making the fields visible was easy enough. Unfortunately, I can't seem to attach anything here - should anyone be interested in the libre office file to see how the bits are assembled, just contact Jens at icomp.de.
So all this effort comes down to "no, this does not answer the question either", as the Excel sheet does not generate the full 144-bit stream. In fact, it even seems to be incomplete, as I can only select "low" as a bandwidth setting. Is that intentional? Or just a result of "work in progress"?
Anyway, it is hard to believe that we're the only ones wanting to use the re-configurable PLL to it's full extent. I have to label my efforts for finding out the remaining, undocumented bits as "failed", hoping for a clear datasheet to be provided by Intel.
greetings from Germany,
Yet another *BUMP* - is it really required to praise the Xilinx support, which has answered all our questions within 24 hours so far?
Come on guys, show some effort. This request has been escalated by the app engineers of Arrow Germany as well, and not a single bit of useful information has come across until now.
Another week has passed, and neither Intel, nor Arrow Europe is moving. We've already discovered that the question is too complicated for the India staff to answer, but there *should* be a few persons from the original Altera staff left who know the details. *PLEASE* put one of these on the case - thanks.
Happy Helloween - no need for costumes if you live the horror of bad and missing documentation!
greetings from Germany,
Please do refer below link.
Let me know if need any further assistance.
Anand Raj Shankar
(This message was posted on behalf of Intel Corporation)
At first sight, this looks like a transcript of the PDFs we already have.
The employee on this topic has a day off today, and yesterday was a holiday in this part of Germany. We'll take a closer look on Monday.
Checking complete: It is the exact same info as in the datasheet. So no detailed bit order (which is no problem for us anymore as we got that from a different document combined with reverse-engineering the Quartus output).
No info how to calculate the charge pump or loop filter to get a specific bandwidth. So yet another *BUMP* with the kind request from a paying customer for proper documentation.
Just a hint: That order for 84 boxes=9996 pcs. 10CL010 is mine (placed through Arrow Germany). I really don't want to play around with "black box values" any longer, as we prefer engineering over tinkering here.
Please refer to the attached .pdf file under table 2 that shows the 144 bits info for the Cyclone 10 LP PLL scan chain bitmap. We have been looking into this request internally and we require some time to check which documentation that has the 144 bits information. Even though the documentation stated Cyclone III, the PLL architecture for Cyclone 10 LP and Cyclone IV should be the same as Cyclone III. For details on the PLL Reconfig for Cyclone 10 LP, you can refer to the link below:
Hopefully this might help to address your needs.
Thanks for - well - again, nothing.
We've already been at the point where we checked Cyclone III documentation, because with such a long history of Altera-based FPGA designs, the similarity of Cyclone 10 vs. Cyclone III is more than obvious.
The document you've attached has errors. Table 2 uses the wrong order for LF_R_0 to LF_R_4 (bits 4 to 8). The table itself is tricky to read, as you need to send it to the PLL starting with bit 0, so you need to read the table from left to right, but from BOTTOM to TOP.
Needless to say that the document completely skips on the topic of filter settings: What are LF_R*, LF_C* and CP*, what do they do and how do you calculate them? The rest of the document is examples that don't correspond to our use case.
Another week has passed, and still no documentation, not even a comment about the document errors I have reported here. Still trying to find that guy who has the knowledge?
Apologize for the delay. I believe you may already know that the LF_R*, LF_C* and CP is referring to loop filter resistor, loop filter capacitor and charge pump. However the information that you are asking specifically for your "case usage" (to calculate the charge pump or loop filter) is not available for public use. We've been checking the documentation and discussing internally back and forth regarding this inquiry with multiple different teams to end up with the same answers. All the information published in the Intel PLL documents are sufficient for users to be able to use the PLL IPs as it is without any issue. There no particular reason or justification for the engineering team to be releasing any other information than what has already been available/published in the official documents. Users can use Quartus PLL IP to get these M,N,C, LP, LF counter parameters either one of this method:
a) Set the Fref and Fout in ALTPLL IP and run Quartus compilation. After full compilation, user can see the information in Compilation Report->PLL Summary.
b) In the ALTPLL IP set the Fref and Fout settings in the PLL reconfiguration and select Generate a Configuration file in the ALTPLL MegaWizard Plug-In Manager. This will then generate either a .hex or .mif file with all the counter settings. Hence customer can use .hex or .mif file to set the ALTPLL_RECONFIG IP.
I apologize that this may not address to what you are looking for specifically, however the counters information can be be obtain without any issue (using the above methods). Thank you for your understanding.
I was kind of expecting that you will retreat to a position that is like this. However, everyone who has been following this thread should know how silly it is to rate this information "classified", as I heard from the Arrow application engineers that there are other customers who have problems with the stability of these PLLs especially with low reference frequencies.
Please note that in a different design with a 10CL025, I've had trouble with the PLL running from an 8MHz reference clock; the PLL lost lock every now and then (maybe once every five seconds), despite perfect voltages and low ripple (<15mv) on 2.5V and 1.2V supplies. After I've put an extra 50MHz oscillator into the design and generated all clocks from that, all problems were gone. Note that jitter on the 8MHz clock was under 250ps - just in case the Arrow app engineers have not reported that case. The design was a migration from an EP3C25, where the 8MHz reference clock has worked for years in the field.
The 50MHz solution is not very satisfying, as I have bought FPGAs with PLLs that are supposed to work with reference clocks as low as 5MHz. In other words: Either the calculation(s) that these black-box-megafunctions do are not correct, or these PLLs just don't comply with the datasheets you're providing.
Having over 30 years of experience reading datasheets, I know that things sometimes need to be read "between the lines". I would have loved to calculate the loop filter components myself, as I'd have the chance to verify what's going wrong. After all, the errors in the document that was posted in this thread is showing without a doubt that people who work for Altera/Intel are not free of errors either.
Revealing a full description of these values can help improve the documentation of your products. I don't see how this could be any problem for Intel, other than admitting that you have no exact idea either (which is no problem, as it's not an Intel invention, but acquired from Altera). You should not be afraid of getting this right - it will ultimately improve your product.
I apologize that the responses here in the forum does not satisfy to what you are looking/requiring. We will channel your input and feedback to the internal/engineering team responsible on this IP for them to consider future documentation enhancement. You are correct there are errors in the document and what we can do is to submit the request to the internal team to take the appropriate action accordingly.
Nevertheless, regarding on the details information that your are questing, unless the engineering team can release/provide the information on the correct multiplication and divisor combination meeting the legal range/limits of the PLL/FPLL IP algorithm then we don't have the direct way to generate desire output clock without trial and error. The information that you are requesting are not available for public use since this is part of the IP and device proprietary.
For other PLL issues (Cyclone 10 PLL stability issue with low reference frequencies 8Mhz) than the original question posted here, I suggest that you can submit another thread. We will find and assign an engineer to help to look into it. Otherwise you may consult with your local distributor, Arrow if you still require further support on this topic.