SBP-2: Recording of Cycle Start requirement
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.
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
ArbGap :== caused by the detection of an ArbGap after a packet has been
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
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
roll_flag :== flag that says that the internal cycle offset value has
rolled over to 0.
:== returns 0 (false) if channel_number is not one that is being
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
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
&& (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 =
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:
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
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.
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