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
Regular ContributorHi Leonardo,
Thank you for sharing the detailed observation.
We understand your concern, especially since the issue is seen even with the factory MAX V image and factory FPGA/flash content. Based on your description, the behavior appears to be specific to FPP configuration through the MAX V path, while AS configuration is still working.
We will need to further review this internally. Could you please help provide the following details?
1. Board revision and serial numbers of the affected and working units
2. MAX V image version used
3. Factory design package version used
4. Any observed difference in boot behavior between factory image and custom MAX V image
We will check this further and update once we have more information.
Regards,
Fakhrul
Occasional ContributorHi Fakhrul,
Correct, AS works as expected while the FPGA can't be programmed by the MAX V through FPP.
Here are the info you requested:
1. We have two affected boards with S/N: 5CPCIE00100214 and 5CPCIE00100263, and one working board with S/N 5CPCIE00100041. All three boards are revision B (the PCB is actually labelled rev. A, but the mismatch between the PCB rev. and the actual rev. has always been there). In the past we had other rev. B boards which were all working, but I don't have the S/N available.
2. We used both the MAX V v6 image included in the factory design "Installer Package for Windows (v22.1std)", and a MAX V v5 image edited with the correct flash pinout according to the revision change. We also used some other custom images based on both v5 and v6 with different timing constraints and/or utilization.
3. The factory design package used is the one included in "Installer Package for Windows (v22.1std)".
4. There is no significant difference in behavior between the MAX V images. With a very lightweight MAX V image to reduce utilization, one of the two affected boards actually boots once every ~50 power cycles, but I wouldn't consider it significant enough.
Thank you,
Leonardo
