How to resolve hardware resource conflict in Multi-core embedded system?
Our application is Advanced Drive Assist Systems(ADAS). Our Electronic Control Unit(ECU) contains Two Renesas RH850 / U2A16 Microcontrollers. Each microcontroller has Four cores. Our Embedded Software Design is based on ETAS Autosar version 4.x RTOS.
Microcontroller A has Four cores. core0, core1, core2, core3. Microcontroller A has Error Control Module (ECM). The problem is that core1, core2, and core3 are all trying to write to ECM registers at the same time. There is a resource conflict where each core is trying to unlock and relock the ECM registers - effectively, this results in the ECM being locked when one or more of the cores are trying to write to an ECM register.
Do we need to add semaphore / OS Resource protection to the ECM functionality such that only one core can modify ECM registers at a time?
What core synchronization services does the ECM have? How will cores share mutually exclusive peripherals? Can this synchronization achieved using a semaphore? Are there any semaphore objects and semaphore services provided to ensure mutually exclusive data access?
Is there inter-core communication that involves sharing of data among cores through sharing of memory space? Is it possible to use message queue object for inter-core communication through which cores send or receive messages placed in a shared memory? Are there any services provided by RTOS that cores can use to send messages to and receive messages from queue? And somehow use these messages to achieve mutually exclusion access to ECM.
In our os configuration file, there is a macro OS_NUM_RESOURCES ( 8U ). The eight resources that are declared are: core0, core1, core2, core3, core0_scheduler, core1_scheduler, core2_scheduler, and core3_scheduler. Can ECM resource be defined as well? Will RTOS manage this hardware resource?
How many of following options will solve this problem?
1. This rtos has 'GetSpinlock' API. GetSpinLock is used to give one core exclusive access to shared resource - typically writeable data. Only one core is able to occupy a specific spinlock at a time. Syntax of this API is 'GetSpinlock ( SpinlockIdType SpinlockId )'. Does this rtos have knowledge of ECM resource? Can ECM be defined as a shared resource? If core 1 occupies spinlock, will rtos prevent other cores from accessing ECM registers?
2. This rtos has APIs such as 'ModifyPeripheral32'. Modifies the 32-bit value at Address by ANDing it with the Clearmask and ORing it with the Setmask. The syntax of this API is: StatusType ModifyPeripheral32 ( AreaIdType Area, unint32 * Address, unit32 Clearmask, uint32 Setmask )
Description of this API: Reads a 32 bit value from the specified address, then does a bitwise AND with the Clearmask and a bitwise OR with the Setmask, before writing the value back.
Typically used to allow code in untrusted OS Applications to modify data from areas of memory that would otherwise be inaccessible because of memory protection settings. The read is done
from a trusted context. Peripheral Areas must be declared in the configuration. Their legal address range must be specified, and also the OS-Application that can access them.
All 32 bits of the modified value must be within the configured address range.
The OS does not prevent two different cores from accessing peripherals at the same time.
What does the last sentence mean? If Three cores use this API simultaneously, there will be ECM resource conflict issue?
3. Is it possible to synchronize cores using event objects? For example, core 2 and core 3 wait for core 1 to set a event?
Microcontroller A has Four cores. core0, core1, core2, core3. Microcontroller A has Error Control Module (ECM). The problem is that core1, core2, and core3 are all trying to write to ECM registers at the same time. There is a resource conflict where each core is trying to unlock and relock the ECM registers - effectively, this results in the ECM being locked when one or more of the cores are trying to write to an ECM register.
Do we need to add semaphore / OS Resource protection to the ECM functionality such that only one core can modify ECM registers at a time?
What core synchronization services does the ECM have? How will cores share mutually exclusive peripherals? Can this synchronization achieved using a semaphore? Are there any semaphore objects and semaphore services provided to ensure mutually exclusive data access?
Is there inter-core communication that involves sharing of data among cores through sharing of memory space? Is it possible to use message queue object for inter-core communication through which cores send or receive messages placed in a shared memory? Are there any services provided by RTOS that cores can use to send messages to and receive messages from queue? And somehow use these messages to achieve mutually exclusion access to ECM.
In our os configuration file, there is a macro OS_NUM_RESOURCES ( 8U ). The eight resources that are declared are: core0, core1, core2, core3, core0_scheduler, core1_scheduler, core2_scheduler, and core3_scheduler. Can ECM resource be defined as well? Will RTOS manage this hardware resource?
How many of following options will solve this problem?
1. This rtos has 'GetSpinlock' API. GetSpinLock is used to give one core exclusive access to shared resource - typically writeable data. Only one core is able to occupy a specific spinlock at a time. Syntax of this API is 'GetSpinlock ( SpinlockIdType SpinlockId )'. Does this rtos have knowledge of ECM resource? Can ECM be defined as a shared resource? If core 1 occupies spinlock, will rtos prevent other cores from accessing ECM registers?
2. This rtos has APIs such as 'ModifyPeripheral32'. Modifies the 32-bit value at Address by ANDing it with the Clearmask and ORing it with the Setmask. The syntax of this API is: StatusType ModifyPeripheral32 ( AreaIdType Area, unint32 * Address, unit32 Clearmask, uint32 Setmask )
Description of this API: Reads a 32 bit value from the specified address, then does a bitwise AND with the Clearmask and a bitwise OR with the Setmask, before writing the value back.
Typically used to allow code in untrusted OS Applications to modify data from areas of memory that would otherwise be inaccessible because of memory protection settings. The read is done
from a trusted context. Peripheral Areas must be declared in the configuration. Their legal address range must be specified, and also the OS-Application that can access them.
All 32 bits of the modified value must be within the configured address range.
The OS does not prevent two different cores from accessing peripherals at the same time.
What does the last sentence mean? If Three cores use this API simultaneously, there will be ECM resource conflict issue?
3. Is it possible to synchronize cores using event objects? For example, core 2 and core 3 wait for core 1 to set a event?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
If I define 'counter' resource in my rtos and access counter without acquiring a semaphore, os will allow that? If not, what would happen?
It depends on the implementation of processes, etc.
Define a process as having it's own address space, and threads within a process sharing an address space.
(That means a process has at least one thread. )
In that case a declaration of counter will be shared within a process at the same physical location.
If you have multiple processes then each process will have their OWN counter,.
Semaphores should be implemented by the OS and be shared among processes. (You open/create a semaphore..., to gain access) like you open a file)
so if all processes use the same semaphore they are synchronised.
spinlocks are a HARDWARE implementation that only assumes/requires some special cache hardware fascilities. ( to ensure updats are visible to all systems on the system bus, even across chipsets). sempahores are the software equivalent. although they try to avoid loopign themselves and use spinlock to implement that access phase.
If you want a better answer please provide links to hardware & CPU descriptions, as well as OS documentation. of the right versions.
Between LOCK BUS & UNLOCK buss no other CPU may do any bus transfer. (blocking all external activity..)
Define a process as having it's own address space, and threads within a process sharing an address space.
(That means a process has at least one thread. )
In that case a declaration of counter will be shared within a process at the same physical location.
If you have multiple processes then each process will have their OWN counter,.
Semaphores should be implemented by the OS and be shared among processes. (You open/create a semaphore..., to gain access) like you open a file)
so if all processes use the same semaphore they are synchronised.
spinlocks are a HARDWARE implementation that only assumes/requires some special cache hardware fascilities. ( to ensure updats are visible to all systems on the system bus, even across chipsets). sempahores are the software equivalent. although they try to avoid loopign themselves and use spinlock to implement that access phase.
If you want a better answer please provide links to hardware & CPU descriptions, as well as OS documentation. of the right versions.
Acquire spinlock pseudo code:
loop:
lock bus
flush CPU cache
move @spinlock.flag to r0
move 1 to @spinlock.flag
flush CPU cache
unlock bus
if r0 != 0 goto loop
move @pid to @spinlock.owner
flush CPU cache
return
Release:
lock bus
move 0 to @spinlock.owner
move 0 to @spinlock.flag
flush CPU cache
unlock bus
returnBetween LOCK BUS & UNLOCK buss no other CPU may do any bus transfer. (blocking all external activity..)
ASKER
Thank you for the great explanations. There is just one point I want to clarify.
>> Between LOCK BUS & UNLOCK buss no other CPU may do any bus transfer. (blocking all external activity..)
There is nothing preventing other CPU to transfer on bus? If they do transfer on bus, it would be a mistake or bug?
In your example above counter is a resource. Between acquiring and releasing semaphore, nothing is preventing some other thread from writing to counter? If so, it would be a mistake or bug?
>> Between LOCK BUS & UNLOCK buss no other CPU may do any bus transfer. (blocking all external activity..)
There is nothing preventing other CPU to transfer on bus? If they do transfer on bus, it would be a mistake or bug?
In your example above counter is a resource. Between acquiring and releasing semaphore, nothing is preventing some other thread from writing to counter? If so, it would be a mistake or bug?
LOCK bus means just THAT: "NO OTHER CPU" can engage the BUS, it is locked, it will execute wait states or some other means for doing NOTHING.
Why do you guess it is called LOCK.
If you want to halt a complete system, have on CPU lock the bus and than sit idle.....
Fortunately as this has high impact on many CPU's the lock will only be valid for ONE instruction, and that instruction will do an exchange between memory and a register.
Lookup x86 LOCK and x86 XCHG instructions, other CPU architecture have similar ways
Why do you guess it is called LOCK.
If you want to halt a complete system, have on CPU lock the bus and than sit idle.....
Fortunately as this has high impact on many CPU's the lock will only be valid for ONE instruction, and that instruction will do an exchange between memory and a register.
Lookup x86 LOCK and x86 XCHG instructions, other CPU architecture have similar ways
ASKER
I believe semaphores are restricted to code within a core? Spinlock is like semaphores but it works across cores ?
>> If you need to add one to some counter protected by the semaphore
so counter is a resource? Do I define this resource in my OS configuration just like Eight other OS Resources are defined.