SBP-2: Recording of Cycle Start requirement

Stephen Finch/SSI1 Stephen_Finch/SSI1.SSI1 at notes-gw.tus.ssi1.com
Mon Aug 4 10:29:33 PDT 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Stephen Finch/SSI1 <Stephen_Finch/SSI1.SSI1 at notes-gw.tus.ssi1.com>
*
Well, in the last message I tried to outline the problem, i.e., the need to 
generate a psuedo isochronous cycle to meet the requirements of SBP-2.  Now, 
here is an attempt at an algorithm that accomplishes this need.  What we need 
to do now is determine if there are any holes in it.

steve finch

=================================

The following code is written in something resembling C.  It is different than 
C in that each 'if' clause runs concurrently with all other 'if' clauses.  One 
iteration through the code occurs each 'clock' cycle.  All input signals are 
assumed stable at the time of use.


External Input Signals:

Reset          :== true during power up coditions until power is stable.
CycleStarted   :== caused by the successful receipt or transmission of a cycle 
start packet.
ArbGap         :== caused by the detection of an ArbGap after a packet has been 
sent.
FirstQuadlet   :== coincides with the first quadlet of every received packet.  
Only present if
                   packet header is valid.
RcvdData       :== bus containing quadlets of received data.  Bus bit numbers 
are [31:0] with 31
                   being MSB and 0 being LSB <NOTE: this is different than 1394 
number scheme>
CycleOffset    :== the cycle offset value from the cycle timer

NOTE:  Reset, CycleStarted, ArbGap, FirstQuadlet are, by 1394 definition, 
mutually exclusive, i.e., they can not occur in the same clock cycle.


External Output Signals:
IsoCycle       :== isochronous cycle is in progress
SubIsoCycle    :== a substitute isochronous cycle is in progress

Internal signals:
roll_flag      :== flag that says that the internal cycle offset value has 
rolled over to 0.

Internal function:
valid_stream_channel(channel_number)
               :== returns 0 (false) if channel_number is not one that is being 
recorded.
                   Returns 1 (true) if channel_number is being recorded.


==============================================================================================

if (Reset == 1)       // power on reset, do we need to add other resets??
  {
  IsoCycle = 0;
  SubIsoCycle = 0;
  roll_flag = 0;      // local cycle offset roll over flag, set
  }

if (CycleStarted) 
  {
  IsoCycle = 1;
  SubIsoCycle = 0;
  roll_flag = 0;  // CycleOffset is also reset to value in cycle start packet 
(a low value).
  }

if ((ArbGap) && ((IsoCycle == 1) || (SubIsoCycle == 1)) )
  {
  if (IsoCycle == 1)
    roll_flag = 0;
  IsoCycle = 0;
  SubIsoCycle = 0;
  }

if (   (IsoCycle == 0)
    && (SubIsoCycle == 0)     // do substitute cycle generation if not in an 
iso cycle
    && (FirstQuadlet == 1)    // start of new packet
    && (RcvdData[7:4] == 0xA) // tcode == isoc packet
    && (valid_stream_channel(RcvdData[13:8])) // channel is to be recorded
   )
  {
  SubIsoCycle = 1;
  }

if (cycle_offset == 3071) // about to roll over
  {
  roll_flag = 1;
  }

if ((roll_flag == 1)  && (cycle_offset == 3050))
  {
  SubIsoCycle = 1;
  }  



================================================
Original message (which got no comments...)



SBP-2, revision 2e, Section 11.1, includes the following extracted text.  This 
text was introduced in rev 2b.

====================================================
11.1 Cycle marks
:
:

When a target is a listener and detects a missed isochronous cycle, it shall 
synthesize and record a CYCLE MARK packet on the medium. The second_count and 
cycle_count values shall be taken from the target,s free-running cycle timer.
====================================================

I have been trying to figure out an algorithm which can be used to accomplish 
this task, but have not been successful.  I have also been told that other 
groups (e.g., Open HCI) have attempted to accomplish this goal as well and have 
not succeeded.  If we can not create a reliable algorithm, how can we expect to 
have this requirement met?  We need to either:  1)  figure out an algorithm, or 
2) remove this requirement.


This message attempts to outline the constraints of the problem.  I,d like 
feedback if I have misstated any of the facts or if I have missed any important 
issues.  If we have consensus that these are the correct constraints, I hope we 
can come up with an algorithm.


A summary of relevant constraints:

1.  There could be a difference between value in a received cycle start packet 
and the local cycle timer due to:

a.  If the delays in the path from the cycle master to this node are ignored, 
the maximum amount of variance between the cycle timers in the cycle master and 
this node is based on the difference in frequencies of their respective 
reference clocks which is limited to .02% or .0002 (one could be +.01% and the 
other -.01% and both be compliant).  Since the count between cycles is 3072, 
the maximum deviation between the cycle master,s offset count and this node,s 
offset count is .0002 times 3072, or less than 1 count value, but we must allow 
this to be either 0 or 1.  Since the cycle timer is incrementing at NClk rate, 
or 24.576 MHz, this translates into 0 to 4 Base Rate clocks of 98.304 MHz.

