UCR CS269: Hardware/Software Engineering of Embedded Systems

CS269 deals with the exciting and rapidly-growing field of embedded computing systems.  The course will present state-of-the-art software and hardware design techniques for embedded computing systems.  Topics include specification models, languages, simulation, partitioning algorithms, estimation methods, model refinement, and design methodology.  

Course information

Class Readings and Presentation

You are expected to read assigned readings before the date they are presented, to attend classes and actively participate in discussions.  You are also expected to present several papers during the quarter, for which you should study thoroughly, and do outside research as necessary.  Questions will be posed in class about the material and you are expected to be able to answer them.  You are free to contact authors for extra material (including presentation material) and to answer any questions you might have.  (Obviously, they are not under any obligation to respond).  However, you must properly acknowledge the source so there won't be questions of plagiarism.

Individual Projects

Project should be done individually.  You are encouraged to propose your own project, possibly related to your Ph.D., M.S. thesis work or even B.S. senior project work.  The idea is that it may, with possibly one more quarter of independent study work, become a submission to a workshop and/or a chapter in your thesis.  The content should falls somewhat within the broad confine of the course and has comparable depth as the other projects.  A list of potential project will also be available at the beginning of the class.  Project request is on a first-come-first-serve basis.  You are encouraged to send me e-mail frequently about your progress or any question you may have throughout the quarter.  

Project Deadlines are: 

1) Extending eBlock Simulator

2) Programmable eBlock

3) Protocol Exploration Tool for eBlock Systems

4) Implementing Abstraction/Refinement Operations for Formal Verification in Metropolis

5) Performance Analysis of Metropolis Design Using SMART

6) A Practical Language for LOC

7) Integrating LOC checker into PSL framework

8) Safe Abstraction for Simulation Trace Checking

9) Testing and synthesizing a configurable logic architecture for dynamic hardware/software partitioning

Project Descriptions

1) Extending eBlock Simulator

Mentor: Susan Cotterell (susanc@cs.ucr.edu); Harry Hsieh (harry@cs.ucr.edu)

Student: K. Stephenson

Goal:

The goal of eBlocks is to empower regular people, having no programming or electronics experience, to build basic useful electronic systems around the home, office, store, etc. eBlocks strive to achieve this goal by creating a set of embedded system building blocks - eBlocks - that regular people could easily connect together to build a huge variety of basic but useful monitor/controller systems. The key is to add compute intelligence to components that previously had none - to sensors, switches, light-emitting diodes (LEDs), speakers, etc. Adding compute intelligence to those items was previously cost and power prohibitive, but extremely small, cheap and low power processing devices now make such addition possible. Ideally, people could simply connect such eBlocks together to build basic systems.

Currently a eBlock simulator is available which allows anyone to build a subset of eBlock systems on the web. The goal of this project is to extend the simulator.

Procedure:

1. Study and understand the basic concept and goals of eBlocks.
2. Study and understand the Java code used to implement version 1.1 of the eBlock simulator.
3. Extend the simulator to allow users to load and save eBlock configurations created on the webpage.
4. Extend the simulator to allow users to mimic the desired test environment either through a testbench, graphically, or some other means.
5. Extend the simulator such that a user can track various parameters and statistics such as power consumption, eBlock state, transmission delay, etc.
6. Extend the simulator to assist users in configuring the logic block, if they choose to request assistance.
7. Extend the simulator to handle more of the Boolean as well as the integer eBlocks.

Expected Products:

An eBlock simulator with the aforementioned extensions as well as any other improvements that may be beneficial

Reference:

• eBlock Homepage
• eBlock Simulator
• First Results with eBlocks: Embedded Systems Building Blocks
  S. Cotterell, F.Vahid, W.Najjar, H.Hsieh
  CODES+ISSS Merged Conference, October 2003.

2) Programmable eBlock

Mentor: Susan Cotterell (susanc@cs.ucr.edu); Harry Hsieh (harry@cs.ucr.edu)

Student: To Be Determined

Goal:

The goal of eBlocks is to empower regular people, having no programming or electronics experience, to build basic useful electronic systems around the home, office, store, etc. eBlocks strive to achieve this goal by creating a set of embedded system building blocks - eBlocks - that regular people could easily connect together to build a huge variety of basic but useful monitor/controller systems. The key is to add compute intelligence to components that previously had none - to sensors, switches, light-emitting diodes (LEDs), speakers, etc. Adding compute intelligence to those items was previously cost and power prohibitive, but extremely small, cheap and low power processing devices now make such addition possible. Ideally, people could simply connect such eBlocks together to build basic systems.

