From: olson@zuni.esd.sgi.com (Dave Olson)
Subject: Re: WANTED: tips and driver code for 33C93A SCSI chip
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 2 Sep 92 06:44:59 GMT

In <5409@unixhub.SLAC.Stanford.EDU> ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes:

| In article <BtpJ5r.Iqq@world.std.com> sja@world.std.com (Stuart J Adams) 
| writes:
| >We are in the process of writing a SCSI driver for a WD/Am33C93A
| >chip. I am looking for any tips as well as example code if anyone
| >has some. Our host processor is an 68HC11 but we will most likely
| >be using C.
| >
| >Thanks,
| >Stuart Adams
| >sja@world.std.com
| 
| 1. Get the bug sheet from WD. There are about five pages full of bugs,
|    some of which you have to know about. If WD refuses to give it to
|    you, I could send you a copy.
| 2. Try to squeeze any sort of application note or sample code out of
|    WD. I failed at that. Maybe they don't exist. WDs customer support

It exists.  Try the distributors (like Wyle) instead of WD.  WD is
very 'large OEM' oriented at the chip level, and even at the OEM level,
we had troubles finding a good contact.

|    and technical information is atrociously bad. I didn't try to get
|    documentation for the Am part (when having the problems with the 
|    western digital chip, I was not aware that AMD has second-sourced
|    it). Maybe AMD is more helpful than WD. Furthermore, Hewlett-Packard
|    second-sources the 33C93, but when I last checked not the 33C93A.
|    If they do now, their part may also be better behaved (see below).

Interesting; I didn't know that HP was a second source.  AMD second
sources the 93A, but not (at least yet) the 93B.

| 3. Based on rumours, not first-hand experimence: If at all possible, 
|    don't use the WD part. Use the Am instead. The WD supposedly is very 
|    sensitive to glitches on the status lines, and will get confused all

No, it isn't.  We have been using them for over 4 years now (93, 93A,
and 93B) and have never observed a problem like that.  Somebody is
blaming the part for a poor host implementation.

|    the time due to them. The Am part is supposedly much safer to use in
|    that respect. In my case, the part would frequently interrupt select-

The AMD part is from the same masks as the WD parts (or used to be), so
this seems very unlikely, although not impossible.

|    and-transfer commands due to "unexpected phase change", but when 
|    looking at the phase, it was perfectly correct. I felt that changing

This could be a misunderstanding on your part.  An 'unexpected phase change'
is any change that the microcode can't handle by itself, or one for
which there is a reasonable chance that the most might want to do
something about it.  It does not mean a SCSI bus phase change that
violates the SCSI spec.

|    the design to use another SCSI controller would be less pain than 
|    writing the handlers to manually deal with all possible phases.

That may be true, but the WD part is very good at minimizing interrupts
and (to a lesser extent) PIOs per transfer, relative to some other
parts.  It *IS* a complicated chip to program for all the various
cases, and documentation is rather weak.

| 4. In talking to a major WD33C93A user (a company in the rocky mountains
|    which makes helical-scan video tape drives), I found that they are
|    so unhappy with the 33C93A that they will be moving to other chips
|    with the next major revision of their product. So the problems with
|    it are not just my imagination.

It may be that they have concerns about WD's financial viability, or want
to move to a different (host) bus interface as well.  Certainly they
don't use the 93A to its full speed potential.  It is hard to know just
why (we are an OEM of that company as well).  I hadn't heard that they
were concerned about how hard the chip was to program (after all, they
have all the code written now!).  Certainly they had a few other firmware
problems in their product with the 93A (and they were *not* all related
to the 93A, by any means!)

| 5. If at all possible, don't use the 33C93A. Instead I suggest the NCR
|    53C90 (which I think is second-sourced by Motorola). Reason: It works,
|    the 33C93A doesn't. Let me explain that statement. The 33C93A has many
|    quirks and bugs you have to work around. It takes more commands and

Actually, there are few bugs in the 93A current silicon.  The 93 had
many of them, and getting the bug list was extremely difficult.

|    and generates more interrupts for the same task. It is relatively slow. 

If it is so slow, why does SGI consistently have one of the best SCSI
disk throughput rates of the major workstation vendors?  I measure
sustained rates above 4.5 Mbytes/sec on the 93A with no real problem
(on SCSI devices that can sustain that rate).

|    Support for it ranges from "sucks" to non-existing. The NCR 53C90 is 

Now here, you are correct.  The 93A is *not* for the hobbiest, by any
means!  The NCR chips are far better supported, and documented.

|    quite the opposite. It seems to work as advertised (at least as far as 
|    I have used it). It has more complex commands, and generates much fewer
|    interrupts for each SCSI transfer. The DMA is not quite as flexible, but

2-3 interrupts for the WD isn't uncommon (per transfer); a few more if
the drive disconnects during the transfer.  The more complex
command set of the 53C9X (or the 700 series) look to me like they could
actually be harder to support in a number of cases, at least, to get high
i/o rates, but I have to admit it has been years since I looked at it
very closely.  The 700 series also could be a pain if you want to interface
it to anything other than a [34]86 or Motorola CPU bus; I don't remember
about the 53C9X series.
--

     Dave Olson (olson@sgi.com)