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.

[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.

[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.

[LCE]

One more vote for some extra configurable logic in STM32

[BarryWhit]

Thank you all for your interesting comments. I reiterate my support for the addition of a "CLC/CCL/CCLLCCLC/etc"-like peripheral to future STM32 families, together with the addition of lightweight graphical configuration pane in CubeIDE. Beyond that, I don't think more comments are needed, from me anyway.

[unsigned_char_array]

---

@BarryWhit wrote:

Thank you all for your interesting comments. Beyond that, I don't think more comments are needed, from me anyway.

---

Why are you acting like the OP? Very confusing.

[Nikita91]

Raspberrypi used another solution by introducing PIO with the RP2040.
This makes it possible to generate peripherals not provided for by the manufacturer, using this type of very fast processor (it's almost the 4-bit processor requested by someone, but more flexible).

But overall ST has chosen another direction: to provide in each MCU a large number of peripherals of all kinds, increasingly complex, but not all usable at the same time due to the lack of interconnection between them and with the outside world. The notion of AF is very primitive and rustic (there are a lot of empty boxes in the tables), and the more the number of IPs in the MCU increases, the more crucial the problem becomes, which leads to having to choose a case with more pins than necessary.

Introducing something like PIOs or logic cells would produce another MCU architecture:
- Fewer peripherals such as SPI or UART (can be replaced on demand using programmable logic)
- simpler peripherals (I2C and UARTs are very complex at ST, and must consume a lot of cells)
- Need for fewer timers: no more need for master/slave chaining to generate complex signals (but it is still possible if necessary). Given the limited number of timers, their channels must be able to be directed to any GPIO.
For this to work you need more interconnection between the devices (like the Atmel event buses).

Silicon saved on peripherals can be used for interconnects and programmable cells.

Summarizes the expected MCU for me:
- Fewer core peripherals: 2 UART, 2 SPI, 2 I2C. But complete: FIFO, interrupt, etc.
- Few timers: TIM1 for motors/power supplies, TIM2 and TIM5 in 32 bits, all in 4 differential channels.
- An interconnection bus for peripheral events.
- A generalization of the GPIO assignment (which allows the use of cases with fewer pins)
- And PIO and programmable logic: LUT, FLIP/FLOP,

This would likely lead to a "small" MCU in terms of silicon surface area.
So yes this will require changing programming habits, but what flexibility of use!

But this completely changes ST's vision of MCU architecture, and therefore it is unlikely to see the light of day. Not to mention that CubeMX might need to be thoroughly reviewed. In my opinion, if programmable logic is introduced, it will be in the current architecture: limited and fixed interconnection of peripherals, and assignment of specific GPIOs (even more competition for I/O), which will limit their use.

But I'm still impatiently awaiting this development.