ARM7TDMI Instructions Taking 50-100 Clocks

I'm running an Atmel ARM7TDMI on a prototype board I wire-wrapped and
am monitoring the system with an oscilloscope. By comparing the clock
pulses to the read/write pulses, I'm finding that single-byte store
and read operations are taking literally 50-100 clocks. Naturally this
is unacceptable for any purpose, and is obviously a sign of something
being majorly wrong. I've read all the literature on the ARM I can
find including all of Atmel's documentation and white papers. Does
anyone have any idea what this might be?

"Alex Varanese" <alex@amvbooks.com> wrote in message
news:1163d895.0402032336.7cbfcabf@posting.google.com...
> I'm running an Atmel ARM7TDMI on a prototype board I wire-wrapped and
> am monitoring the system with an oscilloscope. By comparing the clock
> pulses to the read/write pulses, I'm finding that single-byte store
> and read operations are taking literally 50-100 clocks. Naturally this
> is unacceptable for any purpose, and is obviously a sign of something
> being majorly wrong. I've read all the literature on the ARM I can
> find including all of Atmel's documentation and white papers. Does
> anyone have any idea what this might be?

Does this implementation of the ARM7 also include programmable timing for
its memory interface (duration of reads, writes etc). I know the two devices
that I've used allow this.

In article <bvq7r9$vmals$1@ID-154333.news.uni-berlin.de>, 
graeme@hotmail.com says...
> "Alex Varanese" <alex@amvbooks.com> wrote in message
> news:1163d895.0402032336.7cbfcabf@posting.google.com...
> > I'm running an Atmel ARM7TDMI on a prototype board I wire-wrapped and
> > am monitoring the system with an oscilloscope. By comparing the clock
> > pulses to the read/write pulses, I'm finding that single-byte store
> > and read operations are taking literally 50-100 clocks. Naturally this
> > is unacceptable for any purpose, and is obviously a sign of something
> > being majorly wrong. I've read all the literature on the ARM I can
> > find including all of Atmel's documentation and white papers. Does
> > anyone have any idea what this might be?
> 
> Does this implementation of the ARM7 also include programmable timing for
> its memory interface (duration of reads, writes etc). I know the two devices
> that I've used allow this.
> 
> 
> 
I think you've got it.  The AT91R40807 that I used starts up the
system with 8 wait states on CS0.  One of the first steps in the 
boot process is to set an appropriate number of wait states for the
speed of the memory actually in use.

Another factor may be in the reading and storing of single bytes.
On a system with 16-bit memory width, single-byte reads and stores
can take some extra cycles while the bytes get properly aligned.
Storing a single byte may become a read-modify-write operation.

The OP didn't say whether the 50 to 100 clocks was the length
of a single read or write cycle, or the time for a complete
read-modify-write cycle.


Mark Borgerson

"Alex Varanese" <alex@amvbooks.com> skrev i meddelandet
news:1163d895.0402032336.7cbfcabf@posting.google.com...
> I'm running an Atmel ARM7TDMI on a prototype board I wire-wrapped and
> am monitoring the system with an oscilloscope. By comparing the clock
> pulses to the read/write pulses, I'm finding that single-byte store
> and read operations are taking literally 50-100 clocks. Naturally this
> is unacceptable for any purpose, and is obviously a sign of something
> being majorly wrong. I've read all the literature on the ARM I can
> find including all of Atmel's documentation and white papers. Does
> anyone have any idea what this might be?


If you run the AT9155800A at 32 kHz then your performance will drop
somewhat.
It would help if you told us which chip and clock frequency you use.
-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB