PCI Architecture Question for Data Acquisition Board

I am building an FPGA data acquisition board which will interface with
the PC over the PCI bus at 33Mhz. The fpga is going to be responsible
for acquiring data from peripheral devices and passing this to the
CPU. The data includes two separate video channels as well as some
sensor readings.

What are the pros and cons of implementing the FPGA as a PCI master
versus as a PCI target?

I will need to use DMA to do the actual transfers. What are the pros
and cons of doing the DMA on the PC side versus on the FPGA side?

Can anyone give me a high level overview of how DMA would work with
PCI as a master versus a target?

Thank you.

Why are you using PCI? Why not PCI Express? I would of thought PCI is
pretty much dead now. All the new FPGA devices, even the cheap ones support
PCI Express so you may be better looking at that route. 

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

The fpga board will mate with a single board PC which only has a PCI
interface (actually it is a PC/104+ stackable interface).

On Nov 30, 9:21=A0am, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> Why are you using PCI? Why not PCI Express? I would of thought PCI is
> pretty much dead now. All the new FPGA devices, even the cheap ones suppo=
rt
> PCI Express so you may be better looking at that route.
>
> Jon =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

On Nov 30, 9:30=A0am, mksuth <mksutherla...@gmail.com> wrote:
> The fpga board will mate with a single board PC which only has a PCI
> interface (actually it is a PC/104+ stackable interface).
>
> On Nov 30, 9:21=A0am, "maxascent"
>
> <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> > Why are you using PCI? Why not PCI Express? I would of thought PCI is
> > pretty much dead now. All the new FPGA devices, even the cheap ones sup=
port
> > PCI Express so you may be better looking at that route.
>
> > Jon =A0 =A0 =A0 =A0
>
> > --------------------------------------- =A0 =A0 =A0 =A0
> > Posted throughhttp://www.FPGARelated.com

Video acquisition devices usually use DMA to store the video in the
host memory.
Reading the video data from the video acquisition board as a PCI slave
is much
slower.  It also uses CPU time as well as the PCI bus bandwith.
Whether or not
you use DMA, you will probably need a RAM attached to the FPGA as a
frame
buffer.  This is due to the nature of PCI in that another bus master
may hog
the bus indefinitely, or long enough to overflow any internal FIFO
buffering
the video data to the DMA.

Regards,
Gabor

> What are the pros and cons of implementing the FPGA as a PCI master
> versus as a PCI target?


The vast majority of (all?) PCI 'hosts' can't burst target reads.

This means if you want to make the most of the PCI bandwidth you'll have
to implement a PCI master core in the FPGA and use this to DMA data
into the host memory.



Nial. 

Thanks for the answers so far.

I do plan on using an an external RAM to buffer the video data.

I'm still confused about doing the DMA in the host PC versus on the
FPGA.

So is it even possible to use the host CPU's dma controller to fetch
one frame at a time using a whole bunch of consecutive PCI reads? Why
would this hold up the cpu and why is this so much slower than doing
it the other way round?


On Nov 30, 11:07=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > What are the pros and cons of implementing the FPGA as a PCI master
> > versus as a PCI target?
>
> The vast majority of (all?) PCI 'hosts' can't burst target reads.
>
> This means if you want to make the most of the PCI bandwidth you'll have
> to implement a PCI master core in the FPGA and use this to DMA data
> into the host memory.
>
> Nial.

mksuth <mksutherland5@gmail.com> wrote:

>I am building an FPGA data acquisition board which will interface with
>the PC over the PCI bus at 33Mhz. The fpga is going to be responsible
>for acquiring data from peripheral devices and passing this to the
>CPU. The data includes two separate video channels as well as some
>sensor readings.
>
>What are the pros and cons of implementing the FPGA as a PCI master
>versus as a PCI target?
>
>I will need to use DMA to do the actual transfers. What are the pros
>and cons of doing the DMA on the PC side versus on the FPGA side?
>
>Can anyone give me a high level overview of how DMA would work with
>PCI as a master versus a target?

With PCI there is no such thing as DMA. What PCI can do is transfer
data between devices. If you want to transfer blocks of data (burst)
then your card must be capable of becoming a master. Most if not all
computers cannot initiate burst transfers.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

>The fpga board will mate with a single board PC which only has a PCI
>interface (actually it is a PC/104+ stackable interface).
>


Hey, i am working on a project similar to yours. I will be using a PC/104+
and a custom doughter card with a FPGA too. For now i am working with a
board called raggedstone1 from Enterpoint. It is a PCI card with an FPGA
but for standard computers. Its works for me becouse i dont got the PC/104+
on my hands right now but the PCI bus is the same. I am trying to work with
OpenCOres PCI Bridge becouse it can Master the Bus so you can send and
receive Bursts of packages. But i am having some problems to understand how
to make it work. I hope i got some results until the end of the week (as i
am working on other problems too). To help take a look at this site:
http://sourceforge.net/projects/pcibridgedriver/ A guy developed a driver
for linux (but it got some porblems i am trying to fix) and a "simple"
guide to make use of the bridge. If you want we can exchange information to
make this work faster. If you are interested my e-mail is
luisf.rossIGNORETHIS@gmail.com. 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

> So is it even possible to use the host CPU's dma controller to fetch
> one frame at a time using a whole bunch of consecutive PCI reads? Why
> would this hold up the cpu and why is this so much slower than doing
> it the other way round?

The minimum number of clock cycles for a PCI read transaction is 5
(from memory). If you can't burst reads (which you can't from a target)
then for every 32 bit word you read it takes 5 (or more) clocks.

With the same overhead a burst transfer can transfer up to 128 (I think)
32 bit words, so it's _much_ more efficient.

I think I managed ~ 8Mb/s using target reads, bursting you can aim for
~60Mb/s (in a system with other things on the PCI bus).

You need to get hold of the PCI spec if you're going to be implementing
an interface.


Nial

On Nov 30, 4:34=A0pm, mksuth <mksutherla...@gmail.com> wrote:
> Thanks for the answers so far.
>
> I do plan on using an an external RAM to buffer the video data.
>
> I'm still confused about doing the DMA in the host PC versus on the
> FPGA.
>
> So is it even possible to use the host CPU's dma controller to fetch
> one frame at a time using a whole bunch of consecutive PCI reads? Why
> would this hold up the cpu and why is this so much slower than doing
> it the other way round?
>
> On Nov 30, 11:07=A0am, "Nial Stewart"
It becomes easier to understand if you think about the case when the
read data is not ready. This causes the device being read to drive
TRDY until its data is ready and then the burst continues. The first
thing that happens is your mouse doesn't work during the transfer
until perhaps the system monitor decides that the bus has locked up
for too long and aborts the PCI transaction. At that point your read
DMA would have to know how far it had got and then try to carry on. I
appreciate that your video frame is ready to go in one hit but many
applications are not. All PCI devices therefore just do not go there
if at all possible. Nial has given you best case bandwidth reasons for
not reading, the worst case is unacceptable sytem wide.
Also it is worth learning about PCI bridges. These devices connect two
or more PCI buses together but transfers only go through them when
they need to. Otherwise transfers on either side can occur
simultaneously. Both sides will grind to a halt during a long read
through the bridge whereas a write just gets posted when the arbiter
lets it.
As an aside this was all sorted with PCIX but I won't go there if you
are not.

Colin