feeding a FIFO from PCI - Hardware

This is a discussion on feeding a FIFO from PCI - Hardware ; John, I might have missed something, but if you need a FIFO size of 8K x 48Bits you'll get that into most reasonable sixed FPGAs these days (Cyclones or Spartans). Otherwise hang a DRAM off it as rickman says. If ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 30 of 30

Thread: feeding a FIFO from PCI

  1. Re: feeding a FIFO from PCI

    John,

    I might have missed something, but if you need a FIFO size of 8K x 48Bits
    you'll get that into most reasonable sixed FPGAs these days (Cyclones or
    Spartans). Otherwise hang a DRAM off it as rickman says.

    If your data rate to the FPGA is only 1MByte/second you could almost get
    away with one of the FTDI USB 1.1 interfaces (FT245R gives an 8 bit
    fifo output).

    If this isn't sufficient there are a couple of easy to implement microcontrollers
    about that give you a FIFO interface at USB 2.0 full speed data rates.

    The host PC would need to do more of the work but if this is acceptable then
    an embedded SBC seems like complete overkill?


    Nial.



  2. Re: feeding a FIFO from PCI

    Nial Stewart wrote:
    > ...
    > If your data rate to the FPGA is only 1MByte/second you could almost get
    > away with one of the FTDI USB 1.1 interfaces (FT245R gives an 8 bit
    > fifo output).


    If the data rate is only a 1-2 Mbytes/S it can be done in a single
    MPC5200,
    with some (64M, 128M?) DDRAM and a flash chip. The FIFOs are on chip,
    one of the serial ports can be set to do 16 or 32 MbpS; it will only
    have to be
    deserialized - some CPLD or whatever (6 x 74hct164....?). The entire
    BOM
    would be $50 to $100 for prototype quantities. With DPS running on it,
    net access over the 100 Mbps Ethernet port is there. Want a HDD,
    connect
    one to the 5200 ATA port.
    But this is me, the rest of the world seems to consider designs which
    do not rely on some intel/linux/MS monstrosity illegal nowadays.

    Dimiter

    P.S. a similar (doing apr. 1.8 Mbytes/S thing) is at
    http://tgi-sci.com/y2demo/

    ------------------------------------------------------
    Dimiter Popoff Transgalactic Instruments

    http://www.tgi-sci.com
    ------------------------------------------------------
    http://www.flickr.com/photos/didi_tg...7600228621276/

    Original message: http://groups.google.com/group/comp....b?dmode=source

  3. Re: feeding a FIFO from PCI

    "Didi" wrote in message
    news:e7faffe3-e733-4033-aa1a-abb07d42f36e@q10g2000prf.googlegroups.com...
    > But this is me, the rest of the world seems to consider designs which
    > do not rely on some intel/linux/MS monstrosity illegal nowadays.


    It's just that finding people to code on those platforms is easier and -- if
    you need the complexity of a GUI or full TCP/IP stack or USB host anyway,
    there's a huge amount of code, completely free, that you can leverage if you
    just "tow the company line" and use one of those "monostrosities." A couple
    bucks extra in hardware is a lot easier to get funded than a few more
    programmers and another year of development time, after all (especially when
    finding GOOD programmers is somewhat tricky these days!)

    I bet plenty of people ask why your software doesn't "look" like standard
    Windows, don't they?



  4. Re: feeding a FIFO from PCI

    Hi Didi,

    "Didi" wrote in message
    news:018c2551-78ca-4749-8d91-c5bbed3c41d7@1g2000prf.googlegroups.com...
    > DPS is less popular than that. It is all my work, my property etc.


    You wrote the TCP/IP stack from scratch? That's a lot of effort! Good work.

    > Comes
    > on my products. I have been wanting to put a cheap product with it on
    > the market but I just got a setback and may be unable to do it this
    > year
    > yet again....


    I hope you'll be able to do it eventually; I'm sure many people would be
    interested.

    ---Joel



  5. Re: feeding a FIFO from PCI

    Joel Koltner wrote:
    > Hi Didi,
    >
    > ....
    > > DPS is less popular than that. It is all my work, my property etc.

    >
    > You wrote the TCP/IP stack from scratch? That's a lot of effort! Good work.


    Thanks. It took me about 6 months to do (including the DNS and some
    high
    level clients), and is not such a great part of DPS (about 10%).

    >
    > I hope you'll be able to do it eventually; I'm sure many people would be
    > interested.


    So do I hope (hope, that is)! ... :-). I will eventually, it won't
    take that much - I
    know I'll do it, as for those interested I wish I knew a bit
    more.... :-).

    Dimiter

    ------------------------------------------------------
    Dimiter Popoff Transgalactic Instruments

    http://www.tgi-sci.com
    ------------------------------------------------------
    http://www.flickr.com/photos/didi_tg...7600228621276/

    Original message: http://groups.google.com/group/comp....8?dmode=source

  6. Re: feeding a FIFO from PCI

    In article 5d75b59b9a8e@p25g2000pri.googlegroups.com>, Didi says...
    > It does not matter how tempting
    > those nice things under that tree look, danger may be lurking around
    > if the place is so desolated.... :-).


    If the place is so desoloated it is dangerous. Such places are away
    from support. Also there is extra danger on first approach since the
    hazards are unfamiliar.

    I rather suspect many in this group prefer the hazards and beauties of
    the new, unfamiliar (and desolate) to the dangers of the crowds. If
    nothing else for the thrill of treading less travelled paths.

    Is the metaphor broken yet

    Robert
    ** Posted from http://www.teranews.com **

  7. Re: feeding a FIFO from PCI

    On Sat, 12 Apr 2008 09:38:30 -0700, John Larkin wrote:
    [re "box that will control a scientific gadget" possibly using "an
    Intel-cpu SBC and a custom board" where "SBC would talk gigabit
    ethernet to the customer's system and PCI to our board." with SBC
    like http://us.kontron.com/index.php?id=2...productid=1726

    > Our board would have a PCI interface driving a biggish FIFO, say 8k deep
    > by 48 bits wide, inside an FPGA. [...]
    > OK, we finally get to a question: If we run some flavor of Linux on the
    > SBC, what's a good strategy for keeping the fifo loaded? Assuming that
    > we have the recipe for an entire experimental shot in program ram, some
    > tens of megabytes maybe, we could...

    ....
    > 3. Best, if possible: set up a single DMA transfer to do the entire
    > shot. That involves a dma controller that understands that the target is
    > sometimes busy [...]


    If the linux kernel is given a "mem=n" parameter at boot time, it will use
    only n bytes of memory, which leaves the balance of memory to be contiguously
    allocated later with "dmabuf = ioremap(...)" (see "Allocating the DMA Buffer"
    and "Do-it-yourself allocation" in Chap. 13 of Linux Device Drivers, by
    Rubini and Corbet; eg http://www.xml.com/ldd/chapter/book/ch13.html .)

    If high memory isn't usable by the DMA controller, you could build a
    kernel with your device driver using preallocated fixed buffers,
    rather than loading the driver as a module.

    User code can access the buffer as a memory-mapped file; see
    eg http://www.scs.ch/~frey/linux/memorymap.html for background, and see
    eg http://linux.die.net/man/2/mmap for notes on some flags that can lock
    the mapped pages in memory, make them private, map to fixed location, etc.

    > 4. If it's a dual-core cpu, is it hard (under Linux) to assign one cpu
    > to just do the fifo transfers?


    Root can use cpusets, described at http://lwn.net/Articles/127936/
    to allocate cpu's and memory nodes, or can use system calls as
    described in http://linux.die.net/man/2/sched_setaffinity to
    control which cpu's given processes will run on.


  8. Re: feeding a FIFO from PCI

    On Apr 12, 11:24 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
    Murray) wrote:
    > >When you say that you don't need "real time software", I am missing
    > >something. Once started, does the DMA run to completion by itself?
    > >Maybe I am not up to speed with current software techniques on the PC,
    > >but I thought even DMA required real time response to keep it queued
    > >up and running. As far as allocating a block of memory to buffer the
    > >data, I have no understanding of what it takes to allocate a buffer of
    > >half a GB or more of contiguous memory. But like I said, I am not so
    > >familiar with this approach.

    >
    > The basic idea is that you give the FPGA a pointer and length.
    > It reads memory a cache block at a time as it needs it. When
    > it's done, it sets a status bit and maybe generates an interrupt.


    I understand perfectly how DMA works and all the permutations. But
    you are glossing over all of the difficulty of getting physical
    addresses from an OS and getting the software to let the hardware use
    it.

    > It's possible I'm overlooking something critical. Maybe allocating
    > huge (as compared to big) chunks of memory is hard. I'm sure
    > a good kernel wizard can do it one way or the other. If nothing
    > else, you hack the very early part of the kernel to put some memory
    > in it's back pocket until you ask for it. Ugly, but effective.


    That is the sort of stuff that I would not want to deal with. I am
    much more comfortable with offloading the entire real time function
    onto the dedicated hardware and keeping the PC out of the time
    critical loop. When it is so easy to add a little bit of RAM to the
    board, I don't get why anyone would want to have to make a complex OS
    run a real time task???

    But like I said before, we are all comfortable with different
    things.

  9. Re: feeding a FIFO from PCI

    rickman wrote:
    > .....
    > > It's possible I'm overlooking something critical. Maybe allocating
    > > huge (as compared to big) chunks of memory is hard. I'm sure
    > > a good kernel wizard can do it one way or the other. If nothing
    > > else, you hack the very early part of the kernel to put some memory
    > > in it's back pocket until you ask for it. Ugly, but effective.

    >
    > That is the sort of stuff that I would not want to deal with. I am
    > much more comfortable with offloading the entire real time function
    > onto the dedicated hardware and keeping the PC out of the time
    > critical loop. When it is so easy to add a little bit of RAM to the
    > board, I don't get why anyone would want to have to make a complex OS
    > run a real time task???


    This is a sane reasoning I have heard more than once while discussing
    different projects (sometimes hypothetical). At this point my question
    usually is "so what is the bloody PC for in the design then?" . The
    usual
    answer is something like "well but they are so cheap and so
    popular..."...

    Dimiter

    ------------------------------------------------------
    Dimiter Popoff Transgalactic Instruments

    http://www.tgi-sci.com
    ------------------------------------------------------
    http://www.flickr.com/photos/didi_tg...7600228621276/

    Original message: http://groups.google.com/group/comp....1?dmode=source


  10. Re: feeding a FIFO from PCI

    On Apr 21, 4:56 am, Didi wrote:
    > rickman wrote:
    > > .....
    > > > It's possible I'm overlooking something critical. Maybe allocating
    > > > huge (as compared to big) chunks of memory is hard. I'm sure
    > > > a good kernel wizard can do it one way or the other. If nothing
    > > > else, you hack the very early part of the kernel to put some memory
    > > > in it's back pocket until you ask for it. Ugly, but effective.

    >
    > > That is the sort of stuff that I would not want to deal with. I am
    > > much more comfortable with offloading the entire real time function
    > > onto the dedicated hardware and keeping the PC out of the time
    > > critical loop. When it is so easy to add a little bit of RAM to the
    > > board, I don't get why anyone would want to have to make a complex OS
    > > run a real time task???

    >
    > This is a sane reasoning I have heard more than once while discussing
    > different projects (sometimes hypothetical). At this point my question
    > usually is "so what is the bloody PC for in the design then?" . The
    > usual
    > answer is something like "well but they are so cheap and so
    > popular..."...


    The PC is there as the UI. If the job is using standard interfaces,
    then it could be worth a bit of software work to avoid having to build
    hardware. But this project is building a special board with an FPGA!
    Heck, unless they have highly specialized interfaces to their project
    they want to control, they could even do the whole thing on a
    standard, COTS evaluation board if it has enough memory! There are
    tons of boards available which include high speed interfaces like
    Ethernet and USB and will support this project as-is other than a
    specialized interface on the project end.

    Then you can use the PC as a UI and don't even need to build
    hardware!


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2