Comments on SCAM

[JEFFE at fdc.mhs.compuserve.com]

                               - - Mail - - 
         May  2, 1994          4:41pm    
   FROM: Jeff Epstein                    
     TO: SCSI Reflector                  
SUBJECT: Comments on SCAM                
   COPY: Mark Heppenstall                
         Mark Woithe
         Steve Timm - Microsoft

5/2/94

  To: X3T10 Members
From: Jeff Epstein - Future Domain
  RE: Comments on Larry Lamers' and Jim McGrath's comments on SCAM.

1)   Should legacy, level 1, and level 2 host devices be allowed on the same
bus?

Larry - I think that this is highly desireable.
If not, then level 2 host devices will find limited application.
Currently Rev 5 of SCAM prohibits this, but the justification is not clear.

jpm - I agree
Jeff E. - me too, however if Ed G. wants to propose a solution; great.
After all it was his idea to go beyond the one-host scenario.

2)   Is a level 1 device required to recognize dominant master contention?

Larry - This one is debateable, but I believe the answer is no.
Rev 5 of SCAM did not specifically require this.

jpm - I agree - level 1 devices need not know about the level 2 world
Jeff E - I agree, but this assumes that level 2 masters aren't there.

3)   Is a level 2 device required to have a current ID?

Larry - I believe the answer is yes to insure backward compatibility.

jpm - I agree
Jeff E - no comment

4)   Should the soft ID be saved to the saved ID to become the current ID
following the a subsequent reset condition or power-on condition?

Larry - The answer seems to be no - the soft ID is never remembered by a
device following a reset condition or a power-on condition.

jpm - I agree
Jeff E. - I disagree.  We need a "warm boot" capability.  The trouble is
that we never agreed to solve this problem -- and I think it's important
that we solve it.  For example, if power has not been removed from the bus
(ie from the level 1 host and peripherals), then an ordinary "reset" that is
not followed up with a SCAM isolation sequence (by the host) should leave
all devices IDs as they were.  This would be a "warm boot"  However, if
the host starts the SCAM sequence, this would be a "cold boot".
This does not seem like a hard thing to do.  Comments?


5)   Is someone going to propose a mode page to set the current/saved ID?

Larry - Many disk drives already support a vendor unique mode page to set
the SCSI ID.  The new SCSI ID becomes the saved ID following a reset
condition or a power-on condition if the save parameters bit is set.
The current ID is determined by first checking the non-volatile storage.
If a saved ID other than zero exists then the saved ID becomes the current
ID.
If the saved ID is zero then the default ID set by the jumpers/switches
becomes the current ID.

The hard ID is the current ID of the device following a power-on condition.

The soft ID becomes the current ID if a SCAM protocol occurs and assigns a
soft ID to the device.  The soft ID shall not become the saved ID.

jpm - the concept of a savable ID is orthongonal to SCAM - we can discuss it
as a regular SCSI work item.  The key is that any savable ID must work as
the defualt ID works, not the soft ID

Jeff E - I agree, it needs more discussion.
But, I hope Larry isn't motivated by "which device is the boot device"
and trying to break that deadlock in this manner.  SCAM was intended to
make the bus "ID conflict" free.  It does this in a satisfactory manner.
However, I feel that solving the "warm boot" problem would go a long way
to fix many of the type of problem Larry mentions.
I would rather have it work just like the PnP ISA Bus cards, PCMCIA
cards and PCI cards do.  No memory of the past when power goes off.
A new reset can start it all over again from scratch or just put
everyone to rest and continue operations.  The only "memory" of the past
should be held in the platform (aka motherboard bios in PC land).

6)   Can we get rid of the abhorent terminology and used SCSI terminology.

Larry - A SCAM master is really a SCAM initiator.
A SCAM slave is really a SCAM target.

jpm - I agree
Jeff E - who cares?

7)   Are all SCAM host adapters required to put out the bus master
contention code?

Larry - This has been a real debate - the document is ambiguous - or rather
seems to state both sides of the case - that a host adapter at level one
does not need to do bus master contention but that all scam masters should
do it.  There is a potential interoperability problem here.

jpm - no opinion
Jeff E - ditto. Back to the level 1's with level 2's problem scenario.

Thanks,
Jeff Epstein - Future Domain
Internet: jeffe at fdc.mhs.compuserve.com