profile
viewpoint
Lee Moore eroom1966 Imperas Software Limited

riscv-software-src/riscv-config 35

RISC-V Configuration Validator

riscv-verification/RVVI 2

RISC-V Verification Interface

eroom1966/ibex 1

Ibex is a small 32 bit RISC-V CPU core (RV32IMC/EMC) with a two stage pipeline, previously known as zero-riscy.

eroom1966/core-v-verif 0

Functional verification project for the CORE-V family of RISC-V cores.

eroom1966/cv32e40p 0

CV32E40P is an in-order 4-stage RISC-V RV32IMFCXpulp CPU based on RI5CY from PULP-Platform

eroom1966/dump1090 0

Dump1090 is a simple Mode S decoder for RTLSDR devices

eroom1966/ogn-rf 0

This software listens to OGN radio messages and sends it to Open Glider Network.

eroom1966/riscv-bitmanip 0

Working draft of the proposed RISC-V Bitmanipulation extension

issue openedSymbioticEDA/riscv-formal

are rvfi_valid and rvfi_trap mutually exclusive.

Hi

in the description of the interface, rvfi_valid is said to indicate the following

  1. When the core retires an instruction, it asserts the rvfi_valid
  2. The signals are only valid during such a cycle and can be driven to arbitrary values in a cycle in which rvfi_valid is not asserted.

later

rvfi_trap must be set for an instruction that cannot be decoded as a legal instruction, such as 0x00000000.

The purpose if the rvfi_trap is to indicate an exception, an instruction which causes an exception, by definition does not retire. But this contradicts the previous statement, a good example is the misaligned LD/ST

If I have the following instruction (assuming the implementation does not support misaligned LD/ST) lw x1, x0(1)

This will take an exception, and X1 will not update as the instruction does not complete (retire) How can this be described in the interface, as it should be the following rvfi_valid=0, rvfi_trap=1, ....

But this would be ignored as rvfi_valid is 0

If rvfi_valid indicates a retirement, and rvfi_trap indicates an exception - then these two signals must surely be mutually exclusive ?

created time in 2 days

push eventriscv-verification/RVVI

eroom1966

commit sha a594711de54922ef2d21d00a81cfcbbf04d67c56

fix ordering format to be consistent

view details

push time in 17 days

push eventriscv-verification/RVVI

eroom1966

commit sha 5df36552f243669518647ad05a21bdc53dd0fb98

update to indicate multiple concurrent register writes

view details

push time in 17 days

push eventeroom1966/RVVI

eroom1966

commit sha 0b963d11f52c7d377da90585cc0554827877bbb7

update for SV/C interaction

view details

Lee Moore

commit sha c330936b05d080b0ac19abce92d9fa8f4f433ca7

Update rvvi.md

view details

eroom1966

commit sha 1cc7764f255843282a15e6c463b00d61aa4db609

calling sequence diagram

view details

Imperas Github Account

commit sha 6cae78779c03de61c77d25c58d4e4fed78537860

Update README.md

view details

Imperas Github Account

commit sha ece8f331a3b459d969cf84457bf63eb626e55578

Update README.md

view details

eroom1966

commit sha 9226eef12c9ee233ce6cb4d481ee1eabc49032d7

update to version 0.3

view details

Imperas

commit sha 293f01484c47b63b42e8d433111790d9bda985b3

added API and updated VLG all to version 0.5

view details

Imperas

commit sha b2e19645acf771403ff64d741d765a089bff6cb8

update typos

view details

Imperas

commit sha ac795bd25ed4c617153e8dc81e235998d468dc6c

fix link

view details

Imperas

commit sha 7e9625a4923956155ac86c5aaec9d74fa6486a1f

update

view details

Aidan

commit sha c7c9747f3fdd4ef2d0fa3c1577e482b67c1a75a5

Add include/source folders and tidy up

view details

Lee Moore

commit sha f113aaf51760e6d8d673a1367c550809d3b83bc2

Merge pull request #1 from riscv-verification/aidan/tidyup Add include/source folders and tidy up

