Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!bingvaxu!leah!itsgw!imagine!pawl20.pawl.rpi.edu!jesup
From: jesup@pawl20.pawl.rpi.edu (Randell E. Jesup)
Newsgroups: comp.arch
Subject: Re: Cycle stretching
Message-ID: <381@imagine.PAWL.RPI.EDU>
Date: 17 Feb 88 07:20:37 GMT
References: <844@daisy.UUCP> <20409@amdcad.AMD.COM>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: beowulf!lunge!jesup@steinmetz.UUCP
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 27

In article <20409@amdcad.AMD.COM> philip@amdcad.UUCP (Philip Freidin) writes:
>The implementation of this variable period clock can be done with the

>AMD  AM2925  clock generator chip.

>It is specifically designed to do exactly what you asked about. In a micro-
>programmed system, each micro cycle execution duration is a function of
>what the critical path will be for the specified operation. This is
>known at assembly time of the microcode. An extra field is added to the
>microcode, which controls the Am2925, and thus sets the duration of the
>clock for that microcycle. The chip has a 3 bit control field, so it can
>generate 8 different clock periods. With wait states, this can be extended.

	This will probably only work at relatively slow speeds.  At higher
clock rates, you will find that the inter-chip latency is magnitudes greater
that the amount you want to adjust the clock by.

	If, in some micro-programmed CISC (yuch! :-), you wnat to stretch a
cycle by 20%, you could just use a 4 or 5 times faster clock and take another
cycle.  In a RISC, unless it's awfully slow, you might as well take the
extra cycle, because chip-edge capacitance slows things down so much.  That
is the real next hurdle that state of the art stuff has to beat.

     //	Randell Jesup			      Lunge Software Development
    //	Dedicated Amiga Programmer            13 Frear Ave, Troy, NY 12180
 \\//	beowulf!lunge!jesup@steinmetz.UUCP    (518) 272-2942
  \/    (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup