Units: 1.0 CU
Terms: Spring 2017 (first offering)
When: MW 3--4:30pm
Where: Towne 303
Instructor: DeHon (office hours
T4:15pm-5:30pm, Levine 270)
TA: Hans Giesen
(Lab Hours Tuesday, Thursday 6-7pm, Ketterer)
|Graduate||working knowledge of
[Relation to other courses]
Catalog Level Description:
Motivation, design, programming, optimization, and use of modern
System-on-a-Chip (SoC) architectures. Hands-on coverage of the breadth of
computer engineering within the context of SoC platforms from gates to
application software, including on-chip memories and communication
networks, I/O interfacing, RTL design of accelerators, processors,
concurrency, firmware and OS/infrastructure software. Formulating parallel
decompositions, hardware and software solutions, hardware/software
tradeoffs, and hardware/software codesign. Attention to real-time
By the end of theh course, you will be able to:
- design, optimize, and program a modern System-on-a-Chip.
- (i) analyze a computational task, (ii) characterize its computational requirements, (iii) identify performance bottlenecks, (iv) identify, explore, and evaluate a rich design space of solutions, and (v) select and implement a design that meets engineering requirements.
- decompose the task into parallel components that cooperate to solve the problem.
- characterize and develop real-time solutions.
- implement both hardware and software solutions, how to formulate hardware/software tradeoffs, and how to perform hardware/software codesign.
- understand the system on a chip from gates to application software, including on-chip memories and communication networks, I/O interfacing, RTL design of accelerators, processors, firmware and OS/infrastructure software.
- understand and estimate key design metrics and requirements including area, latency, throughput, energy, power, predictability, and reliability.
Architectural building blocks and heterogeneous architecture,
Hardware-Software Codesign, Embedded Software, Interfacing, Computational
requirements and system analysis, Concurrency, Real Time, Design-space
formulation and exploration, Costs and metrics (energy, area, runtime,
reliability, predictability), Quantitative design and analysis.
Rough Syllabus Plan
- Overview, scope, methodology
- Metrics and bottlenecks
- Computational models
- Data parallel microarchitectures (SIMD, Vector, GPU)
- Thread-level Parallelism and virtualization
- Real-time, reactive
- Spatial computations, basic mapping from high-level
- Fine-grained parallelism microarchitectures (FSMD, VLIW)
- High-level synthesis (C-to-gates, resource selection and provisioning)
- On-chip networking / Network-on-Chip
- VLSI technology and scaling
- Defect and fault tolerance
This course will include a substantial project running throughout term.
Students work in groups of 2. Platform will be an SoC-FPGA (e.g.,
Xilinx Zynq or Intel/Altera Arria), allowing the provisioning of soft-core
processors, accelerators, and memory in addition to the use of the
embedded SoC logic. It will start with a significant task (like video
acquisition, processing, compression, networking). Course starts by
running the task on single processor and identify resource requirements.
Then, it will deal with I/O for task.
It then migrates the task to multiple processors to accelerate. After
ther, it develops custom accelerators for task and integrate with
networked processor. The final half of the course is an open-ended
optimization project using the techniques and design options introduced in the course.
Grading is based on:
- Design Project [50%]
- Weekly Assignments [20%]
- Midterm [10%]
- Final [20%]
Writeups must be done in electronic form and submitted through
Canvas (below). Use CAD or drawing
tools where appropriate. Handwritten assignments and
hand-drawn figures are not acceptable.
Each individual should turn in a homework or project writeup.
The specific homework assignments will specify what portion of the writeup
can be performed jointly and what part should be individual. Even if the
entire assignment is done jointly, we will still expect individual
submissions (both students submit identical PDFs, if it is appropriate for
that project or homework assignment).
All assignments will be turned in electronically through the Penn Canvas
website. Log in to canvas with your PennKey and password, then select ESE 532 from the Courses and Groups dropdown menu.
Select Assignments from the links on the left and select the assignment you
wish to submit for. Submission should be as a single file (preferably
Assignments must be turned in by the published due date to receive credit.
We will grant each student 3 free late days for the course of the entire
term. That means you could, for example, turn in three assignments one day late each or
one assignment 3 days late and still receive full credit. The quantum for
free late days is a day, so you cannot turn in every assignment 6 hours
late and receive full credit.
Students are allowed and encouraged to help each other with the Xilinx
tools (SDSoC, SDK, Vivado, Vivado HLS, Windows, Linux) used for the course, but are disallowed from developing collaborative
design solutions (C-code, pragmas, design and analysis) outside of identified project groups. Within a project group,
the assignment will specify what part should be done as a group and what
part should be done individually.
- Tools---We know the tools are complex and the documentation
often dense or inadequate, and we won't be surprised if they are buggy.
It will likely be necessary to collaborate as a class on figuring out how
to best use the tools for the term. We encourage students to help each
other and share what they learned. We will award bonus points for
student-developed instructions and tutorials on how to solve common
tasks that arise for the tools.
- Design Solutions---Each team (or individual where specified)
should develop their own solutions to the design problem and their own
implementations. You are taking this class to develop these skills, and
we believe you need to work out the solutions on your own to master the
skills. You cannot share code, diagrams, specific pragma settings,
plots, analysis, metrics, or other results. You cannot share problem
- HLS Pragmas---HLS Pragmas sit at the border between
where collaboration is allowed and not allowed. You are allowed to help
make each other aware of the existence of pragmas and the syntax for
pragmas. You are not allowed to tell each other what pragma values and
settings best solves the problem---you should be reasoning through what
the settings mean and how they impact the code mapping, and you should be
performing your own experiments in your project teams. You are
allowed to say where a pragmas goes syntatically (e.g., relative to function
header, relative to loop header), but are not allowed to suggest which
function or loop would benefit from a specific pragma.
In general, you are expected to abide by Penn's
Code of Academic Integrity. If there is any uncertainty, please ask.
Use the Penn Course Absence Report (CAR) in Penn-in-Touch to report
Make sure you call any problems with grading to our attention immediately
and not later than the next class meeting after they are returned or posted
on canvas. To submit a request for a review of a credit assignment on
a lab assignment send an email to the instructor stating the nature of the
problem and the remedy you desire. We will not consider any requests for
grade adjustments that are submitted later than the one week grace period
after the grades are posted on canvas. You are responsible for checking
your posted grades in a timely manner.
Comparison to ESE534
This will borrow or inherit about 1/3 of the material from the
ESE534. This course will not go deep into how to design a spatial
substrate (compute, interconnect), nor go deep into processor--FPGA
continuum and instruction design. If offered again, ESE534 will likely
evolve to take this course as a pre-requisite. Possibly ESE534 and 535
will merge into a single advanced, follow-on course. Note that ESE534 did
not have the kind of hands-on project that becomes a key component of this
Comparison to CIS501
This course is complementary to CIS501. This course is more focused on
custom, application-oriented design with real-time concerns, while CIS501
focuses on ISA compatibility and best-effort designs. This course assumes
you are willing to recompile and perhaps rewrite your application code; as
a result, it does not touch upon the ISA abstraction and compatibility and
will have almost nothing on dynamic ILP and pipelining of a general-purpose
processor. This course will be driven more by real-time concerns rather
than best-effort tasks, whereas CIS501 is more focused on best-effort.
This course will spend one day on the high-level benefits of memory
hierarchy, but will not dive deep into cache-design and cache-hierarchies,
which is a major component of CIS501. This course will mostly look at
non-shared memory models and architectures with, at most, a small nod to
the existence and challenges in shared memory, whereas CIS501 is mostly
focused on shared-memory models and architectures.
Last modified: Mon Mar 20 08:25:06 EDT 2017