IRC logs for #openrisc Sunday, 2014-05-04

--- Log opened Sun May 04 00:00:33 2014
mor1kx[mor1kx] skristiansson pushed 1 new commit to master:
mor1kxmor1kx/master aa77169 Stefan Kristiansson: add support for l.lwa/l.swa atomic instructions...06:16
blueCmdstekern: wooh, nice push09:45
stekernblueCmd: thanks =)09:46
stekernright now, I'm writing Changelog entries to or1ksim09:46
_franck_stekern: I made jtag_vpi to work with verilator (with the cpp testbench)11:17
stekern_franck_: nice! I did a pull request to fusesoc with some fixes so Jose's stuff works with it too11:19
_franck_I'll add support for it in mor1kx-generic11:19
stekerndid you add it to verilator_tb_utils?11:21
_franck_no, I added some files in my jtag_vpi repo (which is not vpi only anymore)11:21
_franck_see the pull request11:21
stekernah, I hadn't got the mail yet11:22
stekernI think that should be in verilator_tb_utils though11:23
stekerninstead of the changes you did to or1200-generic11:23
stekern'rsp' is already registered as a commandline argument there, is that the same as -j?11:24
_franck_it has the advantage to show what it does here11:24
_franck_I don't think we use 'rsp' anymore but I didn't wnat to use it for jtag_vpi since it's not an rsp server11:25
stekernah.. well, I think we can just remove the 'rsp' then and add the 'j' instead11:25
stekernit's not like rsp has been used anywhere, right?11:26
stekernmy point is, to add support to mor1kx-generic, you'd copy-paste the exact same code in there, right?11:26
_franck_not that I'm aware of11:26
stekernthat was the point of verilator_tb_utils, to avoid that11:27
_franck_you still need to hook-up jtag signals to your verilog_tb_utils jtag thing11:28
_franck_what I meant by "show what it does here" is that you can see the jtag client the tb.cpp file . It's not hidden in verilator_tb_utils11:29
stekernhow is it a problem? that it'd be 'hidden11:31
stekern' in verilator_tb_utils?11:31
_franck_I think for "less knowledgeable" users it is more clear11:33
stekernyeah, so would not using verilator_tb_utils at all be11:37
stekernand keep duplicate code for every system around instead11:37
_franck_ok, I'm not that rigid, I'll move it to verilator_tb_utils.11:38
stekernat least part of it, perhaps you're right about the connection between the tdi, tck... signals11:44
stekerncouldn't that be registered in the VerilatorJTAG constructor though?11:45
stekernand then the verilator_tb_utils could be passed the pointer to that?11:46
stekernor something like that11:46
stekernso, basically the only line in the system dependent code would be: VerilatorJTAG* jtag = new Verilator(10, &top->tck_pad_i, &top->tms_pad_i...11:48
_franck_then we would pass this pointer to VerilatorTbUtils, well, ok, let's do that11:51
stekernyes, perhaps you'll find a better way on the way though.11:52
stekernbut, I think the gist of it in the system code should be "hey, I want jtag connection with these signals" and that's it11:53
poke53281Stekern: Thanks, so the speed is comparable to a Pentium90.18:36
stekernpoke53281: yup, which I think is pretty decent20:35
poke53281Well, it depends on the FPGA. What would be the speed on the most advanced FPGA?23:26
--- Log closed Mon May 05 00:00:34 2014

Generated by 2.15.2 by Marius Gedminas - find it at!