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

[Rudolf Usselmann <rudi@asics.ws>]

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