Low end CPLD/FPGA for switching interlock design

We are working on an interlock circuit where we’d like to use a FPGA/CPLD in combination with a MCU to in a switching circuit. The basic requirement is that both switches can’t be on at the same time, so the FPGA will enforce the timing such that switch X has to be off for z amount of time before switch Y can be turned on. Basically the MCU and FPGA would have to agree before a switch could be turned on to reduce the possibility that both switches could be turned on at the same time.

Some things that seem nice to have:

  • instant on would be nice, but not sure if absolutely required
  • enough logic to implement a few counters and some simple logic
  • be re-programmable in-system so we can change the operation if needed

Years ago, we used Xilnix CPLDs in applications like this. Still seems like it might be a reasonable option as they have 3.3V power (better noise immunity), etc.

Does anyone have any suggestions? I’ve been out of the FPGA design space for quite a few years, so likely not current on what is available.

You might consider the ICE40 series for something like this – very small, low power, and low cost. 3.3v IO banks are supported, and there is a good free and open-source synthesis toolchain for the ICE40s. Bitstreams can be loaded from internal OTP, external SPI flash, or over SPI from an MCU host (likely what you want to do here).

The Ice Breaker is a good reference board for development (and was a good reference for me when I built this board):

If you want to build a single prototype in 2021, probably do not use ICE40.

You may want to have a look at Efinix or Gowin. Both are new FPGA companies with small devices. I don’t know of many fresh CPLDs.

Dialog GreenPAK might be sufficient for your needs. I’m in love with GreenPAK at the moment for miniaturizing glue logic. You should check it out.

1 Like

Very good point! I forgot about these but they are a good option.

Why not use 2 schmitt triggers and 6 discrete components instead of an FPGA?

Or add Class B code to the microcontroller and let it handle the switching…

Hi Cliff,
In addition to the FPGA suggestions mentioned so far, I would suggest considering the CCL (Configurable Custom Logic) peripheral of the new ATtiny series from Microchip. The ATtinyxx16 and xx17 series have this peripheral as well as some others in the ATtiny family. The CCL has a software defined logic lookup table as well as various logic building blocks which could be programmed to perform what you’re suggesting. The CCL can use inputs from and send outputs to the event system, so the CCL peripheral can operate asynchronously from your main code paths. You could for example connect the compare match output of a timer to an event system channel, and the use this even system channel as an input to the CCL. If you want a “hardware” counter, you can use the event system to clock TCA of the Attiny.

Thanks for all the ideas – learning about a many parts that I did not know about.

What are your reasons for this? Some of these parts seem well stocked at Digikey, but maybe that won’t last.

This is what has been done in the past, but we want the ability to change the timing (be reprogramming the logic device in system) if needed. The discrete component approach fixes the timing and requires rework if anything needs to change.

That is an option, but we would really like to have two devices involved so there is little chance of failure if one device fails. There are relays and other high power devices switching close by, so potential for noise. We could use two MCUs …

Very interesting!

Seems like a very good fit as we could no doubt leverage the mixed signal functionality.

Why is Lattice so popular these days with the open toolchain projects?

Quicklogic has embraced the open tools, but it seems their parts are hard to find and seem to be putting all their focus on the EOS MCU/FPGA parts.

Also, is there a good forum for FPGA discussions?

I guess I’m specifically speaking about my issues sourcing ICE40HX8K but my understanding was that across the board Lattice had LT issues like most vendors these days. If there is digikey stock then maybe you are ok, just be sure to buy 6-12 months of rolling inventory in advance.

I have used Xilinx CPLDs to do exactly this operation. (In my case dynamic shoot-through current tuning in a high switching frequency H-Bridge )

Some of the lattice parts are low pin count and SRAM based and are easily loaded. However, sometimes the IO are in weird states during configuration and you may have to have external logic to still ensure the switches are not ever in an invalid state. It is always good to triple check w/ the FPGA. When designing with SRAM based FPGAs, it is something I always look out for.

NXP MCUs have a peripheral called a “state configurable timer.” I have done very similar things with the SCT without needing external logic. Might be something to look into.

Do you know offhand how the GreenPAK does in regards to noise immunity – say compared to an STM32 MCU? This design has several relays switching 20-40 AMPs, so ideally we’d something that is fairly noise immune to implement watchdog type functionality for the main MCU.

Check out the darasheet for the Greenpak. Only 1mA input current seems to indicate the latchup level

New STM32 has 100mA latchup

If that is right, then STM32 is much more reliable

Dialog responded on their support forum with this comment:

Thanks for reaching out. We donot have any data regarding noise immunity but GPAKs overall are better than MCUs in most cases. GPAKs are currently being used in many safety circuits. The reason being GPAKs consist of a set of HW blocks while MCUs mainly depend on clock and SW implementation.

Seems a little dubious

I looked up the GPAK again. It has 1mA latchup current

An example, STM32F and STM32G has 5mA. So most MCUs are probably more noise immune than the Greenpak

About noise immunity, it only comes into play if you have noise at the device, so that depends on how external stimuli is handled, how noise is attenuated.

A good ground plane to make sure you have no voltage gradient over the plane, and good filters on relevant IO, diverted away to ground

Thanks for all the input on the Greenpak.