openrisc / or1k-tests

Unified OpenRISC 1000 test suite
8 stars 11 forks source link

Docs #2

Open markNZed opened 7 years ago

markNZed commented 7 years ago

Is there a testbench for the verilog RTL version of or1k ? Are there any docs on how to set that up ? Are there any coverage results available ? Thanks.

olofk commented 7 years ago

Hi,

There are basically two ways to do this. Either use the old infrastructure from orpsocv2. Please note however that this is no longer maintained and only works with the legacy or1200 implementation.

The preferred way to do it is instead to use FuseSoC (https://github.com/olofk/fusesoc) Once installed, you can run fusesoc sim mor1kx-generic --elf-load=<your compiled testcase> to run one of the testcases in or1k-tests

I wrote a quick script a while ago to run all the or1k-tests with FuseSoC. You can find it here https://gist.github.com/olofk/76b0b04181a7edd002a7529cf97ea325 Adapt as you want and don't hesitate to ask for further assistance

markNZed commented 7 years ago

Thanks. Running or1k-alignillegalinsn with your script I get errors in verilator.err.log Do you see the same error ?

%Error: ../src/uart16550_1.5.4/rtl/verilog/uart_transmitter.v:275: syntax error, unexpected INTEGER NUMBER, expecting IDENTIFIER or ')' %Error: ../src/elf-loader_1.0/elf-loader.c:21: syntax error, unexpected '#' %Error: ../src/elf-loader_1.0/elf-loader.c:21: Unsupported: Verilog 2001-config reserved word not implemented; probably you want include instead: include %Error: ../src/elf-loader_1.0/elf-loader.c:22: Unsupported: Verilog 2001-config reserved word not implemented; probably you wantinclude instead: include %Error: ../src/elf-loader_1.0/elf-loader.c:23: Unsupported: Verilog 2001-config reserved word not implemented; probably you want include instead: include %Error: ../src/elf-loader_1.0/elf-loader.c:24: Unsupported: Verilog 2001-config reserved word not implemented; probably you wantinclude instead: include %Error: ../src/elf-loader_1.0/elf-loader.c:25: Unsupported: Verilog 2001-config reserved word not implemented; probably you want include instead: include %Error: ../src/elf-loader_1.0/elf-loader.c:26: Unsupported: Verilog 2001-config reserved word not implemented; probably you wantinclude instead: include %Error: ../src/elf-loader_1.0/elf-loader.c:27: Unsupported: Verilog 2001-config reserved word not implemented; probably you want `include instead: include %Error: ../src/elf-loader_1.0/elf-loader.c:42: syntax error, unexpected if %Error: ../src/elf-loader_1.0/elf-loader.c:50: syntax error, unexpected IDENTIFIER %Error: ../src/elf-loader_1.0/elf-loader.c:90: syntax error, unexpected if %Error: ../src/elf-loader_1.0/elf-loader.c:143: syntax error, unexpected if %Error: Exiting due to 13 error(s) %Error: Command Failed /usr/bin/verilator_bin -f mor1kx-generic_0.vc -Wno-fatal --trace make: *** [Vorpsoc_top.mk] Error 10

olofk commented 7 years ago

I do recognize this error. Let me have a look and I get back to you.

Also, I remembered that some of the tests might not pass, as they have dependencies on old infrastructure, and we haven't properly updated all the tests yet. They should all compile though

olofk commented 7 years ago

ok, this should be fixed now. You need an updated elf-loader. Just run fusesoc update and you shall hopefully have access to elf-loader 1.0.1 (you can verify by running fusesoc core-info elf-loader and see that it says 'ame: ::elf-loader:1.0.1` at the top). Let me know if it helps

markNZed commented 7 years ago

The update with some warnings including:

WARN:  plusargs section is deprecated and will not be parsed by FuseSoC. Please migrate to parameters in ::elf-loader:0

But also reports orpsoc-corecs and fusesoc-cores as "Already up-to-date"

Running fusesoc core-info elf-loader returns Name: ::elf-loader:1.0

I'm getting the same error when running the test, I guess because elf-loader is not updated

Can you give me the name of a test that is know to pass ? I'm using or1k-basic

Removing the directory .local/share/fusesoc/fusesoc-cores/elf-loader then running fusesoc update did not download the elf-loader (I'm not sure if it should). I tried deleting .local/share/fusesoc and running fuses init which downloaded elf-loader:1.0 again

What can I do to download elf-loader:1.0.1 ?

olofk commented 7 years ago

Hi again,

I realize that you managed to hit a number of unrelated bugs. Sorry about that :/

Regarding elf-loader, it turns out I never pushed the new version to fusesoc-cores (fusesoc-cores is the new library that eventually will replace orpsoc-cores). That is done now, and you should be able to run fusesoc update to get it. If this still doesn't work, you can clone https://github.com/fusesoc/elf-loader somewhere and run fusesoc with --cores-root=/path/to/cloned_repo as the first argument to force FuseSoC to use this version instead.

The warnings about plusargs can be ignored, and will eventually go away as we leave the old orpsoc-cores repo behind. It's a backwards-compatible thing

The other thing I noticed is that or1k-alignillegalinsn was one of the five tests that still doesn't work properly after the migration from orpsocv2. So ignore or1k-alignillegalinsn, or1k-intloop, or1k-intmulticycle, or1k-intsyscall and or1k-inttickloop for now. or1k-basic works just fine

...but.. I just rewrote the verilator backend for FuseSoC and discovered now that I introduced a few bugs (mostly related to running with the --keep argument. It might be safer to use Icarus verilog or modelsim as your simulator instead. (Run with --sim=modelsim or --sim=icarus. Skipping the --sim argument completely will use Icarus as it is set as the default simulator)

I'm taking the opportunity here to fix the bugs in FuseSoC and trying to make the rest of the tests pass

markNZed commented 7 years ago

No pb. I now have elf-loader:1.0.1

Is the script fusesoc_multi_launch.py intended to run from a specific directory ? e.g. from the directory above or1k-tests

I have a directory structure:

or1k or1k/or1k-tests or1k/fusesoc_multi_launch.py

When running python fusesoc_multi_launch.py I see the message "Killing or1k-basic"

In build/mor1kx-generic_0/sim-icarus/icarus.log I have 4 lines:

orpsoc_tb.dut.mor1kx0.bus_gen.ibus_bridge: Wishbone bus IF is B3_REGISTERED_FEEDBACK
orpsoc_tb.dut.mor1kx0.bus_gen.dbus_bridge: Wishbone bus IF is B3_REGISTERED_FEEDBACK
No ELF file specified
                   0 : Illegal Wishbone B3 cycle type (xxx)

I've modified fusesoc_multi_launch.py to only run or1k-basic with --sim=icarus

I've also tried running:

fusesoc sim --build-only mor1kx-generic 
fusesoc sim --keep mor1kx-generic --elf-load or1k-tests/native/build/or1k/or1k-basic

which gives the same error message "No ELF file specified"

Am I missing a step for generating the ELF file ?

olofk commented 7 years ago

fusesoc_multi_launch.py was just something I quickly threw together as a response to https://github.com/openrisc/orpsoc-cores/issues/109 . I do think I should clean it up and put a proper version in or1k-tests in the future, but it still has some rough edges with hardcoded paths and timeouts.

I can't see a reason however why it shouldn't work to run fusesoc directly as you have also tried. Is there any difference if you build and run in one stage, i.e. fusesoc som mor1kx-generic --elf-load=or1k-tests/native/build/or1k/or1k-basic ? Just to test, you could try to supply the absolute path to the file. Shouldn't be needed, but I'm running out of ideas right now

Oh wait.. you did compile the test cases, right? Running make from the native subdirectory should build them

markNZed commented 7 years ago

Hi,

I was not running make in the native dir, when I do:

make -C lib/
make[1]: Entering directory '...../or1k/or1k-tests/native/lib'
or1k-elf-gcc -c cache.S -o cache.o
cache.S:1:23: fatal error: or1k-sprs.h: No such file or directory

Where should or1k-sprs.h be ? Thanks.

I found the file in https://github.com/openrisc/newlib and copied it to /opt/or1k-toolchain/or1k-elf/include

Now when running fusesoc sim --keep mor1kx-generic --elf-load or1k-tests/native/build/or1k/or1k-basic I see:

No ELF file specified

in the icarus.log but or1k-tests/native/build/or1k/or1k-basic is an ELF file now

Running with fusesoc --verbose I see:

INFO: vvp -n -M. -l icarus.log -melf-loader_1.0.1 -mjtag_vpi_0-r2 fusesoc.elf -lxt2

which does not have the plusarg for the ELF file.

I tried:

cd build/mor1kx-generic_0/sim-icarus
vvp -n -M. -l icarus.log -melf-loader_1.0.1 -mjtag_vpi_0-r2 fusesoc.elf -lxt2 +elf_load=../../../or1k-tests/native/build/or1k/or1basic

This gives:

elf-loader: ../../../or1k-tests/native/build/or1k/or1k-basic was loaded
Loading         734 words
                   0 : Illegal Wishbone B3 cycle type (xxx)
report(0x8000000d);
exit(0x00000000);

What does the message "Illegal Wishbone B3 cycle type (xxx)" mean ? Is it expected ? How do I know if the test ran successfully ?

I ran across https://olofkindgren.blogspot.fr/2016/08/fusesoc-15.html :

"The old [plusarg] sections that were deprecated in favor of the [parameter *] sections are no longer parsed as I have decided that users have had enough time to migrate to the parameter sections. The warning still remains to remind everyone that it's time to move on and the article about FuseSoC 1.4 has more info on what the [parameter] sections should look like."

I guess this is different from plusarg arguments but maybe something was changed there too.

olofk commented 7 years ago

I've never seen an issue with a missing or1k-sprs.h before. Very strange. I'll try do dig into that. Great that you found a solution for now. Could you tell me where you got your toolchain (precompiled or built from source? Where did you find instructions?)

I also see now that you managed to uncover another bug in FuseSoC. Try running without the --keep flag for now. It will rebuild the simulation model for each run, but that's pretty quick so it shouldn't be a problem in practics.

The illegal wishbone cycle warning is expected. It's a false warning, and I should fix that. The test ran successfully. report(0x8000000d) is supposed to be read as gooooood (Yeah, I know. It's far from obvious :)). Combined with exit(0x00000000), it means that the test was ok.

