Computer Organization and Design

Course Description

Computer Organization and Design examines basic computer systems design and architecture, covering computer memory design, central processing units, input/output devices, buses, and addressing schemes.

Within the SCNS taxonomy, CDA is the Computer Design and Architecture prefix, and the 4000-level number places this in the upper division. Daytona State publishes it at 3 credits, prerequisites CET1112C or CET3116, offered fall and spring, giving approximately 45 contact hours.

This is the course that explains why software behaves the way it does. Most computing coursework treats the machine as an abstraction that executes instructions; this one opens it. Performance, memory behaviour, concurrency bugs, and an entire class of security vulnerabilities are only comprehensible from below the abstraction, which is why architecture remains a required course decades after most programmers stopped writing assembly.

Learning Outcomes

Required Outcomes

• Describe the major components of a computer system and how they interconnect.
• Represent and convert data in binary, hexadecimal, and other number systems.
• Describe signed integer representation and two's complement arithmetic.
• Describe floating-point representation and its precision limitations.
• Describe character encoding schemes.
• Apply Boolean algebra and design combinational logic circuits.
• Describe sequential logic, flip-flops, registers, and counters.
• Describe instruction set architecture and the distinction between architecture and implementation.
• Describe instruction formats, operands, and addressing modes.
• Read and write simple assembly language programs.
• Trace the fetch-decode-execute cycle through a datapath.
• Describe CPU organization, including the datapath and control unit.
• Describe the arithmetic logic unit and its operations.
• Describe pipelining, its performance benefit, and its hazards.
• Describe the memory hierarchy and the rationale for it.
• Describe cache organization, mapping schemes, and replacement policies.
• Calculate cache hit rates and effective access times.
• Describe virtual memory, paging, and address translation.
• Describe bus architecture, arbitration, and system interconnect.
• Describe input/output methods, including programmed I/O, interrupts, and direct memory access.
• Describe secondary storage organization and characteristics.
• Evaluate performance using appropriate metrics and describe the limits of speedup.
• Describe parallelism, multicore organization, and cache coherence at an introductory level.

Optional Outcomes

• Describe RISC and CISC design philosophies and their convergence.
• Describe superscalar and out-of-order execution.
• Describe branch prediction and speculation.
• Describe microarchitectural security vulnerabilities.
• Describe GPU and accelerator architecture.
• Describe embedded and low-power design considerations.

Major Topics

Required Topics

• System components and interconnection
• Number systems and data representation
• Two's complement arithmetic
• Floating point and precision
• Character encoding
• Combinational logic design
• Sequential logic and storage elements
• Instruction set architecture
• Instruction formats and addressing modes
• Assembly language
• The fetch-decode-execute cycle
• CPU datapath and control
• The arithmetic logic unit
• Pipelining and hazards
• The memory hierarchy
• Cache organization and mapping
• Cache performance calculation
• Virtual memory and address translation
• Buses and system interconnect
• I/O: programmed, interrupt-driven, and DMA
• Secondary storage
• Performance metrics and speedup limits
• Parallelism and multicore

Optional Topics

• RISC and CISC
• Superscalar and out-of-order execution
• Branch prediction and speculation
• Microarchitectural security
• GPUs and accelerators
• Embedded and low-power design

Resources & Tools

• Computer Organization and Design (Patterson & Hennessy) — the standard text and the one the course title echoes. Available in MIPS, ARM, and RISC-V editions; use whichever your course assigns.
• Computer Organization and Architecture (Stallings) — the common alternative, broader and less hardware-focused.
• Nand2Tetris (nand2tetris.org) — free, and outstanding: you build a working computer from logic gates upward. The single best way to make this material concrete.
• MARS or RARS — free MIPS and RISC-V simulators with visual register and memory views; essential for the assembly component.
• Logisim Evolution — free digital logic simulator for building and testing circuits.
• RISC-V specifications (riscv.org) — free and open; increasingly the teaching architecture because the documentation is accessible.
• Godbolt Compiler Explorer (godbolt.org) — free, and it shows the assembly a compiler generates from your source in real time. Genuinely illuminating.
• Agner Fog's optimization manuals — free, detailed, and the practical bridge from architecture to performance.
• A breadboard and logic ICs, if your programme includes hardware work — cheap and instructive.

Career Pathways

• Embedded systems developer — architecture knowledge is a working requirement, not background.
• Systems programmer — operating systems, drivers, and runtime work.
• Performance engineer — a well-paid specialization that depends directly on understanding the memory hierarchy.
• Firmware and hardware-adjacent software engineer.
• Computer hardware engineer — with an engineering degree.
• Security researcher — exploitation and defence both require understanding memory layout and microarchitecture.
• Test and validation engineering — hardware and firmware verification.
• Aerospace and defence computing — Florida's Space Coast has a real embedded and avionics sector.
• General software development — architecture literacy separates developers who can diagnose a performance problem from those who can only guess at it.
• Graduate study — a standard prerequisite for computer engineering and systems research.
• SOC codes 15-1252 Software Developers, 17-2061 Computer Hardware Engineers, and 15-1241 Computer Network Architects.

Special Information

⚠ The memory hierarchy is why your fast code is slow

The single most practically valuable idea in the course, and the one that changes how a student writes software.

Processors have been far faster than main memory for decades, and essentially all of modern computer design is an elaborate response to that gap. The hierarchy — registers, multiple cache levels, main memory, storage — exists to hide latency, and it works only when programs exhibit locality.

• The cost difference is enormous. A register access, a cache hit, and a main memory access differ by orders of magnitude, and a page fault to storage is another world entirely. Instruction counts are a poor proxy for performance.
• Temporal and spatial locality are what caching exploits — recently used data is likely to be used again, and nearby data is likely to be used soon. Programs that respect this are fast; programs that do not are slow for reasons invisible in the source code.
• The classic demonstration: traversing a two-dimensional array in row-major order versus column-major order executes the same number of operations and can differ in runtime by a large factor, purely because one pattern uses each cache line fully and the other discards most of it.
• Data structure layout matters. An array of structures and a structure of arrays contain the same data and perform very differently depending on the access pattern.
• Pointer chasing defeats prefetching. Linked structures scattered across memory are slow in ways that a complexity analysis does not capture — which is why an O(n) array scan frequently beats an O(log n) tree traversal at realistic sizes.
• Measure rather than assume. Profilers and cache performance counters exist because intuition about performance is unreliable.

The general lesson: asymptotic complexity is necessary and not sufficient. Constants are determined by the machine, and this course is where you learn what determines them.

⚠ Abstractions leak — and the leaks are where the interesting bugs live

The conceptual payoff of studying architecture in a curriculum otherwise built on abstraction.

• Floating point is not real arithmetic. Values have limited precision, addition is not associative, and comparing floats for equality is a defect. Every developer meets this and only those who have studied representation understand why.
• Integer overflow is defined by the representation. Two's complement wraparound produces results that are perfectly logical from below and surprising from above — and it has caused real failures, including in safety-critical systems.
• Alignment and padding explain why a structure's size is not the sum of its members, and why some architectures fault on unaligned access.
• Endianness matters the moment data crosses a machine boundary or a file format.
• Concurrency bugs are architectural. Memory reordering, cache coherence, and the absence of a global instruction order mean that multithreaded code can behave in ways the source text does not suggest. Memory models exist because of this.
• Undefined behaviour in languages like C is undefined precisely because it permits architecture-dependent implementation, and reasoning about it requires knowing what the machine does.

The framing worth carrying: higher-level languages hide the machine successfully most of the time. The value of this course is being able to reason about the cases where they do not — which are disproportionately the hard bugs.

⚠ Architecture became a security subject

A development that moved microarchitecture from a performance topic to a security one, and it is recent enough that older courses skip it.

• Speculative execution vulnerabilities — the Spectre and Meltdown class disclosed in 2018 and their successors — demonstrated that performance optimizations invisible to software can leak data across security boundaries. The processor speculates, discards the wrong path architecturally, and leaves microarchitectural traces that can be measured.
• The significance is conceptual as much as practical: the abstraction boundary that security models relied on turned out to be permeable, and mitigations have real performance costs.
• Cache timing side channels are a general technique — the time a memory access takes reveals whether the data was cached, which reveals what has been accessed. Cryptographic implementations must be written to be constant-time for exactly this reason.
• Memory layout underpins classical exploitation. Buffer overflows, stack layout, return addresses, and the mitigations against them — ASLR, stack canaries, non-executable memory — are all architectural, and understanding them requires this material.
• Rowhammer showed that repeatedly accessing memory can flip bits in adjacent rows — a physical property of DRAM with security consequences.
• Trusted execution environments and hardware security features are now part of the architecture, and their guarantees depend on microarchitectural details.

Career note: security work that goes beyond configuration requires this understanding. It is one of the clearer cases where an upper-division architecture course maps directly onto a well-paid specialization.

⚠ Write assembly, even though you never will professionally

Practical guidance on how to get value from the part of the course students most resist.

• Nobody is training you to be an assembly programmer. The point is that writing assembly is the only way to genuinely understand the instruction set, the datapath, and what a compiler is doing.
• Use a simulator with visible state. MARS and RARS are free and show registers and memory changing instruction by instruction — watching the fetch-decode-execute cycle happen makes the abstraction concrete in a way that a diagram does not.
• Trace by hand. Step through a short program on paper, updating registers yourself. It is tedious and it is how the model gets built.
• Use Compiler Explorer. Writing a small function in C and watching the generated assembly change as you alter the source or the optimization level is the most efficient way to connect the two levels, and it is free.
• Build something from gates. Nand2Tetris takes you from a NAND gate to a working computer running a program you wrote. It is free, it is a substantial time investment, and students who do it never find this material mysterious again.
• Do the cache calculations by hand until the mapping schemes are automatic — direct-mapped, set-associative, and fully associative behave differently and the differences are examinable and practically consequential.

⚠ Only about three Florida institutions carry this number — hedge accordingly

This course appears at roughly three institutions statewide. Content, credit value, and emphasis vary more than they would for a widely taught course. Read your own institution's catalog description and syllabus rather than assuming this guide describes your section exactly, and have any transfer evaluated in writing.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement.

CDA4101 is a lecture course, 3 credits and approximately 45 contact hours, offered fall and spring. Expect problem-based assessment — number representation, logic design, cache and performance calculations, and assembly programming — with some programmes adding a simulator or hardware project.

CDA4101 is upper division: a lower-division introduction to computing will not substitute. Students arriving from an A.S. should note that A.S. degrees are applied and do not carry the A.A.'s guaranteed junior-status transfer, though Florida institutions publish B.S. in Information Technology and Engineering Technology pathways designed for that population.