DOC

Week 1 Goals To provides a review of basic system engineering

By Virginia Rivera,2014-06-23 11:04
7 views 0
Week 1 Goals To provides a review of basic system engineering

    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: Reading - Reading - Homework - Homework - Relevance - Relevance - StudentRaw ScoreAverageRaw ScoreAverageRaw ScoreAverageLM1

    LM2

    LM3

    LM43.253.254.33Martin Bamberg445Neil Chung333Ronald Delvisco245Ali Hodroj545Minh-Tam Nguyen214Daniel Smith3.53.54

    LM5444.5Martin Bamberg345Neil Chung443Ronald Delvisco555Ali Hodroj435Minh-Tam Nguyen444Daniel Smith445

    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 trade-off 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 trade-

    off 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

Report this document

For any questions or suggestions please email
cust-service@docsford.com