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.  This year we will have a slight focus on the specification model, design methodology, and formal methods.

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.  For the presenter, the papers listed under "Extra reading" is strongly recommended.

Deadlines:  You must choose the papers for the first round of presentation by noon Thursday 1/10.  The deadline for choosing the second round of papers will be announced later

Individual Projects

Project may be done in a team of 1 or 2.  A list of proposed projects follows.  You may also propose your own project, as long as the topic falls within the confine of the course and it has comparable depth as the other projects.  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.  The idea is that the result of the project, possibly with one more quarter of independent study by one student, will have enough technical content for a conference or workshop presentation.

Project Deadlines are: 

1) Modeling heterogeneous semantics in Metropolis

2) Simulation and Formal Verification of Metropolis designs using SPIN

3) Simulation and Formal Verification of Metropolis action automata using SPIN

4) Generating Simulation monitor for LOC using SPIN

5) Simulation of Metropolis design using SpecC design environment

6) Simulation and Formal Verification of Metropolis action automata using SMV

Project Descriptions

1) Modeling heterogeneous semantics in Metropolis:

Students: S. Dhirakaosal and A. Buyukkurt

Goal:
-----
Metropolis heterogeneous system design framework has within it a metamodel language which can be used to unambiguously model other models of computation.  This project studies variety of semantics of computation and communication often used in applications of embedded systems, and identifies how they can be modeled with the Metropolis meta-model. Metamodel allows one to model
different semantics uniformly using a common set of building blocks. This capability is essential in synthesis and verification, where heterogeneous components must be compared and their interaction needs to be analyzed. The project considers the Finite State Machine, Synchronous Data Flow,  Discrete Event, and Process Network models of computations.  The project is to construct a "library" for each MOC so design within a model of computation can be represented clearly using the elements of the library.  Since these semantics are also supported in Ptolemy II, a translator should then be built to convert designs in Ptolemy II (there are many) into Metropolis Metamodel (MMM) using appropriate library.

Procedure:
----------
1) Study and understand MMM.
2) Study and understand FSM, SDF, DE, and PN and understand how they are implemented in Ptolemy II
3) Document carefully how each MOC can be modeled by defining a library of constructs and functions for each MOC
4) Write a "possibly JAVA" program to interface with Ptolemy II so designs written in those two domains can be translated into MMM. There are numerous demo design already exists that can be used to test your translator.
5) Test out the translator by simulating within Ptolemy II and by manually
trace the generated MMM files (if they are ready, you may also simulate with JAVA, SystemC, SpecC, or Spin simulator)
(extra) Do the above for other domains chosen from the following: CSP, DDE, DT, or Giotto.

Expected product:
-----------------
Careful documentation of the metropolis libraries for the domains, plus a fully functional translator for the examples within Ptolemy II.

Reference:
----------
* Ptolemy website: ptolemy.eecs.berkeley.edu
* "Metropolis: Design Environment for Heterogeneous Systems", Metropolis Project Team, Cadence Technical Conference 2001.
* "Modeling and Designing Heterogeneous Systems", F. Balarin, L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, M. Sgroi, and Y. Watanabe.
* "The Metropolis Meta-Model, version 0.2.7" The Metropolis Project Team

2) Simulation and Formal Verification of Metropolis designs using SPIN

Students: J. Guo and L. Jin

Goal:
-----

SPIN is a widely distributed tool for software verification developed at Bell Labs. This project will make it possible to verify designs captured in Metropolis using SPIN. Both Metropolis and SPIN use linear temporal logic to write properties to be verified. They both use single specification languages, but with different concerns. The challenge is to represent designs captured in Metropolis using SPIN's specification language, PROMELA. In this project, the semantics of the two languages will be carefully analyzed, and a
Metropolis backend tool will be written in order to generate PROMELA from Metropolis.

Procedure:
----------
1) Study and understand MMM.
2) Study and understand Promela and SPIN.
3) Document carefully and unambiguously how each Metropolis metamodel constructs can be modeled by Promela. If there are constructs that can not be translated, explain precisely why. You will need to explain especially what you do with the non-determinism in MMM, as well as the scheduling that may not be supported directly by SPIN.
5) Write a (probably JAVA) program to interface Metropolis AST, so designs written in MMM can be translate into Promela. Spin already accept LTL as properties. You may ignore LOC and ELOC constraints for now.
6) Test out the translator and show through examples that the translation is correct. Simulate the example in SPIN, and perform a simple verification case study.
(extra) Translate LOC and ELOC into monitors for simulation within SPIN, and if you can, translate LOC and ELOC into properties to be checked within SPIN.  For the properties that you cannot, explain why.

