| --- Log opened Sun May 04 00:00:33 2014 | ||
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/aa77169b6a0f84633ea2ad82f7153860f01688ba | 06:16 |
|---|---|---|
| mor1kx | mor1kx/master aa77169 Stefan Kristiansson: add support for l.lwa/l.swa atomic instructions... | 06:16 |
| blueCmd | stekern: wooh, nice push | 09:45 |
| stekern | blueCmd: thanks =) | 09:46 |
| stekern | right now, I'm writing Changelog entries to or1ksim | 09: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 too | 11:19 |
| _franck_ | I'll add support for it in mor1kx-generic | 11:19 |
| stekern | did 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 request | 11:21 |
| stekern | ah, I hadn't got the mail yet | 11:22 |
| stekern | I think that should be in verilator_tb_utils though | 11:23 |
| stekern | instead of the changes you did to or1200-generic | 11: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 here | 11:24 |
| stekern | huh? | 11:25 |
| _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 server | 11:25 |
| stekern | ah.. well, I think we can just remove the 'rsp' then and add the 'j' instead | 11:25 |
| stekern | it's not like rsp has been used anywhere, right? | 11:26 |
| stekern | my 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 of | 11:26 |
| _franck_ | right | 11:26 |
| stekern | that was the point of verilator_tb_utils, to avoid that | 11:27 |
| _franck_ | you still need to hook-up jtag signals to your verilog_tb_utils jtag thing | 11: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_utils | 11:29 |
| stekern | how is it a problem? that it'd be 'hidden | 11:31 |
| stekern | ' in verilator_tb_utils? | 11:31 |
| _franck_ | I think for "less knowledgeable" users it is more clear | 11:33 |
| stekern | yeah, so would not using verilator_tb_utils at all be | 11:37 |
| stekern | and keep duplicate code for every system around instead | 11:37 |
| _franck_ | ok, I'm not that rigid, I'll move it to verilator_tb_utils. | 11:38 |
| stekern | at least part of it, perhaps you're right about the connection between the tdi, tck... signals | 11:44 |
| stekern | couldn't that be registered in the VerilatorJTAG constructor though? | 11:45 |
| stekern | and then the verilator_tb_utils could be passed the pointer to that? | 11:46 |
| stekern | or something like that | 11:46 |
| stekern | so, 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 that | 11:51 |
| stekern | yes, perhaps you'll find a better way on the way though. | 11:52 |
| stekern | but, I think the gist of it in the system code should be "hey, I want jtag connection with these signals" and that's it | 11:53 |
| poke53281 | Stekern: Thanks, so the speed is comparable to a Pentium90. | 18:36 |
| stekern | poke53281: yup, which I think is pretty decent | 20:35 |
| poke53281 | Well, 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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!