THead: Add Xuantie C910 ACT Test Report

[jamesbeyond]

No description provided.

[billmcspadden-riscv]

I've reviewed this PR. Looks good to me. I suggest that me merge.

[cetola]

This looks good to me. Suggest we merge.

[cetola]

@allenjbaum Any reason we should not merge these test reports for the C910?

[allenjbaum]

Im a concerned that they can't test the [c.]ebreak instruction because they use it to signal that the test is ended (that's how i interpret it, anyway). This superficially looks pretty much the same as the original 908 submission, otherwise.

[allenjbaum]

Like the 908, this definition is reversed. If should be
mask= 0x0000000, fixedvalue=0x094112D

[jamesbeyond]

I'll try to fix this asap

[jamesbeyond]

you are correct @allenjbaum that is why the ebreak instruction is failed at this time

[allenjbaum]

This looks OK. The definitoin of MISA should be fixed (paramters are reversed), but otherwise it appears OK

[MarcKarasek]

Would this cause misaligned test along with ecall and ebreak to fail?

…

On Thu, Mar 2, 2023 at 1:19 AM Qinghao Shi ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In T-Head/Xuantie-C910-2023-02-26/c910_isa.yaml <#2 (comment)> : > + mxl: + implemented: true + type: + warl: + dependency_fields: [] + legal: + - mxl[1:0] in [0x2] + wr_illegal: + - Unchanged + extensions: + implemented: true + type: + warl: + dependency_fields: [] + legal: + - extensions[25:0] bitmask [0x094112D, 0x0000000] I'll try to fix this asap — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD72ZM7PLV3LC3S3Z3TA24DW2A3WFANCNFSM6AAAAAAVKYARJ4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** .com>

-- /**************** Marc Karasek ASM T648 Herder of Cats ****************/

[allenjbaum]

no - it is specific to Ecall. Other traps (should) work fine. It is an errata for one specific architectural berhavior out of a large number of architectural behavior in the priv spec, but that pretty much invalidates the entire priv spec compatibility. We don't differentiate between a little incompatible and completely compatible. There was a mention of a different debug methodology- and they could make a case that they will support debug in a different way, but its still a custom priv layer, even if it only has a single difference. They are allowed to do that and they have limited its scope, but we don't have leeway to really condone that, from a compatibility point of view. On Thu, Mar 2, 2023 at 6:17 AM Marc Karasek ***@***.***> wrote:

…

Would this cause misaligned test along with ecall and ebreak to fail? On Thu, Mar 2, 2023 at 1:19 AM Qinghao Shi ***@***.***> wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In T-Head/Xuantie-C910-2023-02-26/c910_isa.yaml > < #2 (comment) > > : > > > + mxl: > + implemented: true > + type: > + warl: > + dependency_fields: [] > + legal: > + - mxl[1:0] in [0x2] > + wr_illegal: > + - Unchanged > + extensions: > + implemented: true > + type: > + warl: > + dependency_fields: [] > + legal: > + - extensions[25:0] bitmask [0x094112D, 0x0000000] > > I'll try to fix this asap > > — > Reply to this email directly, view it on GitHub > < #2 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AD72ZM7PLV3LC3S3Z3TA24DW2A3WFANCNFSM6AAAAAAVKYARJ4 > > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.*** > .com> > -- /**************** Marc Karasek ASM T648 Herder of Cats ****************/ — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJTMJI7Y6FY4RXSQWUTW2CTVZANCNFSM6AAAAAAVKYARJ4> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[jamesbeyond]

@allenjbaum regarding the ebreak failure, it is actually a known limitation when using the riscof gdb plugin,
please found it out in : https://gitlab.incoresemi.com/core-verification/riscof-plugins/-/tree/master/gdb
here I quote it

Currently, the gdb plugin is seeing a failure with EBREAK, because the plugin uses breakpoints through gdb.

[allenjbaum]

That sounds like the chip does support EBREAK - but the test environment overrides it. Let's see if we can find a way to fix that, possibly by adding a configuration option to the gdb plug to use ECALL instead of EBREAK. We'd have to make a corresponding change in the trap handler, but that should be straightforward.

…

