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

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

jmkasunich-at-ra.rockwell.com wrote:

>  
>
>>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.
>>    
>>
>
>Ouch!  Do you have any idea where I went wrong?  Using
>your 4-encoder board for example, you have ~2500 gates
>per encoder counter, and I got 580.  Are we comparing
>apples to apples - 16 bit counter with capture register
>and quadrature decoder?
>
Oh, no, I am using a 24-bit counter, and it has a digital filter to 
prevent illegal
state transitions.  I used a 24-bit counter mostly because EMC already has
rollover logic for a 24-bit counter, and that logic is not at the lowest 
driver
level.  580 gates is awfully optimistic if the logic is dedicated per axis.
This worked out well enough I had no need to explore multiplexing the
logic and just having a couple of storage registers dedicated to each axis.
I also have a 24-bit latch register for each axis that is latched 
simultaneously
for all 4 axes.  So, there's really 48 bits of latches or counters for 
each axis.

>  I just don't understand how the
>gate counts for the individual circuits can get so high.
>Unless it's routing limited.  IIRC, when I was doing
>Xilinx stuff years ago, routing was the limiting factor.
>  
>
Well, their routing is pretty good, on the Spartan series, for these 
type of circuits.
If you want, the tools will literally let you wire the chip up one 
signal at a time.
(No way I want to do this.)  But, taking into account the complexities 
mentioned above,
you may see why I need more gates.  there is a common bus interface and an
interrupt timer on the encoder chip, but they don't add up to that much.

The latch is really necessary to hold a valid sample until the CPU can 
read it.
You could do other ways to get guaranteed valid samples for one axis at a
time, but all the pros have some sort of simultaneous sampling of all 
the axes.

>>  I've seen some MSI
>>"TTL" PCI interfaces that were only about 5 74AHCxxx ICs.
>>Mostly, an address comparator and 74AHC374's.
>>    
>>
>
>This is the first I've ever heard of a "simple" PCI interface.
>Any links where I could look further, or should I just start
>googling?
>
Yes, I saw some of these years ago, I have serious doubts that they 
would work
reliably on PCI 66 MHz systems, for instance.  I'm sure I didn't keep 
links to them.

>All we really need is the ability to read and write a few
>dozen 8 or 16 bit registers.  DMA, bus mastering, and so on
>are ridiculous for this application.
>  
>
Right.  the LSI PCI thing was to read switches and latch a byte and show 
it on LEDs.
But, it probably could do more than that.

>>>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.
>>    
>>
>
>You obviously know where to buy small quantities of more
>modern Xilinx parts.  What's the secret?
>  
>
I now buy a lot of it through http://www.usbid.com/ . You have to join 
them, with
some restrictions.  But, you can make a bid on a pile of stock sitting 
on some
distributor's shelf.  Digi-Key will actually order modest quantities of 
Xilinx
parts they don't list in the catalog, but some of the minimums are too 
high for me.
I think Arrow and Marshall have stock, too.

>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!
>>    
>>
>
>I'm aware of that technique, that's why I assumed the
>encoder counters would have capture registers.  A single
>hardware signal would capture all encoder values at once.
>
>  
>
>>This is not used by the current version of EMC,
>>    
>>
>
>I didn't know that.
>
Well, let me clarify.  EMC DOES latch all axes at the same time, but it 
doesn't
latch it on order of a hardware clock.  The first couple instructions in the
real-time task trip the latch (and simultaneously update all DAC or rate gen
velocity commands on my boards).

>
>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.
>  
>
>
>For ParPort interfaces I assume that is IRQ 7 or 5?
>  
>
Well, whatever you can set your motherboard hardware to.

Jon