[rcxdude]

The semantics of HDLs are generally kind of funky: they have a sequential interpretation, which us what simulators will use. That interpretation does involve a bunch of blocks which will operate in parallel, but within those blocks it's just a sequential series of operations not unlike aby other programming language. But HDLs generally can express a lot more than what can be automatically synthesised into hardware (this is useful because you often have simulation-only test blocks and harnesses which don't need to exist in hardware).

The way you then write hardware is you define a series of blocks which are in the form "when this clock edge happens, update these variables in this way based on the previous value of variables in scope". It doesn't matter so much how you express this change, so long as the synthesis engine can map any given set of input variables to an output, which it will turn into digital logic. It is why verilog has odd constructs like "assign this value to this variable after the next time step". It's not unlike writing event-driven non-blocking code (without async or green threads).

Note at this point that the HDL written is saying nothing about delays: by running it in simulation, everything will complete in time for the next clock cycle. And the synthesiser will happily produce a circuit which the place and router can't actually make fast enough for the next cycle. That's where two other parts come in: firstly there's timing analysis which takes the low-level results of the place-and-route and basically tries to work out the fastest and slowest a signal can pass from one register output to another register input, and how that compares to the clocks to those registers (usually it'll be the same clock). That is generally what will tell you if what you've written won't work in some situation or another. And secondly, the tool can also take that low-level compiler outout, and give you a kind of "decompiled" version in your HDL, which doesn't bear much resemblance to what you put in but does include all the estimated delays, so you can simulate (much more slowly) what the timings will actually look like.

The upshot of which us that writing an HDL generally involves thinking about what the hardware would look like, writing some code that simulates what that hardware would be doing, running it through a slow build cycle, looking at what hardware was actually generated and working put why it's failing timing, thinking about how to change the hardware and then changing the code to get the sythesis tool to spit out the right version of that. You don't tend to get super high levels of abstraction in a given execution path: more the abstraction is in how you connect those parallel blocks together.