About the connection of pipelined execution and latency Let's consider we want to calculate a[i]=a[i]*c for a vector the size of N=12 on some random processor.
We do assume that c is some given constant already present in the register. We do not consider any superscalarity or vectorization.
We also know the latencies for the following instructions:

Load operand to register (4 cycles)
Multiply a(i) with c (2 cycles); (a[i],c in registers)
Write back result from register to mem./cache (2 cycles)
Increase loop counter as long as i less or equal N(0 cycles)

The result my class gives me for the pipelined execution of this is the following, where each line represents one CPU cycle:

Why is this correct? Or is this even correct?
If we consider the first load (load a[1]) shouldn't it block my only load unit on the processor for 4 cycles?   How can I even load a[2]in cycle 2then?
Or is latency only the time to that is needed to send information that something is e.g. loaded, and the actual load unit is only busy for one cycle for each load operation?
In a processor that would nowadays be considered simple, you need two numbers for an instruction: what is the total execution time (for example 4 for load) and how long you need to wait before another independent operation can be issued - it seems that someone assumed 1 cycle between instructions for load. A different processor might only allow a load every two cycles, and your numbers would be totally different.
The PowerPC 603 was interesting in that a multiplication took 4 cycles, but it couldn’t start four multiplications in a row, so your multiplications would have started at cycles 4, 5, 6, 8, 9, 10, 12 etc.
Things get more interesting when you have multiple independent execution units; like you assume at least three units capable of load, store, and multiplication. And more interesting if you have limits decoding instructions, dispatching to execution units etc.