Generic Quad SPI Controller II IP questions

[Terry6]

I have several questions about the Generic Quad SPI Controller II IP. The only documentation I can find on this core is a small section in the Embedded Peripherals User Guide. Is there a document that describes the interface to this core in more detail?
I've provided feedback on the Embedded Peripherals User Guide as part of this effort. The Tech Doc support individual requested that I include this number in a technical support case: 15012903294

Setup: Intel Cyclone 10 GX, Micron MT25QU256 PROM, Quartus 22.3, IP version 20.1.2

Questions/issues that I've encountered during the design and simulation phase:

1. The documentation describes the avl_mem_byteenable control as “during bursting mode, byteenable bus bit will be all high always, 4’b1111”. Since the Avalon Memory interface to the core is always bursting, it seems like the byteenable bits should always be 4’b1111. If so, how do you perform a single-byte write to the PROM? I’ve tried doing single and multicycle transactions on the Avalon Memory interface in simulation but the byte enables seem to have no effect and the entire 4-byte DWord is written to the PROM regardless of the state of the byteenable controls.
2. The Generic Quad SPI Controller II IP core includes internal hardware that takes care of asserting the Write Enable Latch (WEL) bit within the PROM before performing memory write transactions. This automated WEL control is very helpful because it prevents the user from having to assert the WEL bit manually. My concern is that IP core also supports performing Sector Erase, Sector Protect, and Bulk Erase operations which all require that this WEL bit be asserted, however, the IP core does not automatically assert the WEL bit for these operations. When performing these operations the user must manually assert the WEL bit by inserting a write transaction before performing the desired operation.
   This strange behavior is not documented in the IP core documentation. I only discovered this interaction when attempting to perform these operations in simulation. Do I understand this behavior correctly?
3. The FLASH_RD_STATUS and FLASH_RD_RDID registers have identical behavior descriptions in Table 232. Both register claim to “store the read back data”, however, based on simulations, they have very different behavior. When reading the FLASH_RD_STATUS register the read contents are provided on the Avalon CSR bus immediately. In this case I think “store the read back data” means that the data is returned and the Avalon CSR read transaction is terminated.

   When reading the FLASH_RD_RDID register it seems like this causes the PROM’s Device ID read data to be latched into the DEVICE_ID_DATA_x registers which can then be read over the Avalon CSR bus in subsequent transactions. This behavior is not documented, but seems important for the user to understand.

4. The EPCQ_FLAG_STATUS register pertains to non-EPCQ devices like our Micron MT25QU256. Ignoring the EPCQ name in the register, there are comments in the documentation about writing this register to clear flag status bits, however, there’s no indication of which flag status bits need to be cleared manually and which are cleared automatically. Based on simulations, I think I’ve figured out how to interact with the register, but I’m inferring a lot about the behavior and am not positive in my conclusions.

5. The IP interface clock “clk” defined in Table 231 includes a description indicating “up to 40MHz input clock”. This clock drives the IP core logic and is used for the PROM interface as well.
   This 40MHz limit seems wrong as recent PROMs such as the Micron MT25QU256 PROM are capable of running at up to 166 MHz.
   The Micron simulation model I have for the MT25QU256 reports timing violations, so I’ve tried running the IP core clock at higher rates with mixed results. I get timing violations at frequencies >= 125MHz, but don’t see any timing errors when running the interface at 100MHz.
   Again, I think the 100MHz clock I’m feeding to the IP core is acceptable based on my simulation results, but I’m definitely not confident based on the clk description in the document.

Any help with these issues would be greatly appreciated.

Thanks,
Terry

[JingyangTeh]

Hi Terry

Thank you for reaching out to us.

Please find my response below

1. The byte enable has a bit of a different behaviour. Maybe an example will be much easier to understand:

e.g. When trying to write a data of 0x78563412 

with byte_enable 0x0001 : The written data will be 0x12121212

with byte_enable 0x0010 : The written data will be 0x34343434

with byte_enable 0x0100 : The written data will be 0x56565656

with byte_enable 0x1000 : The written data will be 0x78787878

