Hacker News Reader

Comment by nonrandomstring | Hacker News Reader

The implications of Karnaugh maps and state machine reduction, which we did in "Digital Logic" when I was a student, were that you could take any problem, express it as a set of states and transforms, and boil that down to an optimal netlist of discrete logic gates.

Of course, in the mid 80's that was a pedagogical tool to lead us toward register machines and von Neumann architectures, but there were still some old-skool EE hackers around who built things like guidance systems for the Navy which were hybrid analogue/digital "computers" totally without CPUs or code. Today we have FPGAs and high level tools for building ASIC, but cheap microprocessors effectively swept aside an entire approach.

Maybe we missed something. Many small and well constrained problems in IoT type applications might better be served by hard-configured solutions. They would use less power, be immune to malicious network hacking, not need 'firmware' updates,

View on HN

> not need 'firmware' updates

Well, you might still need flaws to be fixed in the device, but now flaws in the device can never be corrected.

In the past, technicians would get engineering change orders and follow the instructions to rewire boards to fix problems. You could also replace state machine and microprogram ROMs, which I guess sounds a lot like a firmware update.

It's expensive to hire someone technical enough to:

- Perform such an update

- Sign off that they performed the update _correctly_

If you need an air-gapped system, it's still much easier to set it up so it can update from a USB flash drive and log "I did the update correctly" back to the drive.

true, but most people doing hardware are doing formal designs and prove their work correct. While the proofs are not perfect, there are a lot less bugs. The cost of fixing bugs in hardware is a lot more than software, so it is seen as worth it.

Of course the cost of doing the above is one reason we don't do everything in hardware. If you have the money you could implement everything people do with computers in hardware, no software - I don't even want to think about the cost.

I have experience working with IoT hardware, there were a fair few bugs, in an apparently constrained domain.

One including a datatype mismatch, that was also a bug in the specification.

> most people doing hardware are doing formal designs and prove their work correct.

My god how I wish that were true.

Sounds like a good feature. More trustworthy device.

If a pregnancy test can run doom. It can run state level surveillance.

The problems are power consumption, speed, cost, size, development time, and the difficulty of updates and bug fixes. A modern embedded processor handily solves all of those.

Boards full of TTL are a fascinating engineering exercise, but there aren't many applications where they're a better solution.

It's also tempting to cheat and solve some of the sub-problems with monostables and analog timers. As soon as you do that you're introducing potential issues caused by temperature drift, component tolerances, and component ageing.

A fully clocked solution is always more reliable, but often that means a higher component count and cost.

FPGAs have real applications, but they're still harder to develop than code.

When I was a student one of the tutors said "We'll all be doing this in software soon" - and he was right.

"difficulty of updates and bug fixes"

We as EE engineers learned to test our creations. We are however slowly pushed to a SW process world where there are modules and integration tests and at the end, testing is just pingponged between EE and System and nobody do the testing.

> power consumption

That's the only one I don't quite understand. All your other points are definitely great objections.

Are you saying that a clocked system consistently uses less power than a stateful but quiescently 'static' circuit? I can imagine there's a reason, but it goes counter to my experience that the faster you clock a microprocessor the more power it consumes; therefore at zero clock rate a purely data-driven system should consume the least power. What am I missing?

Roughly, the power of a digital system is sum of the static power and the dynamic power (P=1/2 CV^2*F).

1. Discrete logic chips tend to be built in substantially larger process nodes (microns vs nanometers) that are less efficient. This means higher leakage current and more static power.

2. Discrete logic has to drive traces on a PCB, which have substantially higher capacitance (C) and therefore use more power getting across a board.

3. Discrete logic operates at higher voltages. Contrast 5V TTL vs. 1V core voltage inside a processor. Power is proportional to the voltage squared.

4. A microprocessor running even at low speed can replace a massive number of discrete logic chips, so for simple solutions F is low. If you're doing something very simple and interrupt-driven, F can be in the tens-hundreds of kHz.

Consequently, there's a whole lot more of both static and dynamic power with discrete logic than with a uC.

Appreciate that description. Helps crystalize exactly how revolutionary microprocessors were compared to other contemporary approaches.

