*** cesar[m]11 is now known as cesar[m]1 | 00:57 | |
cesar[m]1 | lkcl: OK, I think I'm done with the SVP64 CR predication. I'm ready to work on dcache. What do you need? | 21:56 |
---|---|---|
*** gatecat <gatecat!sid281702@gateway/web/irccloud.com/x-ykmatmbhtttewclv> has left #libre-soc | 21:57 | |
lkcl | cesar[m]1, fantastic. i've a case committed (very recently) | 22:00 |
lkcl | the wb_in.stall, if set, results in requests that come one cycle too late | 22:01 |
lkcl | comment out line 1648 | 22:02 |
lkcl | and you will see that dcache rams wr_data and wr_addr are one cycle out of sync | 22:03 |
cesar[m]1 | Sure, I'll take a look. | 22:06 |
cesar[m]1 | By the way, I'm having a new error on this test: | 22:08 |
cesar[m]1 | python ~/src/openpower-isa/src/openpower/decoder/isa/test_caller.py DecoderTestCase.test_cmpeqb | 22:08 |
cesar[m]1 | File "/home/cstrauss/src/openpower-isa/src/openpower/decoder/isa/comparefixed.py", line 99, in op_cmpeqb | 22:09 |
cesar[m]1 | src1 = GPR[RA] | 22:09 |
cesar[m]1 | NameError: name 'RA' is not defined | 22:09 |
lkcl | cesar[m]1: remove the entirety of the pseudo-code from pywriter | 22:10 |
lkcl | use the new openpower-isa repo | 22:10 |
lkcl | and re-run "make pywriter", there | 22:11 |
lkcl | let me run that here and see if it happens | 22:11 |
lkcl | that's running now | 22:12 |
lkcl | cesar[m]1: no, doesn't happen here. does give a silly error | 22:14 |
lkcl | File "openpower/decoder/isa/test_caller.py", line 320, in test_mtcrf | 22:14 |
lkcl | self.assertEqual(sim.cr, SelectableInt(expected << ((7-i)*4), 32)) | 22:14 |
lkcl | which i kinda expected | 22:14 |
cesar[m]1 | I fixed this earlier today, please do a git pull. | 22:17 |
cesar[m]1 | ... on the openpower-isa repo. | 22:18 |
lkcl | ah, star | 22:19 |
lkcl | brilliant, you got up-to-date on the new openpower-isa repo, yay | 22:20 |
lkcl | ok, so, dcache. | 22:20 |
lkcl | the test, what it does is: it a load at address 6*8 | 22:21 |
lkcl | (line 1798, 1806) | 22:21 |
lkcl | that is actually where the problem occurs, straight away. | 22:21 |
lkcl | actually i will commit a comment-out of the dcache_store 1 sec | 22:22 |
lkcl | what dcache does is, when it sees a load request, it actually fires off *eight* 64-bit requests | 22:23 |
lkcl | to fill the entire cache line | 22:23 |
lkcl | each of those 8 loads, the result is written into the sram. | 22:25 |
lkcl | in this case, it is replace_way=0b10 (2nd sram - there are 4). you can see do_wr1 is set to 1 | 22:26 |
lkcl | BUT | 22:26 |
lkcl | you can also see, wr_data is *one cycle early* from the wr_data | 22:26 |
lkcl | r1.store_row | 22:28 |
lkcl | at line 1129 | 22:28 |
lkcl | line 1330, r1.store_row.eq(req_row) - req_row is delayed by 1 clock cycle | 22:36 |
lkcl | cesar[m]1, i think i have it. it is to do with r1.real_adr at line 1424 | 23:00 |
lkcl | oh btw, there is a major bug in microwatt, long-standing | 23:17 |
lkcl | cesar[m]1: all wishbone addresses are 64-bit *include the three LSBs* which should never be done | 23:18 |
lkcl | the "sel" lines are supposed to be used to specify the bytes, effectively encoding the three LSBs of the address in unary | 23:18 |
lkcl | but, in microwatt, what they have done is mistakenly put the 3 LSBs onto the address bus | 23:19 |
lkcl | but this is *consistent* across *all* code | 23:19 |
lkcl | therefore, it "works". | 23:19 |
lkcl | in litex, those 3 LSBs are set to zeros, externally. | 23:19 |
lkcl | the WB spec says, if you have a 64-bit data bus, and 32-bit addresses, you should only put (32-(64//8)) bits onto the WB bus. | 23:20 |
lkcl | microwatt puts 32. | 23:20 |
cesar[m]1 | Interesting. Are those 3 LSB bits decoded at all on the slave, or simply ignored / not connected? | 23:22 |
lkcl | inside microwatt? | 23:22 |
lkcl | they should never have been there in the first place | 23:22 |
lkcl | i am *hoping* they are not used accidentally as "state" information | 23:23 |
lkcl | ROW_LINE_BITS is set to 3 (which is the 3 LSBs) | 23:24 |
lkcl | actually... 1 sec | 23:25 |
lkcl | need to create something called ROW_SIZE_BITS | 23:25 |
programmerjake | > the WB spec says, if you have a 64-bit data bus, and 32-bit addresses, you should only put (32-(64//8)) bits onto the WB bus. | 23:27 |
programmerjake | isn't that actually (32-log2(64/8)) bits? | 23:27 |
lkcl | programmerjake, yes, thank you, good catch | 23:27 |
lkcl | ok, late here. been at this a while. night all | 23:51 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!