IRC logs for #openrisc Wednesday, 2013-09-04

--- Log opened Wed Sep 04 00:00:41 2013
stekern_franck_: you now have your name in wb_sdram_ctrl too ;)05:25
olofkblueCmd_: Congratulations05:46
olofkHmm.. looks like my test bench stops because I run out of random :(06:00
olofkWhere can I buy more random?06:00
stekernat any random store06:01
olofkIt's ok now. I found some more06:10
olofkBut now I got a read mismatch after 16931 transactions06:12
blueCmd__franck_: moving to Ireland to start work next thursday so not just yet ;)06:19
olofkblueCmd_: Are you hired to spread the gospel of OpenRISC to Ireland? :)06:38
olofkstekern: Is it expected to always have to do a refill when I write data and read it back?06:40
olofkBecause my failing transaction never enters refill06:40
stekernolofk: no, if the data to be written is in the cache buffer, it should just write it there and not refill on read06:42
stekern...but if the data is *not* in the cache buffer, then you of course should expect a refill06:48
stekernand to elaborate a bit on how the cache works (since you asked about it earlier, but maybe you've figured it out already). It's actually a pretty ordinary write-through cache, but with only *one* cache line06:50
stekerneach port has it's own "cache" and they are coherent (i.e. writes (should) go to all ports caches)06:51
stekernand writes (as you noticed) go through a fifo06:52
blueCmd_olofk: hah, sadly no06:52
olofkstekern: And bufhit is asserted when the requested address is cached?07:12
olofkLooks like the cache isn't updated. I found that the value I'm getting back has been written in an earlier transaction07:18
stekernok, is this within a single port?07:20
stekernor is it the coherency logic that is failing?07:20
olofkYes. Each master writes to a different memory area07:21
olofkSo single port07:21
olofkIt works if I separate the requests by a few cycles07:21
stekernso, when the write happens, is bufhit asserted then?07:23
olofkw8. Need to rerun with less wait time between transactions07:25
olofkThe transaction is two data long, and the second data fails. On the first, bufhit is asserted, but not on the second07:27
olofkIt's a wrap burst, with addresses 0x31C, 30007:27
olofkbte = 10 (Wrap 8?)07:28
olofkyep. wrap 807:28
olofkah.. yes.. and the previous transaction did a 1 cycle access to address 0x314. That might be what makes it confused07:31
stekernhmm, with the latest bugfixes I've done, I see that the writes are a bit weird...07:31
stekernbut that's probably unrelated to this07:31
stekernnon-burst writes are now written twice to the fifo07:33
olofkThree cycles between accesses seems to do the trick07:36
stekernmaybe it's the handshaking latency between sdram and wb that is causing that07:38
olofkhmmm... it's not the RAW timing for that cycle that seems to be the problem. It's the delay from the previous read cycle that needs to be increased07:41
stekernhmm, I'm starting to doubt that this was entirely correct:
olofkI haven't really figured out enough of the code to analyze that patch07:45
LoneTechwithout understanding the rest of it I can't tell if either is right, but it does look like it's conflating the issues of burst and acknowledge behaviour07:46
olofkBut I see now that when it fails, the refill block that is read from the previous transaction hasn't finished when the failing transaction starts07:46
LoneTechIIRC the WB spec also had an odd and possibly unintended requirement that the byte selects not vary07:47
olofkI suspect that the data written in the failing transaction is overwritten by the data that was read back from the ram07:48
olofkLoneTech: wb_sel is static here, but I noticed that too. And I agree that it feels like unintended07:48
LoneTechthis change seems to remove the double write prevention for non-bursts07:52
stekernolofk: I think that this is needed for the writes to be correct:
stekern(it will still dual write into the cache, but that's not so important)07:53
LoneTech(non-bursts including end of bursts)07:54
olofkstekern: Apply against master?07:55
stekernyes, but there might be more dragons now when I think about it...07:56
olofkShould I try it anyway?07:57
stekernah, now I was just imagining the dragons, I think that should be ok07:58
stekernthe dragons are only related to the buf write, since the addres and data that go there is delayed by one clock cycle07:59
stekern... I should probably change that07:59
stekernso, yes, try that07:59
olofkNope. Sorry08:00
olofkBut I'm not completely sure about the state of my wb_port.v now. Haven't got git on the machine I run it on, so it's getting a bit patchy now :)08:01
olofkNah. it looks good. Only difference was the patch from _franck_08:04
olofkok. Second data in the last transaction is never written to the cache08:15
stekernbecause bufhit isn't asserted?08:21
olofkYes, bufhit is only asserted for the first data (of two) in the write08:26
olofkI can see that the first is written correctly to the bufram08:26
olofkYou want another bmp? :)08:28
stekerni'm on the phone, so can't look at the bmp, but isn't the second write within the cacheline?08:28
stekernso then the write is correct08:30
olofkIs it?08:30
stekernbut how can it not be within the cacheline?08:30
olofkHmm.. did I misunderstand "within the cacheline"?08:31
olofkOnly one of two is written to the bufram08:31
stekernok, i got that. the question is, is that correct?08:32
olofkI suppose not, because when I read it back, I'm getting an old value08:32
stekernso, then it is within the cacheline (i.e. the address you sre writing to in the second write is in cache)08:34
olofkah... ok. Yes. I think that's the problem, because the previous transaction refills that position08:35
stekernso it's the bufhit logic that bugs out08:36
stekerni've got a hunch, could it be that the sdram is still refilling when the write happens in wb domain08:39
stekernsdram domain08:39
stekernsdram domain is refilling, wb domain writes is what I'm trying to say...08:41
olofkYes, that's what I'm thinking too08:42
olofkEspecially since it works if I delay the write for one cycle, so that the previous refill from SDRAM finishes first08:43
stekernI have guard against that in IDLE stat before going to write, can that condition change during the burst?08:43
stekernif so, the guard have to be added to WRITE state as well08:44
stekernor can something slip through that guard08:45
stekernyes, it can...08:46
stekern(i'm just reading the code from memory though)08:46
olofkNow that's seriously spooky08:47
stekernso, in IDLE, we have to check that all bits in buf_clean is set before going to write08:48
stekerntest that08:48
stekernuse the _wb signal of buf_clean08:48
olofkWhere do you check that all data from SDRAM has been returned during a refill?08:49
stekernwhat's spooky?08:50
olofk08:46 < stekern> (i'm just reading the code from memory though)08:50
olofkHmm.. should I just prevent the transition to WRITE, or should I disable wb_write_ack and wb_write_bufram too?08:52
stekernIf I understand your question right, when all bits in buf_clean is set, the refiöl is done08:52
olofkah. ok08:53
stekern(spooky) but I physically read the code just an hour ago08:53
stekernput it in the guard clause for the whoöe write thing08:54
olofkHmmm... adding & &buf_clean_wb to the if statement was not a good idea08:58
olofkNo failing transaction, mainly because no transactions at all are being processed08:59
stekerndo bufhit & bufclean...09:02
olofkLunch now09:05
olofkams: That's what she said!09:42
olofkstekern: Still not looking any good. Trying to figure out something10:00
olofkstekern: I got something working now10:06
olofkSomething like this:
olofkIntendation is fucked up. Haven't got verilog-mode on this machine10:11
olofkRerunning with 3*200000 transactions to see what new bugs I can uncover :)10:13
olofkYep. That works too10:17
olofkNow I just need to rerun it with different clock combinations, and allow masters to access the same memory to check for cache coherence bugs10:17
olofkOh.. and increase the maximum burst length10:18
olofkLarger bursts works fine10:21
olofkBut faster wb_clk than sdram_clk fails :(10:27
stekernyes, I can imagine that will bring out corner cases11:34
stekerndoesn't sound like a very likely scenario though11:35
stekernto have bus freq > memory freq11:35
stekernbut if there's some obvious bugs that it brings out, it's of course good11:36
stekernhmm, looking at your patch, it doesn't actually exclude the corner case I thought were causing the bug11:39
stekernhow can your condition ever be true?11:40
stekernobviously it can since it fixes the bug you are seeing, but I don't understand it11:41
stekernah, I missed a ')' in the patch11:41
stekernso it does exclude the corner case I was thinking about11:42
stekernbut it excludes too much ;)11:43
stekernit should only be: bufhit & !refill_busy11:44
stekernI don't understand why 'bufhit & (&bufclean_wb)' didn't work though11:48
stekernolofk: so the question is, doesn't 'bufhit & !refill_busy' work?11:52
_franck_I've never tried my jtag_vpi thing on complete soc until today. That's not very usable...13:58
_franck_That's so slow13:58
_franck_olofk: stekern do you making a testbench for every system in orpsocv3 worth it ? We could have only the generic system for debugging purpose.17:53
stekern_franck_: I think we *should*18:14
stekernthat said, I know it's a problem with altera and xilinx stuff not playing with iverilog18:15
stekerni.e. you need modelsim for it18:15
_franck_I did a pull request for openrisc/orpsocv3 but I think I can pull those changes myself there...19:17
_franck_stekern: I sent you a patch (github pull request) to change arbiter.v -> wb_port_arbiter.v in your wb_sdram_ctrl19:41
stekern_franck_: pulled19:56
stekernnice, github makes a link to the right commit if you reference it by its hash in another commit20:03
_franck_my Cyclone II does not support NEW_DATA_WITH_NBE_READ for its dpram...20:42
_franck_stekern: do you think we can avoid this situation in your wb_sdram_ctrl and remove this option in dpram_altera ?20:43
--- Log closed Thu Sep 05 00:00:42 2013

Generated by 2.15.2 by Marius Gedminas - find it at!