• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 369 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.

OMAP-L138: SDK, IPC, Evaluation, etc. Recommendations?

Go Bravos
Expert 6090 points
Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAPL138B-EP, SYSBIOS, OMAPL138

Team,

A number of questions for you:

  1. What is the advice for teams using C6000 code generation tools (CGT) v7.4.x for C6000 DSP cores like the C674x core on the OMAP-L138?  Should we consider moving onto to C6000 CGT v8.x?
  2. What replacement devices are available that are comparable to the OMAPL138B-EP?
    1. How can we maximize compatibility of our existing software with a new device?
    2. If we don’t really care about software  compatibility and don’t mind porting software to a new device, what devices would TI recommend?
  3. If we want to upgrade from the OMAPL138B-EP to a newer device, what upgrade paths should we consider?
      1. What higher performance devices are available in an enhanced plastic (EP) version?
  4. Linux SDK for OMAP-L138
    1. What is the roadmap for the Linux software development kit (SDK) for the OMAP-L138 low cost development kit (LCDK)? How long will the OMAP-L138 be included in updates?
    2. What processor(s) and evaluation board(s) would you recommend for the most feature-rich experience with the Linux SDK?
  5. TI-RTOS SDK for OMAP-L138
    1. What is the roadmap for the TI-RTOS SDK?  How long will the OMAP-L138 be included in updates?
    2. What processor(s) and evaluation board(s) would you recommend for the most feature-rich experience with the TI-RTOS SDK?
  6. Interprocessor Communication (IPC)
    1. I have come across an some examples for IPC between the ARM core and DSP core on the OMAP-L138 over the past few years. Are there any new examples worth exploring?
    2. What processor(s) and evaluation board(s) would you recommend for the most feature-rich experience with IPC functionality between heterogeneous processor cores?
  7. Multicore DSP devices
    1. Are there recommendations for helping a team decide to use a multicore DSP device with homogeneous cores?
    2. What software development frameworks have emerged for multicore DSPs? Is OpenMP still a thing?

  • 0
    TI__Guru** 116170 points

    Let me respond to the software questions here and I will let product marketing comment on the OMAPL138-EP replacement.

    Go Bravos said:
    What is the advice for teams using C6000 code generation tools (CGT) v7.4.x for C6000 DSP cores like the C674x core on the OMAP-L138?  Should we consider moving onto to C6000 CGT v8.x?

    The major update moving from CGT 7.4.x to CGT 8.x that you need to understand is that CGT 8.x drops support for TI COFF binary format and only supports ELF binary format. COFF and CGT 8.x adds support for OpenMP extensions. CGT 7.4 supported both COFF and ELF binary formats to allow customers the option to migrate from legacy COFF To ELF binary format. If you are working with a software stack that is built using COFF binary format for example DSP BIOS based stack or have thrid party binary libraries that are in COFF format then we would recommend using CGT 7.4. 

    Most of the newer software that TI provides in the RTOS SDK software is based on SYSBIOS And bare-metal code and libraries that are supported in ELF binary format and is packaged with the CGT 8.x compiler. We also provide several application notes to help with the COFF to ELF migration in case you decide to migrate your legacy COFF code base to ELF format.

    Go Bravos said:
    • Linux SDK for OMAP-L138
      1. What is the roadmap for the Linux software development kit (SDK) for the OMAP-L138 low cost development kit (LCDK)? How long will the OMAP-L138 be included in updates?
      2. What processor(s) and evaluation board(s) would you recommend for the most feature-rich experience with the Linux SDK?

    OMAPL138 has been included in the PRocessor SDK Linux releases during every quarterly release for the last 3 years. We are currently supporting the device on the 4.19 (2019 LTS version). We consider the Processor SDK Linux offering to be mature and don`t expect any major updates. 

    Given the 2019 LTS version is planned to be supported till 2024 by the community,(as per kernel.org) we are planning to keep the device on 2019 LTS in the near future until 1H21 and we will assess the needs/demand for an update to migrate to newer LTS

    While OMAPL138 LCDK does have similar user experience to all the other processors supported in the Linux SDK, some of processors that have an option for display and other connectivity options offers a richer Linux SDK experience. You can can look at AM57x GP EVM or IDK  or AM335x GP EVM for richer linux experience or based on your usecase also look at out 64 bit Processor platforms like TDA4 EVM and AM65x EVMs based on the feature set and performance requirements for your application.

    Go Bravos said:
    Interprocessor Communication (IPC)
    1. I have come across an some examples for IPC between the ARM core and DSP core on the OMAP-L138 over the past few years. Are there any new examples worth exploring?
    2. What processor(s) and evaluation board(s) would you recommend for the most feature-rich experience with IPC functionality between heterogeneous processor cores?

    The IPC mechanism has evolved quite a bit over the years and so I will need a little more information on what you mean by feature rich experience with IPC. The IPC mechanism on OMAPL138 has migrated from DSPLINK (in older DVSDK) to SYSLINK  and is now in sync with the latest IPC3.x - remoteproc interface supported on all newer devices.  We don`t plan to support any newer IPC mechanism on OMAPL138 beyond IPC 3.x and remoteproc interface.

    On newer devices like AM572x and AM571x, we also support IPC mechanisms like OpenCL which is an API based interface that abstracts underlying IPC functionality for Linux users who don`t want to program the DSP. You may want to review the multiple IPC mechanisms that we offer in the article provided in the URL below:

    http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_IPC.html#multiple-ways-of-arm-dsp-communication  

    Go Bravos said:
    Multicore DSP devices
    1. Are there recommendations for helping a team decide to use a multicore DSP device with homogeneous cores?
    2. What software development frameworks have emerged for multicore DSPs? Is OpenMP still a thing

    The decision to select a multi core DSP is driven by the amount of DSP performance required by the application and if there is a way to perform parallel compute and leverage the advantage of having common memory and peripheral interface that will exist on the same die. The TI multicore processor selection tool can be used as a guiding tool that will provide you part number options based on the DSP performance expected and the target peripheral set:

    https://www.ti.com/processors/digital-signal-processors/c6000-floating-point-dsp/products.html

    Within the software development packages and SDKs that we support we do offer support for standard SYSBIOS, IPC, DSP libraries and platform development kit for multicore DSP platforms similar to what we offer on OMAPL138 devices. In addition to this we do have support for TI OpenMP-DSP in the SDK

    http://downloads.ti.com/mctools/esd/docs/openmp-dsp/intro.html