Re: FPGA for PCI based servo control board

[Jon Elson <elson-at-pico-systems.com>]

jmkasunich-at-ra.rockwell.com wrote:

>The two board solution helps.  The "brain" board has
>the high speed and complex stuff in FGPAs.  That board
>will probably have to be four layer because of the
>speed of the PC interface signals, whether they are
>PCI, ISA, parallel port, or ethernet.  But in all of
>those cases, I expect the it will be small, maybe 3"
>square, or bigger if needed to support a PC bus
>connector.  This board is a candidate for "commercial"
>production.
>  
>
For PCI, 4-layer is most likely necessary.  I am using all 2-layer 
boards for
my PPMC and Universal Stepper Controller, and the 30K gate Spartan
is getting to be a serious FPGA.  I have had no trouble with them.
I use lots of decoupling caps, and robust ground busses around the FPGA.

>The solvable problem is how to connect the FPGA
>to the ethernet cable.  What does it cost to add
>ethernet to an embedded project?
>
A lot.  There is now an Ethernet in an RJ-45 socket, for $35.
But, you still need a CPU to handle the complex messages, in
most cases.  It may be possible for a very tightly defined protocol
to be implemented with just an FPGA, though.

>The more serious problem is the NIC driver in the
>PC.  Linux provides a whole bunch of NIC drivers,
>for many different cards.  They all have one thing
>in common though - they run in the non-realtime
>part of the PC, as part of the Linux kernel or
>as kernel modules.  AFAIK, they are _not_ usable
>by a real-time task running under RTLinux or RTAL.
>Can somebody who knows the EMC architecture either
>confirm this, or set me straight?
>
Yup, that is true.  You'd have to go in at the hardware level, with a
custom driver that will run in RT.  This might not be so hard, but you'd
need a different version for each chipset.  Not an attractive thought.
Really, at that level, Ethernet is not a whole lot different than a
fancy UART, though.

>  If the Linux
>drivers are indeed not accessible to real-time tasks,
>then any ethernet solution will require writing a
>real-time compatible NIC driver for every brand of
>NIC.  On the other hand, if real-time tasks can
>use the existing Linux NIC drivers with a clean
>raw packet interface, ethernet looks very good!
>
No way.  It might be possible to extract a common section of the
protocol stack, and use that as the basis for the RT code.  But, it would
almost always require hand massaging, I'm afraid.  Once you go
outside the RT code for anything, you are, BY DEFINITION, no
longer real-time.  That code could lose control due to a higher priority
task, and the message would not get there in time.

Jon