The following !set variables affect the interface to the WRspice simulator, and SPICE output in general.
prefix1=newprefix1 prefix2=newprefix2 ...This will cause lines beginning with prefix to have prefix replaced with newprefix. If the ``=newprefix'' is omitted, that line will not be printed. For example, to map all devices that begin with `B' to `J', and to suppress all `G' devices, the full command is
!set SpiceAlias B=J G.Note that there can be no space around the `='. After this command is given, the indicated mappings will be performed as SPICE text is produced.
The variable is set automatically from the !ssh command, or can be set by hand.
When using a remote host, this specifies the X display string to use, which is needed for running graphics. If not set, a display name will be created as follows: If the local DISPLAY variable is something like ``:0.0'', the remote display name will be ``localhostname:0.0''. If the local DISPLAY variable is already in the form ``localhostname:0.0'', this is passed verbatim.
One can use ssh transport for the X connection on the remote system as follows. Use ``ssh -X'' to open a shell on the remote machine. Type ``echo $DISPLAY'' into this window, it will print something like ``localhost:10.0''. Use this value for SpiceHostDisplay. The !ssh command will set the variable automatically. The shell must remain open while running WRspice, exiting the shell will close the X connection.
This will work under Windows, if Cygwin is installed, along with the OpenSSH package (for the ssh command) and the Cygwin X server. One weirdness: use ``ssh -Y'' instead of ``ssh -X''. The -Y option, which applies to recent ssh versions, is similar to -X, but overcomes stronger security checks included in recent ssh implementations. This seems to be necessary when using the Cygwin X server.
Background
In legacy X-window systems, the display name would typically be in the form hostname:0.0, where the hostname could be (and usually is) missing. A remote system will draw to the local display if the local hostname was used in the display name, and the local X server permissions were set (with xauth/xhost) to allow access. Typically, the user would log in to a remote system with telnet or ssh, set the DISPLAY variable, perhaps give ``xhost +'' on the local machine, then run X programs.
This method has been largely superseded by use of ``X forwarding'' in ssh. This is often automatic, or may require the `-X' or `-Y'option in the ssh command line. In this case, after using ssh to log in to the remote machine, the DISPLAY variable is automatically set to display on the local machine. X applications ``just work'', with no need to fool with the DISPLAY variable, or permissions.
The present Xic remote access code does not know about the ssh protocol, so we have to fake it in some cases. In most cases the older method will still work.
The ssh protocol works by setting up a dummy display, with a name something like ``localhost:10.0'', which in actuality connects back to the local display. Depending on how many ssh connections are currently in force, the ``10'' could be ``11'', ``12'', etc.
In the present case, if we want to use ssh for X transmission, the display name must match an existing ssh display name on the remote system that maps back to the local display.
If there is an existing ssh connection to the remote machine, the associated DISPLAY can be used. If there is no existing ssh connection, one can be established, and that used. E.g., from the ssh window, type ``echo $DISPLAY'' and use the value printed.
The display name provided by the SpiceHostDisplay variable will override the assumed display name created internally with the local host name.
When running WRspice from Xic, there should not be compatibility issues, as Xic will automatically recognize the capabilities of the connected WRspice and compensate accordingly - as long as the hypertext facility is used to define node, branch, and device names. This is true when point-and-click is used to generate names. However, subcircuit reference names that for some reason are entered by hand may need to be updated, or a .options line added as a spicetext label, or the SpiceSubcCatchar, SpiceSubcCatmode variables may be set to enforce backward compatibility.
In releases 3.0.8 and later, this variable will also control toolbar visibility if the wrspiced daemon is used. However, this requires wrspiced distributed with wrspice-3.0.7 or later. If this variable is set with an earlier wrspiced release, the WRspice connection will not work!