2. I do not have an answer right now, but let me get back to you in a later time.

3. You are right on the behaviour and understand that this information is lacking on the documentation. We will add this into the document.

4. You could refer to the EPCQ Device Datasheet for the flag status description (Table 27):

https://www.mouser.com/datasheet/2/612/cfg_cf52012-1301744.pdf

5. From the SME the limitation of 40Mhz is due to some legacy issue of the design. For operation that exceed 40Mhz, you could try using the GSFI 

https://www.intel.com/content/www/us/en/docs/programmable/683419/22-2-20-2-1/user-guide.html

Regards

Jingyang, Teh

[Terry6]

Thanks for the response which clears up several confusing aspects.

You mentioned the GSFI IP core as an alternative to the Generic Quad SPI Controller II core that I'm currently using. I had assumed that the Generic Quad SPI Controller II core was a better/newer solution based on the naming conventions. Is the GSFI IP a better/newer IP core to target?

Re question 5: I'm not convinced about the 40MHz limitation based on my simulation and FPGA build results. When simulating, the Micron PROM models include timing checks to confirm that interface timing requirements are not violated. I don't see any timing violation warnings. Additionally, the core does not have any timing violations when clocking at 100MHz when I build the FPGA design.

Thanks again!

Terry

[JingyangTeh]

Hi Terry

Sorry for the late reply.

Justo get back to you on point 2. Regarding the WEL Control.

Which IP Version you are using currently? There was a bug fix for this issue after the 19.1 IP update.

Could you try it out with the version 19.1 or above?

The Generic SPI Controller II IP gives more flexibility to the user in terms of the setting manipulation where as the Generic Quad SPI Controller II is not.

The timing parameters of above 40MHZ are not recommended for the Generic SPI Controller II IP.

Regards

Jingyang, Teh

[Terry6]

Hi, 

Regarding question #2, I'm using IP version 20.1.2 which should have the bug fix you're referring to. 

Setup: Intel Cyclone 10 GX, Micron MT25QU256 PROM, Quartus 22.3, IP version 20.1.2

My sims show that with the MT25QU256 PROM that the WEL is not asserted for Sector Protect, Sector Erase, or Bulk Erase operations.

Maybe this is a situation in which the IP core WEL behavior supports the Intel EPCQ devices but does not support the Micron MT25QU256 device operations in the above cases? That seems strange because both devices require WEL to be asserted for these operations.

Thanks again,
Terry

[JingyangTeh]

Hi Terry

Apologies for the late reply.

I will get back to you as soon as possible.

Regards

Jingyang, Teh

[JingyangTeh]

Hi

Sorry for the confusion. Yes you are right. Thanks for raising this up to us.

The behavior is indeed that WEL needs to be manually toggled for Sector Protect, Sector Erase and Bulk Erase.

This behavior will be documented in the document.

We are in the midst of doing the documentation update.

Regards

Jingyang, Teh

[Terry6]

Thanks for the update and I'm glad that our findings align.

I would recommend that Intel re-investigate the clock rate (Question #5 in the original post). My sims and FPGA builds show that the design and PROM interface meet timing and behave as expected when the clock rate is 100MHz. Maybe this is only true for Micron PROMs because I have not simulated with Intel PROMs.

Please consider this support request accepted and closed and thanks again.

Terry

[JingyangTeh]

Hi Terry

Thank you very much for your valuable feedback!

I have created an internal tracking case and will see through that it is closed for the remaining points.

For point 5, it is not guarantee for some devices that it might work for clock speed greater than 40Mhz.

We will add a note to the documentation as well that the guaranteed operating speed is up till 40Mhz.

Since this thread been resolve, I shall set this thread to close pending. If you still need further assistance, you are welcome reopen this thread within 20days or open a new thread, some one will be right with you. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

If you happened to close this thread you might receive a survey. If you think you would rank your support experience less than 10 out of 10, please allow me to correct it before closing or if the problem can’t be corrected, please let me know the cause so that I may improve your future service experience.

Regards

Jingyang, Teh