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

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

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
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.

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?

Thanks again for your responses.

best regards,
Peter

-----Original Message-----
From: Rudolf Usselmann [mailto:rudi@asics.ws]
Sent: Tuesday, January 09, 2001 9:46 PM
To: usb@opencores.org
Cc: pteng@mail.com; peter_teng@el.nec.com; pteng@yahoo.com
Subject: Re: [usb] USB 2.0 core Spec. First Draft



Hi Peter !

on 1/10/01 10:15, Peter Teng at peter_teng@el.nec.com wrote:
> Rudolf,
>
> Responses embedded below:
>
> Rudolf> So I can do the search in about 610 nS, lets double this number,
and
> say I can do it in 1220 nS - will this be OK ?
> Peter: Check page 58 of UTMI spec 1.04, the SIE decision time for 8 bit
> 60MHz mode in HS operation is around 14 clks, which is equivalent to
233ns!
> Never mind the FS mode.
> And again, tiing a flexible timing (CPU running from few MHz to several
> hundered MHz) architecture with another fixed (USB 2.0 480Mbps)
architecture
> is not a good idea. I assume that your SIE should be running at clk output
> from UTMI.

Yes, you are right ! I'm dropping the linked list idea !  It was to good to
be true anyway !!!!

> Rudolf> No, that is impossible. I agree that a +2 increment is nicer, but
it
> does
> not fit.
> Peter: I just notice that in .3 spec you have added few more bits.
>
> Rudolf> As defined by the USB spec., I believe 3 NAK conditions in a row.
> Peter: The host never issue NAK to function. Why would you need that? Is
> this generated from 3 NAKs returned by the function? If that is the case,
> there is no need for the function to generate that since the software may
> keep track of that from NAK interrupt.

Right, I guess I can remove it.
Sorry, I'm very new to USB, still trying to memorize all 550 pages ;*)
Plus UTMI ....

>
> Rudolf> This is per USB spec 2.0, chapter 5.9. Basically this allows you
> to define a high speed high bandwidth endpoint that can operate at 192
Mb/s.
> Peter: My question is how does this register affect the design of this
core.
> I assume that the spec only call out for non-intelligent SIE engine that
> does not do auto control responses. If my assumption is right, what does
> this register offer?

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 !

>
> Rudolf> See the text ! 3.1.2 first paragraph !
> Peter: Sorry that I don't see any description about usage/function of
share
> bit is for.

Here is what the text says. I have to update/clarify it I guess ...

"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."

>
> Thanks for your input in such a short period of time.

No ! Thank you for your feedback !!!

> best regards,
> Peter

Cheers !
rudi