IRC logs for #openrisc Wednesday, 2014-03-19

--- Log opened Wed Mar 19 00:00:27 2014
stekernah... there is this source_type variable, that can be C or systemC07:58
stekernwhy does all those extra args for systemC need to be hardcoded in
stekernto me it feels like a more generic build_CPP that would be feed those args from a higher level would be more appropriate08:00
stekernperhaps a first step towards that is to add a build_CPP and make build_SysC a superset of that08:01
olofkstekern: Yes, you're right. I wanted to get the systemC stuff integrated and figured that we could clean it up later08:06
olofkSo I say that we want to have a switch that tells verilator to use --cc or --sc08:06
olofkAnd then we want to be able to compile C and C++ filer08:07
stekernfair enough, just trying to get my head around how to get my "plain" c++ to compile in a sane way08:07
stekernthen there's of course the interesting situation where you have a core with mixed c and c++ files...08:22
stekerncan you have several [verilator] sections?08:22
stekern...and.. it's a bit confusing that it's src_files, but source_type08:25
_franck_web_I think several [verilator] sections could work08:30
_franck_web_I agree source_type must be changed to src_type08:31
stekernnow when I added a CPP builder, my files aren't copied into build/yadayada/src/my_core/08:32
stekernany idea why that might be?08:32
olofkSeveral sections with the same name is illegal in ini files08:35
olofkThere is however another way that I have been investigating for both plusargs and VHDL08:35
olofkIt is to name the section [plusarg timeout], or [vhdl name_of_vhdl_lib]. It's easy to extend the support in to handle that08:36
olofkFor plusargs it would be a much cleaner solution. I already have a local branch for that08:36
olofkHmm.. what do you want several [verilator] sections for anyway?08:37
stekernI don't necessarily want it, just thinking about ways to handle the mixed c and c++ case08:37
olofkI'm wondering if we could find some inspiration in autotools makefiles or cmake. They must have come across the same situation08:39
olofkMaybe suffix detection is the easiest way after all08:39
stekern...or fall back to the suggestion I had yesterday: c_src_files, cpp_src_files, sysc_src_files08:40
stekernthat's how you usually do it in Makefiles08:40
olofkWould there be any dependency problems with that? I'm thinking if a c++ file has a dependency on a c file that has another dependency on a c++ file08:42
olofkMaybe that's not a problem08:42
stekerneven if it's a problem, the current solution doesn't solve it08:43
stekernand you can even have that problem with c only files08:44
stekern...what I'm trying to say, it's a seperate problem, and it can be solved, but it doesn't have anything to do with mixing c and c++08:46
stekernolofk: where are the core files copied into build/yadayada/src/mycore?08:48
stekernhmm, this seems to be unrelated to my c++ builder08:51
stekernoh, ok. it doesn't copy them without a [vpi] section08:53
stekernthat seems a bit non-intentional, right? =)08:54
_franck_web_stekern: at some point I had this fixed. You should make all your tests without a vpi section. Because files are (were) exported from there. Didn't test since olofk updates09:07
_franck_web_cores files are copied by .export() method09:08
stekern_franck_web_: yes, it worked in your (old) verilator branch09:08
stekernthat's why I thought it was related to my cpp change, since I switched branch when I started to work on that09:09
_franck_web_as olofk said that would be great have a testsuite in place09:10
_franck_web_I think this is the answer to the export problem09:24
stekernnext problem; how do I use elf-loader in another core?10:29
_franck_web_what do you mean ?10:31
stekernI want to use elf-loader, but not in tb.cpp10:31
stekernin a seperate core, called verilog_tb_utils10:32
stekernhow does my verilog_tb_utils find elf-loader.h?10:32
_franck_web_if verilator_tb_utils depends on elf-loader it doesn't work ?10:33
_franck_web_something to do with export() you should try the patch I showed you10:37
_franck_web_for now, only take care of the system core file10:37
stekernwhat patch?10:38
stekernisn't that already applied?10:39
_franck_web_I don't think so10:40
stekernah, ok, I thought you meant that that created the problem10:41
stekerndoes that apply cleanly=10:42
_franck_web_not sure, I haven't rebase it10:43
stekernit doesn't10:45
stekernwould it make sense to just add build/yadayada/src to -I10:48
_franck_web_in ...../src/ you will have subdirs too10:48
stekernand then just let the cores that depend on things do #include <elf-loader/elf-loader.h>10:49
_franck_web_ok, I was too fast :)10:49
_franck_web_well, yes, why not10:49
stekernthat has the advantage that you see the relation to from where the file is included10:51
stekernas well10:51
stekernand you avoid .h filename clashes10:52
_franck_web_we now have 3 good reasons :)10:53
stekernain't that the lucky number? =)11:00
stekernnow it's broken...11:36
stekernwhy do I have -lelf twice on the first row?11:37
stekernnot that it works better with one11:44
stekernhmm, it's the start-end-group that is messing with it11:45
stekern-lelf have to be outside of it, and the .a's have to be inside11:45
stekerntaking care of a sick kid makes wonder for open source productivity...11:46
stekernnext problem; how do I include verilator include files into a sub-core?11:51
stekernI'm speaking about global verilator files, like verilated_vcd_c.h11:52
stekernnot generated .h files11:52
amsone should replace all files with generated files, then one doesn't have to write code.11:52
stekerntrue, as long as you have a generated generator11:56
amsstekern: what do they pay you to do?12:00
amswrite code?!12:00
stekerncan you get paid to do that? unpossible!12:06
stekernolofk: this is how my tb.cpp looks like after pushing away everything else to the utils core:
_franck_web_stekern: so nice !15:57
olofk_stekern: That's a nice tb.cpp. Just what I was looking for17:54
stekernnow I just have to figure out how to make the utils core look nice as well ;)17:55
olofk_stekern: Ah.. you cheated ;)17:56
stekernnah, it's not _that_ bad, but it'll be nicer17:57
stekernI haven't touched the arg parsing yet17:57
stekernbut that's the easy part, it'll be harder to figure out how to do the hacks I've done to fusesoc to get the system compiling in a nice way18:00
stekernthis is one of the headaches:
stekernhow to figure that out if VERILATOR_ROOT isn't set18:03
olofk_stekern: Whoops... that was a bit quick and dirty18:04
stekernright now I just do:
stekerni.e. fall back to the default install path18:05
stekernit's close to a sane thing to do, and better thab nothing18:05
stekernbut not really good still...18:05
olofk_We should really use the detection from verilator.py18:12
stekernit's annoying that it can't just print that out for us18:14
stekernlike: verilator --print-verilator-root18:15
stekernthe detection in doesn't work out of the box though18:16
stekernbecause VERILATOR_ROOT and the place where the verilator "binary" isn't necessarily the same18:17
stekernin an installed environment, VERILATOR_ROOT is "/usr/local/share/verilator"18:17
stekernbut the binary is in /usr/local/bin/verilator18:18
stekernusing argp made the arg parsing more clean (and less error prone):
stekernand this is the help output:
amsargp rocks22:14
amsthough .. <file> ... you should just use FILE which is the common way to detonate parameters to arguments22:15
stekernyeah, I know22:16
stekernbut I just copied that from the old code22:16
blueCmdso. can I autogenerate wb_intercon?22:34
blueCmdgood. that would have sucked22:35
stekerncores/wb_intercon/sw/wb_intercon_gen /path/to/wb_intercon.conf /path/to/wb_intercon.v22:36
blueCmdvivado is pretty retarded when it comes to naming stuff22:37
stekernat some point that should be automatically done by the builders methinks22:37
blueCmdthe standard project dumps files in 'project.srcs/sources_1/new/filehere.v'22:37
blueCmdall new 'runs' have sensible names but has an _1 which anoys me to no end22:38
blueCmdimpl_1, synth_1, sources_1, constr_1 ...22:38
stekernI haven't touched vivado yet22:38
blueCmdyeah, that was my plan but they have stopped releasing new IP Cores to ISE AFAIK22:40
--- Log closed Thu Mar 20 00:00:28 2014

Generated by 2.15.2 by Marius Gedminas - find it at!