High speed USB devices

linnix <me@linnix.info-for.us> writes:
> One thing to consider is that you might have to run the FPGA at 400MHz
> for HS.  Dedicated chips usually have internal PLL to multiple from
> slower external crystal (i.e. 12mHz).

The UTMI interface runs at 60MHz, 8-bit wide. This route would be interesting, as
we're size constrained and the PHY chips seems to be in almost tiny packages.

-- 
Mikko

On Apr 4, 11:23=A0am, Mikko OH2HVJ <oh2...@sral.fi> wrote:
> Dombo <do...@disposable.invalid> writes:
> > Unfortunately I don't know the details (the fine tuning was not done
> > by me). I vaguely remember it had to do something with configuring
> > buffering and endpoints on the FX2 side to squeeze the last bit of
> > performance out of it. I'm sorry I cannot be more specific than that.
>
> Ok, thanks for giving faith anyway!
>
> I remembered that I have USRP software radio that I used for a GPS projec=
t. I googled for
> USRP USB bandwidth and it seems that even 45MBytes/sec is possible!
>

That's the USB bandwidth, but does not mean you can stream at max.
speed without latency and delay.  You must have enough buffers to take
care of milli-seconds gaps.  Otherwise, you will have scrambled
pictures or black spots.

On 4 Apr., 18:34, Mikko OH2HVJ <oh2...@sral.fi> wrote:
> "langw...@fonz.dk" <langw...@fonz.dk> writes:
> > something like this in fifo mode:http://www.ftdichip.com/Products/ICs/FT2232H.htm
> > should do it. Or just a 2.0 phy and an usb 20.0 core, theres one on
> > opencores I think
>
> What kind of performance can be expected from the FT232H ?

ft2232H not ft232H, I've never used it but they claim 40Mbyte/sec in
single channel fifo mode



-Lasse

On 4 Apr., 20:25, Mikko OH2HVJ <oh2...@sral.fi> wrote:
> linnix <m...@linnix.info-for.us> writes:
> > One thing to consider is that you might have to run the FPGA at 400MHz
> > for HS. =A0Dedicated chips usually have internal PLL to multiple from
> > slower external crystal (i.e. 12mHz).
>
> The UTMI interface runs at 60MHz, 8-bit wide. This route would be interes=
ting, as
> we're size constrained and the PHY chips seems to be in almost tiny packa=
ges.
>
> --
> Mikko

yeh, the phy does the serial-parallel, parallel-serial conversion
clock recovery etc.

I'd think integrating the usb into the fpga it is unlikely that there
will be any
bottlenecks on the device side, with an external device you never know
what limitations
there might be

-Lasse

langwadt@fonz.dk <langwadt@fonz.dk> wrote:
> On 4 Apr., 18:34, Mikko OH2HVJ <oh2...@sral.fi> wrote:
> > "langw...@fonz.dk" <langw...@fonz.dk> writes:
> > > something like this in fifo mode:http://www.ftdichip.com/Products/ICs/FT2232H.htm
> > > should do it. Or just a 2.0 phy and an usb 20.0 core, theres one on
> > > opencores I think
> >
> > What kind of performance can be expected from the FT232H ?

> ft2232H not ft232H, I've never used it but they claim 40Mbyte/sec in
> single channel fifo mode

FT232H should be similar to FT2232H in synchronous FIFO mode. However the
FT232H has not been released yet.
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

On 4 Apr., 21:48, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
> langw...@fonz.dk <langw...@fonz.dk> wrote:
> > On 4 Apr., 18:34, Mikko OH2HVJ <oh2...@sral.fi> wrote:
> > > "langw...@fonz.dk" <langw...@fonz.dk> writes:
> > > > something like this in fifo mode:http://www.ftdichip.com/Products/ICs/FT2232H.htm
> > > > should do it. Or just a 2.0 phy and an usb 20.0 core, theres one on
> > > > opencores I think
>
> > > What kind of performance can be expected from the FT232H ?
> > ft2232H not ft232H, I've never used it but they claim 40Mbyte/sec in
> > single channel fifo mode
>
> FT232H should be similar to FT2232H in synchronous FIFO mode. However the
> FT232H has not been released yet.
> --

you are right, I missed the significance of the H and assumed is was
the old
full-speed rs232 device


-Lasse