Although eBlocks are targeted towards people with no program expertise, those with programming knowledge should not be confined. By creating a programmable eBlock, users can specify the desired functionality of their own eBlock and use it in conjunction with pre-existing eBlocks.

Procedure:

1. Study and understand the basic concept and goals of eBlocks.
2. Study and understand the Java code used to implement version 1.1 of the eBlock simuator.
3. Create an environment in which users can specify the functionality of a programmable eBlock.
4. Extend the simulator to allow users to test the programmable eBlock along with the pre-existing eBlocks.

Expected Products:

An environment which allows users to program a programmable eBlock as well as an eBlock simulator which allows users to test the programmable eBlock along with pre-existing eBlocks found in the eBlock library.

Reference:

• eBlock Homepage
• eBlock Simulator
• First Results with eBlocks: Embedded Systems Building Blocks
  S. Cotterell, F.Vahid, W.Najjar, H.Hsieh
  CODES+ISSS Merged Conference, October 2003.

3) Protocol Exploration Tool for eBlock Systems

Mentor: David Sheldon (dsheldon@cs.ucr.edu); Harry Hsieh (harry@cs.ucr.edu)

Student: To Be Determined

Goal:

The goal of eBlocks is to empower regular people, having no programming or electronics experience, to build basic useful electronic systems around the home, office, store, etc. eBlocks strive to achieve this goal by creating a set of embedded system building blocks - eBlocks - that regular people could easily connect together to build a huge variety of basic but useful monitor/controller systems. The key is to add compute intelligence to components that previously had none - to sensors, switches, light-emitting diodes (LEDs), speakers, etc. Adding compute intelligence to those items was previously cost and power prohibitive, but extremely small, cheap and low power processing devices now make such addition possible. Ideally, people could simply connect such eBlocks together to build basic systems.

A further requirement of eBlocks is that they are battery powered, to avoid the complexity of connecting every component to a wall power source. Thus, eBlocks must have sufficient battery life such that a user is not constantly changing the batteries. Communication is one of the main contributors to power dissipation. The goal of this project is to design a tool that will determine the optimal parameters for the system so that the system will use minimal power, while still working properly. Given parameters such as the length of the packet, transmission frequency, and error detection, create a tool that will determine the best configuration that will also use the smallest amount of power. The environment may effect the power or accuracy of the transmission so all the power and error rates the user should be able to change.

Procedure:

1. Study and understand the basic concept and goals of eBlocks.
2. Study and understand the Java code used to implement version 1.1 of the eBlock simuator.
3. Create an environment in which users can specify and explore various transmission protocols.
4. Exploration tool should keep track and display various statistics of interest such as power dissipation, system delay, etc.
5. Exploration tool should allow a user to specify environmental stimuli, such as how often input into the systems occurs.
6. Exploration tool should allow a user to weight the importance of various parameters and/or specify the environment an eBlock system will be placed in and output the optimal transmission protocol.

Expected Products:

An eBlock transmission protocol exploration/optimization environment in which users can test the impacts of various protocols given a defined test environment as well as an option to optimize the protocol given a defined test environment and/or weighted parameters.

Reference:

• eBlock Homepage
• eBlock Simulator
• First Results with eBlocks: Embedded Systems Building Blocks
  S. Cotterell, F.Vahid, W.Najjar, H.Hsieh
  CODES+ISSS Merged Conference, October 2003

4) Implementing Abstraction/Refinement Operations for Formal Verification in Metropolis

Mentor:  Harry Hsieh (harry@cs.ucr.edu)

Student: Xi Chen

Goal:

The existing formal verification checks the whole state space of a design for properties (specified in LTL or LOC) of a design. A realistic system design (e.g. PiP) is usually too large to be exhaustively verified. Due to the fact that only a part of the design needs to  be checked, some components of the design can be abstracted to simpler representations without changing the validity of the properties in the verification. We call it safe abstraction.

The goal of this project is to design a set of safe abstraction procedures that can be applied automatically or manually by designers to make the formal verification of large designs possible. The basic requirement is not to affect the validity of the properties.

Procedure:

