Re: FPGA for PCI based servo control board

[John Sheahan <jrsheahan-at-optushome.com.au>]

On Sat, Apr 05, 2003 at 11:25:40PM -0500, John Kasunich wrote:
> 
> 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.

Sorry - I was particularly unclear.

I see (at least) two interfaces and (at least) two ways of
sending the data.
Either send all data , of a delta.  
Either scheme can be used on either interface. 
Doing transfer-time- sums for the max data at the slowest 
serial interface rate seemed unreasonable.

Sending all data takes longer, but is more robust to packet loss. 
 


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

minor quibble. gigabit ethernet is as fast as pci.  

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

agreed on PCI.  not a givem for a PLCC on eth I think. 
Could even put a fpga on a couple-inch square smd that plugs in 
to the perf board - like many of the current usb-style interfaces.



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

I think this shows our relative experience bases. I'd see the fpga as
a couple of days to get the rtl simulating. It would take me longer
than that to decide on the IO drivers, sort out footprints and draw
the board. 


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

I find HD SCSI cables relatively expensive, short  and fragile.
And the sockets are expensive in small qty.  


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

sure. I'd just add the interface electronics at that point. 


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


perhaps that daughter board I mentioned would be useful here.


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

I'm happy to design the ethernet-mac to pins of an fpga.
I've got a Xilinx eval board uncommited it should be testable on.


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