Forum Discussion
Occasional ContributorCyclone V GT Dev Kit - new units fail to boot from FPP
An update/fix if someone else encounters the same issue.
GordWait an I kept investigating the problem and sharing our findings daily, until we got all our boards working 100% of the time on hundreds of reboots. While we ended up with slightly different solutions the root cause is the same, and I will share the core of what helped me for future reference.The root of the problem is presumably some signal integrity/timing issue across the fpga_config_d/fpga_dclk lines, which seems to be present only on newer boards/chips.
The greatest improvement came from reducing the drive strength of these lines, by adding in the QSF:
set_instance_assignment -name CURRENT_STRENGTH_NEW 7MA -to fpga_dclk
set_instance_assignment -name CURRENT_STRENGTH_NEW 7MA -to fpga_config_d[*]While this solution helped on most of the affected boards it did not fix them all.
To better improve the situation the fpga_dclk can be effectively reduced to 50 MHz, with the easiest way being changing the pfl_x8_inst's "Ratio between input clock and DCLK output" to 2. By doing this the fpga_config_d changes on the fpga_dclk's falling edge, thus improving the hold slack.
To better suit this fix there are some constraints to add in the .sdc.
- fpga_dclk should be a generated one:
create_generated_clock -name {fpga_dclk} -source {clk_config} -divide_by 2 [get_ports {fpga_dclk}]- The data output delay should be based on this clock and respect the Cyclone V datasheet tsu:
set_output_delay -add_delay -max -clock [get_clocks {fpga_dclk}] 5.500 [get_ports {fpga_config_d[*]}]
set_output_delay -add_delay -min -clock [get_clocks {fpga_dclk}] -1.000 [get_ports {fpga_config_d[*]}]- If using the "Ratio" option a multicycle path should actually be defined:
set_multicycle_path -setup -start 1 -from [get_registers {*|alt_pfl_cfg_fpga:*|fpga_data_reg[*]}] -to [get_ports {fpga_config_d[*]}]
set_multicycle_path -hold -start 1 -from [get_registers {*|alt_pfl_cfg_fpga:*|fpga_data_reg[*]}] -to [get_ports {fpga_config_d[*]}]Note that these fixes don't consider the usage of the FPPovJ, for which better constrains should be designed.
Moreover, the FPP boot time is largely limited by the flash access time, so even halving the DCLK won't affect the boot time much. Even with the 50 MHz clock it still boots comfortably within our system's PCIE enumeration window.All of this was tested on a limited number of boards, so I can't assure this works 100% of the time, but until Altera finds a proper solution this can be a good starting point for anyone facing the same problem as we did.
Leonardo
Occasional ContributorHi Fakhrul
- The QSF assignments that fixed the issue for me on MAX 5 image are:
set_instance_assignment -name CURRENT_STRENGTH_NEW 7MA -to fpga_dclk
set_instance_assignment -name CURRENT_STRENGTH_NEW 7MA -to fpga_config_d[*]
To be honest, in the MAX 5 image I'm currently using I also changed the logic to run fpga_dclk at 50 MHz, but even in the tests I've done at 100 MHz it was working fine (though the testing was not so extensive).
- I just tested the 2 affected boards and 1 working board with the new MAX image for around 100 power cycles. They worked 100% of the time. Obviously my sample size is quite limited, and this was only tested at room temperature.
- Regarding the waveforms, you can find the ones regarding dclk and config_d below. On the left is the one obtained with the new MAX image (also with the reduction to 50 MHz), and on the right the original image. While I reckon that the new MAX image is a bit too slow for my liking, the original one has quite a bad overshoot/undershoot.
Below you can find the acquisitions on nConfig and nStatus with the original firmware on a not working board. It is not particularly exciting but you can see the FPGA configuration retrying many times until the 6 seconds timeout. Also note that the time interval between the retries is not repeatable across different power cycles, confirming that the issue has some randomness to it.
Do you have any update on the "related case that is currently under internal review" you mentioned in a previous message? Can you confirm whether you were able to replicate/verify the issue on your side?
Best regards,
Leonardo
Regular ContributorHi Leonardo,
Thank you for the detailed results and waveforms. Achieving 100 successful power cycles on all three boards is encouraging. The original overshoot/undershoot and the improvement with reduced drive strength support a marginal signal-integrity or timing-margin issue in the FPP path.
However, since the modified image changes both the drive strength and DCLK frequency, we cannot yet confirm the root cause or treat this as an official production fix. If practical, could you perform one final comparison at 100 MHz, changing only the drive strength to 7 mA, and share the Quartus version used?
The related internal case remains under engineering review; we do not yet have a confirmed internal reproduction or root cause. We will add your findings and request review of the DCLK routing and factory MAX V settings. Please treat the 7 mA setting as an experimental workaround. You may proceed with the distributor RMA process if you prefer, while we continue the engineering assessment.
Thank you again for your valuable investigation.
Regards,
Fakhrul
- LeonardoG
Hi Fakhrul,
Sorry, I forgot the Quartus version in my last message. For the MAX V image I'm using Quartus 14.1.
I did a final comparison at 100 MHz, changing only the drive strength to 7 mA. Even in this case the 2 "affected" boards always booted correctly over around 100 retries each.
One caveat is that in this situation, when probing DCLK with the oscilloscope, the boot failed and I could clearly see the waveform not reaching 2.5 V. Unfortunately I don't have an active probe available at the moment to scope it better. But even a "working" board with the default image sometimes failed to boot when being probed.
I guess the 7 mA clearly helps, but I can't really say if it is 100% reliable. With the 50 MHz DCLK I feel confident enough.
Regards,
Leonardo 
GordWaitHi FakhrulA,
I think you will find that Intel/Altera have moved the manufacturing of the Max V CPLD to a new fab line, and the new versions have much faster rise and fall times on the output drivers. As LeonardoG has found, the DCLK routing on the CVGT board is far from ideal, and the fact that reducing the drive strength seems to fix things seems to indicate this silicon fab change. This would be your root cause.
