Current simulation languages are primarily libraries built on top of programming languages such as C++, Python, Java and Tcl. The modeler or architect must be conversant with the semantics and coding styles of these languages, in addition to understanding the system operation. Some can be extremely complex such as the object-oriented semantics of C++ and others will be complex mechanisms to create scheduled events such as Tcl/TK.

However, the use of the modeling-specific scripting language, called SmartMachine  that draws on concepts developed for the original Turing Machine can be used to overlay popular simulators such as SystemC and Ptolemy. This makes it possible to more easily construct and generate statistics for queuing, co-design and algorithmic models.

The simulator addition enhances the chosen simulation programming language to provide concurrency definitions, advanced data types and basic operations such as priority queue, scheduling schemes and statistics generator. It has been used in modeling a variety of applications including a functional cache, the FlexRay bus protocol, hardware schedulers and RTOS models.

Current simulation language approaches
Current simulation languages are stand-alone and integrated into the design flow. A large part of the system must still be defined using the standard language constructs. For complex activities, such as semaphores and thread management, the code required can only be developed by experienced programmers. In addition to system modeling background, these engineers need to be very good software programming.

The primary issue with simulation languages is the difficulty in creating models. These languages are introduced to make simulations run faster or for creating standards, but they take much longer to construct relative to the solutions being replaced. So, all the simulation performance benefits are lost to the model construction time. The SmartMachine addresses this by providing a small set of instructions and an integrated regular expression language. Models can be constructed using only these instructions and are as such readable by non-modelers.

Current programming simulation languages do not provide the ease of use requirement for wide adoption and lack such features as easy parameterization for repetitive runs, accessing modeling memories and generating scheduled events. Standard functions such as data type transformation, defining queues and arrays and complex regular expressions need to be built custom.

The model and the simulation code must be valuable beyond just the modeling world. It must be the basis for generating documentation and debugging implementation. To debug a signal problem in the implementation, the engineer could quickly refer to the system model. To be usable as a documentation tool, IP code has to be simple.

Code structure with well written code is possible, but visibility into structure in code is very difficult with existing approaches. Graphical block diagrams are incredibly effective for seeing patterns and can quickly identify problems that are almost impossible to figure out from code. A code that is built state-machine like and is procedural would be very quick for tracing and equal understanding by all.

The Turing Machine Advantage
Alan Turing created the "Turing" machine in 1936, based on a finite state machine that separates information into two elements, its internal state and externally derived state. At any instance of time, the state is based on its current state and the next discrete time step.

A "Turing" machine reads its input from a tape it is processing. The tape controls the behavior, based on the current state, and determines what action to take next (erase, write or move tape). Any particular Turing Machine can be described as an action table, or as state transition diagram, representing the same information in diagrammatic form.

The advantage of the Turing Machine is in its ability to store information to a tape of unlimited length, storage for partial execution results, and room for unlimited output. With the proper information on a tape (or script), a Turing Machine could emulate the actions of a different machine. The ultimate Turing Machine would be able to read any set of instructions from its tape.

Turing proved that such a machine, the Universal Turing Machine, would also be a universal computer, that is, it could emulate any machine whose behavior could be described symbolically. Turing assumed a conventional model of computation, meaning a distinction between fixed data and variable data, which a computer could operate on. The Turing Machine is considered the simplest form of generic processor. A Turing Machine has three commands and a simple state machine. Theoretically, a turning machine can perform any operation given an infinite tape.

The SmartMachine Difference
Similar to the Turing concept, the SmartMachine is like a tape that moves back and forth, with state machine like decisions. But unlike the Turing machine, this approach uses addresses, instead of a tape, and Jump-If-True, Jump-If-False and While are instructions that describe the decisions.

The SmartMachine is (1) closer to implementation, (2) more state-machine like, (3) handles threads easily and (4) works on memories. The scripting language consists of 10 instructions, 40 keywords and a Just-In-Time compiler. The concept behind using a reduced instruction set is that users can learn how to create a model using a custom, small instruction set scripting language quickly, as opposed to a general-purpose complex language.

Each script line can be indexed with an address and should be easily understood by hardware or software architects alike. The simplified instruction set also has the advantage of a simpler JIT compiler, and fast execution, much like RISC architecture, except it is done in software.

The blocks compile the script at run-time and execute within a simulation kernel. The language can describe dynamic functional and performance details of components, algorithms, implementations and sub-systems. The language has an extendable Regular Expression Language and creates classes of the script-instance with the optimized (JIT) compiler.

