Functional safety features in modern MCUs
Keywords:Functional safety? automotive SoCs? enhanced direct memory access?
This article discusses the key functional safety features present in modern semiconductor devices, allowing customers to run safety relevant tasks in their applications.
Functional safety requirements
Functional safety is related to minimizing the hazards resulting from a faulty system. The faults in a system may occur because of hardware/software errors, permanent/transient errors, or because of random/systematic errors. The following are the possible reactions when an error occurs:
???Fail-dangerous: Possibly causes a hazard in the case of a failure
???Fail-inconsistent: Provided results will be noticeably inconsistent in the case of a failure
???Fail-stop: Completely stops itself in the case of a failure
???Fail-safe: Returns to or stays in a safe state in the case of a failure
???Fail-operational: Continues to work correctly in the case of a failure
???Fail-silent: Will not disturb anyone in the case of a failure
???Fail-indicate: Indicates to its environment that it has failed
The implementation of functional safety in a system typically means "mapping" the first three types of reactions above into any of the last four reactions which ensure minimal hazards results from the system failure.
The next section discusses various functional safety implementations available in system-on-chips (SoCs) that allow device operation in any of the last four reactions listed above in case of system failure.
General safety implementation
Before discussing the key modules related to functional safety, let us first briefly discuss general industry standard implementations:
1) Checker core: Ensuring safe operation of the core in an SoC is one of the prime requirements for functional safety. Generally, this is taken care of by implementing a checker core which executes the same instructions as the main core and the address and data bus from the cores are compared in a checker unit to detect operational deviations. Depending on the nature of errors, there may be a reset or maskable/non-maskable interrupts generated by the system. From a software view point, the system behaves as a single-core. (see figure 1 below for a block diagram.)
Apart from the core, other safety relevant modules like enhanced direct memory access (eDMA), interrupt controller, cache, RAM, etc. can be similarly replicated in system maintaining the physical separation on the die so that common cause faults (CCFs) do not affect the operation of both the modules similarly.
2) Safe clock mechanism: In order to keep the system independent of external clocks during safe operation, there is an implementation of safe clock in Freescale automotive SoCs. This safe clock is provided by an internal RC oscillator which is available as soon as the device comes out of reset. The availability of this clock ensures that the system has a clock to operate even if the internal PLL fails for some reason. For the same reason, all the safety critical modules should run only on the safe clock. This IRC oscillator is trimmable for maintaining the clock consistency across PVT (process, voltage, and temperature).
Related Articles | Editor's Choice |
Visit Asia Webinars to learn about the latest in technology and get practical design tips.