Santifort, Conor

Amber ARM-compatible core

Hi,

I followed the Amber Open Source Project User Guide to run a simulation (page 7).  However:

$ ./run.sh hello-world
Test hello-world, type 4
make -s -C ../mini-libc MIN_SIZE=1
../tools/check_mem_size.sh boot-loader-serial.mem "@000020"
make -s -C ../mini-libc MIN_SIZE=1
./run.sh: line 239: fuse: command not found

I have installed fuse-2.9.2-11.el7.x86_64. 

Looking forward to your reply

Fail to run simulations

i actually cant able to generate .mem file.kindly can anyone provide any solutions for it.

i am using windows gnu complier for this.does all scripts written will support?

,mem file

root@jayanth:/home/jayanth/proc_paper/amber_down/trunk/hw/isim# ./run.sh hello-world
Test hello-world, type 4
make -s -C ../mini-libc MIN_SIZE=1
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-ld: warning: crc16.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail
arm-none-linux-gnueabi-ld: warning: xmodem.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail
arm-none-linux-gnueabi-ld: warning: elfsplitter.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail
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
../tools/amber-memparams128.sh boot-loader-serial.mem boot-loader-serial_memparams128.v
arm-none-linux-gnueabi-objdump -C -S -EL boot-loader-serial.elf > boot-loader-serial.dis
../tools/check_mem_size.sh boot-loader-serial.mem "@000020"
make -s -C ../mini-libc MIN_SIZE=1
arm-none-linux-gnueabi-ld -Bstatic -Map hello-world.map  --strip-debug --fix-v4bx -elf2flt=-v -elf2flt=-k -o hello-world.flt -T sections.lds hello-world.o start.o ../mini-libc/printf.o ../mini-libc/libc_asm.o ../mini-libc/memcpy.o
arm-none-linux-gnueabi-ld: warning: ../mini-libc/printf.o uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail
arm-none-linux-gnueabi-ld: warning: ../mini-libc/memcpy.o uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail
arm-none-linux-gnueabi-ld: warning: cannot find entry symbol lf2flt=-k; defaulting to 00008000
hello-world.o: In function `main':
hello-world.c:(.text.startup+0xc): undefined reference to `__printf_chk'
hello-world.c:(.text.startup+0x18): undefined reference to `__printf_chk'
../include/common.mk:111: recipe for target 'hello-world.elf' failed
make: *** [hello-world.elf] Error 1

hello-world.elf failed

The Code Sourcery package mentioned in "2.2 Installing the Compiler" seems to be not for free anymore?

Greeting,
Benjamin

User Guide Update

I'm using mentor's code sourcery tool chain to compile c code for simulation.
When I do divide, I use __aeabi_idiv in mini-libc. It works really fine.
But with arm-none-linux-eabi library, the program doesn't work.
i.e. When I do divide using __aeabi_idiv which is in arm-none-linux-eabi library, it doesn't work at the simulation process.

When I use division function in mini-libc, simulation works and calculation results are fine.
However, when I use one in arm-none-linux-eaba library instead, simulation doesn't work and calculation results are incorrect.

Can I use function in arm-none-linux-eabi library?

Please let me know.

Really thanks for all your works.
Best and regards.
Dave

Division using gcc library

Hi,

For those of you that have an FPGA board without any UART connector available, you may be interested in the ALTERA JTAG UART feature and the nios2-terminal.
This can be achieved very simply by modifying  the file "uart.v" ( Revision 82 ) located into directory "hw\vlog\system\".

The procedure is the following:

1/ Insert the following line after line 171:

  wire tx_fifo_pop;
  
2/ Modify line 370 (formerly 369) accordingly:

  assign   tx_fifo_pop_not_empty = tx_fifo_pop && !tx_fifo_empty;

3/ Insert these two lines after line 426 ( formerly 425 )

  `ifndef ALTERA_JTAG_UART
   assign tx_fifo_pop = txd_state == TXD_STOP3 && tx_bit_pulse == 1'd1;

