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

["Craig Edwards" <cedwards-at-ceinetworks.com>]

Just a few quick comments...
Craig

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


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


There are several options I'll continue to look into with regard to system
partitioning, but my "baseline" is still a single FPGA...with approx 75 to
100k "effective" gates.  As I'm sure you're aware, "gates" is a pretty
imprecise term when used with FPGAs, because of many can't be used,
depending upon granularity of architecture, routing limitations, etc.  Yes,
a full 32 bit target implementation takes a lot of gates, at least 18K-20k,
depending on whose terminology you use.  But based on my preliminary
research, it's still the most cost effective route for us to pursue. But
I'll continue to review the trades as we get the spec flushed out.  Of
course, no reason that different implementations couldn't be developed, even
for PCI...:)



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


I'd like to optimize here as much as we can here, I believe this area offers
the most "room for improvement" compared to what is currently available to
the hobbyist.  Jon's post outlining an on-board timer that sets the update
rate is a good direction to pursue, really starts to address the software
integration issues that I'd like to try to contribute to.  We need to talk
with the Jon, NIST software architects, ect, with a whiteboard to make fast
progress in this area. Yes, I think we really have to support existing
analog servo amps....just too many good deals on surplus stuff.



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

I'm fine with a bi-directional bus, but need a mechanism to handle who is
driving the bus...just a little more complexity I think. I'm traveling for
the next 3 days or so, but I'll try to start a spreadsheet where we can
capture things like I/O , functional blocks, and estimated gate counts.  Is
there a place to conveniently post such a document?  Actually, I was
thinking of putting up a web page (as I have a hosting service that I'm
already paying for...), but just haven't taken the time to do so.  Any
thoughts or preferences?

Craig