Example: Preserving Micro-Frame Integrity - Intel IXP45X Developer's Manual

Intel
9.14.4.1

Example: Preserving Micro-Frame Integrity

One of the requirements of a USB host controller is to maintain Frame Integrity. This
means that the HC must preserve the micro-frame boundaries. For example: SOF
packets must be generated on time (within the specified allowable jitter), and High-
speed EOF1,2 thresholds must be enforced. The end of micro-frame timing points EOF1
and EOF2 are clearly defined in the USB Specification Revision 2.0. One implication of
this responsibility is that the HC must ensure that it does not start transactions that will
not be completed before the end of the micro-frame. More precisely, no transactions
should be started by the host controller, which cannot be completed in their entirety
before the EOF1 point. In order to enforce this rule, the host controller must check
each transaction before it starts to ensure that it will complete before the end of the
micro-frame.
So, what exactly needs to be involved in this check? Fundamentally, the transaction
data payload, plus bit stuffing, plus transaction overhead must be taken into
consideration. It is possible to be extremely accurate on how much time the next
transaction will take. Take OUTs for an example. The host controller must fetch all of
the OUT data from memory in order to send it onto the USB bus. A host controller
implementation could pre-fetch all of the OUT data, and pre-compute the actual
number of bits in the token and data packets. In addition, the system knows the depth
of the target endpoint, so it could closely estimate turnaround time for handshake. In
addition, the host controller knows the size of a handshake packet. Pre-computing
effects of bit stuffing and summing up the other overhead numbers could allow the host
controller to know exactly whether there was enough bus time, before EOF1 to
complete the OUT transaction. To accomplish this particular approach takes an
inordinate amount of time and hardware complexity.
The alternative is to make a reasonable guess whether the next transaction can be
started. An example approximation algorithm is described below. This example
algorithm relies on the EHCI policy that periodic transactions are scheduled first in the
micro-frame. It is a reasonable assumption that software will never over-commit the
micro-frame to periodic transactions greater than the specification allowable 80%. In
the available remaining 20% bandwidth, the host controller has some ability (in this
example) to decide whether or not to execute a transaction. The result of this algorithm
is that sometimes, under some circumstances a transaction will not be executed that
could have been executed. However, under all circumstances, a transaction will never
be started unless there is enough time in the frame to complete the transaction.
9.14.4.1.1 Transaction Fit: A Best-Fit Approximation Algorithm
A curve is calculated which represents the latest start time for every packet size, at
which software will schedule the start of a periodic transaction. This curve is the 80%
bandwidth curve. Another curve is calculated which is the absolute, latest permitted
start time for every packet size. This curve represents the absolute latest time, that a
transaction of each packet size can be started and completed, in the micro-frame. A
plot of these two curves is illustrated in
page 421. The plot Y-axis represents the number of byte-times left in a frame.
The space between the 80% and the Last Start plots is bandwidth reclamation area. In
this algorithm the host controller may skip transactions during this time if it is prudent.
The Best-Fit Approximation method plots a function (f(x)) between the 80% and Last
Start curves. The function f(x) adds a constant to every transaction's maximum packet
size and the result compared with the number of bytes left in the frame. The constant
represents an approximation of the effects of bit stuffing and protocol overhead. The
host controller starts transactions whose results land above the function curve. The
host controller will not start transactions whose results land below the function curve.
® ®
Intel IXP45X and Intel IXP46X Product Line of Network Processors
Developer's Manual
420
® ®
IXP45X and Intel IXP46X Product Line of Network Processors—USB 2.0 Host Controller
Figure 56, "Best Fit Approximation" on
August 2006
Order Number: 306262-004US