5 ms·

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, expre

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,

andi999 4y ago
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.
- the_only_law 4y ago
  Software becomes interesting when I have to make the hardware do things Jobs doesn’t want me to.
pegasus 4y ago
Yes! It seems to me this would be the only sane way to build voting machines, especially.
- orlp 4y ago
  There is no sane way to build voting machines. Voting isn't a technology problem, it's a social/trust problem.
  - dalbasal 4y ago
    Dropping stones in a bucket is "technology," effectively.
    - BVCommander 4y ago
      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.
  - lb1lf 4y ago
    -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.
    - deleted 4y ago
      [deleted]
TheOtherHobbes 4y ago
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.
- hulitu 4y ago
  "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.
- nonrandomstring 4y ago
  > 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?
  - mjgerm 4y ago
    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.
okeuro49 4y ago
> 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.
- Gracana 4y ago
  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.
  - ReactiveJelly 4y ago
    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.
    - deleted 4y ago
      [deleted]
- bluGill 4y ago
  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.
  - heurisko 4y ago
    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.
fennecfoxy 4y ago
Ya let's start programming exclusively in asm again as well \s
- nonrandomstring 4y ago
  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 https://news.ycombinator.com/item?id=31543953

andi999 4y ago

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.

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

pegasus 4y ago

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

orlp 4y ago
There is no sane way to build voting machines. Voting isn't a technology problem, it's a social/trust problem.
- dalbasal 4y ago
  Dropping stones in a bucket is "technology," effectively.
  - BVCommander 4y ago
    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.
- lb1lf 4y ago
  -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.
  - deleted 4y ago
    [deleted]

TheOtherHobbes 4y ago

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.

hulitu 4y ago
"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.
nonrandomstring 4y ago
> 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?
- mjgerm 4y ago
  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.

okeuro49 4y ago

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

Gracana 4y ago
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.
- ReactiveJelly 4y ago
  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.
  - deleted 4y ago
    [deleted]
bluGill 4y ago
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.
- heurisko 4y ago
  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.

fennecfoxy 4y ago

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

nonrandomstring 4y ago
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 https://news.ycombinator.com/item?id=31543953