DRA821U-Q1: Getting started with DMSC for use in safety-critical applications

Hi Ricardo,

Ricardo Bedin Franca said:

What does "<10MHz" mean in this context? Do the RM/PM services run all the time or only when we call them via the appropriate APIs?

This is the overall compute/CPU load cost that would be taken by RM/PM services on your running system.

The SysFW model is a class client-server model, the RM/PM services are a library being run in a thread (Server), and runs when there is an incoming request from other processors.

Ricardo Bedin Franca said:

- Assuming we are going to use only one A72 or R5F core present in the MAIN domain*, will the execution of MCU1_0 interfere in the MAIN cores timing behavior (i.e. will there be any resource contention and timing interference in a MAIN core even if I am not explicitly calling any SysFW function allocated to MCU1_0)?

The MCU R5F and MAIN R5F are separate cores, so there is no interference at all. The MCU R5F core has to be up and running first so that the SciServer is providing services to all the other processor cores. Any RM/PM resource requests from MAIN R5F (Sci Client) would have to go MCU R5F (Sci Server), but that can be done as part of your application init code.

Ricardo Bedin Franca said:

- Does the execution of DMSC interfere in the MAIN cores timing behavior (i.e. are there timing interference channels between the M3 and a MAIN R5F/A72 due to resource contention)?

Same answer as above, DMSC primary purpose is for Security and Processor Boot services, so there would be no runtime interference.

Ricardo Bedin Franca said:

- Should the DMSC memory be subject to any multi-bit upset, may it reset the entire SoC without our MAIN cores being informed?

- Should the MCU1_0 memory be subject to any multi-bit upset, may it reset the entire SoC without our MAIN cores being informed?

The MCU1_0 also serves as the primary Safety master in the SoC, so most of the Safety bit error detections etc are handled by MCU1_0. The MCU1_0 can be monitoring the various ESM events and take appropriate action, including performing a SoC reset.

This is typically an integration choice if your MAIN cores need to be informed as part of the Safety restart.

Ricardo Bedin Franca said:

* We think we need to run our application in the MAIN domain because we need access to the internal SRAM, the GPMC and the LPDDR4. 

The MAIN domain peripherals can be accessed by MCU R5F and the MCU domain peripherals can be accessed by MAIN domain cores as well, the two domains are on separate voltage domains, but are interconnected through asynchronous bridges at the SoC interconnect level.

DDR is always in MAIN domain, and you can have a MCU R5F application firmware run out of DDR as well.

regards

Suman

Hi Suman,

Thanks for your answers! Of course, we have more questions...

Suman Anna said:

This is the overall compute/CPU load cost that would be taken by RM/PM services on your running system.

The SysFW model is a class client-server model, the RM/PM services are a library being run in a thread (Server), and runs when there is an incoming request from other processors.

How does MCU1_0 work in this architecture? Is the Sci Server called periodically by any interrupt or the like? Does it perform any access through the asynchronous bridge when checking if any client has sent a service request? Our concern is that we do not know how to prove that normal SciServer operation does not interfere with any other core due to contention for access to the interconnect.

Suman Anna said:

The MCU R5F and MAIN R5F are separate cores, so there is no interference at all. The MCU R5F core has to be up and running first so that the SciServer is providing services to all the other processor cores. Any RM/PM resource requests from MAIN R5F (Sci Client) would have to go MCU R5F (Sci Server), but that can be done as part of your application init code.

Since we are sure that an 1GHz R5F is more than capable of running our application and we are much more worried with timing predictability than performance, would it be more advisable for us to deploy our application in MCU1_0, MCU1_1 or a MAIN core? If Sci Server takes a small (and predictable) CPU usage that we can easily measure while measuring our application time, we would probably want to use only MCU1_0 and leave all other cores turned off.

Suman Anna said:

Same answer as above, DMSC primary purpose is for Security and Processor Boot services, so there would be no runtime interference.

Assuming we intend to configure the processor and peripherals only during boot and initialization, what actions does the DMSC perform in runtime? Will it  stay in some infinite loop? Will it periodically perform accesses to the MCU interconnect?

As our use case may look odd, I will try to summarize our wishes and worries:

