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

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

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.

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.

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?

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.

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

best regards,
Peter

-----Original Message-----
From: Rudolf Usselmann [mailto:rudi@asics.ws]
Sent: Tuesday, January 09, 2001 5:33 PM
To: usb@opencores.org; Peter Teng
Cc: Damjan Lampret
Subject: Re: [usb] USB 2.0 core Spec. First Draft


on 1/10/01 5:00, Peter Teng at peter_teng@el.nec.com wrote:

> Rudolf,
>
> Thanks for the great job that you have put forward.

Thanks :)

> I have a few comments below:
> 1. Why is a link list architecture is picked for endpoint definition? This
> endpoint definition has to be ran in real time negotiating the external
PHY
> for appropriate responses to the incoming traffic. This imposes the finite
> latency from the time a USB transaction is received and the time a proper
> response shall be generated based upon the endpoint targeted. With the
link
> list, the search time varies with endpoint information location within the
> linked list. And further more each search involves read, compare and fetch
> next. This gives undeterministric behavior for endpoint responses.

Well, the reason for the linked list, is that I want to build a very
universal and flexible USB core.
What is the response latency requirement ? (Didn't get to this point yet :)

Here is how long it would take to search the list:
Max entries: 1 Control EP, 15 IN, 15 OUT = 31 entries
2 cycles per entry to search for the entry = 62 cycles
10 nS per Cycle = 610 nS

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 ?

> 2. There are quite a number of empty bit space for link list entry. They
> should be able to fit all in two 32 bit space instead. And in addition, it
> is better to have +2 counter instead of +3 counter for search engine to
> forward to the next entry (in case linked list architecture is used)

No, that is impossible. I agree that a +2 increment is nicer, but it does
not fit.

> 3. What are the conditions for the hardware to assert the HALT interrupt?

As defined by the USB spec., I believe 3 NAK conditions in a row.

> 4. What are the number of transactions per uframe register for?

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.

> 5. What does the share bit in 3.1.2 for?

See the text ! 3.1.2 first paragraph !

> 6. How does the TBD of TBD register in 3.1.2 for interrupt acknowledge
> associated the linked list entry? How does the software above the layer
> understand interrupt is generated by which endpoint?

See 4.6 interrupt source register !

> 7. No register read clearing is preferred. This forces the software to
have
> variable storing the register's content after reading it. This in effect
> forces the software to have layer hierarchy of having lower layer to take
> care of all the register read/write protocol, instead of having different
> driver stacks of equal right to access the registers.

OK, thanks for that input, I'll think about it !

> 8. What is default endpoint?

I don't know yet !
To Be Defined :)

> 9. Interrupt source register only contains the endpoint information which
> requires the software in reading the content in time before next
transaction
> occurs. This imposes a very big challenge for the software developer to
put
> a finite constraint of the software behavior. I would prefer to see a
> register have 32 bit corresponding to each out endpoints and another
> register have 32 bit corresponding to each in endpoints. For assertion of
> each bit, it means the interrupt for each endpoint accordingly.

Hmm, ok I'll think about that !

> 10. Why there are two different interrupt pins? Are they prioritized? If
> so, which interrupt is associated with higher, which is for lower?

The interrupt pins are individually programmable (Section 4.5). It's up to
the user how they are used. One way to use them would be for different
priorities.

> 11. Does the spec impose any buffer alignment requirement? For example, a
> 512 byte buffer shall be located in the 512 byte aligned buffer space? If
> so, fewer counter bits can be used to save gatecount.

Yes, thanks for pointing this out, I will add this to the spec !

>
> best regards,
> Peter

Peter,

thanks a lot for your feedback !

As you can see the spec is still a early Draft ! There are many things
missing, like the entire Control and Configuration section, and many things
are unclear.

Please stay tuned, and give me more feedback ! I'm working on the spec every
day and will upload a new version at least twice a week.

BTW: The latest version is 0.3, I'm wondering, some of your questions above
might come from the 0.2 revision draft. Please take another look !

The latest spec can now be downloaded from the USB web page at opencores.

Thanks a lot !

Best Regards,
rudi