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           6115/tcp   #Whiteley Research Inc.

where the port number 6115 is replaced by the desired port number. If there is no port assigned for ``xic/tcp'', port 6115 is used, as this is the IANA registered port number for this service.

If the XTNETDEBUG environment variable is defined when Xic is started in server mode, a debugging mode is active. Xic will remain in the foreground, but will service requests while printing status messages to the standard output. This may be useful for debugging. 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.

The user's application should open a socket to this port for communications. Up to five channels can be open simultaneously.

All transmission to the server is in ASCII string format, however replies are in a binary format, and are likely to be invisible or gibberish in a text-mode connection such as telnet. However, the telnet program can be used to connect to the Xic daemon, and can be used to give simple commands, such as the kill command. 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.

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.

Communication can also be established through use of the example xclient.scr script, which illustrates use of script functions to implement a client within Xic.

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 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.

As more than one connection can exist at the same time, commands from one connection can dramatically alter the environment seen by the other connections, including clearing of data and killing the server. Though the connections are separate, they should be considered as multiple windows into a single processing environment rather than separate processing environments.

Generally, when the last connection closes, all data within the server will be cleared and its state reinitialized, though this can be suppressed, allowing persistence of state and data.

The server may be used as a ``geometry server'', providing compressed representations of the geometry in cells, by layer, as from a Cell Geometry Digest (CGD). A connection object can be linked to a Cell Hierarchy Digest (CHD), allowing operations with the CHD to obtain geometry through the server. This would reduce memory use on the local machine, assuming that the geometry is stored on a remote server.

The built-in non-script commands are described below. 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.

All transmissions to the server are readable ASCII text, using standard network `` \ r \ n'' line termination. Replies from the server are in a binary form described below.

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.

close
This will close the connection to the daemon, and is the normal way to end a session. If no other connections are open, 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 continue 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. This will affect all open connections.

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. This will affect all open connections.

longform
After each line of script input is given and the line processed, a response message will be returned based on the computed result from the line, if any. The user has a choice of receiving a very brief reply, giving only the response code - an integer which indicates pass/fail and the type of computed data, if any. The other choice is to actually return the data along with the response code. The data can be arbitrarily large.

The default return is ``shortform'' which does not transmit the data values. Giving this command switches to the mode where values are returned, for the present connection only.

shortform
When given, subsequent replies fro the present connection 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 from the present connection 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, and applies only to the current connection.

dieonerror
Ordinarily, if the client crashes or there is a connection failure, the server will simply reset itself and continue waiting for new connections and handling other existing connections. If dieonerror was given, the server will instead exit on failure of the current connection.

nodieonerror
This will undo the effect of dieonerror, if dieonerror was given, and has no effect otherwise. It applies only to the current connection.

keepall
Ordinarily, when the server receives a close command, and there are no other connections open, 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. This is a single flag which can be set or reset from any connection, but applies to all connections.

nokeepall
This will undo the effect of keepall, if keepall was given, and has no effect otherwise. This can be given from any connection, and applies to all connections.

geom [chd_name] [cellname]
The geom command implements the ``geometry server'', and unlike the other built-in commands this is an actual function and does not affect the interface state.

Information from Cell Geometry Digests saved in server memory is made available through this interface. The OpenCellGeomDigest script function can be used to create CGDs in the server, and of course the target layout file must be accessible to the server.

All of the arguments that follow ``geom'' are optional, though arguments to the left of a given argument are required. Below are the accepted forms and returns. In all cases, the actual data are returned, as with longform.

geom
If no arguments are given, the reply is a space-separated string listing of CGD access names found in the server. If an access name contains white space, it will be quoted.

geom ? cgd_name
This form will return the string ``y'' if cgd_name is the access name of a CGD in memory, ``n'' if not found.

geom cgd_name
The argument is taken as an access name of a CGD in server memory. The return is a string containing space-separated cell names found in the indicated CGD.

$\parbox{4in}{{\tt geom} {\it cgd\_name} {\tt -?}\\ {\tt geom} {\it cgd\_name} {\tt ?-}\\ {\tt geom} {\it cgd\_name} {\tt -}}$
The argument is taken as an access name of a CGD in server memory. The return is a string containing space-separated cell names that have been removed from the CGD.

geom cgd_name ? cellname
This form will return the string ``y'' if cgd_name is the access name of a CGD in memory, and cellname is found in that CGD. The string ``n'' is returned if the CHD access name matches a CGD name, but the cellname is not found in that CGD. An empty string is returned otherwise.

geom cgd_name - cellname
if the cgd_name and cellname match a CGD and cell, that cell will be removed from the CGD, and resources freed. However, the cell name and its status as having been removed is retained. This will return the string ``y'' if cgd_name is the access name of a CGD in memory, and cellname is found in that CGD (and removed). The string ``n'' is returned if the CHD access name matches a CGD name, but the cellname is not found in that CGD. An empty string is returned otherwise.

$\parbox{4in}{{\tt geom} {\it cgd\_name} {\tt -?} {\it cellname}\\ {\tt geom} {\it cgd\_name} {\tt ?-} {\it cellname}}$
These forms will return the string ``y'' if cgd_name is the access name of a CGD in memory, and cellname has been removed from that CGD. The string ``n'' is returned if the CHD access name matches a CGD name, but the cellname is not in the removed list for CGD. An empty string is returned otherwise.

geom cgd_name cellname
If two arguments, they are taken as the CGD access name and a cell name in the indicated CGD. The return is a string consisting of space-separated layer names of layers in the cell that contain geometry.

geom cgd_name cellname ? layername
This form will return the string ``y'' if cgd_name is the access name of a CGD in memory, and cellname is found in that CGD, and layername the name of a layer found in that cell. The string ``n'' is returned if the CHD access name matches, but either cellname or layername is not found. An empty string is returned otherwise.

geom cgd_name cellname layername
With this form, the return value is the compressed string representing the geometry. These data have a unique return class, described in the format documentation below.

The normal way to terminate a session with the server is to issue the close command. Unless keepall is in effect, if there are no other open connections the server will be cleared and reinitialized. The clearing and reinitialization is equivalent to giving the reset and clear commands, which can be given at any time from any connection, and affects all connections. 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 will exit if dieonerror was in effect for the affected connection, otherwise the behavior will be the same as for a close operation.

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.

The ReadReply and ConvertReply script functions can be used the to handle server responses when the client is implemented as a script. For other applications, the user will have to write a parser, perhaps using the code from the xclient.cc example. Whiteley Research can provide assistance to users who need to develop this capability.