Posts Tagged ‘cache memory

Code partitioning in internal, external, and cached memory

The memory architecture that provides the best performance is one that only has local memory. However,this architecture is not always practical since many useful programs will exceed the available capacity of the local memory. On the other hand, running from external memory exclusively may have more than an eight times performance disadvantage due to the peripheral bus latency. Caching the external memory is an excellent choice for PowerPC. Caching the external memory in MicroBlaze definitely improves results, but an alternative method is presented that may provide optimal results.

For MicroBlaze, perhaps the optimal memory configuration is to wisely partition the program code, maximizing the system frequency and local memory size. Critical data, instructions, and stack are placed in local memory. Data cache is not used, allowing for a larger local memory bank. If the local memory is not large enough to contain all instructions, the designer should consider enabling the instruction cache for the address range in external memory used for instructions. By not consuming BRAM in data cache, the local memory can be increased to contain more space. An instruction cache for the instructions assigned to external memory can be very effective. Experimentation or profiling shows which code items are most heavily accessed; assigning these items to local memory provides a greater performance improvement than caching. One function in the Thread-Metric Basic Processing test is identified as time critical. The function’s data section (consisting of 19% of the total code size) is allocated to local memory, and the instruction cache is enabled. The 60 MHz, cached and partitioned-program system achieves performance that is 560% better than running a non-cached, non partitioned 75 MHz system using only external memory.

However, the 75 MHz system shows even more improvement with code partitioning. If the time critical function’s data and text sections (22% of the total code size) are assigned to local memory on the 75 MHz system, a 710% improvement is realized, even with no instruction cache for the remainder of the code assigned to external memory. In this one case, the optimal memory configuration is one that maximizes local memory and system frequency without cache. In other systems where the critical code is not so easily pinpointed, a cached system may perform better. Designers should experiment with both methods to determine what is optimal for their design.

Tags : , , , , , ,

XOM, a secure architecture in Embedded Systems

XOM is the acronym of eXecute Only Memory. XOM wishes to completely secure an architecture. Moreover XOM is supposed to be sure and claimed that hardware solutions are more efficient than the software ones. So XOM mostly relies on hardware mechanisms to ensure security. New primitives are provided within the OS in orderto handle key and signature manipulation. The name of the OS extension is XOMOS. The main features of XOM are : memory ciphering and hashing, data and program partitioning, interruption and context switching protection.

Each partition of the memory is associated with a secret key to decrypt its content (the session key in Figure 3). The session key is obtained with the XOM key table which establishes the connection between the session key and the secret keyof a specific partition of the memory. The secret key is also encrypted with an asymmetric encryption. The key (private keyin Figure 3) required for the asymmetric decryption is stored in the secure zone of the architecture. The use of the hash solution is classic. The signature result of the hash algorithm is compared with the original one to validate the integrity of the hashed message. In addition the data stored in cache memory is associated with an identifier. When a task wants to use adata, the identifier of the task must be the same as the data one, in that case it means the task is allowed to read and modify the data. This feature protects the system from malicious program which tries to get illegal information. XOM proposes hardware security primitives to protect cipher keys and hash signatures which are essential to guarantee the architecture durability.

Fig. 3. XOM architecture

The last point of the XOM solution concerns the preemption within the OS which has similarities with the management ofthe interruptions. The context must be saved. It is essential to store and to protect the context in order to fend off an attack who aims to change some register values. XOM ciphers and hashes the switching context which is interesting for a solution with an OS. XOMOS can be seen as an extension of a non-secure OS which brings new security primitives (ciphering and hashing).

All the protections added by the solution have a cost. The first one concerns the implementation of XOM in an existing OS. A work is necessary on the kernel to add the instructions which help for the use of the security primitives. All this work is invisible for the user of the kernel. A real overhead appears inthe cache management. The number of cache miss raises from 10 to 40%. It depends on the kernel operation. This raise is due to the information added in the cache to secure the data. Data are associated with the identifier of the task. It means some parts of the cache are used to store the identifier. The protection of the context switching also brings an increase of the number of cycles to store the context and to protect it.

 

Tags : , , , , , , , , , , , , , , , , , , , ,