Forum Discussion

Knug's avatar
Knug
Icon for Contributor rankContributor
4 years ago

How to handle properly pfl_flash_access_granted & pfl_flash_access_request signals ?

Hi @YuanLi_S_Intel

How to handle properly pfl_flash_access_granted & pfl_flash_access_request signals if PFL uses both Flash Programming + FPGA Configuration mode

Looked at the PFL doc :

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf

Seen in the pin list what it describes BUT cannot get CFI_1Gb flash to be detected to perform flash programming of the generated .pof (when I combined the 2 flash programming + fpga configuration & generated just one module) within CPLD MAX V.

Seen the following message on the JTAG programmer screen:

"Waiting for pfl_flash_access_granted to be asserted"

Before we had separate loader (for flash programming) & separate config module (for FPGA configuration FPPx16) (MConfig module was a VHDL wrapper instantiating the loader_pfl) generated within the CPLD (that worked ok ie was programming the flash with the loader .pof & then autodetecting the flash & then FPGA configuration of the application code was successful) but after I combined the 2 functionalities (flash programming + FPGA configuration using FPPx16) into 1 module & tried to use same internal logic controlling the pfl_flash_access_granted & pfl_flash_access_request signals as was done for the Mconfig standalone module had problems autodetecting the flash.

The issue autodetecting the flash has to do with the controlling correctly the pfl_flash_access_granted & pfl_flash_access_request signals.

The logic that was implemented within MConfig and re-used in the 1 module (when combining the Flash Programming & FPGA Configuration together in 1 module) was:

pfl_flash_acess_request output of the loader_config_pfl was connected internally within the Loader_MConfig wrapper as follows :

pfl_flash_access_granted <= pfl_flash_access_request AND (not fpga_conf_done);

It was actually connected like this within the component instantiation :

::::

signal r_fl_access_req : std_logic;
signal r_config_done : std_logic := '0';

::::

pfl_inst : component config_pfl
port map (
flash_addr => flash_addr,
flash_data => flash_data,
flash_nce => flash_nce,
flash_noe => flash_noe,
flash_nwe => flash_nwe,
fpga_conf_done => fpga_conf_done,
fpga_data => fpga_data,
fpga_dclk => fpga_dclk,
fpga_nconfig => fpga_nconfig,
fpga_nstatus => fpga_nstatus,
fpga_pgm => fpga_pgm,
pfl_clk => in_clk,
pfl_flash_access_granted => r_fl_access_req and (not fpga_conf_done),
pfl_flash_access_request => r_fl_access_req,
pfl_nreset => (not r_config_done)
);

----

If I connect directly the pfl_flash_access_request output signal to the input pfl_flash_access_granted of the pfl within the Loader_MConfig wrapper, I see that I can autodetect the flash after I load the loadware code and do a power cycle BUT it fails to program the loaded application code !

----

I read in the above pfl doc pg13 the following :

"When programming the configuration flash memory device through the CPLD JTAG pins, you must tri-state the FPGA configuration pins common to the CPLD and the configuration flash memory device.
You can use the pfl_flash_access_request and pfl_flash_access_granted signals of the PFL block to tri-state the correct FPGA configuration pins"

pfl_flash_access_granted signal (wrt PFL IP core doc) it states that it enables the access to the flash memory device whenever the PFL IP core receives a high input signal at this pin. This active high pin can be connected permanedly high if we want PFL Core to function as the Flash Master. Pulling the pfl_flash_access_granted pin low prevents the JTAG interface from accessing the flash and FPGA configuration.

Q/ Is it ok to connect pfl_flash_access_granted input pfl to '1' and leave the pfl_flash_access_request output unconnected?

When I did this & compiled the code, I had the following extra warnings :

Warning (13044): Always-enabled tri-state buffer(s) removed
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[0]" to the node "flash_addr[0]" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[1]" to the node "flash_addr[1]" into a wire
:::
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[23]" to the node "flash_addr[23]" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[24]" to the node "flash_addr[24]" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[25]" to the node "flash_addr[25]" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_nce" to the node "flash_nce" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_noe" to the node "flash_noe" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_nwe" to the node "flash_nwe" into a wire

I did not attempt to try this on the bench yet. Asking whether it is ok to try this but seen above (13045) warning Converted the fanout from the always-enabled tri-state buffer to a wire !!

Any help on this matter will be appreciated

Regards,

Kevin

45 Replies

