The targets using CV32 were compiled using a completely absurd -U__riscv__
flag. The result is that several regression tests were using code
targeting the OpenRISC ISA (!!!) and OR10N (!!!), roughly with 10
years of delay.
Clearly, that did not end well, resulting in errors like the following
```
testAddSubNorm.c: Assembler messages:
testAddSubNorm.c:116: Error: unrecognized opcode `l.addnru a2,a2,a5,5'
testAddSubNorm.c:122: Error: unrecognized opcode `l.addnrru a2,a2,a5,5'
```
Frankly speaking, I do not have the faintest idea how such regressions
could pass using the same source, compiler, and compiler flags in the past.
But they did!!!
Bonkers..
Only for CV32E40X, at least for now. This commit also adds a script
objdump2itb.py from core-v-verif:
4e6e8604fa/bin/objdump2itb
This is used to generate an instruction table file that is, in turn,
used to populate instruction traces.
The script is lightly patched to support llvm-objdump's output.
* Add possibility to supply additional vsim flags with run target
* Now the user can supply the bootmode=<spi|flash|fast_debug|jtag>
variable with the run target to choose the desired boot mode.
You might think these are too many checks, but in fact each is needed to
cover all possible edge cases.
For example you could remove all the VSIM_PATH checks when creating the
symlink and force the creation of symlink (-f flag), but this will fail
for /boot, since on many machines /boot does actually exist.
Removing VSIM_PATH from the run target can cause problems when calling
run with a pre-compiled build directory etc.
When running a questa simulation for pulp/pulpissimo, the testbench
tries to write some log files to stdout/ and fs/, which don't exist
resulting in an ENOENT.
This reverts commit d898ae3424, reversing
changes made to b8f77f397f.
The problem is that when you call `make run` twice, then the work target
tries to re-do it since its a broken symlink. Furthermore, it should be
anyway possible to get the bender flow working withouth symlinking the
work directory.
