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.

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_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/e6afa044f684b6e1?dmode=source

On Apr 21, 4:56 am, Didi <d...@tgi-sci.com> 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!