Re: New project...PCI based servo control board

[Jon Elson <elson-at-pico-systems.com>]

jmkasunich-at-ra.rockwell.com wrote:

>First the output section.  This is based on the drawing I
>posted earlier.
>
>Per axis:
>Command register, 16 D Flipflops with clk ena (10 gates):  160
>26 bit Adder (16 gates per bit - is this reasonable?):     416
>Accumulator, 26 D Flipflops (8 gates):                     208
>Range selection mux (6 inputs):                             24
>Output logic (the stuff to the right of the adder):         63
>                                                        ------
>Total gates per axis for output:                           871
>
>Now the encoder section.  Here I am assuming a 16 bit
>up/down counter, a 16 bit register to capture the
>count value, and a small state machine to convert
>quadrature to up/down pulses
>
>Per axis:
>Counter register, 16 D flipflops (8 gates):                128
>Counter logic (12 gates per bit, is this reasonable?):     192
>Capture register, 16 D flipflops with clk ena (10 gates):  160
>Quadrature decoding state machine, 4 D FFs + logic:        100
>                                                        ------
>Total gates per axis for feedback:                         580
>                                                        ------
>Total gates per axis, output and feedback:                1451
>
>I've been using 8 axis as my target.  This allows for a hexapod
>with a spindle encoder and jog wheel.  (Technically that is six
>outputs and 8 inputs, but I'm gonna just go for 8 complete axis.)
>
>Total gates for output and feedback for 8 axis:          11608
>
>We also need a watchdog timer, some decoding, and the digital
>I/O interface.  Even if this stuff amounts to a several thousand
>gates (which I doubt), we are looking at a 15,000 gate device.
>  
>
This is way optimistic.  I'm using a 10000 gate FPGA for my 4 encoder 
counter
board, and it is pretty full.

I am using a 30,000 gate FPGA for my 4-axis stepper controller (encoder 
counters
plus step rate generators) and it is pretty full, too.

><ranting geezer mode on>
>In another post, someone mentioned that the PCI interface will
>run around 10K-20K gates.  It just blows my mind that the bus
>interface might take more logic than actual control hardware.
>The only reason the bus interface exists is to support the
>control hardware.  That's why I hate the modern PC
>architecture.  Give me an ISA bus anyday.
>  
>
Well, it takes some sophistication to keep the I/O flowing at full speed.
I suspect if you do slave only, no DMA and no auto configuration, it is
MUCH less.  I've seen some MSI "TTL" PCI interfaces that were only
about 5 74AHCxxx ICs.  Mostly, an address comparator and 74AHC374's.

>I found the PCI to ISA bridge idea that Craig mentioned in
>another post _very_ interesting!
><ranting geezer mode off>
>
>After I got the gate count, I hauled out the Digikey catalog
>and looked at the choices.  I was looking for ~15K gates.
>
>Xilinx Spartan-II series - XC2S15-5TQ144C - $10.89
>But this is a 2.5V part, and I don't know whether cheap
>development tools are available.
>  
>
Xilinx has free tools for some of their parts available for download on 
the web,
and they have another tool that you upload the VHDL and they run the placer
and fitter, and then send the reports and program file back to you.

>Xilinx 4000 series - XC4013E-4PC160C - $102.00 <gasp, choke>
>This is the most recent family I have any experience with.
>It is only 13K gates.  Runs on 5V, which I like.  5V will
>be available on PC motherboards for a while - eliminating
>it will require everything from keyboards to floppy drives
>to be re-designed.
>  
>
This is 10+ year old technology, stay away from it.  The original Spartan is
very similar, but much newer and cheaper.  5V.  My 30K gate XCS10TQ144
part in the Universal Stepper Controller is $30.  The XCS10PC84 in the 
encoder
counter board is $12.

>Xilinx 5200 series - XC5210-6PQ160C - $67.20 <still gasping>
>Also runs on 5V
>  
>
Antique.

>That's all I saw in the Digikey catalog.  That catalog is
>my standard for "readily available" parts.  I'm sure there
>are other readily available parts, as well as dozens or
>hundreds of harder to purchase choices.
>  
>
Maybe.  They are YEARS behind the times in what Xilinx parts they carry.

>>>Yes, Jon has confirmed that 1KHz isn't a magic number.
>>>It would be good to have a target rate in mind though.
>>>      
>>>
>
>  
>
>>>>That's one of the things I would like to understand in
>>>>more detail...what are the bottlenecks to higher update rates?
>>>>        
>>>>
>
>  
>
>>>Only one bottleneck - Money.  Money for faster PC CPUs,
>>>and faster, more sophisticated control hardware.
>>>      
>>>
Not really.  Even given the fairly slow I/O rate of ~ 1 uS/byte on the 
parallel port
in IEEE-1284 mode, I can still do a 3-axis servo cycle in 50 uS on a 333 
MHz Pentium-II.
You could do the servo cycle at 10 KHz and still have 50% of the CPU 
left over.
This INCLUDES all the digital I/O, both input and output, too, because 
they are
passed through the same bus.

>I think for many folks the bottleneck that drives them from
>pure software (step/dir out the parallel port) to a hardware
>solution, is stepper pulse rates, not the servo update rate.
>  
>
>
>Well... I was really referring to the software algorithms...
>  
>
>
>As I understand it, when running true servo, EMC runs the
>position loop only.  It gets position feedback (encoder
>counts) and outputs a velocity command, usually analog.
>Is this correct, or is the velocity loop in the software
>too, outputting a torque (current) command to the amps?
>  
>
It is position loop.  It could do velocity loop easily, deriving 
velocity from the
encoders.  One problem is that the velocity may need some smoothing, and the
smoothing gets worse the faster you sample, because you may get an encoder
count every 5 or 10 cycles.

>I think the interrupt latency under real time Linux is on the
>order of 5-25uS.  Negligable at 1KHz, but starting to be
>significant at at 20KHz where the total budget is 50uS.
>
My PPMC and USC boards have update timers on them that allow them to be
the source of the servo update rate.  They also latch the encoder count 
and send
the new velocity info to the DAC or rate generator.  That way, there is NO
software-induced timing jitter!  This is not used by the current version 
of EMC,
but it could be used quite easily.  You just have to substitute the 
interrupt vector
and let the RT scheduler know which interrupt you are supposed to be 
triggered
by.

Jon