Skip to main content
Visitor II
June 25, 2024
Question

Feature request: Programmable logic

  • June 25, 2024
  • 16 replies
  • 6553 views

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.

    This topic has been closed for replies.

    16 replies

    ST Employee
    June 27, 2024

    Hello @LVan .31,

    We appreciate the time you took to share your ideas, your request has been communicated to the dedicated team! 

    Graduate II
    June 27, 2024

    There I needed an external clock signal to propagate to other peripherals and be able to enable/disable this.

    Your chip's RCC peripheral may have a "Master Clock Out" option with a configurable clock divider, which you can use to send a clock from the STM32 to other devices.

     

    I also think even a handful of simple logic cells could reduce the BOM and board space in some cases. It's a common enough use-case to be worth considering by ST. Sometimes a CPLD is overkill, and discrete gates feel too much like the 1980s. 

    Graduate II
    June 27, 2024

    Honestly this sounds like it would be a support and tool nightmare.. notwithstanding the usefulness of the out come.

    The RISC-V approach is to have the entire thing build into an FPGA, and then you just glue the IP you want/need together.

    Super User
    June 27, 2024

    @Tesla DeLorean wrote:

    Honestly this sounds like it would be a support and tool nightmare..


    I remember the Triscend devices:

     

    AndrewNeil_3-1719520612629.png

     https://antronics.co.uk/portfolio/csoc/

    The tooling was, indeed, key.

    And it did take a lot of support - someone had to help them: https://developer.arm.com/documentation/kan159/latest/

     


    @Tesla DeLorean wrote:

    notwithstanding the usefulness of the out come.


    I found it really useful - being able to customise the peripheral set exactly to the application requirements.

     

    ST used to have the Waferscale products PSD products:

    AndrewNeil_0-1719520333542.jpeg

    https://en.wikipedia.org/wiki/STMicroelectronics#WaferScale_Integration_Inc.:~:text=In%202000%2C%20WaferScale%20Integration%20Inc.%20(WSI%2C%20Fremont%2C%20California)%2C%20a%20vendor%20of%20EPROM%20and%20flash%20memory%2Dbased%20programmable%20system%2Dchips

    https://www.eetimes.com/stmicroelectronics-buys-waferscale-integration/

     

    Microchip have their CCL (Configurable Custom Logic) peripheral in some AVRs:

    AndrewNeil_1-1719520469841.png

    https://onlinedocs.microchip.com/pr/GUID-C866D457-41E2-43C7-8442-2F1193FAAD9F-en-US-4/index.html?GUID-BCB62DAC-D256-4F52-854F-36AFF54FDB3C

     

    nowadays there are FPGAs available with Cortex-M (and other) cores built in - sometimes the core is "hard"; sometimes "soft" ...

     

    Graduate II
    June 27, 2024

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

    I'm not denying it could be very useful, but the problem is finding the ideal fit, nobody is going to be satisfied, either it's too limited or too complicated. It will be an end-less source of complaining. And likely a patent minefield too.

    And I say this as an early adopter of PAL,GAL,PLD,GATE ARRAYS (NEC & TOSHIBA), FPGA, and being familiar with IC DESIGN, VALIDATION and TEST (PHILIPS)

    Graduate II
    June 27, 2024

    The RISC-V approach is to have the entire thing build into an FPGA, and then you just glue the IP you want/need together.

     

    I don't follow. Is the 10-cent CH32V003 RISC-V MCU actually a 1000$ FPGA in disguise? FWIW, as the OP stated, microchip has had this in their product lines for a long time (they call it "CLC"). Also, we're talking very simple logic here, not an embedded FPGA. Just a handful of gates and no HDL whatsoever. If they added an LPBPAM scenario editor to CubeMX, this is feasible as well. It's also, arguably, a natural progression for ST. They've already added op-amps and comparators to their chips, like microchip did. Certainly you'd agree those are very useful?

    Graduate II
    June 27, 2024

    No, more like the GoWin FPGA's and Tang Nano 9K / 20K / 25K, w some soft-cell RISC-V, might be some fixed/hard-cell variants too.

     

    https://wiki.sipeed.com/hardware/en/tang/tang-primer-25k/primer-25k.html

    https://www.sparkfun.com/products/24511

    And there are Lattice ICE40K designs (iCESugar-nano), NEORV32, etc

     

    ST had some PLA type stuff in the parts sold to their "White-Goods" customers

     

    I'm not saying having some means to add glue-logic is a bad idea, per se, it's just not a winning idea for the large mass-market the STM32 MCU's have done so well with.

    Super User
    June 27, 2024

    @Tesla DeLorean wrote:

    ST had some PLA type stuff in the parts sold to their "White-Goods" customers


    Are you thinking of the ex-Waferscale PSDs?

    Apparently that didn't work out for ST - as they canned the product line

    Super User
    June 27, 2024

    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.

    LVan .31Author
    Visitor II
    July 1, 2024

    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.

    LVan31_0-1719819380681.png

    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

     

     

    Super User
    July 1, 2024

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

    Super User
    July 1, 2024

    > 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 .31Author
    Visitor II
    July 1, 2024

    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

     

    Super User
    July 1, 2024

    > 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

    Graduate II
    July 1, 2024

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

     

    Super User
    July 2, 2024

    > 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