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

[jmkasunich-at-ra.rockwell.com]

Craig Edwards wrote:

>>> Also, I prefer a non-volatile architecture, i.e. one
>>> which doesn't require a boot process during power up,
>>> but there is a cost trade-off with regard to SRAM based FPGAs.

>> In a PC environment, it might be possible to store the
>> FPGA program on disk, and completely eliminate programming
>> of PROMs or FPGAs during board >construction.
>> Maybe a little far-fetched, but it would be cool to be able
>> to download a new FPGA configuration and install it without
>> even opening the PC case.

> This is actually pretty common now....maybe you pioneered
> more than you thought..:)  But the way I'm currently thinking
> of implementing the PCI bridge (in the same FPGA as the rest
> of the logic), you would need to store the update code
> somewhere else on the board, then flash the FPGA.

> Or do partial flashes (which a few FPGAs provide)

Yuck - don't want to limit the FPGA choices to provice
in-system update.

> Or provide another update path like a JTAG port to USB,
> which I think is too much overhead.  I'll do what I
> can here, but I think the cost penalty for providing
> in-system update capability might not be worth it.

Agreed.

I'm already on record as preferring the bus interface to be a
different FPGA than the control functions, so the design can
be moved to other busses.  Splitting the interface off from
the control circuits would make in-system update reasonable,
otherwise it's just not worth the trouble.

I wanted to see roughly how many gates would be needed for
the control functions, to help understand the FPGA needs
and partitioning.  Here is what I came up with.  It's been
a while since I did this kind of counting, could someone
more familiar with gate counting check this please?

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.

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

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

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

Atmel AT40K series - AT40K10-2BQC - $28.23 <whew, got a breath>
This is also a 5V part.  Said to be VHDL & verilog compatible,
don't know what the tools cost.

Atmel also has a series of complex PLDs.  They top out at
about 6000 gates, but one part could probably handle 3-4 axis
of control hardware.  Basic tools are available for free.
A 5V, 6000 gate part in an 84 pin PLCC is $9.78.  I like
this option, since the parts can be socketed instead of
soldered.  Most folks might only need one, those running
hexapods or whatever could plug in a second part for more
axis.

Cypress DELTA 39K series - according to the text, these are
CPLDs that run from 15K to 200K gates.  The smallest part
listed is the CY39100V208B, at $67.95 for 100K gates.
I don't know what the 15K version costs.  Runs on 2.5-3.3V.

Cypress ULTRA 37000 series - these have gate counts up to
7700, so more than one would be needed.  The 7700 gate part
costs $32.34, so if a multi-part solution is acceptable,
the Atmel parts are much cheaper.  They are 5V.

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.

<personal aside>
If I were building my own project (as I intended to do
before this thread started), I would use several of the
Atmel parts.  I would use the ISA bus since I have several
PCs with ISA slots.  One device would implement the bus
interface, digital I/O interface, watchdog timer, etc.
Then I'd see how many axis I could fit in one chip, and
use as many chips as I need.  A development kit for the
Atmel parts is $99, includes basic design tools, a demo
board, and a programming cable.
<end personal aside>

>>> I think the 1KHz update rate is pretty arbitrary, with a
>>> 1GHz main processor and a PCI board I'd expect at least
>>> 10x better.

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

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

> but I think Jon's on the right track on his next post..:)

Jon knows a lot more about servo control than I do.  At
NAMES last year, I studied the schematic of his analog
servo amp, and was very impressed.

I couldn't quite follow his post - it implies changes a
special amplifier design, where I've been thinking along
the lines of something that works with standard amps or
drives.  Maybe we can cover both.

>>> Seems most of the higher end motion control boards claim
>>> at least a 20K update rate. Now providing that across 6
>>> or 8 axis might be a stretch...:)

>> I think Jon Elson has reported that he gets good results
>> at 1KHz servo updates.  Maybe 2KHz or 4KHz is better,
>> but is 20KHz really good for anything except specsmanship?
>> I'm talking about machine tool control here, not
>> pick-n-place machines or other high end motion control.

> Yep..specmanship it is....:)

So what should be a reasonable goal.  If 1KHz is the absolute
minimum, and 20KHz is far more than needed, should we be
aiming at 5KHz, or 10KHz?

>>> PWM is also a good option

>> Actually when I said PWM yesterday I was over-simplifying.
>> What I actually had in mind is PFM (Pulse Freqency Modulation).
>> The PFM waveform is _much_ easier to filter to a smooth analog
>> signal, or to put it another way, the filter bandwidth can be
>> much higher for the same amount of analog ripple.

>> What's really cool is the the PFM signal can be generated
>> by the same hardware circuitry that generates step and
>> direction pulse trains.

>> The drawing at:
>> http://home.att.net/~jekasunich/CNC_Output.gif
>> shows the circuit I have been planning to use for my
>> pulse generator, modified to include the PFM output
>> signal and the analog filter.

>> You can trade off analog resolution for update rate by
>> changing the time constant of the filter.