markNZed commented 7 years ago

I think the issue with or1k-sprs.h is caused by my build script cleaning up the src & build directory after installation. I guess or1k-sprs.h is not copied into /opt/or1k-toolchain/or1k-elf/include/or1k-sprs.h by the install script ?

I'm building the toolchain based on: https://github.com/embecosm/chiphack/wiki/OpenRISC-tools-install

Here is the build script (I'm using Docker):

RUN apt-get -y --no-install-recommends install automake build-essential make gcc g++ flex bison patch texinfo libncurses5-dev libmpfr-dev libgmp3-dev libmpc-dev libzip-dev python-dev libexpat1-dev libftdi-dev libtool autoconf libftdi-dev subversion libelf-dev elfutils &&\
    cd /home/USER &&\
    mkdir or1k &&\
    cd or1k &&\
    wget https://github.com/openrisc/or1k-src/archive/or1k.zip &&\
    unzip or1k.zip &&\
    rm or1k.zip &&\
    mv or1k-src-or1k or1k-src &&\
    wget https://github.com/openrisc/or1k-gcc/archive/or1k.zip &&\
    unzip or1k.zip &&\
    rm or1k.zip &&\
    mv or1k-gcc-or1k or1k-gcc &&\
    mkdir /opt/or1k-toolchain &&\
    export PATH=$PATH:/opt/or1k-toolchain/bin &&\
    mkdir bld-or1k-src bld-or1k-gcc &&\
    cd bld-or1k-src &&\
    ../or1k-src/configure --target=or1k-elf --prefix=/opt/or1k-toolchain --enable-shared --disable-itcl --disable-tk --disable-tcl --disable-winsup --disable-libgui --disable-rda --disable-sid --disable-sim --disable-gdb --with-sysroot --disable-newlib --disable-libgloss --disable-werror &&\
    make &&\
    make install &&\
    cd ../bld-or1k-gcc &&\
    ../or1k-gcc/configure --target=or1k-elf --prefix=/opt/or1k-toolchain --enable-languages=c --disable-shared --disable-libssp &&\
    make &&\
    make install &&\
    cd ../bld-or1k-src &&\
    ../or1k-src/configure --target=or1k-elf --prefix=/opt/or1k-toolchain --enable-shared --disable-itcl --disable-tk --disable-tcl --disable-winsup --disable-libgui --disable-rda --disable-sid --enable-sim --disable-or1ksim --enable-gdb --with-sysroot --enable-newlib --enable-libgloss --disable-werror &&\
    make &&\
    make install &&\
    cd ../bld-or1k-gcc &&\
    ../or1k-gcc/configure --target=or1k-elf --prefix=/opt/or1k-toolchain --enable-languages=c,c++ --disable-shared --disable-libssp --with-newlib &&\
    make &&\
    make install &&\
    echo "# OpenRISC tool chain path" >> /home/USER/.bashrc  &&\
    echo "export PATH=\$PATH:/opt/or1k-toolchain/bin" >> /home/USER/.bashrc &&\
    cd .. &&\
    git clone https://github.com/openrisc/openOCD.git &&\
    cd openOCD &&\
    ./bootstrap &&\
    ./configure --enable-usb_blaster_libftdi --enable-adv_debug_sys --enable-altera_vjtag --enable-maintainer-mode &&\
    make &&\
    make install
RUN cd /home/USER/or1k &&\
    git clone https://github.com/olofk/fusesoc.git &&\
    cd fusesoc &&\
    python3 -m pip install -e . &&\
    su - USER -c "/bin/echo -e \"\n\n\"|fusesoc init" &&\

In fusesoc_multi_launch.py it might be nice to add:

subprocess.call('make', cwd='or1k-tests/native')

just before running fusesoc

Removing --keep allows fusesoc_multi_launch.py to run it outputs:

launching or1k-basic (PID 691)
or1k-basic exited with return code 0

Thank for your help, it is encouraging to see a test running.

I can't run more than one test with fusesoc_multi_launch.py without --keep working right ?

Do you have any coverage statistics for these tests ?

olofk commented 7 years ago

Regarding the toolchain instructions, those are unfortunately outdated as we have gradually been getting our code upstream since those were written. These are the recommended instructions. If you don't feel like rebuilding your toolchain again, you could try one of the pregenerated toolchains at the bottom of this page. I filed a bug report at the chiphack repo to see if we can get those instructions updated

I agree that we should run make in fusesoc_multi_launch.py if it is to be included in the or1k-tests repo. I'll see if I can find time to fix that.

I just fixed the issue with --keep too, so that should work again, and yes, I think that's required to launch several instance.

Regarding coverage, I don't have any numbers or an easy way to get that, but one idea would be to use modelsim (or any other simulator that supports coverage. Icarus doesn't unfortunately) and add a tcl script that is called prior to running the simulation. If this is done for all tests, they can be combined later