1. Study and understand the methodology of formal verification.
2. Study and understand the concept of design abstraction.
3. From the PiP design (or its components) and several properties, identify abstraction procedures that won't affect the validity of the properties.
4. Generalize the abstraction procedures for stantard logic operators (e.g. LTL and LOC).

Expected Products:

A case study of safe abstraction for simulation trace checking probably using the PiP design. Generalization of the abstraction procedures for LTL and LOC logic operators.

Reference:

• "Automatic trace analysis for logic of constraints",  X. Chen, H. Hsieh, F. Balarin, Y. Watanabe.  Design Automation Conference, 2003
• "Metropolis: an Integrated Electronic System Design Environment", F. Balarin, Y. Watanabe, H. Hsieh, L. Lavagno, C.  Paserone, A. Sangiovanni-Vincentelli,, IEEE Computer, volume 36, issue 4, April 2003, pages: 45- 52.
• References on abstraction/refinement

5) Performance Analsysi of Metropolis Design using SMART

Mentor: Xi Chen (xichen@cs.ucr.edu); Harry Hsieh (harry@cs.ucr.edu)

Students: J. Yu

Goal:

Formal verification and performance analysis is critical to the correct functioning of a design.  Metropolis design framework allow designer to start from concept all the way down to implementation, all within a formal framework.  Preliminary work exists to formally verification small portion of the MMM design using the translation path to SPIN.  However, what distinguishes Metropolis is its ability to specify architecture and function to architecture mapping.  Performance analysis, at high level of abstraction, can be achieve with early mapping of function to architecture.  Since no detail information is yet available at this stage, stochastic parameters may be best used to characterized a higher level design.  This project seek to capitalized on SMART's ability to perform stochastic verification.  Since SMART is also capable of formal functional verification, a more direct and efficient path to functional verification is also sought for in this project.

Procedure:

1. Study and understand SMART and Petri Net.
2. Study and understand Metropolis and MMM through simulation (SimpleByte example, architecture example, PIP example).
3. Perform stochastic case study on examples by writing PN equivalents of the MMM designs.
4. Translate simple design from MMM to PN for both functional verification and performance analysis.

Expected Products:

Case study on stochastic performance analysis of Metropolis functional and architecture design using SMART.  Simple automatic translator from MMM to PN for both performance analysis and functional verification.

Reference:

• Balarin F, Lavagno L, Passerone C, Watanabe Y. Processes, interfaces and platforms. Embedded software modelling in Metropolis. [Conference Paper] Embedded Software. Second International Conference, EMSOFT 2002. Proceedings (Lecture Notes in Computer Science Vol.2491). Springer-Verlag. 2002, pp.407-21. Berlin, Germany.
• Balarin F, Watanabe Y, Hsieh H, Lavagno L, PAserone C, Sangiovanni-Vincentelli A. Metropolis: an integrated electronic system design environment. [Journal Paper] Computer, vol.36, no.4, April 2003, pp.45-52. Publisher: IEEE Comput. Soc, USA.
• Balarin F, Lavagno L, Passerone C, Sangiovanni-Vincentelli A, Sgroi M, Watanabe Y. Modeling and designing heterogeneous systems. [Book Chapter] Concurrency and hardware design. Advances in Petri nets. Springer-Verlag. 2002, pp.228-73. Berlin, Germany.
• Xi Chen, Fang Chen, Hsieh H, Balarin F, Watanabe Y. Formal verification of embedded system designs at multiple levels of abstraction. [Conference Paper] Proceedings Seventh IEEE International High-Level Design Validation and Test Workshop. IEEE Comput. Soc. 2002, pp.125-30. Los Alamitos, CA, USA.
• Balarin F, Lavagno L, Passerone C, Sangiovanni-Vincentelli A, Watanabe Y, Guang Yang. Concurrent execution semantics and sequential simulation algorithms for the Metropolis meta-model. [Conference Paper] Proceedings of the Tenth International Symposium on Hardware/Software Codesign. CODES 2002 (IEEE Cat. No.02TH8627). ACM. 2002, pp.13-18. New York, NY, USA.
• reference on SMART

6) A Practical Language for LOC

Mentor: Xi Chen (xichen@cs.ucr.edu); Harry Hsieh (harry@cs.ucr.edu)

Student: P. Appachu

Goal:

Logic Of Constraints (LOC) is a formalism designed to reason about execution traces containing quantitative performance values (also known as annotations).  It is designed for analyzing traces from the execution of higher, transaction level system models, where the input/output events, instead of their precise time of occurrence, are of primary importance.   LOC consists of all the terms and operators allowed in sentential logic, with additions that make it possible to specify quantitative assertions without compromising the ease of analysis.

