Thursday, 2021-11-11

Veera[m]programmerjake:  What is the procedure to git pul repos01:32
Veera[m]python3 develop should be rerun?01:33
Veera[m]for openpower-isa: are these to be rerun: make svanalysis make pywriter make pyfnwriter01:34
programmerjakethe process I use isn't necessarily the best one...I git pull all repos then run the make commands in openpower-isa.git's readme01:34
programmerjake;a=blob;;h=708b81e2d4fb1f91e9311dc9ef58fcb12ad09e6a;hb=HEAD01:35 only rarely needs to be rerun01:35
programmerjake@lkcl likely uses a different process01:36
Veera[m]I just made new clones and setup again as per hdl-dev-repos and it is working01:36
programmerjakethat works, but is really slow01:37
Veera[m]lst = [f"subf 3, 1, 2"]... (full message at
Veera[m]I think e.intregs[3] should be -0x670e65d9e273943e01:51
Veera[m]In python3 prompt I ran hex(~0x833652d96c7c0058+0x1c27ecff8a086c1a+1)01:52
Veera[m]I beforehand tell that am weak in binary arithmetic01:54
programmerjakewell, actually the answer in the source is correct, the 0x98f... value is interpreting the 64-bit register value as an unsigned integer, the -0x670... value is interpreting it as signed. you get the unsigned value by masking out bits above bit 63: -0x670... & (2 ** 64 - 1) == 0x98f...01:57
programmerjakebit 63 in lsb0 form01:59
Veera[m]Thanks for explaining, i will find and learn it.02:00
programmerjakebasically all modern computers use two's complement as the representation of signed integers02:02
programmerjakepython takes the approach of conceptually having two's complement but extending it to an infinite number of bits, that way the programmer never has to worry about python integers overflowing02:04
programmerjakehopefully you found that useful and not just repeating what you already knew02:08
Veera[m]got it. it's print the signed value as unsigned value in hex.02:31
Veera[m]Add expected state to case_addze for addze in alu_cases unit test05:44
Veera[m]Is the code format and placement ok?05:45
Veera[m]Also removed a non-use code line: self.add_case(Program(lst, bigendian), initial_regs)05:45
Veera[m]I think Kyle has not updated CR fixes yet05:46
Veera[m]Rest of cases depend on it, except some xer lines cases.05:47
Veera[m]What is initial_sprs in: self.add_case(Program(lst, bigendian), initial_regs, initial_sprs)05:49
Chips4Makers[m]@lkcl: I'm afraid typing annotations is another thing we'll have to agree to disagree on. I am using an editor that does the type checking when typing the code and it has tremendously increased my productivity. For me there is no way back and all new code I write is with type annotations.09:01
programmerjakeyup, that's a major part of why I like using pyls and type annotations09:06
programmerjakeVeera initial_sprs is the initial values of the PowerPC special-purpose registers, that's where CR, XER, and similar are09:10
lkclVeera[m], you should never have to re-run "python3 develop", that's the whole point09:11
Veera[m]programmerjake: ok. do you know how to put expected=e in such case?09:11
lkclonly when the markdown or csv files change do you need to re-run make svanalysis etc.09:12
Veera[m]lkcl:  ok. I will never run python3 setup develop09:12
lkclwhich is also quite rare09:12
lkclbut will (and does) happen09:12
lkclVeera[m], try not to drop too long messages into matrix.  this is what happened:09:13
lkcl<Veera[m]> lst = [f"subf 3, 1, 2"]... (full message at
programmerjakeVeera idk off the top of my head, lkcl should know, i'll let him answer09:13
* lkcl catching up09:13
lkclit is also completely unnecessary to re-clone everything.09:14
lkclthis again you should never need to do09:14
Veera[m]yep. followed.09:15
lkcl"<Veera[m]> Is the code format and placement ok?"09:16
lkclif it runs, and passes, and produces no errors (syntax or otherwise) it's fine09:16
Veera[m]yes. it runs and passes. I am waiting for fix in CR print values?09:19
Veera[m]def case_addme_ca_0(self): I do not know how to put expected state and values!09:20
* lkcl hmmm09:21
lkcltry it anyway.  try case_cmp and see how it goes09:21
lkcldon't worry about what values come out, but... oh i know what: from the "dump" put that actually in the source, but commented-out09:23
Veera[m]It is still failing in case_1_regression "add." test and run09:23
lkclso to reiterate: if it is failing, then your immediate reaction should always always always, without fail, alter the program so that it does succeed09:24
Veera[m]Actually CR assertions fail09:24
lkclthen leave the "failed" version in as commented-out code09:24
lkcland alter the value so that it does succeed09:24
lkclwe can compare the two09:24
Veera[m]lkcl: I am too new to this.09:24
lkclagain, to reiterate: we know that these unit tests are correct09:25
Veera[m]So I cannot alter the required program!09:25
lkclbecause the HDL has already been compared against the Simulator, and against qemu09:25
lkclcannot alter the required program?09:25
lkcli don't understand09:26
lkclcan you commit what you have and git push it, i will take a look09:26
Veera[m] this bug has not been fixed till now09:26
lkclVeera[m], ignore that - let's investigate09:27
lkclpelase commit what you have so i can take a look09:27
lkclhmmm /tmp/expected/alu_cases/case_1_regression only has 3 lines when there are 6 tests, hmmm09:32
lkclohh it's overwriting09:32
Veera[m]def case_1_regression(self):... (full message at
Veera[m]cr assertion fails09:33
lkclVeera: again, that's too long a message so it has gone to a matrix off-site system09:34
Veera[m]cr0 = 0 but 0x809:34
lkcl<Veera[m]> def case_1_regression(self):... (full message at
lkclok i'll add that and try it09:34
Veera[m]lkcl: sorry09:34
Veera[m]lkcl: so how to put these kind of lengthy msgs09:35
lkclalthough it is a pain, paste them only a few lines at a time09:35
lkclmaximum of about... 409:35
lkclbut be careful of IRC flooding09:35
Veera[m]if some one posts in between there will be break09:35
lkclnot a problem09:35
Veera[m]max 4: ok09:35
lkclor, just commit it (as i asked)09:36
lkclit's rare to commit code that doesn't pass tests09:36
lkclbut ok09:36
lkclbecause the tests are there to show errors09:37
lkclokaaay so now we have an unexpected value, i'm committing that09:38
lkclwith a comment to say "it's being investigated"09:38
lkclVeera[m], do git pull09:41
lkclcommit 619081e1678d309228a758ba52cfeba22705095c09:41
Veera[m]saw the change(diff)09:45
lkcldid you run it?09:45
Veera[m]I had already run it in morning. If I run it will produce same error.09:46
Veera[m]Or have you made it work!09:46
lkclwhy do you believe that?09:46
lkcli am walking you through the process, so there may be some differences, yes?09:47
lkcli was not awake in your morning-time :)09:47
lkclthere will now be a difference between what you wrote in your morning-time, and what i just committed09:48
lkcland i would like to walk you through it, which i can't do if you don't run it :)09:48
lkclbecause you won't be able to see for yourself the differences in the output09:48
lkclbetween what you ran a few hours ago, and the results that are created by what i just committed09:49
lkclso please do a git pull and re-run the test09:49
lkclwhat results did you get?09:52
lkclit should be a lot shorter / quicker to run09:53
lkcl(you only have to do "git pull" on openpower-isa09:53
lkclno other commands need to be run09:53
lkclexcept to run the test itself of course09:53
Veera[m]ok it passes.09:53
lkclpython3 simple/test/ nosvp64 alu >& /tmp/f109:53
Veera[m]you put e.crregs[0] = 0x009:55
Veera[m]but with "add." opcode CR0 != 009:55
lkclyes.  sooOooo...09:56
Veera[m]the previuosly run expected state CR0 == 0x8 is correct09:56
lkclit looks like... the CRs are not being properly outputted09:57
lkcli need to check the Asserts09:57
Veera[m]That's what i am trying to say09:58
lkcli'm going to put the log in a loop first09:58
lkclthen the asserts09:58
lkcl        for i, (self.crregs, s2.crregs) in enumerate(09:58
lkcl                zip(self.crregs, s2.crregs)):09:58
lkcl            log("", i, self.crregs, s2.crregs)09:58
lkcl*then* asserts09:58
Veera[m]And previous  bug:730 comment 2309:58
lkclso that the asserts don't stop the entire log output from happening09:59
lkclthen we can see the numbering09:59
lkclok there's something weird going on10:01
lkclok i know what it is10:03
lkclkylel, you had this:10:04
lkclfor i, (self.crreg, self.crreg2) in enumerate(self.crreg, self.crreg2)10:05
lkclwhich will enumerate as expected, but destroy - overwrite self.crreg and self.crreg2 in the proces10:05
lkcllikewise for intregs10:05
lkclahhh noooow we have what i was thinking would happe10:06 0 0 810:06 1 0 010:06 2 0 010:06 3 0 010:06 4 0 010:06 5 0 010:06 6 0 010:06 7 8 010:06
lkclhaaa :)10:06
lkclVeera[m], okaaay try now. git pull10:08
lkclVeera[m], see how the number for the CR field is 76543210 not 01234567?10:08
lkclbut there was a 2nd error masking the 1st error10:09
Veera[m] 7 8 0 -- why value 8 and 010:14
Veera[m]test passes though10:15
lkclngggh ok, so the regs returned by HDLState.get_crregs() is inverted10:16
lkclit didn't have the 7-10:16
lkclfrickin Power ISA :)10:16
lkcl    def get_crregs(self):10:17
lkcl        self.crregs = []10:17
lkcl        for i in range(8):10:17
lkcl            rval = yield[7-i].reg10:17
lkclin soc/simple/test/teststate.py10:17
kylellkcl, ugh, sorry about that10:20
lkclit's only driving me slightly nuts.  like it does every time dealing with this :)10:21
kylelonly slightly? ;-)10:21
lkcl5 months tracking down numbering-order bugs, it's no surprise everyone else has the same problem10:24
* cesar is looking for the right Pipeline/Handshake class to use.10:25
lkclcesar: i'd suggest just using direct for now, but if you do want to use one, use SimpleHandshake10:26
lkclif you'd like to do "direct", see how things are set up in, now10:26
lkclit's pretty close to how things are in TestIssuer already10:26
kylelin hindsight I should have asked more questions way back when doing it by borrowing parts of the original code because it always struck me as odd instead of treating it as some sort of magical black box. live and learn.10:28
lkcloh you actually changed the numbering from what it was?10:29
lkclVeera[m], ok all done10:30
lkclgit pull on openpower-isa _and_ soc this time10:30
Veera[m]did you changed cse to case for all the tests10:31
Veera[m]trying what you said10:31
lkclyes, to save time10:34
cesarlkcl: I'd rather use "direct" (derive straight from ControlBase), and do my own valid/ready handshake. Thanks!10:34
lkclcesar, yehyeh, that's what i do in :)10:35
lkcldo try to keep to the StageAPI though, by adding ispec() and ospec() functions10:35
lkclthis will "force" a need to create Input and Output data structures10:35
lkclwhiiiich of couuurse, you can then use the output data struct from the previous as the exact same input data struct for next10:36
lkclwhich is the whole point of the Stage API :)10:36
Veera[m]lkcl: test working perfect10:36
lkclVeera[m], kylel, hooraaay10:37
Veera[m]lkcl: is there any simple way to revert def cse_ to def case_10:37
lkclVeera[m], if you use vi: ":%s/def cse_/def case_/g"10:38
lkcli've done it and committed it already10:38
lkclgit pull10:38
lkclyou can do the opposite of course as well10:38
Veera[m]saw it10:40
lkclok now i need something to drink, and to try to get rid of this massive headache10:40
lkclback later10:40
Veera[m]is there a reason why register values are printed in decimal value!10:40
lkclno :)10:47
lkcl            # pc and intregs10:47
lkcl            sout.write("%se = ExpectedState(pc=%d)\n" % (lindent, state.pc))10:47
lkclchange that to "pc=0x%x"10:48
lkclthis is correct                     msg = "%se.crregs[%d] = 0x%x\n"10:48
lkcloh wait... do you mean in the assertions?10:48
lkcl            self.dut.assertEqual(intreg, intreg2,10:49
lkcl                "int reg %d (%s) not equal (%s) %s. got %x  expected %x" %10:49
lkclthe python unit test code - the function assertEqual - will automatically print out the values it is comparing if they are different10:49
lkclit does so.... in decimal10:49
lkclbecause that's no so useful, we have added a debug printout line, which _does_ print out in hexadecimal10:50
lkcl got %x  expected %x10:50
lkclyou can't disable the default behaviour of assertEqual10:50
lkclso you get both10:50
Veera[m]lkcl: def case_addme_ca_0(self): how to put expected=e in it!10:56
lkclMaciejPijanowski, ghostmansd[m], ping, you saw the NLnet cavatools port is approved?10:57
lkclVeera[m], ahh that one will be fun10:57
lkclprobably something like... oh i know10:59
lkcladdme_e = ExpectedState(...)11:00
lkcladdme__e = ExpectedState(...)11:00
lkcladmeo = ExpectedState(...)11:00
lkcladdmeo_ = ...11:00
lkcl1 sec let me do a demo11:01
ghostmansd[m]lkcl: Hi, yes, I'm reading it now. I'll be able to deal with it at the end of this month (likely circa November 23).11:03
lkclghostmansd[m], star11:04
ghostmansd[m]And for sure no sooner than I get something from NLnet. :-)11:04
lkclyes. sigh11:04
lkclVeera[m], done, git pull11:30
lkclso you can copy that style for case_addme_ca_111:30
lkclby looking at /tmp/expected/alu_cases/case_addme_ca_1.py11:31
lkcland going, "hmm that expected state produced that value, so put that inside the "if" statement..."11:31
lkcli put in some comments so you can see how it works11:32
lkclalso if you do:11:32
lkcldiff -u /tmp/expected/alu_cases/case_addme_ca_0.py11:32
lkcl     /tmp/expected/alu_cases/case_addme_ca_1.py11:32
lkclyou should be able to much easily guage what to do11:33
lkclbut yes, e.crregs[7] = 0x4 is, i think, correct!11:34
lkclor... errr...11:34
lkclprobably not, actually11:34
lkclthat's sticky overflow11:35
lkclwhich should go into CR0.SO11:35
kylellkcl, You want me to run it through qemu?12:39
lkclkylel, i got disconnected, luckily i saw the opf chat.  yes good idea16:28
lkclalthough, there's actually no guarantee that qemu has this right!16:45
kylelusing addme. with 0x7ffffffff18:47
kylelcr: 0b100000000000000000000000000000018:49
kylelbig endian, shows 418:49
kylelin cr718:50
kylelor then it could be cr0 because reversed?18:53
kylellol, ugh18:54
kylelok, verified bit ordering using case_cmp2 which should modify cr219:10
kylelthat one is: 0b100000000000000000000019:11
kylelso indeed, cr0...cr7 order from qemu19:12
lkclso it is CR0.SO that's being set, not CR7.SO21:07
kylelappears that way21:32
Veera[m]lkcl: hey how much money you are setting for this bug21:41
lkclVeera[m], depends roughly on how long it takes. i'll work it out as we go along, then you tell me if it's ok?21:42
Veera[m]lkcl: let's see21:43
Veera[m]lkcl: running def case_addme_ca_0(self) for "addmeo." : /tmp/expected/alu_cases/ does not shows e.crregs[0] = 0x422:59
lkclVeera[m], kylel added a test that, once an expected case is added, it no longer gets entered into /tmp/expected23:04
Veera[m]got it. So i was looking at old one!!!23:17
Veera[m]reran it - it showing correctly23:17

Generated by 2.17.1 by Marius Gedminas - find it at!