Santifort, Conor

Amber ARM-compatible core

I just started working with the amber project. I have installed all the tools and the repository in a VM centos 6.6(32bits) and I'm having problems in running the amber project scripts. For example, when I run the hello-world example I got:

Test hello-world, type 4
make -s -C ../mini-libc MIN_SIZE=1
arm-none-linux-gnueabi-gcc -c -Os -march=armv2a -mno-thumb-interwork -ffreestanding -I../include   -c -o boot-loader-serial.o boot-loader-serial.c
arm-none-linux-gnueabi-gcc -I../include    -c -o start.o start.S
arm-none-linux-gnueabi-gcc -c -Os -march=armv2a -mno-thumb-interwork -ffreestanding -I../include   -c -o crc16.o crc16.c
arm-none-linux-gnueabi-gcc -c -Os -march=armv2a -mno-thumb-interwork -ffreestanding -I../include   -c -o xmodem.o xmodem.c
arm-none-linux-gnueabi-gcc -c -Os -march=armv2a -mno-thumb-interwork -ffreestanding -I../include   -c -o elfsplitter.o elfsplitter.c
arm-none-linux-gnueabi-gcc -c -Os -march=armv2a -mno-thumb-interwork -ffreestanding -I../include   -c -o ../mini-libc/printf.o ../mini-libc/printf.c
arm-none-linux-gnueabi-gcc -I../include    -c -o ../mini-libc/libc_asm.o ../mini-libc/libc_asm.S
arm-none-linux-gnueabi-gcc -c -Os -march=armv2a -mno-thumb-interwork -ffreestanding -I../include   -c -o ../mini-libc/memcpy.o ../mini-libc/memcpy.c
arm-none-linux-gnueabi-ld -Bstatic -Map boot-loader-serial.map  --strip-debug --fix-v4bx -o boot-loader-serial.elf -T sections.lds boot-loader-serial.o start.o crc16.o xmodem.o elfsplitter.o ../mini-libc/printf.o ../mini-libc/libc_asm.o ../mini-libc/memcpy.o
arm-none-linux-gnueabi-objcopy -R .comment -R .note boot-loader-serial.elf
../tools/amber-elfsplitter boot-loader-serial.elf > boot-loader-serial.mem
../tools/amber-memparams32.sh boot-loader-serial.mem boot-loader-serial_memparams32.v
make: execvp: ../tools/amber-memparams32.sh: Permission denied
make: *** [boot-loader-serial_memparams32.v] Error 127
Error compiling boot-loader-serial


**I tried rolling back to some old versions of the project and got the same error. I think it mut be something in my configuration.
Do you have any idea on what is going on here ?

thanks for your help,

Rodrigo Fonseca

problems running tests

