n2kbod4 - need to know Body, chapter 4

last updated 15 oct 97 - mjh

4) computer aided engineering

This group has a long history of engineering projects (see (2.3) a rough history of time (experiments) for details), the majority of which were designed using paper and pencil. Today, all of our electronic design work is performed using computer aided engineering tools, either for the sake of their abilities, or because none of the "young kids" know what sepia is...

4.1) tools

Our primary toolset is directed at board-level schematic capture, (digital) simulation, and printed circuit board design. These tools are from VeriBest, a descendent from Daisy Systems. We bought into Daisy Systems in 1984, and have remained a "true believer" ever since. Our legacy of design information has been maintained, following through a succession of vendor changes (see (2.2.1) online documentation for more). Most of our design work, and all of our legacy designs, are on the Sun workstations, under Unix.

However, all of our new design work, and our future, lies on the NT platform. We have (or shortly will have) all of our Sun-based capabilities on the NT boxes, both from VeriBest and from a small collection of related third-party tools.

4.1.1) what we have, where

The following list outlines our VeriBest-based software collection on the NT platform:

All of these tools are located in I:\apps\veribest. You are welcome to browse around, but there should be nothing *in* I:\apps\veribest that you will actively need to find, for the following reasons:

  1. all of the tools and documents have been "installed" and are accessible from the NT Start menu, and
  2. everything "local" to us is *not* in I:\apps\veribest, but in I:\apps\UofI instead!

This is an important path, I:\apps\UofI. It is a "parallel structure" to the veribest tree, as well as to trees from our other software vendors. Anything that needs to be "changed" in the vendor-supplied software (control files, etc.) is in fact changed *only* in I:\apps\UofI. We then connect *our* versions to supersede over theirs. If you are working on schematic entry (VBDC), take a look inside your [project].prj file. Go ahead, it is just ASCII (*don't* change it, though!). You will find many entries labeled

   ${VBEST14PATH}\config\... 
These are control files as distributed by VeriBest. But if you happen to see a
   ${UofI14PATH}\config\... 
entry, it is one of ours. This is how we work. By creating parallel structures, and "layering" ours on top of theirs, we derive two very real benefits. First, we can see *exactly* what we have tailored; it is equal to the contents of our ${UofI14PATH} tree. This really helps when the question arises "did we do that?"

Second, and this has really paid off a number of times, is that software installation of a large number of complex interrelated packages can result in mutual corruption. It is less common today, but for years the standard debug procedure from the VeriBest (Intergraph, really) hotline was "re-install all of your software." If our adjustments actually resided in the same locations as the installed software, they would be long gone by now, considering the number of time we have re-re-re-re-re-re-loaded some of the packages.

We also have a few key pieces of 3rd party software:

Altera and Xilinx are FPGA design packages. The Altera software is quite at home on the NT platform, and we have been getting a *lot* of productivity out of it. We are still fighting with the Xilinx software to get what we need on the NT box. If you are designing with Xilinx FPGAs, talk to Mike Haney about setting up a makefile to do batch processing on one of the Suns. As with VeriBest, the Altera tools are physically located in I:\apps\max80\maxplus2. Our parallel is I:\apps\UofI\maxplus2. The Xilinx stuff is in I:\apps\Xilinx, but let's not go there.

This Imagecraft C cross-compiler for the HC11 is located in:

   I:\Apps\UofI\ICC11
There is a "compile.bat" script in that folder. Copy this to your area, and edit it to define your environment and the files that you want to compile. The comments in the "compile.bat" file should help. Also read the discussion on (7.4) programming (for) microcontrollers for additional insight.

Above and beyond these, we have a motley mix of homegrown or adopted (freeware) tools. The pointy-clicky stuff is in I:\apps\UofI\tools\tcl, and includes:

These are all FPGA-related tools. We also have a number of command-line executables, suitable for incorporating in scripts, located in I:\apps\UofI\tools\bin, which include:

You may note a number of references to Unix. We have a great deal of strength in using Unix utilities to fill in the blanks between CAE tools. The NT platform does not natively posses the building-block capabilities that are found on every Unix box. And while we have found a few Unesque pieces (ls, tar, cat), which we have installed on every box, we are still searching for effective ways to get things done.

So *where* is everything, really? The "I:" drive has been (or should have been) mapped to a shared disk on our NTServer machine: \\NTServer\EnginApps. As a result, everything should be accessible to everyone in the group, but licensing is unique to the machine. Your home directory is on the NTServer (\\NTServer\[your_group]\[you]). All of our active designs are on the NTServer (\\NTServer\EnginDesigns). But none of this should be visible to you. The applications are on your "I:" drive; your home is the "H:" drive; our designs are on your "J:" drive.

What if the server goes down? We have a *very* strong support environment to keep that from happening. But the honest truth is, if the server goes down, you need to find something else to do for a day.

Would you be better off making local copies of stuff to your hard drive? Not really. A big part of the reason *why* our server is so well supported is because our individual machines are *not* supported! Not as individuals, that is. The standing rule is that if something goes wrong with an individual machine, we just scrub the disk and reload the defaults. Or just replace it. Our individual machines have only a limited amount of individuality, and all of the important machine-specific tailoring are recorded in central locations. If you want to use your local hard drive as a scratch work-area, that is fine. But keep in mind that it will not be backed-up, and quite frankly you should *not* back it up either. The server is backed-up, continually through-out the day. That is where the real information belongs.

There is one other side effect of this server-centric view. All of our CAE applications reside on a disk maintained by the server, but each individual machine "sees" that software as if it were installed locally. This requires rather careful maintenance of the Start - Programs menu, the registry, and user environment variables. Each of the CAE vendors expect each user (multiplied times each machine) to execute "setup.exe" to "adjust" their environment. We do that once, in one place, then reconstruct an operational context that everyone can share. This means that each person as a person can be "adjusted" once, and each machine as a machine can be "adjusted" once (if at all) in order to install new software. *DO NOT* install software yourself, unless i) it is yours personally, and ii) it is going on your local hard drive. You are welcome to do this, but remember that it is and always will be your problem to maintain. If anything goes wrong, the first thing that our support people are going to do is scrub the hard drive! Oh, was that your personal software? Too bad.

