cpldcpu

All of them use ASML lithography, including CXMT.

They are, of course, a bit slower in EUV adoption. But its already there:

https://www.tomshardware.com/pc-components/dram/micron-sampl...

https://www.techinsights.com/blog/samsung-d1z-lpddr5-dram-eu...

This lists many transistor patents from oldest to newest.

https://patents.google.com/?q=(H03F3%2f16)&sort=old

The Matare/Welker Patent is missing though

https://patents.google.com/patent/US2673948A/en.541

The entire debate is tiring. It would be better if these reviews would put the actual device physics of the different concepts into context.

Is there any report of a reproduction of the device proposed by Lilienfeld in his patents? If he managed to make functional devices back then, it should be possible today? (Note: Cu2S is not a very well controllable semiconductor...)

Edit:

Gemini Deep Research summary here, its quite informative: https://docs.google.com/document/d/1jE0wQVeWP9Eiybh_C6zMKeZ5...

Also specifically on Cu based TFT: https://docs.google.com/document/d/1_B2x2gBPKgGFVgJyQ0qzPdI4...

From the second document: "The primary obstacle for $Cu_2S$ TFTs is degeneracy. Spontaneous copper vacancies form with negligible energy cost in the sulfur lattice. As a result, stoichiometric $Cu_2S$ is thermodynamically unstable in air, rapidly oxidizing or losing copper to form substoichiometric phases ($Cu_{2-x}S$) with hole concentrations exceeding $10^{20}-10^{21} \text{ cm}^{-3}$."

This explains why there are zero reproductions of Lilienfelds devices. It should be noted that Lilienfeld is one of the inventors of electrolytic capacitors and did therefore know where well how to create extremely thin insulating layers as needed for TFTs. It is not impossible to assume that he could have used other semiconductors (e.g. CdS) with his concept. However, the patents seems to specifically mention Cu2S, which does not yield functional TFTs.

"Zero power" does not include the power needed to translate information between electronic and optical domains and the light source itself.

What also cannot be ignored, is that transformer models are a great unifying force. It's basically one architecture that can be used for many purposes.

This eliminates the need for more specialized models and the associated engineering and optimizations for their infrastructure needs.

I am not a professional software developer but instead more of multi-domain system architect and I have to say it is absolutely magical!

The public discourse about LLM assisted coding is often driven by front end developers or rather non-professionals trying to build web apps, but the value it brings to prototyping system concepts across hardware/software domains can hardly be understated.

Instead of trying to find suitable simulation environments and trying to couple them, I can simply whip up a gui based tool to play around with whatever signal chain/optimization problem/control I want to investigate. Usually I would have to find/hire people to do this, but using LLMs I can iterate ideas at a crazy cadence.

Later, implementation does of course require proper engineering.

That said, it is often confusing how different models are hyped. As mentioned, there is an overt focus on front end design etc. For the work I am doing, I found Claude 4.5 (both models) to be absolutely unchallenged. Gemini 3 Pro is also getting there, but long term agentic capability still needs to catch up. GPT 5.1/codex is excellent for brainstorming in the UX, but I found it too unresponsive and intransparent as a code assistant. It does not even matter if it can solve bugs other llms cannot find, because you should not put yourself into a situation where you don't understand the system you are building.

Not a big fan of emojis becoming the norm in LLM output.

It seems Grok 4.1 uses more emojis than 4.

Also GPT5.1 thinking is now using emojis, even in math reasoning. 5 didn't do that.

At this point in time, the shield headers rather look like a trademark than a useful connecter.

The dimensions should actually be closer to 12000 * (no of tokens*no of layers / x)

(where x is a number dependent on architectural features like MLHA, QGA...)

There is this thing called KV cache which holds an enormous latent state.

These interfaces use serialized binary encoding.

SNNs are more similar to pulse density modulation (PDM), if you are looking for an electronic equivalent.

I believe the argument is that you can also encode information in the time domain.

If we just look at spikes as a different numerical representation, then they are clearly inferior. For example, consider that encoding the number 7 will require seven consecutive pulses on a single spiking line. Encoding the number in binary will require one pulse on three parallel lines.

Binary encoding wins 7x in speed and 7/3=2.333x in power efficiency...

On the other hand, if we assume that we are able to encode information in the gaps between pulses, then things quickly change.

It was also a question from my side. :)

