Instructions re-encoding aligned with stable pulp_encoding_blocks-OPHW-2022-11-14.xlsx #740

pascalgouedo · 2022-11-25T10:24:28Z

pulp_encoding_blocks-OPHW-2022-11-14.xlsx from issue #452.

Changes wrt pulp_encoding_blocks-OPHW-jm-jpb-pgo-2022-04-26.xlsx :

new encoding for cv.extract, cv.insert, cv.shuffle, cv.pack, cv.cplxmul, cv.subrotmj, cv.add/subb.div2/4/8
description fix for cv.insert, cv.clb, cv.bitrev, cv.avgu
added missing SIMD cv.sdotsp.sc.b
updates related to Hardware Loops (2 new instructions, CSR mapping, constraints).

…p_encoding_blocks-OPHW-2022-11-14 from issue openhwgroup#452. Changes wrt pulp_encoding_blocks-OPHW-jm-jpb-pgo-2022-04-26 : - new encoding for cv.extract, cv.insert, cv.shuffle, cv.pack, cv.cplxmul, cv.subrotmj, cv.add/subb.div2/4/8 - description fix for cv.insert, cv.clb, cv.bitrev, cv.avgu - added missing SIMD cv.sdotsp.sc.b Signed-off-by: Pascal Gouedo <[email protected]>

…straints). Signed-off-by: Pascal Gouedo <[email protected]>

Silabs-ArjanB · 2022-11-25T10:59:16Z

Opting out of PULP related reviews

Signed-off-by: Pascal Gouedo <[email protected]>

MikeOpenHWGroup

LGTM, thanks for this @pascalgouedo. I will leave it to @davideschiavone to approve as he is far more knowledgeable than me regarding the XPULP ISA.

docs/source/control_status_registers.rst

davideschiavone · 2022-12-05T09:52:49Z

docs/source/corev_hw_loop.rst


 -  HWLoop body must contain at least 3 instructions.
-   An illegal exception is raised otherwise.
+   An illegal instruction exception is raised otherwise.


when does this happen? when setting the END of the HW Loop? We should specify this in my opinion, as well as specify the ordering of settings, because if you check that the HW loop END instruction is greater or equal to START + 12 (or +16 actually as you point to the next after the end)- when setting the END of the loop, then START must be programmed before, otherwise, if you check when fetching the first time the first instruction of the HW Loop, then ordering does not matter.

Quite complex ordering constraint.
A Loop Enable bit could solve the ordering problem when programming HW loops CSRs.
General answer could be what is stated in last conversation/comment.

sorry what is the last conversation/comment?

Anyway, for me it is fine any kind of solution, e.g. the easiest would be when fetching the first instruction of the HW Loop (start), but we need to say this

Do nothing in HW for that, no exception.

davideschiavone · 2022-12-05T09:53:19Z

docs/source/corev_hw_loop.rst


 -  No Compressed instructions (RVC) allowed in the HWLoop body.
-   An illegal exception is raised otherwise.
+   An illegal instruction exception is raised otherwise.


shall we say this happens when fetching the first time a compressed instruction inside the HW loop?

I think any time because this is an unrecoverable error and program execution can not continue after that anyway.

ok for me, shall we add some words to better specify it?

davideschiavone · 2022-12-05T09:53:44Z

docs/source/corev_hw_loop.rst

-  No uncoditional jump instructions allowed in the HWLoop body.
-   An illegal exception is raised otherwise.
+-  No unconditional jump instructions allowed in the HWLoop body.
+   An illegal instruction exception is raised otherwise.


shall we say this happens when fetching the first time a jump instruction inside the HW loop?

Same answer as above.

davideschiavone · 2022-12-05T09:53:55Z

docs/source/corev_hw_loop.rst

-  No coditional branch instructions allowed in the HWLoop body.
-   An illegal exception is raised otherwise.
+-  No conditional branch instructions allowed in the HWLoop body.
+   An illegal instruction exception is raised otherwise.


shall we say this happens when fetching the first time a branch instruction inside the HW loop?

Same answer as above.

davideschiavone · 2022-12-05T09:54:08Z

docs/source/corev_hw_loop.rst


 -  No privileged instructions (mret, dret, ecall, wfi) allowed in the HWLoop body, except for ebreak.
-   An illegal exception is raised otherwise.
+   An illegal instruction exception is raised otherwise.


Same answer as above.

davideschiavone · 2022-12-05T09:54:14Z

docs/source/corev_hw_loop.rst


 -  No memory ordering instructions (fence, fence.i) allowed in the HWLoop body.
-   An illegal exception is raised otherwise.
+   An illegal instruction exception is raised otherwise.


Same answer as above.

davideschiavone · 2022-12-05T09:54:29Z

