Forum Discussion
Occasional ContributorCyclone VGT Dev Kit boards - some new boards failing to boot from NOR Flash
Occasional ContributorHi Fakhrul, I looked into your questions.
I have 4 of the bad boards in hand, so I can verify the following serial numbers and the U29 part. All four have the same part that the schematic calls for:
5CPCIE 00100129 - has IDT QS3861
5CPCIE 00100142 - has IDT QS3861
5CPCIE 00100147 - has IDT QS3861
5CPCIE 00100148 - has IDT QS3861
An older Rev B I have here is a good board, it has an IDT Q53VH8COQG device on board.
You mention : " The difference between the factory .pof and self-compiled version may point to differences in fitter/timing results." - since I am using the same provided source files, and the same Quartus version, should it not create the exact same max5.pof binary?
More answers:
- For the 3 boards that work with the factory .pof, do they complete configuration in a single attempt or still show retries? - it seems like the configure in a single attempt, based only on the boot up speed.
- For the 2 boards that still fail, is the retry behavior identical across all images? - yes, random N number of retries until the ERR led turns on.
- Have you compared settings between your compiled .pof and the factory .pof (e.g. compression, configuration options)? - I used the exact factory source files with the factory QSF and constraints files, I get a different checksum, and my compiled factory image does not work at all.
- Could you share the serial numbers of the affected boards? There may be a specific affected range for certain revisions. - yes, see above. (missing one, I don't have it at the moment)
- For the silk screen difference, if possible, please share board markings or photos for comparison.
For my older good working board, there is a silk screen label UK/CA that is in the open to the "East" of the USB jack. For the new bad boards, the UK/CA label is there partly covered by the FPGA fan, further "East".
This will help us check if your boards fall within any known affected batch or if this is a new variation.
Regular ContributorHi GordWait,
Thanks for the detailed follow-up and the serial number information, this helps a lot.
A couple of clarifications from our side:
- The serial numbers you shared (5CPCIE00100129 and above) are outside the known affected range documented in the KDB (5CPCIE00100011 to 5CPCIE00100115).
- Based on our internal data, the impacted component is expected to be QS3VH800QG, which can affect the AS configuration path.
Regarding the U29 marking you mentioned (Q53VH8COQG), we suspect this may be a marking interpretation issue. The assembled part for this location is QS3VH800QG, and depending on the top marking, it can sometimes be misread (e.g. “QS3VH800” appearing similar to “Q53VH8CO”).
Could you help double confirm the marking again (or share a close-up photo if convenient)? This will help ensure we are referencing the exact component correctly.
At the same time, there is still a mismatch between:
- Expected impacted component vs what you’re seeing behaving as “good”
- Your boards being outside the known affected SN range
So your case may not fully align with the documented issue. We are checking this internally and will update once we have more clarity.
Thanks again for the very thorough debug work.
Regards,
Fakhrul
- GordWait
I was finally able to get the factory source to compile and create the exact same binary as the factory binary (max5.pof). (I used Quartus 18.1 and did not allow it to update the library parts. From the files it seems like Quartus 15.1 was used to build the factory max5.pof found in the v22 package. )
Here is our updated S/N list with notes:
5CPCIE 00100129 - has QS3861 - will boot sometimes with factory binary max5.pof (Digikey)
5CPCIE 00100142 - has QS3861 - will boot with factory binary max5.pof. (Digikey)
5CPCIE 00100147 - has QS3861 - will boot with factory binary max5.pof. (Digikey)
5CPCIE 00100148 - has QS3861 - will not boot at all. (Mouser)
5CPCIE 00100134 - not checked yet - will boot with factory binary max5.pof. (Digikey)
5CPCIE 00100144 - not checked yet - will boot with factory binary max5.pof. (Mouser)That binary works with both known good boards and our (4) "marginal" boards. The marginal boards only work with the factory binary max5.pof but not our released production max5.pof with our own edits).
I then just removed the factory_user inversion and restored it to the way it was in previous releases. This build did NOT work with the 3 marginal boards but does work with the good boards.I noticed that the max5 design is 99% full. Any minor change affects timing:
Critical Difference: Slow Model Recovery on `clk_config`
| Check | works | inverted switch | delta |
| Slow Model Recovery `clk_config` (worst path) | **0.361 ns** | **0.122 ns** | −0.239 ns |
| Slow Model Setup `clk_config` | 0.675 ns | 0.973 ns | (inverted switch better) |
| Fast Model Hold `clk_config` | 0.280 ns | 0.280 ns | 0 |
I was able to restore the timing and finally build a working version. Since we don't use the FPGA access port or the I2C controller in the Max5, I removed those to reduce the logic in the Max5, and now my build also works.
Something on the 4 marginal boards is slightly different, so this minor timing change causes them to fail to boot properly.
I suspect the max5.pof timing has always been very close to failing, and something has now changed that makes our production Ikomed max5.pof fail all the time.
Any idea if Altera moved the MaxV CPLD to a different silicon fab line, or perhaps Micron did with the NOR flash?
My next goal is to understand the flash reset timing in more detail and perhaps adjust our Ikomed copy of the max5 design to have far better margin. A timing shift of 0.239 ns is very small.
- FakhrulA_altera
Hi,
Thanks for the detailed update, very helpful.
Your findings strongly point to a timing margin issue in the MAX V design:
- Very high utilization (~99%)
- Small slack change (~0.2 ns) causing pass/fail behavior
- Factory build works, while slight modifications fail on marginal boards
- Reduced logic improves stability
This is consistent with tight timing + board-to-board variation, rather than a functional issue.
On your question, we do not have indication of fab change for MAX V or NOR flash, but we will double check internally.
Your current approach (improving timing margin and simplifying design) is correct. Focusing on recovery paths and adding margin should improve robustness.
Thanks again for the detailed investigation.
- FakhrulA_altera
Hi,
Thanks for the detailed work.
This looks like a timing margin sensitivity in the MAX V design. We do not see indication of any fab or component change on our side, including for your SN range.
Since you have identified a working approach by improving margin, you may proceed with that.
Thanks again.
