Stephen A. Edwards Columbia University Crown
  Languages for Embedded System Design:
Student Projects
Home Project Projects FAQ Flyer Bulletin Board
  * indicates a CVN student
 VxWorks and Real Time Linux
  Benjamin Ip*
  Most existing real-time operating system such as VxWorks, is based on proprietary technologies and that are designed to run on processors tailored to specific applications. This often means that they are quite expensive because of licensing fees and there is usually a large investment of time and capital involved in designing application specific hardware. Real time Linux provides a large cost savings over proprietary real-time operating systems since it is free and fully featured. Besides general operating system functions, both commercial and real-time Linux provide modern real-time multi-media applications such as graphics, sound and network drivers. This project will focus on performance measurement of kernel functions provided by the two operating systems. The project, in particular, will evaluate the:
  • scheduling
  • memory management
  • communications stack
through the use of application programs developed and real-time measurement tools.

In order to accurately measure these entities, the hardware platform will be chosen such that both of these operating system will support. The results of the experiment will be used to demonstrate and analyze the efficiency of commercially and publicly-available operating systems.

   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 Study of performance of two RTOS
  Shahmil Merchant, Kalpen Dedhia

Install 2 RTOS RTLinux and Ucos-ii as a dual boot
on a machine. Run certain benchmark applications
to test OS performance.

- To get RTLinux and Ucos-ii as a working RTOS.
- Getting a group of applications capable of
  running on both the OS.
- Techniques of setting benchmarks.

- A stand alone dedicated machine(We are hoping
  you could get us one).
- Access to computer science account.
- Ucos software

   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 Language and Operating System Performance
  Ambika Pajjuri*, Haseeb Ahmed*

We propose in the time frame of the semester to do
a performance analysis for a choice of select
algorithms varied over multiple systems running on
different CPU and Memory models.

Our proposed languages for comparison are Java and
C/C++. These languages have emerged from a "close
to assembly" paradigm (the C language) to a high
level object oriented model adopted for Java.

Our main objective is to study the strengths and
weakness of these languages through the analysis
of some traditional and some specially geared
algorithm implementations.

Our metrics will be based on (in no particular order): 

[1] Speed of execution.

[2] Memory usage:

[2.1] Algorithm static memory (compiled size)

[2.2] Operation memory (during code execution)

[3] Overheads imposed by choice of language.

[4] Selective features offered by each of the
    above languages and their impacts to
    algorithms (i.e. are the features more Hype or
    a Reality?)

Our initial plan consists of using the Linux and
Windows Operating systems.

We intend to add some variety by experimenting
with *nix-flavors on different CPU and memory
models. (This will vary based on machines the
project team has access to individually as well as
shared computer resources at Columbia University).

   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 A Domain-Specific Language for Network Interface Cards
  Apostolos Manolitzas
  The purpose of this project is to propose a specific domain language (SDL) for the implementation of device drivers for network interfaces cards (NIC). The idea is based on the GAL language proposed by Thibault Scott. The spotlight of the project will be the studying of current implementation of NIC device drivers and it will follow an attempt to patronize common components that consist each driver. The ultimate objective will be the proposal of a language that will follow the philosophy of specific domain languages. Of course an introductive literature survey will set the proper base.
   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report

NIC drivers for Linux


source code:Linux/drivers/net



source code: Linux/drivers/net/tulip

DP83840A for the MII

tulip reference


source code:Linux/drivers/net/

Please contact me to send you the technical notes with mail.



source code:Linux/drivers/net


data sheets


source code:Linux/drivers/net

data sheet RTL 8139

Useful Links

NIC info settings

Charles Spurgeon Ethernet Web Site

Networking at layer 1 & 2

 An ARM Simulator
  Alpa Shah

What is a simulator for assembly languages? : 

A Simulator is a simple virtual machine that can
directly execute compiled files normally loaded
onto processors. It provides a way for people to
learn the essential lessons of computer
architecture and assembly languages without
getting bogged down in the confusing details and
idiosyncrasies that plague real architectures.

Which Assembly Language : 

I am interested in working with RISC architectures
and would like to build a simulator of the ARM

ARM [Advanced RISC Machines] processor:

The ARM is a general-purpose 32-bit microprocessor
based on RISC principles. Its instruction set and
related decode mechanism are much simpler that
those of Complex Instruction Set Computers [CISC]
machines. It has two instruction sets:

