©
1997 IEEE. Personal use of this material is permitted. However, permission
to reprint/republish this material for advertising or promotional purposes
or for creating new collective works for resale or redistribution to servers
or lists, or to reuse any copyrighted component of this work in other works
must be obtained from the IEEE.
By choosing to view this document, you agree to all provisions
of the copyright laws protecting it.
[ Index | Introduction | Expositive | Demonstrative | Interactive | Practical | Conclusion | References ]
Continuing the methodological
classification of learning tools, that represents the skeleton of this
paper, it is now time to make clear what we mean with the term "practical"
applied to a pedagogical methodology and which are the tools that apply
such methodology [23]. The learning tools
presented so far are targeted to foster the understanding
of concept or to acquire some operational capability. They process, therefore,
contents that their developers have built within the tools themselves.
The tools belonging to our practical methodology, instead, are designed
to process, within a specific field, data that the learner has entered
[24].
In a course of digital
electronics, beyond the ability of understanding concepts, methodologies
and existing implementations, it is necessary to acquire design capabilities.
Conceiving circuits and systems is generally more difficult than understanding
and analyzing them and it requires different and complementary skills.
It is also difficult to teach, because the solution to a design problem
is not unique, and consequently the presentation of just one possible solution
is somewhat misleading, while a thorough investigation of many different
design alternatives is too time-consuming when carried out only with paper
and pencil [18].
The situation demands the
services of a kind of tools that allow the students to process their
own data with the final target of designing and testing a system [3].
The use of professional simulators for this process is not recommended
because students cannot have the skills and the frame of mind of the accomplished
digital designer, for whom the professional tools are made.
We have developed a set
of tools to support this approach. They are divided in two groups: local
tools and general purpose tools. To the first group belong simple software
applications with a limited scope: typical examples are the code-converters,
the memory maps generator, tools for Boolean function synthesis and minimization
and so on. Local tools are usually developed using the hypertext authoring
environment. The second group is composed of three general purpose simulators
(digital networks, state machines and microprocessor). They are custom-built
applications with approximately the same characteristics of professional
CAD tools for electronics, except that their design has been carried out
with a strong pedagogical orientation [25].
Their construction has required different software instruments and programming
skills.
A typical local tool
(Fig. 16) performs the conversion from a digital number
to the corresponding binary. In the automatic mode it works as a tool:
when the user needs a conversion, may do so by typing the number in the
input box (white in the figure) and clicking on the proper button. In the
manual mode the tool assumes a pedagogical value (interactive methodology)
because all the calculations necessary for the conversion must be executed
by the learner, under the control of the tool (working example).
Another local tool (Fig.
17) has been designed to help the students practicing in the field
of memory systems. It provides, as output, the memory map, the chip connections
and the decoding circuit of a microcomputer memory system. It takes, as
input, the amount and type of the required memory and the size of available
chips (working example).
In this paragraph we provide a short description of the three simulators. Given their relative complexity, it is beyond the purpose of this paper to allow the reader to play with working examples, as we did with the learning tools presented before. We plan to do so in another paper, dedicated specifically to the general-purpose tools.
The Digital Circuit
Simulator (DCS) appears to the user as a digital circuits editor (Fig.18),
with the possibility of choosing components from a function library and
to interconnect them with wires. DCS does not reproduce, as many commercial
educational simulators do, the "laboratory metaphor". Real laboratory
instruments are too complicated and distracting for a beginner student.
It is simpler to show a waveform as a timing diagram instead of reproducing
the screen of an oscilloscope to be controlled by a virtual panel full
of knobs [26]. A novel feature of the tool
is the provision to operate at different levels of user competence. As
an example, the number and complexity of the available components are functions
of the level chosen.
The student interacts with
the circuit under simulation by flipping the input switches, running the
clock generators and observing the resulting changes. An output window
shows the timing diagrams of input, output and clock signals. The simulator
has two modes of operation: "run" and "step". In the
"run" mode the signals are visualized as flowing timing waveforms.
In the "step" mode the simulation proceeds by events, to observe
in details the circuit behavior. Such mode of operation is especially useful
for troubleshooting a network just designed. The digital networks, and
the waveforms obtained by simulation, can be stored and used for future
sessions, or printed.
In the case of anomalous
circuit behavior (such as iteration of unknown states or uncertainty of
the final state) the simulator warns the user with messages whose content
is function of the competence level described above.
The Finite State Machine
simulator speeds up considerably the process of verifying the design of
an ASM-based FSM. Three main integrated modules compose the FSM simulator:
the graphic editor, the logic simulator and the map synthesizer [27].
The editor allows the graphical
construction of the FSM diagram, according to the rules of the ASM method.
In this phase the student is assisted by a toolbox containing the drawing
tools, and a window showing the properties of the selected objects. ASM
charts are constructed by using the mouse and toolbox’s buttons to insert
and to interconnect the appropriate blocks, captions and comments. The
properties of the objects inserted in the diagram are defined, examined
and modified by a window which content is context-sensitive. A syntactic
and semantic corrector identifies the most common mistakes, such as diagram
inconsistency, duplication of names and codes, and insufficient number
of state variables.
The logic simulator generates
the timing waveforms of the FSM state and output variables directly from
the analysis of the ASM chart. Time tracing of input, state and output
variables takes places in a dedicated window. In this window the student
can interact, step by step, with the FSM time evolution by clicking on
buttons corresponding to the machine inputs. At the same time, the student
can observe the current state involved and the path to the next one, highlighted
in the window containing the ASM chart. The resulting effect is of a visual
animation of the machine. It is worth to note that this tool, allowing
the preliminary simulation of the ASM chart before going to the synthesis,
presents the logic of the state sequence without the complication of the
network synthesis, as it would be the case using a professional digital
simulator.
The last module, the logic
synthesizer, provides automatically the next state and output Karnaugh
maps from the FSM diagrams. Fig. 19 presents three
windows of the Finite State Machine simulator: the state diagram editor
with its toolbar (left), the simulation presented as a timing diagram (bottom-right)
and the synthesis (top-right).
The microprocessor emulator
(EMUZ80) is a tool to write and run programs for the Z80 microprocessor
(the one presented in the course) [14]. The
emulator places itself between an assembly Z80 program and the computer
under which it runs, by translating the assembly language program into
a code executable by the host computer and running it. For the sake of
simplicity, the microprocessor is initially presented to the learner
in a reduced form (only a subset of its architecture is
used) and the emulator can be successively configured to represent the
complete microprocessor structure using a menu command. Another pedagogical
aspect is the emulation of the memory, that allows students to use properly
ROM (Read Only Memory) and RAM (Random Access Memory) present in the system.
In a professional emulator (as well as in a real system!), programming
or memory allocation errors usually produce system crashes that cannot
be easily understood by the beginner student. Our emulator provides a protection
from most of this kind of errors by inhibiting programs to produce the
operations that would be fatal in a real system: it supplies warning and
information when such errors occur. For example, unlike professional emulators,
the emulator warns the learner when attempting to read a RAM memory location
that has not been previously initialized.
The emulator provides the
following functions: program editing, assembling of mnemonic instructions
into machine code, code loading in the emulated memory, execution of the
code. Because only the first and the last function must be controlled by
the user, the intermediate phases are carried out by the emulator in a
transparent mode. Program execution may be continuos or step-by-step, with
the possibility of setting breakpoints and inputting manually the contents
of registers and memory locations (Fig. 20). A complete
hypertextual on-line help completes the emulator.
Fig. 16. A decimal-to-binary conversion tool.
Fig. 17. A screen-shot of a tool to build memory systems.
Fig.18. The Digital Circuit Simulator (DCS) with a circuit under simulation
and the output window.
Fig. 19. The Finite State Machine simulator: the state diagram editor and
its toolbar (left),
the simulation (bottom-right) and the synthesis (top-right).
Fig. 20. The emulator, executing a program in Z80 Assembler, has reached
a breakpoint.
