Lpc2000

Good morning,

Sorry for this newbie question but the MAM module confused me a lot

I have understood that the MAM module allows operating up to 60MHz but
is it possible at 0 wait state ?

On the MAM usage notes, it is refered that the MAMTIM must be
configured   regarding the the operating frequency, for example for
system clock faster than 40 MHz, MAMTIM must be set to 3 CCLKs, does
it mean that we introduce 2 wait states ?

Thanks in advance

Frederic

--- In lpc2000@yahoogroups.com, "croquettegnu" <croquettegnu@...> wrote:
>
> Good morning,
> 
> Sorry for this newbie question but the MAM module confused me a lot
> 
> I have understood that the MAM module allows operating up to 60MHz but
> is it possible at 0 wait state ?
> 
> On the MAM usage notes, it is refered that the MAMTIM must be
> configured   regarding the the operating frequency, for example for
> system clock faster than 40 MHz, MAMTIM must be set to 3 CCLKs, does
> it mean that we introduce 2 wait states ?
> 
> Thanks in advance
> 
> Frederic

LPC flash is 50ns flash memory organised 128-bit wide.  Hence flash
reads and writes flash are buffered four words at a time.

Philips says "MAM provides nearly zero-wait state execution" from
on-chip flash.  I suspect the "nearly" means "on the average when
access patterns match prefetching".

The first access after a branch or exception would take 50ns or 3 CCLKs.

MAM has other problems. Have a look at:

http://article.gmane.org/gmane.comp.hardware.arm.lpc2100/7556

Hope this helps.

Jaya

---- Original Message ----

From: "croquettegnu" <croquettegnu@...>
To: <lpc2000@yahoogroups.com>
Sent: Wednesday, April 12, 2006 4:32 PM
Subject: [lpc2000] Flash Access at 0 wait state at 60 MHz ?

> I have understood that the MAM module allows operating up to 60MHz but
> is it possible at 0 wait state ?
>
> On the MAM usage notes, it is refered that the MAMTIM must be
> configured   regarding the the operating frequency, for example for
> system clock faster than 40 MHz, MAMTIM must be set to 3 CCLKs, does
> it mean that we introduce 2 wait states ?

Yes.  But the point of the MAM is that you often can read with 0 waitstates
from the MAM buffers instead of from flash with 2 waitstates.

Most important is the 128-bit prefetch buffer that prefetches instructions
so that normal sequential instructions can be fetched and executed without
waitstates.  Jumps take 5 clocks (1 base clock plus 2 clocks pipeline
flush plus 2 clocks MAM waitstates) instead of 3 (if we had 0-waitstate
memory).  Since sequential instructions are the most normal, the net
performance of instruction fetching is like close to 0 waitstates.

There is a separate 128-bit data buffer so that when reading constants from
flash, you often do that with 0 waitstates instead of 2.  You get 0
waitstates when you read a word in the same 16-byte block as the previous
flash data read.  This is often the case when reading constants from the
literal pool.

There is also a branch target buffer that remembers the 16-byte block at the
last jump destination (non-sequential code read).  This optimizes simple
loops so that the first jump back to the loop top takes the full 5 clocks,
but the subsequent jumps to the loop top only take 3 clocks because the
instructions at the loop top can be fetched from the branch target buffer.
This of course only works when there are no other jumps in the loop body.

The MAM gets you close to 0 waitstates flash in average, wih more
predictability and fewer transistors than a cache.  It is much easier to
predict when you get the 2-clock penalty with the MAM than with a cache.

Karl Olsen

Thanks a lot !
Got it !

In fact, for sequential read code, we can reach 0 wait state at full
speed but for non sequential operations, when MAMTIM=3, we will add 2
wait states for each read ... Am I correct ?

And to be able to reach 0 wait state at 60MHz, according to the
errata, we must have MAMTIM=3 and have the MAM enabled, does it mean
that we must in ll cases use the MAM ?

--- In lpc2000@yahoogroups.com, "Karl Olsen" <kro@...> wrote:
>
> ---- Original Message ----
> From: "croquettegnu" <croquettegnu@...>
> To: <lpc2000@yahoogroups.com>
> Sent: Wednesday, April 12, 2006 4:32 PM
> Subject: [lpc2000] Flash Access at 0 wait state at 60 MHz ?
> 
> > I have understood that the MAM module allows operating up to 60MHz but
> > is it possible at 0 wait state ?
> >
> > On the MAM usage notes, it is refered that the MAMTIM must be
> > configured   regarding the the operating frequency, for example for
> > system clock faster than 40 MHz, MAMTIM must be set to 3 CCLKs, does
> > it mean that we introduce 2 wait states ?
> 
> Yes.  But the point of the MAM is that you often can read with 0
waitstates
> from the MAM buffers instead of from flash with 2 waitstates.
> 
> Most important is the 128-bit prefetch buffer that prefetches
instructions
> so that normal sequential instructions can be fetched and executed
without
> waitstates.  Jumps take 5 clocks (1 base clock plus 2 clocks pipeline
> flush plus 2 clocks MAM waitstates) instead of 3 (if we had 0-waitstate
> memory).  Since sequential instructions are the most normal, the net
> performance of instruction fetching is like close to 0 waitstates.
> 
> There is a separate 128-bit data buffer so that when reading
constants from
> flash, you often do that with 0 waitstates instead of 2.  You get 0
> waitstates when you read a word in the same 16-byte block as the
previous
> flash data read.  This is often the case when reading constants from the
> literal pool.
> 
> There is also a branch target buffer that remembers the 16-byte
block at the
> last jump destination (non-sequential code read).  This optimizes simple
> loops so that the first jump back to the loop top takes the full 5
clocks,
> but the subsequent jumps to the loop top only take 3 clocks because the
> instructions at the loop top can be fetched from the branch target
buffer.
> This of course only works when there are no other jumps in the loop
body.

> 
> The MAM gets you close to 0 waitstates flash in average, wih more
> predictability and fewer transistors than a cache.  It is much easier to
> predict when you get the 2-clock penalty with the MAM than with a cache.
> 
> Karl Olsen
>

--- In lpc2000@yahoogroups.com, "croquettegnu" <croquettegnu@...> wrote:
>
> Thanks a lot !
> Got it !
> 
> In fact, for sequential read code, we can reach 0 wait state at full
> speed but for non sequential operations, when MAMTIM=3, we will add 2
> wait states for each read ... Am I correct ?
> 
> And to be able to reach 0 wait state at 60MHz, according to the
> errata, we must have MAMTIM=3 and have the MAM enabled, does it mean
> that we must in ll cases use the MAM ?
> 

I believe the only reason not to use MAM is if you want fully 
deterministic speed of access to the on-board flash. However, this is 
rare enough requirement on processors such as ARM, where using speed of 
execution as a method of acurate timing is a poor choice (due to 
variable length of instructions, pipeline issues etc.).

Apart from the speed improvement, I believe there's also a current 
consumption reduction if you use MAM as well.

--- In lpc2000@yahoogroups.com, "croquettegnu" <croquettegnu@...> wrote:

> And to be able to reach 0 wait state at 60MHz, according to the
> errata, we must have MAMTIM=3 and have the MAM enabled, does it mean
> that we must in ll cases use the MAM ?

You can disable MAM but this means extra wait states plus higher power
consumption.  Also, do not forget to initialise MAMTIM even if you do
not want to use MAM to work around MAM bug in LPC213x.

Jaya