Parallel Flash Loader function

Hello,

I have a couple of problem with the Parallel Flash Loader on a custom board. First, I describe my conditions:

1) Stratix III FPGA (ep3se110f1115i3) to be configured via Fast Passive Parallel

2) MAX II ( EPM570F100) to configure the FPGA and the flash; due to space saving needs I use the access mode in normal mode (no bursts)

3) Quartus II 9.0 (no sp, no patches)

4) usb blaster (both rev b and rev c)

5) Intel P30 flash

Then I try so summarize my observations:

1) via JTAG I can access the fpga and correctly configure it so I think it is in a good health state

2) via JTAG I can access the MAX II and configure it

3) once configured the MAX II with a PFL I can examine the flash chip and I see it is correctly identified

4) with Quartus programmer I try to write the Option Bits via MAXII and it is done

5) as above with page 0 but the verify fails (fpga not programmed). I observed that the writing phase is very quick... I suspect this is too quick: watching the flash content with u-boot from the FPGA after a failed writing I find quite all bits still set to 1 and some bits (the position seems random) to 0.

6) tried to instantiate a PFL in an FPGA project... same results. (MAX II erased to prevent concurrent writings)

7) tried to write the Option Bits with PFL and page 0 via u-boot on fpga. The flash content has been updated and checking manually some parts of the .rbf file with the bits in memory has given positive results. Anyway after reprogramming MAX II and a power down cycle the FPGA is not programmed.

Anyone has suggestions?

Thanks for attention,

gabrigob

I used PFL with Spansion rather than Intel flash, so I don't know, if there are particular issues. AN386 says, that only 28F128P30 has been actually tested, the others should work according to their CFI compliance.

If you didn't modify the PFL design, I would primarly expect a hardware issue, e.g. wrong flash wiring. I understand that you wired the flash to MAX II and FPGA in parallel. I hope, this doesn't bring up problems.

As you reported, that the flash isn't programmed by the PFL when it should, I would start checking the flash signal during programming sequence with a logic analyzer or oscilloscope. Running the PFL on the FPGA, you can also use SignalTap.

Thank you FvM for your answer.

We made some measurements with an oscilloscope. Putting the probes on MAX II pins we observed the following things:

1) at power up it continue to try to configure the FPGA. It fails and this is due to the incorrect page 0 configuration (it fails the verify after loading into flash via pfl). Owing to this, conf_done is never released

2) with reference to figure 11-6 on page 11-4 of stratix III handbook, all measured signals (nConfig, nStatus, DCLK) are inside tolerance range for timing; voltage and overshoot seem ok too

We've then kept focus on the bus between the flash and max II and, using again the probes, we found that:

1) on the rise of nconfig the PFL inside MAX II reads at base_address_option_bits+0x80 which contains ff03 (did not found any reference on AN386 but I must re-read)

2) read locations base_address_option_bits and base_address_option_bits+2 and reads expected values (start address and end address of page 0)

Basing on experience with CFI flash decives, we suspected a timing violation on programming cycles particularly thinking about the lot of ones and the fewer zeros seen with u-boot.

We made quartus programmer to configure the flash via PFL on max II and we seen:

1) during erase cycles before programming, the pfl (or quartus II via Jtag) a polling of reads is done probably to verify the erase of the single position has been done successefuly

2) during programming, only write cycles are done (no polling) and write cycles are done with short time intervals measured (with oscilloscope) between 10 us and 57 us; those values seem shorter than the conventional word programming times (200 us reported on Intel/Numonyx P30 data sheet)

thanks,

gabrigob

Thanks again FvM,

We observed that, during programming, only write cycles are done (no polling) and write cycles are done with short time intervals measured (with oscilloscope) between 10 us and 57 us; those values seem shorter than the conventional word programming times (200 us reported on Intel/Numonyx P30 data sheet).

The data sheet reports that the flash chip has a small buffer for write operations so the option bit (that are a small) can be saved in the buffer while most part of the data are lost due to, most likely, a buffer overflow having insufficient pauses between writes.

But I am not shure I have understood correctly your suggestion.

sincerely,

gabrigob

Hello,

today we tried to install QuartusII version 9.1 on Windows Vista. Now the flash is correctly programmed.

I missed to tell you all that all these experiments were done under LINUX.

Is it possible that a difference in time calculations between Linux and Windows make the quartus II programmer fail to correctly access the flash?

This could mean that the access time is calculated without hardware feedback.

The other option is that a bug was found on version 9.0 and corrected on 9.1 without declaring it on the megafunction errata.

In your experience, who could tell it to us? An Altera FAE or the mySypport Service?

You can check yourself, if the error is in the Megafunction code or the Quartus Programmer tool. I would expect the latter, most likely specific to the Linux version. Did you use the basic or enhanced PFL version? The enhanced version has considerably faster programming operation, but needs more MAX II resources.

You should contact Altera support in any case, I think.

--- Quote Start ---

Hello,

I have a couple of problem with the Parallel Flash Loader on a custom board. First, I describe my conditions:

1) Stratix III FPGA (ep3se110f1115i3) to be configured via Fast Passive Parallel

2) MAX II ( EPM570F100) to configure the FPGA and the flash; due to space saving needs I use the access mode in normal mode (no bursts)

3) Quartus II 9.0 (no sp, no patches)

4) usb blaster (both rev b and rev c)

5) intel p30 flash

Then I try so summarize my observations:

1) via JTAG I can access the fpga and correctly configure it so I think it is in a good health state

2) via JTAG I can access the MAX II and configure it

3) once configured the MAX II with a PFL I can examine the flash chip and I see it is correctly identified

4) with Quartus programmer I try to write the Option Bits via MAXII and it is done

5) as above with page 0 but the verify fails (fpga not programmed). I observed that the writing phase is very quick... I suspect this is too quick: watching the flash content with u-boot from the FPGA after a failed writing I find quite all bits still set to 1 and some bits (the position seems random) to 0.

6) tried to instantiate a PFL in an FPGA project... same results. (MAX II erased to prevent concurrent writings)

7) tried to write the Option Bits with PFL and page 0 via u-boot on fpga. The flash content has been updated and checking manually some parts of the .rbf file with the bits in memory has given positive results. Anyway after reprogramming MAX II and a power down cycle the FPGA is not programmed.

Anyone has suggestions?

Thanks for attention,

gabrigob

--- Quote End ---

P30 flash is now produced by Numonyx. Numonyx's P30 has longer programming time than Intel's but both shared the same device ID code. Numonyx's P30/P33 are supported only from Quartus II 9.1 onwards. In 9.1, programmer will do an extra checking after reading the device ID for P30/P33 to differentiate between Intel's and Numonyx's. If you happen to use Numonyx P30 in 9.0, the flash would be programmed using the values meant for Intel P30, so you will expect failures since Numonyx's P30 has longer programming time. Hope this clears everything :)