SMOK Introduction Last modified: April 12, 2005

CSE Home

About Us

Search

Contact Info

Overview

SMOK is the machine organization simulator component of the Sloop Machine architecture course project.  SMOK components are modelled after (and include all) those found in "Computer Organization and Design: The Hardware / Software Interface," by Patterson and Hennessy.  For those without a copy of that book at hand, components are things like and gates, registers, and muxes, and more complicated components like ALUs and register files.  SMOK model simulation is much higher level than  that  provided by gate-level simulators, and much lower level than a typical student would write if asked to simulate a processor in software.  Here's a picture of a SMOK model that simply counts.  (The Halt component is a SMOK artifice to allow termination of the simulation.)

SMOK simulates these components at a functional level.  SMOK models do not use detailed timing information, in the sense that path lengths are irrelevant (and, more or less, assumed to be zero).  Rather, each clock cycle has a "clock up" and a "clock down" edge.  All combinational components are settled during clock up, with SMOK automatically ensuring that stable inputs are available to them before advertising outputs.  Latched components latch on "clock down."   SMOK allows the user to specify component delays by component type, and uses these to compute a minimum possible cycle time for the machine organization, but this is a static evaluation and those delays are not used in any way to drive the simulation.  (SMOK also evaluates machine "cost," using per-component-type costs that can be set by the user.)

SMOK supports the Sloop Machine,  a low-level RISC architecture designed to allow  pipelining of the Atari 6502 (think "game console") and its software (think "Donkey Kong") through on-the-fly translation of 6502 instructions into Sloop instructions (think "Pentium Pro").  Details on the Sloop are forthcoming.

The Sloop/SMOK software is designed to be portable to multiple user interfaces.  The original interface was as a C-library, requiring the user to specify the target machine organization as a set of C++ new's of SMOK components, and then simulating that organization.  Output was in the form of a trace file that the simulator would spend all its time writing instead of getting any simulation done.

The current version of Sloop/SMOK comes with a Windows front-end.

Basic Simulation Operation

This section gives an overview of SMOK simulation.  The information presented here is independent of the SMOK UI used.  UI dependent operations, such as how to define or edit a model, are presented in sections on the various UI's (of which there are currently one).

Each cycle is divided into two phases, ClockUp and ClockDown.  

• ClockUp
  
  At ClockUp each component in the model is given a chance to read its inputs, and to calcuate and advertise new output values.  Unconnected inputs produce 0's when read.  Any connected input is guaranteed to have an updated value; that is, reading an input connected to the output of some component X during cycle N yields X's output for cycle N.  For combinational components, this is their new value, computed by their reading their own inputs during the ClockUp phase of cycle N.  For latched components, this is the value they last latched (during cycle N-1 or earlier).
  
  Under this scheme, cycles of combinational components are unstable; it is unspecified what the computed outputs should be since there is no way for all components in a cycle to read updated values for their inputs (given that SMOK models do not contain information about path lengths or propagation delays).  SMOK detects such cycles when they occur and raises an error that halts simulation at that point.  Note that this detection is done dynamically, not statically, so it is possible (if unusual) to have static loops among combinational components so long as no execution sequence produces a live loop.  (E.g., a MUX connected to one latched and one combinational component may be involved in a static loop, but if the combinational input is never selected during execution no error results.)
  
• ClockDown
  
   During the ClockDown phase each latched component is given a chance to latch its input.  Whether or not an individual component does so may be dictated by control lines; e.g., the Register component has a single-bit control line that causes latching when the value of that line is 1, and skips latching when it is 0.

When the simulator is paused (it has two states, simulating and paused, so whenever it's not simulating it's paused), it is held in a state equivalent to being after the ClockUp phase of the next cycle but before the ClockDown.  This means that as the machine configuration is modified, for instance by adding components or by changing connections among them or by altering the values of latched components, the values advertised stay consistent with each other and the operation of the individual components.  For this reason, the "current cycle" information available while paused indicates the next cycle to be executed.  (Cycles are numbered starting at zero.)

How Do I Know My Model Is Working?

If you don't give your users any way to see the values produced by your simulator, it's possible to perform remarkably fast simulations of very complex models.  Appealing as this may be, we took a more middle road, providing outputs at the cost of some simulation speed.

Model outputs are, to an extent, dependent on the UI used with SMOK.  However, SMOK contains a component type intended solely to produce debugging output.  This component, called a DebugOutput component, has no functional purpose in the machine organization (and isn't in Patterson and Hennessy).  It can be attached to the output of any other component in the model, and can itself be attached to (so that it can be spliced into a functional connection as a kind of passive probe).  During simulation, it writes its input value during the ClockUp phase of each cycle (following the usual rule of always reading an updated input for that cycle).  Where it writes is dependent on the UI.  In WinGUI it writes to a dedicated window (one per DebugOutput component); the information in that window can be printed or cut-and-paste'd into some other application.

SMOK provides two other components not part of real machines.  The DebugInput component is an way of soliciting input from the terminal each ClockUp phase.  It cannot be connected to any other model component (since it's connected to the keyboard), but other components can connect to it for their input.

The final simulation-only component is the Halt component.  It provides conditional termination of simulation depending on the state of the simulator.  In particular, a Halt component has an internal value that is compared each ClockUp against the value read from its input.  The Halt component can be configured to stop the simulation when the two values are equal, or unequal.

Department of Computer Science & Engineering University of Washington Box 352350 Seattle, WA  98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to zahorjan@cs.washington.edu]