A little background - I've written a couple of Verilog compilers - you can have always statements with multiple events, protocol state machines a bit like:

    always @(posedge clk) begin
         do some stuff
         if (condition) begin
              @(posedge clk);
              do some more stuff
         end else begin 
              @(posedge clk);
              do some different stuff
         end
         ......
    end

Synopsis will happily synthesise this, generating the implied state variable. There really is a loop in there. In fact 'always' is exactly 'initial #0 forever'

But if the result is a flipflop, where is the loop?

Always implies an outer loop, when you reach the bottom of the loop you go back to the top and do the original event wait again, but not until you've waited for the intermediate event waits

In simulation this is easy to implement, but in synthesis the synthesis tool needs to rewrite it as some hidden flops for state and a top level case statement

I'll add these examples of how to make a clock from the Verilog 2k standard:

    always #half_period areg = ~areg;

    always c = #5 ~c;

the @() portion is not intrinsically part of the always - it's just usually used there for synthesisable code

So you're explicitly restricting yourself to simulators only?

If not, where in this shift register[1], when synthesized to an FPGA, is the loop waiting for posedge clk or posedge reset?

[1]: https://asic4u.wordpress.com/2016/03/28/verilog-1-delay-in-r...

No - the example I gave above with multiple @(posedge clk) in the single always statement is synthesisable (by synopsys at least, I don't know about others) and contains an embedded loop - it's arguably a higher level way to make logic than the traditional always/case/state state machine. Maybe a simpler example will do:

    always begin
        @(posedge clk) v <= a+1;
        @(posedge clk) v <= a-1;
    end

is identical to:

    always @(posedge clk) begin
        v <= a+1;
        @(posedge clk) 
        v <= a-1;
    end

both can be synthesised and make the same logic

the shift register example you give would normally be synthesised to something with a synchronous clock and an async reset - during simulation the loop is waiting for either

> during simulation the loop is waiting for either

Ok, then we agree. Of course a simulator will have an implicit loop, that's not contentious.

However you did not mention this in your initial statement, and I've read and been told explicitly not to think of it like this because there's no loop in hardware.

That’s not exactly the right way to think about it. In HDL, you’re writing an algorithm, but the algorithm produces a physical device, not a computation.

It’s like programming a machine to make a watch. At the end you have a watch. Would you say the gears execute in parallel while it measures time?

In some sense it’s right, but in another it’s missing the point.

I think the loop term is OK, it's just gated by the event sensitivity list for each iteration. If you have an always without a sensitivity list then it is a while(1) equivalent.

This is not exactly true, because the event you expect in software, the loop ticking over, can itself happen at any time. posedge(*) will trigger on _any_ change in the always block, and those changes can happen at the same, slightly different, or much different times.

always( * ) is not the same as always, I was referring to the latter. always( * ) is gated by the sensitivity list, always is not.