Generic Quad SPI Controller II IP questions

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