I learned last night of <https://github.com/hneemann/digital>, a poorly
named open-source system for simulating digital logic. I haven't tried
it yet, but it seems to be intended as an improved replacement for Carl
Burch?s Logisim, especially for teaching students who are learning
digital logic for the first time.

Like Verilog, it supports propagation delays for digital gates, but all
the base propagation delays are the same.

Like LTSpice, it has a schematic-capture UI, and it includes a library
of existing chips, but they?re digital chips; they include 28C64, a lot
of the 7400 family (including the 7408, the 7414, the 74138, the 74164,
the 74165, the 74244, the 74595), but none of the CD4000 family, not
even 74HC4051 and the like. You can add new components written in VHDL
or Verilog.

It purports to have reasonable simulation performance: ?The example
processor can be clocked at 120 kHz,? on a 2.6GHz i5-32320M.

And it can export configurations for PALs, CPLDs, the Artix 7 (on the
Basys 3 board), and the iCE40LP8K (on the TinyFPGA BX board), as well as exporting VHDL or Verilog.

This seems like it might be usable for tasks beyond just student
exercises? Has anybody here tried it?

Kragen

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 9/4/2026 6:41 PM, Kragen Javier Sitaker wrote:

This seems like it might be usable for tasks beyond just student
exercises? Has anybody here tried it?

Is your goal just to get a rough idea as to whether or not your
logic *might* work? Or, do you actually want to produce finished
designs that *must* work?

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 04 Sep 2026 22:41:45 -0300, Kragen Javier Sitaker <kragen@canonical.org> wrote:

I learned last night of <https://github.com/hneemann/digital>, a poorly
named open-source system for simulating digital logic. I haven't tried
it yet, but it seems to be intended as an improved replacement for Carl >Burch?s Logisim, especially for teaching students who are learning
digital logic for the first time.

Like Verilog, it supports propagation delays for digital gates, but all
the base propagation delays are the same.

Like LTSpice, it has a schematic-capture UI, and it includes a library
of existing chips, but they?re digital chips; they include 28C64, a lot
of the 7400 family (including the 7408, the 7414, the 74138, the 74164,
the 74165, the 74244, the 74595), but none of the CD4000 family, not
even 74HC4051 and the like. You can add new components written in VHDL
or Verilog.

It purports to have reasonable simulation performance: ?The example
processor can be clocked at 120 kHz,? on a 2.6GHz i5-32320M.

And it can export configurations for PALs, CPLDs, the Artix 7 (on the
Basys 3 board), and the iCE40LP8K (on the TinyFPGA BX board), as well as >exporting VHDL or Verilog.

This seems like it might be usable for tasks beyond just student
exercises? Has anybody here tried it?

Kragen

My guys write "test benches" in VHDL, to test their FPGA designs.

We used to use one-time programmable antifuse FPGAs with no test tools
but the PCB itself. They usually worked first time.


John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Kragen Javier Sitaker <kragen@canonical.org> wrote: |---------------------------------|
|"[. . .] a poorly |
|named open-source system [. . .]"|
|---------------------------------|

Inventing a name can be hard.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

John Larkin wrote: |-------------------------------------------------------------|
|"We used to use one-time programmable antifuse FPGAs [. . .]"| |-------------------------------------------------------------|

Did you stop? Why?
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 5 Sep 2026 21:41:54 -0000 (UTC), C?il?n Niocl?s?n Glost?ir <thanks-to@Taf.com> wrote:

John Larkin wrote: >|-------------------------------------------------------------|
|"We used to use one-time programmable antifuse FPGAs [. . .]"| >|-------------------------------------------------------------|

Did you stop? Why?
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

Personally, because I have other people program FPGAs for me now. And
because the coding tools have become so complex.

And because people these days prefer to hack code fast and test it,
rather than design and check carefully.

People are using AI to write code in minutes, knowing it will have
bugs, and assume they will test and fix.

Code fast and test mostly works.

I'd rather design hardware, where getting it right first time has real
value.

Hardware design involves architectural design, electrical theory,
control theory, parts, mechanics, electromagnetics, mechanical
design, and thermal design. I find that a lot more interesting than
typing code.


Both these boards worked perfectly first time.

https://www.dropbox.com/scl/fi/69wwpsoc0o47cidxwust7/B360_20260813_110116.jpg?rlkey=y0sxkzswmgj3wa9lvf9ihbdio&raw=1

Well, the SMA connectors were a bad choice. I replaced these with
SMBs, which was a serious PITA.


John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

It's an amateur development not suited for production. It's full of bugs and insurmountable architectural deficiencies. The original developer got burned out and quit it and the follow-on start-from-scratch replacement. Which should tell you something, as in, if he didn't want anything further to do with it, why would you?

--
For full context, visit https://www.electrondepot.com/electrodesign/hneemann-s-digital-for-more-than-just-introduction-to-ee-4409990-.htm


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Almost all AI code is something that has been scraped from the literature that is mostly tutorial and demonstration level. It is not recommended for a working product. Testing it is a start but no guarantee.