view details

push time in 17 days

push eventriscv-verification/RVVI

Aidan

commit sha c7c9747f3fdd4ef2d0fa3c1577e482b67c1a75a5

Add include/source folders and tidy up

view details

Lee Moore

commit sha f113aaf51760e6d8d673a1367c550809d3b83bc2

Merge pull request #1 from riscv-verification/aidan/tidyup Add include/source folders and tidy up

view details

push time in 17 days

PR merged riscv-verification/RVVI

Add include/source folders and tidy up documentation

This PR does the following things:

  • Corrects some typos in the markdown files.
  • Adds root level source+include folders for the various interfaces.
  • Updates the copyright notice for 2022 year.
  • Remove the dual markdown files in the rvvi-vlg folder (only README.md now)
  • Reflows markdown to 80chars for easier reading as plaintext.
+287 -189

0 comment

8 changed files

bit-hack

pr closed time in 17 days

push eventriscv-verification/RVVI

eroom1966

commit sha 9226eef12c9ee233ce6cb4d481ee1eabc49032d7

update to version 0.3

view details

push time in a month

issue commentopenhwgroup/cv32e40x

dcsr cause mismatch when entering debug after a step

Pull request issued, could somebody please review and comment

strichmo

comment created time in a month

PR opened openhwgroup/core-v-verif

Cv32e40x/dev

Fix to handle testcase exhibiting priority resolution on debug requests https://github.com/openhwgroup/cv32e40x/issues/340

+2 -2

0 comment

5 changed files

pr created time in a month

PR opened openhwgroup/core-v-verif

Cv32e40s/dev

Fix for missing registers cpuctrl, and seed 0-2

+2 -2

0 comment

5 changed files

pr created time in a month

push eventeroom1966/core-v-verif

eroom1966

commit sha 83db3d8cac80cd3e9d3411c5805225a778233636

Latest change for debug priorities

view details

push time in a month

push eventeroom1966/core-v-verif

eroom1966

commit sha 54db8bdb00c3e0b2b494d4e1d9f22d27f19d9484

add debug fix for haltreq priority

view details

push time in a month

push eventeroom1966/core-v-verif

eroom1966

commit sha e2ee63eceb3aaddcaef530b79c133b9f7a53d271

update for new registers cpuctrl and seed 0:2

view details

push time in a month

issue commentopenhwgroup/cv32e40x

dcsr cause mismatch when entering debug after a step

I think the root cause here is that the ISS should not assume that debug is entered due to single step even if a single stepped instruction completed. Only on the next instruction after that can the ISS know what the highest priority debug entry reason was.

We could potentially add another rvfi_trap reason to signal that 'an instruction was single step (i.e retired) but a debug_request was honored as well determining the cause of the next debug entry'.

@Silabs-ArjanB do you think this is still the case given the description above by @JamesKenneyImperas ?

strichmo

comment created time in a month

push eventeroom1966/core-v-verif

eroom1966

commit sha 3f45560c37a5568446c7675b1d3fb7bb353b9759

add new functionality for CV32E40S registers

view details

push time in a month

issue commentopenhwgroup/cv32e40x

dcsr cause mismatch when entering debug after a step

how many instructions does it take for this test to complete ?

strichmo

comment created time in a month

issue commentopenhwgroup/cv32e40x

dcsr cause mismatch when entering debug after a step

To run this testcase it appears I also have to set the following on the make command CV_CORE=cv32e40x Can you confirm if this is correct ?

strichmo

comment created time in a month

fork eroom1966/core-v-verif

Functional verification project for the CORE-V family of RISC-V cores.

https://core-v-docs-verif-strat.readthedocs.io/en/latest/

fork in a month

PR opened eroom1966/core-v-verif

Cv32e40x/dev
+7459 -3050

0 comment

148 changed files

pr created time in a month

issue commentopenhwgroup/cv32e40x

misa value for B extension incorrect when configuring B_EXT

@MikeOpenHWGroup I think this is specifically an issue with using a different compiler, defined by GNU_SW_TOOLCHAIN

