AM2434: AM2434 OCRAM usage with DMSC & DMSC/SYSFW in context of Aerospace & Defense DAL certification

The customer should be given access to the safety manual and FMEDA collateral for AM24x family. 

https://www.ti.com/drr/opn/AM64X-RESTRICTED-DOCS-SAFETY

Responses to their queries

1. DMSC runs continuously and uses a portion of OCSRAM actively. Does DMSC cause timing interference on Cortex-R5F cores? If not, how this is achieved? 

The sections of on-chip ram which DMSC uses are reserved and not used by other cores. There are 8x256kB SRAMs, we lump them together and call is MSRAM at the abstract diagram level. Each 256k region is its own single port memory. Using each region by just one initiator, there are zero conflicts. So the 256kB region DMSC uses, don’t touch it from anywhere else.

https://www.ti.com/document-viewer/lit/html/SPRUIM2H#GUID-9B06B805-207C-4E2B-81DB-F5F1444DADFD/TITLE-SPRUIM2SOC_MAIN_MEMMAP_SEC

See an E2E that tries to explain this

(85) AM2432: What's the bandwidth of the shared OCRAM ? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

2. More specifically: Is there contention between the R5F cores and the DMSC for OCSRAM access? 

Same as 1

3. What is the timing profile of the code that runs inside DMSC? Is it a loop that executes continuously or it is enabled by some sort of interrupt? 

Interrupt based.

4. How does DMSC deal e.g. with Single Event Upset (SEU) scenarios? Is there documentation available regarding safety-related measures that DMSC implements?  

DMSC.RAM1 is a memory ECC for DMSC RAM which can provide protection against soft errors by allowing single bit errors to be detected and corrected and double bit errors to be detected. MSRAM1 is the memory ECC for on-chip RAM.

(refer to the safety manual) 

 5 DMSC performs management functions that Cortex-R5F must request to it. Is Cortex-R5F capable of performing the same operations or only DMSC has access to some (or all) management resources? 

All power management, resource management  & security/firewall configurations are requested from a particular core (R5F or A53) and are catered to by DMSC M3. Current SW arch doesn’t allow any of this to be done without DMSC

6 Is there any possibility of customizing DMSC code? 

We do not support customers modifying DMSC code.

7/ Does the possibility of TI sharing DMSC code with customer exist? Verification aspects are a large concern when certification comes to place, and not having access to the entire code executed during operation is a strong drawback. 

The source code can be shared under stringent NDA on exception basis. The code is provided as is , we do not support any questions on the source code and do not provide any support for end certifications. 

8/ Is there any way of disabling DMSC? Our intention would be having DMSC to perform its strictly necessary operations during boot (if it cannot be thoroughly replaced, which would be preferrable, of course) and then entering an off/sleep/hold mode to release the full OCSRAM to be used in operation and eliminating any interference concerns.

DMSC will be needed for all PM, RM & Security configuration, can’t be disabled in the current SW architecture. We do not support modifying or bypassing this.

Hi Mukul,

Below you can find additional questions from customer.

8. Assuming we are going to use only R5F core 0 of cluster 0, and that we are not going to perform any requests to DMSC after MCU boot and set-up, what actions are performed by DMSC by itself? What is the frequency of the interrupt that triggers its periodic behavior?

9. What are the usual questions certification authorities pose regarding DMSC? Should they ask us anything we are not able to answer by ourselves, may we forward their questions to you?

While we are confident that we need only one R5F core, we do need every bit of memory we have. Thus:

10. Is there any standard procedure to make the R5F core 0 of cluster 0 use the cluster 1 TCM? We assume this is doable because SPRACV1B provides memory read latency for “TCM of another Cortex-R5F” but we do not know how to do it.

11. The AM243x MCU+ SDK shows MSRAM bank 7 as follows:

In our scenario (single-core, no need for IPC between MCUs), would we be able to use all the 128KB of this bank for non-time-critical data/code?

12. Are we right to assume that we can allocate our no-load data (e.g. .bss sections) to the 512KB used by SBL?

13. We are using the GPMC to communicate with an FPGA at 66MHz – we will have a hard time increasing GPMC frequency due to restrictions from our FPGA usage. While its write speed is in line with our expectations (~27MB/s), read speed is being a bottleneck (~7.5MB/s). In previous experiences with external interfaces of other MCUs, read speed is usually slower than write speed, but the transaction time increased at most 30%, rather than 360%... Are there any recommendations from your side to improve GPMC performance (e.g. means to reducing turnaround cycles between transactions)?

Could you please address it?

Thanks and regards,

Hamilton

Hello Hamilton,

Hamilton Ignacio said:

We are using the GPMC to communicate with an FPGA at 66MHz – we will have a hard time increasing GPMC frequency due to restrictions from our FPGA usage. While its write speed is in line with our expectations (~27MB/s), read speed is being a bottleneck (~7.5MB/s). In previous experiences with external interfaces of other MCUs, read speed is usually slower than write speed, but the transaction time increased at most 30%, rather than 360%... Are there any recommendations from your side to improve GPMC performance (e.g. means to reducing turnaround cycles between transactions)?