b.  The variance in delays in the path from the cycle master to this node is 
limited to 1 clock of variance per intervening node plus one clock variance at 
the local node.  Since a maximum hope count is 16 (per 1394-1995), the maximum 
difference is 16 clocks.

c.  Worst case cable delay could add, at most, one half clock delay per hop, or 
a total of 8 clocks.

The net result is that the maximum difference that could occur is plus or minus 
28 clocks.  These clocks are base rate clocks of 98.294 MHz or 10.174 ns.  
Total uncertainty is .265 usec.


2.  When the cycle master determines that it should send a cycle start packet, 
it must arbitrate for the bus.  The cycle master must wait until the next 
subaction gap occurs before it begins to arbitrate, and then it is guaranteed 
to win the arbitration at that time.  If an other node begins arbitration an 
instant before the cycle master determines it must arbitrate, the cycle master 
is forced to wait until the transmission of the winner is complete, the 
associated ack is complete and a subaction gap elapses.  The receiver of the 
cycle mark must also receive the entire packet before it can be used.

a.  maximum arbitration time of node sending last asynchronous packet = 6.856 
usec (based on gap count of 63).

b.  maximum packet transmit request of 512 bytes at 100 MHz.  Including the 
header, this packet is 536 bytes in length or 4288 bits transmitted at 98.294 
MHz, or a total of 43.624 usec

c.  end of packet time = .260 usec

d.  maximum acknowledgment phase time is 2.887 usec

e.  end of packet time = .260 usec

f.  maximum subaction gap time is 10.550 usec (based on gap count of 63).

g.  maximum arbitration time of cycle master sending arb packet = 6.856 usec 
(based on gap count of 63).

h.  maximum packet transmission for cycle start = 5 quadlets or 160 bits = 
1.719 usec

This adds to a total maximum delay of 73.012 usec.  This is the worst case push 
back of an isochronous cycle.

3.  An isochronous period begins at the transmission or reception of a cycle 
start packet and ends with the detection of a subaction gap.  Isochronous 
packets may be transmitted both inside the isochronous period (isochronous 
channels) and outside the isochronous period (asynchronous streams).  Only 
those transmitted within the isochronous period are of interest to our streams 
and require a cycle mark to be recorded before the isochronous packets that are 
recorded.  Fortunately, the channel number within an isochronous packet sent 
outside an isochronous period will never occur in a packet sent during an 
isochronous period and, because of this fact, such a packets can never be 
confused with a stream data that is being recorded within a stream.

4.  Transmission of isochronous packets can only occur during an isochronous 
period and an isochronous period begins at the transmission or reception of a 
cycle start packet.  If a cycle start packet is not received for a given cycle, 
then no transmission of isochronous packets may occur.

5.  A recorded stream must record a cycle mark every time a cycle mark is 
received and whenever a missed cycle mark is detected, a cycle mark must be 
created by the receiver.  (This is the SBP-2 concern that this message is 
attempting to address.)



Observation-1:  Reception of isochronous packets could be based solely on the 
channel number within the isochronous packet, without regard to whether or not 
we in an isochronous period if cycle marks weren,t recorded in the file.  

Observation-2:  The detection of an isochronous packet with a channel number we 
are recording outside of an isochronous period might be sufficient to determine 
that an cycle start packet was missed, either not transmitted or corrupted 
during transmission and discarded (i.e., a CRC error).  

Observation-3:  If the cycle start packet is bad when our node sees it, it 
might have been bad when all other nodes see it and the result might have been 
that no isochronous packets were transmitted during the missed cycle.  For this 
reason, relying on Observation-2 has a major pit fall.


The cases that must be considered:
  <Normal operations>
1.  Cycle start could be received before the local counter has rolled over.
2.  Cycle start could be received slightly after the local counter has rolled 
over.
3.  Cycle start could be very late due to traffic on bus. (some packet, cycle 
start, isoc period)
4.  Cycle start could be late due to an extended isochronous cycle on bus which 
could include multiple isochronous packets after the local counter has rolled 
over.  (isoc period, cycle start, isoc period)
5.  Receipt of isochronous packet outside of an isochronous period is valid. 
(Asynchronous streams.)
  <Abnormal operations>
6.  Cycle start was to be received before the local counter has rolled over, 
but was lost.
7.  Cycle start was to be received slightly after the local counter has rolled 
over, but was lost.
8.  Cycle start was to be very late due to traffic on bus, but was lost. (some 
packet, cycle start, isoc period)
9.  Cycle start was to be late due to an extended isochronous cycle on bus 
which could include multiple isochronous packets after the local counter has 
rolled over, but was lost.  (isoc period, cycle start, isoc period)

=======================================

Once the above has been absorbed, we,ll try to come up with an algorithm....
 

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list