In Harvard architecture, it’s common for instruction and data memories to have different word lengths, meaning the number of bits used to store each unit of data can vary between the two. This flexibility is an advantage of the architecture. For instance, instructions might be stored as 16-bit or 32-bit words, while data might be stored in smaller or variable sizes such as 8-bit, 16-bit, or even single bits in the case of flags or Boolean values. The processor handles each memory independently, with its own address and data buses that are configured for the correct word size. This allows systems to optimise memory use—large, complex instructions can be stored efficiently without wasting memory for smaller data values. This design is particularly useful in embedded systems and digital signal processors, where space and power efficiency are key. The control unit ensures that the word lengths are interpreted correctly for each type of memory transaction.

In traditional Harvard architecture, the instruction memory is typically non-volatile and read-only during normal operation. This means the processor cannot modify program code while the system is running. The advantage is improved security and stability, especially for embedded systems that must perform fixed tasks consistently. However, in more flexible or modern systems, such as those using a modified Harvard architecture, the processor may have limited or controlled access to instruction memory. For example, in microcontrollers with flash memory, the system can write new instructions during a firmware update, but this requires special routines and is not part of normal execution. During everyday operation, the processor executes instructions without altering them, reducing the risk of accidental corruption. This approach is ideal for applications like medical devices or automotive controls, where software must remain unchanged once deployed. Updates, if needed, are handled through reprogramming modes, often while the device is offline.

In a Harvard system, handling interrupts or external events typically involves a dedicated interrupt handling routine stored in the instruction memory. When an interrupt occurs—such as a signal from an external sensor or an error condition—the control unit temporarily suspends the current execution flow and jumps to a predefined memory location where the interrupt service routine (ISR) is stored. Because the instruction memory is separate from data memory, fetching the ISR does not interfere with ongoing data operations. This allows fast and predictable response times, which is essential in real-time systems. Harvard systems usually include a vector table at the beginning of instruction memory, where addresses of various ISRs are stored. These addresses are hardcoded or loaded during initialisation, so the processor knows exactly where to jump. Since instructions cannot be modified at runtime, these routines are static and secure, preventing unauthorised changes during critical system events.

Yes, it is entirely possible to use the same underlying memory technology—such as SRAM, DRAM, ROM, or Flash—for both instruction and data memory in a Harvard system. However, the physical and logical separation of the two types of memory remains essential. The choice of memory type depends on the system’s needs. For instance, instruction memory is often implemented using non-volatile memory like ROM or Flash to store permanent program code, while data memory is typically volatile RAM to allow for frequent reading and writing during execution. Using the same memory technology can simplify manufacturing and reduce costs, particularly in embedded systems with tight space or budget constraints. However, the memory controller and bus architecture must still treat the two regions separately, allowing for independent access and bus signalling. The important distinction is not the type of hardware used, but rather how that memory is addressed, accessed, and managed by the CPU and control unit.

Harvard architecture is generally not suitable for systems that rely on self-modifying code or frequent dynamic loading of instructions, because instruction memory is typically read-only during runtime. This means the CPU cannot overwrite existing instructions or load new ones directly into executable memory. Systems that require dynamic instruction loading—like modern desktop operating systems that load libraries and modules on the fly—are better suited to Von Neumann or hybrid architectures where memory is unified. However, some modified Harvard systems introduce programmable instruction memory using Flash or EEPROM, enabling the processor to write new instructions in controlled situations, such as during firmware updates or staged loading. This process usually requires disabling normal execution, copying the new code into a staging area, and then resetting the execution flow. Even then, safeguards are in place to prevent corruption. As such, Harvard architecture is preferred in environments where the code remains static after deployment, supporting predictable and secure execution.