Re: FPGA for PCI based servo control board

[John Kasunich <jmkasunich-at-worldnet.att.net>]

At 07:27 PM 4/5/03 -0500, John Sheahan wrote:

>On Sat, Apr 05, 2003 at 04:49:22PM -0500, John Kasunich wrote:
> >
> > With ethernet, there are two possibilities.  One is to send
> > a 256 byte packet from FPGA to PC, transferring the entire
> >...
> > makes it better, but your're still transferring far more data
> > than is actually needed.
>
>how come one scheme here always transmits max size data,
>and one transmits a delta?  All schemes could run either way.

I don't understand what you are saying.  One scheme sends 256
bytes.  The other scheme sends only the bytes needed by the
specific machine, which depends on the number of axes, etc.
For any given machine, the number of bytes in each packet is
always the same, and all data is updated every servo cycle.
No deltas.  One scheme is simpler to implement but slower,
the other is faster but more complicated.  I don't care which
one is used, but obviously the software in the PC and the
micro or state machine at the other end of the link have to be
using the same scheme.

> > I see the micro-fpga interface as a set of registers.  Not too
> > complex at all.
>
>which is the model used inside the pc. What did we gain with the
>interface card exactly?

Again I don't understand.  There are two interfaces in the system.
One is between the PC and the FPGA, and the other is between
the FPGA and the physical devices like encoders, stepper drivers,
limit switches, etc.

The PC to FPGA interface can be ISA or EPP for low cost,
PCI for performance, or ethernet to let the FPGA board be
closer to the machine.  The user makes the choice depending
on what he thinks is most important.

The FPGA to device interface common to all four designs, and
I/O boards can be used with any FPGA board.  I/O boards are
designed to mix and match I/O to keep cost down.  For a one
off project, the I/O board could be custom made on perf-board
or wire-wrap, using published schematics.  That's much harder
to do with an FPGA, especially if your gonna connect it to a
33MHz PCI bus!

> > 1)  PCI - big FPGA, containing a PCI interface and the control
> > hardware.  The control registers are mapped to a block of PCI
> > I/O addresses.  PnP complicates things, but it really comes
> > down to getting the base address to the EMC code somehow.
>
>on a new SMD board inside the PC. Not complex, but
>hard to assemble.

Complexity is in the eye of the beholder.  Yes, the parts count is
low.  But that's like saying a 2003 PC motherboard is less complex
than a 1985 one because there are fewer parts on it.  In my view,
complexity = design time, not parts count.  The FPGA is complex,
the I/O interface is simple.  But the interface costs as much or
more than the FPGA, because terminal blocks, relays, optocouplers,
and such are expensive.

>Whats the model for the connection between this card and the target?
>some kind of wide, high-density connector?

Yes.  I was thinking SCSI-3 cables (68 pins), but there are other
possibilities.

>Thats what I was actually trying to eliminate.

Why?

>The IO card is still required.

Yes.  You will always have an I/O card, unless you intend to take
the limit switch leads, spindle on/off, coolant pump, and all the
other wires directly to the back of the PC slot.  Whether it's a
25 pin parallel port cable, or 60+ wires on a complex machine
with a many axes, jog wheels, and a tool changer, you will need
something to break them out from high density fragile electronic
connectors to rugged industrial screw terminal strips.  What I am
advocating is making that breakout board design cheap, modular
and expandable.

> > 2)  ISA - small FPGA, containing an ISA interface and the control
> > hardware.  The control registers are mapped to a block of ISA I/O
> > addresses.  The base address is set by jumpers, and entered into
> > the EMC ini file.  Old-fashioned, but it works.
>
>what do we gain with this we do not have today?  Also the transaction
>speed on the ISA interface is an issue for the real-time loops.

We gain lower cost.  It works just like a Servo to Go card, but costs
less.  Improvements don't have to be in performance.  The cheapest
solution that does the job at hand is the right one.  ISA performance
obviously isn't a problem for the people using STG cards today.

> > 3)  EPP - small FPGA, containing an EPP interface and the control
> > hardware.  The control registers are accessed sequentially through
> > the EPP "bus".  The parallel port address (378h, etc.) is entered
> > into the EMC ini file.
> >
>
>yes. Again, seems to be pretty much what Jon has done well.