Expected product:
-----------------
Careful documentation of the translation from MMM to Promela, plus a fully functional translator. You will also need to document a careful case study of simulation and formal verification.

Reference:
----------
* SPIN website: http://netlib.bell-labs.com/netlib/spin/whatispin.html
* "Metropolis: Design Environment for Heterogeneous Systems", MetropolisProject Team, Cadence Technical Conference 2001.
* "Modeling and Designing Heterogeneous Systems", F. Balarin, L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, M. Sgroi, and Y. Watanabe.
* "The Metropolis Meta-Model, version 0.2.6" The Metropolis Project Team.

3) Simulation and Formal Verification of Metropolis action automata using SPIN

Students: F. Chen and X. Chen

Goal:
-----
The semantics of Metropolis metamodel is defined by a set of "action automata" and associated datapath. For each syntactic construct in the meta-model, an automaton specifying its control semantic is defined. The goal of this project is to automatically generate these automata and the associated datapath for a given meta-model netlist. The automata and the datapath would be represented in Promela, the entry language for SPIN.  SPIN is a widely distributed tool for software verification developed at Bell Labs. In this project, the semantics of the two languages will be carefully analyzed, and a Metropolis backend tool will be written in order to generate PROMELA for Metropolis action automata.

Procedure:
----------
1) Study and understand MMM, especially how action automata are generated from MMM
2) Study and understand Promela and SPIN.
3) Document carefully and unambiguously how each Metropolis action automata constructs can be modeled by Promela. If there are constructs that can not be translated, explain precisely why. You will need to explain especially what you do with the non-determinism in metropolis action automata.
5) Write a (probably JAVA) program to interface Metropolis AST, so designs written in MMM can be translate into Promela.
6) Test out the translator and show through examples that the translation is correct. Simulate the example in SPIN (what about non-determinism?), and perform a simple verification case study.
(extra) Build a semantic checker on top of your tool.  Given a Metropolis simulation trace, can you verify the trace is semantically correct according to the action automata?  (extra extra) what is the minimum elements required to be in the simulation trace for you to make that determination?  Clearly you need more than just primary I/O.  You will probably need to think about observability/controllability

Expected product:
-----------------
Careful documentation of the translation from Metropolis action automata to Promela, plus a fully functional translator. You will also need to document a careful case study of simulation and formal verification.

Reference:
----------
* SPIN website: http://netlib.bell-labs.com/netlib/spin/whatispin.html
* "Metropolis: Design Environment for Heterogeneous Systems", MetropolisProject Team, Cadence Technical Conference 2001.
* "Modeling and Designing Heterogeneous Systems", F. Balarin, L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, M. Sgroi, and Y. Watanabe.
* "The Metropolis Meta-Model, version 0.2.6" The Metropolis Project Team.

4) Generating Simulation monitor for LOC using SPIN

Students: TBA

Goal:
-----
LOC (Logic Of Constraints) is used to specified a set of constraints particularly useful in embedded system design. It is strictly more powerful than prepositional logics, (or Linear Temporal Logics, for that matter), so it is not possible to represent constraints in LOC with Finite State Automata.  However, it is possible to generate a monitor to test whether or not a particular constraint is satisfied during simulation. This project is to define a translation from constraints in LOC to simulation monitor in Promela.  It is mean to work for any Promela simulation whether they are for embedded system or general software/protocol design.

Procedure:
----------
1) Study and understand LOC
2) Study and understand Promela and SPIN.
3) Document carefully and unambiguously how each LOC constraint can be translated into a simulation monitor written in Promela, and how this simulation monitor can be used during simulation of Promela codes.  . If there are constraints that can not be translated, explain precisely why..
5) Write a program (including a parser) that will take any constraints in LOC and output a correct Promela simulation monitor. 
6) Test out the translator and show through examples that the translation is correct. Simulate an example in SPIN, and show how the simulation monitor works.
(extra) Identify subset of LOC that is amendable to formal verification within SPIN.  Augment your translator to translate those constraints into LTL or FSM monitor so they can be formally verified.

Expected product:
-----------------
Careful documentation of the translation from LOC contraints to Promela simulation monitor, plus a fully functional translator. You will also need to document a careful case study of simulation with with these monitors.

Reference:
----------
* SPIN website: http://netlib.bell-labs.com/netlib/spin/whatispin.html
* "Metropolis: Design Environment for Heterogeneous Systems", MetropolisProject Team, Cadence Technical Conference 2001.
* "Modeling and Designing Heterogeneous Systems", F. Balarin, L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, M. Sgroi, and Y. Watanabe.
* F. Balarin et. al., "Constraints Specification at Higher Levels of Abstraction", International High-Level Design Validation and Test Workshop, Nov 2001.

