This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM62L: AM62L OSPI Write Performance

Part Number: AM62L

Hello.
 
We have connected MRAM to the OSPI(as Quad-SPI) of the AM62L and are measuring the read and write performance.
The PSDK is using version 11.00.15.05.
I am checking how much the performance improves when changing the OSPI clock frequency(OSPI_CLK) to 25MHz, 50MHz, and 100MHz.
 
When performing a 512KB full area read using the dd command, the read time decreases proportionally with the frequency.(25MHz: 43ms, 50MHz: 20ms, 100MHz: 8ms)
 
However, in the case of writing, the writing time becomes slightly shorter according to the frequency, but it is not as short as the read time. (25MHz: 127ms, 50MHz: 104ms, 100MHz: 98ms)
 
Looking at the waveform during writing, the write operation is performed in blocks of 1 block (256 Bytes) each, and there is a waiting time where CS is deasserted after each write completion.
When looking at the writing time per block, it decreases in proportion to the frequency.
 
On the other hand, the waiting time while CS is deasserted does not shorten in proportion to the frequency. 
 
It is considered that the write time has not been shortened by this waiting time.
What is this waiting time during deassertion waiting for?
And is it possible to reduce this waiting time?
Additionally, the cdns,tshsl-ns time set in the device tree is on the order of nanoseconds, which is considered not to be dominant.
 
Best Regards, 
Takayuki
  • I'm checking with HW team on the write performance observation, and will get back to you.
    Best,
    -Hong

  • Hello, Hong-san.

    Thank you for your reply.

    Could you please update me on the progress?

    Best regards,

    Takayuki

  • Hello Takayuki-san,

    For ospi-nor, read performance is generally scalable proportionally with the interface clock, but on write, while you can speed up the command and data transfer phases by increasing the clock frequency, the actual programming time remains constant. This is why NOR flash write performance doesn't scale linearly with clock frequency beyond a certain point.

    Are you using the Linux kernel driver on the specific MRAM device? or you're using the generic Linux kernel cadence qspi-nor driver?

    If the generic qspi-nor driver is used, kernel drive might poll the busy signal or bit, but MRAM doesn't have busy signal or bit on write. That may explain the MRAM write performance vs the clock frequency you observed on your testing.

    Best,
    -Hong

  • Hello Hong-san,

    Thank you for the reply.

    We're using the modified generic cadence qspi-nor driver.

    Is it possible to stop the busy signal or bit polling to reduce the write time?

    Best Regards,

    Takayuki

  • Hello Takayuki-san,

    We don't have the HW setup connecting the MRAM device with the OSPI controller.

    I'd recommend getting in touch with the MRAM device vendor on feasibility & how to adapt spi-cadence-quadspi.c driver to improve the write performance on the MRAM device in response to the scaled clock frequency on your board.

    Best,
    -Hong