#+TITLE: 035 / #10daystooffload VHDL pre-book review
#+author: screwlisp
* Motives
I am a monotonically increasing number of days into my CADR4 three
months. You may have read 034 - some incoherent thoughts on the modern
reimplementation of the lispm's microcode. To my memory, I stand by
those. Anyway, I wanted a quick runthrough of Reichenbacher's 2024
book on VHDL which is targetted at second year students ("literally
anybody").
* Reichenbacher's book
** History of VHDL
This is spectacular. VHDL is roughly the same age as specifically
common lisp, and also is one of those sorts of american military
funded projects. Its goal (failed) then was to liberate computing
hardware from a small number of fab-owning and patent-holding
companies. Reichenbacher came to VHDL in the early 90s, beginning a
career in military satellite design. I will recapitulate the history
here:
*** Stages of a freer hardware
**** Rubilith
Paint (or something) a big version of what will literally be etched in
photolithography. Obviously too involved.
**** Custom cells
Paint (or something) reuseable cells, and arrange/reuse these to make
larger designs too labour intensive to make by hand. Of note was that
the edges of the cells would have to be constructed by hand to match
up.
**** At the same time
***** Standard cells
Instead of custom cells, already-done logic cells with the
edges-matching stuff already figured out
***** Gate arrays
Uniformly pre-created fabric of logic gates, onto which one metal
layer of the custom connections from-where to-where metal was
printed. However this was found to be expensive and wasteful, since
gates which would never be used were always on the pre-printed gate
fabric board.
**** Late 1980s until now
***** FPGAs
Reprogrammable (field-programmable) gate arrays. 
*** VHDL
is the language of this short and recent history of attempting to
liberate electronic hardware.
** As a VHDL primer
My brain ground along interestedly for the first 25 pages, at which
point I remembered enough VHDL that the rest of chapters 1-4 (where I
got to until now) was vacuous in terms of knowledge, but quite
interesting in terms of how Reichenbacher was casting this knowledge
to students.
*** Broad points
**** Netlists are not appropriate for humans to ever see
What the FPGA programmer (the device) ultimately does is tell the FPGA
where to electronically hook any given gate's ports to another gate's
ports, but this is not useful to try and write by hand or reason about
any more than a compiled lisp lambda whose defining lambda form has
been lost. VHDL is useful to form inspectable and reason-about-able
units.
**** VHDL's Whole Point Is Its Concurrency Model
This is a pretty fabuous claim. The concurrency model is like this:
#+begin_src vhdl
  A <= not B after 2 ns;
  B <= '0', '1' after 30 ns;
#+end_src
where A is sensitive to B (has B in its sensitivities).

Signal B becomes '0' at time 0. Signal A is sensitive to B, so this
triggers A to become ==not '0'== (==not B==) at time 2 ns
(nanoseconds).

This happens every time B changes. So when B becomes '1' after 30 ns,
this triggers A to become ==not '1'== at 32 ns = (+ 30 2) ns.

Reichenbacher emphasises that there in no inherent ordering, so it
doesn't matter which order these two vhdl lines appear in: All it
describes is that signal A is sensitive to signal B, in terms of
literal time passing. While the FPGA or ASIC always has real time pass
in order to set a signal (propagation/gate delay), for the purposes of
simulation if no =={after}== time is specified, it happens one "delta
time" later. And if what happens at this delta time was a sensitivity
of another signal, that one happens two delta times later. But this is
a description of the VHDL simulation standard.

Something I think has gone unappreciated is that the programmer's
literal interaction with the nascent VHDL simulation is tapping these
orderless lines onto their keyboard. I will try using a
host-class-less #'clim:define-presentation-type specified over two
CLIM:VIEWs. My reason being that I am confident that exploratory
programming style is just better than the waterfall approach advocated
to new students in Riechenbach's book (1. agree on a success
criteria 2. choose an existing algorithm 3. implement that very
carefully with static illogical types, 4. then reimplement with the
same test bench with logical types.

While I'm on the topic of exploratory programming, I think that both
VHDL and ACL2 make a similar arguement that I think is wrong: They
argue that the search or the simulation couldn't be usefully reasoned
with. I notice that each of these projects basically predates common
lisp 2e's condition system, though something like lisp style debugging
was already in the culture. I think standard common lisp style
surgeory could be applied during an interrupted-for-handling VHDL
simulation, or even ACL2 logic searching though one wants the regular
suite of utilities to this end. Using clim2 seems like almost the
definition of incompatibility with zetalisp, but y'know, you can't
make an omelette.

**** Explicitness
Because of the historical and to a reasonable extent current
costliness of incorrect-assumption-based mistakes, VHDL is verbose and
statically typed. I would say this is where we know something has gone
wrong with the language as such, since as we learned from exploratory
programming style, defering commitment is a fundamental tool of
creating meta-complicated systems (by which I mean a complicated
system whose components are complicated systems).
**** The language standard includes a spec for simulating the language
This is I think, the piece de resistance of VHDL and Reichenbacher
also knows this.
**** Behavioural modelling
Honestly, I think this concept is on its own a dud. The idea is that
VHDL simulation can be used as a rudimentary software programming
language, incompatible with FPGA or other hardware
description. Reichenbacher advises students to basically write
intensely numbersy programs that can be simulated on abstract concepts
of numbers, with the idea the the numbers would then be replaced with
logical implementations of the numbers. Anyway, I think I have
something better.

I should note here that a behavioural model of the 80s microcode
specification of the lispm is what ams is waiting for from me, and is
a location I plan to reach in a few senses.
** Remembering that chapters 1-4 are convincing a student programming in VHDL is useful
It does go on. I'm optimistic about some of the future sections:
1. Why VHDL is important to describe concurrent electronic circuits
   Chapters 1-4
2. How to program in VHDL, and VHDL's notions of modular code
   Chapters 5-10
3. Verification of hardware/simulations and an introductory testbench framework
   Chapters 11-13
4. Logic synthesis- about and targetting the synthesisable subset of VHDL designs
   Chapters 14-17
5. Advanced topics: State Machines, Functional Decomposition (?) and Code Reuse seen in real world examples
   Chapters 18-21

* My Feels
I'm going to finish reading this book, and see if my later specified
concepts continue to blossom.
** Simulation VHDL with GHDL where?
While ams was not very impressed with me speculating on a comfortable
GHDL-running environment, I have very scarce computing resources and
lost an environment recently, so figuring out where and how to run a
big project is non-trivial for me.

Actually, I might try getting GHDL onto ~institute first, since this
would solve lots of my problems (it's got clang and gnat on there, so
I'm optimistic). Otherwise I will proviision a dragonflybsd
environment as I was thinking. DragonflyBSD and FreeBSD otherwise are
explicitly named by GHDL.

I guess my staging environment will just be git on codeberg (the new
cadr4 repo is currently hosted on m$ github, for which I do not have
an account).
** Lisp Was Designed Towards The Available Hardware
Decades into the x86-amd64 monopoly, it seems a little weird to think
about lisp as having been oriented to anything but amd64 cpu
architecture, though this was the case with I think MAClisp on the
PDP-10, which was a 36 bit architecture so one 36 bit cons named two
18 bit addresses (words in 262K of memory) from which lisp to a large
extent emerged.

This was also the case with the lispm microcode/microprocessor,
coding/running the most primitive functions of the lisp
implementation.

For this reason, even a bug-for-bug compatable implementation of the
microcode underneath zetalisp must be designed towards the assets and
futures of FPGAs, and specifically with a mind on
1. Effective garbage collection implementations
2. Internetworking (FPGA hosted CHAOSNET services)
3. Rich outputs and inputs

I'll have to ask Hayley about the realities of (1). I'm concerned
about The Memory System, though I guess microcode for communicating
with the memory system could just fake it for now. Behavioural!. (2)
seems naturally promising on FPGAs, since the CHAOSNET spec organises
fully duplexed reliable (through repitition) communication and so
forth and the handling of chaosnet and chaosnet services seems to
benefit from FPGAs' hardware style concurrency as identified by
Reichenbacher. DVI displays and PS/2 mice and keyboards basically
pre-existingly mesh with FPGAs, right? And Reichenbacher is using 24
bit audio examples, so I hope relatively rich outputs as well.