The thumb state of MC9328MXL

Hi,

I'm a software engineer and this is a question involved hardware and software of ARM920T that I'm not sure yet.

The hardware group designed a development board of MC9328MXL for our software enginees to work on it. When I look at the schemetic and dig into ARM920T documents, I'm confused on following question.

The hardware board uses only 16 bits of the data bus, i.e. 0-15 bit, the bit 16-31 are not connected. So the all memory chips are 16 bit memory chips too. I asked the reason, the answer is the plan is to use the thumb mode only and the thumb mode is 16 bit.

In section 4.1.1 of ARM DUI OO56B "ARM Developer Suite", there are 4 reasons that might be ARM state.

  1. ARM processes always start in ARM state.
  2. Functionality: such as no enable/disable interrupt in thumb mode
  3. Exception handling, the first part of exception handler must be within ARM state.
  4. Standalone thumb program. I'm not clear what here is talk about

For my understanding, the ARM state is required some time, even most of time the cpu is running in the thumb mode.

If the ARM state is required, does the hardware has to be 32 bit data bus available? can we have 16 bit only data bus?

Thanks for any help.

xugg

Reply to
xugg
Loading thread data ...

With 16-bit bus the processor running in ARM mode will make two memory accesses to fetch the instruction. Also all 32-bit data transfers will be in two 16-bit accesses. Depending on your requirements, Thumb mode might be quite sifficient. 16-bit mode also makes the board layout simpler. But if you would be asked to yield the maximum performance from the board, you would better intervene now (if it is not too late already :)

"The plan is to use the thumb mode only" sounds a bit worrying. Some

10+ years ago the company I was working for has decided to produce modems. The engineer who designed the schematics knew about registers of IBM PC/XT serial ports and Hayes AT commands, yet he decided to make it his own way. Result - at least two programmers have crashed their teeth trying to make it work under DOS. When the requirement came to use (any) standard packed driver and (any) standard communication stack, somebody suggested an ingenious idea -- to make another ISA-bus device, interceptor. It would catch I/O accesses to serial port registers (0x3f8-0x3ff) and cause an interrupt, and the interrupt handler (conveniently placed in the ROM of the interceptor) will do the dirty job of translating hayes commands into whatever necessary.

It was tough decision to bury the "fruits" of 2 years work.

Vadim

Reply to
Vadim Borshchev

Thumb isn't 16-bit - it is a 32-bit architecture. All data and addresses are 32-bits, it just happens that instructions are encoded as 16-bit quantities. In Thumb only the instruction fetches become 16-bits, while the majority of data accesses will remain 32-bits.

The SDRAM controller on the MC9328MXL however can translate

32-bit accesses into a sequence of 16-bit accesses, and therefore supports 32-bit accesses to 16-bit DRAMs. Since the 920T has a unified cache, most accesses are cached, so the performance penalty of the narrow bus will be small except when dealing with large quantities of data.

So the answer the hardware guys gave you is bogus, as you will be able to run ARM code without any problem, and in most cases without a huge penalty. The reason they chose for 16-bit SDRAM was cost, nothing else.

Not sure either about 4 - 1-3 already imply you can't create a Thumb-only programs (until architecture v6T2). I'd add:

  1. Performance - ARM code runs much faster than Thumb from a cache

The ARM core always requires a 32-bit bus, but the SDRAM controller can translate such accesses into 16-bit or even 8-bit ones on the external bus. It would typically stall the ARM core using wait states so that it only ever sees 32-bit accesses. In principle this could be done externally too on any ARM chip that didn't support a narrow bus. It is even possible to define a memory map where some regions are 32 bits, some are 16 bits and some are 8 bits.

Wilco

Reply to
Wilco Dijkstra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.