| --- Log opened Sun Jul 06 00:00:06 2014 | ||
| blueCmd | not super modular, but I guess I can add something to make it configurable | 00:00 |
|---|---|---|
| olofk | blueCmd: Any particular reason that your top-level has a .sv extension? | 08:20 |
| olofk | stekern, blueCmd: Did you actually find any bugs in wb_ram? | 08:20 |
| stekern | olofk: apart from the faulty adress generation, no | 10:15 |
| blueCmd | olofk: what stekern said, I tore out the burst logics and it works | 11:47 |
| blueCmd | olofk: .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 there | 11:48 |
| blueCmd | migen will replace the need for systemverilog anyway | 11:48 |
| blueCmd | olofk: http://1c745be7b97f9492.paste.se/ | 11:57 |
| blueCmd | olofk: I was also a bit worried about that waddr is one clock cycle behind the other signals AFAIK | 11:57 |
| blueCmd | AFAICS* | 11:57 |
| blueCmd | stekern: can I disable the dcache at runtime? | 13:05 |
| blueCmd | or flush it | 13:07 |
| stekern | blueCmd: the delayed write address is ok, since the we signal depends on wb_ack (which is regisgered) | 13:09 |
| stekern | to your other question, yes and yes | 13:10 |
| blueCmd | I'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 one | 13:11 |
| stekern | what is a 'RAM loop? | 13:12 |
| blueCmd | assembler wise it looks like it's doing the right thing, I have memory barriers and volatile markings | 13:13 |
| blueCmd | stekern: eh, if you have a stuck address line | 13:13 |
| blueCmd | or something like that | 13:13 |
| stekern | selvä | 13:13 |
| blueCmd | I think i broke stekern | 13:13 |
| stekern | ;) | 13:14 |
| stekern | the multilingual module in stekern is buggy | 13:14 |
| blueCmd | I set dcache to DISABLED but the problem still persists though | 13:15 |
| stekern | but, yeah, you have to manually flush (or disable) cache for those two accesses to be 'coherent' | 13:15 |
| stekern | ok, that's odd then | 13:16 |
| stekern | ah, no... it should be "NONE" | 13:17 |
| blueCmd | I think I broke my code as well | 13:17 |
| blueCmd | aha ok | 13:17 |
| stekern | I would have liked those boolean parameters to be 0/1 | 13:18 |
| stekern | but no point in changing that around now I think | 13:18 |
| blueCmd | stekern: use http://www.uclassify.com/browse/prfekt/Mood | 13:19 |
| blueCmd | then you can have .FEATURE_DCACHE("SLIGHTLY DISCONTENT") | 13:19 |
| blueCmd | we should host the arch specification in an HTML version | 13:21 |
| stekern | yes, and convert it to ascii-doc or something | 13:22 |
| blueCmd | so, to flush an address I would use DCBFR and just write the address there? | 13:23 |
| blueCmd | and to disable it write 0 to DCCR ? | 13:24 |
| blueCmd | oho, we have or1k_dcache_disable and or1k_dcache_flush | 13:24 |
| stekern | what is dccr? | 13:25 |
| stekern | its dce in SR iirc | 13:25 |
| blueCmd | Data Cache Control Register | 13:26 |
| blueCmd | right, DCE would probably be less violent | 13:26 |
| stekern | I doubt writing 0 to that would disable the cache | 13:32 |
| stekern | dccr I mean | 13:37 |
| blueCmd | so both a less violent and a working way then | 13:37 |
| -!- Netsplit *.net <-> *.split quits: atgreen, FreezingCold, trem | 14:42 | |
| -!- Netsplit over, joins: FreezingCold | 14:48 | |
| -!- Netsplit over, joins: trem | 14:48 | |
| blueCmd | https://asciinema.org/a/10663 | 19:49 |
| stekern | so what was the problem? | 20:38 |
| stekern | nevermind, I forgot that we never got past disabling cache when you still had problems | 20:39 |
| stekern | my improved mul passes the good old mul test now too | 20:41 |
| olofk | blueCmd: write address is delayed because writing and reading has different timing | 21:04 |
| olofk | For 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 cycle | 22:32 |
| olofk | Note that ram_wb returns the data on the same cycle as you provide the address, but that will never map to real block RAMs | 22:32 |
| olofk | Or it might actually for some types of ram, but you will have a really crappy timing path there | 22:33 |
| olofk | So ram_wb was never meant to be implemented in hardware. Just a basic simulation model | 22:34 |
| blueCmd | olofk: yes, ram_wb sucked for that, that's why I wanted to use your much nicer wb_ram | 22:50 |
| blueCmd | but it's painful to carry patches, so please fix it! :P | 22:50 |
| olofk | I won't be able to commit for a few days, so someone else will have to do that | 22:59 |
| olofk | gtgg | 22:59 |
| blueCmd | olofk: np :) take care | 23:01 |
| --- Log closed Mon Jul 07 00:00:08 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!