IRC logs for #openrisc Sunday, 2014-07-06

--- Log opened Sun Jul 06 00:00:06 2014
blueCmdnot super modular, but I guess I can add something to make it configurable00:00
olofkblueCmd: Any particular reason that your top-level has a .sv extension?08:20
olofkstekern, blueCmd: Did you actually find any bugs in wb_ram?08:20
stekernolofk: apart from the faulty adress generation, no10:15
blueCmdolofk: what stekern said, I tore out the burst logics and it works11:47
blueCmdolofk: .sv for some systemverilog features I need for some interconnects. I might end up renaming the orpsoc/ directory back to .v though, I don't use any systemverilog features there11:48
blueCmdmigen will replace the need for systemverilog anyway11:48
blueCmdolofk: I was also a bit worried about that waddr is one clock cycle behind the other signals AFAIK11:57
blueCmdstekern: can I disable the dcache at runtime?13:05
blueCmdor flush it13:07
stekernblueCmd: the delayed write address is ok, since the we signal depends on wb_ack (which is regisgered)13:09
stekernto your other question, yes and yes13:10
blueCmdI'm trying to detect RAM loops in my diagnostics program. I have two pointers: 0x0 and 0x100000 - they both point to the same ram area, but writes to the first one doesn't "change" the second one13:11
stekernwhat is a 'RAM loop?13:12
blueCmdassembler wise it looks like it's doing the right thing, I have memory barriers and volatile markings13:13
blueCmdstekern: eh, if you have a stuck address line13:13
blueCmdor something like that13:13
blueCmdI think i broke stekern13:13
stekernthe multilingual module in stekern is buggy13:14
blueCmdI set dcache to DISABLED but the problem still persists though13:15
stekernbut, yeah, you have to manually flush (or disable) cache for those two accesses to be 'coherent'13:15
stekernok, that's odd then13:16
stekernah, no... it should be "NONE"13:17
blueCmdI think I broke my code as well13:17
blueCmdaha ok13:17
stekernI would have liked those boolean parameters to be 0/113:18
stekernbut no point in changing that around now I think13:18
blueCmdstekern: use
blueCmdthen you can have .FEATURE_DCACHE("SLIGHTLY DISCONTENT")13:19
blueCmdwe should host the arch specification in an HTML version13:21
stekernyes, and convert it to ascii-doc or something13:22
blueCmdso, to flush an address I would use DCBFR and just write the address there?13:23
blueCmdand to disable it write 0 to DCCR ?13:24
blueCmdoho, we have or1k_dcache_disable and or1k_dcache_flush13:24
stekernwhat is dccr?13:25
stekernits dce in SR iirc13:25
blueCmdData Cache Control Register13:26
blueCmdright, DCE would probably be less violent13:26
stekernI doubt writing 0 to that would disable the cache13:32
stekerndccr I mean13:37
blueCmdso both a less violent and a working way then13:37
-!- Netsplit *.net <-> *.split quits: atgreen, FreezingCold, trem14:42
-!- Netsplit over, joins: FreezingCold14:48
-!- Netsplit over, joins: trem14:48
stekernso what was the problem?20:38
stekernnevermind, I forgot that we never got past disabling cache when you still had problems20:39
stekernmy improved mul passes the good old mul test now too20:41
olofkblueCmd: write address is delayed because writing and reading has different timing21:04
olofkFor reads, you will get the data one cycle after you have supplied an address. For writes, you supply the address and data on the same cycle22:32
olofkNote that ram_wb returns the data on the same cycle as you provide the address, but that will never map to real block RAMs22:32
olofkOr it might actually for some types of ram, but you will have a really crappy timing path there22:33
olofkSo ram_wb was never meant to be implemented in hardware. Just a basic simulation model22:34
blueCmdolofk: yes, ram_wb sucked for that, that's why I wanted to use your much nicer wb_ram22:50
blueCmdbut it's painful to carry patches, so please fix it! :P22:50
olofkI won't be able to commit for a few days, so someone else will have to do that22:59
blueCmdolofk: np :) take care23:01
--- Log closed Mon Jul 07 00:00:08 2014

Generated by 2.15.2 by Marius Gedminas - find it at!