Re: FPGA for PCI based servo control board

[jmkasunich-at-ra.rockwell.com]

John Sheahan wrote:

> John Kasunich wrote:
>
>> I'm coming at this strictly
>> from a hobby point of view.  I want simple circuits, parts
>> that I can solder, and non-critical layout.  Ideally I'd
>> be able to use a two layer board, since they are much
>> cheaper in small quantities.

> Agree. my current projects have these constraints.
> however for me a 'simple circuit' means few parts,
> easy-to-asemble. Which sometimes means doing as
> much inside a fpga or a single-chip uP as practical.

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.

The I/O board is the one that I want to keep really
simple.  Everybody has different I/O needs.  I'd like
to keep the design of the I/O board completely open
and modular.  Ideally, people could cut and paste
the interface and signal conditioning circuits for
analog outputs, step/direction outputs, encoder inputs,
and digital I/O, to design their own custom I/O boards
with exactly the mix of I/O they need.  There is also
room for "commercial" offerings of I/O boards with
popular configurations.

For example, when I build my own I/O board for my
project, I'll probably buy between 3 and 5 boards
due to setup charges.  I'll sell the unused PCBs
at my cost, to anyone who wants an I/O mix like
mine (or a subset of mine - the boards don't need
to be fully populated).

Meanwhile, I would buy the brainboard from somebody
else if it was available at a reasonable price.
Everybody will use the same brainboard, so there
is more potential for commercial production, or
at least group purchases of bare PC boards.

> Back to the original thread - seems to me what is
> being considered here is moving some of the
> functionality of the micro to a FPGA running on
> PCI inside a PC.   All the rest remains.

I think everybody agrees about "moving some of the
functionality from the PC CPU to dedicated hardware".
Most agree that the hardware will probably be an FPGA.
The "running on PCI inside a PC" part is more
controversial. <grin>

Give ten engineers a problem and you will get ten
opinions on how to solve it.  After a lot of talking
the opinions may begin to converge, but there will
still be differences.

> I personally find the inside of a PC a nasty
> environment to design for. (mechanically, power,
> short life, crappy IO connector mounting)

> I would leave the board features you describe
> together and use perhaps ethernet withoout the
> protocol stacks, to offload the functionality.
> because I'm personally tired of parallel ports.

> then the bit inside the PC is a single cheapo
> NIC.  The PC that runs my router changes more
> often than the rest of it.

Others have also advocated this approach, and I
like it.  It is probably the most "future proof"
of the approaches that have been discussed.

I see two complications, one solvable, and one
possibly quite serious.

The solvable problem is how to connect the FPGA
to the ethernet cable.  What does it cost to add
ethernet to an embedded project?  The folks at
http://www.embeddedethernet.com sell a tiny little
module, but it costs $70.  I know you can buy a
PC type NIC for $10, but those are commodity
products made in China in enormous quantity.
Also, I expect any ethernet interface will
require a micro to pull data from the ethernet
chip and stick it into the FPGA, and vice-versa.
This isn't hard, a cheap PIC could probably do it.
It will require some firmware though.  To sum it
up, the ethernet to FPGA interface can be done,
but it will cost money and require additional
development effort.  I don't know how it compares
with PCI, but it would certainly be harder and
more expensive than ISA or parallel port.
That work and expense needs to be weighed against
the benefits of the extremely versatile and future-
proof ethernet connection.

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?  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!

> I think this approach allows you to concentrate on
> the 'control' part with as little diversion as
> possible into the wonders of the PCI bus.  Having
> been involved in PCI interfacing. its more painful
> than ISA.

Having _not_ been involved in PCI interfacing, I
don't want to find out how painful it is. <grin>

There has been a lot of talk about this project
lately, by many people including me.  Just to
make clear that it isn't all talk, here is my
personal commitement to this project:

I will design and publish interface circuits
for analog output, step/direction output, encoder
input, and digital I/O. I've posted some very
preliminary drawings at:
http://home.att.net/~jekasunich/Bidirectional_IO.gif
http://home.att.net/~jekasunich/CNC_Output.gif

I will combine these circuits into a schematic,
bill of materials, and layout for an I/O board
that fits my needs (4 axis step/dir output, 6
encoder inputs, ?? digital I/O).  I will post
all of the documentation.  The board files
probably won't be Gerbers, since I don't have
access to real PCB layout tools at home.  I'm
leaning toward the Express PCB tool.  If I can
do the layout using tools from work, I'll post
real Gerber files.

I will buy more than one of my board, and
sell the ones I don't use at a reasonable
price.

I will contribute to the design of the control
portions of the FPGA.  This includes digital I/O,
encoder counters, and step/dir or analog outputs.

I will do an ISA or EPP bus interface if I have to.

I will not do a PCI or ethernet interface - I don't
have the knowledge or time to do either of those.

I will work with anyone who wants to do a bus
interface to the control hardware, especially
if they are doing it in a way that can support
other busses.

I will work with anyone who wants to modify EMC to
work with the control hardware, regardless of the
bus interface used to communicate between EMC and
that hardware.

I will modify EMC myself if I have to, to make it
work with the control hardware, using my chosen
bus interface only (probably ISA or EPP).

Most of the above is stuff I've been expecting to
do anyway, in the process of converting my machine
to CNC.  I know I could just use software step
and direction, or buy Jon's stepper controller,
but what's the fun in that?

Based on commitements to the rest of my life, I
know it will take many months to do all of the
above - anyone who needs results in 6 weeks
better not count on me.

Oh, and one more thing.  I will continue to write
long rambling emails to the EMC list analyzing
every aspect of this project. <grin>

Looking forward to NAMES and EMC Monday.

John Kasunich