The DATools directory provides a method for design automation tool users to share software; the scheme is similar to that used for general Cedar tools, is separate from general Cedar software. Many of the rules here are derived from the rules used by Cedar developers. Much of what follows is directed to writers of DATools packages, but users should also be aware of the rules in order to have reasonable expectations.

Wherever the ® symbol appears, it stands for the version number of the current Cedar release. Thus if the current release is Cedar 6.0, <DATools®> means <DATools6.0>. All directories mentioned here reside on the [DATools] file server. All the forms cited which are not standard Cedar forms can be found via <DATools®>Top>DAToolsForms.df.

A DATools package is a program used for electronic circuit design which is made available to the community of Cedar users. Some DATools packages are large systems; others are simple, one-module features. DATools contains design tool software which is separated from the general Cedar software to reduce the bulk of general Cedar software, as well as to reduce some constraints to writers of design tools.

DATools packages must be easily distinguishable from Cedar release components. In particular, the name of a DATools package must not match that of a Cedar release component. A DATools package may depend on Cedar release components, CedarChest packages, or on other DATools packages but should not depend on private directories.

A DATools package remains the "property" of the submitter. Others may not make modifications (except for their own private use) without negotiating with the owner (who may already be making similar or incompatible modifications). Of course the ownership may pass back and forth among several people as long as they agree.

DATools packages may have a version number attached to the package name, the subdirectory names or the DF-files, but package version numbers are not required except in the path name for the subdirectories. Different package releases should use different subdirectories, but should use the same module names.

To avoid name conflicts, DATools packages of larger systems may start with some prefix letters. These prefix letters should not be used for other unrelated DATools packages. Prefix letters are documented in <DATools®>Documentation>DAToolsPrefixes.tioga.

The directory and DF-file structure for <DATools®> is similar as that for <CedarChest®>. Each package should be entirely described by a DF-file on <DATools®>Top>. This DF-file should pass VerifyDF with no errors or warnings. Imports should come only from <DATools®>, <Cedar®> or <CedarChest®>. Use <DATools®>Forms>DAToolsDF.form as a sample DF file. Documentation should reside in the same subdirectory as the package, not on a separate subdirectory an with CedarChest.

When you are ready to announce a package, use <DATools®>Forms>DAToolsMsg.form as the standard announcement form. Try not to flood the user community with a constant flow of new versions of interfaces (or messages). If your package is undergoing continual changes, adopt a release strategy of regularly spaced, well tested releases. Your users will thank you.

Consider using the CedarUsers^ or DAToolUsers^ lists to request packages (within reason, of course). It is hoped that this will increase sharing of software. If you're about to implement a new package, why not see if someone else already has one, or is also thinking of implementing nearly the same thing?

Every DATools package should have a documentation file. It need not be large — in some cases a paragraph or a reference to other documentation will do — but it should exist. Package.df should store PackageDoc.tioga on <DATools®>Package>, as DAToolsDF.form suggests.

Use CedarDoc.form as a template. This will make it easier for you to produce the document, and easier for the catalog builder to build the catalog.

Periodically, the administrator of DATools will create a catalog of the current packages. This catalog extracts its information for each package automatically from the DF-file on <DATools®>Top> and the documentation file. A sample catalog entry looks like this:

The DF file entry comes from enumerating <DATools®>Top>*.DF. The Commands are discovered by enumerating the ".Load" files in the DF-file. If the ".Load" files aren't there, then the commands are not included in the catalog — sorry. The Author, Keywords, and Abstract entries come from examining the documentation file mentioned in the DF-file. Certain heuristics are used to discover these entries so please use the CedarDoc.form to create your documentation. Short documentation is acceptable, so create an abstract for the catalog entry even if you have nothing more to document. It is customary in some tools to have documentation regarding several df files in one documentation file; if this happens, make at a documentation file with a reference.

Three distribution lists are available for communications concerning design automation tools. DAToolAdministrators^.PA is used to address those responsible for the overall administration of the DATools directory as well as the design tool effort. DAToolImplementors^.PA addresses those people who are actively working on design tools while DAToolUsers^.PA is a list containing names of people who use the design tools.