xuantie-rv / openc906 Goto Github PK

I have a problem with the LWD instruction. The mnemonic is not compatible with the opcode. Can you explain to me how it should look like correct?

Mnemonic:
lwd rd, imm7(rs1)
opcode:
11100 imm2 rd2 rs1 100 rd1 0001011

It seems that critical signals relative to the vector unit are hardcoded to zero.
Some examples:

1. The VS bits in mstatus
   https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/cp0/rtl/aq_cp0_trap_csr.v#L505
2. Decoder signals
   https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/idu/rtl/aq_idu_id_decd.v#L1011
   https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/idu/rtl/aq_idu_id_decd.v#L934
   https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/idu/rtl/aq_idu_id_decd.v#L3740

I tried to run some vector code, but it always triggers exceptions on the vector instructions (if I fix some of the hardcoded values, the exception is generated by some other disabled signals). This makes me think that the code was generated with incorrect settings, or that this version of the processor simply does not support the V extension. Can this be the case? If yes, are there any plans to open-source it?

Thanks a lot,
Matteo

Hello,
I have followed the steps in 'README.md' and run simulation of the testcases.
But unfortunately the 'ISA_INT' testcase showed 'simulation finished with error'.

I tried to locate the problem, and I found it in C906_INT_SMOKE.obj:

0000000000000ec0 <AUIPC>: 
     ec0:	00000117          	auipc	x2,0x0   
     ec4:	61a9                	lui	x3,0xa  
     ec6:	21b9                	addiw	x3,x3,14  
     ec8:	910e                	add	x2,x2,x3    //00000000_0000aece
     eca:	0000a217          	auipc	x4,0xa      //00000000_0000aeca -> not equal to 0000aece
     ece:	00410463          	beq	x2,x4,ed6 <AUIPC+0x16>  
     ed2:	1ab0206f          	j	387c <TEST_FAIL>
     ed6:	00000117          	auipc	x2,0x0 
     eda:	0010019b          	addiw	x3,x0,1 
     ede:	01fe                  	slli	x3,x3,0x1f
     ee0:	01d1                	addi	x3,x3,20
     ee2:	0021813b          	addw	x2,x3,x2    //ffffffff_80000eea
     ee6:	80000217          	auipc	x4,0x80000  //ffffffff_80000ee6 -> not equal to 80000eea
     eea:	00410463          	beq	x2,x4,ef2 <ADD>
     eee:	18f0206f          	j	387c <TEST_FAIL>

These two inequalities lead to the jumps to <TEST_FAIL>, and then the simulation finished with error.

The corresponding C906_INT_SMOKE.s is:

.global AUIPC
AUIPC:
      auipc x2, 0x0
      li x3, 0xa00e
      c.add x2, x3
      auipc x4, 0xa
      bne x2, x4, TEST_FAIL
      auipc x2, 0x0
      li x3, 0x80000014
      addw x2, x3, x2
      auipc x4, 0x80000
      bne x2, x4, TEST_FAIL
      .option norvc

After I changed it into:

.global AUIPC
AUIPC:
      auipc x2, 0x0
      li x3, 0xa00a         //changed here
      c.add x2, x3
      auipc x4, 0xa
      bne x2, x4, TEST_FAIL
      auipc x2, 0x0
      li x3, 0x80000010 //changed here
      addw x2, x3, x2
      auipc x4, 0x80000
      bne x2, x4, TEST_FAIL
      .option norvc

the 'ISA_INT' simulation finished successfully.
My question is: "Is it a bug in 'ISA_INT' testcase?"

Here is my operating environment:
OS: Ubuntu 20.04
Tool: Xuantie-900-gcc-elf-newlib-x86_64-V2.4.0-20220428
Simulation: iverilog 10.3

I have seen mention of an 3d graphics driver for the C906. Does anyone have more information about this? I believe it is for android, but I would like to use it on linux if possible, but android is ok too.

The datasheet only gives a cursory overview of the processor. Is there a more detailed manual (reference or programmers manual) that can also be added?

I'm not sure this is the correct place to report this, but I've got an mango pi mq pro soc with an allwinner d1 cpu, which is supposed to be an C906 chip.

