Is an FPGA the Best Option for High I/O (120-150 Input) Prototype?

An important question you did not answer; How are these components distributed relative to each other, and what is the environment, eg., lots of RFI from motors?

This sounds more like a job for microcontrollers located at each sensor connected together with a robust industrial bus, eg., CAN bus.

FPGAs are good for interfacing to devices with "weird" characteristics, or high-speed I/O. Your task sounds well-suited to multiple inexpensive microcontrollers.

Cheers,

Dave

--- Quote Start ---

An important question you did not answer; How are these components distributed relative to each other, and what is the environment, eg., lots of RFI from motors?

This sounds more like a job for microcontrollers located at each sensor connected together with a robust industrial bus, eg., CAN bus.

FPGAs are good for interfacing to devices with "weird" characteristics, or high-speed I/O. Your task sounds well-suited to multiple inexpensive microcontrollers.

Cheers,

Dave

--- Quote End ---

Thanks for the reply Dave...

So we are on the same page the prototype that I am currently working on is for an airplane ****pit. Once the prototype has been constructed (which is necessary before we can receive funding), we will then engage with a engineering / design company to redesign the prototype taking into account CASA regulations / electrical engineering standards, etc. for the harsh environment and fail safe requirements necessary for aviation.

One area I did not include details about are the driving of multiple LCD panels for display purposes within the ****pit but I don't envisage that this will affect the selection of components at this stage.

Mark

In my earlier post I didn't include the environmental factor... There will be a number of electronics close by that may affect the overall product such as LCD panels and power supplies but since this is a prototype, outside environmental influences will not play a role as it will be prototyped in a simulation environment and not a real ****pit.

Edit: For some reason my previous post did not come through so this reply may not have made sense. Does anyone know why the reply did not post to the board? I didn't receive an error. Although for some reason my words are being censored. It doesn't like my reference to aviation :-).

If it's a distributed system as Dave mentioned, yes probably microcontrollers are the way to go.

Otherwise, your favorite microcontroller and a CPLD for the I/O expansion will work very well together. An FPGA (with possibly a processor, and possibly external memories) sounds like overkill.

Regarding an "overly messy processing loop with a microcontroller based design", if you are more specific others can comment on how programmable logic can/can't help you out.

In regards to the messy processing loop based on a microcontroller design I see the processing loop working as follows;

Select Shift Register (LOW) PIN

Read Shift Register - CPI (MCP23017) (16 bits returned) - Interpret I/O based on attached component, in the case of Rotary Encoders I will be looking at multiple signals to determine what action to take

Deselect Shift Register (HIGH)

I have to repeat the above for the number of shift registers to read in approx 120 or so input pins which I don't have a problem with.

My concern is that for each shift operation this will take time and since there will be a number of rotary encoders, push button switches, 4-way hat switches, etc. that need to be read, some signals may get lost. I need the reading of each digital input to be reliable. The design will need to expanded in future iterations to take in more digital input (another 120 or so inputs) so the solution needs to scale.

The output of this device will be to take the "processed" signals and push them out to a microcontroller via serial / USB to perform the underlying action. When I refer to processed signals I am referring to the result of rotating a rotary encoder up or down (i.e. a counter) as opposed to simply pushing out the raw IO.

Just in case you don't know ...

An ARM LPC800 processor is about $1

http://www.mouser.com/search/refine.aspx?ntk=p_marcom&ntt=129633749

An MCP23017 shift-register is about $1

http://www.digikey.com/product-detail/en/mcp23017-e%2fsp/mcp23017-e%2fsp-nd/894272

I know, when you have a "hammer" all problems look like "nails".

But processing is cheap now. You can program your LPC800 to act "dumb", but it can still be smarter than a shift-register :)

Cheers,

Dave

Hi Dave... I knew about Shift Registers but didn't realise how cheap the ARM processor is in comparison.

Just so I am clear (and on the right track), are you alluding to the use of multiple processors (as a slave) to increase my IO count and then connecting them all to a master microcontroller? I didn't think of that...

If so, what technique would you use to bring them all together? I am just looking for a general concept and I can google the info.

--- Quote Start ---

Just so I am clear (and on the right track), are you alluding to the use of multiple processors (as a slave) to increase my IO count and then connecting them all to a master microcontroller? I didn't think of that...

If so, what technique would you use to bring them all together? I am just looking for a general concept and I can google the info.

--- Quote End ---

Do you own a car? All of the sensors in that car are connected via CAN bus (and some other buses). You can daisy chain multiple devices off a CAN bus, so its a little nicer than Ethernet, as you do not need an Ethernet switch.

What type of signal does your rotary encoder output? I've interfaced to Heidenhain encoders before with FPGAs. But their interface is essentially a synchronous serial interface, which I am sure a microcontroller could handle.

Think of your microcontroller as a bridge device. Lets say you want every sensor to look "the same" to your control system, eg., it looks like a CAN node, or a USB device, or an Ethernet device. Once you have written the code to create a CAN bus rotary encoder node, and a GPIO node, you can write the control software to talk to "CAN nodes" in general, i.e., the high-level code becomes simple (typically command and response packets, just like you would use when two ethernet devices communicate). Splitting a big problem into lots of small problems with well defined interface makes the task much easier to solve.

If you are reading encoders because something has to be in a particular position, then a distributed architecture might help simplify your software, eg., high-level control system sends command "go to <angle>" the CAN bus rotary encoder module then turns on a motor until the encoder reading is correct. All of the CAN nodes can report data at a fixed rate, eg., every 0.5s. Your control system can capture those monitor points and store them to a database.

Note: I'm only mentioned CAN bus because we happen to use hundreds of nodes on radio telescopes and it works well (with completely brain-dead microcontroller - ARM devices are much nicer).

You can easily create a high-level control system written in Python to talk to your cheap little microcontrollers, eg., I just Googled Raspberry PI and CAN and there are several options, and BeagleBone and CAN also generates several hits. I'm sure there are similar open-source boards that already have CAN bus - I think a lot of the NXP boards probably do - oh and maybe the Atmel ... yep ...

http://www.atmel.com/products/microcontrollers/arm/sama5.aspx

https://eewiki.net/display/linuxonarm/sama5d3

http://www.digikey.com/product-search/en?vendor=0&keywords=atsama5d3-xpld

I could not come up with an excuse for buying one of these ATSAMA5D3-XPLD kits ... but maybe you can have fun with one :)

That being said, I love solving problems with FPGAs too! Your problem just doesn't sound like it needs custom HDL, it sounds like a microcontroller problem.

My recommended FPGA solution would probably be to use a MAX 10 device. I just purchased a couple of the BeMicro-MAX10 kits;

http://parts.arrow.com/item/detail/arrow-development-tools/bemicromax10

Your DE-nano will be fine for development if you decide an FPGA is the way to go.

Could you please provide more details on what it is you are building. That will help readers continue to offer advice.

Cheers,

Dave