--
For full context, visit https://www.electrondepot.com/electrodesign/hneemann-s-digital-for-more-than-just-introduction-to-ee-4409990-.htm


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: AI code and circuit designs (was Re: hneemann's "Digital" for more than just introduction-to-EE?)

someone <2a59d59e3809f827ce709d3815e3950eef4a6a93af5557a93a7fdfba71460843@example.com> writes:

Almost all AI code is something that has been scraped from the
literature that is mostly tutorial and demonstration level. It is not recommended for a working product. Testing it is a start but no
guarantee.

It?s probably true that most AI code is tutorial and demonstration
level, but it?s probably not ?scraped from the literature?. But it
might depend on which AI model you?re using, and how you?re using it.

***

Sunday night, I asked Claude Opus 5 (no longer a frontier model now that
Fable is out) to write a bit-serial Verilog soft core for a minimal CPU architecture I?d designed 17 years ago: four 12-bit registers, two of
which form an operand stack. (The other two are the PC, which is
actually 11 bits, and the instruction register.) The ALU instructions
are just subtraction and NAND, so you have to synthesize addition out of subtraction, and XOR out of NAND, and the like. Very inconvenient, and definitely not an architecture you can ?scrape code from the literature?
for.

After asking me about the instruction encoding, which I?d left out of
the design doc, it invented an instruction encoding and wrote the
Verilog. But, because it didn?t have Verilator, it hand-translated it
into a simulator in RTL-level Python, wrote an idiomatic Python
simulator for the instruction set, and wrote a fuzzer to generate
thousands of random programs and ensure that they executed the identical sequence of register values on both simulators.

For good measure, it wrote an assembler, a disassembler, and a number of reasonable small example programs in the assembly language, and also
used those programs in the equivalence test, and tested that their
output was what was expected. Also, some other tooling.

The Verilog specified `timestamp inconsistently, and also had a comment
that Verilator interpreted as a pragma, and once those were removed, the Verilog also worked on the example programs???as you would expect from
the fact that Claude had tested them on the Python RTL-level simulator.

This is a level of testing common in electronics but much higher than
people normally apply to software.

***

With Yosys, the CPU synthesized to 104 Lattice 4-input-LUT logic cells,
which seems like a pretty reasonable size. I haven?t tested it in an
actual FPGA yet. I?m skeptical that this design is actually a good idea
for any product???SeRV would be slower, but it?s much easier to program,
and it?s less than twice as big. This CPU design has been mostly an
exercise for learning about LLMs for me.

It was pretty astounding to me that it just went ahead and casually
wrote a bunch of assembly-language programs for a weird architecture
unlike anything that?s ever been made. I didn?t look at the log of its
?tool calls? but I wouldn?t be surprised if it had to fix the programs
several times before they worked. But they did work.

***

On the other hand, the assembler was passing the definitions of
numerical constants to Python?s `eval`, allowing a malicious
assembly-language source file to run the assembler out of memory and
crash it???and maybe crash your whole computer. I suspect assembling a malicious assembly-language source file could delete your home directory
after emailing your dick pics to your in-laws and a death threat to the President, but the obvious things I tried to escape the assembler?s `__builtins__:{}` sandbox didn?t work. But Python hasn?t supported
sandboxing since Python 2.2, so there?s probably a way.

This inappropriate `eval` is an example of a serious problem in a piece
of AI-generated code. No amount of undirected testing is likely to
uncover things like that; you really did need to review the code. And,
of course, the AI?s rigorous testing did not uncover it???that was
focused entirely on the CPU simulator, not the assembler. Maybe if I?d
asked the AI to do a security review of its own code, it would have
flagged it.

Kragen

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: AI code and circuit designs (was Re: hneemann's "Digital" for more than just introduction-to-EE?)

On 9/9/2026 10:39 PM, Kragen Javier Sitaker wrote:

someone <2a59d59e3809f827ce709d3815e3950eef4a6a93af5557a93a7fdfba71460843@example.com>
writes:

Almost all AI code is something that has been scraped from the
literature that is mostly tutorial and demonstration level. It is not
recommended for a working product. Testing it is a start but no
guarantee.

It?s probably true that most AI code is tutorial and demonstration
level, but it?s probably not ?scraped from the literature?. But it
might depend on which AI model you?re using, and how you?re using it.

***

Sunday night, I asked Claude Opus 5 (no longer a frontier model now that Fable is out) to write a bit-serial Verilog soft core for a minimal CPU architecture I?d designed 17 years ago: four 12-bit registers, two of
which form an operand stack. (The other two are the PC, which is
actually 11 bits, and the instruction register.) The ALU instructions
are just subtraction and NAND, so you have to synthesize addition out of subtraction, and XOR out of NAND, and the like. Very inconvenient, and definitely not an architecture you can ?scrape code from the literature?
for.

After asking me about the instruction encoding, which I?d left out of
the design doc, it invented an instruction encoding and wrote the
Verilog. But, because it didn?t have Verilator, it hand-translated it
into a simulator in RTL-level Python, wrote an idiomatic Python
simulator for the instruction set, and wrote a fuzzer to generate
thousands of random programs and ensure that they executed the identical sequence of register values on both simulators.

This sounds like it was treating your "CPU" as just a simple state machine
as it/you would never use such a "Monte Carlo" technique to validate a
CPU of typical complexity; you'd look at the boundary conditions for
the logic and exercise those to reduce the number of test vectors to
something manageable (and, more importantly, to some set that allows you
to *deduce* where the fault lies in your implementation by highlighting
a pattern).

It's also consistent with the idea of a *process* pattern -- how one
designs an FSM (and validates it!)

For good measure, it wrote an assembler, a disassembler, and a number of reasonable small example programs in the assembly language, and also
used those programs in the equivalence test, and tested that their
output was what was expected. Also, some other tooling.

The Verilog specified `timestamp inconsistently, and also had a comment
that Verilator interpreted as a pragma, and once those were removed, the Verilog also worked on the example programs???as you would expect from
the fact that Claude had tested them on the Python RTL-level simulator.

This is a level of testing common in electronics but much higher than
people normally apply to software.

There are many sophisticated software tools available. The problem most usually lies in the LACK of sophistication of the programmer! Not
keeping up with advances in technology, tools, methodology, etc.[Ask your favorite programmer what TECHNICAL PAPERS he's read, recently. No, not
which "programming language du jour" he's played with but, rather, what *theory*/technology he's exposed himself to.

<crickets>

With Yosys, the CPU synthesized to 104 Lattice 4-input-LUT logic cells,
which seems like a pretty reasonable size. I haven?t tested it in an
actual FPGA yet. I?m skeptical that this design is actually a good idea
for any product???SeRV would be slower, but it?s much easier to program,
and it?s less than twice as big. This CPU design has been mostly an
exercise for learning about LLMs for me.

The problem with LLMs is they don't EXPLAIN their actions. So, you
can neither LEARN from them *or* detect a fault in their reasoning.

I've designed all of my agents to "generate rules" to express what
they've learned. These are introduced to a Production System that
applies them.

But, in this form, they can be examined by a human to see if they
make any sense in the context of the task they are intended to refine.

I also take very deliberate care to only let them look at data that
is LIKELY pertinent to the task. E.g., if developing a set of
criteria for recognizing package deliveries to the front door,
there is likely NO value in letting it see what the currently most
popular *song* happens to be! Or, the weather in South Africa.

It was pretty astounding to me that it just went ahead and casually
wrote a bunch of assembly-language programs for a weird architecture
unlike anything that?s ever been made. I didn?t look at the log of its
?tool calls? but I wouldn?t be surprised if it had to fix the programs several times before they worked. But they did work.

***

On the other hand, the assembler was passing the definitions of
numerical constants to Python?s `eval`, allowing a malicious assembly-language source file to run the assembler out of memory and
crash it???and maybe crash your whole computer. I suspect assembling a malicious assembly-language source file could delete your home directory after emailing your dick pics to your in-laws and a death threat to the President, but the obvious things I tried to escape the assembler?s `__builtins__:{}` sandbox didn?t work. But Python hasn?t supported sandboxing since Python 2.2, so there?s probably a way.

This inappropriate `eval` is an example of a serious problem in a piece
of AI-generated code. No amount of undirected testing is likely to
uncover things like that; you really did need to review the code. And,
of course, the AI?s rigorous testing did not uncover it???that was
focused entirely on the CPU simulator, not the assembler. Maybe if I?d
asked the AI to do a security review of its own code, it would have
flagged it.

LLMs look for patterns. Patterns that are suggestive of OTHER patterns
that it has previously encountered. You can change the operators, variables, constants, etc. but the underlying patterns persist.

Like a sentence is "subject verb predicate", one can make limitless
numbers of DIFFERENT sentences and all fall into that pattern:

'On the Feast of St. Stephen, I was driving my hearse to the
wholesale liverwurst outlet when a hermaphrodite in a piano
truck backed out of a crackhouse driveway, and, as my shoes
caught fire, I pirouetted across Boris Karloff Boulevard,
slapping the truckdriver six times in the loins with a
Chattanooga road map, even though he was humming "The
Pussycat Song"'

There are software tools that can be quasi-directed (informed of
conditions that the developer expects at specific points in the code
stanzas) and they will explore the limits of those expectations in
an attempt at 100% code coverage. But, they are costly (in terms
of execution time) and hard to apply universally -- often because
the developer has a hard time sorting out his expectations!

Sadly, most developers resort to cowboy coder approaches to
"wrangling" their code...


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

someone <2a59d59e3809f827ce709d3815e3950eef4a6a93af5557a93a7fdfba71460843@example.com> writes:

It's an amateur development not suited for production. It's full of
bugs and insurmountable architectural deficiencies.

Can you be specific?

The original developer got burned out and quit it and the follow-on start-from-scratch replacement. Which should tell you something, as
in, if he didn't want anything further to do with it, why would you?

That is not correct; according to the Git log, Helmut Neemann wrote the
first commit 10 years ago, the most recent commit on Monday, and about
98% of the 4566 commits in between. Is it possible you?re confusing
?Digital? with a different piece of software?

Kragen

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)