Interlock and stall in CPU design?

[Davy]

Hi all,

I am new to CPU design and confused with two CPU term. That is
interlock and stall. What's their difference? Does interlock and stall
all do insert NOP and remove the data dependency?

I have copied a sentence from a CPU document "The interlock is
responsible for detecting read-after-write hazards and stalling the
pipeline until the hazard has been resolved. This avoids the need to
insert nop directives between dependent instructions, thus keeping code
size to a minimum, as well as simplifying assembler-level programming."

Best regards,
Davy

[Jon Beniston]

Hi,

In this use, interlock is refering the logic that tracks dependencies
between instructions, and then stalls (pauses the pipeline from the
decode stage backwards) when a dependency is detected that cannot be
resolved by bypassing.

There are other causes of stall that are not related to the interlock,
such as stalls that occur on cache misses.

Cheers,
Jon

[JoshforRefugee]

Hi Davy,
Interlock in this case refers to 'dependencies solver'. It might be a
simple stall logic or could be register renaming logic

[Ben Jones]

Hi Davy,

"Davy" <zhus...@gmail.com> wrote in message
news:1168508109.7...@i39g2000hsf.googlegroups.com...

> Hi all,
>
> I am new to CPU design and confused with two CPU term. That is
> interlock and stall. What's their difference? Does interlock and stall
> all do insert NOP and remove the data dependency?

The data dependency is a property of the program being executed, and is
never "removed" except by maybe changing the program.

In a machine where each instruction completes before the following
instruction starts, data dependencies don't cause any problems. However,
when a machine is pipelined, data dependencies and anti-dependencies can
lead to "hazards".

An interlock circuit detects these hazards. An interlock circuit may stall
one or more stages of the processor pipeline, often introducing a NOP-like
"bubble", to avoid the hazard and ensure correct program execution.

Note that there are other ways to manage hazards that do not involve an
interlock circuit, and that stalling the processor is only the simplest,
most basic way to avoid hazards. You may wish to read Hennessy and Patterson
for a proper description of more advanced techniques.

Cheers,

-Ben-

[Yao Qi]

"Davy" <zhus...@gmail.com> writes:

> Hi all,
>
> I am new to CPU design and confused with two CPU term. That is
> interlock and stall. What's their difference? Does interlock and stall
> all do insert NOP and remove the data dependency?

I am not a CPU guru, and here are some my cents. Hope they are useful.

1. "stall" is a term for pipeline, and "interlock" is a method to
"stall" pipeline.

2. Both interlock and stall DO NOT insert NOP. It is the work done by
compiler. Compiler could insert some NOPs in executable to avoid data hazard.

>
> I have copied a sentence from a CPU document "The interlock is
> responsible for detecting read-after-write hazards and stalling the
> pipeline until the hazard has been resolved. This avoids the need to
> insert nop directives between dependent instructions, thus keeping code
> size to a minimum, as well as simplifying assembler-level
> programming."

Interlock logic could lock the pipeline when data hazard is detected to
make sure the right result. So, compiler or assembler do not insert
NOPs to avoid hazard, so that code size is minimized.

>
> Best regards,
> Davy
>

--
Yao Qi
GNU/Linux Developer

[feebo]

In any system where you have co-processes/ors you never really know at
a given time, if what you asked to be done has been so.

I write a lot of database code and you ask for something to be done
and get on with the rest of your app while the DB engine actually does
the grunt work. Now suppose I try to retrieve a piece of that info I
just "wrote" and it hasn't actually been written by the engine yet, my
app will fail to find it. In DBs, you can issue a command to ensure
that you don't proceed until all pending operations have completed.

Evidently (from your copied sentance) this is a potential for
pipelined processors also. So the interlock and stall makes sure that
if you try to access something that hasn't actually arrived at it's
destination, this is detected and the action is delayed until it is
valid - thus removing the need for you to detect this in your own
code.