Forum Discussion

fa_fpga_enthusiast's avatar
fa_fpga_enthusiast
Icon for Occasional Contributor rankOccasional Contributor
2 years ago

Exploring why GSFI IP Core repeats sending command and address for each 4-byte data in Page Program

Dear Intel Support Team,

We're working on two projects to communicate with Micron Flash Memory. The first one called the SPI project, uses the SPI 4-wire IP core and SPI driver. In the second project, known as the GSFI project, we're using the Generic Serial Flash Interface IP Core with the GSFI HAL driver. The protocol used in the GSFI project is Standard SPI.

In the SPI project, when we use the alt_avalon_spi_command() function to write a page of Flash memory, everything goes smoothly. The Chip-Select signal goes low, then we send the Page Program command, address, and data. Each byte of data is sent to the flash memory one at a time.

But in the GSFI project, when we use the intel_gsfi_write_block() function to write a page in the Flash memory, things are a bit different. For every 4-byte data segment, the GSFI core first sends a Write Enable command. Then it sends the Page Program command, address, and the 4-byte data. After that, it checks the Status Register. This process repeats for each 4-byte segment, creating a lot of overhead.

We're looking for help in understanding why the GSFI core behaves differently compared to the simpler SPI method used in the SPI project. In fact, we are wondering why GSFI IP Core sends the Page Program command and address for each 4-byte data, instead of sending data as a burst, as explained above.

Note: We're using Intel Quartus Prime Pro Edition on Agilex 7 SoC.

Memory

18 Replies

  • fa_fpga_enthusiast's avatar
    fa_fpga_enthusiast
    Icon for Occasional Contributor rankOccasional Contributor
    2 years ago

    Hi Aik Eu,

    Thanks for the reply!

    We're employing the intel_gsfi_write_block() function, and during simulation, the value of burst count is 0x01 which is an incorrect value. The write length corresponds to a page's length (256 bytes) in our design.

    This is how we are using the function:

    intel_gsfi_write_block(flash_dev, sector, address, (const void *) src_ptr, num_of_bytes);

    The value of num_of_bytes is 256.

    Is there a method to enable burst writes using the intel_gsfi_write_block() function? Do we have control over the burst count value using the provided Intel HAL Driver?


    Note: The snapshot of the simulation is attached here.

    Best Regards

  • fa_fpga_enthusiast's avatar
    fa_fpga_enthusiast
    Icon for Occasional Contributor rankOccasional Contributor
    2 years ago

    Hi Aik Eu,

    Thank you very much for your response.

    We utilize the GSFI IP Core within the platform designer, thus, the management of burst count should be handled by the Platform Designer itself (NIOS II processor and the mm_internconnet). However, based on the previous response, it seems we may need to incorporate a wrapper for the GSFI IP core to address the burst count issue. Can you please verify this interpretation?

    The GSFI IP core behaves consistently for both read and write commands. Specifically, it transmits the command and address for each 4-byte read/write data. Furthermore, the burst count is determined by the length argument in the read/write commands:

    • When retrieving values from the Flash memory, we employ the intel_gsfi_read() HAL driver function, requiring the size/length of the read as an argument. Additionally, the size of the read is variable.
    • For writing values into the Flash memory, we utilize the intel_gsfi_write_block() HAL driver function. In our application, the size of writing is equal to the size of one page (256 bytes), thus, the length remains fixed in this scenario.

    The management of burst count is expected to be handled by the platform designer based on the read/write length. Adding a wrapper for the burst count correction might not be a simple task.

    Thank you.

  • fa_fpga_enthusiast's avatar
    fa_fpga_enthusiast
    Icon for Occasional Contributor rankOccasional Contributor
    2 years ago

    Hi Aik Eu,

    Thank you for the reply!


    According to the provided link, the GSFI IP Core doesn't support burst writing of 256-byte pages. It's important to note that the ASMI Parallel II Intel FPGA IP exclusively supports EPCQ, EPCQ-L, and EPCQ-A devices. In cases where third-party flash devices (like Micron Flash Memory) are employed, the recommended option is the Generic Serial Flash Interface Intel FPGA IP, as specified in the ASMI Parallel II Intel FPGA IP User Guide.

    Furthermore, the ASMII Parallel II IP Core isn't available in Quartus Prime Pro Edition, as we are working with Agilex 7 FPGA.

    For optimal performance in SPI mode, we can utilize the SPI 4-wire IP Core instead of the GSFI IP Core. However, how can we achieve the best performance when operating in quad mode?

    Thanks.

  • fa_fpga_enthusiast's avatar
    fa_fpga_enthusiast
    Icon for Occasional Contributor rankOccasional Contributor
    2 years ago

    Hi Aik Eu,

    Thanks for the reply!

    Based on the "Generic Quad SPI Controller II Core Revision History", Generic Quad SPI Controller II Core supports "Intel Agilex 7" product started from Quartus Prime version 23.1. However, even though we're using Quartus Prime Pro version 23.4.0, we're unable to locate this IP core in the IP catalog and Platform Designer. Can you assist us with this issue?

    Thanks.