[1] https://github.com/akiselev/svelters

You don't need a government backed paper currency, you need a mint making precious metal coins. History has several examples like the mints at the Potosí silver mines or those by the East India Company that enabled trade without effective governments to back them up by just providing reliable coinage that spread to many other polities.

As long as there isn't some crazy inflationary force like colonizers arriving with an unlimited supply, we can use something as simple as beads or seashells for currency quite fine. It just means more labor overhead to create that currency in the first place.

I think it's also the case that hard money is a different kind of phenomenon from paper money reflecting an entirely different philosophy concerning property and what it is. It reflects a natural law perspective in its most earthy and primitive form, which is that gold and silver are money because ancestors from time immemorial saw it as such due to certain intrinsic characteristics. Governments certainly regulated mints, but also marketplaces could and did regulate coinage on their own which is possible because of its physical nature. If a coin is clipped or made into a false alloy, that can be detected and corrected without state institutions.

Paper money by contrast tends to reflect more modern positivist theories of property in which property rights are deemed to exist because the state speaks those rights into existence. In the middle ages and even before, states as we know them now did not exist and could not exist, so positivism would have been absurd on its face, and its most direct application in the form of artificial currency could not be made.

The EIC's first mint was operational in 1643, long before it became a quasi-state. It started to become a quasi-government more than a century later, when it started raising its first major army in the 1750s culminating in the Battle of Plassey and didn't really have the resources to fully become one until the diwani in 1765.

Somalia operated on paper money valued at the cost of producing it

And 1932! https://www.movingimagearchive.com/sources/san-francisco-by-...

MMIO (Memory Mapped I/O) is essentially memory (Whenever RAM or ROM) from OTHER devices that is directly visible on the CPU Address Space. My understanding is that from the CPU side, MMIO is mostly transparent (Except for the massive increase in latency) because it gets used like if it was interacting with its own workspace with regular instructions like MOV.

What PCIe ReBAR changes is that before, you could only see a 256 MiB window onto the GPU VRAM, so there was an added overhead since the GPU may need to relocate things from inside that window somewhere else on its total VRAM (So yes, it may be interpreted as if what you see from the CPU side is just some kind of exchange buffer). I believe the best way to describe how it operates is comparing it to EMS (Expanded Memory) from the DOS days since it also worked with a similar, if not the same idea. You could only see a portion of the total memory from what was installed on the EMS card (A 128 KiB window located on the upper part of the 1 MiB address space from the 8086 CPU), so you had to switch which Page (Region) of the memory was visible, adding a lot of overhead and most likely requiring an additional buffer in main RAM to move data from one Page to another. However, since I have no knowledge if the GPUs really work like that I can't confirm. I never knew whenever the 256 MiB is "fixed" (You always see the same Region) or if you can decide which section of the VRAM to make visible.

[1] https://en.wikipedia.org/wiki/Advanced_eXtensible_Interface

For historic reasons (e.g. 32 bit address spaces, plus the need to reserve the space for multiple pci peripherals) it has been a narrow, movable aperture.

Resizable BAR lets the size of the aperture be chosen (which is usually chosen to allow all of VRAM to fit in and be directly accessible).

When you insert a GPU into a PCIe slot, the memory mapped regions in memory can't be put in a hard wired location because any arbitrary device can be inserted and it can provide an arbitrary amount of memory (yes the GPU provides its own memory to the CPU). A BAR reserves a memory mapped region in the CPU space that is backed by the PCIe device.

When the BAR is smaller than the memory of the inserted device, the CPU cannot communicate with all of the memory on the inserted device directly anmore. This means if you want to perform a write to a region in the GPU outside a BAR region you have to go through the BAR region anyway. It's not a RAM buffer for PCIe packets.

>I assume it's not like memory mapped peripherals on an AXI bus which is why you need the buffer?

The PCIe controller is an AXI peripheral...

That's not how Metcal fixed temp induction soldering irons work. They don't have a control loop, which is what makes them so much better than other soldering irons.

They exploit the Curie temperature [1] of some alloys, in which the metal loses its inductive properties when it hits a certain temperature. A Metcal power supply pumps a simple 13.56 Mhz signal into the tip which heats it up and when it reaches its Curie temperature, it just stops heating. Since the signal is constant, whenever the temperature of the tip drops it just heats back up without any PID loop. The downside is that you have to switch tips (alloys) with a pair of pliers to change temperatures, but the upside is that there is no control loop delay.

