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.

AM6412: OSPI with 2 Devices

Part Number: AM6412

Hello Support,

I would like to support 2 devices on the AM64x OSPI interface:

- boot flash

and
- MRAM.

Boot flash at CS0, the MRAM at CS1.

I would connect both devices completely parallel to the signals.
DQS from flash/MRAM to CPU via 22R and then a Y-distribution.
The rest of the data signals would be connected in parallel.
Flash on top, MRAM on bottom to keep the stubs as short as possible.


Question 1: Would this be possible? In principle the OSPI should be accessible for the MRAM during operation, right?

Question2: Is there a PCB routing guideline from TI, which length the DQS signal must be routed from the Flash/MRAM to the CPU? Same length as the data signals?
And what is the length to pin LBCLK0?

Regards

Daniel

  • Hello Daniel Sommerfeldt

    Question 1: Would this be possible? In principle the OSPI should be accessible for the MRAM during operation, right?

    Please refer below assessment on using multiple devices on the QSPI interface. This is not a use case that has been tested.

    Based on your questions, it seems you understand there are signal integrity issues that must be considered when attaching multiple devices. The data transfer rate can be reduced to allow time for the data signals to settle, but attaching a single clock signal to multiple devices is problematic.

    It is not possible to distribute a single clock to multiple devices via fly-by topology without the risk of producing internal glitches on any device connected in the middle of the clock signal trace even if connected without creating stubs. It may be possible to minimize this concern by using a T topology, but it must be implemented properly and verified using signal integrity simulations. The best way is to ensure there are no clocking issues is insert a 1:n clock buffer in the clock signal path, which inserts significant delay and reduces the data transfer rates for the entire interface. In my opinion, the only way to reliably achieve the data transfer rates wanted for this interface is to limit the connectivity options to a single external memory device with point to point connections.

    A single clock signal should never be routed to more than one device. It is not a good design practice to connect any devices in the middle of a clock signal PCB trace (transmission line). Let me explain with an example. Let’s assume the QSPI_CLK output buffer has a source impedance of approximately 50 ohms and the characteristic impedance of the clock PCB trace is 50 ohms. The source end of the transmission line will have a mid-supply step function on each low to high and high to low transition when the output toggles. This occurs because the output buffer source impedance and transmission line impedance creates a voltage divider. Since the impedance is the same, the voltage will step to approximately the IO supply voltage divided by 2. This mid-supply voltage will propagate to the end of the transmission line where it encounters a high impedance load. This produces a in phase reflection equal to the incident voltage transition. This reflection is completely attenuated once it returns to the source since the output buffer source impedance matches the transmission line impedance. The net result is, the input buffer (QSPI_RCLK) connected to the far end of the transmission line will see a full voltage transition. However, the device connected mid-line (QSPI device) will see the mid-supply voltage step, which is very likely to create a glitch on its internal clock since the signal pauses near the switching threshold of its input buffer.

    It may be possible for the customer to implement a T topology with very short signal traces on each branch of the T and make this work, but it is risky. None of the signal integrity effects associated with multiple devices connected to the interface were considered during OSPI timing closure.

    Regards,

    Sreenivasa

  • Hello Daniel Sommerfeldt

    Question2: Is there a PCB routing guideline from TI, which length the DQS signal must be routed from the Flash/MRAM to the CPU? Same length as the data signals?
    And what is the length to pin LBCLK0?

    We have a section in the datasheet that could be. referenced.

    9.2.2 OSPI/QSPI/SPI Board Design and Layout Guidelines.

    The recommendation is to connect the OSPI interface as a point to point interface.

    Regards,

    Sreenivasa

  • Hello, but generell it is possible to boot via OSPI in Octal mode from boot flash and during operation, the OSPI can be used in Quad mode for an MRAM?

  • Hello Daniel Sommerfeldt

    Thank you for the inputs.

    The challenges associated with using multiple devices have been detailed above.

    In terms of being able to interface to 2 devices, your assessment seems correct.

    Regards

    Sreenivasa

  • Hi, I have strong power-up time requirements, that means I have to boot up the CPU as fast as possible. Therefore I would like to use a OSPI Boot Flash. Do I have to use a OSPI Flash that comes out of reset as a x8 device if the bootpins of the CPU are configured to OSPI or can a Boot Flash used that comes out of reset as x1 and can be switched to x8? Problem is that the initial configuration must be programed via SPI (x1) to the Flash.

    Or do I have to set the boot pins to SPI (x1) and the CPU changes the interface to x8 during the first reads?

    Regards

  • Or how do you program the OSPI Boot Flash on the Eval Board of the AM64xx reference circuit?

  • Hello Daniel Sommerfeldt

    Hi, I have strong power-up time requirements, that means I have to boot up the CPU as fast as possible. Therefore I would like to use a OSPI Boot Flash. Do I have to use a OSPI Flash that comes out of reset as a x8 device if the bootpins of the CPU are configured to OSPI or can a Boot Flash used that comes out of reset as x1 and can be switched to x8? Problem is that the initial configuration must be programed via SPI (x1) to the Flash.

    Or do I have to set the boot pins to SPI (x1) and the CPU changes the interface to x8 during the first reads?

    Thank you for the query.

    We typically recommend discussing one topic in a thread that relates to the title. This in turn helps other users.

    Would you mind starting a thread with the title including the xSPI bootmode 

    Regards,

    Sreenivasa