TMS570LS1227: TMS570LS1227

Hello Samuel,

TMS570LS1227 is ARM Cortex-R based MCU. Cortex-R real-time processors offer high-performance computing solutions for embedded systems where reliability, high availability, fault tolerance and/or deterministic real-time responses are needed. 

Please refer to our datasheet and technical reference manual for more features and performance.

Hello QJ. Thanks for the quick reply. I'm quite familiar with the product and have actually used it to implement a high integrity demonstrator for the aerospace market. Looking down the road to possibilities beyond demonstration, I need to better understand the determinism of the main cross bar arbitration and prioritization control scheme. I imagine my question will require the expertise of the person(s) who architected the SOC and/or wrote the firmware for that shared resource. Is there a way to get the next level on this question? Thanks. -S

QJ, some additional info on my question from Section 2 (page 12) of the TMS570LS31X and 21X product overview document:

"The level two device hierarchy is dominated by a switched central resource (also known as a bus matrix or crossbar). This is a device level interconnect that allows multiple bus masters to access multiple bus slaves, prioritization, routing, decode, and arbitration functions are provided. Bus masters to the level two device hierarchy include CPUs, bus master peripherals, debug bus masters, and general purpose direct memory access (DMA) controllers. Bus slaves on the level two hierarchy include the Flash EEPROM emulation memory, external memory interface (EMIF), access to one or more peripheral bus segments, and a Cortex-R4F slave port Flash allows level two bus masters to access the level one tightly coupled
memories."

As there are multiple bus masters to the level two device hierarchy, do the masters have scheduled shared resource access (deterministic) or does an interrupt-based prioritization scheme govern (non-deterministic)?

Thanks, -S

Shemuel,

The DMA and periperal bus masters need to be configured before they are active.
So if you don't use DMA, HTU, or FTU you won't have any conflict.

Turning on the DMA may add slightly to the latency of your code execution as there would be arbitration to memory sometimes - but the CPU dominates priority to it's own TCM [it should say somewhere that it's set at 16:1 CPU v.s. DMA in case of an on going conflict, but because the RAMs are in different banks B0, B1 and interleaved it's not likely you will have a sustained conflict like that,
CPU can fetch from B0 while DMA fetches B1 for example.].

Interrupts though would introduce much larger (compared to conflict in the fabric w. DMA) uncertainty in the execution time of the code running on your CPU, but the CPU has a vectored interrupt controller so interrupt response time is much improved on this CPU... and beyond that it's a bit up to you in terms of how much work you code into your ISR.

But you can certainly build your application so that it uses no DMA and no interrupts with this device. Neither are enabled by default after reset and neither are required.

-Anthony

WOW! Thanks for the thorough answer. Is there a way to reach out should I have additional questions? -S

Shemuel,

Thanks - this is the right place (E2E).

Best Regards,
Anthony