I have a virtex II pro fpga pci board. I have to transfer data from fpga to the host computer over the pci bus.How should I go about it? I have a external pci bridge on the card between fpga and the pci.Now the vendor doesnt provide any details. I have a program given by vendor which can read data from memory on the board but the intitiation has to be from host i.e by running the program. I have to figure out how can I send data to host from fpga and how do I confirm that the host has captured the right data. Should I start with tweaking pci drivers or is there any other way ?
The group may give more information if tell us what your development board is. Assuming that your development boards supports Initiator functions then you should be able to implement a DMA function across the PCI bus to your destination. You will need information from the O/S or drivers in the system such that you know where to write to as PCI based memory spaces are allocated normally at boot and hence not necessarily a fixed value.
John Adair Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan3 PCI Development Board.
ITs an AMIRIX AP1070 board . It has a pci bridge external to fpga which acts as an interface between (10/100mbps etherenet, pmc module , 64 bit pci) and the fpga. . I can send data to the pci bridge . i got to find out how to address this data to the host through the 64 it pci. I can send data to the etherenet over the pci brdge..I dont know whther the pci bridge will generate the control signals needed for data transfer to the host since this is not in my control.I can just send data to the bridge . I am also not sure how to confirm that the data has indeed reached the host. Nitesh
Nitesh, I took a quick look on amirix site : interesting board... The board guide (developboard.pdf) claims that theboard is provided with all necessary stuffs in particular the "apcontrol-windows" (board windows driver + test app) If PCI transfers are single Read/Write initiated from the host, some signals will be updated and your FPGA design should exploit them : to simplify : transfer flag , transfer direction, transfer adress When host reads data, you must provide them in the appropriate register(s)
For other PCI transfers - burst / bust mastering , it is a bit more complicated ....
The main thing for you is to look at the PCI controller of your board (documentation , programmation method)
yes the main problem was the apcontrol program ( I am using linux based ) can read data from memory onboard. But I want to do burst transfers to host from module in fpga and I need to capture this data on host side. I am integrating PLB master module to transfer data to the pci and then will look into the host side communication. My doubt initially was how does the tranfer between the pci bridge and host pci take place. Should I intiate some control signals. However there are no extra control signals ... i.e I can send a ping to etherenet over the pci bridge with no additional signals just address and data .Hopefully it will be same in the pci case. Any other advise for what I should be looking into....
Nitesh, This is the PCI controller of your board which initiates the burst transfer (bus mastering) , Before that, either your application (C/linux) or your design (VHDL) must provide transfer length AND physical memory start adress. Lookt at your doc to see how the actual 'go' signal (i.e start DMA transfer) is provided to the controller (onthe board i use at work, it is up to the C application to write to a register of the DMA ctlr)
So...lets say that the FPGA was capable of bus-mastering, and thus could initiate a PCI write transaction. Lets say that the main system processor (x86 or whatever) had already provided a set of physical addresses to the FPGA through some other means (perhaps as a totally separate PCI write transaction from the x86 to the FPGA). My understanding is that the FPGA is then capable of initiating a PCI write transaction, where it can write data to, say, SDRAM that is connected up to the main system processor, without any intervention from the system processor itself. I think the order of events would go like this:
0) FPGA arbitrates for the PCI bus
0.5) FPGA is granted the PCI bus
2) FPGA starts a write transaction, with the target address being that of SDRAM hooked up to the system processor.
3) Each data word is then clocked onto the PCI bus, received by the PCI controller hooked up to the system processor, which then arbitrates for the processor's local bus in order to write data to the local SDRAM.
4) When the FPGA has written all the data it wants, it would assert one of the INTx lines to indicate to the system controller that data is now available at the previously-assigned physical address.
Thus, no intervention from the system processor at all here...any flaws in this logic? Also, I assume that if the FPGA can do a burst write in step 3 above, all of the data that is bursted onto the bus by the FPGA will end up in the sequential physical memory locations in the SDRAM, until either the system processor/PCI controller stops the transaction or the FPGA simply ends.
I am not well versed with the drivers stuff. I have a pci bridge between the pci bus and the fpga. I configure the bridge for the DMA trasfers . I do not have driver asociated with the pci card.
Now what destination address should I give if want to transfer the bursts of data to the host and how do I read this data on the host. Should I write a driver for capturing this transfer? Nitesh
I have a psb core written in verilog which interfaces the dual pci bridge( POWERSPAN II) friom tundra with virtexII pro. This bridge is an interface between the PSB bus on the fpga side and the pci bs on the host side. I want to configure the bridge to do dma transfer from the fpga to the
32 bit pci on the host. I went through the powerspan II data sheets and have a rough idea of the architecture . Before that I have to configure the bridge . I needed some help on configuring the bridge using vhdl. Has anyone written a code to configure the pci bridge before? Thanks, Nitesh
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.