On Thu, Mar 9, 2023 at 11:41 PM Qinghao Shi ***@***.***> wrote: @allenjbaum <https://github.com/allenjbaum> regarding the ebreak failure, it is actually a known limitation when using the riscof gdb plugin, please found it out in : https://gitlab.incoresemi.com/core-verification/riscof-plugins/-/tree/master/gdb here I quote it Currently, the gdb plugin is seeing a failure with EBREAK, because the plugin uses breakpoints through gdb. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJXRMISNHYV7GBBBDUTW3LLLJANCNFSM6AAAAAAVKYARJ4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MarcKarasek]

We may be having the same issue as ecall and ebrak are showing as broken. I have not dug into why yet as I have other more pressing bugs...

…

On Fri, Mar 10, 2023 at 2:07 PM Allen Baum ***@***.***> wrote: That sounds like the chip does support EBREAK - but the test environment overrides it. Let's see if we can find a way to fix that, possibly by adding a configuration option to the gdb plug to use ECALL instead of EBREAK. We'd have to make a corresponding change in the trap handler, but that should be straightforward. On Thu, Mar 9, 2023 at 11:41 PM Qinghao Shi ***@***.***> wrote: > @allenjbaum <https://github.com/allenjbaum> regarding the ebreak failure, > it is actually a known limitation when using the riscof gdb plugin, > please found it out in : > https://gitlab.incoresemi.com/core-verification/riscof-plugins/-/tree/master/gdb > here I quote it > > Currently, the gdb plugin is seeing a failure with EBREAK, because the > plugin uses breakpoints through gdb. > > — > Reply to this email directly, view it on GitHub > < #2 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AHPXVJXRMISNHYV7GBBBDUTW3LLLJANCNFSM6AAAAAAVKYARJ4 > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD72ZM7CY52G5QAH3D2UYCLW3N3YRANCNFSM6AAAAAAVKYARJ4> . You are receiving this because you commented.Message ID: ***@***.***>

-- /**************** Marc Karasek ASM T648 Herder of Cats ****************/

[allenjbaum]

We can fix it at our end easily enough, but it needs fixing at the testbench end as well. RVMODEL_HALT should either be - configurable (so that if you're trying to test the RVMODEL_HALT op, you can switch it to another op that isn't being tested in that test, or - be an instructions that can trap only under specific conditions (e.g. a store to a test-bench-defined MMIO address that no test uses, because it is out out of range of code/data/signature segments) More stuff tha tneeds documenting On Sat, Mar 11, 2023 at 2:35 PM Marc Karasek ***@***.***> wrote:

…

We may be having the same issue as ecall and ebrak are showing as broken. I have not dug into why yet as I have other more pressing bugs... On Fri, Mar 10, 2023 at 2:07 PM Allen Baum ***@***.***> wrote: > That sounds like the chip does support EBREAK - but the test environment > overrides it. > Let's see if we can find a way to fix that, possibly by adding a > configuration option to the gdb plug to use ECALL instead of EBREAK. > We'd have to make a corresponding change in the trap handler, but that > should be straightforward. > > On Thu, Mar 9, 2023 at 11:41 PM Qinghao Shi ***@***.***> > wrote: > > > @allenjbaum <https://github.com/allenjbaum> regarding the ebreak > failure, > > it is actually a known limitation when using the riscof gdb plugin, > > please found it out in : > > > https://gitlab.incoresemi.com/core-verification/riscof-plugins/-/tree/master/gdb > > here I quote it > > > > Currently, the gdb plugin is seeing a failure with EBREAK, because the > > plugin uses breakpoints through gdb. > > > > — > > Reply to this email directly, view it on GitHub > > < > #2 (comment) > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AHPXVJXRMISNHYV7GBBBDUTW3LLLJANCNFSM6AAAAAAVKYARJ4 > > > > . > > You are receiving this because you were mentioned.Message ID: > > ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > < #2 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AD72ZM7CY52G5QAH3D2UYCLW3N3YRANCNFSM6AAAAAAVKYARJ4 > > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- /**************** Marc Karasek ASM T648 Herder of Cats ****************/ — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJXR3DFANIRXUTGK4HDW3T42NANCNFSM6AAAAAAVKYARJ4> . You are receiving this because you were mentioned.Message ID: ***@***.***>