The scripting language uses the Just-In-Time compiler to accelerate simulation performance by 10-100X over existing scripting languages. The instructions, integrated operations and the Regular Expression Language reduce modeling time by over 6X relative to standard simulation languages. Other scripting languages, such as Tcl/Tk, Perl and Python, offer a limited set of similar functionality outside a simulation environment and tend to execute slower.

The SmartMachine has ten instructions:

DEF     Declare, or define, a memory
LBL     Label used as identifier by other instructions
END    End stops current thread and removes from Process Queue
ACT     Action instruction for expressions, queue operation and scheduling a wait
JIT       Jump if True is an if expression that responds to a true result and jump to an 
             instruction line based on a LBL or absolute address
JIF       Jump if True is an if expression that responds to a false result and jump to an
             instruction line based on a LBL or absolute address
WHL   While (evaluates to true) executes a set of instructions following this statement
             until a RTN command is reached, Else (evaluates to false) jump to an instruction
             line based on a LBL or absolute address
SBR     Execute Subroutine at an instruction line based on LBL or absolute address
RTN     Return to the SBR or WHL statement that corresponds to this Return
GOTO  An instruction line based on a LBL or absolute address
GTO     Thread is a special case of the Goto that initiates a new Thread while the
              current  Thread continues.

The user defines code in a fixed procedural format for the JIT compiler as shown in Table 1, below.

Table1: SmartMachine Procedural Format

Basic SmartMachine Operation
Figure 1 below illustrates the underlying block diagram for the SmartMachine. The Just-In-Time compiler is not shown in diagram. The script engine communicates with model memory as block, local, or global types. The script memory is known only to a specific instance of script.

Figure 1: SmartMachine Block Diagram

Using this block, the user can have multiple SmartMachine blocks running the same script with no memory name overlaps. The local and global memory can be accessed across multiple scripts instances.

The memories can be used to define priority queues, array queues, FCFS (First Come First Served) queues, array memories, scheduler links, or make virtual connections. The simulator-level integration of this script language leverages legacy models in the existing simulation environment. Moreover, the underlying regular expressions commands can be executed for complex operations.

The script engine also communicates with the Input_Queue (In Q, in Figure 1), Wait_Queue (Wait Q, in Figure 1), and Process_Queue (Thread Q, in Figure 1).

A user can add as many input and output ports to the script instance as required. The Data Structures arriving on the Input Port enters the Input_Queue. The "wait" statements can be executed in SmartMachine to either wait for a specified time or for a Data Structure (event) on an input port.

The name assigned to an input or output port, can be used in the script to retrieve Data Structures from an Input, or send Data Structures to an output. The SmartMachine can also communicate with other script instances and with other named memory locations that are visible from the script using a named connection.

Data Structures can be transferred virtually anywhere within the simulation model using this feature. The Input Queue contains Data Structures arriving on the input port(s), directly through virtual memory connection(s), or from internal thread functions.

The Wait Queue is populated with the Command Address and the thread which is waiting for an external event. The Thread Queue contains the list of the different threads currently executing. Thus, if a thread is waiting for an input event to continue processing, then the thread will be in the Wait Queue. Once an event arrives, the waiting thread will be moved to the back of the Thread Queue for execution.

Figure 2: SmartMachine script for an M/G/1 queue model of a Bank Teller

The example script above in Figure 2 shows the construction of a Bank Teller Line defined as a M/G/1 queue (exponentially distributed inter-arrival times and an arbitrary distribution for service times) using the Input_Queue and the SmartMachine instructions. The instructions are used to generate customer arrivals at a Bank Teller. The customer arrival rate is based on the selection of the distribution parameter in the graphical entry.

The SmartMachine is shown integrated into VisualSim, an architecture exploration simulation environment from Mirabilis Design. The output histogram of the script for the different distribution selections is show in Figure 3 below.

Figure 3. Histogram output from SmartMachine script plotted in VisualSim Post Processor

Conclusion
A modeling-specific Turing Machine that executes a script with 10 types of instructions, SmartMachine combines the power of custom-code with graphical modeling to create a highly productive modeling paradigm for solving complex problems.

There are many applications that can take advantage of the SmartMachine, especially where the model schematic size and simulation speed are a consideration, including:

* Software Estimation
* Hardware Refinement
* Real Time Operating System
* Protocol State Diagrams
* Switch Fabrics
* Algorithm Analysis
* Advanced Statistics generation
* Complex Functional Expressions
* Multi-threaded applications

The advantages of this approach are ease-of-learning and use, native code speed simulation performance, small code footprint and language flexibility. Modelers can author blocks for reuse by others.

Deepak Shankar is Founder/CEO and Darryl Koivisto is CTO at Mirabilis Design Inc.

Reference:
[1] "Computing Machinery and Intelligence" " Alan Turing, (Mind, 1950).