To make LOC easier to use and more powerful to express complex properties, we need a practical language for it. The goal of this project is to design 
an assertion language for Logic Of Constraints following the style of Property Specification Language, a popular assertion language which has base its mathematical foundation on Linear Temporal Logic (LTL).  Part of the inspiration of the language design should also come from SMV.

Procedure:

1. Study and understand Logic Of Constraints.
2. Study and understand PSL and LTL.
3. Understand the difference between LOC and LTL/PSL, and the difference between a language and a logic.
4. Study and understand SMV and possibly utilize some of the concept and constructs.
5. Identify the language constructs that can be used for LOC properties.
6. Following the style of PSL and SMV, design a practical language for LOC.
7. Write a parser for this language by extending the exiting LOC checker generator (or possibly PSL checker generator).
8. (extra credit) Integrate PSL and the language for LOC into a "super" language.

Expected Products:

A well defined language for LOC, along with a functioning parser which is integrated with existing LOC (code) checker generator.

Reference:

• "Constraints specification at higher levels of abstraction", F. Balarin, Y. Watanabe, J. Burch, L. Lavagno, R. Passerone, A. Sangiovanni-Vincentelli, International Workshop on High Level Design Validatino and Test, 2001.
• "Automatic trace analysis for logic of constraints",  X. Chen, H. Hsieh, F. Balarin, Y. Watanabe.  Design Automation Conference, 2003.
• "Verifying LOC Based Functional and Performance Constraints",  X. Chen, H. Hsieh, F. Balarin and Y. Watanabe. International Workshop on High Level Design Validation and Test, 2003.
• PSL homepage: http://www.eda.org/vfv
• FoCs homepage: www.haifa.il.ibm.com/projects/verification/focs
• SMV Homepage: http://www-cad.eecs.berkeley.edu/~kenmcmil/smv/

7) Integrating LOC Checkers into PSL Framework

Mentor: Xi Chen (xichen@cs.ucr.edu); Harry Hsieh (harry@cs.ucr.edu)

Student: R. Evans

Goal:

LTL-based assertion language PSL and LOC can be used to formally specify the functional and performance properties of a system level design. LTL and 
LOC have been shown to have different domains of expressiveness and can complement each other.

For LTL/PSL properties, we leverage the existing tool, FoCs, to generate the checker core and then manually write wrappers that are necessary for checking simulation trace off-line (as compare to on-line monitoring).. For LOC properties, we use our own tool to generate checkers. The goal of this project is to first automate the wrapper generation for FoCs generated checkers, and then integrate the two checker generations into a unified framework.

Procedure:

1. Study and understand Logic Of Constraints and its checker generator.
2. Study and understand PSL and its checker generator FoCs.
3. Write a wrapper generator for FoCs generated PSL monitor so a trace checker can be generated.
4. Give example of a meaningful, non-trivial, combination of LTL with LOC, and manually write the corresponding checker
5. Define rules for combining LTL and LOC, write automatic checker generator for tyical LOC+LTL properties.
6. Integrate the two separate checker generations into one unified framework.

Expected Products:

A wrapper generator for FoCs generated PSL checkers and a integrated tool for both LTL/PSL and LOC checker generations.

Reference:

• "Constraints specification at higher levels of abstraction", F. Balarin, Y. Watanabe, J. Burch, L. Lavagno, R. Passerone, A. Sangiovanni-Vincentelli, International Workshop on High Level Design Validatino and Test, 2001.
• "Automatic trace analysis for logic of constraints",  X. Chen, H. Hsieh, F. Balarin, Y. Watanabe.  Design Automation Conference, 2003.
• "Verifying LOC Based Functional and Performance Constraints",  X. Chen, H. Hsieh, F. Balarin and Y. Watanabe. International Workshop on High Level Design Validation and Test, 2003.
• PSL homepage: http://www.eda.org/vfv
• "Utilizing Formal Assertions for System Design of Network Processors". X. Chen, Y. Luo, 
  H. Hsieh, L. Bhuyan, F. Balarin, to appear in Design Automation and Test in Europe, Feb 2004.
• FoCs homepage: www.haifa.il.ibm.com/projects/verification/focs
  

8) Defining Levels of Abstraction for Simulation Trace Checking

