Automotive Designs Have No Room for Error
Automotive designs demand a high level of fault tolerance, and one of the methods to achieve this is to use error correcting codes (ECC).
This Wikipedia https://en.wikipedia.org/wiki/ECC_memory gives a flavour, though that article concentrates on memory and we are interested in wider applications using a form of forward error correction https://en.wikipedia.org/wiki/Error_correction_code. This technique can be applicable to both memories (to detect and or correct data storage errors) and interconnect busses (to detect and or correct transmission errors). There are various levels of protection possible, and for automotive the choice of SECDED (Single Error Correction, Dual Error Detection) is popular. There are however multiple ways to implement this, such as choices of word size and particular error correcting code. There are trade-offs between efficiency (in terms of the number of extra bits required for the coding), degree of protection, and latency to consider.
At first glance, the selection of automotive-qualified IP incorporating ECC features would seem to be a boon for the designer of an automotive system on chip. It conjures the idea that one can just buy the parts and plug them together. However, there are many factors to consider, and traps for the unwary. The use of ‘end-to-end’ ECC for a data route between two IP blocks in attractive in terms of simplicity and efficiency, but only works if the IPs at each end support the same code and operate at the same word size. Unfortunately, they often don’t. Furthermore, even when the two ends of a data route are compatible, the Network on Chip (NoC) that routes data between them may combine or split the data transactions into larger or smaller word sizes for good reasons of address alignment and network performance and/or protocol conversion.
An additional challenge to deal with is to be sure that the various IPs uses the same equations. SECDED could be performed in different ways. So, one will then need to adapt the two ends preserving the encoding / decoding equations with the issue that the code is owned by different IP providers. This forces the usage of dedicated bridges knowing encoding to decode and correct.
Whilst that is what a NoC is supposed to do, this can eliminate the possibility of end-to-end ECC altogether. In those circumstances, it may be necessary to encode and decode the ECC protection several times in different ways as the data makes its way around the SoC. This adds a great deal of complexity, not only to implementation, but to verification. On the plus side to trade this off, it also adds more protection because if you have multiple independent stages of error correction, you can cope with more errors.
This is just one of the many complexities that have to be considered when designing ultra-complex custom chips for automotive applications. We have years of experience in this area with skilled engineers who know exactly how to design automotive chips that will ensure that IP blocks work together as described above. We have just taped out such a design for a Tier 1 automotive company so, if you want an automotive design where all the errors are correctly corrected, contact us now using this link. https://www.sondrel.com?utm_source=sondrel&utm_medium=blog&utm_campaign=ecc&id=1000