\documentstyle[newcen]{article}
\begin{document}

\section{Overview}

In the hands-on study of Digital Logic\footnote{EECS couses 6.004,
6.111 and others.}, the ``nerd kit'', a portable electronic
breadboard, is used by students to construct medium scale digital
systems using standard devices. Design and analysis of these systems
could be simplified by computer simulation, especially with good
graphical tools with which to observe the simulation.

\section{Breakdown}

The simulator engine should focus on the combinational and sequential
aspects of digital logic. It should address the following ideas:
\begin{enumerate}
\item Multi-state combinational logic, with at least the states hi,
low, tristate, undefined, contention. Perhaps active/inactive which
are special forms of hi/low which are specific to the `type' of
wire/input they are hooked to. 

\item Simulation by logic elements. This should include and, or,
not, xor, latch elements%
\footnote{Latches should be included for efficiency, not completeness,
as they can be built from combinations of AND and NOT}
PALs, ram, rom, clock elements, data streams (serial and parallel).

\item Simulation by actual device specification. A mapping should be
constructed between collections of logic elements and actual parts,
with time delays included as needed. 

Certain ``real element'' behaviours should be included:
\begin{itemize}
\item propagation delays.
\item glitches.
\item rise-time requirements.
\item tri-state behavior and contention. Some of these can be detected
at setup time, others at runtime.
\item continued oscillation due to feedback.
\end{itemize}

	A straightforward mapping must exist between these two types
of simulation; it should be partially automated, but since this is a
tool for educational use, it should be very clear at all times what is
happening.

\item Creating modules on the fly. Seperate modules could exist
at the logic and device levels, but the ability for the user to create
repeatable subsystems of their own in a simple manner is very
important.

\item Graphic tools to accomplish all parts of the project.
These include:
\begin{enumerate}
\item digital scope/logic analyser (which should be
built upon the user interface of some existing device, to make it
RELEVANT to the user, instead of obscure.)
\item digital input sources. Used in conjunction with a
``wired nerdkit'' and a logic analyser, the student can inject 
\begin{itemize}
\item static digital signals
\item dynamic digital signals (clocks)
\item data streams (serial or bus-width)
\end{itemize}
and get immediate feedback on the affect of these upon
the circuit under test.

\item graphic logic designer. Pick and place logic
elements, with user-assisted wire routing, to produce large modules of
circuit that can be tested using the tools developed under (a) and (b)
with look and feel similar to that available from real hardware.

\item graphic ``nerdkit''. This would cover full layout of
components, on a graphic grid that had the virtual dimensions of the
labkit, but which had elements which were actual circuit elements. The
same testing could occur here as in the logic designer, with the
ability to go quickly from one to the other to make it clear what was
actually on the board. This could be used in conjunction with a real
nerdkit, and would provide the mapping between the two simulation
types.
\end{enumerate}

The ability to go from a wired nerdkit to a logic design would be
convenient, although it might require a ``very clever'' algorithm for
wire and element layout. This may be an interesting project itself, or
a subject of future study.

\end{enumerate}

\section{Analysis}
The graphic tools are the most visible results of this thesis. They
contribute highly to the usefulness of this system as a tool, although
they are not critical to its success.

I believe that (5) would certainly be the most visible part of the
thesis, although (3) is the most critical and time-consuming. As you
mentioned, this tool should be available, but not necessary for
students to use; its success could be measured in terms of how
accessable the students find it.

Since the description above expects interfaces of a very interactive
nature, I will need to develop the simulator `engine' along a
different direction than it has grown so far, to allow both
interactive change in the circuit itself and the progress of
time/data. This may make a `batch' simulator useful for speed,
however, when simulating large circuits (yet another branch to diverge
into, including parallel computations.)

Probably the most `interesting' component of the project, from a
Computer Science viewpoint, would be the mappings between different
abstractions (logic elements, devices, positions on a graphic screen)
and how they are kept consistent. From an Engineering viewpoint, the
simulation of actual devices is very interesting. The graphic
interfaces are interesting in there own way, independent of the
others; it seems this project has at least some breadth, although its
depth depends on how much focus is given to different areas.

\end{document}