On 4/4/2011 1:51 PM, linnix wrote:
> On Apr 4, 11:23 am, Mikko OH2HVJ<oh2...@sral.fi>  wrote:
>> Dombo<do...@disposable.invalid>  writes:
>>> Unfortunately I don't know the details (the fine tuning was not done
>>> by me). I vaguely remember it had to do something with configuring
>>> buffering and endpoints on the FX2 side to squeeze the last bit of
>>> performance out of it. I'm sorry I cannot be more specific than that.
>>
>> Ok, thanks for giving faith anyway!
>>
>> I remembered that I have USRP software radio that I used for a GPS project. I googled for
>> USRP USB bandwidth and it seems that even 45MBytes/sec is possible!
>>
>
> That's the USB bandwidth, but does not mean you can stream at max.
> speed without latency and delay.  You must have enough buffers to take
> care of milli-seconds gaps.  Otherwise, you will have scrambled
> pictures or black spots.

In most cases we have seen the bottle-necks on the PC side.  The FX2 
with the default 512 EP FIFO was sufficient to get to ~30MB/sec.  The 
buffering and threading on the PC side has to be handled carefully.  It 
will depend on the drivers you are using on the PC, how often you get 
the data (poll or block), and how many threads.

.chris

On Apr 5, 5:11=A0am, Christopher Felton <noem...@now.com> wrote:
> On 4/4/2011 1:51 PM, linnix wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 4, 11:23 am, Mikko OH2HVJ<oh2...@sral.fi> =A0wrote:
> >> Dombo<do...@disposable.invalid> =A0writes:
> >>> Unfortunately I don't know the details (the fine tuning was not done
> >>> by me). I vaguely remember it had to do something with configuring
> >>> buffering and endpoints on the FX2 side to squeeze the last bit of
> >>> performance out of it. I'm sorry I cannot be more specific than that.
>
> >> Ok, thanks for giving faith anyway!
>
> >> I remembered that I have USRP software radio that I used for a GPS pro=
ject. I googled for
> >> USRP USB bandwidth and it seems that even 45MBytes/sec is possible!
>
> > That's the USB bandwidth, but does not mean you can stream at max.
> > speed without latency and delay. =A0You must have enough buffers to tak=
e
> > care of milli-seconds gaps. =A0Otherwise, you will have scrambled
> > pictures or black spots.
>
> In most cases we have seen the bottle-necks on the PC side. =A0The FX2
> with the default 512 EP FIFO was sufficient to get to ~30MB/sec. =A0The
> buffering and threading on the PC side has to be handled carefully. =A0It
> will depend on the drivers you are using on the PC, how often you get
> the data (poll or block), and how many threads.
>
> .chris

But the image sensor data is very critical in timing,  you have to
clock in 24 bits in parallel and reformat usb serial out.  Buffering
needs to be done at the FPGA side as well.

On Apr 4, 11:51=A0am, linnix <m...@linnix.info-for.us> wrote:
> On Apr 4, 11:23=A0am, Mikko OH2HVJ <oh2...@sral.fi> wrote:
>
>
> > I remembered that I have USRP software radio that I used for a GPS proj=
ect. I googled for
> > USRP USB bandwidth and it seems that even 45MBytes/sec is possible!
>
> That's the USB bandwidth, but does not mean you can stream at max.
> speed without latency and delay. =A0You must have enough buffers to take
> care of milli-seconds gaps. =A0Otherwise, you will have scrambled
> pictures or black spots.

When you add the framing and bit-stuffing, 480Mbps becomes 40MBps.
USB is an "expensive" protocol.  And when using a "consumer grade
graphical OS" streaming for anything other than direct disk reads/
writes is limited to about 1/2 of that.

Ask me how I know some time...

Christopher Felton <noemail@now.com> writes:

> In most cases we have seen the bottle-necks on the PC side.  The FX2
> with the default 512 EP FIFO was sufficient to get to ~30MB/sec.  The
> buffering and threading on the PC side has to be handled carefully.
> It will depend on the drivers you are using on the PC, how often you
> get the data (poll or block), and how many threads.

Fortunately in this application we'll have almost full control of the PC.
The first version will be using the common consumer-grade OS, but later
on there will be a custom Linux box on the other end of the USB.

We'll have a buffer for a few frames, so matching the sensor timing with
USB traffic is 'easy'.

Thanks everyone, this was a very useful thread!

--
Mikko