Feature request: Programmable logic

[LVan .31]

I am a fan of STM32, especially the peripheral sets offered are great. Over the years however, one type of peripheral is missing which would be a great help for many projects, this is a programmable logic cell.

Such a cell would contain elements like Flip-Flops, Look Up Tables and such that can be configured for specific functions. For instance using the LUT's, it would be possible to create all kinds of logic operations like AND, OR, XOR gates.

Using the Flip-Flops, I would be able for instance to create a clock gate, which I needed in my last project. There I needed an external clock signal to propagate to other peripherals and be able to enable/disable this. In the end I manage to create this function with a timer but this unfortunately generates something like 9 clock cycles of latency limiting the maximum frequency of the external clock signal. A basic Flip-Flop solution would probably introduce a much smaller latency.

Competing products offer this kind of functionality more and more, for instance the Microchip SAMD51 offers a Custom Logic cell which is highly programmable.

Such a peripheral would offer inputs and outputs that can be connected to other peripherals (GPIO, Timers and so on). Here I do see an issue since the Peripheral Interconnect of STM32 is not quite generic but very specific for the different types of peripheral. Another consideration would be to add so called hardware event channels to the STM32 which allow connecting almost any peripheral event output to another peripheral event input.

Well forgive me for starting to design, just adding the programmable logic would be really great for many control oriented applications.

[Andrew Neil]

---

@Tesla DeLorean wrote:

There was Actel SmartFusion too, and that got swallowed up by Microchip..

---

Remember them, too - looked at as a replacement for Triscend after Xilinx killed them.

---

@Tesla DeLorean wrote:

the problem is finding the ideal fit, nobody is going to be satisfied, either it's too limited or too complicated.

---

Indeed.

Having worked with both Triscend and WSI, one thing I observed was that very few people could grasp the concept: 

• The "software" people couldn't understand the "hardware/logic" part;
• The "hardware/logic" people couldn't understand the "software" part.

But bringing the two together is fundamental to this type of product.

That's how I ended up writing that Keil App Note!

[waclawek.jan]

Whatever - small programmable logic, better interconnects (and boy are there possibilities there!), better GPIO, micro-programmable IPs. But, please, pretty please, provide adequate documentation.

Enter Cypress (this week Infineon) PSoC. I exerted some honest effort to get a grasp of their capabilities, without attempting to get the tools going. My final impression was, that the documentation is deliberately inadequate and one is supposed to click.

I had a similar impression while working with the Waferscale chips back then, luckily that was just an EPROM/FLASH+RAM+2 GALs and luckily it was not me who had to get it going.

And my colleagues working with FPGAs confirm that that's the general approach in the realm of programmable logic. The user is deemed to be too *** to be worthy of the grand ideas hidden in the chip, delivered to him through some multigigabyte magic. Just code up some verilog, drink a coffee or two until it synthesizes, and it either fits or not.

As if we'd have for STM32 CubeMX and the DS, without RM.

I hate that approach.

JW

PS. [bragging mode on] Wrote jedec bitstream for GALs manually back then. It's easy, if you know the internal structure and the mapping and know basics of digital design. There's no reason why this wouldn't be possible for any other programmable logic. It's just bigger, nothing else. Sure, I wouldn't write a softprocessor in that way, but a basic traffic light controller, why not.

[BarryWhit]

---

@Andrew Neil wrote:

---

@BarryWhit wrote:

microchip has had this in their product lines for a long time (they call it "CLC"). 

---

* CCL (Configurable Custom Logic)

---

Oh, that's interesting. I thought you were clearly wrong but then I discovered we are both right.

This feature exists in Microchip's PIC line under the name "CLC" (Configurable Logic Cell).

It's also in ATMEL's AVR line as "CCL" (Configurable Custom Logic), which of course microchip swallowed.

I'm not sure if the moronic name difference is evidence this feature existed in the AVR line before the takeover,

or whether they deliberately chose different names, so they could refer to one implementation or the other unambiguously.

In any case the picture now is clear: why are STM32 chips missing this "Industry-Standard" feature? ;)

[Andrew Neil]

---

@BarryWhit wrote:

---

---

Oh, that's interesting. I thought you were clearly wrong but then I discovered we are both right.

---

So it seems!

---

@BarryWhit wrote:

I'm not sure if the moronic name difference is evidence this feature existed in the AVR line before the takeover

---

I don't think it did ?

