Contributor
Regular ContributorHi,
At the beginning before configuration starts (ref. Fig1) nConfig is low, CONF_DONE is high & nStatus is high so it looks like we are at that stage. I'm I not correct to state this ?
This is not correct as if the nConfig is low then the CONF_DONE will be also be reset with the maximum delay of 600ns. You may refer to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_51002.pdf Table 18.
The nConfig pin of the FPGA is a input pin where it will need to be pull-high and if external component is driving it low then it will go into reset state.
You may refer to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_5v2.pdf "Figure 7-1: Configuration Sequence for Cyclone V Devices"
ContributorHi @JohnT_Intel
>>This is not correct as if the nConfig is low then the CONF_DONE will be also be >>reset with the maximum delay of 600ns. You may refer >>to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature>>/hb/cyclone-v/cv_51002.pdf Table 18.
Table 18 in the above link has no relation on what we are talking about. Which Table 18 you mean? or do you mean Table 58?'
----
A better state Configuration cycle state machine I was looking at yesterday is at :
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cfg/cfg_cf51001.pdf - Fig2
After power up, the FPGA should hold FPGA_nStatus low for the time of the POR delay.
After power up, before and during configuration, open drain FPGA_conf_done should be low
When the device comes out of reset, FPGA_nConfig must be at logic high level in order to release the open-drain FPGA_nStatus pin. Cyclone FPGA should sense the low-to-high transition on FPGA_nconfig to initiate configuration. After FPGA_nStatus is released, it should be pulled high by a pull-up resistor and the FPGA will be ready to receive Configuration data. To begin configuration, FPGA_nconfig & FPGA_nStatus must be at a logic high level and kickstart configuration. The device should then receive configuration data on it’s DATA0 pins.
Isn't this the case?
>> The nConfig pin of the FPGA is a input pin where it will need to be pull-high and if >> external component is driving it low then it will go into reset state.
The nConfig is an output of the PFL module and I do not control it within the CPLD (as stated before). BUT if an external pull-up resistor is not present on the nConfig pin, it will not drive it back high right after reset. Isn't this the case?
ContributorOne thing which I will report to my team is the nconfig could be missing the pull-up resistor.
---
I just run again the combined PFL Loader_MConfig. Noticed just if I load program/configure the Loader_MConfig.pof file (this is before power cycle to autodetect the flash and then run the application code to configure the FPGA once the flash is detected)
Conf_done was high then it went low. pfl_flash_access_request and pfl_flash_access_granted went low from high and after around 28uS later nConfig went low and stayed low. pfl_flash_access_request and pfl_flash_access_granted stayed low for about 66.18uS and then went back high. fpga_dclk then started clocking.
fpga_conf_done was low for 641.191mS and then it went back high. fpga_dclk was pulsing during the time the conf_done was low.
--
This looks like it tried to configure the FPGA during this time ! I was not expecting this at this stage. Please comment here ..
FPGA configuration should happen after power cycling / autodetecting the flash and then loading the application code for flash erase the flash programming and then FPGA configuration at the end.
---
I tried re-running the same above ie just loading programming/configuring the combined Loader_MConfig.pof file (this is again before power cycle to autodetect the flash and then run the application code to configure the FPGA once the flash is detected).
Results were now different than the ones reported above.
conf_done and nstatus remained high.
fpga_nconfig went low and fpga_dclk went low from high and both stayed low
pfl_flash_access_request and pfl_flash_access_granted went both low before fpga_nconfig went low.
This is the state I had before and suspected fpga_nconfig staying low (held in reset state).
With this test (2nd try), managed to autodetect the flash ok after power cycle but fpga_nconfig stayed low and conf_done and nstatus stayed high here.
Decided not to load/program the application code because I know it will not configure the FPGA after successful flash programming..
