RE: [usb] USB 2.0 core Spec. First Draft

["Peter Teng" <peter_teng@el.nec.com>]

Rudolf,

	I would like to make clear that "number of transaction per uframe" register
is not needed for PID checking. The PID checking or generation are done
differently (see 8.6 of USB 2.0 spec for more detail).
	I don't understand what you meant by "I dropped the S bit as it would
introduce to much of a latency!"

If you don't see my response within 24 business hours to your email, please
email me using pteng@mail.com, pteng@yahoo.com or peter_teng@el.nec.com, or
please call me direct. Sorry in advance for the trouble that may caused you.

best regards,
"Peter" Chu Tin Teng
Computing technology I/O Group
NEC Electronics Inc.
Physical address
3301 Olcott St.,
Santa Clara, CA 95054

Mailing address
Olcott Building
2880 Scott Blvd., M/S: SC2302
P.O. Box 58062
Santa Clara, CA  95052-8062
Tel: (408)9692766
Fax: (408)9692435
Email: peter_teng@el.nec.com/pteng@mail.com


-----Original Message-----
From: owner-usb@opencores.org [mailto:owner-usb@opencores.org]On Behalf
Of Rudolf Usselmann
Sent: Wednesday, January 10, 2001 6:52 PM
To: USB Mailing List
Subject: [usb] USB 2.0 core Spec. First Draft



on 1/11/01 0:48, Peter Teng at peter_teng@el.nec.com wrote:
> Rudolf,
>
> Comments embedded below.
>
> Rudolf> Hmm, I think I need this when I do a control response. Oh, wait, I
> remember,
> I need that to do proper data PID checking and generation, to stay in sync
> with the host !
> Peter: The data PID generation or checking should be done automatically by
> the SIE which maintains the PID synchronization. The number of
transactions

Right, so I will need this information for proper PID checking and
generation.

> per uframe provides information to host's software in managing the
> transaction traffic. The number of transaction per uframe is no different
> from other control responses sent by function to host. Since the control
> endpoint buffer is maintained by the function backend CPU, and there is no
> intelligence SIE that will do auto control response, it should be fair to
> say that CPU has responsibility in returning all control responses
including
> number of transaction per uframe. And if that is the case, there is no
need
> for CPU to handle the number of transaction per uframe differently. If you
> plan to provide auto control response, there are quite a lot others to be
> incorporated. Check standard request chapter in USB spec.

Right, and whatever values it returns to the host in the control structure,
it should also set up in the endpoint registers, so they know what
PID sequencing to expect.

>
> Rudolf> "The buffer pointers point to the input/output data structure in
> memory. If
> the S bit is set, this indicates that the buffer is a shared buffer. In
this
> case a interrupt is generated and the core waits for the controller to
clear
> the TBD bit in the TBD register. Clearing the TBD bit, will cause the USB
> core to perform the transmit/receive operation. A value of all ones
(7FFFh)
> indicates that the buffer has not been allocated. If both buffer are not
> allocated the core will respond with TBD acknowledgments to the USB host."
> Peter: I am sorry. I can not understand the usage of S bit in this
> paragraph. Is this share bit used as "arm" flag (sharing between backend
CPU
> and host) indicating the buffer containing the data from host is emptied
by
> backend CPU (for Out endpoint) and ready for next receive action, or
buffer
> is filled with data from backend CPU (for In endpoint) and it is ready for
> transmit action? Or is this bit used as ping-pong ("shared" by both In and
> Out endpoints) indicating which buffer is armed?

Don't worry, I dropped the S bit as it would introduce to much of a latency!

> Thanks again for your responses.
>
> best regards,
> Peter

Thanks !
rudi