• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 422 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.

SRIO Communication for Multiple DSP,Multiple board

vijayabharathi chelladurai
Intellectual 955 points

 

 

Hello

We are working with a client whose requirement is

Usage of  SRIO for communication between 6 DSP in a board,

Usage of  SRIO for communication between Multiple boards of same kind connected through Backplane

firmware should demonstrate

a) Able to operate in heterogeneous processing node configuration.

b) Should support Discovery / Enumeration in both host and node.

 

Iam confused how to prove especially b)

Kindly suggest me

 

Vijayabharathi

 

 

 

  • 0
    Intellectual 955 points

     

    C6474 as node

    In case of C6474 as node, i got some picture that host in some other board will "Identify,Enumerate, Initialize" C6474.

    But in case of C6474 as host .. If suppose my board containing 6 DSP, assume there are also some other boards in the backplane. For this case,Is there any option that one of C6474 DSP available in my board capable of performing enumeration,discovery of nodes? If so, any software libraries available in TI to support?

    Is the DIO library linked to this?

     

     

     

  • 0 in reply to vijayabharathi chelladurai
    TI__Mastermind 23525 points

    Vijayabharathi,


    I noticed that your question was never addressed.  The C6474 could be used as a system host to perform the discovery/enumeration of the other SRIO devices in the system.  The DIOLib does have some support for this, the BRU module has defined function calls that could be used. 

    https://gforge.ti.com/gf/project/sriodirectiolib/

    System bringup, or discovery/enumeration can be static or dynamic in nature.  So RapidIO can support a full range, very simple or very software intensive mechanisms.  You can look at chapter 2.3 of Part 7 of the RapidIO interconnect spec entitled System and Device Inter-operability Specification.  Also, with even more detail is the Annex 1: Software/System Bring Up Specification.  These both describe how it can be done. 

    http://www.rapidio.org/specs/disclaimer?specfile=/zdata/specs/inter-op.pdf

    http://www.rapidio.org/specs/disclaimer?specfile=/zdata/specs/sbtg.pdf

    Regards,

    Travis

  • 0 in reply to tscheck
    Intellectual 955 points

     

    Hi Travis

    Thanks for the information. i will contact again if any quereis

    Regards

    Vijayabharathi C

     

  • 0 in reply to vijayabharathi chelladurai
    TI__Mastermind 18146 points

    Hi Vijayabharathi,

    you may want to look at http://www.fetcorp.com/. That's a company offering SRIO network management and discovery:

    RapidFET™ is a new kind of network management and diagnostic tool developed specifically for the new challenges faced in today’s RapidIO systems. While point to point protocols such as RapidIO are superior to multi-drop bus topologies, they are also more complicated. New software is required to initialize and enumerate EndPoints, and switches need routing tables configured, before any kind of software prototyping can begin. Testing board and system level hardware at Giga Hertz bus speeds is a completely new challenge as well. To keep development costs down, and time to market windows short amidst growing system complexity, you need to arm developers with a new kind of tool.

    Kind regards,

    one and zero