.en
.ps 11
.vs 13
.hy 0
.nr sf .25i
.nr so 1.5i
.nr sn 1.5i
.nr
.ps +2
.vs +2
.ce 1000
.ft B
The tmumon Program
.sp
.ps -2
.vs -2
.ft I
Dave Galloway
.sp
Edward S. Rogers Sr. Department of Electrical and Computer Engineering
University of Toronto
.sp
April 2013
.ce 0
.ft R
.ds TL ''- % -''
.su
Introduction
.pp
The \f(CWtmumon\fP program is a daemon process that acts as a front end for the
demonstration board.
It runs on the workstation that is connected to the
demonstration board (currently skynet.eecg, April 2013).
.pp
Tmumon opens two network TCP stream sockets,
and sits waiting for connections to those sockets.
On one of the sockets (the housekeeping socket) tmumon will accept requests
to change or report on the state of the demonstration board.
On the other socket (the ports socket) tmumon will accept data to be
transferred to or from a user's design inside the demonstration board.
See \fIThe TMU Ports Package\fP for a description of how the ports socket
is used.
.pp
A second program called \f(CWtm\fP is usually used to talk to the housekeeping
socket of tmumon.
The tm program can be run on any host, and will transfer one or more requests
to tmumon over the network.
A single request can be given as the arguments to tm.
For example,
.sp
.nf
.in +2i
.ft CW
tm getdesigndir
.in -2i
.fi
.ft R
.sp
will ask tmumon for the name of the directory containing the design
most recently loaded into the demonstration board.
.pp
Multiple requests can be passed to the tm program on the standard input by
giving it a "-" argument:
.sp
.nf
.in +2i
.ft CW
tm -
getdesigndir
getdesigndate
^D
.in -2i
.fi
.ft R
.su
Starting Tmumon
.pp
To start the tmumon daemon, sign on to the computer that has the
demonstration board board connected to it, and type:
.sp
.nf
.in +2i
.ft CW
cd /
tmumon &
.in -2i
.fi
.ft R
.su "Tmumon Housekeeping Socket Requests"
.pp
This is a list of the requests that tmumon understands on the housekeeping
socket:
.l1
.le
acquire P N	Ask for the demonstration board at priority P for N seconds.  Returns 0 if
successful, or the current priority and the number of seconds left in the
current reservation if not.
.le
debug N	Set the debug level to N.  Debugging output will go to
tmumon's standard output.
.le
EXIT	Causes tmumon to exit.
.le
getarch	return TMU as a string
.le
getdesigndir	return the arguments of the last setdesigndir command
.le
getportlistdir	return the arguments of the last setportlistdir command
.le
getstatus	return a string of 1s and 0s that describe the current
status of the board
.le
getstatus1	return the arguments of the last setstatus1 command
.le
getstatus2	return the arguments of the last setstatus2 command
.le
hostname	return the name of the host that tmumon is running on
.le
release	release the demonstration board so others can acquire it
.le
setdesigndir dirname	set the name of the directory containing the design
.le
setportlistdir dirname	set the name of the directory containing the port lists
for the current design
.le
setstatus1 args	set the string returned by getstatus1
.le
setstatus2 args	set the string returned by getstatus2
.le
stop	kill off any ports sockets connected to programs that are talking to the
current design.
.e1
.su "Tmumon Ports Socket Format"
.pp
The ports socket is normally used by the tmuports package to send data to
and from a user's circuit in the demonstration board.
Data is sent to the ports socket as a series of packets.
Each packet consists of a 32 bit packet header,
followed by optional data bytes.
Each header specifies a chip and port number where the data is
to be transferred.
The 32 bit header is sent in network byte order (most significant byte first).
The most significant bit is labelled 31 in this table:
.sp
.ne 1.5i
.TS
center;
c c
n l.
Bit Number	Meaning

31	1 for a write (data transferring to circuit); 0 for read

30	1 if the port uses handshaking; 0 if not

29-28	must be 0

27-26	top two bits of packet data length

25-18	port number inside the chip

17-12	width of the port in bytes

11-0	bottom 12 bits of packet data length (max length is 16383 bytes)
.TE
.pp
A header requesting a write must be followed by the number of bytes of data
that were specified in the header.
A read request header will cause tmumon to block until the specified number
of bytes are received from the design.
.pp
Each request (read or write) will be answered by a 32-bit word containing
the number of bytes transferred to or from the circuit in the case of a
successful transfer, or -1 in the case of an error. 
If it was a successful read request, the word will then be followed by
the number of bytes requested.