- We prefer to work with single-core MCUs and bare-metal applications to keep timing predictability - While a simpler chip like AM243x would certainly fit our performance needs, we prefer the DRA821U-Q1 because of its AEC-Q100 qualification.

- We would like to have more than 4MB of internal memory for data, constants and code, but we can settle for less if there is a fast external RAM interface such as LPDDR4.

- We need a 16- or 32-bit interface such as GPMC in order to communicate with an ASIC or FPGA.

- We would like to be able to demonstrate that our processor behaves like a single-core after initialization - we must be able to have detailed knowledge of the DMSC behavior after boot and initialization.

Best regards,

Ricardo

Hi Ricardo,

Ricardo Bedin Franca said:

How does MCU1_0 work in this architecture? Is the Sci Server called periodically by any interrupt or the like?

SciServer is essentially running in a task/thread of it's own. The thread is scheduled when an incoming request comes in (detected through an interrupt).

MCU1_0 is required to be running an RTOS (cannot be baremetal). 

Please look through the PDK 4.16. SCICLIENT module documentation that details about the SciClient/SciServer usage. Also useful is the 8.3. MCU1_0 Application Development with SYSFW  section in the RTOS SDK documentation.

Ricardo Bedin Franca said:

Since we are sure that an 1GHz R5F is more than capable of running our application and we are much more worried with timing predictability than performance, would it be more advisable for us to deploy our application in MCU1_0, MCU1_1 or a MAIN core? If Sci Server takes a small (and predictable) CPU usage that we can easily measure while measuring our application time, we would probably want to use only MCU1_0 and leave all other cores turned off.

The SciServer task really comes into play only when the other cores are requesting some RM/PM services at runtime while MCU1_0 application is running. If you have requested all the needed resources up-front, and your MCU1_0 application is the only threads running at steady-state, then the SciServer is nearly zero.

The application behavior can still be controlled based on the traditional RTOS thread prioritization of the various threads within your MCU1_0 firmware.

Ricardo Bedin Franca said:

Assuming we intend to configure the processor and peripherals only during boot and initialization, what actions does the DMSC perform in runtime? Will it  stay in some infinite loop? Will it periodically perform accesses to the MCU interconnect?

DMSC is typically running from it's own IRAM and using its internal DRAMs. DMSC also has an associated Watchdog, so it periodically will wakeup to pet the timer if nothing else is scheduled and the processor is idle. During runtime, DMSC is exercised only when some DMA setup is being done on MCU1_0 or other cores, outside of any Security service calls.

Ricardo Bedin Franca said:

- We prefer to work with single-core MCUs and bare-metal applications to keep timing predictability - While a simpler chip like AM243x would certainly fit our performance needs, we prefer the DRA821U-Q1 because of its AEC-Q100 qualification

If this is a strict requirement, then you can just let the MCU1_0 run just the SciServer, and leverage other R5F cores for complete independence. If LockStep behavior (Safety-relavent feature) is not a care-about, you can even have the MCU R5FSS cluster be configured in Split-mode and isolate your application to even MCU1_1.

Ricardo Bedin Franca said:

- We would like to have more than 4MB of internal memory for data, constants and code, but we can settle for less if there is a fast external RAM interface such as LPDDR4.

There are some on-chip SRAMs that you can use. The DRA821 does use LPDDR4, and within the SoC, this memory is the one with the largest latency compared to TCM memories or other on-chip SRAMs. This really depends on how many cores you are going to use and what memory needs are required for each of the firmwares on those cores.

Ricardo Bedin Franca said:

- We would like to be able to demonstrate that our processor behaves like a single-core after initialization - we must be able to have detailed knowledge of the DMSC behavior after boot and initialization

I am confused by your single-core statement. Are you talking about DMSC or your application core?

regards

Suman

Hi Suman,

Suman Anna said:

MCU1_0 is required to be running an RTOS (cannot be baremetal). 

As we intend to run a single application under cyclic executive scheduling (i.e. as simple as possible), the idea of using an RTOS only for resource/power management is quite daunting for us, as our application itself does not need one. Would it be necessary to have an RTOS if we used the DRA821U with SDK 7.0? We would gladly "sacrifice" one MAIN R5F as shown in SDK 7.0 if this would mean no need for an RTOS. Speaking of this MAIN R5F (R5F0 Core 1): What is this third-party HSM software that would run on it (or in the DMSC for SDK 7.0)? Is this something mandatory for any use of the DRA821U? Would this require an RTOS, too?

