RE: [usb] Endpoint Numbers

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

Rudolf,

Rudolf> The endpoint field in the CSR, is the actual endpoint number that is
matched
against the endpoint number in a token from the host. Basically this would
provide a mechanism for changing the endpoint number if desired. I'm not
sure if that is necessary or useful.
Peter: Take your spec rev .4 as example, address 14 hex is pointing to the
CSR of endpoint 1. This endpoint 1 (derived from the addressing) is used to
compare the endpoint number from the token sent from host, right? Otherwise,
why do you need to have another field for storing the endpoint number?
And I have misleading discussion before. There could be an endpoint that can
be served as both In and Out. This means a total 31 logical endpoints can be
implemented. For example, endpoint 1 can be used for both in and out. But
they are logically separated. This means you need to have two separate
entries for describing them. In this case, you need to have 31 entries of
endpoint registers to describe them all.

Rudolf> I have now also added 4 buffer pointers and also size registers for
each
buffer, so I know how much data to transmit or I will set the size to
indicate how much data I have received.
Peter: Instead having more than one buffer pointers, would it be ok to set
the restriction that the single buffer pointer points to the beginning of
the buffer. While there is another field describing the number of buffer
allocated. The buffer allocated shall provide the total contiguous space for
all the number of buffer required. This saves some gates.

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: Rudolf Usselmann [mailto:rudi@asics.ws]
Sent: Wednesday, January 10, 2001 9:16 PM
To: usb@opencores.org; Peter Teng
Subject: Re: [usb] Endpoint Numbers


on 1/11/01 10:16, Peter Teng at peter_teng@el.nec.com wrote:
> Rudolf,
>
> Rudolf> OK, so you are saying that a given endpoint can only be on of the
> three (control, IN or OUT) ? I must have misunderstood the spec !
> Peter: Whatever you are doing now in bit 24-27 of endpoint CSR 4.4.1 of
spec
> 0.4 is fine.
>
> Rudolf> So do you think I should make the actual endpoint ID (4 bit field)
> programmable ? At synthesis time somebody may instantiated 4 endpoints,
> but he want's them to be endpoint 0,1,5 and 6. Making it programmable the
> function software may choose the final endpoint numbers. If not they
> would be fixed 0,1,2,3 for the above example.
> Peter: There is no need for endpoint number field for endpoint CSR.
Whatever
> endpoint not implemented can be read as all zero in endpoint CSR. They can
> either be synthesis out by script during compile time, or programmed
during
> run time. In anyway, the register addressing depicts the endpoint number.

I think you misunderstood me. Let me try to explain this again:

The endpoint field in the CSR, is the actual endpoint number that is matched
against the endpoint number in a token from the host. Basically this would
provide a mechanism for changing the endpoint number if desired. I'm not
sure if that is necessary or useful.

Regarding the "S" bit: I have removed it completely. The functionality I was
proposing, would increase the latency of the core when responding with data
or receiving data. It would basically bring it to a crawl when a slow CPU is
used ...

I have now also added 4 buffer pointers and also size registers for each
buffer, so I know how much data to transmit or I will set the size to
indicate how much data I have received.

Do you have any other suggestions as to how I can enhance the core/make it
more useful ?

Thanks !
rudi

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