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

[Rudolf Usselmann <rudi@asics.ws>]

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