| --- Log opened Tue Nov 10 00:00:03 2015 | ||
| olofk | andrzejr_: For wb_intercon I think I'll prefer the generator approach. I added support for named sections i FuseSoC a few days ago. This was one of the blockers for the generator infrastructure | 08:12 |
|---|---|---|
| olofk | My main reason for this is that I don't want to push any core-specific code directly into FuseSoC | 08:13 |
| olofk | I pushed a fix to the Atlys board to increase the boot ROM size and move it to 0xf0000000. Would be great if someone with an Atlys board could confirm that it's still working | 08:17 |
| andrzejr | olofk, if you've got generator API working we should use that for coregen as well. I used provider API because that was the only thing that did the job | 09:40 |
| olofk | andrzejr: I'm not sure that we should use the generator API (when it comes available) for coregen actually. | 09:46 |
| olofk | or maybe, but have it built into FuseSoC | 09:46 |
| GeneralStupid | olofk: i think that approach is really good. And isn't it the 'same' approach that tensilica and competitors are using? | 09:48 |
| GeneralStupid | olofk: i would like to do add some stuff to fusesoc for generating custom instructions and regenerate the wb_intercon in existing projects... | 09:48 |
| GeneralStupid | olofk: at the moment fusesoc is great to get a working core but after the fetch process you are pretty much on your own (i felt like that) | 09:49 |
| olofk | GeneralStupid: I don't know how Tensilica does things, but I've been planning to add this damn generator API for like three years now :) | 10:00 |
| olofk | Well, you can already do some things with the scripts support | 10:00 |
| olofk | You should be able to add a script that regenerates wb_intercon for you | 10:00 |
| GeneralStupid | olofk: ive done this for my project | 10:02 |
| GeneralStupid | olofk: i need to finish my report and after that i will add the de2 support... And then i want to play with profiling and custom instructions | 10:03 |
| GeneralStupid | CI makes no sense without good profiling | 10:03 |
| olofk | Cool. I like profiling | 10:04 |
| GeneralStupid | olofk: you have to try that tensilica stuff just once... | 10:04 |
| GeneralStupid | olofk: i think its not *that much | 10:05 |
| GeneralStupid | * | 10:05 |
| GeneralStupid | better then openrisc is | 10:05 |
| GeneralStupid | But the toolchain, the profiling, the integration... its really nice | 10:05 |
| olofk | I've been thinking of doing a VPI module to hook up to mor1kx_monitor, so I can save the instruction trace to a database for offline viewing | 10:05 |
| GeneralStupid | what is vpi? | 10:06 |
| olofk | The verilog mechanism for calling C functions | 10:06 |
| olofk | We're using that for the elf-loader and jtag_vpi | 10:07 |
| olofk | and some other stuff | 10:07 |
| GeneralStupid | olofk: instruction trace is what tensilica gives you... for example, i tooked the smallest "CPU" first, i profiled and saw that there is a lot of div32. So i added div32 and saved a lot of cycles... | 10:07 |
| GeneralStupid | olofk: so for simulation? | 10:08 |
| olofk | yes | 10:08 |
| olofk | Are you talking about profiling on real hw? | 10:08 |
| GeneralStupid | is there a more generic way? Which would work in simulation and emulation? | 10:08 |
| olofk | wallento may have something | 10:09 |
| GeneralStupid | olofk: for the tensilica case iam talking about simulated profiling | 10:09 |
| olofk | We got that for OpenRISC already with the mor1kx monitor | 10:09 |
| GeneralStupid | nice nice , but the development time grows because of the emulation, right? | 10:10 |
| wallento | wallento has something, but only the pure execution tracing, no real tooling around it | 10:10 |
| GeneralStupid | is it ok if i tell you, that i hate verilog ?! :-D | 10:10 |
| GeneralStupid | wallento: :( Tooling makes that stuff less painfull :) | 10:10 |
| wallento | yeah, I know | 10:10 |
| olofk | Try fusesoc sim mor1kx-generic --elf-load=/path/to/elffile --trace_enable | 10:11 |
| wallento | whats your email? | 10:11 |
| olofk | and --trace_to_screen to get it printed to the terminal | 10:11 |
| GeneralStupid | wallento: pe@perdmann.de | 10:11 |
| wallento | great, I will send you a quick summary | 10:11 |
| GeneralStupid | thanks | 10:11 |
| GeneralStupid | olofk: i dont have iverilog | 10:14 |
| GeneralStupid | olofk: and it is a problem for me, that i cant mix vhdl and verilog | 10:14 |
| GeneralStupid | olofk: thanks, i need to cook something now :) i will write that in my report. | 10:16 |
| GeneralStupid | we are designing ASIPs and tensilica is often not that good... But profiling and custom instructions are really necessary :) | 10:17 |
| olofk | GeneralStupid: VHDL got VHPI now with VHDL2008, so you could probably reuse some of the VPI stuff by writing a VHPI wrapper instead | 10:23 |
| _franck__ | GeneralStupid: you can do hardware profiling with openocd | 10:31 |
| _franck__ | it is not much accurate because it does polling on program counter but if you run it long enough it can be representative enough | 10:32 |
| olofk | andrzejr: I'll wait a bit wih the coregen provider patches, in case we want to do this as a generator instead | 12:09 |
| GeneralStupid | _franck__: so profiling with the simulator is better? | 12:16 |
| GeneralStupid | olofk: 'write a wrapper' sounds easy :-D | 12:16 |
| olofk | What the hell? xsim doesn't support $clog2 either? | 12:20 |
| olofk | andrzejr: Might need to rewrite the xsim support to use tcl files instead if I can't find a way to turn on systemverilog | 12:32 |
| _franck__ | GeneralStupid: I don't know if it's better but it might be faster | 12:34 |
| GeneralStupid | _franck__: faster, of course. I think its more practically | 12:34 |
| _franck__ | sorry when I said faster I meant in hardware | 12:35 |
| GeneralStupid | _franck__: i meant the development speed... | 12:37 |
| olofk | andrzejr: Found it now. Need to use "sv work <file>" instead of "verilog work <file>" | 13:17 |
| olofk | Need to add some option to indicate if the core needs sv support | 13:17 |
| olofk | Unfortunately all testbenches I try fail with xsim :( | 13:22 |
| olofk | You got to be kidding me. xsim is also getting $clog2 wrong | 13:45 |
| olofk | $clog2(4) == 2 in Icarus and modelsim, but 3 in xsim | 13:46 |
| stekern | of course it has to be wrong to not cause simulation/synthesis mismatches ;) | 13:48 |
| wallento | I think this is why we added this file: https://github.com/optimsoc/rtl/blob/master/optimsoc_functions.vh | 13:49 |
| stekern | yeah, we have a similar file in orpsoc-cores: https://github.com/openrisc/orpsoc-cores/blob/master/cores/verilog_utils/verilog_utils.vh | 13:50 |
| olofk | stekern added something similar some years ago | 13:51 |
| olofk | That was for ISE 13.something that implemented $clog2 as base e or base 10 | 13:51 |
| olofk | Unfortunately icarus doesn't handle static functions, so we had to make a workaround | 13:52 |
| olofk | And I removed this over a year ago since I though no one would be running that ancient ISE version anymore | 13:52 |
| olofk | But they actually managed to reintroduce the bug in Vivado it seems | 13:52 |
| olofk | Does anyone have Vivado later than 2014.4 who can test $clog2 | 14:10 |
| olofk | module clog2_tb; //Should be 2 initial $display("%d", $clog2(4)); endmodule | 14:10 |
| olofk | A newline after "Should be 2" of course | 14:12 |
| wallento | yes | 14:26 |
| wallento | wait a sec | 14:26 |
| wallento | olofk: yes, its 2 | 14:35 |
| wallento | in vivado 2015.2 | 14:35 |
| olofk | wallento: Ah ok. Thanks. Couldn't find anything in the release notes | 15:11 |
| olofk | wallento: Did you test $clog2 with simulation or synthesis? 2014.4 gets it right for synthesis | 15:31 |
| wallento | xsim | 15:32 |
| wallento | right? | 15:32 |
| wallento | should I check synthesis also? | 15:32 |
| olofk | No need. | 15:33 |
| andrzejr | olofk, the ddr2 core generated by coregen has both isim and xsim testbenches working (as generated by coregen) | 17:35 |
| andrzejr | afair | 17:35 |
| olofk | stekern: Shouldn't the `endif be at the bottom of the file in verilog_utils.vh? | 17:44 |
| olofk | Hmm.. can't figure out how these header definitions should be used. Getting duplicate definitions or undefined functions | 17:50 |
| olofk | ok, it works now | 17:52 |
| olofk | Looks like it's still too early to use bleeding-edge features like $clog2 :( | 17:53 |
| olofk | But at least xsim support works fine. Still need to figure out how to handle the verilog/systemverilog case | 17:54 |
| olofk | Right now I'm leaning towards adding an option to the verilog section to set the default language revision to use | 17:55 |
| olofk | In the long run I think we might need per-file overrides, but that's not an issue for now | 17:55 |
| andrzejr | how about having different sections for source files (verilog, system verilog, vhdl etc) | 18:07 |
| olofk | andrzejr: VHDL and verilog already have different sections, although the vhdl support is really minimal | 18:13 |
| olofk | But when I add more IP-Xact support, I think it would make sense instead to define filesets | 18:14 |
| olofk | And have some defaults per fileset | 18:14 |
| olofk | So that for synthesis we use fileset1, for icarus we use fileset1+fileset2+fileset3 and for modelsim we use fileset1+fileset2+fileset4 | 18:15 |
| olofk | So my future plans clash a bit with the current vhdl/verilog sections. Therefore I'm hesitating towards adding a systemverilog section as well | 18:16 |
| -!- rhythmx_ is now known as rhythmx | 18:19 | |
| olofk | Oh... I forgot that I actually already implemented part of the filesets stuff in a branch :) | 18:19 |
| olofk | Ahh.. and with the fancy new named sections, we could define filesets in the core files. This changes EVERYTHING! | 18:20 |
| olofk | Just need to leave my family and quit my job | 18:21 |
| andrzejr | olofk, just an observation - many problems with core files are nicely solved by splitting the core into multiple parts. | 19:47 |
| andrzejr | I've done that with all generated ones by separating out any wrappers etc. no need for extra sections, sequencing etc | 19:50 |
| andrzejr | things get simpler and you can keep your family and job! :-) | 19:53 |
| olofk | andrzejr_: haha. :) | 20:57 |
| olofk | And I agree. No need to make things overly complicated if they can be solved with multiple cores | 20:57 |
| olofk | For example, it might be a lot easier to just allow a single VHDL library per core | 20:58 |
| olofk | And I think that you can only have one VPI library per core as well | 20:59 |
| GeneralStupid | olofk: is the multicore implementation in mor1kx from the TU munich? | 20:59 |
| olofk | GeneralStupid: wallento (from TU Munich) and stekern probably worked most on that. Not sure who did what | 21:00 |
| GeneralStupid | olofk: thanks | 21:15 |
| olofk | Alright! Got Clifford Wolf's picorv32 core running under RTL sims and verilator | 22:45 |
| olofk | But elf-loader could really use a endian selector. Had to hack read_32 for now | 22:48 |
| olofk | And I refactored the verilator support in FuseSoC too. It was a complete mess | 22:50 |
| olofk | Not sure I got everything right though :) | 22:50 |
| robtaylor | nice! | 22:54 |
| GeneralStupid | whats about amber? | 23:45 |
| --- Log closed Wed Nov 11 00:00:04 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!