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

SYS/BIOS multicore development ... suggestions how to start?

Chris Jagielski
Expert 1630 points
Other Parts Discussed in Thread: SYSBIOS

Hello everyone,

I am a little confused where to start with my multicore project.  Already I have created basic projects with SYS/BIOS, IPC, etc.  Today I read the Multicore programming Guide & MAD Utils User's Guide.  I have general ideas of what I want, but not exactly how to get there.

(FYI:  My target is the Advantech 8681, which has 4x C6678 DSPs, so I will have 32 cores available to program.)
Right now, I'm confused and I want to start small.  I believe that I need separate *.out files loaded to each core.  The DSP cores will need to talk to each other a little (via IPC), but each core will basically be running its own separate algorithm.

Here's a graphic that shows, high level, what I NEED to do with my different algorithms (note there will be feedback too... I made this quickly for simplicity!).

How do I go about this? (Do I start modifying the multicore image processing demo project, removing the network/webpage features I don't need? start from scratch with a sys/bios IPC project? create a few unique IPC projects and integrate them with MAD?).

Some details....      When I'm done, I'll have 20+ different functions/algorithms, some that are independent "slaves", some that are "data flow model", but all of them will have some sort of dependencies (maybe timing, or maybe data they need from another algorithm, etc.).  Some functions will be lean (fast) and only run every once in a while as required, and other functions might require multiple cores (perhaps parts of my code will be paralleled by the OpenMP).  Is it easy to put each different algorithm on a separate DSP core?  Does this all make sense?

As you can tell, I am new with this and it is a huge design task for me; it is sure to be an iterative one!

Any and all suggestions are greatly appreciated.  Thank you!

  • 0
    TI__Mastermind 45025 points

    Hi Chris Jagielski,

    Are you using the MCSDK?

    If so, which version?

    Also, please specify the versions of SYS/BIOS and IPC.

    Steve

  • 0 in reply to Steven Connell
    Expert 1630 points

    Hi Steve, thanks for the response.  Yes - I am using the MSCDK.

    • CCS  5.4.0.00091
    • MCSDK  2.0.2.06
    • SYSBIOS  6.35.3.47 (IDE Client)
    • IPC  1.25.0.04

    Basically I'm very curious about some practical multicore best practices.  I need some sort of roadmap to start my development...

    does this make sense?

  • 0 in reply to Chris Jagielski
    TI__Mastermind 45025 points

    Chris,

    Thanks for providing those details.  I think that you will be best served by someone from the MCSDK team.  I've contacted them and asked for their help; you should hear back from them soon.

    Steve

  • 0 in reply to Steven Connell
    TI__Genius 9065 points

    Hello,

    If you are using DSPC-8681E, were you aware of this software and examples?

    http://software-dl.ti.com/sdoemb/sdoemb_public_sw/desktop_linux_sdk/latest/index_FDS.html

    best regards,

    David Zhou

  • 0 in reply to dzhou
    Expert 1630 points

    David,

    Thanks for this suggestion!  This is definitely sparking a few questions in my mind:

    1) Is the Desktop Linux SDK designed to run on all the cores, or on just 1 Master core (meaning SYS/BIOS runs on the "slaves")?

    2) I read the Wiki and it seems the Desktop Linux SDK is not an RTOS, can you help me understand the (high level) use cases for this package?

    3) For example, would I use SYS/BIOS or Desktop Linux SDK for the pipeline processing shown in my 1st post's graphic?  This would be a scenario where I need 6-8+ algorithms to run in parallel and to all pass along their output data every 10mSec.  (I will gladly expand on this if more details are needed to better answer me)

    FYI - my 8681 will be attached to a Linux host "in the field".  The host computer will be communicating with various black boxes (sensors), and my 8681 will be running the "intense" algorithms to process the received data.  I get new data every 10ms, which is why I first looked into SYS/BIOS and its many capabilities as an RTOS.

    I greatly appreciate all of your help so far!

  • 0 in reply to Chris Jagielski
    TI__Genius 9065 points

    1) please check the getting started guide and also development guide:

    http://processors.wiki.ti.com/index.php/Desktop-linux-sdk_01.00.00_Development_Guide

    You can run your application on any numbers of cores. It is up to the PCIe host to control the download, reset and run.

    2) please read the documents in wiki. There are two parts: the host and DSP.

    Host Processor Package includes the following modules

    • Buffer Manager
    • Mailbox
    • Download Manager
    • Contiguous Memory Driver
    • PCIe User Space Driver
    • Out of Box Demo application

    DSP Package includes the following modules

    • Mailbox
    • CCS Project to compile .out file
    • Demo application Source code to compile the .out file

    3) There are different ways to implementation and it is all technically feasible. I suggest you take a look at this package and try with the demos first.

     

  • 0 in reply to dzhou
    Expert 1630 points

    Thanks David.  These are good details.

     

    Can you help me understand - is it possible to load Desktop Linux SDK on Core 0, and load SYS/BIOS on cores 1-31, and have them all communicate?  This way Core 0 is Master, and it interfaces nicely with my host computer.  Then I can also have the great RTOS features of SYS/BIOS on the remaining cores, which I need.

    Has anybody done this before?

  • 0 in reply to Chris Jagielski
    TI__Genius 9065 points

    Hello Chris,

    Yes we have done this in MCSDK video with the DSP images running the DSP/BIOS and with the communication between the cores is through PCIE ( Global shared memory). MCSDK video is using Desktop Linux SDK already and you can find it here:

    http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk_video/latest/index_FDS.html

    Also on the DSPC-8681E, DSPS are daisy chained through SRIO interface. You can also use SRIO to communicate between DSPs by using the LLD (low layer driver) from MCSDK. We have not done that on DSPC-8681E but it is technically feasible.

    Let me know if this answers your question.

    regards,

    David

  • 0 in reply to dzhou
    Expert 1630 points

    David, Thanks.

    This http://processors.wiki.ti.com/index.php/File:Scheduler_Topology3.JPG looks like what I might want to do.

    I'll do some investigation into the video SDK, and post a new thread when I have other questions.

  • 0 in reply to dzhou
    Expert 1630 points

    dzhou said:

    Also on the DSPC-8681E, DSPs are daisy chained through SRIO interface. You can also use SRIO to communicate between DSPs by using the LLD (low layer driver) from MCSDK. We have not done that on DSPC-8681E but it is technically feasible.

    David,

    I'm asking the obvious questions here to make sure I have the correct understanding.

    1. Why would I want to communicate via SRIO?  Is it in order to have faster communication between the cores? (versus PCIe core-to-core, which would take longer).  Are there other reasons to do so?  Are there any tradeoffs?
    2. Can I use the SRIO IPC Transport?  Or are only the SRIO LLD's compatible with the MCSDK-Video?  (I thought MCSDK-Video was a hybrid of SYS/BIOS & Desktop Linux MCSDK, so now I'm confused if MCSDK-Video can use IPC at all).

    Let me know if this doesn't make sense.  Thanks again!!

  • 0 in reply to Chris Jagielski
    TI__Genius 9065 points

    Chris,

    1) If you use PCIE interface for host to DSPs or DSP or host and SRIO in between DSPs. You have more bandwidth. You can check throughput of each interface with literature #: SPRABK5. However, you can still go with PCIe for DSP to DSP communication for now.

    2) You can use SRIO IPC transport. MCSDK-VIDEO is an example application which was based on MCSDK and uses Desktop Linux MCSDK. I was pointing it out just for your references.

    I'd suggest you just go with PCIe for now. If you can get it working then think of using SRIO as part of further performance improvement.

    best regards,

    David Zhou

  • 0 in reply to dzhou
    Expert 1630 points

    Thanks David.  This makes sense, and is a good approach for my development.

  • 0 in reply to Chris Jagielski
    Expert 1630 points

    David,

    I have 4 threads here on e2e with no replies.  Three out of the four have to do with the Linux Desktop SDK.

     

    Can you help me get these answered, or directed to the correct person/forum?

    1. http://e2e.ti.com/support/embedded/bios/f/355/t/294621.aspx
    2. http://e2e.ti.com/support/embedded/bios/f/355/t/294347.aspx
    3. http://e2e.ti.com/support/embedded/bios/f/355/t/294168.aspx
    4. http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/293630.aspx
  • 0 in reply to Chris Jagielski
    TI__Genius 9065 points

    Chris,

    Thanks for bringing this to my attention. The issues you reported will be responded soon.

    best regards,

    David Zhou

  • 0 in reply to dzhou
    Expert 1630 points

    David, Thank you for helping me get my questions answered.

     

    Here I am curious about the Desktop Linux SDK, and want to double check something we briefly discussed earlier in this thread.

    Can the Desktop Linux SDK and SYS/BIOS both be used on the same DSP core?  For example, assume I have 1 c6678 device with 8 cores: could all of the 8 cores use both SYS/BIOS as an operating system (e.g. use IPC, HeapMem, etc.) and at the same time use the Desktop Linux SDK components (e.g. mailBox, bufMgr, etc.) also on all 8 cores?

    I'm just trying to understand how these two SDK's work together and see if I can "pick and choose" what parts of each SDK I want to use.  Thanks again, I hope this makes sense!

  • 0 in reply to Chris Jagielski
    TI__Genius 9065 points

    Please really take a closer look at filetestdemo example in Desktop linux SDK. It is using all the components you asked for already.

  • 0 in reply to dzhou
    Expert 1630 points

    I apologize if my question wasn't very clear.

    I guess I'm confused, because the filetestdemo example does not use SYS/BIOS.  Am I missing something here?

    It does not have a .cfg file, and the "RTSC" view in properties does not exist for this project.  I was assuming that meant the filetestdemo project did not use SYS/BIOS or IPC?

  • 0 in reply to Chris Jagielski
    TI__Genius 9065 points

    Chris,

    You are right filetest demo is not using DSP/BIOS, but you can start to add it.

    I believe MCSDK video is using DSP/BIOS on DSP side.

    regards,

    David

  • 0 in reply to dzhou
    TI__Expert 3715 points

    Chris,

    Can you please provide more details about how your system is partitioned between host and DSP? I assume that data I/O etc happens on host processor and you feed the raw data (over PCIe) for DSP processing. 

    Desktop Linux SDK contains the foundational components necessary to a) download the DSP and b) communicate between host and DSP via mailbox messaging and c) move data between host and DSP's DDR memory. The DSP side of filetestdemo is bare-metal (no BIOS/RTOS) for the sake of simplicity. Also, for the sake of simplicity, the host side application of filetestdemo is a single-threaded application where data I/O on host, moving of data to/from DSP and actual processing of data on DSP - all happen sequentially. 

    In more real world applications, the host side would be multi-threaded application and the DSP side would have some sort of RTOS/BIOS. In fact, it is how we use in MCSDK-Video. I'm not sure if you had a chance to go through MCSDK-Video - it is an application that is build on top of Desktop Linux SDK. The picture in the MCSDK Video documentation (Ref: http://processors.wiki.ti.com/index.php/MCSDK_VIDEO_2.1_PCIe_Demo_Development_Guide#Control_Message_Exchange_via_Pipes_and_Mailboxes) shows you multi-threaded application built on top of Desktop Linux SDK.

    Please let us know if you have any questions...

    Regards,

    Vivek

  • 0 in reply to Vivek Chengalvala
    Expert 1630 points

    Vivek Chengalvala said:

    Can you please provide more details about how your system is partitioned between host and DSP? I assume that data I/O etc happens on host processor and you feed the raw data (over PCIe) for DSP processing.

    Yes - my Host PC interacts with some sensors, obtaining information from the "real" world.  The host PC will then 'translate' that information, as necessary, and send it to my DSP bank via PCIe.  My DSPs are on the Advantech 8681.

    Vivek Chengalvala said:

    The DSP side of filetestdemo is bare-metal (no BIOS/RTOS) for the sake of simplicity. Also, for the sake of simplicity, the host side application of filetestdemo is a single-threaded application where data I/O on host, moving of data to/from DSP and actual processing of data on DSP - all happen sequentially.

    This is a good explanation, thank you for the clarifications.

    I'm assuming I can add SYS/BIOS to the DSP side of filetestdemo, and add some of my custom functionalities there.

    Vivek Chengalvala said:

    In more real world applications, the host side would be multi-threaded application and the DSP side would have some sort of RTOS/BIOS. In fact, it is how we use in MCSDK-Video. I'm not sure if you had a chance to go through MCSDK-Video - it is an application that is build on top of Desktop Linux SDK.

    I have briefly looked at the MCSDK-Video, but most of the "video" aspects of it are over my head.  I suppose my lack of experience with video codecs, decoding & encoding, etc. made that code harder to study :)

  • 0 in reply to Chris Jagielski
    TI__Expert 3715 points

    Chris,

    Thanks for the answers. I'm not sure how to embed my response in your post. But for the question you asked, Yes, you can add SYS/BIOS to the DSP side of filetestdemo and add any custom functionality there instead of the dumb memcpy. In fact, that's what we did in the MCSDK-Video demo.

    I understand that understanding MCSDK-Video with lack of experience with video codecs makes it hard. But, I hope you understood the need of having a multi-threaded application on the host side, having one deviceIO TX and RX thread per device, such that the data I/O between host and each DSP can happen in parallel (as there are 2 PCIe lanes going to each DSP). 

    Regards,

    Vivek

  • 0 in reply to Vivek Chengalvala
    Expert 1630 points

    Thanks Vivek.  Yesterday I merged SYS/BIOS with the filetestdemo code.  I'm putting the demo_loopback_test() in a Task.

     

    Vivek Chengalvala said:

    But, I hope you understood the need of having a multi-threaded application on the host side, having one deviceIO TX and RX thread per device, such that the data I/O between host and each DSP can happen in parallel (as there are 2 PCIe lanes going to each DSP).

    This does make sense.  I'll need to spend some time looking through the host source file also.

    Thanks again.