> Well, I think I agree....now that I understand your
> technique...:) I was concerned about loop BW as well,
> but I think this might be good enough.  This part of
> the board may be a good candidate to simulate, as I
> think we should insure that this solution can be used
> in applications that use the STG board currently.

I want to simulate the my filter circuit for frequency
response, delay, phase shift, etc.  A while back I
worked on a filter design that went inside a control
loop, where the goal was maximum rejection of out-of-
band signals with minimum phase shift on the desired
signal.  I need to dig up those results.  I hope I
still have them...

> I agree that a 20kHz update rate is way more than
> most small CNC machines require...and I'm not
> proposing to add much cost to achieve it.  BUT a
> faster update has to broaden the range of
> applications...and we are looking to improve on
> what is available currently...:)

We agree 100% here.  Increase update rate until it
starts driving the cost up, then stop.

>> Understood.  I think it's important not to lose sight of
>> the breakout board - as VLSI gets cheaper, the overall
>> cost is driven more and more by the interface to the
>> outside world.

>> Bus interface performance isn't that inportant.  Even
>> with a 20KHz update rate and 8 axis, the data rate is fairly low.

>> Total is 18 bytes each way, times 20KHz is 720,000 bytes per second.

>> With a more reasonable 4KHz update rate and 6 axis in use,
>> the total is 112,000 bytes per second.

> Oh I agree, speed per say is not the issue. Latency,
> probably....although it may be swamped by the real time
> software interrupt responses, etc.

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.

>>>> I'd like to propose a two board system.
>>>> Board #1 contains the bus interface and FPGA based hardware.

>>>> The connector to the I/O board would be a 60 pin ribbon cable
>>>> or some other high pin count connection.

>>> Hmm...this is a tough one... I definitely see the merits in
>>> a two board architecture, but I'm still not crazy about requiring the
>>> use of a big fat 60 pin cable, carrying all those discrete signals.

>> They have to become discrete signals eventually.  Ultimately you
>> will have 60 (or more) individual wires, coming from limit switches,
>> encoders, motor drives, >etc., scattered all over the machine.  Some
>> will be two conductor shielded twisted pairs, some will be 4 or 6
>> conductors, some will be individual wires. All >of them have to be
>> screwed into terminal blocks somewhere.

> I agree...but what I was concerned about was bringing all these
> different kinds of signals together into one cable..:).  Now,
> if the assumption is that everything is converted to "standard"
> TTL or CMOS and then drive the SCSI cable, that's better.

Yes, that's exactly what I had in mind.  Nothing but logic signals
in the cable.  Nothing but the FPGA(s) and possibly buffers on the
PC card, all the signal conditioning on the interface card.  Sorry
I didn't make that clear the first time.

> I suspect the only real tradeoff will be the additional cost of
> a cable / breakout board / separate housing, but most applications
> will no doubt make good use of it.

Almost all applications will need some kind of breakout board anyway.
This is the section of the circuit where everyone will want something
different, so a totally open, low tech design really works here.
In my case, I won't even need a housing for it - I intend to use a
single board PC, and it, as well as the breakout board, and the
motor drivers (geckos) will all be in one big housing.

> So I'm fine with using this as our baseline approach for now...
> if anyone has other suggestions going forward we can modify later.

Good!

>> The interface board and the FPGA board should always be
>> close together.

> AGREED...:)

> One closing thought on board #2, I'd like to consider a
> SIMPLE bus expander be included on it, the rational being
> that connectors / cables / FPGA pins are costly and we don't
> want to burden simple machine applications with functionality
> they won't use.... while at the same time there are applications
> that could use a lot of discrete I/O.  I'm thinking something
> like 4 address bits / plus an 8 bit data bus, separate I/O for
> simplicity (total of 24 lines). For simple apps a default
> address could be used, giving 8 lines each way.  Each axis
> would have to use dedicated lines, as John suggested previously,
> 4 lines per axis.  Ideally, I'd like to keep the total
> at under 50 pins (not there yet...), so other ideas are
> certainly welcome.

Excellent idea!  Why waste FPGA gates on simple input and output
ports.  Let the FPGA implement an expandable bus.  How about 8
data lines, 4 address lines, and read and write strobes?  In a
minimal system, the strobes, go directly to a '374 and a '244
for 8 bits of output and 8 bits of input.  Next step up, the
strobes go to a single '139, which can decode strobes for up
to 4 '374s and 4'244s, for 32 outputs and 32 inputs.  Finally,
a maximum system could use 2 to 4 '138s to decode up to 16 ports,
or 128 outputs and 128 inputs.  All with only 14 wires in the
cable.  The interface board has '138s, '139s, '244s, and '374s,
all commodity items that anybody will be able to buy for years
to come.

Revised cable pin count:

Outputs - 2 pins per axis, total 16
Feedback - 3 pins per axis (added index pulse), total 24
Digital I/O - multiplexed bus, total 14 pins
Master enable - from watchdog, 1 pin
Power and ground - +5, +12, -12, 5 pins

Total 60 pins.  If we use the 68 pin SCSI-3 cables, we can
have 8 more grounds, for better noise and crosstalk immunity.


John Kasunich