GPMC Performance on AM64x with PSRAM (16-bit, Mux Mode)

We’ve evaluated read and write performance for GPMC on AM64x interfaced with PSRAM using 16-bit -Multiplexed mode. Below are our observations and performance results (captured in Release Build).

Questions for Clarification:

To better understand and compare your performance results, could you please confirm the following:
1. Memory Type Configuration:
• On the SoC side, did you configure the GPMC interface as PSRAM, NAND, or NOR?

2. Bus Configuration:
• Are you using 16-bit or 8 or 32-bit interface?
• Is your interface in Muxed or Non-Muxed mode?

3. Timing Parameters:
• Are you using the default timing parameters provided in the MCU+SDK?
• Or have you modified them? If yes, please share the timing configuration used.

4. Build Configuration:
• Were the measurements captured in Debug or Release build?
• If the customer performed tests in Debug Build, please request them to recheck in Release Build to get realistic performance metrics.

Next Steps:

If you’re unable to further optimize performance after fine-tuning the timing parameters, it is valid to consider evaluating GPMC with DMA for improved throughput - is this method ok ?

Let me know once you confirm the above details — we’ll be happy to provide tuning suggestions or a DMA-based test example if needed.

Can you please share the syscfg for the GPMC as well to review the timing parameters ?

Regards,

Anil.

Hamilton Ignacio said:

9. What are the usual questions certification authorities pose regarding DMSC? Should they ask us anything we are not able to answer by ourselves, may we forward their questions to you?

 

If you are talking about DAL or AC 20-193 certification considerations - our productline systems or applications does not have any experience with this.  This is typically something customers will need to manage with their end certifying body. We have not had to take the DMSC software for such certification ourselves. I do not have history on A&D customers taking this through certification yet, as typically such development and process takes a lot of time. 

Hamilton Ignacio said:

Assuming we are going to use only R5F core 0 of cluster 0, and that we are not going to perform any requests to DMSC after MCU boot and set-up, what actions are performed by DMSC by itself? What is the frequency of the interrupt that triggers its periodic behavior?

The SYSFW should just wait in idle loop until the Secure Proxy IP registers an interrupt to the DMSC core for the SYSFW to consume the received message. If you are not gonna use any TISCI message then the SYSFW should just be waiting in idle loop forever.

Hamilton Ignacio said:

Is there any standard procedure to make the R5F core 0 of cluster 0 use the cluster 1 TCM? We assume this is doable because SPRACV1B provides memory read latency for “TCM of another Cortex-R5F” but we do not know how to do it.

The TCMs are mapped to the SoC address map as well. So, the other cores can use the available TCMs as needed using their SoC address spaces.

Hamilton Ignacio said:

In our scenario (single-core, no need for IPC between MCUs), would we be able to use all the 128KB of this bank for non-time-critical data/code?

A part of the BANK7 is always occupied by the SYSFW.

https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/security_handover.html#mcusram-bank-7-resource-usage-after-security-handover

Hamilton Ignacio said:

Are we right to assume that we can allocate our no-load data (e.g. .bss sections) to the 512KB used by SBL?

That is correct.

Hi Mukul,

Below you can find some additional questions from Embraer. 

We spent some time digesting the content of our conference call, which was very productive – thank you for that time! We have been unable, for the moment, to go deep in our GPMC setup for a more in-depth analysis of our bus low throughput issues, but we noticed the large difference between read and write performance is due to the GPMC staying idle during 12 bus cycles between read operations, while this large hiatus does not happen between write operations. We hope to provide more details in the coming weeks.

Meanwhile, we have some other questions (we can keep sending them here or directly to Mukul Bhatnagar and Pekka Varis if you wish):

 Are R5F able to make use of the MSRAM owned by the isolated M4F? What would be their latencies when compared to the main OCSRAM?

 Per our conf call, we understood GPMC is a kind of old technology that is being phased out. We usually rely on parallel buses to communicate with the FPGA (so that the FPGA can oversample signals sent by the MCU and still keep some bandwidth), and we would like to know what the modern solutions are to ensure fast and reliable communication with FPGAs.

Can you help us to respond them in a timely manner?

Thanks and regards,

Hamilton

Hello Hamilton 

On the GPMC throughput or cycle issue between read and write, i recommend that the customer or you open a separate E2E post to provide more details and depending on additional details they can provide we will try to assign to right owners in either hardware or software team. 

On R5F latency please see if the data in the benchmark appnote helps

https://www.ti.com/lit/an/spracv1b/spracv1b.pdf

Section 3.1.3. 

On more modern interfaces for FPGA attach, while we still see several customers use GPMC for FPGA post (if you search our forums you will find several references of such implementations in works) , the more standard interface, at least for AM64 will be PCIe , if the customer is ok withe cost and complexity of SERDES and FPGA sizing. 

Please do note that TI does not have full PCIe drivers coverage and missing few features. If they want to go this route, we can recommend a few 3P who can provide support on PCIe software enablement.

Regards

Mukul