markNZed commented 7 years ago

I'm trying to build the latest tools but running into an issue with fusesoc:

fusesoc
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 635, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 943, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 834, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (attrs 16.0.0 (/usr/local/lib/python3.5/dist-packages), Requirement.parse('attrs>=16.1.0'), {'okonomiyaki'})

I was trying to use the same build script for fusesoc so I wonder if changes made for other issues broke this ?

olofk commented 7 years ago

This is unfortunately because the pip package manager for Python packages is broken, and came up now because of a new release of one of the dependencies.

The oroginal issue was this fusesoc depends on simplesat simplesat depends on attrs >= 15.2.0 and okonomiyaki okonomiyaki depends on attrs < 16.1.0 pip happily installs latest attrs, and okonomiyaki fails. To get around this, I forced fusesoc to install a version of attrs that satisfied both requirements.

It seems now however that newer versions of okonomyaki instead requires attrs >= 16.1.0, which is probably why it fails. I pushed some patches to a depfix branch. Please check if that solves the issue, and I can push them to master after that.

I'm pretty fed up with pip at this point that forced me to introduce a workaround in the first place. Thankfully FuseSoC has a better package manager than pip :)

markNZed commented 7 years ago

I'm not familiar with pip etc so it could be stupid mistakes on my side, here is what I see:

