Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Programming of QSPI-flash (connected to arbitrary GPIO-pins of a MAX10 device) with openFPGALoader / spiOverJtag #435

Open
TrioKross opened this issue Feb 23, 2024 · 2 comments

Comments

@TrioKross
Copy link

Hello,

first of all : Thank you for this great project! Good learning stuff, a very useful tool ... and fun :-)

Goal :

My goal is to use openFPGALoader for programming a QSPI-flash (connected to arbitrary GPIO-pins of a MAX10 device) via "spiOverJtag"-bride!

Things found out (so far...) :

(please correct if wrong or misunderstood!)

a) openFPGALoader supports this feature for Cyclone (IV, V, 10 ...) families

  • device-specific bridge-file required; included for certain device types (spiOverJtag_5ce223.rbf, spiOverJtag_5ce423.rbf.gz, ...)
  • "altera_spiOverJtag.v" is based on "altserial_flash_loader", which relies on the "ASMI hard logic block" (Active Serial Memory Interface) inside Cyclone devices
  • QSPI-flash must be connected to Cyclone's "dedicated QSPI pins" (AS_nCS, AS_DCLK, AS_DATA[3:0])
  • (after programming) QSPI-flash used to configure the Cyclone device (ASx4)

b) MAX10 devices don't have an "ASMI hard logic block"!

  • use "Parallel Flash Loader IP" (in QSPI mode!) instead
  • QSPI-flash (fl_nCS, fl_sck, fl_iodata[3:0]) connected to arbitrary GPIO-pins of MAX10 device (since there aren't any dedicated pins!)
  • (after programming) QSPI-flash may be used to configure a FPGA (e.g. Stratix) per Fast-Passive-Parallel (FPP) config scheme (via Parallel Flash Loader IP in MAX10)

c) "spiOverJtag"-bride (based on "altera_parallel_flash_loader") needs to be generated for MAX10 devices:

  • Not only device-specific (as for Cyclone devices), but also depending on the 6 GPIO-pins selected for connecting the QSPI-flash!

Questions :

Let's suppose the MAX10 is already programmed/running a "spiOverJtag"-bridge (based on "altera_parallel_flash_loader"):

  • What are the next prerequisites for programming a file into the QSPI-flash?
  • Which file format (rbf, svf, jbc, jam, pof ... jic/rpd?) is to be chosen?
  • How to generate this file? (from sof/pof/rbf?)
  • How to call "openFPGALoader" (which parameters are required) ?
  • Use the "--skip-load-bridge" parameter?
  • Is openFPGALoader already prepared for this task? Any additions required?

(Further/Next step would/could be to integrate the new bridge into openFPGALoader to load it temporarily into MAX10-SRAM before programming the QSPI-flash...)

Notes :

  • Already tested: Load "MyProject.svf" into MAX10-SRAM via openFPGALoader : OK (rbf not supported for MAX10!)
  • Intended QSPI-flash devices: "W25Q64", "MT25QU02G"

Thanks in advance for your help/comments/hints

@trabucayre
Copy link
Owner

Thanks!
For spiOverJtag it's not really based on altera_parallel_flash_loader. In fact it uses virtual jtag in one side and altserial_flash_loader in another side:

  • the first is used to communicate between computer and FPGA logic
  • the latter is used to have access to an external flash (it's not possible to bypass this block since these gpios are configured, by default, for SPI flash access.

In fact you can use the logic and remove spi flash module to directly connect SPI signals to your flash with a constraints file correctly configured. openFPGALoader know how to deal with FPGA logic but have no idea about module required to access SPI flash on cyclone devices.

MAX10 is a work in progress. Unfortunately there is no docs on how to program device (or flash it) this is why currently it's required to use an svf file.

@TrioKross
Copy link
Author

Thanks for your reply.

I was thinking of creating a new variant of "altera_spiOverJtag.v" (=> "max10_spiOverJtag" ?), which uses "virtual jtag" on one side and "altera_parallel_flash_loader" on the other side. [Parallel Flash Loader IP UG]

As mentioned before "altserial_flash_loader" is not appropriate for MAX10, because of the missing "ASMI hard logic" in MAX10 devices.
But "altera_parallel_flash_loader" has a "soft-logic" block for QSPI-flash interface. This interface needs to be connected to GPIO-pins, which is user-defined and therefore not as "generic" as the ASMI of the Cyclone devices.

Steps required:

1) Generate a new bridge image "max10_spiOverJtag" (svf - not rbf!)

  • "virtual jtag" => "altera_parallel_flash_loader"
  • user-defined mapping of QSPI-flash signals to MAX10-GPIO pins
  • device-specific / package-dependent

2) Load/program "max10_spiOverJtag" to MAX10-device

  • (at this point) it is not important, if the new bridge-image is loaded to MAX10-SRAM or programmed into the on-chip configuration-flash-memory (CFM)
  • it is also thinkable to include the "spiOverJtag-bridge" permanently into the MAX10 user logic design, so loading the bridge can be skipped then (option "--skip-load-bridge")
  • option "--skip-load-bridge" : must be used as long as "auto-load" for "bridge.svf" is not included in openFPGALoader code

3) Write/program QSPI-Flash (with arbitrary data)

  • e.g. rbf-image with configuration data for another FPGA (e.g. Stratix V via FPP config scheme), that is also connected to the MAX10 device
  • e.g. "Linux rootfs" image for SoC

Something similar is done here (using the Quartus Programmer):
[Program POF (linux image) into Quad SPI Flash]
(although a "Linux rootfs Image" is written to the QSPI-flash instead of a FPGA configuration image)

One question is whether openFPGALoader is already compatible to "altera_parallel_flash_loader" (regarding SPI/QSPI-flash programming - and NOT regarding the "Autoload-bridge to MAX10" functionality), as it certainly is for "altserial_flash_loader"?

Please let me know what you think about that.

Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants