02-21-2017 01:13 AM
For a graduation project i have to find a solution for a frequent hardware redesign needed for an IO-module in a CAN-bus network.
I've already a bit experience with FPGA's (zynq,spartan).
This IO-PCB communicates over a can-bus with a cpu-module (HUI, control panel).The IO-PCB can contain analog and digital in- and outputs to read sensor data, switch motors on and off etc. It can also provide Modbus, dali, profinet, etc interfaces. The company which produces this PCB has to redesign the PCB for different needs, like 5 digital inputs, 2 analog outputs, 1 analog input, etc.
I was thinking of a solution for this with a Xilinx FPGA, to configure the IO pins for different needs. Then only a small amount of additional HW is needed for voltage level conversion, galvanic isolation, etc. This HW can be added on.
How do you guys think about such a solution? would it be wise to use an artrix 7 to use the XADC or is the stellamar all-digital adc an option?
Regards and thanks for your idea's!
02-22-2017 04:46 PM
It's a nice idea, and one that I've considered in the past, but unfortunately I've never found a good way to do it. The problem is essentially that all those interfaces have very different demands.
For analogue input signals, you're normally looking at relatively low speeds (eg. 100kHz). Getting rid of noise in the signal is essential, so having a small analogue filter (or even just a capacitor near the pin) is common. Signals don't have to be perfectly synchronized with each other, so using one fast ADC multiplexed between ten signals is common. Level conversion demands can be substantial (since analogue equipment can often output negative voltages, or very high voltages, or its range can be down in the uV region which requires amplification). This calls for flexible analogue level shifting.
For analogue output signals, you're normally driving level-sensitive loads. No need for fast edges, no need for super-accurate timing. And, of course, analogue outputs can sometimes be current-mode, sometimes voltage-mode, and either can be at (relatively) huge currents (100mA would be reasonable for many loads).
For digital input signals, you're handling very high speeds - 10MHz is common even for microcontrollers on SPI. Reading a 10MHz SPI signal requires that you're sampling the SPI clock and data lines simultaneously at over 20MHz, and preferably much higher. Filtering of the signal is a bad thing; both will slow down the edges. The only thing you want on the input line is a high-speed digital level converter. This won't work as an analogue level converter, and the analogue one probably won't be quick enough for digital signals.
For digital output signals, you're again handling high speeds, and you do need fast edges. The only thing you want on this line is a high-speed digital level converter. Depending on the interface you may want pull-up or pull-down resistors. If you're generating this signal with a DAC, it'll have to be very fast - you need to be able to generate edges that are synchronized to an incoming clock signal (eg. for an SPI slave).
What you're left with is either:
(1) A pin connected to both a very fast ADC and a very fast DAC, without analogue filtering (because that'd mess up the digital signals) but with very fast analogue level converters, plus a bunch of logic in the FPGA to convert between the analogue values and binary data.
(2) A pin connected to a normal ADC and a normal DAC, both with analogue filters and level converters, as well as a digital I/O pin through a high-speed bidirectional level converter. Probably with an analogue switch to select which one is actually connected.
In either case, every external pin requires a lot of pins on the FPGA, and a lot of circuitry.
I would suggest that a better approach is to just have a plug that makes a bunch of analogue unidirectional I/O and digital bidirectional I/O available - maybe ten of each type for 30 pins total. A 10-input ADC is easy; the XADC can handle that. A 10-output DAC is also fairly easy. 10 digital I/O pins are trivial, and on an FPGA each pin can implement just about any interface you want. If necessary you can break out a few extra digital pins for LVDS, and a few more for ultra-high-speed LVDS; these require special treatment on the PCB and in the connector. For "tricky" interface (eg. CANbus, which demands its own transceiver to handle the odd bus voltages) you may have dedicated pins. Then selection of protocols is done by wiring up the plug to connect external devices to appropriate pins. Since adding a new external device will tend to require rewiring that plug anyway (to add the wires for that device) the need to wire up suitable connections isn't really a problem.
03-02-2017 12:04 AM
Thank you for your ideas.
i was thinking of a (simpler) solution were the hardware needed for the different purposes can be added on later as a sandwich PCB.
But, because FPGA's are a lot more expensive than a micro-controller, would it be wise to still use a FPGA instead of a micro-controller?
03-02-2017 03:44 AM
Ah, now that's an interesting idea. I can see a sandwich PCB working nicely. It means you can have one fairly expensive PCB that holds the processor/FPGA and the commonly-used interfaces, and add-on PCBs for any really odd interfaces that get added later.
It looks like a microcontroller would be adequate for this task. If it's sending data over CANbus then your maximum data rate is pretty limited anyway; the performance advantages of FPGAs (like being able to process a billion ADC samples per second) won't be relevant (*). As far as I can tell, an STM32 microcontroller could do your Dali and Modbus interfaces, and Profinet can be done via an adapter on the ethernet line. This will require a fairly high-end microcontroller (eg. an STM32F4 or F7) but it's still nowhere near as expensive or as complex as an FPGA.
(*) Depends on how much processing you want. If the task is one where the controller would take a very large amount of data and turn it into a small amount of data to be sent over CANbus then an FPGA could be very worthwhile. For example, an FPGA might read in pixels from a camera at 50MHz and locate objects in the image, then send just a few bytes of object positions to the host device. However, it seems more likely that the microcontroller/FPGA here would just be an interface-conversion chip, so the maximum data rate would be pretty low.