PCI Architecture Question for Data Acquisition Board

M

mksuth

Guest
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 i
pretty much dead now. All the new FPGA devices, even the cheap ones suppor
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 am, "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 support
PCI Express so you may be better looking at that route.

Jon        

---------------------------------------        
Posted throughhttp://www.FPGARelated.com
 
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.
 
On Nov 30, 9:30 am, 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 am, "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 support
PCI Express so you may be better looking at that route.

Jon        

---------------------------------------        
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
 
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 am, "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
board called raggedstone1 from Enterpoint. It is a PCI card with an FPG
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 wit
OpenCOres PCI Bridge becouse it can Master the Bus so you can send an
receive Bursts of packages. But i am having some problems to understand ho
to make it work. I hope i got some results until the end of the week (as
am working on other problems too). To help take a look at this site
http://sourceforge.net/projects/pcibridgedriver/ A guy developed a drive
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 t
make this work faster. If you are interested my e-mail i
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
 
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).


Nial
I think you intended to say 8MB/s and 60MB/s right?

And Nial, have you ever developed a PCI driver to Linux? I am trying t
work with the example i posted on my last post and LDD third edition, but
still got many doubts...

Thabk you!

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Nov 30, 4:34 pm, 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 am, "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
 
I think you intended to say 8MB/s and 60MB/s right?
Yes sorry, Bytes not bits.

And Nial, have you ever developed a PCI driver to Linux? I am trying to
work with the example i posted on my last post and LDD third edition, but i
still got many doubts...
No, that's always been someone else's problem!

:)


Nial.
 
On 12/1/2010 7:13 AM, Sink0 wrote:
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).


Nial


I think you intended to say 8MB/s and 60MB/s right?

And Nial, have you ever developed a PCI driver to Linux? I am trying to
work with the example i posted on my last post and LDD third edition, but i
still got many doubts...

Thabk you!

---------------------------------------
Posted through http://www.FPGARelated.com
As a note, while I haven't done any Linux driver development our former
programmer did. He said that LDD 3rd ed. is chock full o' both errata
and things that were only true under the 2.4 kernel, not 2.6.

--
Rob Gaddi, Highland Technology
Email address is currently out of order
 
As a note, while I haven't done any Linux driver development our former
programmer did.  He said that LDD 3rd ed. is chock full o' both errata
and things that were only true under the 2.4 kernel, not 2.6.

--
Rob Gaddi, Highland Technology
Email address is currently out of order- Hide quoted text -

- Show quoted text -
Haha thank you for the information. Can you point me any other good
reference? Other than the drivers already placed on the linux?

And as you guys got some experience with PCI can you answer me some
questions that are probablt veeery simple, but i cant understand?

1 - Where exactly is phisicaly placed the configuration space? At host
memory? Or at the car controler?
2 - Why there are more than one BAR? I could not understand how can i
configure BARs?
3 - What is an image address?
4 - What is an mask address?
5 - Why the address need to be decoded?

Now questions related to the Open Cores PCI Bridge

1 - How does the adress that i am sending to the PCI is related to the
wishbone address?
2 - How can i configure that?
3 - How about the oposite? How the address that i use at the wishbone
side is related to the PCI message?

I am reading the PCI documentation but could not understand.

Thank you!
 
Thanks for the additional responses.
I'm experimenting with the Altera PCI core which can be configured to
run as either a master or as a master/target.

As a first step I'll implement the fpga as a PCI target and simply try
to get a linux driver to read single data words from it. From what
you've told me on this thread it seems I may ultimately need to run
the FPGA as a master in order to get the bandwidth I need.
 
On Wed, 1 Dec 2010 13:16:19 -0800 (PST), Sink0 <sink00@gmail.com> wrote:

As a note, while I haven't done any Linux driver development our former
programmer did.  He said that LDD 3rd ed. is chock full o' both errata
and things that were only true under the 2.4 kernel, not 2.6.

--
Rob Gaddi, Highland Technology
Email address is currently out of order- Hide quoted text -

- Show quoted text -

Haha thank you for the information. Can you point me any other good
reference? Other than the drivers already placed on the linux?
You still need LDD, because it has a different perspective. But a better book by
far for 2.6 kernels is "Essential Linux Device Drivers" by Venkateswaran.

- Brian
 
On Wed, 1 Dec 2010 13:16:19 -0800 (PST), Sink0 <sink00@gmail.com> wrote:


As a note, while I haven't done any Linux driver development ou
former
programmer did. �He said that LDD 3rd ed. is chock full o' bot
errata
and things that were only true under the 2.4 kernel, not 2.6.

--
Rob Gaddi, Highland Technology
Email address is currently out of order- Hide quoted text -

- Show quoted text -

Haha thank you for the information. Can you point me any other good
reference? Other than the drivers already placed on the linux?

You still need LDD, because it has a different perspective. But a bette
book by
far for 2.6 kernels is "Essential Linux Device Drivers" by Venkateswaran.

- Brian
Hmm thank you! I just got that on my hands right now i will start readin
it as soon as possible.. end of year is always a hell haha..

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

Welcome to EDABoard.com

Sponsor

Back
Top