Modified harvard architecture

ARMv8-M will retain the modified Harvard architecture since this architecture is not impeded by the bottleneck in pure von Neumann architecture and the constraint in strict Harvard architecture. ARMv8-M will only add eXecute-Only-Memory (XOM) to protect the on-chip firmware from intrusive access.

A related technique is familiar in processors classified under the other perspective of modified Harvard architecture. In those processors modified Harvard architecture means having separate address spaces for instruction and data; however, data can also be located along with instructions in the program memory. Processors under this definition of modified Harvard architecture include the 8051, AVR, Z86, ADSP-21xx, etc. Code protection by inhibiting instructions that read from (internal) program memory is provided through lock bit(s) that the user can set once the program is finalized.

XOM will complement eXecute Never (XN) which, in contrast to XOM, prevents execution from a memory area which is supposed to contain pure data.

In ARMv8-M, addresses still point to a unified memory space. Only section(s) of the memory space will be defined as XOM, the rest (of the memory space) will operate as how they worked in previous versions of ARM.

ARMv8-M will retain the modified Harvard architecture since this architecture is not impeded by the bottleneck in pure von Neumann architecture and the constraint in strict Harvard architecture. ARMv8-M will only add eXecute-Only-Memory (XOM) to protect the on-chip firmware from intrusive access.

A related technique is familiar in processors classified under the other perspective of modified Harvard architecture. In those processors modified Harvard architecture means having separate address spaces for instruction and data; however, data can also be located along with instructions in the program memory. Processors under this definition of modified Harvard architecture include the 8051, AVR, Z86, ADSP-21xx, etc. Code protection by inhibiting instructions that read from (internal) program memory is provided through lock bit(s) that the user can set once the program is finalized.

XOM will complement eXecute Never (XN) which, in contrast to XOM, prevents execution from a memory area which is supposed to contain pure data.

In ARMv8-M, addresses still point to a unified memory space. Only section(s) of the memory space will be defined as XOM, the rest (of the memory space) will operate as how they worked in previous versions of ARM.

Yes I should have said could support Harvard rather than will. There's always the problem of either loading up the code memory from flash which means there is a data path to the code memory - or executing directly from flash in which case one would really want to be able to access data there as well. So there is a data path to the code memory to which access must be restricted. This I guess is where Trustzone comes in, it must be able to restrict changes to the XOM property. I guess one could use a different address range for data access but that is messy. I look forward to seeing more details about the ARMv8-M additions and how they all fit together - I heard they loosed some hackers on it to test out the security.