I recently ran into a problem, when I ran vmsgt.vx v8, v8, a3, which give an illegal instruction, while vmsgt.vx v16, v8, a3 didn't do so (the vector unit was enabled for both).

I haven't found anything in the spec suggesting vmsgt.vx shouldn't work when the source register is also the destination register, compilers generate this type of code and qemu interprets it just fine.

Can anybody reproduce this?

I've been browsing the source code for some time now, but with my limited understanding of hardware design I wasn't able to find where/if the problem occurs here.

e.g. https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/mmu/rtl/sysmap.h#L3

Hello everyone,

I tried to use the printf function within a test program, but it does not work. While debugging, I found some potential problems in the system + environment.

TL;DR:

1. If you just need to have a working printf, change this address and this address to 0x90000000.
2. To avoid possible errors with custom programs, remove this file.

Details:

1. The TB checks the write address biu_pad_awaddr against 32'h10015000 to find a write
   https://github.com/T-head-Semi/openc906/blob/main/smart_run/logical/tb/tb.v#L285
   but the fputc function does not store to that address.
2. There are two definitions of the fputc function:
   https://github.com/T-head-Semi/openc906/blob/main/smart_run/tests/lib/clib/fputc.c
   https://github.com/T-head-Semi/openc906/blob/main/smart_run/tests/lib/clib/printf.c
   From what I see, coremark compiles only because the file tests/lib/newlib_wrap/clib/printf.c is overwritten by tests/lib/newlib_wrap/printf.c (https://github.com/T-head-Semi/openc906/blob/main/smart_run/setup/smart_cfg.mk#L59)
3. I suppose that the definition in https://github.com/T-head-Semi/openc906/blob/main/smart_run/tests/lib/clib/printf.c is wrong, as it uses a non-standard instruction to load a value from a shifted address, with the wrong syntax.
4. https://github.com/T-head-Semi/openc906/blob/main/smart_run/tests/lib/clib/fputc.c makes sense, but the address is not the one checked by the TB.
5. I removed the https://github.com/T-head-Semi/openc906/blob/main/smart_run/tests/lib/clib/printf.c file, and fixed the address here and here, and printf now works.
6. The address to be checked cannot be the one suggested, and cannot be the one used by the c910 core. The write of the fputc function must go to the top without stopping at the cache (so it must be in a non-cacheable region). The manual says that when virtual memory is not used, the PMA settings can be found in C906_RTL_FACTORY/gen_rtl/mmu/rtl/sysmap.h. There, we see that up to 0x8fffffff, the region is cacheable (the settings for c910 are different). Then, up to 0xbfffffff, it is not cacheable.
7. If we set the address to 32'h9000_0000 (both in the tb.v and in the fputc.c), printf works.

Be aware that if you want to use peripherals, either the sysmap.h or the APB rules must be changed, as it seems to me that the UART and all the other peripherals are in the cacheable region as well. So, I guess the best thing to do would be to remap the peripherals and the sysmap.h to have something consistent.

Thanks in advance for further suggestions and comments!
Matteo

No translation for 2 out of 3 documents in doc/ folder.

1. 能否重新提供钉钉群的二维码？
2. 是否还有其他交流群？如果有的话，可以提供加入/联系方式吗？

Data cache tag SRAM must be 128X58, not 64X58. Please check it.
-- I was wrong. There are no errors.

https://github.com/T-head-Semi/openc906/raw/main/doc/%E7%8E%84%E9%93%81C906%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C.pdf

Found some issues in the programming manual that is inconsistent with RISCV spec.
Are those documentation only errors?

Page 150 (Page 167 in the PDF)
FDIV.S
it says fs1 in [24:20], fs2 in [19:15],
but it should be fs2 in [24:20], fs1 in [19:15]

Page 194 (Page 211 in the PDF)
C.FLD
it says [15:13] is 011, which should be 001

Page 201
C.LUI
it says rd ! = 0, which should be rd != 0 && rd != 2,
otherwise it would be ambiguous with C.ADDI16SP

Page 205
C.SD
In instruction encoding, rd should be rs2