I went to verify the latest sources and I noticed that in the latest SVN version there has been some re-factoring of my patch (fair enough - it was a bit rough). It seems this breaks thousands of fuzz test results though :( 

The same tests pass when pointed at the unrefactored sources. :/

bics	r4, r12, #0x63 ... loop: 0 instruction: e3dc4063	Failed.
errors:	 expected,actual,bitwise difference  r4(0x738f3690,0x72b1479c,0x013e710c) r15(0x2c001011,0x2c001013,0x00000002)

initial: r0=0x7f68da85,r1=0x0f09f350,r2=0x24560884,r3=0x720a8380,r4=0x2b4886dd,r5=0x42ab98e5,r6=0x533f02ea,r7=0x33231392,r8=0x2b9bab45,r9=0x128241dd,r10=0x4e49468a,r11=0x2bebe2eb,r12=0x72b1479f,r13=0x1bfeffa1,r14=0x25006b80,r15=0x2eb73661,r8_firq=0x6a180405,r9_firq=0x37848102,r10_firq=0x2d0261dd,r11_firq=0x396443e2,r12_firq=0x738f36d1,r13_firq=0x5853619a,r14_firq=0x100d0c38,r13_irq=0x334b0228,r14_irq=0x650f8cff,r13_svc=0x2932006f,r14_svc=0x139fc17c,

arcem: r0=0x7f68da85,r1=0x0f09f350,r2=0x24560884,r3=0x720a8380,r4=0x738f3690,r5=0x42ab98e5,r6=0x533f02ea,r7=0x33231392,r8=0x2b9bab45,r9=0x128241dd,r10=0x4e49468a,r11=0x2bebe2eb,r12=0x72b1479f,r13=0x1bfeffa1,r14=0x25006b80,r15=0x2c001011,r8_firq=0x6a180405,r9_firq=0x37848102,r10_firq=0x2d0261dd,r11_firq=0x396443e2,r12_firq=0x738f36d1,r13_firq=0x5853619a,r14_firq=0x100d0c38,r13_irq=0x334b0228,r14_irq=0x650f8cff,r13_svc=0x2932006f,r14_svc=0x139fc17c,

amber: r0=0x7f68da85,r1=0x0f09f350,r2=0x24560884,r3=0x720a8380,r4=0x72b1479c,r5=0x42ab98e5,r6=0x533f02ea,r7=0x33231392,r8=0x2b9bab45,r9=0x128241dd,r10=0x4e49468a,r11=0x2bebe2eb,r12=0x72b1479f,r13=0x1bfeffa1,r14=0x25006b80,r15=0x2c001013,r8_firq=0x6a180405,r9_firq=0x37848102,r10_firq=0x2d0261dd,r11_firq=0x396443e2,r12_firq=0x738f36d1,r13_firq=0x5853619a,r14_firq=0x100d0c38,r13_irq=0x334b0228,r14_irq=0x650f8cff,r13_svc=0x2932006f,r14_svc=0x139fc17c,


I will keep checking.

Many fuzz test failures after refactor

To be able to run Amber on Altera FPGAs, you need to transform your ELF executable code into an Altera memory compatible HEX file.
Below is presented a method to achieve this.

A/ Modify file "sw\include\common.mk":

    1/ Add these two lines at the beginning of the file:
    HEX32  = $(addsuffix _32.hex,  $(basename $(TGT)))
    HEX128 = $(addsuffix _128.hex, $(basename $(TGT)))
    HEXCV  = ../tools/convert_hex.awk
    
    2/ Modify lines 95 and 97 accordingly:
    ifdef USE_MINI_LIBC
    debug:  mini-libc $(ELF) $(MMP32) $(MMP128) $(DIS) $(HEX32) $(HEX128)
    else
    debug:  $(ELF) $(MMP32) $(MMP128) $(DIS) $(HEX32) $(HEX128)
    endif
    
    3/ Then, add the following lines ("--gap-fill" option is important since it forces bytes in generated HEX file to be contiguous):
    $(HEX128): $(TGT)
      $(OC) -O ihex --gap-fill 0 --pad-to 0x4000 $^ tmp.hex
      $(HEXCV) -v width=16 tmp.hex > $@
      rm -f tmp.hex
      
    $(HEX32): $(TGT)
      $(OC) -O ihex --gap-fill 0 --pad-to 0x4000 $^ tmp.hex
      $(HEXCV) -v width=4 tmp.hex > $@
      rm -f tmp.hex
    
    4/ Modify line 131 accordingly:
    @rm -rfv *.o *.elf *.flt *.gdb *.dis *.map *.mem *.v $(MMP32) $(MMP128) $(HEX32) $(HEX128)
    
B/ Below is the "convert_hex.awk" source code to be put in "sw/tools/directory" (This file will parse objcopy-generated HEX file and will convert it to Altera memory HEX compatible format):

-------------------------------------------------
  #!/bin/awk -f
  
  BEGIN { k=0;  line = ""; crc = 0; addr = 0; }
  
  substr($0,8,2) == "00" {
  
    size  = strtonum( "0x" substr($0,2,2) );
  
    for ( i=0; i<size; i++ ) {
  
      j   = 10 + i * 2;
      str = substr($0,j,2);
      crc += strtonum( "0x" str );
      line = ( str line ); #swap bytes
      k++;
      if( ( k % width ) == 0 ) { printf ( ":%02X%04X00%s%02X\n",  width, addr, line, and( -( addr/256 + addr + width + crc ), 0xFF )  ); crc = 0; line = ""; addr += width; }
    }
  }
  
  END { print ":00000001FF"; }
-------------------------------------------------

C/ Create and instantiate your Altera boot memory:
 
 1/ In file "boot_mem32.v" if you use a23:

      altera_sram_4096x32_byte_en u_mem( 
       .address ( address     ),  // 4096 words, 32 bits
       .clock   ( i_wb_clk    ),
       .wren    ( start_write ),
       .byteena ( byte_enable ),
       .data    ( write_data  ),
       .q       ( read_data   )
     );
 
 2/ Or in file "boot_mem128.v" if you use a25:
 
     altera_sram_1024x128_byte_en u_mem( 
      .address ( address     ),  // 1024 words, 128 bits
      .clock   ( i_wb_clk    ),
      .wren    ( start_write ),
      .byteena ( byte_enable ),
      .data    ( write_data  ),
      .q       ( read_data   )
    );

  When creating the memory component with the Altera Mega Wizard, specify "rom_32.hex" for a23 initialization file and "rom_128.hex" for a25.
  
D/ Simulation:

  Before simulating your design, copy the generated HEX files "<your_code_name>_128.hex" or "<your_code_name>_32.hex" to "rom_128.hex" and "rom_32.hex" respectively into you simulation directory. 
  
E/ Synthesis:

  Copy files "rom_128.hex" or "rom_32.hex" into the Quartus project directory.
  
For people interested, I will provide soon a complete Amber port on Cyclone IV for the low cost BeMicro SDK platform (https://www.altera.com/b/bemicro-sdk.html) with LPDDR2 and Ethernet support.

Enjoy :-)

Method to initialize boot memory with executable code for Altera users

Altera users may have noticed that the synthesizer ignores initialization constructs like:

reg dummy = 1'b1;

Enabling the "NOT gate push back" options doesn't seem to solve that problem either.

Stephen Leary has proposed a nice script that parses the source code and generates "initial" blocks to setup registers.

Another solution to circumvent that problem without modifying the Amber source code is to use the "POWER_UP_LEVEL" directive inside the QSF file.
Below is the list of directives I use on my Quartus project. This list is quite minimalist. It may be possible to automate the generation of an exhaustive list with a script based on Stephen's one (http://pastebin.com/WyCJemH8).

List of directives to add in your QSF file (Paths may be updated to your hierarchy - Tested on Quartus 13.1 and 14.1):

set_instance_assignment -name POWER_UP_LEVEL LOW  -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_condition[0]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_condition[1]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_condition[2]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_condition[3]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_pc_sel[1]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_pc_wen"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_decode_iaccess"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_status_bits_mode[0]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_status_bits_mode[1]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_status_bits_irq_mask"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_status_bits_firq_mask"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_iaddress_sel[1]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a25_core:u_amber|a25_decode:u_decode|o_daddress_sel[1]"

set_instance_assignment -name POWER_UP_LEVEL LOW  -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_condition[0]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_condition[1]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_condition[2]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_condition[3]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_pc_sel[1]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_pc_wen"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_decode_iaccess"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_status_bits_mode[0]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_status_bits_mode[1]"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_status_bits_irq_mask"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_status_bits_firq_mask"
set_instance_assignment -name POWER_UP_LEVEL HIGH -to "system:u_system|a23_core:u_amber|a23_decode:u_decode|o_address_sel[1]"

Method to initialize Amber registers for Altera users

Here's a video showing Stephens latest patches allowing the Amber core not only to run riscos but to also run the best port of the Elite game in all its glory:

https://www.youtube.com/watch?v=YG_RhA6UBnk

Latest Amber patches enable Elite game

I've mentioned this one already but i'm going to raise it so that we dont lose track of it. The following code writes back to R14_usr instead of R14_svc. It was introduced by a different fix. I'll put a patch on for it later.

<p>
AREA    |main|, CODE, READONLY
        EXPORT  _start

	ORG	&1000
_start
	TEQP	PC,#3
	ADR	R14,datatable
	LDMIA 	R14!,{R0-R13}^
EXIT	
	NOP	
	NOP	
	
	SWI	&FFFFFF

	NOP
	NOP
		
datatable
	&	&0000003c
	&	&00000000
	&	&00000000
	&	&00000001
	&	&000010b8
	&	&0004b000
	&	&00000000
	&	&00000000
	&	&00001064
	&	&00050000
	&	&0381a290
	&	&0026dc06
	&	&00001000
	&	&01c01eb4
	

	END
</p>

LDM/STM Writeback base register

Really sorry... feel like the bad guy here but:- 

MOV R0,R0,RRX ignores the carry flag contents.

Code to demo...

        ;; setup the carry for the test
	;; could do this in program.cpp but
	;; doing this makes the test repeatable
	;; on a real Archie from BASIC V.
	MOV	R0,#0
	SUB	R1,R0,#1
	ADDS	R1,R1,#1
	;;Do the test
	MOV	R0,#0
	MOV     R0,R0,RRX
EXIT

Expected R0 = 0x80000000
Amber Actual R0 = 0

$ ./program/Va23_core bugs/rrxbug.bin 
Executing % on Amber/ArcEM Comparison
40
40
Failed.
errors:	 expected,actual,bitwise difference  r0(0x80000000,0x00000000,0x80000000) r15(0x60001027,0x60001023,0x00000004)

initial: r0=0x7e1d4e3c,r1=0x06f1d01b,r2=0x1d5d2ed9,r3=0x6f6f8292,r4=0x7c6b63c9,r5=0x2f69a363,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x00000003,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

arcem: r0=0x80000000,r1=0x00000000,r2=0x1d5d2ed9,r3=0x6f6f8292,r4=0x7c6b63c9,r5=0x2f69a363,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x60001027,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

amber: r0=0x00000000,r1=0x00000000,r2=0x1d5d2ed9,r3=0x6f6f8292,r4=0x7c6b63c9,r5=0x2f69a363,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x60001023,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

Verified on ArcEM/Real Archie. 

https://www.dropbox.com/s/dolx0o3pyfj1ces/A540RRXBug.JPG?dl=0

Broken Carry for MOV R0,R0,RRX

:( sorry but another carry issue...

TEQ and EOR should use the carry in it seems. Code to demonstrate is below.


	;; setup the carry for the test
	;; could do this in program.cpp but
	;; doing this makes the test repeatable
	;; on a real Archie from BASIC V.
	MOV	R0,#0
	SUB	R1,R0,#1
	ADDS	R1,R1,#1
	;;Do the test
	MOV	R4,#0
	MOV     R5,#&53000000
	TEQS    R4,R5
	;; flag a result to BASIC/Program.cpp
	MOVCC	R0,#1
	MOVCS	R0,#0

On a real archie/arcem R0 is 0, on Amber R0 comes back 1.

$ ./program/Va23_core bugs/teqbug.bin 
Executing Amber/ArcEM Comparison
52
52
Failed.
errors:	 expected,actual,bitwise difference  r0(0x00000000,0x00000001,0x00000001) r15(0x20001033,0x0000102f,0x2000001c)

initial: r0=0x7e1d4e3c,r1=0x06f1d01b,r2=0x1d5d2ed9,r3=0x6f6f8292,r4=0x7c6b63c9,r5=0x2f69a363,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x00000003,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

arcem: r0=0x00000000,r1=0x00000000,r2=0x1d5d2ed9,r3=0x6f6f8292,r4=0x00000000,r5=0x53000000,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x20001033,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

amber: r0=0x00000001,r1=0x00000000,r2=0x1d5d2ed9,r3=0x6f6f8292,r4=0x00000000,r5=0x53000000,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x0000102f,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

I have a photo of this running on an A540 and agreeing with ArcEM. Will post on request.

Carry issue with TEQ and EOR

For anyone looking for an MMU for this CPU core i've reimplemented the MEMC from the Archimedes A540 and verified it with the RISC OS 3 Post tests. It gives up to 16MB of RAM but has all the pains of the original Acorn MMU. Available from me at my open cores email address on request.

I aim to publish it as a core for MiST before too long.

MEMC Clone MMU Available

I can confirm that the barrel shift bug is fixed. However i found more issues (in fairness i've got things setup to hunt for differences). I *think* this was introduced by recent changes.

The following code shows up another carry issue. Its odd in that removing cmp or tst shows up no differences.

        AREA    |main|, CODE, READONLY
        EXPORT  _start

	ORG	&1000
_start

	MOV	R0,#2
	MOV	R1,#1
	MOV	R3,#&930

	CMP     R0,#1
	MOV     R1,R3
	TST     R1,#&10            ; =16
		
	MOVCS   R0,#1 ; Expected
	MOVCC   R0,#0 ; Actual

	NOP
	NOP

	; I use this to stop simulations... ignore.	
	SWI	&FFFFFF

	NOP
	NOP

	END

The above was compiled with ASASM. 

There is the output of the code running on my A540 with ARM3

https://www.dropbox.com/sc/h1emywrhd8m4wc2/AAAkJrP_0yuTb5tX39OWSouLa

Here is the output of the ArcEM vs Amber comparison tool.

stephen@development:~/svnwork/archie/bench/tests/fuzz$ ./program/Va23_core ../../tstbug2.bin
Executing % on Amber/ArcEM Comparison
56
56
Failed.
errors:	 expected,actual,bitwise difference  r0(0x00000001,0x00000000,0x00000001) r15(0x24001030,0x04001033,0x20000003)

initial: r0=0x7e1d4e3c,r1=0x06f1d01b,r2=0x1d5d2ed9,r3=0x6f6f8292,r4=0x7c6b63c9,r5=0x2f69a363,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x569d67a8,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

arcem: r0=0x00000001,r1=0x00000930,r2=0x1d5d2ed9,r3=0x00000930,r4=0x7c6b63c9,r5=0x2f69a363,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x24001030,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

amber: r0=0x00000000,r1=0x00000930,r2=0x1d5d2ed9,r3=0x00000930,r4=0x7c6b63c9,r5=0x2f69a363,r6=0x19430192,r7=0x0de580bf,r8=0x4c467585,r9=0x41ce04b8,r10=0x44a2b75b,r11=0x0b00c412,r12=0x3119e1f5,r13=0x6b052991,r14=0x66b52125,r15=0x04001033,r8_firq=0x304dc14d,r9_firq=0x611dec5a,r10_firq=0x1b088c0e,r11_firq=0x147c49d9,r12_firq=0x4ab42a1b,r13_firq=0x0e0912fe,r14_firq=0x464da53c,r13_irq=0x529e0ec9,r14_irq=0x4580ab03,r13_svc=0x5c49d017,r14_svc=0x322acccd,

More carry issues with TST

Found using an instruction fuzzer and comparing ArcEM with Amber in the same process (I can provide this setup as part of the testbench if needed but it will need a few things renamed in the sourcecode to work). 

All AND instructions passed the fuzzer comparison. Many ANDS instructions pass. Looks like a carry bug (see the bitwise difference) between arcem and amber. I've not been able to see why/how this is breaking yet.

ands
-------------------
ands	r12, r3, r2, ror #0x1f ... Passed.
ands	r13, r11, r6, ror #0x1b ... Passed.
ldrh	r11, [r7], -r5 ... Passed.
ands	r1, r12, r3, ror r6 ... operands: 3 loop: 95 instruction: e01c1673	Failed.
errors:	 expected,actual,bitwise difference  r15(0x20001011,0x00001011,0x20000000)

initial: r0=0x4d6755c4,r1=0x3fc69145,r2=0x0998d9f3,r3=0x2bc180b5,r4=0x175df823,r5=0x0e090b2b,r6=0x327e8200,r7=0x55f3f5f2,r8=0x63299e53,r9=0x6b3b9315,r10=0x1b0d3e09,r11=0x31d030e7,r12=0x683bb1d0,r13=0x3262f306,r14=0x5552b279,r15=0x6061cd35,r8_firq=0x02c5a1ff,r9_firq=0x2f007581,r10_firq=0x64008b42,r11_firq=0x0c6ecb4f,r12_firq=0x73c48d0a,r13_firq=0x384edc8b,r14_firq=0x77b2827f,r13_irq=0x3cd9e19c,r14_irq=0x50de00aa,r13_svc=0x4d7f5c84,r14_svc=0x12673cc3,

arcem: r0=0x4d6755c4,r1=0x23c08000,r2=0x0998d9f3,r3=0x2bc180b5,r4=0x175df823,r5=0x0e090b2b,r6=0x327e8200,r7=0x55f3f5f2,r8=0x63299e53,r9=0x6b3b9315,r10=0x1b0d3e09,r11=0x31d030e7,r12=0x683bb1d0,r13=0x3262f306,r14=0x5552b279,r15=0x20001011,r8_firq=0x02c5a1ff,r9_firq=0x2f007581,r10_firq=0x64008b42,r11_firq=0x0c6ecb4f,r12_firq=0x73c48d0a,r13_firq=0x384edc8b,r14_firq=0x77b2827f,r13_irq=0x3cd9e19c,r14_irq=0x50de00aa,r13_svc=0x4d7f5c84,r14_svc=0x12673cc3,

amber: r0=0x4d6755c4,r1=0x23c08000,r2=0x0998d9f3,r3=0x2bc180b5,r4=0x175df823,r5=0x0e090b2b,r6=0x327e8200,r7=0x55f3f5f2,r8=0x63299e53,r9=0x6b3b9315,r10=0x1b0d3e09,r11=0x31d030e7,r12=0x683bb1d0,r13=0x3262f306,r14=0x5552b279,r15=0x00001011,r8_firq=0x02c5a1ff,r9_firq=0x2f007581,r10_firq=0x64008b42,r11_firq=0x0c6ecb4f,r12_firq=0x73c48d0a,r13_firq=0x384edc8b,r14_firq=0x77b2827f,r13_irq=0x3cd9e19c,r14_irq=0x50de00aa,r13_svc=0x4d7f5c84,r14_svc=0x12673cc3,

Carry issue with ANDS

Picked up by my instruction Fuzzer

From http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/CIHIHGGJ.html

Syntax
MUL{cond}{S} Rd, Rm, Rs
MLA{cond}{S} Rd, Rm, Rs, Rn
where:
cond
is an optional condition code (see Conditional execution).
S
is an optional suffix. If S isspecified, the condition code flags are updated on the result of the operation (see Conditional execution).
Rd
is the ARM register for the result.
Rm, Rs, Rn
are ARM registers holding the operands.
r15 cannot be used for any of Rd, Rm, Rs, or Rn.
Rd cannot be the same as Rm.

So MUL r0,r0,r0 works perfectly on Amber but it doesnt work on any of the Emulators or a Real ARM. Just worth having a note of it here.

Multiply Inconsistency with Real ARM(tm)

In file "wishbone_arbiter.v":
-lines 280, 281, 282 : current_slave == 5'd5 -> current_slave == 4'd5 
-lines 288, 289, 290 : current_slave == 6'd6 -> current_slave == 4'd6

Operands size mismatch in comparison

In file "trunk\sw\boot-loader-ethmac\packet.c", function "parse_rx_packet", there is a typo in the following code:

  rx_packet->dst_mac[0] = buf[0];
  rx_packet->dst_mac[1] = buf[1];
  rx_packet->dst_mac[1] = buf[2]; -> should be: rx_packet->dst_mac[2] = buf[2];
  rx_packet->dst_mac[3] = buf[3];
  rx_packet->dst_mac[4] = buf[4];
  rx_packet->dst_mac[5] = buf[5];

wrong rx packet parsing

My local copy of Amber now boots RISC OS 3.

https://www.youtube.com/watch?v=jj3doUkCnV0

The LDMIA bug i raised today was the last bug i needed to fix to get RO3 to boot to the desktop properly. I also had to implement a translate flag via a wishbone tag and I had to implement data aborts. The data abort was almost implemented but didnt work because the cache write did not wait for external memory to acknowledge before doing the write to cache and acking the cpu. 

If anyone wants a copy of my modified A23 sources they will shortly be getting published as one of the the MiST project cores.

I spent 4-5 months debugging issues in Amber and my cores and i eventually hacked up ArcEM to spit out an instrumentation stream that i could compare to a filtered/processed version of the amber.dis. Step by step i found where the two simulations diverged. There are still some differences but they are getting less and less.

Amber now boots RISC OS 3

The following code should load R13_user with 01818af0 but instead loads it into r13_svc

_start
	;; ensure supervisor mode
	TEQP	PC,#3		
	ADR R13,datatable
	;; load into the usermode register bank!!!
        LDMIA   R13!,{R0-R14}^

done
	B	done
	NOP
	NOP

datatable
	& &03886448  
	& &00070010  
	& &00000010  
	& &0000027f  
	& &01818b04  
	& &00001480  
	& &ffffffff  
	& &000003be  
	& &0000028c  
	& &000400c0  
	& &0386cd1c  
	& &00000000  
	& &01801a84  
	& &01818af0  
	& &23885c00

Broken LDMIA for user mode register load

The V flag gets set by TST and TEQ. The manual says only the N,C and Z flags are affected. Sample code below.. 

	;; set the flags 
	TEQP	PC,#&90000000
	;; do the test
	MOV	R1,#0
	TST	R1,#0

	;; Flags should be 5 here (Z and V)
	;; on Amber the flags are 4 (Just Z)
	MOVVC	R0,#0
	MOVVS	R0,#1


And the same test also works for TEQ

	;; set the flags 
	TEQP	PC,#&90000000
	;; do the test
	MOV	R1,#0
	TEQ	R1,#0

	;; Flags should be 5 here (Z and V)
	;; on Amber the flags are 4 (Just Z)
	MOVVC	R0,#0
	MOVVS	R0,#1


In both cases the V flag is reset to zero instead of being preserved.

V Flag set by TST and TEQ.

The following code reproduces an interesting issue for me. It is run from the origin in supervisor mode.

        adr r3,datatable
        ldmfd R3!,{R0-R2,R4-R14}
        mov r3,#0

        ADD     R6,R6,#1
        CMP     R6,R8
        LDRLS   R3,[R9,R6,LSL #2]
        MOVLS   R4,R11
        MOVHI   R3,#0
        TEQLSP  PC,R10
        MOV     R12,R6             ; *** Not R8-R14
        MOV     R14,PC
        ;TEQP    R14,#&40000000

        b main

datatable
        &       &380b284        ; r0
        &       &380b294        ; r1
        &       &00000010       ; r2
        &       &00000010
        &       &00000000
        &       &00000000
        &       &00000000
        &       &00000000
        &       &00000000
        &       &0380b28d
        &       &00000024
        &       &0380b270
        &       &01c01f98
        &       &00000000

---

Basically I expect r12 to be set to 0x00000001 and r12_firq to be unset. However the amber.dis output is ...

000000014         0:   add     r3,  pc,  #40
000000016         4:   ldmia   r3!, {r0, r1, r2, r4, r5, r6, r7, r8, r9, r10, r11, ip, sp, lr}
000000019              read    addr 30, data 0380b284
000000021              read    addr 34, data 0380b294
000000023              read    addr 38, data 00000010
000000025              read    addr 3c, data 00000010
000000027              read    addr 40, data 00000000
000000029              read    addr 44, data 00000000
000000031              read    addr 48, data 00000000
000000033              read    addr 4c, data 00000000
000000035              read    addr 50, data 00000000
000000037              read    addr 54, data 0380b28d
000000039              read    addr 58, data 00000024
000000041              read    addr 5c, data 0380b270
000000043              read    addr 60, data 01c01f98
000000045              read    addr 64, data 00000000
000000048         8:   mov     r3,  #0
000000050         c:   add     r6,  r6,  #1
000000052        10:   cmp     r6,  r8
000000054        14:  -ldrls   r3, [r9, r6, lsl #2]
000000056        18:  -movls   r4,  r11
000000058        1c:   movhi   r3,  #0
000000060        20:  -teqpls  pc,  r10
000000062        24:   mov     ip, r6
000000064        28:   mov     lr,  pc
000000066        2c:   b       0
000000067              jump    from 2c to 0, r0 0380b284, r1 0380b294, r2 00000010, r3 00000000, r4 00000010, r5 00000000, r6 00000001, r7 00000000, r8 00000000, r9 00000000, r10 0380b28d, r11 00000024, r12 0380b270, r13 01c01f98, r14 2c000033, cc 2

Notice R12 is unchanged. I found this code in the RISC OS 3 operating system.

How did I find this? I am trying to boot RISC OS 3 on Amber core. I have found issues with the cpu core and i've instrumented the core against ArcEM archimedes emulator. I've been at this debugging for about 3 months.

Strange issue with r12 after TEQLSP

The following code 

      // set the carry up
      MOV  R1,#0xFFFFFFFF
      ADDS R1,R1,#1
      // do the test
      MOV  R1,#0x00800000
      TST  R1,#0x00FF0000
      MOVCC R0,#0
      MOVCS R0,#1

After this code executes on amber R0 is 1
After this code executes on a real arm R0 is 0

Also verified on ARM3,Armulator, ARM610 and StrongARM. 

I have however modified my version of Amber heavily but this seems to originate in the barrel shifter which i havent touched. I am using the non-FPGA version of the barrel shifter and i havent tried the FPGA version yet.

Carry flag possibly incorrectly set by TST

The following instruction 

  STRT    R1,[R9],#0

Is excecuted as though it was 

 STR    R1,[R9],#0

Similarly for LDRT.

I would expect this to drop the CPU core into User mode for the duration of the instruction which doesn't happen. I'm guessing this is because the core doesnt have a wishbone compliant way of announcing what mode the CPU is in during a memory cycle. This should also be added. 

This prevents Amber from passing hardware tests in some systems. I'm guessing you wont fix this but there should be a record of it.

Browse

Amber ARM-compatible core