Show More
  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    I have concern on the nConfig and CONF_DONE pin.


    The nConfig should be released except that something is driving this low. Do you have osciloscope to scope this signal?


    The CONF_DONE will only be released to high by FPGA when the configuration is completed. If the nConfig is low then the CONF_DONE shouldn't be high.



    • Knug's avatar
      Knug
      Icon for Contributor rankContributor
      4 years ago

      Hi @JohnT_Intel

      Yes, I am using a logic Analyser scoping nConfig + CONF_DONE & nStatus.

      Those readings I supplied were before even autodetecting the flash and loading the application code to check if FPGA is configured. You just asked me for the status of those signals after power cycle & I supplied them to you.

      Why did you state that "if the nConfig is low then the CONF_DONE shouldn't be high" at that stage?

      Wrt page 1:

      https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cfg/cfg_cf51001.pdf

      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 ?

      ----

      I carried on autodetecting the flash & then loading the application code.

      In the latest run, I noticed CONF_DONE being low, nStatus being high and nCONFIG low

      Configuration somehow kickstarted because noticed DCLK pulsing and CONF_DONE went high at the end of the configuration cycle BUT nConfig was low throughout this time. Application code was not running (ie FPGA configuration not fully working).

      So, yes nConfig could be the issue during the Configuration phase. Expected that pin to be high. Please confirm here.

      Regards,

      Kevin

      • Knug's avatar
        Knug
        Icon for Contributor rankContributor
        4 years ago

        Hi @JohnT_Intel

        After looking into the 'loader', 'Mconfig' separate PFLs within CPLD noticed at the beginning when loading / programming/configuring the 'loader' code, there is no FPGA_nconfig, FPGA_conf_done, FPGA_conf_done signals used here (note: these pins were declared later at the 'Config' PFL). Pin list of the 'loader' listed those pins as “Reserved input with a weak pull-up”. So during this stage eg pin A4 (which is used later in the 'Config' module as FPGA_nconfig) was listed for the loader as “Reserved input with a weak pull-up”, so this looks the reason why pin A4 is high at this stage (as expected due to the reserved weak pull-up resistor).

        In my case with the combined PFL Loader_MConfig, pin A4 is set to FPGA_nconfig from the start BUT since there is no pull-up resistor present on the board to the FPGA_nconfig line this line cannot go high right after reset to begin the configuration cycle. And thus since FPGA_nconfig is low, the device is held in reset. Isn't this the case? Please confirm

        Note:

        -> FPGA_nconfig is output of the PFL module, so I do not have direct control access to this

        -> nStatus & conf_done noticed pull-up resistors in place but not on the FPGA_nconfig line.

        Regards,

        Kevin

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    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"


    • Knug's avatar
      Knug
      Icon for Contributor rankContributor
      4 years ago

      Hi @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?

      • Knug's avatar
        Knug
        Icon for Contributor rankContributor
        4 years ago

        One 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..

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    I would recommend that you connect the nConfig to weak-pull high before we proceed as this will help on avoiding the device from getting reset.


    • Knug's avatar
      Knug
      Icon for Contributor rankContributor
      4 years ago

      Hi @JohnT_Intel

      I raised this concern about the pull-up resistor to the FPGA_nconfig line.

      However, my colleague came back to tell me that there was a hardware mod on the board adding a pull-up resistor to the FPGA_nconfig line.

      I would not have been able to spot that that pull-up resistor modification was connected to the FPGA_nconfig line. My board has a DALE 1441 type (questioned to whether this a 1.44Kohm resistor? or 1441 means something else?)

      Instructions they listed specified a 10K pull-up resistor and a 10K is the recommended value your link doc (listed within this ticket) suggested

      Does it make a difference to the value of the pull-up? The larger the value the weaker it is. Isn't this the case? or should I attempt to change this to a 10k value one?

      You suggested connecting the nConfig to a weak-pull high as this will help on avoiding the device from getting reset. The 1.44K resistor is a stronger pull-up. Will this be the reason of the issue seen ? Do I need to change it to a 10K one (ie weaker pull-up) ?

      • Knug's avatar
        Knug
        Icon for Contributor rankContributor
        4 years ago

        Another meeting I had, my colleague confirmed that the DALE 1441 resistor (same one on his board) is a 10K one. When he unsoldered the resistor on one end he measured it as 10K and he said it was written 10K at the bottom of the resistor which I could not see whilst the resistor is soldered on the board. So FPGA_nconfig looks to have a 10K pull up resistor to 3V3

        What is the problem then?? Why the FPGA cannot be configured? What causes the FPGA_nconfig stay low?

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    May I know if the nConfig is only connected to CPLD or it is connected to other host as well? The reason is that something is driving the nConfig low which cause the issue. We will need to figure out where it is driving from.


    • Knug's avatar
      Knug
      Icon for Contributor rankContributor
      4 years ago

      Hi @JohnT_Intel

      nConfig is an output from the CPLD and it is connected directly to the FPGA nConfig pin (input) and has a 10K pull up resistor.

      It may be trying to do FPGA configuration at the start and puts nConfig line low together with Conf done (nStatus remaining high) and fails doing it (will be re-checking this) when I try to configure/program the PFL before even autodetecting the flash to program/configure it with the FPGA application code and thus when I reach that stage nConfig line is still held low !

      • Knug's avatar
        Knug
        Icon for Contributor rankContributor
        4 years ago

        Hi @JohnT_Intel ,

        Stuck with this issue and cannot find the solution.

        With the combined PFL solution, PFL logic in CPLD should determine when to start Configuration process, read the data from the flash & program it and then later configure the FPGA in FPP configuration scheme.

        Need correct signal control access during these stages.

        conf_done, nstatus, nconfig, pfl_flash_access_granted, pfl_flash_access_request, pfl_nreset, flash_nreset

        PFL combined solution documentation is NOT available. The only thing it documents is when creating 2 different PFLs, one for flash programming and one for FPGA configuration.

        I'm I not right to say that conf_done should be all the time high and when Configuration kickstarts it should go low and nConfig line should be high (nStatus line high too).

        nConfig stayed low?? that kept conf_done low too & tried kickstarting FPGA configuration at the end after flash programming (noticed DCLK pulsing until conf_done gone back high) and conf_done went back high at the end but the annoyed nConfig line kept being low !

  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    May I know if you are able to try to find out who is pulling the nConfig low? Is it coming from the CPLD? I don't think that the PFL will pull the nConfig low without releasing it.


    The FPGA is only using the nConfig pin as input pin and there is no way it is driving it low.


  • JohnT_Altera's avatar
    JohnT_Altera
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi Kevin,


    What are your views wrt the counter I added ?

    If the user does not program the flash and delays this passing the time when pfl_nreset goes back high, the system will fail to configure the FPGA.


    I suspect that the PFL is performing something that cause the system will fail to configure the FPGA. Will need to monitor all the signal to understand what is actually happening.