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

Add flash support for the Xilinx VCU118 board #293

Closed
6 tasks done
barbedo opened this issue Jan 21, 2023 · 4 comments
Closed
6 tasks done

Add flash support for the Xilinx VCU118 board #293

barbedo opened this issue Jan 21, 2023 · 4 comments

Comments

@barbedo
Copy link
Contributor

barbedo commented Jan 21, 2023

Hey again,

This is a followup from #283, since I've got access to a full Vivado license.

Adding support for the dual QSPI flash on this board was more difficult than I had expected, so I'll try to document all the modifications and the rationale behind them here and break down the code modifications in multiple PRs to ease a bit the review.

If these modifications are merged, it can potentially open the door to support other Xilinx UltraScale-based boards with Dual QSPI Flash, like the KCU105, KCU1116, VCU110, ZCU102, etc.

Changes

  • Add support for the MT25QU01 QSPI flash chip.

  • Add support for flash chips with more than 128 Mb by adding 4-byte addressing when writing to flash addresses higher than 0xFFFFFF.

    • I decided to do it dynamically by using the 4-byte address variation of the read/write/erase commands only if the address is higher than 128 Mb. From what I could find online, pretty much every chip from Micron/Infineon/Spansion with more than 128 Mb supports it.
  • Modify the spiOverJtag module to take into account the new differences introduced by the UltraScale series.

    • The pads to the primary QSPI flash are not accessible anymore directly from the design and need to be accessed through the STARTUPE3 module.
    • The pads to the secondary QSPI flash are accessible as normal I/Os after configuration, except for CCLK, which is shared with the primary flash chip.
    • To avoid maintaining two bitfiles, each one targeting a different flash chip, I chose instead to select which QSPI flash to use based on the boundary scan user instruction that is selected: USER1 for the first flash, USER2 for the second flash.
    • Two BSCANE2 blocks are now instanced.
    • I tried to modify the design only if the virtexultrascale flag is present.
    • See below the diagram for the design:
      vcu118-dual-qspi-flash
    • I regenerated the design for the Arty A7 100T (the only other board that I have access to right now) to verify that it didn't break the bitfile for the other Xilinx FPGAs.
  • Make the instruction register codes variable according to the Xilinx FPGA being used.

    • Only default or xcvu9p for now.
    • According to UltraScale Architecture Configuration User Guide UG570 Table 1-5, the instruction register lengths are variable, because of their 3D IC thingy. The FPGA in the VCU118 board has an IR length of 18 bytes.
    • The instruction codes were taken from the xcvu9p_flga2104.bsd boundary scan file of a Vivado installation.
    • The default instruction code table contains the values from the 7-series FPGAs (values in the previous code).
  • Add a new pair of CLI options --secondary-bitstream and --target-flash.

    • --target-flash indicates the target of write/read/dump flash operations and can be primary, secondary or both. The default is primary.
    • --secondary-bitstream points to the bit file to load or to be dumped when --target-flash is secondary or both. If target-flash=both, then --bitstream also needs to be specified.
    • If someone uses the SPIx8 feature to speed up the loading time or to load a very complex configuration, I envision something like this:
      • openFPGALoader -f --board vcu118 --target-flash both --bitstream my_design_spix8_primary.mcs --secondary-bitstream my_design_spix8_secondary.mcs
    • I needed to make these options independent because using both flash chips is not obligatory. Someone may, for example, load the design on the primary flash only in SPIx4 mode and load arbitrary data in the second:
      • openFPGALoader -f --board vcu118 --target-flash primary --bitstream my_design.mcs
      • openFPGALoader -f --board vcu118 --target-flash secondary --secondary-bitstream my_data
    • Before each flash access in the Xilinx class, the correct USERx instruction is set to be used depending on the flash chip being targeted.

I've tested the following configurations with the boards that I have access to right now:

Board Load RAM Load Primary Flash Load Secondary Flash Load Both Flashes
VCU118 --board vcu118 --bitstream xxx --board vcu118 -f --target-flash primary --bitstream xxx --board vcu118 -f --target-flash secondary --bitstream xxx --board vcu118 -f --target-flash both --bitstream xxx --secondary-bitstream yyy
Arty A7 100T --board arty_a7_100t --bitstream xxx --board arty_a7_100t -f --bitstream xxx NA NA

Here's the branch with the full working version: https://github.com/barbedo/openFPGALoader/tree/vcu118-flash

PRs

I tried my best to create non-dependent PRs. Only the last one will depend on the other ones.

@trabucayre
Copy link
Owner

Great Work!
I'll try to apply PRs in chronological order or when there is no discussions remarks about content.
Thanks!

@barbedo
Copy link
Contributor Author

barbedo commented Feb 9, 2023

Everything to support the VCU118 is now merged. Thanks for everything!

I'll just keep this issue open until I add the missing documentation on doc/xilinx.rst

@barbedo
Copy link
Contributor Author

barbedo commented Feb 14, 2023

Well, I think that's all for now, so closing this issue.

Thanks a lot!

@barbedo barbedo closed this as completed Feb 14, 2023
@trabucayre
Copy link
Owner

Thanks for your contribution too!

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