Here are my comments on the following lines from spec(refer S-11.8.4.1,
USB 1.1):-
1. A keep-alive must minimally be derived from each SOF. It is recommended
that a keep-alive be generated on any valid full-speed token.
2. The keep-alive must start by the eighth bit after the PID of the
full-speed token.
Note: I will limit only to referring these statements alone when it
comes to generation of keep-alive signal
Comments
Periodicity of Keep-alive signaling: 2ms < Tka << 3ms if,
the signal is used only to prevent the device from going to suspend state
(cable delays should be considered).
But, we provide for a minimum of 1ms periodicity. The spec says that
we can have Tka < 1 ms. This means that we cant bank on the the signaling
to mark frame boundaries. Note: 'Tka' is used by me and not borrowed from
the USB spec.
Consider the topologies given below which will be referred in the discussion
Arrows show the connectivity of USB components
Topo1:
Port1 (RH) -> LS
Other ports (2,3,4) are Not Connected
Topo2:
Port1 (RH) -> Hub ->LS
Other ports (2,3,4) are Not Connected
Topo3:
Port1 (RH) -> Hub -> LS
Port2 (RH) -> HS
Other ports (3,4) are Not Connected
Discussions
Special case: SOF token
It would be easier to drive low speed EOP on the low speed bus by a
hub every time an SOF token is received by it!
Consider Topo1:
I guess SOF would not be generated by HC in this case. Will not HC
generate keep-alive? The referred section seems to be confusing!
Well, the terminal count on frame counter should initiate the HC to
send a keep-alive to LS.
Consider Topo2:
Here, the SOF to Hub should be good enough for the Hub to send a keep-alive
to LS. In any case, Hub has to wait for atleast the reception of 8 bits
of PID field to decide on the nature (and correctness) of the token PID
before it issues keep-alive to LS
Consider Topo3:
The SOF to Hub should be good enough for the Hub to send a keep-alive
to LS. In any case, Hub has to wait for atleast the reception of 8 bits
of PID field to decide on the nature (and correctness) of the PID (to ensure
its a SOF) before it issues keep-alive to LS.
Also, any SOF token to HS received by Hub can be used to transmit keep-alive
to LS.
General case: Any full speed IN / OUT token
Consider Topo3:
Any high speed token to HS received by Hub can be used to transmit
keep-alive to LS. Hub has to wait for atleast the reception of 8 bits of
PID field to decide on the nature of the PID (to ensure its a token PID)
before it issues keep-alive to LS.
Wonder case: Why not high speed handshake / data packets >From HC to Device!!
I understand that if a hub can issue keep-alive to a LS on any high speed packet received by it (not necessarily token packet), the second point under section 11.8.4.1, USB 1.1 is not required.
So our question should focus on why only a high speed
token
packet should be used by Hub to generate keep-alive to LS?
With Best Regards,
====================================
Srikanth Kashyap S.
====================================
But I don't have to know an answer. I don't feel
frightened by not knowing things, by being lost in the
mysterious universe without having any purpose, which
is the way it really is, as far as I can tell, possibly.
It doesn't frighten me.
-- Richard P. Feynman
====================================
--
To unsubscribe from usb mailing list please visit http://www.opencores.org/mailinglists.shtml