On Apr 13, 11:08=A0am, Mikko OH2HVJ <oh2...@sral.fi> wrote:
> Ulf Samuelsson <u...@a-t-m-e-l.com> writes:
> > If you are going to connect it to an embedded Linux,
> > why not put the FPGA inside the Linux box, and run a faster interface?
>
> The camera has to be small&light with about 1.5m very flexible cable. And
> we'd like to start the project using a PC and later move to the custom Li=
nux box.
>
> > What is the Linux box (or PC) going to do?
>
> Video compression, simple UI and networking. The first one requiring some=
 DSP power or
> a codec core.

I assume you want more than 640x480, than you might need more than
480M to move the raw data.  You might need multiple USB or PCIx.

Ulf Samuelsson <ulf@a-t-m-e-l.com> writes:
> If you are going to connect it to an embedded Linux,
> why not put the FPGA inside the Linux box, and run a faster interface?

The camera has to be small&light with about 1.5m very flexible cable. And 
we'd like to start the project using a PC and later move to the custom Linux box.

> What is the Linux box (or PC) going to do?

Video compression, simple UI and networking. The first one requiring some DSP power or
a codec core. 

-- 
Mikko

On Apr 12, 3:19=A0pm, Ulf Samuelsson <u...@a-t-m-e-l.com> wrote:
> Mikko OH2HVJ skrev 2011-04-03 20:26:
>
> > Hi,
>
> > I'm building a custom USB-camera. There will be an FPGA chip doing some=
 simple
> > data handling for the sensor data and after that the image needs to be
> > transmitted to a PC or an embedded Linux computer.
>
> > Estimated raw data rate is almost 30 megabytes per second without any
> > compression. Basically a single endpoint is enough for the task.
>
> > What are the available chips in addition to Cypress FX2, NXP ISP1581 ?
>
> > And how much compression will I be needing, i.e. what is the best perfo=
rmance
> > available ?
>
> If you are going to connect it to an embedded Linux,
> why not put the FPGA inside the Linux box, and run a faster interface?

Actually, he would need both.  Parallel to Serial on the device side
and Serial to Parallel on the Linux side.

> What is the Linux box (or PC) going to do?

Compression?

Mikko OH2HVJ skrev 2011-04-03 20:26:
> Hi,
>
> I'm building a custom USB-camera. There will be an FPGA chip doing some simple
> data handling for the sensor data and after that the image needs to be
> transmitted to a PC or an embedded Linux computer.
>
> Estimated raw data rate is almost 30 megabytes per second without any
> compression. Basically a single endpoint is enough for the task.
>
> What are the available chips in addition to Cypress FX2, NXP ISP1581 ?
>
> And how much compression will I be needing, i.e. what is the best performance
> available ?
>

If you are going to connect it to an embedded Linux,
why not put the FPGA inside the Linux box, and run a faster interface?

The AT91SAM9M10 has a a dual bus structure, so you
can put the FPGA on the secondary bus, and DDR2 on the primary
bus and move data using high speed DMA.
DDR2 supports 533 MB/s peak so you will be using < 10 % of the bandwidth.

What is the Linux box (or PC) going to do?


Best Regards
Ulf Samuelsson

On 04/05/2011 08:44 PM, Mikko OH2HVJ wrote:
> 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'.

In my experience, with a FPGA + USB 2.0 PHY and Linux host with a decent 
driver it is possible to get almost theoretical throughput (minus normal 
protocol overhead).

In my case, saving the data to a hard drive was the bottleneck, but that 
was a few years ago when drives were a lot slower.

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

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

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