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]

---

@LVan .31 wrote:

configurable logic like present in the Microchip ATSAMD51.

---

that's another one that was originally Atmel and, as for AVR, calls it CCL:

https://www.microchip.com/en-us/product/atsamd51g19a#:~:text=One%20Configurable%20Custom%20Logic%20(CCL)

which may or may not be of any significance at all ...

[BarryWhit]

> as many replicants noted,

I was once a replicant, but Deckard caught up with me. :frowning_face:

> 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

It is my understanding that the HRTIM peripheral *is* specifically designed for such real-time control applications. if you're working on such designs, andthe technical solution ST's designed with just these kinds of applications in mind does not meet your needs, perhaps it would be useful for you give specifics. And also give a concrete example of how a CLC-like functionality (which is a fairly primitive things) would resolve your difficulties.

Me, I just want some glue logic baked in, so I can pare down my BOM.

We also have to remember that it's categorically NOT a bad thing for different companies to independently explore the solution space and offer a different approach to what competitors offer. We don't want to live in a world where everyone makes the same MCU, just with a different logo laser-ed on top.

[waclawek.jan]

> We don't want to live in a world where everyone makes the same MCU, just with a different logo laser-ed on top.

Partially, we already live in such a world. Half of the chinese mcus are STM32F103 clones, with or without a different logo.

JW

[BarryWhit]

Exactly. So if ST does something differently than Microchip - that can be a good thing (depending on context).

[LVan .31]

Besides Microchip, many vendors offer configurable logic with event connections at the hardware level:

Infineon: ERU (Event Request Unit)
Renesas: ELC (Event Link Controller)
Silicon Labs: PRS (Peripheral Reflex System)
Analog Devices: TRU (Trigger Routing Unit)

Most of these are generic in the sense that they allow any event source to be connected to any event sink in combination with logical operations. The background of many of these is that the peripheral set is able to work without software intervention enabling low power modes.

In this sense, ST lags behind in the sense that the peripheral interconnect is far from generic and many of the connections do not allow operation in low power modes.

[BarryWhit]

I think you missed  both my point (perhaps I made it badly) and the fact that I've already expressed support for this feature request. Oh well.

[LVan .31]

---

@BarryWhit wrote:

I think you missed  both my point (perhaps I made it badly) and the fact that I've already expressed support for this feature request. Oh well.

---

Hi Barry,
i did not miss your point and it is very clear to me reading your posts that you are in favor of the requested feature, which I appreciate.

[unsigned_char_array]

A configurable logic block can be very useful in my opinion.
Some things are notoriously slow in software such as reversing/changing bit order that are done instantaneously in hardware by just a bunch of wires. Even a simply pin matrix that allow more flexibility of connecting peripherals to a pin can be very useful.

My dream is a configurable logic block with a enough logic components to create most of the basic serial/parallel peripherals so you can create custom peripherals or variants of existing ones that suit your needs. A few look up tables, an adder, multiplier, a few counters, shift registers, registers and prescalers would be enough for many things. Allowing it to trigger interrupts or DMA transactions would make it extreme useful in automating certain tasks. Perhaps even in sleep mode.

I imagine an external ADC and DAC and you can create a filter peripheral or PID controller peripheral that runs without CPU intervention. A simple PID or simple filter in software only needs a few lines of code, but it can put a lot of load on the CPU if it has to run in a timer interrupt due to interrupt latency.

ESP32 has the RMT peripheral that is not a logic block, but quite flexible. Something like that would be very useful too.

Perhaps the peripheral can be a tiny efficient 4-bit microprocessor :). Then it would be Turing complete.

Documentation is key and I think the best documentation would be c code that simulates the exact behavior of the logic block so you can simulate it, emulate it and run unit tests on it instead of guessing what it might do in certain edge cases not mentioned in text documentation.

[BarryWhit]

>  most of the basic serial/parallel peripherals so you can create custom peripherals

explicitly not what some us want, which is "a handful of gates". You want a complete embedded logic fabric, which is not just "another peripheral", but an entire reorientation of ST's product line. I don't think that's likely, but in any case, it's different from what, at Least I, am asking for.

Xilinx/AMD, and Altera/Intel, Mentor Graphics/Siemens have spent literally 100s of man-years developing the tooling for developing on top of logic fabrics (HDL compilers, synthesis optimizers, timing analysis tools, power estimators, place and route tools, gate-level libraries, Hard-IP block, embedded soft processors), the software effort involved alone, is far far beyond anything ST has ever done in terms of user-facing software (which is to piggyback either eclipse, or recently vscode). Don't hold your breath.

[unsigned_char_array]

---

---

---

@BarryWhit wrote:

>  most of the basic serial/parallel peripherals so you can create custom peripherals

explicitly not what some us want, which is "a handful of gates". You want a complete embedded logic fabric, [...]an entire reorientation of ST's product line.

---

That's not what I wrote at all!
All I want is, whatever the implementation, that the number of components are enough to create useful things. I'm not proposing a small FPGA.

---

@BarryWhit wrote:

Xilinx/AMD, and Altera/Intel, Mentor Graphics/Siemens have spent literally 100s of man-years developing the tooling for developing on top of logic fabrics

---

And they patented them and also optimized them for their production processes. ST doesn't have the licenses to just copy those blocks as far as I know and I doubt they can be easily adapted to the same manufacturing process as their microcontrollers. But I can be wrong here. Maybe I'm overestimating it. But I'm definitely not proposing that!

That's why I proposed a 4-bit microprocessor too with some hardware acceleration and access to interrupt controller and DMA controller. I think this should not take up too much silicon . But I can be wrong here.