New Contributor
Regular ContributorHi 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
New ContributorThanks 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
