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