External memory and AHB-lite bridge

[GTrannoy]

Hi,
I am using Microsemi IGLOO2 and Microsemi uses AMBA interfaces for their IP.

So I try to do a Wishbone-AHBLite bridge. I did it easily without special lock or burst and for 32bits.
I would have try to improve compatibility and I face to some questions.

1. In the documentation, it is mentioned that the processor can access the data address space in:

8 – byte (8-bit)-accessible (when writing)
16 – half-word (16-bit)-accessible (when writing)
32 – word (32-bit)-accessible (when writing)

I tried in a test program the following function to write a half-word only:

void HW_set_16bit_reg(uint32_t reg_addr, uint16_t value) {

  (*(IO_REG32 reg_addr)) = value;
} 

But I have an error 'Store address misaligned'. Have you any idea on how to proceed, pls ?

I precise that address is in the Data_address_space.

2. As it is mentionned above ''(when writing)'', I suppose it is needed a 32bits aligned address when reading. Isn't it ?

3. The AHBLite and Wishbone can support bursts. But, it seems to need [CTI_O] signal for the wishbone and it is not present on the top instance. So I supposed that Burst tansfers are not supportted. Am I right ? To be sure...

[stnolting]

This is strange.

I just tried your function using the ext_ram_c memory in the default testbench (this memory is located at base address F000.0000).

HW_set_16bit_reg(0xF0000000UL, 0x1234);
HW_set_16bit_reg(0xF0000002UL, 0x5678);
HW_set_16bit_reg(0xF0000004UL, 0xabcd);
HW_set_16bit_reg(0xF0000006UL, 0x0e0f);

I don't get any address alignment exceptions there... 🤔

Anyway. At first you should use IO_REG16 in your function since you only want to access 16-bit portions of memory. In your version you are writing 16-bit data to a 32-bit "pointer", which will make the compiler create "read-mask-modify-mask-write" memory operations. This works, but it is veeeery slow. So better use:

void HW_set_16bit_reg(uint32_t reg_addr, uint16_t value) {

  (*(IO_REG16 reg_addr)) = value;
} 

Second, you need to make sure that the address you are passing in reg_addr is always aligned to the quantity of data you want to write. In your case 16-bit - so the address has to be 16-bit (or "half-word) aligned:

reg_addr = 0x9000.0000 -> valid, 16-bit aligned
reg_addr = 0x9000.0001 -> INVALID, will raise an alignment exception
reg_addr = 0x9000.0002 -> valid, 16-bit aligned
reg_addr = 0x9000.0003 -> INVALID, will raise an alignment exception
...

By the way...
It is pretty clever to use the pre-defined IO_REG* macros! Seems like I totally forgot about these... I always use some ugly pointer (de-)referencing, but your solution is much more elegant! 👍

[stnolting]

Ok, maybe something with my setup... I have misalignement error on the address "0x900000002", "0x900000006",... for example. As returned in the MTVAL if i understand correctly.

That's correct.

Maybe it could be related with the linker file ?

I don't think so... The alignment check is done inside the CPU - so before any memory/IO/whatever access actually takes place.

I use the DMEM at address 0x8000_0000 with a size of 32*1024. I update the "neorv32.ld" file as mentionned in the documentation.

Did you also adapt the top's MEM_INT_IMEM_SIZE generic accordingly?

I have an external memory of 2MB that I address at 0x9000_0000. It is in the Data_address_Space and I think it tolerate 16bits and 8bits writing accesses.

Should be no problem (now) as the problems seems to be inside the CPU.

Or maybe the compiler has not correctly interpreted my '' (*(IO_REG32 reg_addr)) = value; '' ?...

I don't think so, but you could check out the generated assembly file.

There must be something else... Can you provide a code snippet where you call HW_set_16bit_reg?

And I could share you my wb-ahb bridge, even if not so complicated :-)

Thank you very much. That would be great! 👍

[GTrannoy]

Did you also adapt the top's MEM_INT_IMEM_SIZE generic accordingly?

Yes, I did it.

There must be something else... Can you provide a code snippet where you call HW_set_16bit_reg?