4/ Finally, add these lines after line 720 ( formerly 717 )

  `else
      
  `ifdef AMBER_SIM_CTRL
    reg r_ena = 1'b0;
    always@( posedge i_clk ) 
      r_ena <= ~r_ena; // dummy stuff for simulation
    assign rx_fifo_push = 1'b0;
  `else
    wire t_pause;
    wire r_ena;  
    alt_jtag_atlantic jtag_uart_alt_jtag_atlantic
      (
        .clk     (i_clk),
        .r_dat   (tx_byte),          // <- data to send
        .r_ena   (r_ena),            // -> allow to send data
        .r_val   (r_val),            // <- data is valid
        .rst_n   (1'b1),
        .t_dat   (rx_byte),          // -> received data 
        .t_dav   (~rx_fifo_full),    // <- data can be sent
        .t_ena   (rx_fifo_push),     // -> data is sent
        .t_pause (t_pause)
      );
  
    defparam jtag_uart_alt_jtag_atlantic.INSTANCE_ID = 0, // 0 for first instance, 1 for second instance
             jtag_uart_alt_jtag_atlantic.LOG2_RXFIFO_DEPTH = 6,
             jtag_uart_alt_jtag_atlantic.LOG2_TXFIFO_DEPTH = 6,
             jtag_uart_alt_jtag_atlantic.SLD_AUTO_INSTANCE_INDEX = "YES";
  `endif //AMBER_SIM_CTRL
    reg r_val;        
  	assign tx_fifo_pop = r_val;
    always@( posedge i_clk )
  	  r_val <= ~tx_fifo_empty & r_ena;	         
  `endif //ALTERA_JTAG_UART
  
5/ That's all folks! And there is no modification on software side...
Don't forget to define ALTERA_JTAG_UART in your verilog compiler settings.

6/ Invoking nios2-terminal
Open the nios2-shell ( menu ALTERA 15.0.0.145 Web Edition -> NIOS II EDS 15.0.0.145 -> NIOS II 15.0 Command Shell ) 
and type 'nios2-terminal'. If you have compiled your design with the 'boot-loader-serial' application, you are then able to send commands and see messages.

Cyril

Modification of "uart.v" to be able to use Altera JTAG UART

I'm trying to use example "boot-loader-ethmac".

In start.S file

        /* Switch to IRQ Mode */
        mov     r0, #0x00000002
        teqp    pc, r0
        /* Set IRQ Mode stack pointer */
        ldr     sp, AdrIRQStack

There is teqp opcode.

But I compile this start.S file, I get different disassemble result.

  78:	e3a00002 	mov	r0, #2
  7c:	e13ff000 	teq	pc, r0
  80:	e59fd26c 	ldr	sp, [pc, #620]	; 2f4 <AdrIRQStack>

I traced that operation in simulation. teqp operation has to do Exclusive OR operation. But it does operates like only teq in simulation.

I'm really confused about those issues.

Please let me know if you have any knowledge about this.
Thanks.

Opcode TEQP

Hello,

I'm trying to use interrupt controller with amber23.

I use whole source code you uploaded. So interrupt controller I use is included in hw source code.

I have few questions.
First, does your interrupt controller can control nested interrupts?
Second, like I said, I'm trying to use interrupt feature. But there are too less information about amber23 processor. Is there any reference design, code or documents?

I'm really digging to have processor working.

Thanks for all your works.
Dave.
Thanks.

Interrupt controller

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

Following the amber-user-guide.pdf, when I try to compile the boot-loader-serial I run into this error:

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-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
../tools/amber-memparams128.sh boot-loader-serial.mem boot-loader-serial_memparams128.v
arm-none-linux-gnueabi-objdump -C -S -EL boot-loader-serial.elf > boot-loader-serial.dis
../tools/check_mem_size.sh boot-loader-serial.mem "@000020"
Mem file boot-loader-serial.mem too big
make: *** [all] Error 1


The size of the generated .mem is 40K. 


Thanks, 
Ciprian

mem file too big

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

Re-opening this issue since I've identified a simple configuration to make it appear.

Considering the last Amber revision (86),

if we modify line 192 of file "main_mem.v" from: 
  assign o_wb_ack = i_wb_stb && ( start_write || start_read_d2 );

to:
  assign o_wb_ack = i_wb_stb && ( wr_en       || start_read_d2 );

This has the effect of delaying the wb acknowledge of one clock cycle, generating a wait state when writing to the main memory.
In this configuration, when the "boot-loader-ethmac" software is run in simulation for a23, Amber enters into an infinite loop when executing the instruction "push	{r3, lr}" at address 0x1003788. 
This is the first instruction of the "main" function.  
This issue does not appear when running this test with a25.

Load/store operations restarted when stalling (3)

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,

Browse

Amber ARM-compatible core