
Magic Binary Distribution
-------------------------

This is an updated version of the binaries to the magic program, i've included below the original readme that came with the older binary set :)

If you have problems related to this binary, sent me an email and i'll try and sort them out for you.

Have Fun

Karl Maftoum

k.maftoum@student.canberra.edu.au


-------------------------------------------------------------------------

Magic 6.4.4 binaries for Linux, in case you're having trouble
compiling the source, or would rather not have to mess with it.


Quick Installation Steps:

  tar -xvfz magic-6.4.4-bin.tgz    You already did this, right?
  cd magic-6.4.4-linuxELF-bin              If you haven't already...
  setenv CAD_HOME `pwd`           Different if you use bash, CAD_HOME
                                    must be set to this directory.
                                    You'll probably want to add something
                                    to your .cshrc or .profile to set this.
  cp dot.magic ~/.magic           This is optional.
  lpr dot.magic.cheat-sheet       Also optional, but if you're new to
                                    magic, this could be useful.

  Note: You'll also need to add the $CAD_HOME/bin directory to your
  shell's search path, or maybe make some links from a place in the
  search path to the files in $CAD_HOME/bin, or maybe even put them
  in some place like /usr/local/bin.  It's up to you.

Running Magic:

  Assuming that your shell can find the binary, just type
  "magic", and it should run.  If magic complains about not
  finding things, then you probably didn't set CAD_HOME or
  create the "cad" user.

  Magic will run without X, in "null graphics mode", but
  this is basically only useful for non-interactive use.
  If you are indeed running X, but it comes up in null
  graphics, well, it's confused, so type "magic -dx11"
  to give it a hint.

  The keyboard macros for magic are stored in
  $CAD_HOME/lib/magic/sys/.magic for all users, and you
  can create a .magic file in your home directory to
  override the defaults.  I supplied an example and a
  small "cheat-sheet" for it.

  In $CAD_HOME/doc is a set of tutorials written for magic
  which explain it very clearly.  They will consume lots
  of paper if you print them, by the way.


The "cad" User:

  Old versions of magic required a user named "cad" be
  created with the "cad" user's home directory at the
  location where you untar'd cad.tar.  You either need
  to create the "cad" user, or set CAD_HOME, so magic
  will know where to find files.  My system has a "cad"
  user.  If you run into trouble, it might be worth a try.



Libraries:

  Magic looks in $CAD_HOME/lib/magic/tech_name, where "tech_name"
  is the name of the technology you're using.  If you put .mag
  files in this directory (hopefully only ones with the same
  technology), they'll be available as standard cells for all
  users.  I provides a few I've made, which aren't particularily
  useful, but seem to get used quite often anyways.

  To use them from within magic, type ":dump cell" or ":getcell cell"
  where "cell" is the name, without the .mag on it.  ":dump"
  will add it directly to the cell you're editing, ":getcell"
  will add it as a subcell.  (You've read tutorial #4, right?)


Minor Changes In The Source For This Binary:


  I made two small changes in the source, which I'll mention here,
  in case anyone is interested.  In signals/signals.c, line 462,
  I just commented this one out, since gcc complained about
  duplicate case values.  All it does here is decide what short
  little message to print before aborting the program, apparantly
  due to receiving a signal.  The other change is in graphics/grX11su1.c,
  line 211, where I changed  "XSetLineAttributes(grXdpy, grGCDraw, 1,"
  back into "XSetLineAttributes(grXdpy, grGCDraw, 0,", as it is defined
  for other operating systems, and as it is in the source for 
  version 6.3pl3 (which has never had a problem on my machine).  The
  comment on line 210 claims this works around some bug in the
  XFree86-2.x server (which never showed up in my usage of magic
  6.3pl3 under XFree86-2.0, 2.1, or 2.1.1).  While the code will
  compile either way, having that '0' turned into a '1' causes a
  massive decrease in drawing speed on my machine, which is 
  particularily noticable when the grid is drawn.  Since I never
  encountered the bug in XFree86 2.x with it this way, and this
  binary is linked against the XFree86-3.1 libs anyways, I think the
  risk is worth the massive increase in interactive speed.
   
  I've also implemented a change that exits gracefully on >256 color screens.



For God's Sake, CHECK YOUR CIF FILE!!

  By the time you're ready to fab, you've probably put
  many all-nighter's in or otherwise spent far too much
  time and effort on it, so CHECK THE FILE that magic
  produces.  One small error and your silicon (or GaAs,
  I suppose) will be worthless, and you won't even know
  until it finally arrives and doesn't work.  All the
  design-for-test and spice simulation in the world isn't
  going to help you if layer names are wrong or the
  scaling is not right.  I've seen a few people's
  projects ruined because of simple problems that could
  have been avoided, from magic and other cad software.

  (even this binary of magic could have problems)

  My first chip was transmitted to Mosis by a student
  who was supposed to handle all the mosis communication
  for the university.  He sent a CIF file two weeks
  before the project was finished, to reserve space on
  that fab run.  The final two weeks were spent checking
  the layout (using Mentor Graphics, yuk!) and I found
  one wiring error, which I fixed.  He sent the 'update'
  to Mosis when I was done.  When I got the chips into
  the lab, two months later (and he had graduated), they
  didn't work.  A ring oscillator, which had been 
  simulated-to-death didn't oscillate.  The 4th order
  digital filter was creating all of its timing signals,
  but the data was bogus.  I couldn't explain it.  When
  I finally put it under a microscope, it was able to find
  the exact wiring error I had fixed, and the oscillator
  (which was thrown into a bit of extra space in the last
  couple days) was not on the chip, but a wire I had routed
  early-on for its output to the pad frame was there,
  just dangling into the empty space.  It was obvious
  after looking through his mail that there had been an
  error in the second CIF file, and Mosis has sent an
  e-mail acknowleging the transmission and reporting the
  error.  He didn't read most of the message, and I had
  to wait for three months for the next attempt.  I used
  magic to produce the next CIF file and I sent it to
  Mosis myself, and finally it did work. :)

  If you're a student "just learning" and you don't intend
  to fab a chip, then this isn't a concern, but if you've
  put in the effort to lead to a piece of real silicon, even
  a simple circuit, it just doesn't make sense not to
  be very careful, check the CIF file however you can, and
  veryify every step of the transmission of the layout to the
  foundry.  I hope your design works when you get your chips.
  

  Good Luck.

