Re: FPGA for PCI based servo control board

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

At 07:21 PM 4/4/03 -0500, you wrote:

>On Fri, Apr 04, 2003 at 08:52:03AM -0500, jmkasunich-at-ra.rockwell.com wrote:
> >
> > NO. Raw packets.  Point-to-point connection, no
> > switches, hubs, or collisions.  Still need protection
> > against noise corrupted packets (CRC errors).
>
>Agree.  8019 class devices do crc.
>
>now the question of what happens when a packet is lost
>arises.  Its equivilant to what happens when the
>parallel port (choose favourite interface) glitches.
>(this is the root cause of my parallel port phobia)

The way I've been looking at this project, all of the output
data is updated at the servo rate, 1mS or faster.  If a
packet is lost, the hardware just uses the old data for
another millisecond, until the next packet arrives.

A watchdog timer is a is required on any version of this,
since the hardware can continue to drive the motors
even if no commands are received.  After 5mS or so
with no updates, the timer needs to set all outputs
to zero and do an E-Stop.  This is true regardless of
the interface used.

>ethernet will be no worse than anything else here.
>probably quite a bit better than most.

It's better than the parallel port.  With ethernet, you
either get good data, or no data.  With the parallel port,
you can get bad data.

As Jon has pointed out, with short, well shielded cables,
the parallel port is pretty reliable.  The PCI and ISA
versions would be even better.

> > >
> > > the fpga can suck fixed formatted
> > > packets straight out.
> >
> > Can it assemble packets and stuff them into the
> > ethernet chip too?  Gotta handle the inputs as
> > well as the outputs.
>
>Hey - I'm on record as requiring a HDL for the fpga design
>and a decent fpga.  State machines is _the main_ area
>HDL designers dislike regressing to schematics.  no problem.

OK, I''ll have to take your word for it.  I tend to think of complex
but relatively slow tasks (packet building) as jobs for micros,
and simple but very fast tasks (step pulses) as jobs for dedicated
hardware.  There are probably more people on this list who can
write/debug the code to do it in a micro compared to folks who
can write/debug the HDL to do it in the FPGA.

> >  Also, do we use a fixed
> > format packet that includes 8 axis and 128 bits
> > of digital I/O regardless of the actual amount
> > needed, or should the packet format be determined
> > at boot time?  I agree that during run time, the
> > packet format should be fixed.
>
>sounds like a parameter for the fpga compile. A format that
>can obviously be  extended for more axis or more resolution
>as required.   Don't think its a big deal either way.

Joe User ain't gonna be re-compiling the FPGA to suit his
mix of motors and I/O.  He has neither the tools or the
know-how.

The way I see it, the control hardware interface is simply
a set of registers.  An encoder input is a 16 bit read register.
An analog or step/dir output is a 16 bit write register.  Digital
inputs are one or more 8 bit read registers, and digital outputs
are one or more 8 bit write registers.  Using the 8 axis/128 bit
system, the total is 32 bytes read, 32 bytes write.  That would
cover the vast majority of systems, but I suppose you could
expand the register map further if needed.  I can't see any
system needing more than 256 bytes read and 256 bytes
write.  The following assume that the interface to the control
hardware is a set of 256 or less registers:

With an ISA or PCI interface, the registers would be mapped
directly to CPU I/O ports, and the software interface is trivial.

With EPP, the CPU can access two ports, data and address.
The byte written to the address port determines which register
is accessed from the data port.  The address register can be
made auto-incrementing to speed up access to sequential
blocks of registers.  (I believe that is what Jon does.)  The
software interface is still pretty simple.

With ethernet, there are two possibilities.  One is to send
a 256 byte packet from FPGA to PC, transferring the entire
block of read registers to a RAM image in the PC.  Then the
servo code reads the image, computes its outputs, and
writes them to another RAM image.  Then that image is
sent as a 256 byte packet to the FPGA, which updates all
256 write registers.  This is simple at both ends, but a 256
byte packet is over 2.5mS long at 10Mb.  100Mb ethernet
makes it better, but your're still transferring far more data
than is actually needed.

The other way is to use a config packet at startup of EMC
to define the actual subset of registers that is really needed.
The config packet might look something like this:

Byte 1 =  Nr   -   number of registers to be read each cycle.
Byte 2 =  Nw  -   number of registers to be written each cycle.
Bytes 3 to (Nr+2) =  register addresses to be read
Bytes (Nr+3) to (Nr+2+Nw) = register addresses to be written

The config message would most likely be built and sent by
the MotInit function, based on information found in the ini
file.  The info would be remembered by the FPGA or a micro
between the network interface and the FPGA.

The read packet would be Nr bytes long, and would be
assembled from FPGA registers based on the addresses
from the config message.

The write packet would be Nw bytes long, and would be
copied to the FPGA registers based on the addresses
from the config message.

>I'd vote for full duplex and some limit on max packet rate to keep
>both sides happy.

The job of updating servos is inherently a half-duplex task.
Feedback goes from the encoders to the PC, the PC computes
the new velocity command, and the command goes back
to the hardware.  That doesn't mean that full duplex is bad,
but I see it as an option, rather than a neccessity.

The packet rate _is_ the servo rate.  It is specified in the ini file.

>   The reverse channel has to work reliably.

Definitely - feedback is as important, if not more important,
than output.

>The interface between the
>micro and the fpga will be as complex as the fpga/ethernet-chip.
>And has to be specified.

I see the micro-fpga interface as a set of registers.  Not too
complex at all.

>Let me throw in another thought - the ethernet mac is smaller
>than the pci core, do that in the fpga too.

I like that.  I still see four versions:

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.

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.

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.

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.

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.

>   We need a new thread here :)

That's for sure.

John Kasunich