| --- Log opened Wed Mar 19 00:00:27 2014 | ||
| trsohmers | Greetings | 06:30 |
|---|---|---|
| stekern | ah... there is this source_type variable, that can be C or systemC | 07:58 |
| stekern | why does all those extra args for systemC need to be hardcoded in sections.py? | 07:59 |
| stekern | to me it feels like a more generic build_CPP that would be feed those args from a higher level would be more appropriate | 08:00 |
| stekern | perhaps a first step towards that is to add a build_CPP and make build_SysC a superset of that | 08:01 |
| olofk | stekern: Yes, you're right. I wanted to get the systemC stuff integrated and figured that we could clean it up later | 08:06 |
| olofk | So I say that we want to have a switch that tells verilator to use --cc or --sc | 08:06 |
| olofk | And then we want to be able to compile C and C++ filer | 08:07 |
| stekern | fair enough, just trying to get my head around how to get my "plain" c++ to compile in a sane way | 08:07 |
| olofk | s/filer/files | 08:07 |
| stekern | then there's of course the interesting situation where you have a core with mixed c and c++ files... | 08:22 |
| stekern | can you have several [verilator] sections? | 08:22 |
| stekern | ...and.. it's a bit confusing that it's src_files, but source_type | 08:25 |
| _franck_web_ | I think several [verilator] sections could work | 08:30 |
| _franck_web_ | I agree source_type must be changed to src_type | 08:31 |
| stekern | now when I added a CPP builder, my files aren't copied into build/yadayada/src/my_core/ | 08:32 |
| stekern | any idea why that might be? | 08:32 |
| olofk | Several sections with the same name is illegal in ini files | 08:35 |
| olofk | There is however another way that I have been investigating for both plusargs and VHDL | 08:35 |
| olofk | It is to name the section [plusarg timeout], or [vhdl name_of_vhdl_lib]. It's easy to extend the support in core.py to handle that | 08:36 |
| olofk | For plusargs it would be a much cleaner solution. I already have a local branch for that | 08:36 |
| olofk | Hmm.. what do you want several [verilator] sections for anyway? | 08:37 |
| stekern | I don't necessarily want it, just thinking about ways to handle the mixed c and c++ case | 08:37 |
| olofk | I'm wondering if we could find some inspiration in autotools makefiles or cmake. They must have come across the same situation | 08:39 |
| olofk | Maybe suffix detection is the easiest way after all | 08:39 |
| stekern | ...or fall back to the suggestion I had yesterday: c_src_files, cpp_src_files, sysc_src_files | 08:40 |
| stekern | that's how you usually do it in Makefiles | 08:40 |
| olofk | Would 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++ file | 08:42 |
| olofk | Maybe that's not a problem | 08:42 |
| stekern | even if it's a problem, the current solution doesn't solve it | 08:43 |
| stekern | and you can even have that problem with c only files | 08: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 |
| stekern | olofk: where are the core files copied into build/yadayada/src/mycore? | 08:48 |
| stekern | hmm, this seems to be unrelated to my c++ builder | 08:51 |
| stekern | oh, ok. it doesn't copy them without a [vpi] section | 08:53 |
| stekern | that 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 updates | 09:07 |
| _franck_web_ | cores files are copied by .export() method | 09:08 |
| stekern | _franck_web_: yes, it worked in your (old) verilator branch | 09:08 |
| stekern | that's why I thought it was related to my cpp change, since I switched branch when I started to work on that | 09:09 |
| _franck_web_ | as olofk said that would be great have a testsuite in place | 09:10 |
| _franck_web_ | stekern: https://github.com/fjullien/fusesoc/commit/081cf6ce1313b41eca742d44845724c9b03e596c#diff-7629af326efaa4b729fcabeb069f6ed5R124 | 09:24 |
| _franck_web_ | I think this is the answer to the export problem | 09:24 |
| stekern | ok | 09:37 |
| stekern | next problem; how do I use elf-loader in another core? | 10:29 |
| _franck_web_ | what do you mean ? | 10:31 |
| stekern | I want to use elf-loader, but not in tb.cpp | 10:31 |
| stekern | in a seperate core, called verilog_tb_utils | 10:32 |
| stekern | how does my verilog_tb_utils find elf-loader.h? | 10:32 |
| stekern | s/verilog_tb_utils/verilator_tb_utils | 10:32 |
| _franck_web_ | if verilator_tb_utils depends on elf-loader it doesn't work ? | 10:33 |
| stekern | nope | 10:34 |
| _franck_web_ | something to do with export() you should try the patch I showed you | 10:37 |
| _franck_web_ | for now, verilator.py only take care of the system core file | 10:37 |
| stekern | what patch? | 10:38 |
| _franck_web_ | https://github.com/fjullien/fusesoc/commit/081cf6ce1313b41eca742d44845724c9b03e596c | 10:38 |
| stekern | isn't that already applied? | 10:39 |
| _franck_web_ | I don't think so | 10:40 |
| stekern | ah, ok, I thought you meant that that created the problem | 10:41 |
| stekern | does that apply cleanly= | 10:42 |
| stekern | ? | 10:42 |
| _franck_web_ | not sure, I haven't rebase it | 10:43 |
| stekern | it doesn't | 10:45 |
| stekern | would it make sense to just add build/yadayada/src to -I | 10:48 |
| _franck_web_ | in ...../src/ you will have subdirs too | 10:48 |
| stekern | and 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 not | 10:49 |
| stekern | that has the advantage that you see the relation to from where the file is included | 10:51 |
| stekern | as well | 10:51 |
| stekern | and you avoid .h filename clashes | 10:52 |
| _franck_web_ | we now have 3 good reasons :) | 10:53 |
| stekern | ain't that the lucky number? =) | 11:00 |
| stekern | now it's broken... | 11:36 |
| stekern | About | 11:36 |
| stekern | bah... | 11:36 |
| stekern | http://pastie.org/8950230 | 11:36 |
| stekern | why do I have -lelf twice on the first row? | 11:37 |
| stekern | s/row/line | 11:37 |
| stekern | not that it works better with one | 11:44 |
| stekern | hmm, it's the start-end-group that is messing with it | 11:45 |
| stekern | -lelf have to be outside of it, and the .a's have to be inside | 11:45 |
| stekern | taking care of a sick kid makes wonder for open source productivity... | 11:46 |
| stekern | next problem; how do I include verilator include files into a sub-core? | 11:51 |
| stekern | I'm speaking about global verilator files, like verilated_vcd_c.h | 11:52 |
| stekern | not generated .h files | 11:52 |
| ams | one should replace all files with generated files, then one doesn't have to write code. | 11:52 |
| stekern | =) | 11:55 |
| stekern | true, as long as you have a generated generator | 11:56 |
| ams | stekern: what do they pay you to do? | 12:00 |
| ams | write code?! | 12:00 |
| stekern | can you get paid to do that? unpossible! | 12:06 |
| stekern | olofk: this is how my tb.cpp looks like after pushing away everything else to the utils core: http://pastie.org/8950827 | 15:56 |
| _franck_web_ | stekern: so nice ! | 15:57 |
| olofk_ | stekern: That's a nice tb.cpp. Just what I was looking for | 17:54 |
| stekern | now 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 |
| stekern | nah, it's not _that_ bad, but it'll be nicer | 17:57 |
| stekern | I haven't touched the arg parsing yet | 17:57 |
| stekern | http://pastie.org/8951237 | 17:59 |
| stekern | but 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 way | 18:00 |
| stekern | this is one of the headaches: https://github.com/olofk/fusesoc/blob/master/fusesoc/sections.py#L138 | 18:03 |
| stekern | how to figure that out if VERILATOR_ROOT isn't set | 18:03 |
| olofk_ | stekern: Whoops... that was a bit quick and dirty | 18:04 |
| stekern | right now I just do: http://pastie.org/8951247 | 18:04 |
| stekern | i.e. fall back to the default install path | 18:05 |
| stekern | it's close to a sane thing to do, and better thab nothing | 18:05 |
| stekern | but not really good still... | 18:05 |
| olofk_ | We should really use the detection from verilator.py | 18:12 |
| stekern | yes | 18:14 |
| stekern | it's annoying that it can't just print that out for us | 18:14 |
| stekern | like: verilator --print-verilator-root | 18:15 |
| stekern | the detection in verilator.py doesn't work out of the box though | 18:16 |
| stekern | because VERILATOR_ROOT and the place where the verilator "binary" isn't necessarily the same | 18:17 |
| stekern | in an installed environment, VERILATOR_ROOT is "/usr/local/share/verilator" | 18:17 |
| stekern | but the binary is in /usr/local/bin/verilator | 18:18 |
| stekern | using argp made the arg parsing more clean (and less error prone): http://pastie.org/8951799 | 21:51 |
| stekern | and this is the help output: http://pastie.org/8951808 | 21:52 |
| ams | argp rocks | 22:14 |
| ams | though .. <file> ... you should just use FILE which is the common way to detonate parameters to arguments | 22:15 |
| stekern | yeah, I know | 22:16 |
| stekern | but I just copied that from the old code | 22:16 |
| blueCmd | so. can I autogenerate wb_intercon? | 22:34 |
| stekern | yes | 22:34 |
| blueCmd | good. that would have sucked | 22:35 |
| stekern | cores/wb_intercon/sw/wb_intercon_gen /path/to/wb_intercon.conf /path/to/wb_intercon.v | 22:36 |
| blueCmd | sweet | 22:36 |
| blueCmd | vivado is pretty retarded when it comes to naming stuff | 22:37 |
| stekern | at some point that should be automatically done by the builders methinks | 22:37 |
| blueCmd | the standard project dumps files in 'project.srcs/sources_1/new/filehere.v' | 22:37 |
| blueCmd | all new 'runs' have sensible names but has an _1 which anoys me to no end | 22:38 |
| blueCmd | impl_1, synth_1, sources_1, constr_1 ... | 22:38 |
| stekern | I haven't touched vivado yet | 22:38 |
| blueCmd | yeah, that was my plan but they have stopped releasing new IP Cores to ISE AFAIK | 22:40 |
| blueCmd | AFAICT* | 22:40 |
| --- Log closed Thu Mar 20 00:00:28 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!