I comment parts to do differents access types and check if it is working with a sample table:

	                // Write 32bits
	                for(uint8_t h=0;h<10;h++) {
	                    HW_set_32bit_reg(SRAM_BASE+(h<<2), SRAM_INIT_VAL[h]);
	                }

	                // Write 16bits
	                /*for(uint8_t h=0;h<20;h++) {
	                    if ((h % 2) == 0) HW_set_16bit_reg(SRAM_BASE+(h<<1), (uint_fast16_t) (SRAM_INIT_VAL[h>>1] & 0xffff));
	                    else HW_set_16bit_reg(SRAM_BASE+(h<<1), (uint_fast16_t) ((SRAM_INIT_VAL[h>>1] >> 16) & 0xffff));
	                }*/

	                // Write 8bits
	        		/*for(uint8_t h=0;h<40;h++) {
	                    if ((h % 4) == 0) HW_set_8bit_reg(SRAM_BASE+h, (uint_fast8_t) (SRAM_INIT_VAL[h>>2] & 0xff));
	                    else if ((h % 4) == 1) HW_set_8bit_reg(SRAM_BASE+h, (uint_fast8_t) ((SRAM_INIT_VAL[h>>2] >> 8) & 0xff));
	                    else if ((h % 4) == 2) HW_set_8bit_reg(SRAM_BASE+h, (uint_fast8_t) ((SRAM_INIT_VAL[h>>2] >> 16) & 0xff));
	                    else HW_set_8bit_reg(SRAM_BASE+h, (uint_fast8_t) ((SRAM_INIT_VAL[h>>2] >> 24) & 0xff));
	                }*/

In the "asm" file, with my macro, I had:

00000c14 <HW_set_16bit_reg>:
     c14:	00b52023          	sw	a1,0(a0)
     c18:	00008067          	ret

With the macro you suggested (IO_REG16):

00000c14 <HW_set_16bit_reg>:
     c14:	00b52023          	sh	a1,0(a0)
     c18:	00008067          	ret

=> I can't test today, but I suppose this is the explanation ! Because 'sw' is for storing 32bits and 'sh' is for storing 16bits. So I think this is why I have misalignement errors.

You rox ! ;-)

=> Just to be sure, with my others questions: Reading is only 32bits and this is no Bursts ???

[stnolting]

I have tested the (commented?) "Write 16bits" part of your code snipped:

// Write 16bits
for(uint8_t h=0;h<20;h++) {
    if ((h % 2) == 0) HW_set_16bit_reg(SRAM_BASE+(h<<1), (uint_fast16_t) (SRAM_INIT_VAL[h>>1] & 0xffff));
    else HW_set_16bit_reg(SRAM_BASE+(h<<1), (uint_fast16_t) ((SRAM_INIT_VAL[h>>1] >> 16) & 0xffff));
}

with the following dummy data and address:

#define SRAM_BASE 0xF0000000UL // testbench dummy memory C base address

uint32_t SRAM_INIT_VAL[10] = {
  0xcafebabe,
  0x11112222,
  0x33334444,
  0x55556666,
  0x77778888,
  0x9999aaaa,
  0xbbbbcccc,
  0xddddeeee,
  0xffffabab,
  0xcdcdefef
};

and it works as expected - so no alignment exception:

=> I can't test today, but I suppose this is the explanation ! Because 'sw' is for storing 32bits and 'sh' is for storing 16bits. So I think this is why I have misalignement errors.

I think you are right! 👍

=> Just to be sure, with my others questions: Reading is only 32bits

The CPU also provides load operations to access 32-bit (lw), 16-bit (lh) and 8-bit (lb). You just need to use the right pointer type. For example:

uint16_t HW_get_16bit_reg(uint32_t reg_addr) {

  return (*(IO_REG16 reg_addr));
}

and this is no Bursts ???

Right, the CPU does not support burst operations yet. Without a cache, burst transfer do not make sense.
However, there already is an instruction cache, but unfortunately it still does not support bursts. As soon as I finished implementing the data cache I will focus on that 😉

[stnolting]

💡 By the way, <neorv32.h> provides some simple functions (using inline assembly) for loading/storing data directly from/to the address space, so you don't have to mess with pointers. Just make sure to pass correctly aligned addresses:

void neorv32_cpu_store_unsigned_word(uint32_t addr, uint32_t wdata);
void neorv32_cpu_store_unsigned_half(uint32_t addr, uint16_t wdata);
void neorv32_cpu_store_unsigned_byte(uint32_t addr, uint8_t  wdata);

uint32_t neorv32_cpu_load_unsigned_word(uint32_t addr);
uint16_t neorv32_cpu_load_unsigned_half(uint32_t addr);
uint8_t  neorv32_cpu_load_unsigned_byte(uint32_t addr);

[GTrannoy]

Thank you for this info ! It can be helpful.

[GTrannoy]

If it can help you, find attached the small bridge for wb to ahblite bus I made.
WB2AHBL.zip

[stnolting]

Thank you very much for handing out your bridge code!
I would like to add a NEORV32 top entity with AHB-lite interface instead of AXI-Lite to rtl/templates/system. I don't have a test setup for AHB right now, so it will take some time - but it's on the ToDo stack! 😉

By the way, are you still encountering problems with unaligned address exceptions?

[GTrannoy]

You are welcome !

By the way, are you still encountering problems with unaligned address exceptions?

It seems working correctly, but honestly, I had not well tested now... So I will tell you soon! ;-)