• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 1168 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.

TMS320C6657: Understanding the UPP Interface and the EMIF16 Interface

joe lindula
Mastermind 6930 points
Part Number: TMS320C6657

Hello, I am looking at the TMS320C6657 on a possible future design. I was anxious to learn about the UPP interface I had hopes of using it to interface with an FPGA. However, after looking at the datasheet I find out that some of the UPP pins serve as EMIF16 pins. I was hoping that they would be separate interfaces. So with this, what are the limitation of this UPP/EMIF16 interface? I was hoping that I could use the UPP as a sole interface with an FPGA. Does it mean that I would use the EMIF16 for booting the processor and then after booting the UPP could be used to interface with the FPGA? 

If this does not sound like a good application for the UPP please let me know. I do plan to use one of the SPI and SRIO channels to interface with the FPGA.

Thank you,

Joe

  • 0
    TI__Mastermind 30110 points

    Hi Joe,

    Let me loop in a colleague more familiar with UPP to chime in on its use with an FPGA.

    UPP and EMIF16 are muxed on this device.

    During the application execution, you must select either one or the other with the PIN_CONTROL_1 register...

    8.3.21 Pin Control 1 (PIN_CONTROL_1) Register
    UPP_EMIF_MUX
    • 0 = EMIF16 pins enabled
    • 1 = uPP pins enabled

    The device can boot from EMIF and then switch to UPP. The EMIF chip selects are not muxed with UPP, so there is no concern about your EMIF device while using the UPP

    You could boot from any other peripheral from the below list also.

    Device boot mode:

    • 0 = EMIF16 / UART / No Boot
    • 1 = Serial Rapid I/O
    • 2 = Ethernet (SGMII)
    • 3 = NAND
    • 4 = PCIe
    • 5 = I2C
    • 6 = SPI
    • 7 = HyperLink

    EMIF16 / UPP muxed pins...

    Regards,
    Mark

  • 0 in reply to Mark M
    Mastermind 6930 points
    Mark,

    HI, so let me run this by you, after I boot from NAND I can use the UPP interface for FPGA and also use the EMIF16 interface for User Flash memory, is that correct?

    Thanks,
    Joe
  • 0 in reply to joe lindula
    TI__Mastermind 42545 points

    Hi Joe,

    I think you are suggesting that you would like to connect your interface to both the FPGA and the NAND device, toggling the control pin between UPP mode and EMIF16 mode. That was not the intention when we muxed the EMIF16 with the UPP. All testing of the device has been performed using those pin defined as either UPP or EMIF16. We don't have any data on how the device will operate when that mode is toggled back and forth during operation. 

    Regards, Bill

  • 0 in reply to Bill Taboada
    Mastermind 6930 points
    Bill,

    So it sounds like if you want to use the UPP then you must boot via SPI or I2C which I think is slow. Is NAND boot over the EMIF16 bus?

    Thanks,
    Joe
  • 0 in reply to joe lindula
    TI__Mastermind 42545 points
    HI Joe,
    NAND boot would use the EMIF16 interface. SPI can operate at very fast speeds. The best option would be to create a two stage boot using SPI. The first stage would load a small boot loader program read from the SPI memory with the sole function of initializing device and increasing the speed of the SPI interface. The second stage could then quickly load your application.
    Regards, Bill
  • 0 in reply to Bill Taboada
    Mastermind 6930 points
    Thanks Bill! When I get to that point I may ask for your help. Have a good day.