5) Simulation of Metropolis design using SpecC design environment

Student: A. McDaniel

Goal:
-----

SpecC is developed initially by Prof. Gajski of UC-Irvine and is poised to be one of the major competitor to SystemC as a system level design language for embedded systems.  Like SystemC, it is based on C/C++ constructs and capable to model any specification for embedded application.  A simulator and a reference compiler is freely available for SpecC, so this project will attempt to simulate Metropolis constructs and Metropolis designs using SpecC.  In this project, the semantics of the two languages will be carefully analyzed, and a Metropolis backend tool will be written in order to generate SpecC from Metropolis.

Procedure:
----------
1) Study and understand MMM.
2) Study and understand SpecC, SpecC Simulator, and SpecC reference compiler
3) Document carefully and unambiguously how each Metropolis metamodel constructs can be modeled by SpecC. If there are constructs that can not be translated, explain precisely why. You will need to explain especially what you do with the non-determinism in MMM, as well as the scheduling that may not be supported directly by SpecC.
5) Write a (probably JAVA) program to interface Metropolis AST, so designs written in MMM can be translate into SpecC.  You may ignore LTL, LOC and ELOC constraints for now.
6) Test out the translator and show through examples that the translation is correct. Simulate some test examples in SpecC.
(extra) What can you do with LTL, LOC and ELOC for SpecC?  How about simulation monitors?  Write a translator to translate LTL, LOC, and probably some ELOC (how do you do "there exists"?) into SpecC simulation monitor that if a violation of the constraints occurred during simulation, a flag will be raised.

Expected product:
-----------------
Careful documentation of the translation from MMM to SpecC, plus a fully functional translator. You will also need to document a careful case study of simulation.

Reference:
----------
* "Metropolis: Design Environment for Heterogeneous Systems", MetropolisProject Team, Cadence Technical Conference 2001.
* "Modeling and Designing Heterogeneous Systems", F. Balarin, L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, M. Sgroi, and Y. Watanabe.
* "The Metropolis Meta-Model, version 0.2.6" The Metropolis Project Team.
* A. Gerstlauer et. al., "System Design: A practical guide with SpecC", Kluwer Academic Publishers
* "SpecC language reference manual v1.0"
* www.ics.uci.edu/~specc

6) Simulation and Formal Verification of Metropolis action automata using SMV

Goal:
-----
The semantics of Metropolis metamodel is defined by a set of "action automata" and associated datapath. For each syntactic construct in the meta-model, an automaton specifying its control semantic is defined. The goal of this project is to automatically generate these automata and the associated datapath for a given meta-model netlist. The automata and some aspect of the datapath would be represented in SMV, the entry language for Symbolic Model Verifier and intermediate format for Formal Check from Cadence Design systems.  In this project, the semantics of the two languages will be carefully analyzed, and a Metropolis backend tool will be written in order to generate SMV for Metropolis action automata.

Procedure:
----------
1) Study and understand MMM, especially how action automata are generated from MMM
2) Study and understand SMV.
3) Document carefully and unambiguously how each Metropolis action automata constructs can be modeled by SMV. If there are constructs that can not be translated, explain precisely why. You will need to explain especially what you do with the datapath portion of the design.  Some abstract will probably be needed, write down your abstraction.
5) Write a (probably JAVA) program to interface Metropolis AST, so designs written in MMM can be translate into SMV.
6) Test out the translator and show through examples that the translation is correct.  Perform a simple verification case study.
(extra) Build a semantic checker on top of your tool.  Given a Metropolis simulation trace, can you verify the trace is semantically correct according to the action automata?  Be careful that you handle your datapath abstraction conservatively  (extra extra) what is the minimum elements required to be in the simulation trace for you to make that determination?  Clearly you need more than just primary I/O.  You will probably need to think about observability/controllability

Expected product:
-----------------
Careful documentation of the translation from Metropolis action automata to SMV, plus a fully functional translator. You will also need to document a careful case study of  formal verification.

Reference:
----------
* "Symbolic Model Verifier", Ken McMillen.(www-cad.eecs.berkeley.edu/~kenmcmil/smv)
* "Metropolis: Design Environment for Heterogeneous Systems", MetropolisProject Team, Cadence Technical Conference 2001.
* "Modeling and Designing Heterogeneous Systems", F. Balarin, L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, M. Sgroi, and Y. Watanabe.
* "The Metropolis Meta-Model, version 0.2.7" The Metropolis Project Team.