next up previous contents index
Next: The Ascii Format Up: Using Xic Previous: Batch Mode   Contents   Index


Server Mode

Xic has the capability of operating as a daemon process, servicing requests for processing of design data. This allows Xic to be used as a back-end for automation systems designed by the user or third parties.

To start Xic in server mode, the -S option is used, as

xic -S[port]

This causes Xic to start without graphics, go to the background, and listen to a system port for requests. The port number used can be provided on the command line immediately following the ``-S''. If not given on the command line, the ``xic/tcp'' service is queried from the local host. This will come up empty unless the ``xic/tcp'' service has been added to the host database, usually by adding a line like the following to the /etc/services file:

xic           3002/tcp   #Whiteley Research Inc.
where the port number 3002 is replaced by the desired port number. If there is no port assigned for ``xic/tcp'', port 3002 is used.

If the environment variable XTNETDEBUG is defined, Xic will not go into the background, but will service requests while printing status messages to the standard output. This may be useful for debugging.

The user's application should open a socket to this port for communications. Only one process can access the port at a given time. For testing and experimental purposes, the telnet program can be used to connect to the Xic daemon. After starting the daemon, one types

telnet hostname port
where hostname is the name of the machine running the daemon (one can use ``localhost'' if running on the local machine). The port is the port number in use by the daemon.

While the server is working on a task, the server is sensitive to interrupts. An interrupt will cause the server to abort the current task and begin listening for new instructions. The interrupt handling works about the same as in graphical mode when the user types Ctrl-C, though there is no confirmation prompt -- the task is always aborted. There may be a short delay before the interrupt is recognized.

Interrupts can be sent to the server by sending an interrupt (``INT'') to the process number of the server with the Unix kill command. The server socket will also raise an interrupt if out of band (OOB) data are received. Thus, the client can send a single arbitrary byte of OOB data to generate an interrupt. The Unix manual pages describe the concept of OOB data.

The default data mode for communications is ascii mode. In this mode, all data are transferred as ASCII text. Also available is binary mode, where data returned by the server is in a binary format, which can be more efficient for large data transfers.

The text expected by the daemon is in the form of statements which can be understood by the script interpreter, i.e., script lines. In addition, there are a number of special control commands. The modes implied by these commands apply to the current connection, and never carry over to subsequent connections. These commands consist of a single word from the table below:

close
This will close the connection to the daemon, and is the normal way to end a session. The daemon will generally clear the database of all cells and otherwise initialize itself to a clean state for the next connection (effectively calling reset and clear, see below), though this can be suppressed with keepall (see below). The daemon will begin listening for new connections.

kill
This will close the connection and cause the server to exit.

reset
This command will reset the script parser to its initial state, exiting from any control block in effect and deleting any script variables that may have been defined previously.

clear
This will clear the server database of all cells, and delete any layers that were not initially read from the technology file. This is equivalent to calling the ClearAll script function.

ascii
When given, subsequent transmissions will use the ascii data format. This is the default format.

binary
When given, subsequent transmissions will use the binary data format.

longform
When given, subsequent transmissions will use the long form for returned data, meaning that the actual data are returned.

shortform
When given, subsequent transmissions will use the short form for returned data, which consists of only the data type code. This is the default.

dumpmsg
When given, the text of subsequently received messages is printed, surrounded by vertical bar (`|') symbols, on the standard output, meaning that the text will appear in the daemon_out.log file in normal operation. If the server is running in debugging mode (the XTNETDEBUG environment variable was found when the server started), this text will be printed on the console window.

nodumpmsg
This turns off the printing of received messages, if dumpmsg was given. It has no effect otherwise.

dieonerror
Ordinarily, if the client crashes or there is a connection failure, the server will simply clear itself and wait for new connections. If dieonerror was given, the server will instead exit.

nodieonerror
This will undo the effect of dieonerror, if dieonerror was given, and has no effect otherwise.

keepall
Ordinarily, when the server receives a close command, the interpreter context is reset, the cell database is cleared, and other steps are taken to provide a clean environment for the next connection. If this command is given, all of this will be skipped, so that the same context and environment will be available to the next connection.

nokeepall
This will undo the effect of keepall, if keepall was given, and has no effect otherwise.

The normal way to terminate a session with the server is to issue the close command, which will reset and clear the server and close the communication channel, and the server will begin listening for new connections. The ``reset and clear'' is equivalent to giving the reset and clear commands. If the keepall command was in effect, the server will not be reset and cleared before the connection is closed, thus its state will be retained for the next connection. If there is a communications error, the server is always reset and cleared, or will exit if dieonerror was in effect.

When a new connection is established, all of the modes associated with the commands assume the default values. These states do not carry over if keepall was given, so that the appropriate commands must be repeated to establish the same state.

There is quite a bit of internal server state that is not reset to any preset value between connections. Examples are the mode (physical or electrical) and the status of variables set with the !set command or Set function. Thus, when writing scripts for execution by the server, it is important to explicitly initialize any such state or variable.

All other input should be parsable by the script parser, except that lines that start with `#' are not allowed, so no comments or preprocessor directives are allowed.

After each line of input is given, the server returns a message giving the data type and possibly the data for each script command. Most script functions return some value. Assignments return the value assigned. A variable name returns the value of that variable, if the variable has a known type. The default mode is to return only the data type code, which minimizes the network overhead. Optionally, the longform command can be applied, in which case the data are returned. Note that this can be arbitrarily large for some data types.

If the XTNETDEBUG environment variable is set when Xic is started in server mode, a debugging mode is active, and Xic remains in the foreground. If the dumpmsg command is given, Xic will print the text of messages received on the terminal screen, enclosed in `|' symbols to delineate the text. The command nodumpmsg can be given to turn off the message printing. This can be a useful feature for debugging a client-side program which is communicating with Xic.

An example file xclient.cc is available which provides a demonstration of how to interact with the Xic daemon through a C/C++ program. This file can be found in the examples directory of the Xic installation.



Subsections
next up previous contents index
Next: The Ascii Format Up: Using Xic Previous: Batch Mode   Contents   Index
Stephen R. Whiteley 2006-10-23