Input/Output Module Design Assignment

Computer Architecture

1. Functions of the I/O Module

1.1 Device Communication
The I/O module acts as an intermediary between the CPU and peripheral devices (keyboard, display, printer). Its key
communication functions include:

Address Recognition: Identifies which device is being accessed based on device addresses
Command Interpretation: Decodes control signals from the CPU (READ, WRITE, STATUS CHECK)
Data Translation: Converts data formats between CPU and devices (parallel/serial conversion, voltage level
matching)
Status Reporting: Provides device status information to the CPU (ready, busy, error states)

Example: When the CPU wants to read from the keyboard, the I/O module recognizes the keyboard's address, checks if data
is available, and transfers the character code to the CPU.

1.2 Data Buffering

Data buffering compensates for speed mismatches between the CPU and I/O devices:

Temporary Storage: Holds data temporarily in buffers during transfer operations

Speed Matching: Allows fast CPU to work with slower devices without waiting
Data Accumulation: Collects data until sufficient amount is available for efficient transfer
Burst Transfers: Enables rapid data transfer when buffer is full or empty

Buffer Types Used:

FIFO (First-In-First-Out): Used for keyboard input and printer output - maintains data order
Circular Buffers: Efficient memory usage for continuous data streams from display

Example: Printer buffer holds multiple print jobs, allowing CPU to continue other tasks while printer operates at its slower
mechanical speed.

1.3 Interrupt Handling

The I/O module manages interrupts to enable efficient asynchronous I/O operations:

Interrupt Generation: Signals CPU when device requires attention (data ready, operation complete, error)
Interrupt Request Lines: Maintains separate interrupt request signals for each device
Priority Management: Determines which device gets serviced first when multiple interrupts occur
Vector Information: Provides interrupt vector to CPU for quick handler identification

Example: Keyboard generates interrupt when key is pressed, allowing CPU to immediately process input without
continuous polling.
1.4 Device Control

The I/O module controls device operations based on CPU commands:

Command Execution: Initiates device operations (start printing, clear display, read keyboard)
Timing Control: Generates proper timing signals for device operation
Error Detection: Monitors devices for error conditions (paper jam, display failure)
Device Initialization: Configures devices at system startup
Status Management: Maintains current state of each device (idle, busy, error)

2. Block Diagram of the I/O Module

┌─────────────────────────────────────────────────────────────────────
│ I/O MODULE │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ CONTROL LOGIC │ │
│ │ • Command Decoder • Status Register │ │
│ │ • Timing Generator • Device Selector │ │
│ └──────────┬────────────────────────────────────┬─────────────┘ │
│ │ │ │
│ ↓ ↓ │
│ ┌──────────────────────┐ ┌───────────────────────┐ │
│ │ INTERRUPT LOGIC │ │ ADDRESS DECODER │ │
│ │ • Priority Encoder │ │ • Device Selection │ │
│ │ • IRQ Generator │ │ • Port Mapping │ │
│ │ • Vector Table │ └───────────────────────┘ │
│ └──────────┬───────────┘ │
│ │ │
├─────────────┼───────────────────────────────────────────────────────
│ CPU BUS │ │
│ Interface │ │
├─────────────┴───────────────────────────────────────────────────────
│ ↕ (Data, Address, Control Signals) │
└─────────────┬───────────────────────────────────────────────────────
│
┌────────┴────────┬───────────────┬──────────────┐
↓ ↓ ↓ ↓
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌──────────────┐
│ KEYBOARD │ │ DISPLAY │ │ PRINTER │ │ BUFFER │
│ INTERFACE │ │ INTERFACE │ │ INTERFACE │ │ MANAGEMENT │
├─────────────┤ ├─────────────┤ ├─────────────┤ ├──────────────┤
│ • Scan Code │ │ • Video RAM │ │ • Print │ │ KEYBOARD: │
│ Decoder │ │ Buffer │ │ Buffer │ │ FIFO (16B) │
│ • Debounce │ │ • Character ││ • Data │ │ │
│ Logic │ │ Generator │ │ Formatter │ │ DISPLAY: │
│ • IRQ Gen │ │ • Sync Gen │ │ • Status │ │ Circular │
│ • Status │ │ • DMA Ctrl │ │ Monitor │ │ (2KB) │
│ Register │ │ • IRQ Logic │ │ • IRQ Logic │ │ │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ PRINTER: │
│ │ │ │ FIFO (256B) │
↓ ↓ ↓ └──────────────┘
┌────────┐ ┌────────┐ ┌────────┐
 │Keyboard│ │Monitor │ │Printer │