But I understand that they simulate the spikes as integer events in the forward pass (as described here https://github.com/BICLab/Int2Spike) and calculate a continuous gradient based on high resolution weights for the backward pass.

This seems to be very similar to the straight-through-estimator (STE) approach that us usually used for quantization aware training. I may be wrong though.

Well, it would still allow to deploy the trained model to SNN hardware, if it existed.

>The current implementation adopts pseudo-spiking, where activations are approximated as spike-like signals at the tensor level, rather than true asynchronous event-driven spiking on neuromorphic hardware.

Isn't that in essence very similar to Quantization Aware Training (QaT)?

Nice! Thank you for the pointers.

Thank you for mentioning this! Indeed, a practical application of the flame oscillation research is fire detection and monitoring of combustions processes. I should have mentioned this somewhere.

Thank you for your comment, indeed!

I think the main confusion for analog implementations of chaotic circuits is that they often have an inherent source of noise (e.g. johnson or flicker noise of resistors, transistors) which will be amplified into large changes by the sensitivity of the system to initial (and also intermediate) conditions.

So the actual implementation has an unpredictable behavior, but this is because the randomness of the components is amplified.

I don't know what the most obvious distinction between a chaotic analog circuit and a TRNG is. For me it was always obvious that any kind of visible structure in the trajectory (the attractors) contradicts randomness. But whenever people see Chua's circuit brought up, there are lots of commends regarding random number generators. It turned into a bit of a pet peeve of mine.

Nice, I was not aware of that! Quite interesting. Thank you for the source.

It seems to be a corner case. As I learned to know them, chaotic circuits have unpredictable cyclic behavior. Chua's circuit typically follows an oscillatory behavior with a double attractor.

If true randomness is the goal, it is much easier to use other sources of randomness like avalanche transistors, jitter of ring-oscillators in the analog domain or LFSRs if you are in the digital domain.

Chaotic circuits are neat, but they are actually not random (their output distribution is not uniform or gaussian). And candles are not random either :)

btw, slightley related: https://cpldcpu.com/2020/06/15/building-a-chaotic-oscillator...

You what is even easier than using Emacs to operare ffmpeg? Just use claude-code (or one of the other CLI code-agents)...

The self-trimming wick is the trick. Before that was invented, people had to use special scissors to trim the wick and avoid uncontrollable large (and flickering) candle flames.

https://en.wikipedia.org/wiki/History_of_candle_making#Indus...

This was 10-15 years ago.

In between they used dedicated ASICS: https://cpldcpu.com/2013/12/08/hacking-a-candleflicker-led/

And more recently simply microcontrollers: https://cpldcpu.com/2024/01/14/revisiting-candle-flicker-led...

The third reference from the article provides some pointers (see also references there).

https://arxiv.org/pdf/1803.10400

But its not trivial at all, its a complex fluid dynamics problem. I stumbled upon all the "coupled candle oscillators" literature when I was looking for a shortcut to a semi-physical candle model. But there is no easy way out...

I think you misunderstand what this does. It is not only a coding agent. It is an abstraction layer between you and the computer.

They decided to pivot to innovation that does not require extreme CMOS scaling. For example, they focussed heavily on ultra-low-power SOI at 28nm.

Keep in mind that your iphone only has very few chips in <10nm technology. The rest is using much larger groundrules, even the memory.

I thought the snark was rather the hallmark, but i'll take it...

But, yes, they are a search engine. However it seems that all the other frontier LLM companies easily copied this as a feature, so one has to wonder which part is really differentiating.

Isn't perplexity rather a "wrapper" company? Wouldn't acquiring a UX focused company bring enormous difficulties in integration, to retain Apples look and feel?

What seems to be missing for Apple is access to competitive foundation models. Perplexity has published a few finetuned models (https://openrouter.ai/provider/perplexity), but their focus does not seem to be own creating their own foundation models.

Furthermore, the entire angle on multimodality is also lacking, which is needed for true AI assistants.

Here you can see how i prompted it. I provided a similar paper (also generated with C. opus) as an example, but Opus took it from there:

https://claude.ai/share/963b66a7-930c-47a6-a4ea-d7e6993347fa

You can find the reference-paper also on Vixra: https://ai.vixra.org/abs/2506.0049

Sorry, this is just getting old...

Its a trite talking point and not the reason why there are so few consumer-AI companies in Europe.

But this is just the SFT - "distilled" model, not the one optimized with RL, right?

There is almost no information under the link