XicTools Open-Source  Release
                         July 31, 2017

Whiteley Research is pleased to offer the XicTools programs:  Xic
(graphical editor) and WRspice (circuit simulator) as open-source. 
The two programs have sold commercially for more than 20 years, having
been updated steadily along the way.  However, a lot more development
is required to increase usage, and Stephen Whiteley, the author of most
of this, is ready to try a new approach.

It is expected that these programs will enjoy accelerated development
in an open-source environment, with the contributions of one and all
adding capability.  One day they may become widely used and known for
stability and available on-line support through user and developer
groups.  With this critical mass, the programs may become a viable
choice for foundry users, particularly those who may lack the
resources to pay for the Big Box tools.  This would never be achieved
with a proprietary software model given the limited capabilities of a
tiny company such as Whiteley Research.

The XicTools software is being released under the Apache-2.0 license,
which is actually one of the most "free" licenses available.  One is
not restricted in using this software in a commercial environment, or
in commercial products.  There is no requirement that you must share
your source code if you use this.  The code can be redistributed with
few restrictions.  See the LICENSE-2.0.txt file for the wording of the
license.  Basically, if you are commercial and this software can add
to your bottom line, go for it, and we might even help you!

However, this software, like virtually all software, has a history. 
Much of it originalted from places like the University of California,
Berkeley (e.g., WRspice is a direct descendent of Berleley Spice). 
There are bits and pieces that come from other universities.  The
university licenses are also very unrestrictive and likely highly
compatible with the Apache-2.0 license (remember that your taxes
almost certainly paid for the software developed at the university).

At least one accessory (the help viewer) is tainted by the GNU library
license.  So, at the time of this initial release, there may be some
question as to whether the full terms of the Apache-2.0 license apply
in some cases.  This shall presumably be clarified in the future.  All
old headers have been retained, so users can make their own judgement
about the constraints on a given set of files.  Incorporating a better
HTML viewer, that understands CSS, should be a priority.

Incidently, the GNU licenses are an absolute scourge and should die. 
Gnu-licensed software is anything but free, its use is highly
restricted and is poison in a commercial environment.  Fortunately the
world is moving away from that nonsense, but the damage has been done. 
For years, Gnu-licensed Linux, and open-source in general, was
considered to be something far-out hippy-dippy communist, due to
"copy-lefts" and other peculiarities, by corporate IT departments. 
These people instead bought Microsoft, costing the world billions of
dollars (maybe a trillion?  who knows) as a consequence of poor
security, and need for countermeasures.  Anyway, Bill Gates owes a big
wet kiss to the GNU folks who made open-source toxic for so long.


1. Overview - What's Here

The distribution consists of several semi-independent programs and
libraries, rooted in subdirectories.  These are described below.

KLU
This is simply a wrapper around the SuiteSparse sparse matrix package
written by Timothy A. Davis, available from
http://faculty.cse.tamu.edu/davis/suitesparse.html

The provided makefile operates on the SuiteSparse distribution file,
applying needed patches, compiling and linking.  The reslt is a
run-time loadble module which provides the sparse matrix capability,
for use with WRspice (or any other application with a suitable interface).
WRspice does not require this plug-in, but will employ it when provided.
Use of the SuiteSparse package generally reduces simulation time.

mozy
The mozy package contains the help system and viewer used by Xic and
WRspice, including an http/ftp file transfer utility, and a screen
capture into image file utility.  This code (and only this program
code) is derived from GNU-licensed code.  Commercial users may wish to
build the XicTools without the mozy package, which is a top-level
option.

mrouter
The MRouter is derived from the Qrouter maze router by Tim Edwards,
available at http://www.opencircuitdesign.com.  It may be used as a
stand-alone tool similar to Qrouter, or run-time loaded into Xic as
a plug-in, in which case its functionality is available within Xic.
This integration is at a very early development stage.

secure
This package provides the license server, client-side code, and
license-generating utilities for the licensing system used with the
commercial version of Xic and WRspice.  This, of course, is no longer
used, by simply hacking the main validation entry to always return a
validated status.  This package is retained, for now at least, in the
chance that it may be of value to someone.

vl
This is a Verilog simulator, which is integrated with WRspice but can
be used as a stand-alone non-graphical simulator.

wrspice
The WRspice program is a SPICE-derived circuit simulator.

xic
The Xic program is a graphical editor, used for displaying and editing
layouts and schematics.  It provides DRC, extraction, and a lot of
uther  capability.

xt_base
This contains base libraries and configuration scripts for use with
the other packages.


2.  Dependencies

wrspice
  xt_base
  secure
  KLU
  vl

xic
  xt_base
  secure
  mrouter

mozy
  xt_base

vl
  xt_base


3.  Building the XicTools

3.1.  Prerequisites

CentOS/RedHat Linux is the reference platform.  You should have
success building the tools on a RPM-based Linux, including OpenSuSE
and Fedora.  Other Linux distributions will provide challenges, for
now.

You will need to be familiar with makefiles, compilers, and the tools
needed to build Linux programs.  Unless you are very lucky, something
won't work right, and you'll need to know how to fix it. 
User-friendliness varies from nonexistant to execrable, meaning that
the code itself is the documentation.  This will all change over time,
but for now, this is probably for experts only.

You will need to have the development versions of lots of different
libraries installed, including GTK.  I don't have a list, but as you
encounter missing headers, etc., these should be installed on your
system from your operating system source repositories.  You of course
need the software development tools installed.

3.2.  Procedure

The procedure is as follows.


    1.  Copy Makefile.sample into Makefile, edit Makefile to set the
        configuration flags, as described in the Makefile.
    2.  "make config" will configure the source tree to your build
        environment.
    3.  "make all" will build all of the programs.

The intended installation procedure is to first build a binary package
(RPM) for each program, then install the package on your system using
the wr_install script.  The Makefiles will actually prevent running
"make install" to the default location under /usr/local.  However, you
can modify the Makefiles to allow this, and skip the packaging step
entirely if you wish.

    Packages are built (on a good day) with "make package" from the
    subdirectories which contain a "packages" sub-subdirectory.
    "make packages" from the top level will build all packages.

    Packages are left in xt/xt_base/packages/pkgfiles.

    It is recommended that the wr_install script be used to install the
    packages when possible, as it takes care of some settings.