IRC logs for #openrisc Tuesday, 2015-11-10

--- Log opened Tue Nov 10 00:00:03 2015
olofkandrzejr_: For wb_intercon I think I'll prefer the generator approach. I added support for named sections i FuseSoC a few days ago. This was one of the blockers for the generator infrastructure08:12
olofkMy main reason for this is that I don't want to push any core-specific code directly into FuseSoC08:13
olofkI pushed a fix to the Atlys board to increase the boot ROM size and move it to 0xf0000000. Would be great if someone with an Atlys board could confirm that it's still working08:17
andrzejrolofk, if you've got generator API working we should use that for coregen as well. I used provider API because that was the only thing that did the job09:40
olofkandrzejr: I'm not sure that we should use the generator API (when it comes available) for coregen actually.09:46
olofkor maybe, but have it built into FuseSoC09:46
GeneralStupidolofk: i think that approach is really good. And isn't it the 'same' approach that tensilica and competitors are using?09:48
GeneralStupidolofk: i would like to do add some stuff to fusesoc for generating custom instructions and regenerate the wb_intercon in existing projects...09:48
GeneralStupidolofk: at the moment fusesoc is great to get a working core but after the fetch process you are pretty much on your own (i felt like that)09:49
olofkGeneralStupid: I don't know how Tensilica does things, but I've been planning to add this damn generator API for like three years now :)10:00
olofkWell, you can already do some things with the scripts support10:00
olofkYou should be able to add a script that regenerates wb_intercon for you10:00
GeneralStupidolofk: ive done this for my project10:02
GeneralStupidolofk: i need to finish my report and after that i will add the de2 support... And then i want to play with profiling and custom instructions10:03
GeneralStupidCI makes no sense without good profiling10:03
olofkCool. I like profiling10:04
GeneralStupidolofk: you have to try that tensilica stuff just once...10:04
GeneralStupidolofk: i think its not *that much10:05
GeneralStupidbetter then openrisc is10:05
GeneralStupidBut the toolchain, the profiling, the integration... its really nice10:05
olofkI've been thinking of doing a VPI module to hook up to mor1kx_monitor, so I can save the instruction trace to a database for offline viewing10:05
GeneralStupidwhat is vpi?10:06
olofkThe verilog mechanism for calling C functions10:06
olofkWe're using that for the elf-loader and jtag_vpi10:07
olofkand some other stuff10:07
GeneralStupidolofk: instruction trace is what tensilica gives you... for example, i tooked the smallest "CPU" first, i profiled and saw that there is a lot of div32. So i added div32 and saved a lot of cycles...10:07
GeneralStupidolofk: so for simulation?10:08
olofkAre you talking about profiling on real hw?10:08
GeneralStupidis there a more generic way? Which would work in simulation and emulation?10:08
olofkwallento may have something10:09
GeneralStupidolofk: for the tensilica case iam talking about simulated profiling10:09
olofkWe got that for OpenRISC already with the mor1kx monitor10:09
GeneralStupidnice nice , but the development time grows because of the emulation, right?10:10
wallentowallento has something, but only the pure execution tracing, no real tooling around it10:10
GeneralStupidis it ok if i tell you, that i hate verilog ?! :-D10:10
GeneralStupidwallento: :( Tooling makes that stuff less painfull :)10:10
wallentoyeah, I know10:10
olofkTry fusesoc sim mor1kx-generic --elf-load=/path/to/elffile --trace_enable10:11
wallentowhats your email?10:11
olofkand --trace_to_screen to get it printed to the terminal10:11
GeneralStupidwallento: pe@perdmann.de10:11
wallentogreat, I will send you a quick summary10:11
GeneralStupidolofk: i dont have iverilog10:14
GeneralStupidolofk: and it is a problem for me, that i cant mix vhdl and verilog10:14
GeneralStupidolofk: thanks, i need to cook something now :) i will write that in my report.10:16
GeneralStupidwe are designing ASIPs  and tensilica is often not that good... But profiling and custom instructions are really necessary :)10:17
olofkGeneralStupid: VHDL got VHPI now with VHDL2008, so you could probably reuse some of the VPI stuff by writing a VHPI wrapper instead10:23
_franck__GeneralStupid: you can do hardware profiling with openocd10:31
_franck__it is not much accurate because it does polling on program counter but if you run it long enough it can be representative enough10:32
olofkandrzejr: I'll wait a bit wih the coregen provider patches, in case we want to do this as a generator instead12:09
GeneralStupid_franck__: so profiling with the simulator is better?12:16
GeneralStupidolofk: 'write a wrapper' sounds easy :-D12:16
olofkWhat the hell? xsim doesn't support $clog2 either?12:20
olofkandrzejr: Might need to rewrite the xsim support to use tcl files instead if I can't find a way to turn on systemverilog12:32
_franck__GeneralStupid: I don't know if it's better but it might be faster12:34
GeneralStupid_franck__: faster, of course. I think its more practically12:34
_franck__sorry when I said faster I meant in hardware12:35
GeneralStupid_franck__: i meant the development speed...12:37
olofkandrzejr: Found it now. Need to use "sv work <file>" instead of "verilog work <file>"13:17
olofkNeed to add some option to indicate if the core needs sv support13:17
olofkUnfortunately all testbenches I try fail with xsim :(13:22
olofkYou got to be kidding me. xsim is also getting $clog2 wrong13:45
olofk$clog2(4) == 2 in Icarus and modelsim, but 3 in xsim13:46
stekernof course it has to be wrong to not cause simulation/synthesis mismatches ;)13:48
wallentoI think this is why we added this file:
stekernyeah, we have a similar file in orpsoc-cores:
olofkstekern added something similar some years ago13:51
olofkThat was for ISE 13.something that implemented $clog2 as base e or base 1013:51
olofkUnfortunately icarus doesn't handle static functions, so we had to make a workaround13:52
olofkAnd I removed this over a year ago since I though no one would be running that ancient ISE version anymore13:52
olofkBut they actually managed to reintroduce the bug in Vivado it seems13:52
olofkDoes anyone have Vivado later than 2014.4 who can test $clog214:10
olofkmodule clog2_tb; //Should be 2 initial $display("%d", $clog2(4)); endmodule14:10
olofkA newline after "Should be 2" of course14:12
wallentowait a sec14:26
wallentoolofk: yes, its 214:35
wallentoin vivado 2015.214:35
olofkwallento: Ah ok. Thanks. Couldn't find anything in the release notes15:11
olofkwallento: Did you test $clog2 with simulation or synthesis? 2014.4 gets it right for synthesis15:31
wallentoshould I check synthesis also?15:32
olofkNo need.15:33
andrzejrolofk, the ddr2 core generated by coregen has both isim and xsim testbenches working (as generated by coregen)17:35
olofkstekern: Shouldn't the `endif be at the bottom of the file in verilog_utils.vh?17:44
olofkHmm.. can't figure out how these header definitions should be used. Getting duplicate definitions or undefined functions17:50
olofkok, it works now17:52
olofkLooks like it's still too early to use bleeding-edge features like $clog2 :(17:53
olofkBut at least xsim support works fine. Still need to figure out how to handle the verilog/systemverilog case17:54
olofkRight now I'm leaning towards adding an option to the verilog section to set the default language revision to use17:55
olofkIn the long run I think we might need per-file overrides, but that's not an issue for now17:55
andrzejrhow about having different sections for source files (verilog, system verilog, vhdl etc)18:07
olofkandrzejr: VHDL and verilog already have different sections, although the vhdl support is really minimal18:13
olofkBut when I add more IP-Xact support, I think it would make sense instead to define filesets18:14
olofkAnd have some defaults per fileset18:14
olofkSo that for synthesis we use fileset1, for icarus we use fileset1+fileset2+fileset3 and for modelsim we use fileset1+fileset2+fileset418:15
olofkSo my future plans clash a bit with the current vhdl/verilog sections. Therefore I'm hesitating towards adding a systemverilog section as well18:16
-!- rhythmx_ is now known as rhythmx18:19
olofkOh... I forgot that I actually already implemented part of the filesets stuff in a branch :)18:19
olofkAhh.. and with the fancy new named sections, we could define filesets in the core files. This changes EVERYTHING!18:20
olofkJust need to leave my family and quit my job18:21
andrzejrolofk, just an observation - many problems with core files are nicely solved by splitting the core into multiple parts.19:47
andrzejrI've done that with all generated ones by separating out any wrappers etc. no need for extra sections, sequencing etc19:50
andrzejrthings get simpler and you can keep your family and job! :-)19:53
olofkandrzejr_: haha. :)20:57
olofkAnd I agree. No need to make things overly complicated if they can be solved with multiple cores20:57
olofkFor example, it might be a lot easier to just allow a single VHDL library per core20:58
olofkAnd I think that you can only have one VPI library per core as well20:59
GeneralStupidolofk: is the multicore implementation in mor1kx from the TU munich?20:59
olofkGeneralStupid: wallento (from TU Munich) and stekern probably worked most on that. Not sure who did what21:00
GeneralStupidolofk: thanks21:15
olofkAlright! Got Clifford Wolf's picorv32 core running under RTL sims and verilator22:45
olofkBut elf-loader could really use a endian selector. Had to hack read_32 for now22:48
olofkAnd I refactored the verilator support in FuseSoC too. It was a complete mess22:50
olofkNot sure I got everything right though :)22:50
GeneralStupidwhats about amber?23:45
--- Log closed Wed Nov 11 00:00:04 2015

Generated by 2.15.2 by Marius Gedminas - find it at!