False. CMOS gates (4000-series) consume no power except when they switch. And they work at low voltage.

There are ways to make a microcontroller use less power, by making it hard-sleep when nothing is happening, but you don't get that without extra work.

I don’t understand speed, either. Once you have the desired circuit, you don’t have to build it out of discrete components, you also can send it to a fab (I think that already happened with 7400-style ICs, too. The 74248 BCD to seven segment decoder doesn’t contain lots of individual NAND gates)

That will introduce practical problems, though. If you want your design on the best tech possible, that costs serious money that you may not be able to afford, especially if you don’t want an enormous number of circuits. Your 10,000 transistor design may fit a million or more times on a top-of-the-line die.

> Once you have the desired circuit, you don’t have to build it out of discrete components, you also can send it to a fab

You are still going to use a very old and obsolete process, compared to the microcontroller.

As a rule of thumb, every generation of lithography that has made transistors smaller and more efficient, has also roughly doubled the NRE costs. As you move down the feature size slope, you get all kinds of useful properties, but the tradeoff is that you have to manufacture more of any given design for it to be able to make any economic sense. To the point where you can get an amazing chip that has an arm core, storage and memory in a single package that costs pennies (well, not right now it doesn't, but it did in the past and will again) and uses almost no power, so long as you can use the exact same device that is also shipped in the millions for other things too.

Cost of fabbing an ASIC is 7 figures. Cost of compiling software is approximately zero. This is assuming that the development costs are similar.

Simplest explanation, that universal logic chips MUST have very wide tolerances, to be really universal.

- They have to use significantly higher voltages and consider higher currents, than really need to work.

For example, typical logic output of universal TTL logic, considers connect to it more than 10 inputs, each of them drain some current.

And also, universal logic i/o MUST tolerate some differences in power supply voltages and interference on real circuits.

But if you don't need to communicate to outside of chip, you could make things much more optimized, make customized outputs, considering for only as much drain as really exists in scheme; make internal highly stabilized power supply and very powerful power distribution network.

For first CPUs this was not talked, they just considered as very expensive logic chip, but ~ from 80186, hard to say exactly date, appears division: some outputs become high power, others stay "normal", low power.

And in commodity cpus, in Pentium appear two voltages - one for core and other for interface circuits.

I could not disagree more. These were highly reliable and effective systems long after their expected design lifetime. The F14 CADC is one example, as well as earlier ADC's.

Yes! It seems to me this would be the only sane way to build voting machines, especially.

There is no sane way to build voting machines. Voting isn't a technology problem, it's a social/trust problem.

Dropping stones in a bucket is "technology," effectively.

Paper slips signed by an independent observer and marked with indelible ink can be audited more easily by electoral participants than counting featureless stones in a bucket.

They have the added security feature of oily fingerprints containing unique DNA imprinted on them. It's customary in functioning democracies to not sequence fingerprints on a ballot paper, but theoretically it could be done.

-That depends on how you use them; this is a people problem, not a tech problem, as you (IMHO) correctly observe.

If you use the voting machines to keep a running tally of votes cast so results are available immediately after polls close, you have already gotten a large benefit from them.

However, to ensure the (most warranted!) concern of the electorate that the votes are not being tampered with, the machine should also print a receipt to the voter after his/her vote is cast, in a human-readable format, which is then deposited in an urn much like today.

So - you get instant results, and if the result is challenged, you can audit the actual ballots rather than just doing a code audit and hoping the numbers haven't been tampered with in some undetectable way.

Ya let's start programming exclusively in asm again as well \s

Since you posted this comment, we've seen a very interesting article on formal languages and 'program proving compilers based on separation logic'. The basis for truly correct, reusable, "eternal code" is in fact to regress to something not unlike ASM but combined with a Rust-like higher level.

Always good to remain mindful that what we assume is 'progress' in one direction may not be progress overall, and that allowing backtracking to older interpretations is actually a more mature scientific stance.

[1] https://news.ycombinator.com/item?id=31543953

There is a very old Steve Jobs video where he says something like:i dont understand what is special about software, what you cannot do in hardware. Let me see if I can find that.

Software becomes interesting when I have to make the hardware do things Jobs doesn’t want me to.

Reply on news.ycombinator.com