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