Re: FPGA-pci communication

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

Does this make sense?

TIA,

John

.

Relevant Pages

  • aic7xxx problem on sparc64 (2.6)
    ... PCI: Probing for controllers. ... PCI0: Bus running at 33MHz ... Uniform Multi-Platform E-IDE driver Revision: ... CMD646: IDE controller at PCI slot 0000:01:03.0 ...
    (Linux-Kernel)
  • Re: PCI FPGA Dev Board Suggestions
    ... without resorting to National Instruments cards (including their FPGA ... It seems that most FPGA PCI boards are tailored to embedded ... PCI33 bus you can use without having to concern yourself with other ... The driver is another problem. ...
    (comp.arch.fpga)
  • Re: whats a platform device?
    ... The situation I have is an FPGA connected over PCI. ... it seems that a "platform device" is a pretty generic concept ... as they have no "bus" to attach too. ...
    (Linux-Kernel)
  • Re: Easy PCI interfacing
    ... > serial bus running around a mother board to do heat and fan monitoring, ... > this come out on the PCI connector? ... A suitable solution will be to use Chameleon POD (smart parallel port ... 'packetable' application like a small I"C Controller or SPI controller. ...
    (comp.arch.embedded)
  • Re: AGP or PCI
    ... the CPU splits into the PCI bus and AGP bus via PCI and AGP controller ...
    (microsoft.public.windowsxp.hardware)