Read-Only Memory (ROM)

A ROM's contents are fixed — or at least, not writable during normal operation — but that restriction comes with a payoff: a ROM is, structurally, nothing more than a hardware lookup table, and that makes it a genuinely different way to implement combinational logic from anything covered in Section C.

A ROM is a truth table in silicon

Feed an n-bit value into a ROM's address input, and its m-bit data output is whatever was stored at that address — which is exactly the definition of a truth table: for every combination of n input bits, a fixed m-bit output. A 2ⁿ × m ROM (2ⁿ addressable words, each m bits wide) can therefore implement any n-input, m-output combinational function whatsoever, correct by construction, simply by storing the desired output value at every address:

Address (inputs) | Data (outputs)
      A B         |    F1 F2
      0 0         |     0  1
      0 1         |     1  0
      1 0         |     1  0
      1 1         |     0  1

This is the same "read the function straight off a truth table" idea as the canonical SOP form from Boolean Algebra & Logic Gates, and the same "decoder as minterm generator" idea from Multiplexers, Decoders & Comparators — a ROM's internal structure is literally a row decoder (selecting one word line per address, exactly the row decoder from the previous page) feeding fixed connections instead of a general storage array. The tradeoff against building the same function from discrete gates is capacity, not correctness: a ROM implementation needs no logic minimization at all (unlike the K-map work from Logic Minimization) but its size grows as 2ⁿ, doubling with every additional input — fine for a handful of inputs, completely impractical for a function of, say, 32 inputs.

ROM types

What differs between ROM types is entirely how and when the stored data gets programmed:

Type	Programmed	Erasable	Typical use
Mask ROM	At the chip factory, baked into the silicon layout itself	No — fixed forever	High-volume parts where the data is finalized and will never change (firmware for a mass-produced fixed-function device)
PROM (Programmable ROM)	Once, by the user, by blowing internal fuses	No	Low/medium volume, data finalized just before deployment, no factory-mask turnaround needed
EPROM (Erasable PROM)	Electrically, by the user, using a floating-gate transistor that traps charge	Yes — by exposure to UV light through a quartz window, erasing the whole chip at once	Development/prototyping, before EEPROM made UV erasure unnecessary
EEPROM (Electrically Erasable PROM)	Electrically	Yes — electrically, byte by byte, no UV needed	Small amounts of persistent configuration data that occasionally needs updating in-system
Flash	Electrically	Yes — electrically, but only in larger blocks rather than byte-by-byte	Bulk non-volatile storage — firmware images, SSDs, USB drives; the dominant ROM-family technology today

The progression down this table is a steady removal of friction: from "only the factory can change it" to "the end system can rewrite it electrically, in-place, without special equipment" — each step trading some cell-density or write-granularity cost for that added flexibility. EPROM's floating-gate charge-trapping mechanism, notably, is the direct ancestor of EEPROM and Flash — the difference is purely in how the trapped charge gets removed (UV light vs. an electrical erase pulse), not in the fundamental storage mechanism.

All of these remain non-volatile — contents survive with power removed — which is the property that makes any ROM variant, not just literal mask ROM, suitable for its namesake job: holding a system's boot code or fixed configuration data, available the instant power is applied, before anything else in the system has had a chance to load or initialize it from elsewhere.

What's next

ROM implements a fixed function chosen once (however that "once" happens). The next page covers programmable logic arrays — PLA and PAL — which apply the same "wire up an array of fuses or transistors to realize an arbitrary function" idea directly to Boolean AND/OR structure, rather than to a lookup table, giving a middle ground between hand-built discrete gates and a full ROM's address-driven table lookup.