Low-end FPGA selection help

[mtwieg]

Hi All, going to try and describe things without revealing too much about the application.

Basically a board receives a logic input (call it A) from a host system. A is distributed to 16 outputs which drive some circuits, let's call the outputs Y[15:0]. In normal operation, all the Y outputs are just equal to A, so none of the bits of Y are independent. But for self-testing purposes, we need to make these outputs somewhat independent, which will require some logic in between.

Basically what I want is to configure each Y bit to select A, ~A, 0, or 1. One way to do this with off-the-shelf devices is to have each Y come from a multiplexer (can be implemented with a 1G57 logic gate), each of which requires two control bits. These control bits would come from a GPIO expander (so need 32 bits to support 16 outputs). Our board already has an I2C interface to the host system, and the reconfiguration doesn't have to be fast, so I2C provides a convenient interface for the GPIO expander. See attached diagram (hoping attachment works...).

But even if we use a single logic gate for each output, that's a lot of board space and components. And we may need to scale to more outputs. I'm looking to replace the whole thing with a CPLD/FPGA, but I'm not very familiar with low-end options.

One big caveat for this application is that this board contains extremely sensitive  broadband RF receivers (can't get into specifics here), so RFI generated by an FPGA is a big concern. I'm fairly sure that even low-end FPGAs have internal oscillators and logic which operates in the background to support certain features (configuration, initialization, debugging, etc). Would be ideal if we could feed the FPGA an additional signal (call it IDLE) which would disable as much of this as possible. So when we need to update the control bits via I2C we would first de-assert IDLE. Then before running the tests we would assert IDLE, which would disable as much as possible while leaving the required combination logic functioning. Repeat as necessary.

Obviously the amount of RFI we see from the FPGA will depend on numerous factors outside of the FPGA itself, but I'm trying to at least select parts which get close to this sort of behavior. This sort of stuff is always buried deep in documentation (or not provided at all). For example, I was looking at the Igloo Nano, and it mentions an "Idle" mode which can be entered by just halting external clock sources. Sounds great, but it doesn't seem to describe what happens to its internal oscillators or the circuitry they clock. Just hoping for some general tips.

Also a few other specifications about the application/fpga:
The logic input A is not very fast, minimum pulse width is maybe 500ns. A few tens of nanoseconds of skew/delay on the Y outputs won't matter.
Being able to update the firmware via that same I2C interface would be nice, but isn't a requirement
FPGA configuration can be stored either in FPGA NVM (i.e. MAX10) or in an external memory (i.e. cyclone)
QFP/QFN footprints would be nice, but BGA is an option too (min pitch 0.65mm though)

[woofy]

Are you sure an fpga is the best fit here? There are low cost fpga's with an i"c interface such as some of the ice40 range. However from what you have said I would probably choose a micro-controller. Something like the PIC16LF15356 and use the clc to route the input through to the 16 outputs. It will do this without cpu intervention so just propagation delay from inputs to outputs. The cpu can receive the i2c and perform your test mode commands when required, otherwise it can sleep.

[SiliconWizard]

I would suggest the Lattice MachXO2 for this. The -256 variant would be more than enough, it's relatively cheap, has internal Flash (so no need for an external Flash chip, and boots up very fast), and has a standby mode that shuts off most of its internals.

[mtwieg]

Are you sure an fpga is the best fit here? There are low cost fpga's with an i"c interface such as some of the ice40 range. However from what you have said I would probably choose a micro-controller. Something like the PIC16LF15356 and use the clc to route the input through to the 16 outputs. It will do this without cpu intervention so just propagation delay from inputs to outputs. The cpu can receive the i2c and perform your test mode commands when required, otherwise it can sleep.

A MCU with some configurable combination logic peripheral like the CLC would also suit our needs (assuming it can power down enough to avoid the RFI concern). Just skimming over Microchip's pic16 offering and it seems like each CLC has just one output, and the max per device is 8, so wouldn't meet our current need... but it wouldn't surprise me if there are similar solutions in other MCU families.

edit: Actually one MCU that might be perfect is the PSoC devices from Cypress. PSoC 5LP should have plenty of configurable logic, maybe PSoC 4 as well. I've actually used PSoC 5LP recently, can't believe I forgot about it...

I would suggest the Lattice MachXO2 for this. The -256 variant would be more than enough, it's relatively cheap, has internal Flash (so no need for an external Flash chip, and boots up very fast), and has a standby mode that shuts off most of its internals.

Yes, machxo2 was one series I was looking at (also ice40 Ultra like woofy mentioned, and Igloo Nano and Trion). The machxo2 has an internal high frequency oscillator, but the datasheet says "The on-chip oscillator has two power saving features. It may be switched off if it is not needed in your design. It can also be turned off in Standby mode." Could be a great fit, but I need to do more reading on the Standby mode.

[Someone]

One big caveat for this application is that this board contains extremely sensitive  broadband RF receivers (can't get into specifics here), so RFI generated by an FPGA is a big concern. I'm fairly sure that even low-end FPGAs have internal oscillators and logic which operates in the background to support certain features (configuration, initialization, debugging, etc).

Most (all?) FPGAs will let you design them without using any on board oscillators, you could clock everything from the I2C interface (just as many I2C chips do).

Equally there are simplifications for the logic, a BGA 1G99 will do all the logic needed for each channel + your choice of I2C decoder. Avoid FPGAs unless you really need some specific feature of them, a CPLD would likely be more appropriate for this scope.

[woofy]

A MCU with some configurable combination logic peripheral like the CLC would also suit our needs (assuming it can power down enough to avoid the RFI concern). Just skimming over Microchip's pic16 offering and it seems like each CLC has just one output, and the max per device is 8, so wouldn't meet our current need... but it wouldn't surprise me if there are similar solutions in other MCU families.

edit: Actually one MCU that might be perfect is the PSoC devices from Cypress. PSoC 5LP should have plenty of configurable logic, maybe PSoC 4 as well. I've actually used PSoC 5LP recently, can't believe I forgot about it...

You may only need one CLC. The PPS output signal routing is port based with each pin selecting the signal source. PortC can select any of the CLC's. PortA also can select from CLC1&2, PortB from CLC3&4. So one CLC could be enough or two will cover the whole chip.
Psoc should work too, but I've never used them other than a brief play on a dev board.

[asmi]

Most (all?) FPGAs will let you design them without using any on board oscillators

That doesn't neccessarily means they will be shut down. I mean, one would think that they will be - but that's not a guarantee. For example, I don't remember reading anywhere in Xilinx 7 series FPGA docs that config oscillator will be shut off once config is complete.

Equally there are simplifications for the logic, a BGA 1G99 will do all the logic needed for each channel + your choice of I2C decoder. Avoid FPGAs unless you really need some specific feature of them, a CPLD would likely be more appropriate for this scope.

+1
The only thing about logic - which may or may not be relevant here - is to balance it for all outputs if possible to ensure they all switch at the same time (or as close to that as practically possible).

[mtwieg]

Most (all?) FPGAs will let you design them without using any on board oscillators, you could clock everything from the I2C interface (just as many I2C chips do).

I'm sure they'll let you choose how to clock your own logic, but for low-level system tasks (power sequencing, reconfiguration/reset handling, PLL monitoring, etc) I suspect these use internally generated clocks which the user may not have control over (without also disabling those important functions, anyways).

Equally there are simplifications for the logic, a BGA 1G99 will do all the logic needed for each channel + your choice of I2C decoder.

Right, this is the concept I outlined in my diagram. It just scales poorly.

Avoid FPGAs unless you really need some specific feature of them, a CPLD would likely be more appropriate for this scope.

Yes a CPLD would be fine for this, but AFAIK they're extremely hard to source right now. I'm open to suggestions on specific CPLDs though.

You may only need one CLC. The PPS output signal routing is port based with each pin selecting the signal source. PortC can select any of the CLC's. PortA also can select from CLC1&2, PortB from CLC3&4. So one CLC could be enough or two will cover the whole chip.

Hmm I think I see what you mean. It means losing some flexibility, but it might still cover our needs. I'd have to draw out the specific set of configurations we'd require and confirm that this scheme can support them.

Psoc should work too, but I've never used them other than a brief play on a dev board.

I just made a PSoC creator project to check, and supporting 16 outputs would require just 17% of its UDB resources, so the configurable logic side is definitely sufficient. Just comes down to whether it can be put in a state that reduces its RFI enough...

That doesn't neccessarily means they will be shut down. I mean, one would think that they will be - but that's not a guarantee. For example, I don't remember reading anywhere in Xilinx 7 series FPGA docs that config oscillator will be shut off once config is complete.

In some of the documents I've read (I forget about which device) it said the you can "disable" some internally generated clocks, but later states that you're gating the clocks output, not disabling the oscillator itself.

Disabling all clocks would reduce the the device to a state where it has to bootstrap itself from sleep using only asynchronous logic. Not impossible, but if I were designing an FPGA I would definitely want that secret always-on oscillator.

[asmi]

I just thought of something - have you considered using some parallel EEPROM as a LUT? Although at 16+1 address lines that can get kind of expensive, and it adds some latency for memory access, but still, it's a rather cool idea

[mtwieg]

I just thought of something - have you considered using some parallel EEPROM as a LUT? Although at 16+1 address lines that can get kind of expensive, and it adds some latency for memory access, but still, it's a rather cool idea

In principle yeah a parallel EEPROM would work fine as an LUT. But that would just replace the combinational logic gates, I'd still need a separate device to generate its inputs (the address lines, I guess). I'm curious though, never worked with a parallel EEPROM, what part would you suggest?

[woofy]

Unless I've missed something, its 32+1 address lines isn't it? Two each for the 16 muxes.
If so that's an 8.5GBx16 EEPROM. Hmmn!

I still think a cheap PIC with CLC is the way to go.

[c64]

Use CPLD
Something like ATF1508 i believe is available
Or can probably use bunch of ATF22v10?

What is your VCC?

[dobsonr741]

Yes, Vcc and propagation delay would drive the selection. Board space allowance would be nice to know, too. And your tolerance of parts availability on long term.

[Mario87]

If you are heavily concerned with RF interference then you should be shielding the electronics to mitigate any radiated emissions and designing in filters to mitigate conducted emissions which can become radiated.

I would not solely rely on a device going to sleep to eliminate your EMI concerns on this project.