By the way: how do security, power and resource management work in AM2432? Is everything concentrated in the M3? Would it require the use of an RTOS?

Suman Anna said:

I am confused by your single-core statement. Are you talking about DMSC or your application core?

Sorry! I mean we would need only one core for our application and we would like to keep all other cores (bar the DMSC) turned off (or doing meaningful work only at initialization) to minimize interference and avoid all the hassle related to multi-core usage in critical software. Since we also want to avoid an RTOS (which is mandatory for SDK 7.1, if we understood your answers correctly), we have the above question regarding SDK 7.0.

Another comparison that may help you understand our questions: A much simpler and less powerful chip, such as the AM2631-Q1, would probably fit our needs if it had either a LPDDR4 interface or more internal SRAM. If we can make the DRA821U behave similarly (i.e. make use of its larger SRAMs and LPDDR4 interface while keeping the rest as simple as possible), we are sure the DRA821 will be a great fit for our application.

Best regards,

Ricardo

Hi Ricardo,

Ricardo Bedin Franca said:

As we intend to run a single application under cyclic executive scheduling (i.e. as simple as possible), the idea of using an RTOS only for resource/power management is quite daunting for us, as our application itself does not need one.

IIUC, you only need one core. Does that R5F cluster needs to be in LockStep?

Ricardo Bedin Franca said:

Would it be necessary to have an RTOS if we used the DRA821U with SDK 7.0?

You can run with baremetal on MCU1_0 as the DM portions on SDK 7.0 are all handled within the TIFS. That said, this SDK is very old, and the architecture won't allow you to pick up any bug fixes from newer release onto that older release. It is preferable that you use a more recent SDK.

You can always run the TI provided SciServer on MCU1_0 using FreeRTOS and leverage the MAIN R5F for your application. The MAIN R5F core can be running any RTOS or baremetal, there are no restrictions on it.

Ricardo Bedin Franca said:

What is this third-party HSM software that would run on it (or in the DMSC for SDK 7.0)? Is this something mandatory for any use of the DRA821U? Would this require an RTOS, too?

TI provides the DMSC firmware on SDK 7.0, and does not provide any third-party HSM software itself. The HSM stack is optional, and is driven by customer needs. This is typically left to customers to choose a HSM stack vendor.

The DMSC firmware does run a TI RTOS.

Ricardo Bedin Franca said:

By the way: how do security, power and resource management work in AM2432? Is everything concentrated in the M3? Would it require the use of an RTOS?

Please open a new ticket for questions on AM2432, and it can be addressed by the relevant support engineers.

regards

Suman

Hi Suman,

Suman Anna said:

IIUC, you only need one core. Does that R5F cluster needs to be in LockStep?

We do not need lockstep.

Suman Anna said:

You can always run the TI provided SciServer on MCU1_0 using FreeRTOS and leverage the MAIN R5F for your application. The MAIN R5F core can be running any RTOS or baremetal, there are no restrictions on it.

Having to insert an RTOS in our development cycle would incur such costs and risks that, unfortunately, it will probably make us rule out the DRA821U. Is the SciServer mandatory for running the SoC, even if we do not intend to alter anything after initialization?

One more question: how are ECC failures in the DMSC dealt with?

Thanks,

Ricardo

Hi Ricardo,

Ricardo Bedin Franca said:

Having to insert an RTOS in our development cycle would incur such costs and risks that, unfortunately, it will probably make us rule out the DRA821U. Is the SciServer mandatory for running the SoC, even if we do not intend to alter anything after initialization?

How many cores overall will you be running in the System for your application - just one core? And is that on MCU R5F?

Would a DM firmware binary from TI suffices for your needs (no modifications) on MCU1_0 if you were to exercise your software on a different core?

If you are not going to have software on other processors, and have no other cores make any runtime changes and have all requests be done at init time, then it is possible to minimize the sciserver, and just use a baremetal application on MCU1_0. 

Ricardo Bedin Franca said:

One more question: how are ECC failures in the DMSC dealt with?

