Re: FPGA for PCI based servo control board

[jmkasunich-at-ra.rockwell.com]

Jon Elson wrote:

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

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

That's good to hear.  Four layer boards add lots of $$$.

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

I'd just use a CPU - shouldn't need much of one.  One packet
each way, between 8 and 20 bytes per packet, at the servo
rate.  No TCP/IP or anything like that, just raw ethernet
packets.

>> The more serious problem is the NIC driver in the
>> PC.  Linux provides a whole bunch of NIC drivers,
>> for many different cards.  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.

Nope, not attractive at all.  As far as I am concerned,
that just about kills the ethernet version,  unless
somebody steps forward and volunteers to write real
time raw packet drivers for a couple dozen of the most
common NICs. :-(

Actually, I wonder if the source for the normal,
non-realtime drivers would contain most of the
hardware level details.  I know absolutely nothing
about how those drivers are structured, but perhaps
real-time drivers could use large chunks of the
existing code?

Bummer...

John Kasunich