Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updated description of rvfi_mem_rdata, rvfi_mem_exokay, rvfi_mem_memt… #954

Merged
merged 2 commits into from Sep 22, 2023
Merged

Updated description of rvfi_mem_rdata, rvfi_mem_exokay, rvfi_mem_memt… #954

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
87c2666
Updated description of rvfi_mem_rdata, rvfi_mem_exokay, rvfi_mem_memt…
silabs-oysteink Sep 21, 2023
eca484f
Update rvfi.rst
Silabs-ArjanB Sep 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
37 changes: 34 additions & 3 deletions docs/user_manual/source/rvfi.rst
View file
Open in desktop
Expand Up @@ -240,10 +240,41 @@ Instructions will populate the ``rvfi_mem`` outputs with incrementing ``NMEM``,
Instructions with a single memory operation (e.g. all RV32I instructions), including split misaligned transfers, will only use NMEM = 1.
Instructions with multiple memory operations (e.g. the push and pop instructions from Zcmp) use NMEM > 1 in case multiple memory operations actually occur.
``rvfi_mem_prot`` indicates the value of OBI prot used for the memory access or accesses. Note that this will be undefined upon access faults.
``rvfi_mem_memtype`` indicates the memory type attributes associated with each memory operation (i.e cacheable or bufferable).
``rvfi_mem_memtype`` indicates the memory type attributes associated with each memory operation (i.e cacheable or bufferable). For misaligned transactions that are
split in two memory operations ``rvfi_mem_memtype`` will only report the type attribute for the first memory operation.
``rvfi_mem_atop`` indicates the type of atomic transaction as specified in [OPENHW-OBI]_.
``rvfi_mem_exokay`` indicates the status of ``data_exokay_i`` for loads, non-bufferable stores and atomic instructions.
``rvfi_mem_err`` indicates if a load, non-bufferable store or atomic instruction got a bus error.
``rvfi_mem_exokay`` indicates the status of ``data_exokay_i`` for loads, non-bufferable stores and atomic instructions. For split transactions, ``rvfi_mem_exokay`` will only
be 1 if both transactions receive ``data_exokay_i == 1``.
``rvfi_mem_err`` indicates if a load, non-bufferable store or atomic instruction got a bus error. :numref:`rvfi_mem_err encoding for different transaction types` shows how
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Not important but)
Is it supposed to be illustrated like this in the text?
image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note sure about the github rendering, it shows up correctly when built to HTML at least

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, looks good then.

different memory transactions report ``rvfi_mem_err``.

.. table:: rvfi_mem_err encoding for different transaction types
:name: rvfi_mem_err encoding for different transaction types
:widths: 60 5 5 5 60
:class: no-scrollbar-table

+---------------------+---------+----------------+----------------+--------------------------------+
| Instruction type | Split | Bufferable (1) | Bufferable (2) | rvfi_mem_err |
+=====================+=========+================+================+================================+
| Load | No | N/A | N/A | data_err_i |
+---------------------+---------+----------------+----------------+--------------------------------+
| Load | Yes | N/A | N/A | data_err_i(1) OR data_err_i(2) |
+---------------------+---------+----------------+----------------+--------------------------------+
| Store | No | No | N/A | data_err_i |
+---------------------+---------+----------------+----------------+--------------------------------+
| Store | No | Yes | N/A | 0 |
+---------------------+---------+----------------+----------------+--------------------------------+
| Store | Yes | No | No | data_err_i(1) OR data_err_i(2) |
+---------------------+---------+----------------+----------------+--------------------------------+
| Store | Yes | Yes | Yes | 0 |
+---------------------+---------+----------------+----------------+--------------------------------+
| Store | Yes | Yes | No | data_err_i(2) |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned internally, in this case rvfi_mem_type is registrated as bufferable, and there is nothing indicating that the second obi transfer is non-bufferable. You could therefor not know if the rvfi_mem_err and rvfi_mem_exokay is "correct" or just tied off.

As we discussed this will be fixed later, but wanted to mention the seemingly problematic scenario.

+---------------------+---------+----------------+----------------+--------------------------------+
| Store | Yes | No | Yes | data_err_i(1) |
+---------------------+---------+----------------+----------------+--------------------------------+

``rvfi_mem_rdata`` will report the read data for load instructions. In case of split misaligned transactions this read data is the combination of the two transfers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.


For cores as |corev| that support misaligned access ``rvfi_mem_addr`` will not always be 4 byte aligned. For misaligned accesses the start address of the transfer is reported (i.e. the start address of the first sub-transfer).

Expand Down