I think the variables GNU_SW_TOOLCHAIN and COREV=YES are somehow incompatible, but only a guess

strichmo

comment created time in 3 months

issue commentopenhwgroup/cv32e40x

misa value for B extension incorrect when configuring B_EXT

Hi Steve, @MikeOpenHWGroup at the moment I have the following variables set

export SIMULATOR=xrun export PATH=${PATH}:$(pwd)/core-v-verif/bin export COREV=YES export COREV_SW_TOOLCHAIN=/home/moore/riscv/corev-openhw-gcc-ubuntu1804-20200913

when executing makeuvmt, I usually add to the command line CV_CORE=cv32e40x without this I get

Makefile.uvmt:28: *** Must set CV_CORE to a valid core. Stop.

I suspect something above is conflicting with your command, I tried unsetting COREV and COREV_SW_TOOLCHAIN, now it compiles and runs !

(hoping Mike can chime in here) I am now confused (and slightly worried) what I should have set in my environment when running tests

I cannot work out how get the parameters through to the core configuration, I tries using cv32e40x/tests/cfg/default.yaml but it has no effect

  • I think we need a shared desktop Steve
strichmo

comment created time in 3 months

issue commentopenhwgroup/cv32e40x

misa value for B extension incorrect when configuring B_EXT

% makeuvmt test TEST=b_ext_test CFG=b_ext_abs GNU=1 GNU_SW_TOOLCHAIN=/work/strichmo/ip_rad_riscv/embecosm/riscv32-embecosm-gcc-centos7-20210829 GNU_MARCH=rv32imc_zba0p93_zbb0p93

strichmo

comment created time in 3 months

issue commentopenhwgroup/cv32e40x

misa value for B extension incorrect when configuring B_EXT

Thanks @strichmo will try this tomorrow

strichmo

comment created time in 3 months

issue commentopenhwgroup/cv32e40x

misa value for B extension incorrect when configuring B_EXT

Hi Steve I downloaded this toolchain for ubuntu 18 https://buildbot.embecosm.com/job/riscv32-gcc-ubuntu1804/76/artifact/riscv32-embecosm-gcc-ubuntu1804-20210829.tar.gz But I still get a compilation failure

/home/moore/Downloads/riscv32-embecosm-gcc-ubuntu1804-20210829/bin/riscv32-unknown-elf-gcc
-Os -g -static -mabi=ilp32 -march=rv32imc -Wall -pedantic
-I ../../tests/asm
-o /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.elf
-nostartfiles
/home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c
-T /home/moore/git/strichmo/core-v-verif/cv32e40x/bsp/link.ld
-L /home/moore/git/strichmo/core-v-verif/cv32e40x/bsp
-lcv-verif /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c: Assembler messages: /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:75: Error: unrecognized opcode clz t5,t3' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:90: Error: unrecognized opcodectz t5,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:105: Error: unrecognized opcode cpop t5,t3' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:121: Error: unrecognized opcodemax t5,t3,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:137: Error: unrecognized opcode min t5,t3,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:153: Error: unrecognized opcodemaxu t5,t3,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:169: Error: unrecognized opcode minu t5,t3,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:184: Error: unrecognized opcodeorc.b t5,t3' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:200: Error: unrecognized opcode andn t5,t3,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:216: Error: unrecognized opcodeorn t5,t3,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:232: Error: unrecognized opcode xnor t5,t3,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:247: Error: unrecognized opcoderev8 t5,t3' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:263: Error: unrecognized opcode rol t5,t3,t4' /home/moore/git/strichmo/core-v-verif/cv32e40x/tests/programs/custom/b_ext_test/b_ext_test.c:280: Error: unrecognized opcoderor t5,t3,t4' ...

strichmo

comment created time in 3 months

push eventeroom1966/core-v-verif

eroom1966

commit sha 8926eeed777871374af0bae19d97760c000e2aca

undo erroneous addition

view details

push time in 3 months

push eventeroom1966/core-v-verif

Steve Richmond