root@af99723f57c0:~/fusesoc# pip install -e .
Obtaining file:///root/fusesoc
Requirement already satisfied: ipyxact>=0.2.3 in /usr/local/lib/python3.5/dist-packages (from fusesoc==1.6)
Requirement already satisfied: simplesat in /usr/local/lib/python3.5/dist-packages (from fusesoc==1.6)
Requirement already satisfied: pyyaml in /usr/local/lib/python3.5/dist-packages (from ipyxact>=0.2.3->fusesoc==1.6)
Requirement already satisfied: six>=1.9.0 in /usr/local/lib/python3.5/dist-packages (from simplesat->fusesoc==1.6)
Requirement already satisfied: attrs>=15.2.0 in /usr/local/lib/python3.5/dist-packages (from simplesat->fusesoc==1.6)
Requirement already satisfied: okonomiyaki>=0.14.0 in /usr/local/lib/python3.5/dist-packages (from simplesat->fusesoc==1.6)
Requirement already satisfied: zipfile2>=0.0.12 in /usr/local/lib/python3.5/dist-packages (from okonomiyaki>=0.14.0->simplesat->fusesoc==1.6)
Requirement already satisfied: jsonschema>=2.5.1 in /usr/local/lib/python3.5/dist-packages (from okonomiyaki>=0.14.0->simplesat->fusesoc==1.6)
Installing collected packages: fusesoc
  Found existing installation: fusesoc 1.6
    Can't uninstall 'fusesoc'. No files were found to uninstall.
  Running setup.py develop for fusesoc
Successfully installed fusesoc
root@af99723f57c0:~/fusesoc# fusesoc
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 635, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 943, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 834, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (attrs 16.0.0 (/usr/local/lib/python3.5/dist-packages), Requirement.parse('attrs>=16.1.0'), {'okonomiyaki'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/fusesoc", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2927, in <module>
    @_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2913, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2940, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 637, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 650, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 834, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (attrs 16.0.0 (/usr/local/lib/python3.5/dist-packages), Requirement.parse('attrs>=16.1.0'), {'okonomiyaki'})
root@af99723f57c0:~/fusesoc# 

I'm using the branch:

root@af99723f57c0:~/fusesoc# git branch

olofk commented 7 years ago

No faults on your side. It's just pip being stupid and thinks it has already satisfied all requirements. I've added another commit to the depfix branch now that migh fix it. Could you try to again, and if that fails, run pip install --upgrade okonomiyaki first, to see if we can force updates of the dependencies

markNZed commented 7 years ago

I'm seeing something strange. After running installing fusesoc as root (which did require pip install --upgrade okonomiyaki) I still need to run fusesoc from inside the fusesoc dir or I get:

fusesoc
Traceback (most recent call last):
  File "/usr/local/bin/fusesoc", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2927, in <module>
    @_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2913, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2940, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 635, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 943, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 829, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'fusesoc' distribution was not found and is required by the application

Python 2.7 and 3.5 on the same machine so that may be the issue.

olofk commented 7 years ago

Have you tried if it works now with FuseSoC 1.6.1?

markNZed commented 7 years ago

I have not, I did not get further than above. https://openrisc.io/newlib is not online. I should probably start from scratch and follow the latest build instructions - can you point me to them ?

wallento commented 7 years ago

Sorry, I also noticed recently, that it is down. I will dig into that soon.

stffrdhrn commented 5 years ago

Hello, I added a test bench runner script. It depends on a new version of mor1kx-generic in my repo and fusesoc. I'll be working on intergrating the cores into fusesoc-cores.

This should make running tests for anyone really easy.