│ (PS/2) │ │ (VGA) │ │(Parallel)│
└────────┘ └────────┘ └────────┘

Key Components Description:

Control Logic:

Command Decoder: Interprets CPU commands (READ, WRITE, TEST)

Timing Generator: Creates timing signals for device synchronization
Status Register: Holds current status of all devices
Device Selector: Routes data to/from appropriate device

Interrupt Logic:

Priority Encoder: Resolves multiple simultaneous interrupts

IRQ Generator: Creates interrupt request signals to CPU
Vector Table: Stores interrupt vector addresses

Device Interfaces:

Keyboard: Converts scan codes, handles debouncing

Display: Manages video buffer, generates sync signals
Printer: Formats data, monitors print status

Buffer Management:

Separate buffers for each device type

FIFO for sequential devices (keyboard, printer)
Circular buffer for display (continuous refresh)

3. Interrupt Handling Mechanism

3.1 Interrupt Generation

Each device interface contains interrupt generation logic that monitors specific conditions:

Keyboard Interrupt Conditions:

Key pressed (scan code available in buffer)

Buffer full (overflow warning)

Display Interrupt Conditions:

Frame complete (vertical sync)

Buffer empty (underflow warning)
DMA transfer complete

Printer Interrupt Conditions:

Ready for next byte

 Print job complete
Error conditions (paper out, jam, offline)

Generation Process:

Device Event → Status Check → Interrupt Enable Check → IRQ Signal

3.2 Interrupt Prioritization

The I/O module implements a priority-based interrupt system using hardware priority encoder:

Priority Levels (Highest to Lowest):

1. Keyboard (Priority 1): Highest priority for immediate user interaction

2. Display (Priority 2): High priority to prevent screen flickering
3. Printer (Priority 3): Lower priority as printing can be delayed

Priority Resolution:

Multiple IRQs → Priority Encoder → Highest Priority IRQ → Vector Generation

Prioritization Logic:

If keyboard and printer interrupt simultaneously, keyboard is serviced first

Display interrupts can preempt printer service but not keyboard
Non-maskable interrupts (NMI) override all device interrupts

Example Scenario:

Time T0: Printer IRQ (Priority 3) occurs

Time T1: CPU begins printer interrupt handler
Time T2: Keyboard IRQ (Priority 1) occurs
Time T3: CPU suspends printer handler, services keyboard (nested interrupt)
Time T4: Keyboard service complete, resume printer handler

3.3 Interrupt Handling Routine

Complete Interrupt Handling Flow:

 Step 1: INTERRUPT OCCURS
Device sets IRQ line HIGH
↓
Step 2: INTERRUPT RECOGNITION
CPU completes current instruction
Checks interrupt enable flag
↓
Step 3: INTERRUPT ACKNOWLEDGMENT
CPU sends INTA (Interrupt Acknowledge) signal
CPU saves current state (PC, flags) on stack
↓
Step 4: VECTOR ACQUISITION
I/O module places interrupt vector on data bus
CPU reads vector to determine handler address
↓
Step 5: HANDLER EXECUTION
CPU jumps to Interrupt Service Routine (ISR)
ISR saves additional registers
↓
Step 6: DEVICE SERVICING
ISR reads/writes device data
ISR performs required processing
ISR clears interrupt flag in device
↓
Step 7: RETURN FROM INTERRUPT
ISR restores saved registers
CPU executes IRET instruction
CPU restores saved state (PC, flags)
Program continues from interruption point

Interrupt Service Routine Structure (Pseudocode):

 ISR_Keyboard:
PUSH all registers // Save context
READ keyboard buffer // Get scan code
CONVERT to ASCII // Process data
STORE in application buffer // Save for application
CLEAR interrupt flag // Acknowledge device
POP all registers // Restore context
IRET // Return from interrupt

