6457 Srio capabilities

Robert,

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics.

In particular, from the Product Folder for the TMS320C6457 you can get to all of the User Guides for the various peripherals of the device. The C6457 SRIO User's Guide has the specific lists of items that are supported and are not supported.

If you have access to conflicting documentation, please cite those.

Regards,
RandyP

You have pointed me back to the document I  ave already seen. It clearly states that GSM and atomic operations are not supported. So I assume this means than nother relating to this functionality is supported

Robert,

Sorry, but your original statement and above does not match with what the C6457 SRIO UG says, so I assumed you had not been there.

Yes, it clearly says GSM is not supported, so I am not sure what your question would be in terms of whether it is supported or not. I am not familiar with that standard, so your expertise on GSM may let you find some similar features that are supported, but I have no idea what those would be.

For atomic operations, it lists outgoing Atomic operations as being supported and Destination Atomic operations as not being supported. I hope you see my dilemma and why I referred you to the User's Guide.

I am not aware of any undocumented feature set that we are hiding. If you would like to discuss your requirements and ways that we could help you to work around that, please reply back with those, or start a new thread, whichever you prefer.

Regards,
RandyP

I am going back through the users guide  SPRUGK4D–March 2009–Revised February 2011 trying to figure out what low level calls I need to make

I am attempting to port an existing real-time messaging system that uses Srio to the 6457. The existing system runs on both a Power PC and Intel cards built by Curtiss Wright. In both of those implementations the Board Support Package (BSP) has a high level API to the srio device. For the 6457 I need to create that interface myself using the CSL.

There are basically 3 interfaces in my current API/device driver; doorbells, shared memory, and Dma.

Doorbells and Dma seem to be workable but  I'm not sure about shared memory

In my existing application, one processor ( the Master) allocates local memory and assigns it to a srio address. Other processors (up to 24), then set up srio addresses pointing to the the memory allocated by the master so it becomes a shared memory area between the processors. My interpetation of the Rio spec is that this is GSM, which your users guide states is not supported.

My 6457 application only needs communication between two 6457s (At this time).

My question about Atomic operations was somewhat acedemic. My current implementation does not require them,   but If I read the guide correctly I can issue an atomic request from the 6457 and if the target processor supports Atomic operations it will be accepted. But if the target is another 6457 it will be rejected. Is that correct?

Another team I work with has specifed the need for atomic operations and they have  6457s and   PPC 6481(s) going through a switch.

The uses guide states that

"Read, write, write with response, streaming write, outgoing Atomic, and maintenance operations" are supported,

but also states

"Target atomic operations (including increment, decrement, test-and-swap, set, and clear) for internal L2 memory and registers"

Robert,

Yes, the GSM spec is not supported by our DSPs and only out-going atomic operations are supported.  This means that the LSU can be programmed to generate the atomic packet types, but on the receive side they will cause an ERROR response:

Ftype=2,  Ttype=4'b1100, Atomic inc                         -> ERROR RESPONSE

                Ttype=4'b1101, Atomic dec                         -> ERROR RESPONSE

                Ttype=4'b1110, Atomic set                          -> ERROR RESPONSE

                Ttype=4'b1111, Atomic clr                            -> ERROR RESPONSE

What this all means is that in your application when you want to write to a shared memory region in the master local space, you will have to manage the accesses by the slaves so that they don't overwrite/conflict each other.  Essentially, you will have to assign portions of the shared memory space to individual slaves through some sort of agreed upon mechanism.  With directIO packet types(nwrite, nwrite_r, nread) packets are memory address based anyway so this is definitely possible.  Let me know if you have any more specific questions.

Regards,

Travis