VexRiscv integration

[Dolu1990]

Hi,

There the VexRiscv integration, it was tested with the simple.py target with iverilog and on the DE1-SoC. Everything look fine (bios + serial).

Just notice that the reset vector of the CPU is fixed in the https://github.com/m-labs/VexRiscv-verilog project.

There is the GCC installation commands (from https://github.com/SpinalHDL/VexRiscv#build-the-risc-v-gcc) :

wget https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-20171231-x86_64-linux-centos6.tar.gz
tar -xzvf riscv64-unknown-elf-gcc-20171231-x86_64-linux-centos6.tar.gz
riscv64-unknown-elf-gcc-20171231-x86_64-linux-centos6.tar.gz
sudo mv riscv64-unknown-elf-gcc-20171231-x86_64-linux-centos6 /opt/riscv64-unknown-elf-gcc-20171231-x86_64-linux-centos6
sudo mv /opt/riscv64-unknown-elf-gcc-20171231-x86_64-linux-centos6 /opt/riscv
echo 'export PATH=/opt/riscv/bin:$PATH' >> ~/.bashrc 

On the DE1-SoC, the synthesis tool can go up to 133 Mhz. So with an Artix7, it should be capable to go at 200+ Mhz. If it doesn't, It is likely that some pipelining need to be added on the instruction/data bus. It is simple to do, and would not add noticable performance penality. Let's me know if it appear to be required in larger SoC.

Regards Charles

[mithro]

@cr1901 @enjoy-digital - FYI - You might be very interested in this pull request.

[sbourdeauducq]

Some quick comments (more related to VexRiscv):

• use synchronous reset
• can the reset vector be configurable, e.g. by making it an input port that then gets tied to a constant? We do use two CPUs with different reset vectors in ARTIQ.

[sbourdeauducq]

Also VexRiscv-verilog does not have to know about nor mention misoc (that can probably simplify the needlessly long path src/main/scala/misoc/cores/vexriscv).

[cr1901]

@mithro When this PR is merged, I'll make an equivalent PR for litex if @Dolu1990 has not done so already.

[sbourdeauducq]

can the reset vector be configurable, e.g. by making it an input port that then gets tied to a constant? We do use two CPUs with different reset vectors in ARTIQ.

Additionally different boards use different reset vectors (due to different memory layouts in the flash used for XIP). So, we really need that.

[sbourdeauducq]

Uses only 321 LUTs more than LM32 on Kasli - looking good.

[sbourdeauducq]

/home/sb/misoc/misoc/software/libbase/system.c: In function 'flush_l2_cache':
/home/sb/misoc/misoc/software/libbase/system.c:100:3: error: output operand constraint lacks '='
   __asm__ volatile("lw x0, 0(%0)\n":"r"(addr));
   ^~~~~~~
/home/sb/misoc/misoc/software/libbase/system.c:91:24: warning: unused variable 'dummy' [-Wunused-variable]
  register unsigned int dummy;
                        ^~~~~
/home/sb/misoc/misoc/software/libbase/system.c:100:3: error: output operand constraint lacks '='
   __asm__ volatile("lw x0, 0(%0)\n":"r"(addr));
   ^~~~~~~
/home/sb/misoc/misoc/software/libbase/system.c:100:3: error: invalid lvalue in asm output 0
Makefile:19: recipe for target 'system.o' failed
make: *** [system.o] Error 1

[sbourdeauducq]

sdram.c needs an update as well (use nop in cdelay).

[sbourdeauducq]

We got liftoff!

$ flterm --port /dev/ttyUSB_kasli-1_0
[FLTERM] Starting...

MiSoC BIOS
(c) Copyright 2007-2017 M-Labs Limited
Built Apr 24 2018 11:49:00

BIOS CRC passed (0edfc341)
Initializing SDRAM...
Read delays: 1:15-24  0:15-25  completed
Memtest OK
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
No boot medium found
BIOS> mr 0 256
Memory dump:
0x00000000  6f 00 00 0b 13 00 00 00 13 00 00 00 13 00 00 00  o...............
0x00000010  13 00 00 00 13 00 00 00 13 00 00 00 13 00 00 00  ................
0x00000020  23 2e 11 fe 23 2c 51 fe 23 2a 61 fe 23 28 71 fe  #...#,Q.#*a.#(q.
0x00000030  23 26 a1 fe 23 24 b1 fe 23 22 c1 fe 23 20 d1 fe  #&..#$..#"..# ..
0x00000040  23 2e e1 fc 23 2c f1 fc 23 2a 01 fd 23 28 11 fd  #...#,..#*..#(..
0x00000050  23 26 c1 fd 23 24 d1 fd 23 22 e1 fd 23 20 f1 fd  #&..#$..#"..# ..
0x00000060  13 01 01 fc ef 00 80 08 83 20 c1 03 83 22 81 03  ......... ..."..
0x00000070  03 23 41 03 83 23 01 03 03 25 c1 02 83 25 81 02  .#A..#...%...%..
0x00000080  03 26 41 02 83 26 01 02 03 27 c1 01 83 27 81 01  .&A..&...'...'..
0x00000090  03 28 41 01 83 28 01 01 03 2e c1 00 83 2e 81 00  .(A..(..........
0x000000a0  03 2f 41 00 83 2f 01 00 13 01 01 04 73 00 20 30  ./A../......s. 0
0x000000b0  17 11 00 10 13 01 01 f5 17 05 00 10 13 05 85 f4  ................
0x000000c0  97 05 00 10 93 85 c5 05 63 08 b5 00 23 20 05 00  ........c...# ..
0x000000d0  13 05 45 00 6f f0 5f ff 37 15 00 00 13 05 05 88  ..E.o._.7.......
0x000000e0  73 10 45 30 ef 00 90 4b 6f 00 00 00 f3 27 00 36  s.E0...Ko....'.6
0x000000f0  73 27 00 33 b3 77 f7 00 93 f7 17 00 63 84 07 00  s'.3.w......c...
BIOS> 

Apart from the few details I mentioned, looks really nice, congratulations.

[jbqubit]

Wow. That was quick from PR to run! Cool!

@Dolu1990 What are prospects for IEEE Floating point in VexRiscv? Wikipedia says this already part of the RISC-V v2.0 ISA.

[Dolu1990]

@jbqubit About floating point, sure, the RISC-V specification + compiler stuff fully support it.

Currently in VexRiscv nothing is implemented about it. Currently i'm focussing to get the support of the compressed instruction set, then maybe some rework on the datacache, and they why not the floating point stuff : D

[Dolu1990]

Everything should be fine now, let's me know if i skipped something

[whitequark]

Looks good to me after fixing the -nostartfiles part.