Course Goals, Assessment Method and Recommendations
SYSE-595: HRDWRE SFTWR INTEGR
By John Blyler (Instructor), Sum’08
I. Instructor Goals
Week 1 Goals: To provides a review of basic system engineering concepts, plus the
motivation for applying SE to the development of today’s complex electronic-based
(hardware-software) devices
Week 1 Reading
1 Why Study Hardware-Software Systems?
2 System Engineering Basics
3 Functional Analysis and OCDs
4 Requirements Analysis
5 Solution Synthesis
6 Modeling Tools
Week 2 Goals: To provide a basic understanding of software systems:
1. HW Basics for SW
2. Software Creations Basics
3 Types of Software
4 Software Process Models
5 Relationships Between Hardware and Software
Week 3 Goals: To understand the full range of hardware-software system architectures
and trade-offs, the students must understand the basic technology and terminology for
both chips, chip packages and printed circuit board development.
1 Chip-Package-Board
Week 4 Goals: This learning module is the first one that uses the book: "ESL Design
and Verification." Electronic System Level (ESL) is one inflection of the general
principles of systems engineering, namely, used by the chip design community. I'll
address the other electronic communities, e.g., board and product level, with
supplemental material as we go along in the course.
Reading Specifics for Week 4 - ESL Development and Enablers
* Ch 3: Evolution of ESL Development
* Ch 4: What Are the Enablers of ESL?
* Ch 10.1: Intro to Post Partitioning
Week 5 Goals: This week covers the life cycle flow of hardware and software in the
design of integrated circuits. Pay special attention to the implementation sections.
For this week, please read the following:
Page 1
* Ch 5: ESL Flow
Week 6 Goals: This week covers the challenges of specification and modeling. The
requirements management section should look similar to LM1. Modeling is also a big
part of any systems engineering activity, but especially as a prelude to the co-design of
hardware and software systems.
For this week, please read the following:
* Ch 6: Specification and Modeling
* Ch 9-9.3: Post-PartitioningAnalysis and Debug
Week 7 Goals: This week covers pre-partitioning at the algorithmic level. Pay special
attention to the approach used in the JPGE encoding example.
For this week, please read the following:
* Ch 7: Pre-Partitioning Analysis
Week 8 Goals: This week covers hardware implementation of the partitioned design.
You'll recognized some of the hardware options covered briefly in the introduction of
chip development earlier in the course.
For this week, please read the following:
* Ch 11: Hardware Implementation, up to but not including Section 11.7
* Course notes as provided in "readings."
Week 9 Goals: This week covers software implementation of the partitioned design.
You'll recognized some of the software development basics covered briefly in the first
part of this course.
For this week, please read the following:
* Ch 12: Software Implementation up to but not including Section 12.3
* Lecture notes (Programmer’s View)
Week 10 Goals: For the last week of the course, we'll be looking at how the green
movement effects the design of and trade-offs between hardware and software
subsystems.
For this week, please read the following:
* Lecture notes as listed (Green Hardware and Software)
II. Goal Assessment Method
Page 2
Each week’s learning module will be evaluated in two ways: 1) assessment evaluation
and 2) student journal entries. In each learning module assessment, the student must rate
and give comments in the following three areas:
> Reading Assignment - On a scale of 1 to 5 (5 being best), how would you rate the
reading assignment for this week? Also, briefly explain what you'd like to learn more
about pertaining to this reading.
> Homework Assignment - On a scale of 1 to 5 (5 being best), how would you rate the
homework assignment for this week? Also, briefly explain if the homework helped or
didn't help your understanding of the reading assignment for this week.
> Relevance - On a scale from 1 to 5 (5 being the most relevant), how would you rate the
relevance of this weeks lesson to the understanding of electronic hardware-software
development? Briefly explain your reasons.
Here’s an example of a partially filled out assessment spreadsheet:
Student
Reading Raw Score
Reading - Homework - Homework Average
Raw Score
Average
Relevance Raw Score
Relevance Average
LM1
LM2
LM3
LM4
3.25
Martin Bamberg
Neil Chung
Ronald Delvisco
Ali Hodroj
Minh-Tam Nguyen
Daniel Smith
4
3
2
5
2
3.5
Martin Bamberg
Neil Chung
Ronald Delvisco
Ali Hodroj
Minh-Tam Nguyen
Daniel Smith
3
4
5
4
4
4
LM5
3.25
4
3
4
4
1
3.5
4
4.33
5
3
5
5
4
4
4
4
4
5
3
4
4
4.5
5
3
5
5
4
5
LM6
LM7
LM8
LM9
LM10
III. Recommendations
Here are the specific recommendations for improving the course next year, based on the
listed assessment evaluations:
Week 1 Recommendations: Students responded well to the trade-off study methodology.
May include one more example of a hw-sw trade-off analysis. Might include a simple
sensitivity measure.
Page 3
Week 2 Recommendations: Several good ideas for improvement:
> Include one example of how “hardware can directly replace software and vice versa,”
in other words, a higher level view to complement the very detailed nature of this LM.
> The concept of timing is completely missing from the software view (see Ali Journal).
Use his very detailed example to introduce the idea of timed and untimed system hw-sw
models (actually covered later in the course). Just need an example here, like Ali’s.
> [Daniel] Hardware homework needs to more closely align with the readers. At least one
student need to supplement readings with research via the Internet.
> More self-assessment test that address actual hardware questions, probably terms,
technology, etc.
> Almost all the students really liked this module. Some recommendations include more
development of buss types, spell out all acronyms. Need to flesh out the “How Software
works” tutorial.
> Be sure to cover MakeFiles (in the software tutorial). Contrast to hardware (no real
Make File, since no compiling, except for FPGAs.)
Week 3 Recommendations: Some of my students are still struggling with basic concepts.
For example, I asked them do describe what a system meant from a chip point of view.
Several seemed to see the chip as a single function entity, not an SoC. Perhaps I need to
focus more on the very simple example from the AFP case study. I haven't done so in the
past because I thought it was a trivial example. But for the next class I'll reintroduce the
AFP - starts from a discrete logic design and goes into a hw-sw board level design. Then
I could ask the class to migrate that design to an FPGA or ASIC, balancing HW-SW
issues. [The ASIC migration might be to a System-in-Package (SiP), i.e., several chip
dies in one pacakge]. I really think this course needs to be a collection of case studies.
Problem is that they need to understand the terms. Chicken and egg dilemma.
Also, there seemed to be too much material in the ‘Complex Electronics Guidebook.”
Next time I’ll space out that reading.
Need to emphasis the difference between simple, single function or descrete chips (e.g.,
flip-flops, etc) and complex SoC. This is where the AFP case study would help. It uses
discrete chips to build a system. Later, that same case study is redone with a complex
chip processor and software – but it still does the same function! This should be a great
example for next time.
Week 4 Recommendations: Nneed to better align the homework with the reading and
provide more examples. For example, “question number one talks about modeling a new
compression algorithm. The reading went more into considerations when modeling, but
not much detail on performing the modeling or developing algorithms.” The third
question is another example. The reading didn't discuss much about DSP's. So trying to
make a comparison for fixed vs IP didn't really line up with the reading. [Ronald
Delvisco].
Week 5 Recommendations: Need to emphasis that ESL is not just one flow, but needs
to be adapted. Personally, I’m not sure that I’ll use this “ESL” book next year.
Page 4
Week 6 Recommendations: Will incorporate the following changes:
> Need to do more with the Gajski-Kuhn Chart - a great diagram for showing the
different levels of abstraction. http://schlosser.info/diplomathesis/thesissu7.html.
> Homework seemed better aligned with assignment. “The question on Gajski's Y-chart
was a good application question. “
> Several students are using DOOR, that is, more typical SE tools than MathWorks. May
want to include more examples from the standard SE tool suites. Might try to resurrect
our tools from past students, too.
Week 7 Recommendations: The use of actual estimation tools like COCOMO was a big
hit in this LM. Here are some other comments:
> [Ronald Delvisco] I know from my experience, alot of time is spent on turning the high
level specifications into low-level requirements, but not enough time is spent doing a
good analysis of how those specifications will be partitioned into different processors.
> [Daniel Smith] I tried to step back and look at the big picture in an attempt to
understand concepts rather than just remember terms. For example how the Systems
Engineer is like the architect who builds the blue prints. The developers are like the
construction workers that do the actual building. The hardware and software products are
like the bricks and other objects that make up the building. I would also think both have
to do a trade-off analysis because the goal is to build a product as fast as you can, keep
costs down, and quality high.
Week 8 Recommendations: TPM, UART example, interface focus of HW-SW as well
as interaction between SE and program management were all well received. Here’s a few
pertinent comments:
> [Ali Hodroj]I think that the main benefit from this learning module was the
introduction of the management aspects of systems engineering within the SoC design
world.
> [Minh-Tam Nguyen] I thought the case study on UART HW-SW Implementation was
great because it broke down all of the advantages and disadvantages of UART from both
the HW and SW side.
Week 9 Recommendations: Comments of value:
> [Martin Bamberger] More discussion on power consumption of the solid state memory
vs traditional hard drives.
> [Ali Hodroj] One interesting thing that caught my attention was the uncertainty in
performance estimations across different hardware platforms. Concerning memory
utilization - I've been recently looking at .NET Micro, which is an embedded version of
the .NET framework for small devices that provides subset of the C#/.NET base class
library: http://msdn.microsoft.com/en-us/embedded/bb278106.aspx
Week 10 Recommendations: Green trade-offs should just focus on low-power tradeoffs.
Page 5
Overall Course Recommendations:
Ideally, this course should cover HW-SW tradeoff approaches for several different types
of industries, i.e., hw-sw tradeoffs for control systems at power plants (including data
storage requirements, I/O, etc). In its current form, the class focuses on hw-sw tradeoffs
for electronics industry. Also, in its present form, the course focuses on chip and board
development, with little emphasis on network and I/O design. To be honest, tho, I’ve
covered network trade-offs in the past to which students felt overwhelmed. The subject
matter can quickly get out of hand.
The difficulty is getting the class on the same page in terms of nomenclature, i.e., basic
terminology. But perhaps I should just jump right in and present several HW-SW tradeoff studies. Then intro terminology and concepts from that point. A bit of a chicken and
egg.
Here are the changes that I will make to the course next year:
> LM1 will remain the same, except that I’ll introduce the following course long tradeoff analysis: Determine which is more cost effective and environmentally friendly to
sustain – print or electronic distribution of material. This seems like a simple question,
but to answer requires a full knowledge of HW-SW trade-offs at all levels.
> LM2 will be expanded into two LMs. The first one will cover what is currently covered
in LM2, except more material on hardware-only (discrete chips, no SW) implementation
of a data acquisition system. Trade-offs are pretty straight forward here. Will also
introduce a hardware only (no software) design – the AFP case study. This will be
expanded throughout the course. The second part of LM2 will cover HW-SW control
basis (as in other non-electronic systems, like power plants, auto plants, etc).
> In later LMs, I’ll modify that hardware-only design to a HW (basic process) and
accompanying SW implementation. This would introduce the basic concepts of
embedded SW, HW and firmware.
> Evolve this design into a single SoC system - either as an FPGA or ASIC w/ or w/o IP.
This would be similar to the NASA ChipStat example in class (very interesting, really).
> Introduce the changes in HW-SW wrought by a simple wireless extension.
> Connect this system to a network.
At each stage I'd discuss the appropriate HW-SW trade-offs, as well as the related
technology risks. Trade-offs would center around the most common:
> Power - consumption and heat dissipation from electronics. Perhaps green ways to
reuse this head.
> Performance (typically throughput)
> Area or footprint
> Cost and risk
All of these above case studies already exists, since I've covered it during previous
classes.
Page 6
Page 7