• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 30 subscribers
  • Views 544 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DLP3021-Q1: SPI Flash Writing Method in FPGA Architecture

Johns Chuang
Intellectual 300 points
Part Number: DLP3021-Q1

Tool/software:

Dear Team,

In our research on FPGA architecture, we have a question we'd like to ask.

We are exploring ways to accelerate the write speed of NOR Flash.

However, based on the circuit diagram in our FPGA architecture, we noticed that writing to Flash is done using Standard SPI, while reading is performed using Octal SPI.

Why not use Octal SPI for programming the Flash? By using a switch IC to toggle between Octal SPI being used for Flash-to-FPGA or PC-to-Flash communication, would it be possible to achieve a faster write speed when flashing the .img file?

Thank you for your assistance.

Best,

Johns

  • 0
    TI__Prodigy 585 points

    Hi Johns,
    Thank you for reaching out to us.
    Let me get back to you on the same.

    Regards,
    Siddharth

  • 0
    TI__Prodigy 585 points

    Hello Johns,
    Thank you for your patience.

    Yes, the flash (MT35XU02GCBA1G12-0AAT) used in DLP3021-Q1 has Octal Input/Output capability (so ideally, we can use Octal SPI protocol to both read and write the flash).

    However, I believe the limitation is coming from the USB-to-SPI adapter we use to write from PC, which can only work for the Standard SPI protocol.
    Also, the Cheetah USB-to-SPI adapter or the FTDI USB-to-SPI cable only work for the standard SPI protocol. 

    Due to this limitation, if you see the Reference design schematic:

    In Box 1, the MUX is used to reuse only the first 2 Flash data lines - Flash DQ0 and Flash DQ1 either for connecting it to the FPGA or to the MISO and MOSI data lines coming from the USB-to-SPI adapter.

    The FPGA (refer box 2) can use all the Flash DQ0 to DQ7 (all 8 data lines) because it has the sufficient I/O pins to do that.

    Since the USB-to-SPI adapter only supports Standard SPI with only 2 data lines, the MUX is designed that way.

    I believe, if an Octal SPI supporting USB -to-SPI adapter is used, and an appropriate 8:1 MUX is used we can achieve PC to Flash write operation faster.


    Regards,
    Siddharth

  • 0 in reply to Siddharth Choudhary
    Intellectual 300 points

    Hi Siddharth,

    Thank you for your confirmation. I have a follow-up question:

    Is the programming speed ultimately limited by the NOR Flash program time?

    The NOR Flash program speed is 256 Bytes / 0.18 ms ≒ 1.1 Mbps.

    Even with 16MHz Standard SPI, the system still has to wait for the NOR Flash programming at 1.1 Mbps, so using a faster OSPI wouldn’t make a difference, right?

    Could you confirm if my understanding is correct? (Theoretically, ignoring Erase and Verify time.)

    Best,

    Johns

  • 0 in reply to Johns Chuang
    TI__Guru 54605 points

    Hello Johns,

    I have informed Siddharth that you have a follow-up question.  He should get back to you in the next couple of days.

    Fizix

  • 0 in reply to Fizix
    Intellectual 300 points

    Hi Fizix~ Thanks for your help!

  • 0 in reply to Johns Chuang
    TI__Expert 6720 points

    Hi Johns,

    Johns Chuang said:

    Is the programming speed ultimately limited by the NOR Flash program time?

    I wouldn't quite say that the NOR flash is the limiting factor because it would differ from one design to another.

    What Siddharth is saying above is that, in the EVM's case, the USB-to-SPI adapter is the bottleneck.

    In someone else's design, they may use a different SPI interface that will allow octal SPI.

    Are you able to screenshot where you found that the NOR flash program speed is 256 Bytes / 0.18 ms? I don't think I found that information in the datasheet.

    Regards,
    Michael Ly

  • 0 in reply to Michael Ly
    Intellectual 300 points

    Hi Michael,

    Sorry, I mistyped. The program time should be 256By / 1.8ms. Since the USB-to-SPI speed seems much faster than the data in Table 48, I’d like to confirm with you: regardless of how I change the transmission method, will it ultimately still be limited by the NOR Flash's program time and erase time?

    Thank you for your assistance.

    Best,

    Johns

  • 0 in reply to Johns Chuang
    TI__Expert 6720 points

    Johns,

    Sorry for the delay. Let me talk to another expert in the meantime just to be sure.

    Regards,

    Michael Ly

  • 0 in reply to Michael Ly
    TI__Expert 6720 points

    Johns,

    Sorry again for the delay. I've been busy with some internal matters and another pressing issue, but I wanted to post this update to let you know I am still thinking about this ticket. I will be asking for additional help tomorrow.

    Regards,
    Michael Ly

  • 0 in reply to Michael Ly
    Intellectual 300 points

    Hi Michael,

    Thanks for your help. Looking forward to good news.
    Best,
    Johns
  • +1 in reply to Johns Chuang
    TI__Prodigy 585 points

    Hello Johns,
    Pardon for the long delay,
    The answer to your question is not straightforward.
    For a NOR flash, data transmission from the host device(PC) via SPI and the actual programming of data into the memory are two separate processes.

    Refer the device block diagram(page 9) in the data sheet.

    For the first step, the flash device has a 256 byte data buffer in which the data is initially transferred from the PC and stored temporarily.

    Next this data is now programmed from the 256 byte buffer to the actual memory. The timing data you shared before -> 256 bytes in 1.8 ms is for this second step.

    Moreover, when this programming from the buffer to flash memory is happening, the data transmission from the host remains on hold (in order to not overwrite the contents of the buffer).

    So technically, since there are two separate steps, if you switch from standard SPI to quad/Octal SPI there would be a slight decrease in the time taken. (it will take slightly less time to transfer data from the PC to the data buffer).

    However, I believe the real bottleneck is still the second step as you mentioned since it takes the majority of time during the whole process of WRITE operation.

    And so, from what I understand, upgrading from the standard SPI to quad/Octal SPI protocol would NOT have a significant time improvement for your application.