Amber ARM-compatible core

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,

Annoyingly truncated my registers

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,

Here are the full fuzzer results. I'm making the assumption that ArcEM is correct (which is mostly seems to be) but I guess that isnt guaranteed. ArcEM does run RISC OS 3 reliably and Amber has crashes and glitches. (less now than before though!!! - thanks to recent work by Conor).

http://pastebin.com/XpFfAH6a

In all failure cases it will give the opcode in hex. The disassembler is libdisarm from google code.

My code to do this fuzzing can be included in Amber upon request. However it needs the a23_decompile module to be modified quite a bit (I have it setup so that -DA23_DECOMPILE is specified at compile time rather than in a .vh file, and i found that verilator does not like using the wire/register "type". So i changed them to itype. I also put the clk_count into decompiler so the whole thing is self contained).

Here is the fuzzer code used.

https://www.dropbox.com/s/2e7u4qsj94wci89/fuzzer.tgz?dl=0

https://www.dropbox.com/s/u5iovqsl2avhnda/amber23_fixes.diff?dl=0

This patch fixes all open amber23 bugs.

1. Fixes all the carry issues (verified with a fuzz - will post the fuzz result)
2. Fixes all the rrx issues.
3. Fixes the LDM/STM issue

Also patches the use of the wire/reg name type to itype. This is a reserved keyword on some verilog variations.

Note this patch doesnt include my Data abort fixes or the translate pin additions (Implemented as o_wb_tga).

Here are the fuzz results...

https://www.dropbox.com/s/nwjfok2fqzh0ut1/soak_patch.txt?dl=0

Summary....

Executed: 44124768 Skipped: 32 Passed: 44124768 Failed: 0

I wouldnt swear that all the bugs are gone but i'd say this was a big step forward in confidence.

Code changes from Stephen added to release 87 for a23, and release 88 for a25. This fixes the issue.