Longer pipelines proved to be pretty much a dead end with the Pentium 4.
They're great and all when it comes to benchmarks and stuff, but their design has a number of serious drawbacks:
1) The control lines for a long pipeline are incredibly convoluted/complicated as necessitated by the movement of individual instructions from one stage to the other along the pipeline across many, many cycles (all of which involve storing the results of the current cycle to a register somewhere along the pipeline, adding immense overhead in today's systems).
2) Flushing longer pipelines is an incredibly taxing procedure. You either flush the entire pipeline and lose a huge chunk of work, basically throwing out several thousand cycles of work as a result of a single branch or value mis-prediction; or you can selectively clear the pipeline which is an extraordinarily difficult feat that involves keeping track of which operation in what order wrote back what data to which register... for dozens of operations.
Granted long pipelines suck, but my point was you can have a higher clock speed than the time it takes light to travel from one end of you're CPU to the other and back. One of the more interesting options IMO is to have 2 separate threads with separate registers using the same hardware so you can interleave calculations without a long pipeline. The issue becomes do you have 2 half speed virtual cores or a single high clock speed core and what do you do about instructions that take more than one clock cycle.
The non-marketing name is Simultaneous Multithreading (SMT), but I've never been impressed with SMT performance. I think the emerging processors that use many simpler cores will have more impact.
They're great and all when it comes to benchmarks and stuff, but their design has a number of serious drawbacks:
1) The control lines for a long pipeline are incredibly convoluted/complicated as necessitated by the movement of individual instructions from one stage to the other along the pipeline across many, many cycles (all of which involve storing the results of the current cycle to a register somewhere along the pipeline, adding immense overhead in today's systems).
2) Flushing longer pipelines is an incredibly taxing procedure. You either flush the entire pipeline and lose a huge chunk of work, basically throwing out several thousand cycles of work as a result of a single branch or value mis-prediction; or you can selectively clear the pipeline which is an extraordinarily difficult feat that involves keeping track of which operation in what order wrote back what data to which register... for dozens of operations.