In a scalar implementation, a structural hazard can exist if specific execution hardware is not fully pipelined. For some operations (e.g., multiplication and especially division) the cost of implementing full pipelining may not be considered worthwhile for the expected frequency of the operation.
In a superscalar implementation, a structural hazard may exist because not every execution unit can perform every operation. E.g., supporting initiating execution of four memory operations or four multiplications every cycle would be relatively expensive when limited to four-wide issue given that a different type of operation is likely to be available.
Register file read and write port limits can also introduce structural hazards. Although it is possible to provide enough read and write ports to support the worst case, the costs of register file ports to satisfy the worst case (even with the benefit in design complexity of not having to specially handle exceptional cases) can be considered not worth the benefits when the bad cases are sufficiently rare or non-critical. E.g., some out-of-order implementations use operand capture (grabbing operands that become available between the time the operation enters the scheduler and the time it is scheduled for execution) and provide fewer register read ports than required for full width operation (whether operands available earlier are read when the operation enters the scheduler or when the operation is scheduled for execution).
(Even for an in-order implementation, result-forwarding and the use of operations with a single register source operand could make supporting four register read ports for two-way issue less necessary.)
Similarly, banking is often used for caches (and has been proposed for register files). E.g., in the common case, two accesses are unlikely to map to the same bank out of 16 banks.
Banking storage is substantially less expensive than adding access ports. The potential for bank conflicts represents a structural hazard.
