Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!elroy!cit-vax!oberon!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.arch
Subject: Re: Cycle stretching
Message-ID: <7183@oberon.USC.EDU>
Date: 24 Feb 88 07:22:58 GMT
References: <844@daisy.UUCP> <28200107@ccvaxa> <42976@sun.uucp>
Sender: news@oberon.USC.EDU
Reply-To: blarson@skat.usc.edu (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 25

In article <42976@sun.uucp> bobc@sun.UUCP (Bob Clark) writes:
[In reply to <28200107@ccvaxa> aglew@ccvaxa.UUCP]

>1) Take a functional module, characterize the worst case delay, and
>add a delay line in parallel with the function.  Use the output of
>the delay line to determine that the function is complete.

or

>2) Design an entirely new ciruit to implement the function, whose
>state changes are controlled in such a way that the final state change
>indicates completion of the function.

Why not something intermediate?  Rather than having a fixed delay,
have one that is a function of the inputs.  An adder that has an extra
output indicating that the maximum carry propigation will be N bits
could be designed.  (Probably sharing some gates with the look ahead
carry generator.) The output may be stable earlier than predicted,
(therefore wasting time) but it is still better than always waiting
the worst case for any input, and possibly uses fewer gates that the
fully determanistic "I tell you exactly when I'm ready" circuts.
--
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%fns1@ecla.usc.edu
			oberon!fns1!info-prime-request