2

On our embedded platform, some devices have a 16-bit data bus (such as the FPGA). However, we need to read them as 32-bit values (such as 32-bit floating point).

My understanding is that when the 16-bit memory is accessed by a 32-bit data load instruction (LDR), the ARM processor will perform 2 16-bit fetches to assemble a 32-bit quantity.

Is this correct?

For example, I would like the ARM processor to load a uint32_t value from the device with 16-bit data bus without having to make 2 uint16_t reads then combine the uint16_t values into one uint32_t variable.

Do we need to explicitly fetch as 2 16-bit quantities and then assemble as a 32-bit quantity?

What ARM documents contain this clarification?

Are there any specific ARM configuration settings for the ARM to make 2 fetches from a 16-bit data bus to form a 32-bit quantity (in a register)?

FYI: We are using an ARM Cortex A8 and the IAR EW IDE/Compiler.
The platform is running is "system" mode and not "thumb" mode.

Thomas Matthews
  • 56,849
  • 17
  • 98
  • 154
  • User manual............. – Martin James May 13 '16 at 01:58
  • the amba/axi documentation. You have a cortex A8 with a 16 bit wide bus? I would assume a 64 bit wide, and maybe 32, but 16 makes no sense. BTW the bus and the processor takes care of all of this, see the amba/axi docs. an 8 word stm instruction against a 64 bit wide axi at an address that is not 64 bit aligned results in at a minimum one length 1 transfer for the odd word, then a length 3 transfer and another length 1 to take care of the other odd word. all magically handled by the hardware, software never needs to care. – old_timer May 13 '16 at 02:58
  • (unless you are pushing the performance of the platform or you are testing the chip design) – old_timer May 13 '16 at 02:59
  • all of this is handled within the chip, if your fpga is on some bus on that chip then you have to look at that chip vendors documentation. if you are using an arm within an fpga then you might have direct access to the amba/axi or you may have to look at the fpga chip vendors documentation. no matter what it is all well documented, depending on what interface you are attaching to. – old_timer May 13 '16 at 03:01
  • you are grossly overcomplicating this, also thumb mode is irrelevant here, it gets converted into arm instructions and then fed into the pipe and/or it has nothing to do with the amba/axi bus nor other busses on the far end of that, nothing on the bus indicates the instruction set decoders being used. – old_timer May 13 '16 at 03:03
  • No one can answer the question without more details on how the FPGA is connected to the CPU. Is it on an AHB bus, an AXI bus, some custom bus. Rule for how the interaction between the ARM CPU and FPGA are defined by the bus. Is there a signal to mask bytes on the bus? Then it probably supports partial reads (ie 16bits on 32/64 bit bus). Your hardware people have work to do or explain thing better to you. HW people can overcome this by decoding the address properly. Ie, 16 bits register address increment by 2/4/8 etc. It seems like your HW people need some help? This is not the place. – artless noise May 13 '16 at 13:16

1 Answers1

0

If you are accessing memory, when the CPU required 32-bit of memory, it will request it directly (Cortex-A8 does not support 16-bit busses). Some peripheral (In the system) is responsible for converting the 32-bit request to 16-bit to adapt to the bus (Doing 2 transfers).

It means that for the CPU is should be totally transparent.

Dric512
  • 3,525
  • 1
  • 20
  • 27
  • I don't understand. We have MRAM and it is 16-bits wide. Our FPGA has 16-bit registers. Did our H/W team make a big mistake because you say Cortex-A8 doesn't support 16-bit data bus. – Thomas Matthews May 13 '16 at 06:29
  • 1
    @ThomasMatthews Well, the data bus on the actual Cortex-A8 block itself [is either 64 or 128 bits wide depending on configuration](http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Cacjeigj.html), your RAM chips are almost certainly hanging off some kind of memory controller which might itself typically have a 32 or 64-bit wide interface to the system side, and there are likely various other upsizers and downsizers around the interconnect in between. Consider making friends with the hardware guys and asking them for an overview of exactly how your chip fits together ;) – Notlikethat May 13 '16 at 07:59