Defining Memory address variables to enable abstract/function based coverpoint defintions for csrs.

[pawks]

Many of the csrs happen to deal with memory addresses. It is not feasible to define absolute coverpoints for these csrs. Hence the need for memory variables which derive their values based on the instruction stream at runtime. The following variables are needed.

• depa: The physical address of the data access.
• depa_align: The alignment of the physical address i.e the 2bits in the LSB.
• deva: The virual address of the data access. This is the effective address of the access as defined by the states being consumed in the instruction i.e in the absence of translation eva==epa.
• deva_align: Currently the alignment of the address of the data access is expressed in ea_align. This needs to be renamed.
• dptw[stage]a: The address being accessed by the ptwalk stage(depending on the levels of ptwalk needed) in the translation of effective data address from va to pa. In the presence of hypervisor the stage becomes a 2 digit number with the first showing the stage in conversion of va to hpa and the second showing hpa to pa.
• iepa: The physical address of the instruction access.
• iepa_align: The alignment of the physical address i.e the 2bits in the LSB of the instruction address.
• ieva: The virual address of the instruction access. This is the effective address of the access as defined by the states being consumed in the instruction i.e in the absence of translation eva==epa.
• ieva_align: LSB 2 bits of the va of instruction.
• iptw[stage]a: The address being accessed by the ptwalk stage(depending on the levels of ptwalk needed) in the translation of effective instruction address from va to pa. In the presence of hypervisor the stage becomes a 2 digit number with the first showing the stage in conversion of va to hpa and the second showing hpa to pa.

All of these can simply be parsed from the SAIL log since it dumps implicit accesses.

[UmerShahidengr]

Hello All,
@MuhammadHammad001 is working on this issue, please assign him this issue.

[MuhammadHammad001]

The support for these variables has been added in the PR#80. Please refer to the comment for the implementation
@allenjbaum
@UmerShahidengr
@neelgala

[allenjbaum]

I commented on needing to customize the address size to the implementation, but couldn't remember its name. The variable is #defined as _ADDR_SZ_ and defaults to 32b on RV32 and 57 bits on RV64. I don't know if we ever need to change it (we might if we have tests that change SATP.mode), so you could .set _VADDR_SZ_, va and .set PADDR_SZ, PA if that's needed since _ADDR_SZ isn't currently used in any tests or macros

…

On Sat, Dec 2, 2023 at 1:34 AM HammadBashir ***@***.***> wrote: The support for these variables has been added in the PR#80 <#80>. Please refer to that PR for the implementation — Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJUOSGVCZGVXJJ6R2A3YHLY3FAVCNFSM6AAAAAARGK5XLOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGEYDGNJUGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>