[sdiy] Parallel processing clock design question

[Magnus Danielson]

From: René Schmitz <uzs159 at uni-bonn.de>
Subject: Re: [sdiy] Parallel processing clock design question
Date: Tue, 15 Jul 2003 17:30:50 +0200

> 
> 
> jbv wrote:
> > I agree that this is some kind of brute force method, and may be
> > not the most elegant design, but it might work quite well.
> > The advantage of this method is that, when interrupt starts, there's no
> > need to save registers and such, since the main task is doing nothing.
> > Furthermore, the uC I'm planing to use (the Scenix SX) has a very
> > short interrupt rersponse time (50 to 60 ns IIRC).
> 
> Well most uCs handle saving the PC on their stack at least, so there
> will be a delay of a couple of cycles at least.
> 
> Worse still, when executing a multicycle instruction the interrupt 
> might be delayed after that instruction has completed.
> 
> Here polling your syncing signal has a distinct advantage of shorter and 
> consistent response time. And if you're going to "burn off" the unneeded 
> performance anyway, you don't loose anything.

Exactly!

You get a more predictable performance. Some CPUs even have neat instructions
that allows for very tight loops (i.e. one instruction).

Interrupts shall only be used for rare events, polling works well for
continously appearing events. For some microprocessors timers give an easy
method for timer-driven repeating event, but for the same microprocessors the
interrupt overhead is minimal. Please recall that any instruction needed to
"reset" the state of the CPU, interrupt curcuit or other interrupt related
state must be counted in as interrupt over-head. Each such instruction could be
better used. When you use larger CPUs, interrupt involved more overhead than
single-chip embedded jobs, and then the point I am making about interrupt
makes a bigger sense.

Cheers,
Magnus