Yes, and if Jon's I/O mix is OK for your application, buy his board.
If not, this one is more flexible, and still fairly cheap.

> > 4)  Ethernet - big FPGA, containing an ethernet MAC and the
> > control hardware.  The packet format is as I described above.
> > The PC NIC ID (eth0, etc.) and the FPGA MAC address are
> > entered into the EMC ini file.
> >
>
>10 or 20 k gates I'd assume, but not a particularly high pin count.
>probably plcc (hence socketable, hence buildable by most)
>On the same board as all the IO buffers, physically located close to
>the machine.  My picture here is just a cheap longish cable.

You could put it all on one board if you want.  But when you lay out
that board, you better know what I/O mix you need.  And be prepared
to re-do the layout if you change your mix.  I/O and FPGA on two
boards lets the I/O change without affecting the FPGA board.  If you
have a medium to high volume application with a fixed set of I/O, by
all means put everything on one board.

> > Most of the EMC code is the same for all 4 versions.  Versions
> > 1 and 2 use the exact same code, once the base address is
> > known.  Version 3 uses a simple interface layer that translates
> > each access into one or two EPP cycles.  Version 4 uses a
> > more complex interface layer that handles packets.
> >
>
>moving the same sort of data to a register map in the NIC, then saying
>go. not much more complex. Perhaps less cpu as it does not have to
>bi bash out a slow interface.  (just how many cycles does a 1G pentium
>waste sinning on an ISA read or write? 100's to thousands. ouch.

Nothing is being bit bashed.  Byte bashed maybe ;-)   If cycles spent
waiting for ISA or EPP bug you, then get the PCI or ethernet versions.

Each of the four designs listed has strong and weak points.
I'm not advocating any one over the others.  I am advocating
an overall concept that allows all four to be built.  The control
portion of the FPGA, as well as all of the I/O stuff, is common
to all four designs.  The EMC servo and I/O code is also the same,
and EMC interacts with the control hardware through a register
map that is the same in all four designs.  The only difference is
the mechanism used by EMC to read/write those registers - from
single instructions for ISA or PCI, to packet drivers for ethernet.

What I'd really like to do is define two things:

1)  A set of registers by which EMC communicates with the control
hardware part of the FPGA.

2)  A set of pins by which the control hardware part of the FPGA
communicates with the outside world of encoders, switches, motors, etc.

If we had these two things, then several parts of the design could
begin to make progress:

I/O hardware to go from pins to terminal blocks could be designed.
For digital inputs this would be either discrete optocoupler inputs,
or OPTO-22 modules.  For outputs it would be relays or OPTO-22
modules.  For analog outputs it would be filters and buffers for
+/-5v, +/-10v, and maybe 4-20mA.  For step/dir outputs it would
be a one-shot and line drivers, with selectable polarity and pulse
length.

The FPGA logic that goes from the register set to the pins could
also be designed.  For outputs, this would be a pulse rate generator
whose output could be filtered on the I/O board for analog outputs,
or buffered for step/dir outputs.  For inputs, an up/down encoder
counter with a quadrature decode state machine.  And for digital
I/O, a simple 8 bit bus.

The EMC software that to perform the basic servo loops and I/O
could be written.  The interface to the registers would be through
a wrapper, something like this:

void WriteReg ( unsigned char reg_no, unsigned char data )
unsigned char ReadReg ( unsigned char reg_no )

And finally, advocates of each method of PC to FPGA communication
could start their designs.  Each method would supply its own copy
of the wrapper functions.  For example, the PCI & ISA versions would
look like:

static unsigned int BaseAddress;

void WriteReg ( unsigned char reg_no, unsigned char data )
{
outportb ( BaseAddress + reg_no, data );
}

unsigned char ReadReg ( unsigned char reg_no )
{
return ( inportb ( BaseAddress + reg_no );
}

Optimized EPP versions are a little more complicated, but I could
write them in an hour.  The ethernet versions would require knowledge
of NICs that I don't have, so as it stands I couldn't write them at all.

John Kasunich