C6472 semaphore address

This information would normally be in the data sheet.  However, the User Guide you mentioned (sprug14) is for the C6474, not the C6472.  The C6474 data sheet contains the absolute address of the semaphore module.  The C6472 data sheet makes no mention of a semaphore module.  I've not yet used the C6472, but from the looks of things, it does not contain a semaphore module.

Hello,

Please look at the device specific datasheet SPRS612B

Regards

Arye

Arye,

Is the IP block called something different in 6472 than it was in the 6474?  I did a search for the word "semaphore" and did not find it listed anywhere in the datasheet.  That was my confusion in the last post.

Brad

Hi guys,

I am not sure now, please look at SPRAB27a.pdf, section 3.2.3:

Each device includes hardware support for atomic arbitration. The supporting

architecture does vary on different devices, but the same underlying function can be

achieved easily. Atomic arbitration instructions are supported with hardware monitors

in the Shared L2 controller present on the TCI6486 and C6472 devices, while a

semaphore peripheral is present on the TCI6487/88 and C6474 devices because they do

not have a shared L2 memory. On all devices, a CPU can atomically acquire a lock,

modify any shared resource, and release the lock back to the system.

Is this what you ment?

Arye

Thanks for the replies.

It is a great pity that TI does not follow occam's razor and is happy to multiply entities. It seems very bad design to have two entirely distinct mechanisms on two very similar chips, guaranteeing that code developed for one cannot work on the other. While it would have been better to have no need for such crude interprocessor synchronization, the semaphore mechanism is reasonably simple and would have been applicable to any memory architecture, while the shared memory technique is overly complex, requires the addition of three new instructions, and makes claiming and releasing locks far more expensive.

Thank you, sincerely, for a dose of philosophy on a Monday morning. At first, I thought you were advertising some competitor's part (occam's razor), but I googled it and found a WikiPedia article that is very good reading with my morning coffee.

And I agree completely with your assessment of the effort required to port between these two very similar devices, C6474 and C6472, at least for the case of semaphores for sharing. The quotation Arye offered is the "why" for "why are there two different techniques?" but not the "why" for "why didn't we put both techniques into both devices?". At least that would make code more easily ported.

The C6474 Semaphore module has a lot of untapped capability for inter-core and even inter-task signalling. The documentation is lacking, but the hardware is very powerful and has been used to get around silicon errata in some cases, prior to getting those fixed in a silicon revision.

The C6472 Atomic Operation Instructions can provide a much lower overhead for the more focused task of accessing shared memory. They can also be used for controlling access to shared peripherals, or anything else, and that meant the designers could leave out the Semaphore hardware module, although I cannot figure out why they wanted to leave it out.

I have seen hints that upcoming multi-core devices will use an improved Semaphore Module (and improved documentation). I hope that the Atomic Operation Instructions are passed along, too.