4.1.2) access to the software

Everything that you need should be under the NT Start Menu, under Programs - CAE Tools or CAE Documentation. Both of these entries are in the lower-half of the Programs Menu, since they are common to all users on the relevant machines.

Most of the software is licensed, and node locked to the specific machines, so if you sit down at a machine that does not have either CAE Tools or CAE Documentation visible on the Start - Programs menu, then you will not be able to run the VeriBest software from that box, regardless of any shortcuts that you may have created for yourself. Please keep this in mind when creating your own shortcuts. The items in the Start - Programs - CAE Tools menu are centrally maintained. Your shortcuts are your problem when they break.

4.1.3) documentation

Everything that you need should be under the NT Start Menu, under Programs - CAE Documentation. This entry is in the lower-half of the Programs Menu, since it is common to all users on the relevant machines.

We have tried to organize the various document from various sources and vendors into a reasonable format. Please let Mike Haney know if there are better ways to do this. Also let him know if there are other documents that you have/need.

4.1.4) support

The primary support for the CAE tools is Mike Haney (m-haney@uiuc.edu; 4-6425; 457 Loomis Lab; try not to call him at home, but he is listed in the phone book; he is pager intolerant).

We pay maintenance fees for all of our big-ticket CAE tools, and as a result we have access to technical support from the vendors. However, most of the contracts require "single-point contact" to filter out the noise. It is *very* costly for a company to train people over the phone. Therefore, if something does not work, talk to Mike, and he will decide if it makes sense to talk to the company.

One thing that ***really*** helps both Mike and the CAE companies is if you can divide and conquer, yourself. Something does not work. Make a copy. If the copy does not work, cut off half. If the half (still) does not work, cut again. Continue the process until the issue is confined on one schematic page, or one file, or one small folder. Make it is small as you can, while still preserving the issue. Sometimes the solution will reveal itself, as you cut away the inoffensive clutter. Or you may distill the problem down to the point that it is so glaringly obvious as a CAE vendor bug that you can take personal joy in their humiliation. Regardless. The stock process for involving the CAE vendor, beyond the "I have a problem" phone call, is to ftp/email/FedEx the "environment" to them to reproduce. If it is 100Mbytes, it will take everyone a fair amount of time and effort to move it around and understand the issue. If it is one tiny schematic, you might get an answer the same day.

4.2) process flows