- The standard 32-bit ARM set

- A 16-bit THUMB set 

Feature List :

Of the two instruction sets, I am going to
concentrate on the 32-bit ARM set. One objective
of this simulator would be to enable developers to
test out their new hardware. The system must be
extensible so that it is possible to add hardware
modules in order to test the new hardware.

The features of an ARM architecture that I would
like simulate are:

- assembler: to generate exact binary/machine code
corresponding to real compiled ARM machine code
for my simulator to execute

- support a smaller number of registers (general
purpose and dedicated, e.g. stack pointer, frame

- correct emulation of arithmetic, logical,
memory-data transfer and branch instructions

- use external compiler to generate ARM assembly
from C-code

- test simulator against various real-world programs

- have a configurable way of modeling the
Instruction set and/or architecture so that newer
instructions and registers, etc can be
incorporated into the simulation

Optional Features :

If I have enough time, I will incorporate some of
the following into the simulator

- a debugger: with the ability to insert special
breakpoint instructions in the machine code, and
instruction step features

- an integrated development environment that
provides a graphical user interface

Really optional Features :

- Develop a tiny interactive shell program/OS for
the simulator that can accept program names, and
load [from host file system] and execute them on
the simulator 
   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 Interface Synthesis
  Ganesh Sastry
  As the complexity of products increases and the market pressure in the technology industry climbs, the importance of reusing complex building blocks also increases. Interface synthesis, which attempts to determine an interface between two incompatible protocols that are trying to communicate with each other so that data transfer can occur, attempts to solve the problem of reusing building blocks. This results in the ability to reuse two complex blocks that may have not been able to communicate without interface synthesis. Since I have been doing research on this topic for only a few weeks, I propose the following for my research project:
  • Performance comparison on interface synthesis algorithms by Passerone, Borriello, Sun, Gajski, and Akella.
  • Extension of interface synthesis algorithm of Passerone to involve asynchronous protocols and streams of data.
My first choice for the research project is #2 but extending an algorithm is not always feasible. Therefore, I want to do #1 if I am unable to complete #2.
 Modeling a Simple Wristwatch using Esterel Studio
  Minsuk Lee, Cheryl Koesdjojo, Dixon Koesdjojo, Harish Peri
  The purpose of this project is to model a simple digital wristwatch using the Esterel Studio software and explore its limitations and abilities. The wristwatch we propose to model will conform to the following list of features:
  • Time display -- both AM/PM and 24-hour modes
  • World time display -- ability to show current time in any time zone
  • Current date display
  • Stopwatch (counter from 0 upwards)
  • Timer (counter for a fixed time interval)
  • Alarm
The initial step will be to model the wristwatch as a finite state machine (FSM) that will describe what the system will be doing under certain conditions and how the system should respond to environment requests. During this step, we will have to figure out the constraints on the system and the resulting design tradeoffs. For this step, we will utilize the extensive graphical modeling tools provided by Esterel Studio. High-level design will be followed by verification and testing. We will have to make sure that all possible states and evolutions in the state machine representation of the watch are "error-free". Test scenarios that check that validity of system behavior will have to be created using the validation tools provided by Esterel Studio. Once we have gone over all possible scenarios and modified the design to account for erroneous scenarios, the last step will be to use Esterel Studio to produce an interactive, graphical simulation of the wristwatch.
   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 SystemC and Verilog Comparison
  Gianfranco Bonanome*
  I would like to implement a simulation of an alarm clock in both Verilog and SystemC. The point of this project would be to compare the two implementations as well as learning the two languages and their respective simulation tools. The comparison will expose advantages and disadvantages of both languages, concluding in which of the two is more appropriate for such a project. The design itself will include a way to load a new time, as if a person was to manually reset it. The device will also have a way to set the actual alarm time and a timed comparator to set the alarm on, when it matches the current time. If time permits it, I would like to add features such as a "snooze" button. This could be implemented by an AND gate which has as inputs the snooze button itself, and output of the comparator mentioned earlier. When the output of this AND gate becomes asserted, an adder could be triggered to add, say 20 minutes to the preset alarm time, hence having the device ring again in 20 minutes. I am not too sure as to how challenging this idea is, since I need to figure out which software tools I will be using, and how long it will take me to familiarize myself to them and to the languages. In light of this, I may need to add or subtract features in order to meet deadlines.
   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 Study of Different Real Time Kernels for Linux
  Vanessa Frías-Martínez
  In our everyday life we are surrounded by embedded systems. In order for these systems to work, they are equipped with an operative system, compact in the sense that there is not so much space, but having as many functions as possible. And, since the development of embedded systems, Linux has existed to fulfill the necessities of those devices. Nowadays, several Linux distributions are being installed in embedded systems with total success.

At this point, we may ask ourselves, could we go even farther? Of course we can. Once we have the service guaranteed, we work on making improvements. Up to now, since operatives systems have fit perfectly l in embedded systems, we look for quick responses. In that sense, real time operating systems began to be transported onto embedded platforms.

And, again, Linux was there to offer those improvements but with the lively open-source philosophy that makes us free. It is amazing the huge quantity of people that are actually working in the development of real-time Linux kernels (both for embedded or non-embedded systems).

Since I am interested in the Linux world and philosophy, I have thought that this is a good chance to dig deeper into the interesting topic of real time kernels in Linux.

The following describes a rough outline of my project proposal. First, I propose to study the differences between already developed kernels (including both open-source and commercial versions), and see how they are implemented. I will focus on the open-source versions, especially in those developed by Kansas University, Berkeley, Carnegie Mellon, and the Politecnico di Milano. The first step will involve the study of these kernels, their implementation, their ways of dealing with interruptions, their handlers, schedules, etc. As a second step, some testing will be done in order to observe the concordance between the theoretic development of the kernels and their practical performance. Finally, having understood the system, some modifications on the code in order to see different behaviors will be implemented.

   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 Comparison of Real-Time and Non-Real-Time Operating Systems
  Dirk Bridwell* and Jan Miller*
  We propose to do the following:

Compare real-time and non real-time operating systems. We intend to make comparisons in three ways. First, we will compare the available facilities to support real-time operations. We will look at the types of synchronization mechanisms, task mechanism, and timers. Second, we will measure the times these mechanisms take. We will look at how deterministic the execution times are. Third, we will attempt to show that a program proven to meet its deadlines using Rate Monotonic Analysis will do so on all platforms. Or failing that attempt to explain why it did not.

We will be considering the following operating systems: Windows NT, Linux, RTLinux, and pSOS. The first two are well known non real-time operating systems. The second two are real-time operating systems. pSOS is a tradition RTOS, while RTLinux is a hybrid between an RTOS and a non real-time operating system.

In order to produce our Rate Monotonic Analysis we hope to use a piece of independently developed software. We are still trying to get a copy. This software also produces prototype code that we would then be able to execute on a given platform.

   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 Feasibility of an Embedded Network Real-Time Data Compression Protocol on the Rabbit 200 Microprocessor
  Stephen Jan and Paolo de Dios
  The great advantage of embedded systems is the ability they have to focus on few, specific tasks. The specificity allows the system to skip computational overhead that is typically associated with general purpose systems (i/o, interprocesses communication, compatability issues, etc...). This specificity comes with the price of resources. We are investigating the feasibility of taking an application that is typically associated with general purpose computing, and applying it to a embedded system. We are primarily interested in seeing how these tradeoffs manifest themselves in development and performance. The embedded system that we are targeting is the Rabbit TCP/IP development enviorment. This system uses a subset of C (Dynamic C), has very limited RAM (256K), and its processing power is minimal (18 MHz). The specifc application that we are targeting is data compression. We intend to port a data compression algorithim (possibly LZO) to Dynamic C, and benchmark its performance w/ a C implementation of the same application.
   page PDF File (for Acrobat) Literature Survey
   page PDF File (for Acrobat) Final Report
 Connect via Embedded Linux and Java
  This is a survey about the networking related features provided by embedded Linux. In this survey, we will summarize the major reasons why Linux is increasingly pervasive in embedded systems market. Seeing the trend that `everything to be connected', we will focus on the networking related features provided in embedded Linux, and compare several distributions. We will also put an eye on the use of Java in embedded systems version as long as the footprint is acceptable.
  Guang Lin
   page PDF File (for Acrobat) Literature Survey

Copyright © 2001 Stephen A. Edwards Updated Wed Dec 19 20:19:35 EST 2001 All Rights reserved