Timing Diagram:

CPU Execution: [Main Program] | [Save State] | [ISR] | [Restore] | [Continue]

↑ ↑
Device IRQ: ────────────────┐ └──────────────────
└──────────────────────
Time: ←─Latency→ ←──Service Time→

4. I/O Techniques: Trade-offs Analysis

4.1 Programmed I/O (Polling)

Description: CPU continuously checks device status until ready, then transfers data.

Implementation:

LOOP:
READ device status
IF device NOT ready THEN
GOTO LOOP
ENDIF
TRANSFER data

Advantages:

Simple to implement (no special hardware required)

Predictable behavior (no asynchronous events)
Low hardware cost
 Suitable for simple, dedicated systems

Disadvantages:

Extremely wasteful of CPU time (busy waiting)

CPU cannot perform other tasks while polling
Poor for multiple devices (must poll each sequentially)
Inefficient for slow devices (printer: CPU waits milliseconds)
Not suitable for asynchronous events (keyboard input)

Best Use Case: Single slow device, simple embedded systems, real-time systems with timing constraints

Performance Example: For keyboard input at 10 chars/second, CPU might waste 99.9% of time polling!

4.2 Interrupt-Driven I/O

Description: Device signals CPU when ready; CPU services interrupt asynchronously.

Implementation:

Main Program executing...

↓
[Interrupt Occurs]
↓
Save state → Execute ISR → Restore state
↓
Continue main program

Advantages:

CPU free to execute other tasks (no busy waiting)

Efficient for multiple devices (each interrupts independently)
Responsive to asynchronous events
Good for moderate data rates
Better CPU utilization (90-99% improvement over polling)

Disadvantages:

Interrupt overhead (context switching takes time: 2-50 microseconds)

Complex software design (ISRs, priority management)
Interrupt latency (delay before service)
Not efficient for high-speed devices (interrupt per byte is costly)
Potential for interrupt overload with many devices

Best Use Case: Multiple moderate-speed devices (keyboard, printer, serial ports)

Performance Metrics:

Context switch overhead: ~50 clock cycles

 Interrupt latency: 1-10 microseconds
Suitable for data rates: 1KB/s to 1MB/s

4.3 Direct Memory Access (DMA)

Description: DMA controller transfers data directly between device and memory without CPU intervention.

Implementation:

CPU: Initializes DMA (address, count, direction)

DMA: Transfers block of data directly to/from memory
DMA: Interrupts CPU when transfer complete
CPU: Processes completion interrupt

Advantages:

Maximum CPU efficiency (CPU free during entire transfer)

Extremely high data transfer rates (limited by bus speed)
One interrupt per block instead of per byte
Ideal for bulk data transfers (disk, display, network)
Reduces system bus contention (intelligent DMA controllers)

Disadvantages:

Expensive (requires DMA controller hardware)

