[akiselev]

> They are fully aware of the message-passing model that backs the HDLs. To them that model is an obstacle to be overcome on the way to building circuits.

Can you expand on this? I don't quite understand what you mean by "message passing model" in the context of HDL. Signals are sort of like messages in the no shared memory sense but there is still plenty of spooky action at a distance when synthesizing.

Unless your level of abstraction is at the interconnect level like AXI, timing is always a huge pain and small changes in design can have significant downstream impact as signals are rerouted. Sure you could create a data structure that represents a complex module but it'd be a monstrosity that accepts dozens if not hundreds of closures to enable tweaks like "delay this half of the bus by n and the other half by 2n" that will have to be modified anytime there is a significant refactor that reorganizes the modules.

The core problem of applying software abstractions to FPGAs is that while HDL describes logic, it compiles nondeterministicly (to humans) into a format where physical placement and fit makes or breaks that logic. At that point, it's not really an abstraction as programmers see it but as, say, cabinet makers see it: there is a variety of well characterized off the shelf parts that they can order and they have a suite of power tools like grinders and routers to modify that part to fit their specific use case. The "arguments" or input for the abstraction have to be incrementally discovered by first grinding or cutting, then trying the part out to see if it fits, then mixing some sawdust with glue to fill in some spot, then grin or cut some more, and so on - rinse and repeat until all parts fit together correctly.

[i_don_t_know]

The message-passing model might refer to discrete event system implementations of digital logic simulators. That is, you can think of the events as messages between logic gates and wires. See for example the simulator in SICP: https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

[brandmeyer]

> Can you expand on this? I don't quite understand what you mean by "message passing model" in the context of HDL.

See Section 9 of the SystemVerilog language reference manual, ieee1800. Bootleg pdfs of the 2005 revision are readily available.

The formal semantics of the language's execution are defined in terms of message-passing. Any lowering to physical hardware should respect the same semantics even if it isn't actually passing literal messages from one reg to the next.

[_mouvantsillage]

Now I think I understand what you mean.

For many hardware engineers, I think that the message-passing semantics is a conceptual framework for explaining how simulators work. It is considered as a "necessary evil" that must be taken into account when writing HDL code.

When I write VHDL, I don't think in terms of communicating processes. I think in terms of combinational and sequential circuits that I describe with processes. The description is written in a way that makes the synthesizer generate the hardware that I had in mind.

I see a possible explanation for this mindset: since only a subset of VHDL or Verilog is actually synthesizable, we cannot rely only on the language semantics to write code that will map to functional hardware.

[brandmeyer]

I totally agree, and that's what I'm getting at.

Other formal models like the lambda calculus have an advantage in that lambda functions and the type systems to work with them aren't that far removed from the machines that execute them. So the practicing software engineer doesn't have a hard time using that model directly++.

As you so demonstrated, practicing HDL engineers don't generally find the actor model to be a good mental representation of their designs. Nevertheless, even in the synthesizeable subset, the languages are formally specified using message-passing processes. They just also happen to admit non-synthesizeable designs as well.