This is a separate topic. Are you expecting a certain Safety level from DMSC? DMSC is primarily geared towards Security, and not Safety. It is the Security master in the System.

regards

Suman

Hi Suman,

Suman Anna said:

How many cores overall will you be running in the System for your application - just one core? And is that on MCU R5F?

Yes. We intend to use only one R5F core for our applicatoin.

Suman Anna said:

Would a DM firmware binary from TI suffices for your needs (no modifications) on MCU1_0 if you were to exercise your software on a different core?

If you are not going to have software on other processors, and have no other cores make any runtime changes and have all requests be done at init time, then it is possible to minimize the sciserver, and just use a baremetal application on MCU1_0. 

Indeed, we are not going to have software on other processors and only the core running the application will perform DM/RM requests at boot/init time. A minimalist SciServer sharing MCU1_0 with our baremetal application looks much more feasible for our use case.

I looked at one FAQ (https://e2e.ti.com/support/processors-group/processors/f/processors-forum/313154/are-any-of-ti-rtos-sys-bios-or-dsp-bios-certified-for-safety--or-mission-critical-applications-have-they-been-used-in-safety-certified-applications) regarding certification and I would like to know if the source code for the binaries that shall load in DMSC and MCU1_0 will be available.

Suman Anna said:

This is a separate topic. Are you expecting a certain Safety level from DMSC? DMSC is primarily geared towards Security, and not Safety. It is the Security master in the System.

While ASIL D is desirable, I do not know yet if it is a must. It looks (from the datasheet diagrams) like the DMSC belongs to the MCU domain, which is ASIL D. Is that right? Our concern regarding the DMSC is that, besides performing security functions, it controls our devices and clocks and we need to make sure that it is as safe as simpler clock management devices we find in simpler processors and MCUs.

Thanks,

Ricardo

Hi Ricardo,

Ricardo Bedin Franca said:

Indeed, we are not going to have software on other processors and only the core running the application will perform DM/RM requests at boot/init time. A minimalist SciServer sharing MCU1_0 with our baremetal application looks much more feasible for our use case.

If your entire system is only running just MCU1_0 (TIFS is mandated), then you can turn on all the desired clocks in SBL, and just run your baremetal applicable in MCU1_0. TIFS is booted by SBL itself, so you can continue in that configuration.

Ricardo Bedin Franca said:

I would like to know if the source code for the binaries that shall load in DMSC and MCU1_0 will be available.

The PDK source code is all public and available as part of the RTOS SDK. The firmware on DMSC is only released in binary form, source code for this is not made available within the SDK.

Ricardo Bedin Franca said:

It looks (from the datasheet diagrams) like the DMSC belongs to the MCU domain, which is ASIL D. Is that right?

DMSC is actually in the Wakeup domain, the MCU domain and Wkup domain have the same voltage though. The DMSC Cortex-M3 core is not Lock-Step, so it is not ASIL-D.

Ricardo Bedin Franca said:

Our concern regarding the DMSC is that, besides performing security functions, it controls our devices and clocks and we need to make sure that it is as safe as simpler clock management devices we find in simpler processors and MCUs.

DMSC controls devices and clocks only prior to 7.1 SDK. Device and Clocks are all part of the DM SciServer from 7.1 kernel onwards, and is all handled as part of the Sciclient module.

regards

Suman

Hi Suman,

Suman Anna said:

The PDK source code is all public and available as part of the RTOS SDK. The firmware on DMSC is only released in binary form, source code for this is not made available within the SDK.

Are you referring to the binary that we may load in MCU1_0 and run it with our application and without an RTOS? Is it already available?

Thanks,

Ricardo

Hi Ricardo,

Ricardo Bedin Franca said:

Suman Anna said:

The PDK source code is all public and available as part of the RTOS SDK. The firmware on DMSC is only released in binary form, source code for this is not made available within the SDK.

Are you referring to the binary that we may load in MCU1_0 and run it with our application and without an RTOS? Is it already available?

The binary I am talking about is the TIFS binary. The MCU1_0 will go through two different software components - the SBL (bootloader) for which the SDK provides the reference code for the TI EVM, and the MCU1_0 application itself. The latter will be yours, the former will need adjustments for your board.

regards

Suman