[libre-riscv-dev] libre-riscv-dev Digest, Vol 3, Issue 5

[lkcl]

On Wed, Nov 14, 2018 at 7:35 AM Daniel Benusovich
<flyingmonkeys1996 at gmail.com> wrote:
>
> Alrighty some progress has been made with the unit test sv_addw_elwidth.S.
>
> I understand most of what is happening though somethings still elude me.
>
> I have created a test case (not committed or patched yet) where x15
> is a scalar while the second parameter is not (x12 - x14):
>
>         SV_ELWIDTH_TEST(  3, 0, 0, 0, 0, 1, 1,

 vl=3,
 ew1=dflt, ew2=dflt, ew3=dflt,
 vec1=false, vec2=true, vec3=true

>                 0xffffffff8b6bab8b,  0xffffffff89694929,  0x0000000042322212 )
>
> That actually passes!

 woo!

> Truly a miracle from the gods. However, during the grueling trials that came
> from figuring this out a few problems came to light.
>
> 1. Whenever the test fails it goes into an endless loop after the
>  BNE in the TEST_SV_IMM macro.

 yeahhh i know - it's why i said run them manually by a cut/paste.

> Not to sure where it goes but it starts to call some BEQ that
> loops forever that i could not find (Got this by looking at the
> generated log before it was deleted or crashed my computer).
> Not fun at all.

 whooops :)

 the deletion is carried out by the Makefile, so manually run it by
cut/pasting the command that comes from the console output, and press
ctrl-c after like 1 second.

>  From what I could tell it is supposed to exit out and post an error
> like the other tests but this one for one reason or another does not. Any ideas?

 none at all... and i've seen standard tests do the same, so i just went,
 "y'know what? not my problem: work around it".

> 2. An additional attempt to create a test case resulted in the following:
>
>         SV_ELWIDTH_TEST(  3, 0, 0, 4, 0, 1, 1,
>                 0xffffffff8b6bab8b,  0xffffffff89694929,  0x0000000042322212 )

ah.  right.  you see that width argument set to 0x4? the limit on the
range is 0-3 (2 bits).  and the macros don't cut the fields off, they
just | together, so what is *actually* happening is...

#define SV_REG_CSR(type, regkey, elwidth, regidx, isvec) \
  (regkey | (elwidth<<5) | (type<<7) | (regidx<<8) | (isvec<<15))

that will be setting the type to 1 (which it's already set to).  and
the answer happens to be the same if done as 32-bit if 64-bit, so,
that'll be why that one worked.

> From what I understand the widths of the vectors determine the
> length of data to be tossed into the source.

 yeees... it's more that, where normally a register is treated as a
discrete fixed-length entity, e.g. 64-bit, SV goes, "right, let's go
back to viewing the *whole* register file as if it was a contiguous
SRAM, "registers" just indicate the "starting point" of where we'd
like data to come to/from, VL says how many elements we want to do,
and elwidth says how wide each element is".

 it's a leeetle different perspective that, ultimately, ends up being
exactly as you describe.

> I'm pretty sure a misunderstanding has occurred.

 you're just using the wrong constants.  if you check other ones, i
define and use SV_W_DFLT and SV_W_16BIT:

         SV_ELWIDTH_TEST(   SV_W_DFLT, SV_W_DFLT,  .... )


> I see in the other test cases how modifying the length of the source
> elements determines the precision of the data in the destination register

 bitwidth.
ew=0 -> bitwidth=XLEN
ew=1 -> bitwidth = 8
ew=2 -> bitwidth = 16
ew=3 -> bitwidth = 32

> This is mostly an update as to what is happening on my end.

 cool.

> With some more experimentation the answers I seek will no doubt
> be found but an explanation always helps everything move along quicker.
> I will continue to add test cases and submit a patch for this unit test
> until told to otherwise. Let me know if that is alright.

 the modifications needed, as described in comments in
sv_addw_elwidth.S, are actually on the critical path that's blocking
me from working in parallel with you, to add other unit tests, in
other files, and also holding me up on doing a follow-up reorg.

 if you can do that first, it will be easier for you to add additional
unit tests (because you will be able to specify alternative source
testdata as one of the macro's parameters).

> Hope everything is going well,

 getting there :)

l.