It's also why their station are so reliable. There's basically no "modern" electronics in them and the worst you have to do to fix them is replace an electrolytic capacitor. I've got a power supply manufactured in the late 90s that's still as good as new and like you said, going back to a Hakko or any other soldering iron is downright painful.

(Side note to anyone who cares: when the patents expired, a couple of Metcal engineers left to form Thermaltronics, which sells cheaper stations and Metcal-compatible tips)

[1] https://en.wikipedia.org/wiki/Curie_temperature

Side note: I found Thermaltronics stations to not be much cheaper than Metcal ones. At least for the lower end stations. Gotta love capitalism.

You and everyone else. That's the great mystery of transformer architectures as applied to language.

To be clear though, they're only good at schematic capture, which is very much a textual representation. Most of the data basically boils down to netlists, which are a text based format mapping connections between abstract pins that only later map to physical copper. The actual schematic portion is for human consumption and LLMs don't need to produce those to be useful.

Where LLMs completely break down is the next step, PCB routing. That's an NP-complete research problem that's been ongoing for decades without much progress. I've had some fun playing with using LLMs to better specify DRC rules in Altium so that the "classical" algorithms are more usable, but at the end of the day their geometric intuition is nonexistent.

It was a pretty simple rp2040 based thing, similar to Adadfruits USB feather.I just gave it kicad and it wrote python to route it. The board was probably larger than it had to be, and two of the silkscreens were swapped, but it worked on the first go.

FWIW - Computer vision is also NP complete, but we do that all the time now.

> FWIW - Computer vision is also NP complete, but we do that all the time now.

I have no idea what you mean by this. What's your definition of NP complete?

However, when I was growing up most serious computer scientists believed that CV (computer vision) was a 'hard' problem that would never be 'solved'. After all, to do it right you must first at least solve subgraph isomorphism and a bunch of other things that are also NP-complete.

What they missed was that we don't actually NEED to solve it in a fixed amount of time. Even for things like driving a car the stochastic heuristic based answer is 'good enough'. e.g. - Cars driven by computers don't have to be perfect, they just have to kill other drivers less often than humans do.

We can find AN answer in polynomial time, and that's good enough. It might not be the ideal answer, but that doesn't matter in the real world.

People use NP complete as shorthand for 'impossible to do with a computer', but we now 'solve' (bypass?) NP complete problems regularly and at scale by just ignoring the fact that our answers aren't perfect.

> I'd love to see that chat log, and the final board. To be fair I've only been testing on nontrivial PCBs with 6+ layers and I haven't had the luck you have.

I wish I could share it, but it's for a commercial project that hasn't been released yet and I'm not sure if it will be open source, but a few folks have asked. I might do a blog post on it this weekend with as much detail as I can safely post.

It's only 3 layers, and less that 30 components, but the fact remains that I didn't design any of it by hand and it worked on the first go.

Here's a question - are there software simulators for things like Eurorack modules? That would make the question somewhat more interesting, since you wouldn't have to build the circuit (or pay someone else to assemble it) to hear how it sounds. It strikes me that SPICE-like algorithms should be fast enough to do this kind of thing in real time now.

This isn't true anymore.

I use LLMs for 3D CAD using OpenSCAD and they understand geometry fine. I've had more success with Sol than with Opus (Opus 5 is around 10 times slower because it does too much verification) though. I haven't tried Astra or Fable for it.

No. Take a look at https://www.eevblog.com/forum/eda/claude-code-for-pcb-design... . Fable did that by working directly on an EAGLE .brd file (well, "directly" by writing a Python program to do it, but still.)

Even so, there remained some "dozens" of unrouted traces, which are likely to be much more difficult to route, after the easy traces have already occupied the space.

Many decades ago, I have written a PCB routing program, which would have routed the example shown at that link at least as well, while using many orders of magnitude less resources, i.e. while running on a single-core 233 MHz Pentium MMX.

Obviously that program would have had great difficulties to complete a real high-density PCB design, including many irregular parts and analog circuits with special requirements. I doubt that Fable would fare better.

[1] https://en.wikipedia.org/wiki/Xfinity#Xfinity_WiFi