Seems they've now come up with a third TLA to cover both! :face_with_rolling_eyes:

https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/core-independent-and-analog-peripherals/system-flexibility/custom-logic

Still not clear from that whether CCL and CLC are identical.

[Andrew Neil]

---

@Andrew Neil wrote:

---

Still not clear from that whether CCL and CLC are identical.

---

It appears that they are different:

https://www.microchip.com/en-us/about/media-center/blog/2021/custom-logic-peripherals-for-improving-applications1

[BarryWhit]

---

@BarryWhit wrote:

I'm not sure if the moronic name difference is evidence this feature existed in the AVR line before the takeover

---

I don't think it did ? 

If true then that is evidence that Microchip liked what adding CLC to the PIC line did for sales, so much so that they decided the same business decision makes sense for the AVR line.

If not, that means Atmel's own market-research independently reached the same conclusion - that adding this feature would increase profits/market share.

Either way, looks like a strong signal for ST's bean-counters that the market wants this.

[LVan .31]

I am glad that my original post generated this fruitful discussion. I would like to comment on some of them....

First of all, I am not suggesting to add something like an small FGPA but indeed, as many replicants noted, configurable logic like present in the Microchip ATSAMD51. STM32 MCU's are very good at things like motor control and communication but not soo for use with 'generic' control applications requiring all kinds of real time signals to react on and be generated in real time so by using peripherals and not software. The STM32 timers are great for this with IC/OC/PWM/Encoder and so on but not generic enough for the purposes I see. As such the suggested functionality is indeed just another peripheral. I think ST recognizes this too, look for instance at the new IRTIM peripheral in the STM32U5 range.

This is what I mean, be it that this is not generic in any way and targeting one very dedicated application, generating modulated IR signals using fixed timers. 

Suppose now that the sources and the sinks for this gate and its functionality (AND, NAND, OR, NOR, ...) would be configurable........

The issue I see is whit the approach ST has taken to make connections between peripherals (The Peripheral Interconnect Matrix). Unfortunately this is not generic in any way. The connections that can be made between peripherals is dedicated and limited. It is not possible to just select a timer and let it trigger whatever other timer. The possibilities depend on the timer or other peripheral chosen.

When adding generic logic (like the Microchip CCL) with the current STM32 approach it will be very hard to define generic relations between this and other peripherals. Here too, the ATSAMD51 offers a generic approach with event channels. Almost any peripheral offers event sources and event sinks which are connected using one of the 32 event channels, which is just another peripheral.

In the discussion until now it is also mentioned that the concept will be hard to grasp by either hardware engineers or software engineers. This brings me to another topic: Configuring an MCU and its peripherals the correct way is neither done from the hardware discipline or software discipline only. This is a system level responsibility for people having detailed understanding of both the hardware and software solutions present in the MCU. I see this for instance with the company I work for. For many hardware engineers an MCU is just a processor with some I2C and SPI. They don't even take the time to understand the possibilities of the peripherals present. I presented them for instance with the possibilities of the MDF (Multi Function Digital Filter) and the HRTIM and they were flabbergasted. The software people on the other hand do not understand it either. Their hardware knowledge is too limited to understand the possibilities of all advanced peripherals and the circuits that can be build by connecting them.

And this is just what it is all about and where my suggestion would be helpful. Having all the right peripherals and possibilities to connect them at hardware level allows for building complex hard real time circuitry inside the MCU where the software is needed to configure those circuits and after that the configured circuit lives a life on its own, operating fully in parallel with the software running on the processing core.

Thanks to all contributors for the ideas and I hope discussions like this will lead to even more useful MCU's

[waclawek.jan]

> look for instance at the new IRTIM peripheral in the STM32U5 range

It's there since the 'F0, some 10 years ago... :)

> hard to grasp... flabbergasted...

This all boils down to inadequate documentation (of all sorts), IMO.

JW

[LVan .31]

Ahh, did not know that, never used the F0. Still it is an example of a very dedicated application of glue logic which when made generic would be more usable

[waclawek.jan]

> Still it is an example of a very dedicated application of glue logic which when made generic would be more usable

I'm not sure in this very case.

The same effect can be achieved using features existing in STM32 ever since, namely by properly programming two timers using master-slave interconnection and gated mode in slave.

IMO this was added because of a client willing to pay a custom "module" in hardware rather than pay programmers who understand the intricacies of STM32 timers.

I keep repeating, this too boils down to inadequate documentation.

JW