So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.
My CS degree had quite a few sections of electronic lectures.
In fact, one way I always looked at function composition in FP languages was to think of them as digital circuit modules.
Functional programming doesn't encapsulate interfacing across different clock domains or one hot vs binary state representation. Trying to bring those abstraction models to HDL you'll find a significant impedance mismatch.
There are quite a few books using LP and FP for modelling of digital circuits.
You can also introduce signal propagation modeling on them.
You should be thinking in terms of state machines, pipelines, routing, delay & setup+hold constraints.
HDLs are just a high-powered blueprint languages. At the end of the day you're still just laying out physical blocks.
I am not talking out of thin air and wild guesses how things should be, rather about my personal experience how we learned digital circuit design and how later, already with that skill, we applied the ideas to FP.
That was the goal of my initial comment, Hardware Design Ideas -> Help understating FP function combinations as if they were ICs, not how to design hardware from FP concepts.
You can't capture pipeline depth, SRAM usage, thermal envelope/clock gating that have significant real world impacts on your design.
Part of it too is that you actually have a different set of problems. Let's say you build and abstract "Foo" block. In programming land you only pay for that block when your branch that selects it runs. Each line of code that references it just is the cost of a single opcode/asm call.
In FPGA/ASIC land each time you reference that block you're instantiating a physical copy of the block. So if your block takes 8-bits of SRAM and you have 300 references(or parent blocks that fan out to 300 references) you're now paying 2.4kB of SRAM from a fixed pool that's usually only a few mB.
Ditto switching logic, one of the fun parts of FPGA bring-up is they can have large in-rush currents of many amps as all the LUTs get flipped to their programmed state. You also have power(and usually thermal that's tied together) budgets driven by how much switching logic you run per-cycle.
It really has a lot more in common with more traditional engineering domains where planning, simulation and strong math models are the standard tools.
Combinational logic is functional as long as you keep feedback loops out of it. For a given input, you will always get a particular output. Eventually. Time is a factor.
Unlike software, this bit of functional logic is "on" or "active" all the time though. At any given moment, there is something at the input and something at the output. It's like a pair of sunglasses. They are always sunglassing, light is going through them and being filtered, whether you are using them or not.
Adding state is necessary for anything but the most trivial designs. And like software, state makes things more complicated. We call the logic that implements state "sequential" logic. By that token, instead of Combinational, we could call it Concurrent logic.
Actors could be a logical grouping of combinational and sequential logic. Pure functions and state. With ports for messaging.
Surely, we don't have to work with raw quantum electrodynamics when designing an FPGA, even though that's what's going on "under the hood".
Thinking that way, gets me wondering about different layers of abstraction along with the benefits and drawbacks of each. With FPGA programming, what levels of abstraction are available and what simplifying assumptions does each model make?
I've got in mind things like Kirchhoff's laws, where we assume perfectly conducting wires, discrete elements, a conservative ambient B field, and essentially DC current over the size of circuit elements. When those assumptions start breaking down, then we can drop down a layer of abstraction.
By "under the hood" I was referring to the constraints you have on what you design. In the software space we are mostly constrained by memory(huge), network speed(blazing fast), CPU time(tasks running long normally don't break things).
In FPGA/ASIC land those constraints are much, much smaller(kB vs gB) and there are many more(thermals, power, hard cycle requirements, etc).
System Verilog goes a lot of the way, but there are many good abstractions missing in HDL. Structs were my biggest complaint before System Verilog.
A major abstraction, absolutely huge, is “Digital.” It’s all analog, and outside of the sanitizing Digital abstraction, it’s not pretty.
But the digital abstraction allowed for astronomically complex designs to be implemented.
Probably. But that doesn't mean you might not see the effects of it. I can't find the story/paper at the moment due to too much noise in my searches, but a team of researchers gave some kind of machine learning process (I think genetic programming) an FPGA to treat as a black box to solve some problem. It ended up making a program for the FPGA that didn't work on any other FPGA, and had what should be useless elements in the program that didn't connect anywhere, but without which the whole system wouldn't work properly. So at the least they had some kind of weird effect going on that wouldn't be explained by normal analysis.
edit: Found it: https://www.damninteresting.com/on-the-origin-of-circuits/