docs/source/corev_hw_loop.rst


 -  The End address of the outermost HWLoop (#1) must be at least 2
   instructions further than the End address innermost HWLoop (#0),
   i.e. HWLoop[1].endaddress >= HWLoop[0].endaddress + 8
-   An illegal exception is raised otherwise.
+   An illegal instruction exception is raised otherwise.


Like the "at least 3 instructions", those 2 constraints are harder to tackle in hardware. It would require to add resources (adders/substractors) just to check these wrong cases. Not really nice to keep CV32E40P small and power efficient.

In my previous life, these cases were only managed by constraining compiler and were not checked by HW ...

I agree with this, but I think you need these subtractors/adders anyway if you want to trigger an illegal exception.
We can share the adder by deciding when checking these features, for example, for "at least 3 instructions" we check in the first instruction of the hwloop, for "at least 2 instruction after..", at the end of the outermost loop, whatever the solution, we must provide an answer to the SW and Verification team.

None required if no HW exception.
For SW, they should not generate those cases so no pb.
For Reference Model, emulate an instruction exception.
For verification, those cases should not be verified and so not generated. If it would happen anyway, there will be a difference for sure as Reference Model will generate an exception and the HW will not ...

mmm I wouldn't go this direction, but I do not have strong opinions either.

We won't definitively sell it as "safe" then, but even if you do nothing in HW, the HW won't work, so we should write AT LEAST that the behaviour is undefined, and we should remove the statements that we raise an exception, as we won't - did I understand this correctly?

I agree this behaviour is not safe at all but E40P is not a safety/secure core.
And yes any undefined behaviour should be mentioned every time it happens.
For these 2 cases, even if the HW does not generate an exception, I would like to add a statement/section that Reference Model should still raise an exception.

ok then you can say that the reference model does it, but I would not, I mean, in theory, the reference model should behave as the DUT, but I let @MikeOpenHWGroup chime in here

Actually, I always say that the DUT should behave as the reference model. 😉

Seriously, this is an important topic. In the general case there are three conditions:

Illegal events that result in either unpredictable behavior and/or an unrecoverable state.
The testbench will be constrained to avoid generating these events. The reference model will not check for these events.

Illegal events that cause an exception.
The testbench will be able to generate these events and will have functional coverage to ensure that it does. The reference model will also generate an exception.

Illegal events that are automatically recoverable in the DUT.
The testbench will be able to generate these events and will have functional coverage to ensure that it does. The reference model will recover in the same way as the DUT.

I generally agree with the first statement except when the reference model is not only used just for verification but also as an execution model for software guys when developing their application.
This is the case when this RM is embedded in a Virtual Platform.
If the RM is not generating an exception for case 1. then you are finding the issue only when simulating on RTL or FPGA.
If the compiler is not generating this case no pb but what if "someone" writes assembly code not respecting hw loops constraints?
I know I know writing assembly code !!!

Signed-off-by: Pascal Gouedo <[email protected]>

… loop body instructions number can be doubled by shifting it by 2 rather than 1. Signed-off-by: Pascal Gouedo <[email protected]>

Signed-off-by: Pascal Gouedo <[email protected]>

docs/source/corev_hw_loop.rst

Signed-off-by: Pascal Gouedo <[email protected]>

Pascal Gouedo added 2 commits November 24, 2022 11:00

Updates related to Hardware Loops (new instructions, CSR mapping, con…

574e5f5

…straints). Signed-off-by: Pascal Gouedo <[email protected]>

pascalgouedo added the Component:Doc For issues in the Documentation (e.g. for README.md files) label Nov 25, 2022

pascalgouedo requested review from MikeOpenHWGroup, davideschiavone, Silabs-ArjanB and jm4rtin and removed request for jm4rtin November 25, 2022 10:25

Silabs-ArjanB removed their request for review November 25, 2022 10:59

Added missing file for tables formatting.

e7d3e61

Signed-off-by: Pascal Gouedo <[email protected]>

MikeOpenHWGroup reviewed Nov 25, 2022

View reviewed changes

davideschiavone requested changes Dec 5, 2022

View reviewed changes

Pascal Gouedo added 4 commits December 5, 2022 12:18

Make uhartid and privlv CSRs only available when PULP_SECURE = 1

201470e

Signed-off-by: Pascal Gouedo <[email protected]>

As loop start and end must be word aligned, immediate value effect on…

83c5a27

… loop body instructions number can be doubled by shifting it by 2 rather than 1. Signed-off-by: Pascal Gouedo <[email protected]>

Started some CSR hierarchical classification.

b13ec2d

Signed-off-by: Pascal Gouedo <[email protected]>

Hardware Loops constraints clarification.

a57c9c8

Signed-off-by: Pascal Gouedo <[email protected]>

davideschiavone requested changes Dec 15, 2022

View reviewed changes

docs/source/corev_hw_loop.rst Outdated Show resolved Hide resolved

Added instructions names.

3c9d54d

Signed-off-by: Pascal Gouedo <[email protected]>

davideschiavone merged commit 3c02faf into openhwgroup:dev Dec 15, 2022

pascalgouedo deleted the dev_pgo_doc branch December 16, 2022 14:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Instructions re-encoding aligned with stable pulp_encoding_blocks-OPHW-2022-11-14.xlsx #740

Instructions re-encoding aligned with stable pulp_encoding_blocks-OPHW-2022-11-14.xlsx #740

pascalgouedo commented Nov 25, 2022

Silabs-ArjanB commented Nov 25, 2022

MikeOpenHWGroup left a comment

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022 •

edited

Loading

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022

davideschiavone Dec 5, 2022

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022 •

edited

Loading

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022 •

edited

Loading

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022 •

edited

Loading

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022 •

edited

Loading

davideschiavone Dec 5, 2022

pascalgouedo Dec 5, 2022

davideschiavone Dec 5, 2022

MikeOpenHWGroup Dec 5, 2022

pascalgouedo Dec 5, 2022

Instructions re-encoding aligned with stable pulp_encoding_blocks-OPHW-2022-11-14.xlsx #740

Instructions re-encoding aligned with stable pulp_encoding_blocks-OPHW-2022-11-14.xlsx #740

Conversation

pascalgouedo commented Nov 25, 2022

Silabs-ArjanB commented Nov 25, 2022

MikeOpenHWGroup left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pascalgouedo Dec 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pascalgouedo Dec 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pascalgouedo Dec 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pascalgouedo Dec 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pascalgouedo Dec 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pascalgouedo Dec 5, 2022 •

edited

Loading

pascalgouedo Dec 5, 2022 •

edited

Loading

pascalgouedo Dec 5, 2022 •

edited

Loading

pascalgouedo Dec 5, 2022 •

edited

Loading

pascalgouedo Dec 5, 2022 •

edited

Loading