Logi-Pi board availability?

For your encoder type application pretty much any FPGA would do - possibly even an ICE40.

As Roger has suggested the video application is a different cup of tea altogether.

The Digilent ARTY board is  a good way to get your hands on a decent modern FPGA with on board DDRAM at a reasonable price ($99)

The ARTYZ7 ($209) gets you a processor closely coupled with an FPGA and makes that video dream a bit more of a possibility.

Arty Z7: APSoC Zynq-7000 Development Board for Makers and Hobbyists - Digilent

These chips are demanding in terms of development effort and knowledge.

I'm not sure why you think the Lattice tool chain is a better long term solution than Xilinx (or Altera).

I've used Lattice parts for the last 10 years although I started with Xilinx when the very first FPGA s appeared. (I do mean first - the ones with 64 logic elements !!). I've recently started using Xilinx again and IMO the Vivado tool chain is streets ahead of Lattice's.

For simple stuff it doesn't matter but for integrating FPGA, processors, DDRAM etc it does.

MK

MK. Very helpful info. I wasn't aware of the ARTYZ7 board. It also appears the Vivado tool has a free version that could be used here in the beginning. I'm going to look into this in more detail.

Interesting to note that Digilent is owned by National Instruments. They make the single-board RIOs for NI (sbRIO). What's really interesting is that NI doesn't like to talk about Digilent or sbRIOs for that matter. I think they are in a quandary on how to protect their more expensive cRIO products. They also have a lot invested in the LabView-to-fpga tools, which work most of the time but can be flaky on some days.

Thanks again for your input. Very helpful.

dan luttrell wrote:

 

. One approach that may work is to use the RPi for capturing images from a camera and then feed the needed arrays to the fpga for fast processing (filtering, peak detection and perhaps a few other things).

IMHO, if you have a 50ms repetition rate, "filtering, finding the peak and perhaps a few other things" is something you can and should do in software. Bouncing the data back and forth to the FPGA is going to be a hassle, and probably not any faster. The FPGA will be able to do these things in say a microsecond, getting the data there and back is likely to cost WAY more... But you're waiting 50 miliseconds for the next frame anyway. I'd say that taking a milisecond to do things in software should also work. But I don't have your complete project parameters....

What you COULD consider is to get a DE-NANO-SOC. Dual core ARM running Linux for the high-level stuff, and... All that runs on the FPGA. The FPGA has access to main memory, the FPGA has private memory, and you could add a special function peripheral to the ARM to do exactly what you need. I think there is also a camera module for the DE- series.

Oh. One thing I forgot to say before: Handling an encoder signal at several MHz is not really a problem. A $2 STM32 can do that. But is your encoder that fast? I've only looked at one datasheet so far, and it mentioned a maximum frequency of 100kHz. So double check that you have encoders that are faster than mine... :-)

The encoders are indeed that fast, actually faster. Each individual signal (A, /A, B, /B) can be up to 10 MHz from the encoder read-head. It uses the RS422 signal format. These are buffered with a receiver chip that generates a single 3.3V signal for each channel.

These are very high resolution encoders with single nanometer resolution. It doesn't take a high speed motion to generate a lot of pulses. For example:

http://www.mgscale.com/mgs/language/english/product/BH25.html

VIONiCplus incremental encoder system with RSLM linear scale

The tightly integrated DE-NANO-SOC looks interesting. It's always worked out well to have more speed and computing capability than initially thought. Something always comes up later to push the capabilities beyond what we ever thought we would need. I have to keep reminding myself of this.

Much as I love FPGAs, if I were doing image processing I'd take a serious look at programming RasPi's GPU (VideoCore IV).  Broadcom released the architectural spec in 2015 -- I think it's still the only GPU that has done that: Broadcom releasing VideoCore IV GPU documentation!

As I recall from the VideoCore IV document, it's basically a modified-SIMD architecture similar to a number of 20th Century supercomputers, but at a tiny fraction of the cost and power consumption.  I don't know how difficult it is in practice to download and use VideoCore IV software.

They might be exaggerating when they claim a resolution of 0.3 the size of a hydrogen atom.

Actually, that resolution is real, and it is sometimes interpolated down to less than that. Ultra-precision motion systems can make coordinated multi-axis moves with following errors in the single-digit nanometer range (velocities are fairly slow). The fine resolution is especially important for deriving velocity and acceleration. Current control systems use an ASIC to read and interpolate these encoders. I'm looking for flexibility beyond what the ASIC offers.