--- Log opened Fri Feb 21 00:00:49 2014 | ||
wkoszek | juliusb_: What do you do these days? | 00:11 |
---|---|---|
wkoszek | juliusb_: Still same $JOB ? | 00:11 |
-!- Netsplit *.net <-> *.split quits: _franck_, bentley`, heroux, rah_, jeremybennett | 00:55 | |
-!- heroux_ is now known as heroux | 00:56 | |
-!- hno` is now known as hno | 02:32 | |
olofk_ | maxpaln: $clog2 should be a vlog2001 feature. | 09:27 |
maxpaln | interesting - it only becomes available in Active-HDL once I turn on the -sv2k5 option. In any case, I got it working now! | 09:42 |
maxpaln | well, I got the design compiling - I ran out of time last night to run any simulations. I couldn't spend any time on this last week at all | 09:43 |
olofk_ | maxpaln: Looks like you're right. Hmm.. it was never my intention to depend on sv2k5 features, but at least it seems to be supported in all the simulators I have tried so far | 11:14 |
olofk_ | The sad part of RTL design is that you are considered bleeding edge if you use features from a seven year old standard | 11:15 |
-!- stekern_ is now known as stekern | 12:17 | |
stekern | olofk_: I'm about to take the verilator features of the fusesoc formerly known as orpsoc | 12:17 |
stekern | out for a ride | 12:17 |
stekern | is there anything I should be aware of? | 12:18 |
stekern | I don't have verilator nor any systemc installed on this machine (and I rather avoid installing systemc on it) | 12:18 |
olofk_ | stekern: You can't use system-installed verilator yet, so don't run make install and use VERILATOR_ROOT to point out the verilator dir instead | 12:29 |
olofk_ | There's a very basic non-systemc test bench for verilator in or1200-generic. It supports loading elf files with --or1k-elf-load <your_elf_file>, and dumps a VCD (unconditonally? Not really sure) | 12:31 |
stekern | olofk_: umm... I had hoped to use an 'apt-get install verilator' verilator | 12:32 |
stekern | that won't work? (and what's the issue?) | 12:33 |
olofk_ | That won't work. The issue is that I used a non-installed verilator and didn't know about the problem until _franck__ told me. The fix is easy. First try to run verilator directly. If that fails, check if VERILATOR_ROOT is set and then run $VERILATOR_ROOT/bin/verilator, else fail | 12:36 |
olofk_ | quick fix: Remove the check on line 34 in verilator.py. change line 106 to cmd = 'verilator' | 12:38 |
olofk_ | That should do it until it is fixed properly (I think) | 12:38 |
_franck_web_ | AFAIR, it's not that easy | 12:38 |
_franck_web_ | $VERILATOR_ROOT should point to /usr/bla/bla/verilator/bla/include or something | 12:39 |
stekern | ah, well, easy or not.. I'll forge on and fix it, I'm not up for manually installing verilator | 12:41 |
_franck_web_ | that would be great if you fix this | 12:41 |
olofk_ | _franck_web_: If it's installed properly, I think that verilator itself sets VERILATOR_ROOT | 12:42 |
_franck_web_ | olofk_: when are you going to rename openrisc/orpsoc to openrisc/fusesoc on github ? | 12:42 |
stekern | but first, how am I supposed to start the non-systemc test bench for or1200-generic? | 12:42 |
olofk_ | _franck_web_: I have done most of it in my local repo, so I'll push it this weekend | 12:42 |
_franck_web_ | great | 12:42 |
olofk_ | stekern: orpsoc sim --sim=verilator or1200-generic --or1k-elf-load conficker.elf | 12:43 |
stekern | is the elf-loader or1k specific? | 12:43 |
olofk_ | stekern: Or rather orpsoc sim --force --sim=verilator or1200-generic --or1k-elf-load conficker.elf | 12:43 |
olofk_ | I don | 12:43 |
stekern | me stekern | 12:44 |
olofk_ | I don't think so now that it's using libelf | 12:44 |
olofk_ | lol | 12:44 |
olofk_ | It was or1k-specific before | 12:44 |
stekern | ok, another thing I'll test (and at least fix the name if it's not) | 12:44 |
olofk_ | Yeah. It's cool if it's cpu-agnostic. I want to test lm32 with fusesoc | 12:45 |
stekern | I'm on day two on hacking up a pipelined eco32 version, trying to make it in a week ;) | 12:47 |
stekern | got most of fetch, decode, alu and mmu done already | 12:47 |
olofk_ | c00l | 12:49 |
olofk_ | How big is the eco32 scene? | 12:51 |
stekern | small | 12:51 |
olofk_ | Anyone else but you? | 12:51 |
stekern | it's mostly used by a german university | 12:51 |
stekern | as an education tool | 12:51 |
olofk_ | I did some quick googling just now, and got mostly german links | 12:52 |
stekern | I've got some changes for cappuccino, that I'm testing in this implementation | 12:53 |
olofk_ | Just noticed the eco32 project on OpenCores. That's very new | 13:00 |
stekern | yes, Hellwig Geisse, the project founder just created it | 13:01 |
olofk_ | But this page http://homepages.thm.de/~hg53/eco32/ makes it look a lot older | 13:01 |
olofk_ | It's not using any standard bus interface, right? | 13:02 |
stekern | ah, yes, it's been around for many years. I think I heard about it for the first time around 2010 or so | 13:02 |
stekern | not the implementation they have, no | 13:02 |
stekern | mine is wb | 13:03 |
olofk_ | wb makes it a bit more useful | 13:04 |
stekern | they have their own reference soc, with serial port, vga console, timer, ide and keyboard cores | 13:05 |
stekern | Error: Failed to checkout http://opencores.org/ocsvn/openrisc/openrisc/trunk/or1200 | 13:07 |
olofk_ | hmm... that wasn't very helpful | 13:12 |
stekern | ah, pesky dependcy on svn is not fulfilled on this machine ;) | 13:12 |
olofk_ | :) | 13:12 |
olofk_ | That will work out automatically as soon as rel3 of or1200 is done or we switch to mor1kx that has awesome release cycles | 13:13 |
olofk_ | So that we can have release tar balls instead of fetching stuff from repos | 13:14 |
stekern | the full error message wasn't much more helpful: http://pastie.org/8755455 | 13:14 |
olofk_ | oops | 13:19 |
olofk_ | Line 58 in opencores.py should probably be print(e) | 13:20 |
olofk_ | That's the problem with those damn lazy evaluation languages. Some code paths are executed so seldom that bugs can go unnoticed for months | 13:21 |
olofk_ | Oh well. All that will be fixed in fusesoc 1.1 | 13:22 |
stekern | That's going to be completely free from bugs, I reckon | 13:27 |
olofk_ | Yes of course. All the test cases will pass | 13:29 |
stekern | her's another: http://pastie.org/8755523 | 13:35 |
stekern | +e | 13:35 |
_franck_web_ | oh yeah I had that one | 13:42 |
stekern | hmmm, the problem is that input.vc is in build/or1200-generic/sim-verilator | 13:42 |
_franck_web_ | self.stderr is a file object, so replace with self.stderr.name | 13:43 |
stekern | ok, yeah, that fixes the error msg | 13:47 |
stekern | http://pastie.org/8755581 | 13:56 |
stekern | hacks to make it run | 13:56 |
stekern | there are errors in wb_intercon though... | 13:56 |
stekern | but why do I need to add the full path to the files? | 13:58 |
stekern | or more to the point, why hasn't it been needed? | 13:59 |
stekern | olofk_: it doesn't like this master/slave_sel_int business in wb_arbiter and wb_mu | 14:10 |
stekern | x | 14:10 |
stekern | wasn't that odd construct in there put there to work-around some issue? | 14:10 |
olofk_ | full path to the files is really awkward. The reason is that I cd to another dir before starting the sim. I did that because the EDA tools are messy and pollute cwd with a lot of files | 14:14 |
olofk_ | For icarus/modelsim I do a little hack so you can specify relative paths and they will be presented as an absolute path to the simulator | 14:15 |
olofk_ | stekern: Which version of verilator are you using? | 14:15 |
stekern | some old from 2012, it's what I got when I apt-get it here | 14:16 |
stekern | trying with a more recent now | 14:16 |
stekern | but why does the cd fail for me then? | 14:16 |
olofk_ | cd fails? Not following you here | 14:19 |
stekern | "The reason is that I cd to another dir before starting the sim." | 14:20 |
stekern | or do you mean manually? | 14:20 |
olofk_ | No, orpsoc runs the simulation from build/<system_name>/sim-<sim_name> | 14:20 |
olofk_ | So the paths will be relative to that dir | 14:21 |
stekern | ok, so the million-dollar question is: why doesn't verilator find the files with relative names then? | 14:21 |
stekern | (here) | 14:21 |
olofk_ | You mean the elf file? | 14:22 |
stekern | no, the input.vc and tb.cpp files | 14:22 |
olofk_ | aha | 14:22 |
stekern | the ones I add the full path to in my 'patch' =) | 14:22 |
olofk_ | Did you clean out the build dir before rebuilding? | 14:22 |
stekern | rm -rf build, yes | 14:23 |
olofk_ | ok... that's fucking weird | 14:24 |
olofk_ | That works so much better in fusesoc ;) | 14:24 |
stekern | ;) | 14:24 |
olofk_ | hmm... | 14:24 |
olofk_ | ahh.. | 14:24 |
stekern | building verilator on this slomo machine is no fun... | 14:24 |
olofk_ | Maybe it has to do with src_type | 14:25 |
stekern | I really need to get a new laptop | 14:25 |
olofk_ | I can | 14:27 |
olofk_ | I can't figure out what's going wrong here | 14:27 |
olofk_ | How did you fiure out that tb.cpp and input.vc weren't found? | 14:28 |
stekern | I've just been waiting for the laptop industry to realise that they should be able to make displays >= 1680x1050 at decent prices | 14:31 |
stekern | verilator said 'me cannot find'em' | 14:31 |
stekern | oh... no, my bad | 14:32 |
stekern | I just realised what happened, I ran the verilator command manually since orpsoc didn't give me the error | 14:33 |
stekern | doh... | 14:33 |
stekern | sorry about wasting your time on that.. | 14:34 |
stekern | and verilator-3.855 doesn't choke on wb_intercon | 14:43 |
stekern | _franck_web_: have you used the libelf loader with verilator? | 15:10 |
_franck_web_ | I think so | 15:10 |
stekern | how? =) | 15:14 |
_franck_web_ | wait :) | 15:16 |
_franck_web_ | unfortunately, it's not on this computer | 15:17 |
_franck_web_ | but I think it needs patches to orpsoc | 15:17 |
stekern | at least or1200-generic have a local version of the or1k-elf-loader that uses or1k-elf-objdump | 15:18 |
stekern | hmm, how do I get verilator to link with libelf | 15:29 |
_franck_web_ | https://github.com/fjullien/orpsoc/blob/verilator/orpsoc/simulator/verilator.py | 15:30 |
_franck_web_ | -LDFLAGS | 15:31 |
stekern | ok, yes | 15:32 |
stekern | hmm, it's still whining about undefined references to various elf_xxxx functions | 15:35 |
_franck_web_ | do you have libelf-devel ? | 15:41 |
stekern | yes, but it seems like the -LDFLAGS put the -lelf to early on the command line | 15:42 |
_franck_web_ | your errors are not coming from verilator but from gcc right ? | 15:48 |
_franck_web_ | https://github.com/fjullien/orpsoc/blob/verilator/orpsoc/simulator/verilator.py#L40 | 15:48 |
stekern | no, it doesn't come from that | 15:50 |
stekern | it comes from when the final link is done | 15:50 |
stekern | http://pastie.org/8755872 | 15:51 |
stekern | the 'get_size' is a real missing reference, the others are just because -lelf is to early | 15:52 |
stekern | ok, got around that with the ugliest hack ever seen... | 16:33 |
_franck_web_ | please tell us :) | 16:39 |
stekern | _franck__: no, I didn't want to give you nightmares | 23:40 |
stekern | it involved removing the .o's from verilator.py and adding them before the -lelf after the -LDFLAGS in the .core file | 23:42 |
stekern | which probably is the necessary thing to do in the end (adding the .o files to -LDFLAGS and then add userlibs after that) | 23:43 |
stekern | but not how I did it now ;) | 23:43 |
--- Log closed Sat Feb 22 00:00:50 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!