Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!rutgers!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.arch
Subject: Re: Some ARM data
Message-ID: <5164@cbmvax.UUCP>
Date: 1 Nov 88 19:06:35 GMT
References: <31748@oliveb.olivetti.com>
Organization: Commodore Technology, West Chester, PA
Lines: 20

in article <31748@oliveb.olivetti.com>, chase@Ozona.orc.olivetti.com (David Chase) says:

> Memory access is either "sequential" (burst mode) or "non-sequential"
> (slower than burst mode).  I'm not sure how much of this is supported
> by the chip and how much is supported by the memory controller.

As I recall from a similarly dated (circa 1985) discussion on the hardware,
it's the custom memory controller that's managing burst.  The burst fetching
works something like a 68030's burst, in that you pay for one long cycle and
get the next three fast.  According to what I read, the ARM chip itself is
given the clock modified by the memory controller.  In a non-burst cycle,
the chip is physically clocked at 4MHz, for the burst fetches, 8MHz.  Pretty
6502ish if you ask me.  I never heard the details on this, but you'd have to
assume that [A] there's nothing like internal pipelining going on, so that
this fast/slow business doesn't slow down other operations in progress, [B]
internal stuff does get hit depending on burst status, or [C] internal
operations work from their own clock, perphaps an always-8 meg clock.
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession