1. An Integrated Approach to Teaching Computing Systems Architecture
Kishore Ramachandran
&
Bill Leahy
College of Computing
Georgia Institute of Technology

2. Outline Traditional approach Pedagogy of new approach
Where does it fit and how do we put it in practice?
Experience at Tech
Evaluating the pedagogy
Challenges
Comparison to other pedagogical models
Concluding remarks

3. Traditional Approach Stovepipe model Georgia Tech
Architecture and OS as distinct courses usually in the junior/senior years
Georgia Tech
Followed similar model until 1999
Two junior level courses one on OS and the other on architecture

4. What is wrong with the traditional approach?
Symbiotic relationship missed
High level language and instruction sets
OS abstractions and processor
Network protocols and physical network
Students get this?
Not if compartmentalized
Gap between the time when the courses are taken
Concepts forgotten
Connections not seen at all by the students most of the time

5. Why change? Problems with the traditional approach Changing CS scene
New areas evolving
Graphics, visualization, HCI
Need rethinking of “core”
UG research involvement
Need to infuse interest early
Entry level for systems research high

6. New approach Excitement of middle-school kids An integrated course
What is inside a box?
What makes it play cool music or video games?
An integrated course
Combining OS and architecture
Goal of the course
“Unraveling the box”
Take the journey together exploring hardware and the OS abstractions
Emphasize connectedness

7. Pedagogy of new approach
Present what is “inside a box”
Processor module
Memory module
I/O and storage module
Parallel module
Network module
Key differentiator
Concomitant treatment of hardware and software in each module

8. Pedagogical style
Discovery as opposed to indoctrination or instruction
Top down approach
Start with problem to be solved
Explore solution space together
Example:
What is memory management?
Understand the need first
Discover the software issues and the corresponding hardware issues
Story telling approach
Keeps the student interest alive

9. Processor module
HLL constructs and their influence on instruction-set design
Simple implementation followed by performance-conscious pipelined implementation
Process abstraction in OS and processor scheduling

10. Memory module Memory management in OS Architectural issues
Memory hierarchies

11. I/O and storage module
Program discontinuities including interrupts, traps, and exceptions
Processor mechanisms
OS mechanisms
Devices and device drivers
Emphasis on disk subsystem
Storage abstraction
File system fundamentals

12. Parallel module Introduce threads as a programming construct
OS issues for supporting parallel programming
Architectural issues for supporting parallel programming

13. Network module
Evolution of networking hardware
Network protocol stack

14. Connecting the different modules
HLL constructs lead to design of instruction-set for LC-2200
Processor implementation of LC-2200
Memory management assists to LC-2200
Interrupt and DMA support to LC-2200 ……

15. Why parallelism in a first course?
Our motivation then (circa 98)
Love affair of CS with parallelism
PL and concurrency
OS and concurrency
Enablers in the 90’s
Java, MT OS, multiple CPUs in desktops
In hindsight now
Multicore CPUs
Multithreading as a programming concept in intro courses

16. Why networking in a first course?
“box” without connectivity is no good today
Protocol stack is an integral part of any OS
Our motivation
Understand evolution of networking gear
Understand mechanisms needed in protocol stack
Understand how a “box” avails of network services

17. Where does this course fit?
Assumed knowledge
Logic design, assembly language, and C programming
New course is a first systems course
Preferably in sophomore year
What follows?
Advanced architecture, OS, networking courses
For those following other pursuits
Sufficient exposure to “core”

18. Putting this pedagogical style in practice
4 credit-hour semester course or 5-credit hour quarter course
45 hours of lecture
Roughly 9 hours for each module (some more than others)
60-90 hours of unsupervised lab time for projects

19. Experience at Georgia Tech
CS 2200 introduced in Fall 1999
Project component for each module
Concepts “get in” via projects
Collaboration allowed
Key is “learning”
Creativity in evaluation

20. Evaluating the pedagogy
CS students hardware-averse
OS and hardware together makes “sense”
Hardware design as an algorithmic exercise
Successful internships
Anecdotal evidence from industries and students
Concepts learned early apply to other domains (e.g. web caching)

21. Students better prepared for advanced courses Informal poll
At beginning of course
10% interested in the course
At end of course
Majority feel the course was useful and important
Increased interest in systems
Number of UG students doing research in systems

22. Other reasons why this is a good approach
Allows curricular innovation
GT CS has been a leader of innovation
Evidence
New ThreadsTM approach
Chapter 7, Pages , “The Right Stuff,” from THE WORLD IS FLAT: UPDATED AND EXPANDED EDITION, by Thomas L. Friedman

23. Meeting the Challenges
Textbook
Good books available for the stovepipe model
None for an integrated model
We developed comprehensive notes and slides
Used standard textbooks as background
Responding to students
Turned our courseware into online textbook in 2005
To match the style and content
Available to the community
In use for 8 consecutive semesters (including summers)

24. Adopting the pedagogical style
Online textbook
Extensive online slides
Several detailed project ideas from 7+ years of teaching this course
Several problem sets and model exams online
In short
Painless transition from stovepipe model to this one

25. Comparison to other recent pedagogical models
Patt and Patel
Logic design, assembly language, plus C
Ideal as a pre-req for our course
Bryant and O’Hallaron
Programmer’s perspective
Goal
How to create “power programmers”?
Important but different from our focus
Best applied to senior level UG
A worthy follow on to our course

26. Saltzer and Kaashoek
System building blocks that appear in different large complex software systems
Goal
How to prepare students who can create modular software systems?
A worthy follow on to our course

27. Concluding remarks
An integrated approach to teaching computer system architecture at sophomore level
Been in practice at GT for 7+ years
Online textbook, slides, project ideas, and tools available for the whole community

28. Applause!!! 

30. Project: Processor Design
Students given datapath 90% complete
Project entails
Completing the datapath
Writing micro-code for implementing LC-2200 instruction set
Circuit design using LogicWorks

31. Project: Interrupts and I/O
Students supplied with LC-2200 simulator and LC-2200 assembler
Project entails
Adding circuitry to project 1 for handling interrupts
Enhancing the simulator to deal with interrupts
Writing an interrupt handler (in LC-2200 assembly) to work with the enhanced simulator

32. Project: Virtual memory subsystem
Students supplied with a processor plus memory system simulator
Project entails
Developing a page-based VM system on top
Experimenting with different page replacement algorithms

33. Project: MT OS
Students provided with a processor plus memory system simulator
Project entails
Implementing multithreaded OS modules for managing the CPU and I/O scheduling queues
Parallel programming using pthreads
Experimenting with different CPU scheduling algorithms

34. Project: Reliable Transport Layer
Students provided with a simulated network layer
Project entails
Implementing a reliable transport that deals with
Packet corruption
Lost packets
Out-of-order delivery of packets
Parallel programming using pthreads