Mentor: Xi Chen (xichen@cs.ucr.edu); Harry Hsieh (harry@cs.ucr.edu)

Student: N. He

Goal:

It is not unusual for designers to run simulation using hours upon hours of computation time, regardless of what property he really cares about.  Given a particular property, it is easy to envision situation where most part of the design are not relevant to the property at hand.  In formal verification, property specific safe abstraction has been studied quite extensively, with mixed result.  This project seek to answer the question in the context of simulation.  Given a design, and a set of LTL or LoC properties, we want to find an abstraction (level) that is safe, in the it retain the essentially characteristic for the pass/fail of the given property.

We will start with a realistic system design (a Picture-in-Picture design specified in Metropolis Metamodel), and find a cooresponding abstract design that is still safe for a class of properties.  We, of course, will also define that class of properties.  Furthermore, we want to see what abstraction procedures can be applied automatically or manually by designers to move from one abstraction level to the other, and to reduce the simulation time.  The lesson learned with the PIP design should then be generalized to MMM design in general.

Procedure:

1. Student and understand PIP in Metropolis
2. Study and understand the methodology of simulation trace checking (LTL and/or LOC)
3. Study and understand the concept of design abstraction.
4. From the PiP design, respecify it at a higher level of abstraction that will reduce simulation time while not affecting the validity of the properties
5. From the PiP design and its properties, identify several abstraction procedures that won't affect the validity of the properties.
6. Generalize the abstraction procedures for stantard logic operators (e.g. LTL and LOC).

Expected Products:

A case study of safe abstraction for simulation trace checking (probably) using the PiP design by working at different abstraction.  Identify and Generalize the abstraction procedures for LTL and LOC logic operators on general MMM designs.

Reference:

• "Automatic trace analysis for logic of constraints",  X. Chen, H. Hsieh, F. Balarin, Y. Watanabe.  Design Automation Conference, 2003
• "Metropolis: an Integrated Electronic System Design Environment", F. Balarin, Y. Watanabe, H. Hsieh, L. Lavagno, C.  Paserone, A. Sangiovanni-Vincentelli,, IEEE Computer, volume 36, issue 4, April 2003, pages: 45- 52.
• reference on abstract interpretation
• reference on shiple's work
• reference on balarin's work

9) Testing and synthesizing a configurable logic architecture for dynamic hardware/software partitioning

Mentor: Roman Lysecky (rlysecky@cs.ucr.edu); Frank Vahid (vahid@cs.ucr.edu); Harry Hsieh (harry@cs.ucr.edu)

Student: P. Vu

Goal:

Improvements in performance and power can be achieved with dynamic software optimizations.  Single-chip platforms with both microprocessors and configurable logic provide even greater optimizations.  Major software speedups and energy reduction result in hardware/software partitioning, implementing software as a hardware coprocessor on configurable logic.  Hardware/software partitioning can also be done at the binary-level with no requirement of special desktop tools.  Warp processing is the process of dynamically optimizing executing binary by moving software kernels to configurable logic.  Traditional FPGAs are not suited well for dynamic hardware/software partitioning. 

A configurable logic fabric and architecture has been designed by Roman Lysecky specifically for dynamic hardware/software partitioning and speeding up critical loops.  Through experiments with popular benchmarks, this configurable logic architecture, fabric and accompanying place and route algorithms have shown to be quicker and using less memory and power.  Research continues with this architecture and fabric.

Procedure:

1. Study and understand the concepts and goals of dynamic hardware/software partitioning.
2. Implement Roman Lysecky’s designed configurable logic architecture for dynamic hardware/software in VHDL, including CLB, looping HW, Memory interface, programmable interconnect...etc.  Synthesize it and check performance/power/size.
3. Test the configurable logic architecture using various testbenches.
4. Synthesize and map the configurable logic architecture onto a Xilinx FPGA, compare with the previous tests in terms of size, performance and power.
5. Execute Xilinx chip with a stand-along processor.

Expected Products:

VHDL models and testbenches for the reconfigurable fabric that can be synthesized into ASIC or FPGA.  An example of HW/SW co-execution.

Reference:

• “A Configurable Logic Architecture for Dynamic Hardware/Software Partitioning”, R. Lysecky, F. Vahid, Design Automation and Test in Europe Conference (DATE), February 2004.
• "", R. Lysecky, F. Vahid, Design Automation Conference, June 2003.