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