This is pretty cool! There are a lot of things for which a little bit of fast, deterministic digital logic is strongly synergistic with the much more flexible, but slower, more power-hungry, and less predictable, programmability of a microcontroller. Much less headache to wire up a custom logic circuit than to paw through hundreds of pages of register maps and errata for various peripherals that almost do what you need. The RP2040's pioasm coprocessor is another approach to the problem.
However, Microchip don't seem to be taking advantage of the CLB to omit the usual panoply of hardwired peripherals for things like SPI, I²C, LINbus, PWM generators, etc.
I didn't expect that Microchip would be using Yosys for this.
The propagation delay through all 32 BLEs was 232ns, 7.5ns per BLE, within the 5–8ns typical range given in table 41-25 on p. 559 of the datasheet. (Quoted in the linked post in a way that suggests I might be misunderstanding it!) That's a little faster than is typical for CMOS discrete logic, but five times slower than TI's datasheet number for a 74AUC04. But it's still a hell of a lot faster than interrupt handling latency or even the 125ns minimum instruction time in the PIC16F13145 datasheet. They say it can work up to 100MHz in asynchronous mode, but I feel like that depends on single-BLE path lengths, and they say that you can't clock the BLEs' flip-flops over 16MHz.
So, what is this good for? It can't do DMA or FIFOs like pioasm. I feel like you could maybe get some mileage out of it for things like pulse density modulation, fast quadrature pulse up-down counting, LFSR noise generation, waking from sleep with complex conditions, and driving WS2812 waveforms, but I don't have a good enough sense of how the rest of the chip is set up to know if that makes sense.
RicoElectrico · 9h ago
> However, they don’t document how to configure it yourself, only referring you to their online configurator tool that submits jobs to an API that places and routes to LUTs.
This is just insane. SaaS-ification got even the largely conservative embedded market.
throwaway81523 · 8h ago
Nice, but some examples of (potential) applications would be nice Why just 32 LUTs instead of at least a few hundred? Enough to build a specialized SERDES or that sort of thing.
unwind · 1h ago
The smallest members of the family are 8-pin devices with 14 KB flash memory and 1 KB of RAM. They cost around $0.60 in quantities of one. That is typically not a platform where you would need/be able to se a specialized SERDES, since it's not powerful enough to deal with a lot of data.
I think the CLB is intended to "eat" some basic latches and/or gates that might en up on boards in industrial/control environments, i.e. push very simple logic stuff with perhaps high demands on timing and reliability into the already-programmable part.
Sounds kind of nice, but (as an actual embedded software developer) I would hesitate to commit to a platform that requires using a remote server to generate parts of my code. :|
Eduard · 8h ago
only 32 LUTs also made me scratch my head: what kind of useful things can be made with so few components?
It includes a creative demo where your browser apparently gets hooked up with a live video stream of an actual running toy hardware setup of a "CLB demo featuring a European traffic light".
It's effectively a finite state machine with two red-yellow-green traffic lights. This minimal setup already consumes 26 of the available 32 units.
Btw: as a European, let me assure you that our intersections usually consist of more than two traffic lights, include a fault state (blinking yellow light), and feature synchronized pedestrian lights on which we mostly stand until they turn green.
indrora · 6h ago
> only 32 LUTs also made me scratch my head: what kind of useful things can be made with so few components?
There's plenty of options: Memory mappers and Very Simple encryption come to mind. Stuff that is intended to make it Just That Much Harder to get to. Very tiny little finite state machines that handle One Thing.
hinterlands · 3h ago
These MCUs are generally targeted for low-power uses and various industrial & automotive stuff. They're not meant for anything high-bandwidth - you'd be using a 32-bit ARM or RISC MCU for that, or a SoC.
So, think of it more in terms of offloading simple automation or logic glue to dedicated hardware to save a microamp or keep the state machines tidy.
fake-name · 4h ago
These are intended to implement things like specialized communication protocols, or other IO behaviour. Basically, it lets you push a variety of things you'd normally do via CPU polling to the hardware.
You could easily do SPI (or something similar, like BiSS-C) in 32 LUTs.
However, Microchip don't seem to be taking advantage of the CLB to omit the usual panoply of hardwired peripherals for things like SPI, I²C, LINbus, PWM generators, etc.
I didn't expect that Microchip would be using Yosys for this.
The propagation delay through all 32 BLEs was 232ns, 7.5ns per BLE, within the 5–8ns typical range given in table 41-25 on p. 559 of the datasheet. (Quoted in the linked post in a way that suggests I might be misunderstanding it!) That's a little faster than is typical for CMOS discrete logic, but five times slower than TI's datasheet number for a 74AUC04. But it's still a hell of a lot faster than interrupt handling latency or even the 125ns minimum instruction time in the PIC16F13145 datasheet. They say it can work up to 100MHz in asynchronous mode, but I feel like that depends on single-BLE path lengths, and they say that you can't clock the BLEs' flip-flops over 16MHz.
So, what is this good for? It can't do DMA or FIFOs like pioasm. I feel like you could maybe get some mileage out of it for things like pulse density modulation, fast quadrature pulse up-down counting, LFSR noise generation, waking from sleep with complex conditions, and driving WS2812 waveforms, but I don't have a good enough sense of how the rest of the chip is set up to know if that makes sense.
This is just insane. SaaS-ification got even the largely conservative embedded market.
I think the CLB is intended to "eat" some basic latches and/or gates that might en up on boards in industrial/control environments, i.e. push very simple logic stuff with perhaps high demands on timing and reliability into the already-programmable part.
Sounds kind of nice, but (as an actual embedded software developer) I would hesitate to commit to a platform that requires using a remote server to generate parts of my code. :|
Microchip has a web page about "CLB"
https://www.microchip.com/en-us/products/microcontrollers/8-...
It includes a creative demo where your browser apparently gets hooked up with a live video stream of an actual running toy hardware setup of a "CLB demo featuring a European traffic light". It's effectively a finite state machine with two red-yellow-green traffic lights. This minimal setup already consumes 26 of the available 32 units.
Btw: as a European, let me assure you that our intersections usually consist of more than two traffic lights, include a fault state (blinking yellow light), and feature synchronized pedestrian lights on which we mostly stand until they turn green.
There's plenty of options: Memory mappers and Very Simple encryption come to mind. Stuff that is intended to make it Just That Much Harder to get to. Very tiny little finite state machines that handle One Thing.
So, think of it more in terms of offloading simple automation or logic glue to dedicated hardware to save a microamp or keep the state machines tidy.
You could easily do SPI (or something similar, like BiSS-C) in 32 LUTs.
The Raspberry Pi Pico modules have something similar (their PIO modules, which support up to 32 instructions - https://dev.to/blues/a-practical-look-at-pio-on-the-raspberr...).
TI also have a CLB module that's actually even smaller (though they document theirs) - https://www.ti.com/lit/ug/spruir8b/spruir8b.pdf
Basically, this is a pretty broadly available IO abstraction.