| --- Log opened Mon May 23 00:00:19 2016 | ||
| imphil | olof, the removal of top->v-> is part of the newest verilator release. there is a command line option to get back the old behavior | 04:38 |
|---|---|---|
| olof | imphil: Ah.. cool. Thanks | 04:54 |
| olof | I'll probably set the parameter then, to let people have some time to adjust | 04:54 |
| olof | For the existing systems at least | 04:54 |
| imphil | I guess the old verilator does not support the parameter; so you need to version-check at one point anyways | 04:55 |
| olof | Hmm.. true, but hopefully I just get a warning with older versions | 04:55 |
| imphil | it seems this is the first info i got out of reading planet librecores :) | 04:56 |
| olof | haha | 04:57 |
| shorne | Hello, sorry about all the disconnects earlier. My network was saturated and I wasn't around to stop it | 05:19 |
| bandvig | Hello! Does anybody know which latest Xilinx tool (WebPack license) supports SPARTAN-6 series? | 05:27 |
| bandvig | Hmm... it looks like ISE 14.7. | 05:45 |
| SMDwrk | bandvig: yep, it's ise14.7 | 05:47 |
| SMDwrk | I 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. http://imgur.com/pgxmCkc | 08:18 |
| stekern | SMDwrk: pro-tip, increase the hier to three or something, it makes it a lot easier to figure out what signals you're looking at | 08:30 |
| SMDwrk | stekern: you mean like this http://imgur.com/s1EXPFc | 08:35 |
| stekern | no, there is a setting somewhere called "Set max hier" or something like that | 08:36 |
| stekern | it will give the "path" to the signal names | 08:36 |
| SMDwrk | http://imgur.com/LKR4Sk1 but now signals are hardly visible( | 08:37 |
| stekern | ah, but you don't need to show *that* much of the path ;) | 08:38 |
| SMDwrk | I 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 sure | 08:38 |
| stekern | well, there can be 'x'es for uninitialized memories etc | 08:39 |
| SMDwrk | http://imgur.com/vpBDD09 that's what you asked for, I guess | 08:39 |
| SMDwrk | There could be, yes, but not after running 1M cycles I think | 08:40 |
| stekern | yes, that's good | 08:40 |
| stekern | well, if only one byte has been ever written to in that position in the cacheline, it can happen | 08:43 |
| stekern | because, it's a read-modify-write with byteselect | 08:44 |
| SMDwrk | stekern: http://imgur.com/fiDSMDY and here starts the problem | 08:49 |
| SMDwrk | that cache entry with 0x63b address seems wrong to me | 08:50 |
| SMDwrk | I wish I could search across .vcd somehow | 08:51 |
| stekern | for values? you can do that | 08:55 |
| SMDwrk | Yep, just googled that, thanks | 08:57 |
| olof | SMDwrk: Did you turn on the option to clear the register files? | 08:59 |
| SMDwrk | olof, yep, but no difference | 09:02 |
| olof | SMDwrk: Ah ok. It was worth a shot | 09:05 |
| stekern | SMDwrk: 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 wrong | 09:18 |
| SMDwrk | stekern: can you tell in which cases "x" are ok? | 09:22 |
| ZipCPU | On opencores, someone writes that they cannot generate "orpsoc.ngc". That they get make errors. Does anyone know about this? | 09:48 |
| SMDwrk | From where mor1kx_lsu_cappuccino.dbus_dat_i comes? Seems somewhere from outside of cpu: http://imgur.com/EMu8NM7 | 10:35 |
| SMDwrk | oh, it goes to ram I guess | 10:46 |
| SMDwrk | The question is why we fail to read something from ram: http://imgur.com/LOPfHkU | 11:01 |
| SMDwrk | I 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 |
| SMDwrk | olof, do you know if I can somehow initialize ram with zeroes using fusesoc? | 13:29 |
| olof | SMDwrk: 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 me | 15:54 |
| SMDhome | olof At least I'd like to try it and see if it helps | 15:55 |
| olof | SMDhome: Yeah, that's probably a good idea | 16:02 |
| olof | Try to add something like this to orpsoc-cores/cores/rtl/verilog/wb_ram_generic.v | 16:04 |
| olof | integer i; | 16:04 |
| olof | initial for (i=0;i< depth;i=i+1) mem[i] = 32'd0; | 16:04 |
| olof | Not tested | 16:04 |
| olof | ah no wait | 16:04 |
| olof | Put the for loop on the line before if(memfile != "") begin | 16:04 |
| olof | Otherwise there's no way to tell which initial statement that will be run first :) | 16:05 |
| olof | ah no wait | 16:05 |
| olof | Put it after that line instead... I think | 16:05 |
| olof | Fuck it. Not sure | 16:05 |
| SMDhome | I'll try both, thanks | 16:06 |
| SMDhome | Is there a key to gcc to init whole mem with zeroes or at least all uninit vars? | 16:08 |
| olof | SMDhome: I think you can do it somehow with the linker script | 16:20 |
| olof | Another option would be to see if there is a switch to the sim (icarus?) to treat unitialized signals as 0 | 16:20 |
| olof | Just to check | 16:20 |
| olof | Can't find such an option though | 16:30 |
| SMDhome | verilator has it | 16:31 |
| olof | SMDhome: Ah ok. | 16:34 |
| olof | Verilator also treats unitialized signals as 0 by default | 16:35 |
| olof | since it has no concept of undefined or conflicting signals | 16:35 |
| olof | gtg | 16:35 |
| olof | SMDhome: 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 time | 17:03 |
| olof | Especially for verilator that saves some time | 17:03 |
| olof | SMDhome: Running dhrystone in icarus now. Can't see that it fetches any unitialized data from RAM | 17:08 |
| olof | Spoke too soon :) | 17:08 |
| olof | hmm... or what's going on here | 17:10 |
| olof | It actually seems to run ok | 17:11 |
| olof | Getting text on the uart at least | 17:11 |
| olof | It's running a lot of tests at least | 17:14 |
| olof | SMDhome: I'm running fusesoc sim mor1kx-generic --elf-load=dhrystone_10.elf --timeout=500000 | 17:44 |
| olof | And 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 terminal | 17:45 |
| olof | hmm.. looking at the bug report again, maybe I should have run it longer | 17:58 |
| -!- Netsplit *.net <-> *.split quits: imphil, eliask | 18:53 | |
| -!- Netsplit *.net <-> *.split quits: zama, blueCmd, fotis2 | 18:53 | |
| -!- zama_ is now known as zama | 19:00 | |
| SMDhome | olof, you get infinite loop, check insn trace diff. Dhrystone is finished and it hangs during result print | 23:36 |
| SMDhome | diff insn traces from the issue | 23:39 |
| --- Log closed Tue May 24 00:00:20 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!