commit sha e346833be2e710fa7d3b4a7f76c19deadc745422

Merge pull request #984 from eroom1966/cv32e40x/dev Cv32e40x/dev

view details

Steve Richmond

commit sha 5e2e130a9949ae2e4055b119a6830f310ab1f15a

fix workaround to configure X core for B_EXT Signed-off-by: Steve Richmond <Steve.Richmond@silabs.com>

view details

Steve Richmond

commit sha a11671c8c44077ecf697f299c0bf41b02eb90b2a

explicitly connect interfaces to avoid compilation issue with JasperGold UNR tool Signed-off-by: Steve Richmond <Steve.Richmond@silabs.com>

view details

Mike Thompson

commit sha 59bb319e90704c565032c93001e89c6ef1c7d834

Merge pull request #985 from strichmo/strichmo/pr/b_ext_param_fix fix workaround to configure X core for B_EXT

view details

Steve Richmond

commit sha 75f137d6acf42909aa5a249888308af468d993be

update jaspergold unr refinement files Signed-off-by: Steve Richmond <Steve.Richmond@silabs.com>

view details

Steve Richmond

commit sha 9237be0f73d47b7dbee8b4a0cc17e5ef3b0524f9

reduce overall number of tests to finish in a night on fewer licenses add more tests Signed-off-by: Steve Richmond <Steve.Richmond@silabs.com>

view details

Mike Thompson

commit sha ab602277d885bec81ad82f2fd49bca3edf67faac

Merge pull request #989 from strichmo/strichmo/pr/e40x_jg_unr_fix Strichmo/pr/e40x jg unr fix

view details

Lee Moore

commit sha 759a9f6196af4681cec366f70d4be3a03526bede

Merge branch 'openhwgroup:cv32e40x/dev' into cv32e40x/dev

view details

push time in 3 months

push eventeroom1966/core-v-verif

eroom1966

commit sha c437c42ea324ad31dec496d494ccc06b4af27efc

update E40X to include bit manipulation 1.0.0

view details

push time in 3 months

issue commentopenhwgroup/cv32e40x

misa value for B extension incorrect when configuring B_EXT

can this be re-opened until we have Steves test working ?

@strichmo I failed to reproduce your test, looks like a toolschain issue as my compiler will not assemble the bit manipulation code. Can you please provide a pointer to the toolchain I should be using ?

as far as I can tell the document link points to here https://www.embecosm.com/resources/tool-chain-downloads/#corev

this seems quite old, and further up the page it refers to the Experimental RISC-V Bitmanip (rvb) compilers

is this what should be used ?

strichmo

comment created time in 3 months

issue commentopenhwgroup/cv32e40x

misa value for B extension incorrect when configuring B_EXT

The original document we worked to was the document CV32E40X, CV32E40S - ISS support dated 4/23/21 revision v1.0

This document has a link to a live document here https://cv32e40x-user-manual.readthedocs.io/en/latest/intro.html#standards-compliance

This makes it difficult to know when changes occur, or what changes occur Is it possible. This document only has a 'latest' version, in which case how should we correlate that to the version specified at 4/23/21 ?

I don't see a history of changes, or changelogs.

At some point the version of bit manipulation supported would have changed from XX.X to 1.0.0 How can we be notified when this happens, or see the history of changes in the specification ?

strichmo

comment created time in 3 months

issue commentopenhwgroup/cv32e40x

misa value for B extension incorrect when configuring B_EXT

It looks like the model is configured to be bitmanip version 0.93 not version 1.0.0 is this correct ? It is difficult to see how this is being assigned, but I think it is here

./lib/uvm_agents/uvma_rvvi_ovpsim/uvma_rvvi_ovpsim_agent.sv ... BITMANIP_VERSION_0P93: $fwrite(fh, $sformatf("--override root/cpu/bitmanip_version=0.93\n")); ... endcase

I am guessing that this is supposed to now be supporting bitmanip version 1.0.0 This would allow independent setting of the Zb* parameters without the setting of MISA.B

strichmo

comment created time in 3 months

more