IRC logs for #openrisc Monday, 2016-05-23

--- Log opened Mon May 23 00:00:19 2016
imphilolof, the removal of top->v-> is part of the newest verilator release. there is a command line option to get back the old behavior04:38
olofimphil: Ah.. cool. Thanks04:54
olofI'll probably set the parameter then, to let people have some time to adjust04:54
olofFor the existing systems at least04:54
imphilI guess the old verilator does not support the parameter; so you need to version-check at one point anyways04:55
olofHmm.. true, but hopefully I just get a warning with older versions04:55
imphilit seems this is the first info i got out of reading planet librecores :)04:56
shorneHello, sorry about all the disconnects earlier. My network was saturated and I wasn't around to stop it05:19
bandvigHello! Does anybody know which latest Xilinx tool (WebPack license) supports SPARTAN-6 series?05:27
bandvigHmm... it looks like ISE 14.7.05:45
SMDwrkbandvig: yep, it's ise14.705:47
SMDwrkI think there may be dcache issue: it happens that we strobe lasts i.e. for 3 cycles and we write normal data, normal data and some trash. The question is what's wrong: too long strobe or that trash.
stekernSMDwrk: pro-tip, increase the hier to three or something, it makes it a lot easier to figure out what signals you're looking at08:30
SMDwrkstekern: you mean like this
stekernno, there is a setting somewhere called "Set max hier" or something like that08:36
stekernit will give the "path" to the signal names08:36
SMDwrk but now signals are hardly visible(08:37
stekernah, but you don't need to show *that* much of the path ;)08:38
SMDwrkI think there should be no "xx00xxxx" signals in the design though. Verilator may pass because it has only "1" and "0" states and no others, but I don't know for sure08:38
stekernwell, there can be 'x'es for uninitialized memories etc08:39
SMDwrk that's what you asked for, I guess08:39
SMDwrkThere could be, yes, but not after running 1M cycles I think08:40
stekernyes, that's good08:40
stekernwell, if only one byte has been ever written to in that position in the cacheline, it can happen08:43
stekernbecause, it's a read-modify-write with byteselect08:44
SMDwrkstekern: and here starts the problem08:49
SMDwrkthat cache entry with 0x63b address seems wrong to me08:50
SMDwrkI wish I could search across .vcd somehow08:51
stekernfor values? you can do that08:55
SMDwrkYep, just googled that, thanks08:57
olofSMDwrk: Did you turn on the option to clear the register files?08:59
SMDwrkolof, yep, but no difference09:02
olofSMDwrk: Ah ok. It was worth a shot09:05
stekernSMDwrk: yeah, I'm not saying you haven't found a bug, but just that because you see X's that doesn't necessarily mean something is wrong09:18
SMDwrkstekern: can you tell in which cases "x" are ok?09:22
ZipCPUOn opencores, someone writes that they cannot generate "orpsoc.ngc".  That they get make errors.  Does anyone know about this?09:48
SMDwrkFrom where mor1kx_lsu_cappuccino.dbus_dat_i comes? Seems somewhere from outside of cpu:
SMDwrkoh, it goes to ram I guess10:46
SMDwrkThe question is why we fail to read something from ram:
SMDwrkI think problem may be the following: ram is not initialized, so it contains "xxxxxxxx" values, and code sometimes writes 3 of 4 bytes of mem, so last byte is still  "xx" or even reads cells which have not been written yet.13:24
SMDwrkolof, do you know if I can somehow initialize ram with zeroes using fusesoc?13:29
olofSMDwrk: You could hack the wb_ram component to do that, but it doesn't sound right that the software reads uninitialized RAM areas. Sounds like an sw issue to me15:54
SMDhomeolof At least I'd like to try it and see if it helps15:55
olofSMDhome: Yeah, that's probably a good idea16:02
olofTry to add something like this to orpsoc-cores/cores/rtl/verilog/wb_ram_generic.v16:04
olof   integer  i;16:04
olof   initial for (i=0;i< depth;i=i+1) mem[i] = 32'd0;16:04
olofNot tested16:04
olofah no wait16:04
olofPut the for loop on the line before if(memfile != "") begin16:04
olofOtherwise there's no way to tell which initial statement that will be run first :)16:05
olofah no wait16:05
olofPut it after that line instead... I think16:05
olofFuck it. Not sure16:05
SMDhomeI'll try both, thanks16:06
SMDhomeIs there a key to gcc to init whole mem with zeroes or at least all uninit vars?16:08
olofSMDhome: I think you can do it somehow with the linker script16:20
olofAnother option would be to see if there is a switch to the sim (icarus?) to treat unitialized signals as 016:20
olofJust to check16:20
olofCan't find such an option though16:30
SMDhomeverilator has it16:31
olofSMDhome: Ah ok.16:34
olofVerilator also treats unitialized signals as 0 by default16:35
olofsince it has no concept of undefined or conflicting signals16:35
olofSMDhome: Somewhat unrelated, but if you're running a lot of simulations where you only make changes to the elf-file, you can run fusesoc sim --keep ... to avoid rebuilding the RTL simulation model every time17:03
olofEspecially for verilator that saves some time17:03
olofSMDhome: Running dhrystone in icarus now. Can't see that it fetches any unitialized data from RAM17:08
olofSpoke too soon :)17:08
olofhmm... or what's going on here17:10
olofIt actually seems to run ok17:11
olofGetting text on the uart at least17:11
olofIt's running a lot of tests at least17:14
olofSMDhome: I'm running fusesoc sim mor1kx-generic --elf-load=dhrystone_10.elf --timeout=50000017:44
olofAnd even though the simulator is aborted before dhrystone is finished, I see that it's starting at least, since it prints out stuff from the uart on the terminal17:45
olofhmm.. looking at the bug report again, maybe I should have run it longer17:58
-!- Netsplit *.net <-> *.split quits: imphil, eliask18:53
-!- Netsplit *.net <-> *.split quits: zama, blueCmd, fotis218:53
-!- zama_ is now known as zama19:00
SMDhomeolof, you get infinite loop, check insn trace diff. Dhrystone is finished and it hangs during result print23:36
SMDhomediff insn traces from the issue23:39
--- Log closed Tue May 24 00:00:20 2016

Generated by 2.15.2 by Marius Gedminas - find it at!