Complex design (arbitration logic, bus mastering)
Potential bus contention (DMA and CPU compete for bus)
Overkill for low-speed devices (keyboard doesn't need DMA)
Setup overhead (not worth it for small transfers)

Best Use Case: High-speed bulk transfers (disk I/O, video display, network packets)

Performance Metrics:

Transfer rate: Up to bus speed (100MB/s - 1GB/s)

CPU involvement: Only setup and completion (<1% overhead)
Minimum efficient transfer: >256 bytes

4.4 Comparative Analysis for Our Three Devices

Keyboard (Recommended: Interrupt-Driven I/O):

Low data rate (10-100 bytes/second)

Asynchronous, unpredictable events
Requires fast response (user experience)
Polling: Wastes CPU time
Interrupt: Perfect fit - responsive, efficient
DMA: Overkill, excessive overhead for single bytes

Display/Monitor (Recommended: DMA):

 Very high data rate (60 frames/second × 1920×1080 = 124MB/s for Full HD)
Continuous, bulk data transfers
Real-time requirements
Polling: Impossible - too much data
Interrupt: Too much overhead (millions of interrupts/second)
DMA: Ideal - transfers frame buffer efficiently with minimal CPU load

Printer (Recommended: Interrupt-Driven I/O or DMA depending on speed):

Moderate data rate (1KB/s - 1MB/s depending on printer type)

Bursty transfers (print jobs)
Can tolerate some latency
Dot Matrix/Inkjet (slow): Interrupt-driven (interrupt per line or buffer)
Laser/Network Printer (fast): DMA (transfer entire page at once)
Polling: Wasteful as printing is slow

4.5 Hybrid Approach for Our I/O Module

Optimal Design:

┌───────────┬──────────────────┬────────────────────────┐
│ Device │ Primary Method │ Justification │
├───────────┼──────────────────┼────────────────────────┤
│ Keyboard │ Interrupt-Driven │ Low rate, async events │
│ Display │ DMA + Interrupt │ High rate, bulk data │
│ Printer │ Interrupt-Driven │ Moderate rate │
└───────────┴──────────────────┴────────────────────────┘

Performance Comparison Table:

╔══════════════╦═══════════╦═══════════╦═════════╗
║ Metric ║ Programmed║ Interrupt ║ DMA ║
╠══════════════╬═══════════╬═══════════╬═════════╣
║ CPU Overhead ║ 95-99% ║ 5-10% ║ <1% ║
║ Response Time║ Poor ║ Good ║ Fair ║
║ Throughput ║ Low ║ Medium ║ High ║
║ Complexity ║ Simple ║ Medium ║ Complex ║
║ Hardware Cost║ Low ║ Medium ║ High ║
╚══════════════╩═══════════╩═══════════╩═════════╝
5. Detailed Design Specifications
5.1 Buffer Specifications

Keyboard Buffer (FIFO, 16 bytes):

Size: 16 bytes (accommodates burst typing)

Type: Circular FIFO
Full condition: Generates interrupt warning
Empty condition: Normal state

Display Buffer (Circular, 2KB):

Size: 2048 bytes (multiple scan lines)

Type: Circular buffer with dual-port access
Refreshed: 60 times per second
DMA access for bulk updates

Printer Buffer (FIFO, 256 bytes):

Size: 256 bytes (one or more lines)

Type: FIFO queue
Full condition: Signals CPU to pause
Empty condition: Printer idle

5.2 Interrupt Vector Table

╔═══════════════╦════════════╦══════════════════════╗
║ Device ║ Vector Addr║ Handler Address ║
╠═══════════════╬════════════╬══════════════════════╣
║ Keyboard ║ 0x20 ║ ISR_Keyboard (0x1000)║
║ Display ║ 0x21 ║ ISR_Display (0x1100) ║
║ Printer ║ 0x22 ║ ISR_Printer (0x1200) ║
║ Error/Timeout ║ 0x2F ║ ISR_Error (0x1F00) ║
╚═══════════════╩════════════╩══════════════════════╝

5.3 Control Signals

CPU to I/O Module:

Address Bus (16 bits): Device selection

Data Bus (8 bits): Data transfer
READ: Read from device
WRITE: Write to device
IO/M: I/O vs Memory operation
RESET: Initialize all devices
I/O Module to CPU:

IRQ: Interrupt request

READY: Device ready/busy
ERROR: Error condition

6. Conclusion
This I/O module design provides an efficient, scalable solution for managing keyboard, display, and printer devices. Key
design decisions include:

1. Interrupt-driven architecture for keyboard and printer ensures responsive, efficient operation
2. DMA support for display enables high-bandwidth video refresh without CPU overhead
3. Priority-based interrupt handling ensures critical devices (keyboard) receive immediate attention
4. Appropriate buffering for each device type balances memory usage with performance
5. Hybrid I/O approach leverages the strengths of each technique for optimal system performance

The design achieves excellent CPU utilization (>95% available for application processing) while maintaining responsive I/O
operations and supporting future expansion to additional devices.

Design Summary Statistics:

Total Hardware Cost: Moderate (DMA controller is main expense)

CPU Overhead: <5% for all I/O operations
Interrupt Latency: <10 microseconds
Maximum Throughput: Limited by bus speed (~100MB/s)
Scalability: Can support up to 16 devices with current architecture