IRC logs for #openrisc Friday, 2014-03-14

--- Log opened Fri Mar 14 00:00:19 2014
stekern_franck__: doesn't those or1200-generic tb changes depend on the other verilator patches that are not yet merged?03:37
stekernpoke53281: is it good to advise people to eat bananas that does not look good?03:38
analognoiseHi everyone. I've just gotten started with the picoblaze, but I'd like to switch to one of the OpenRisc softcore processors for its increased flexibility and development tools. The wiki on OpenCores seems a tad outdated.03:48
analognoiseWhich version of the ORP would be best to start with?03:49
stekernanalognoise: as you have noticed, there are several different or1k implementations, the ones best supported are or1200 and mor1kx04:48
stekernor1200 is the original implementation, more stable, but not much development apart from critical bug fixes goes into this04:49
stekernmor1kx is a more modern implementation, that is faster and smaller04:49
stekernto use either of those, you can use the reference systems in https://github.com/openrisc/orpsoc-cores/04:50
stekernwhich depends on https://github.com/olofk/fusesoc04:50
stekernLoneTech: trying to fool quartus with /* synthesis preserve */ didn't work04:55
stekernit's funny, I can work around it by adding a comb mux at the RAM output04:56
analognoiseThank you so much05:31
analognoiseFusesoc is the piece I had not seen yet!05:31
analognoiseUgh. Total noob with this device. Thanks for your help. :)05:31
analognoiseSheesh05:32
analognoiseThere is a lot of renaming going on!05:33
analognoise analognoise: as you have noticed, there are several different or1krn                     implementations, the ones best supported are or1200 and mor1kx05:36
analognoise[21:48:59] <stekern> or1200 is the original implementation, more stable, but not much development05:36
analognoise                     apart from critical bug fixes goes into thisrn[21:49:26] <stekern> mor1kx is a more modern implementation, that is faster and smaller05:36
analognoise[21:50:39] <stekern> to use either of those, you can use the reference systems inrn                     https://github.com/openrisc/orpsoc-cores/rn[21:50:55] <stekern> which depends on https://github.com/olofk/fusesoc05:36
analognoise[21:55:43] <stekern> LoneTech: trying to fool quartus with /* synthesis preserve */ didn't work05:36
analognoiseWhoops05:36
analognoiseI was copying that to a text file05:36
analognoise:)05:36
stekernolofk: your first confused user!05:56
stekern;)05:56
olofkcool06:10
-!- olofk is now known as orpsoc06:12
orpsocHehe... this will throw them off :)06:12
* orpsoc is deprecated06:20
-!- orpsoc is now known as olofk06:20
olofkIf I give a .c file to g++, will it run a plain C compilation with gcc instead?06:33
olofkman pages seems to indicate that, but c++ is a bit of black magic for me06:34
daliasno idea :)06:35
daliassounds like a bad idea tho06:35
olofkWell, I have a pull request for a patch that checks if the suffix is c or cpp, and runs g++ or gcc based on that.06:36
olofkSo if g++ handles that itself, I trust that more than the patch I just got06:36
olofkand I don't want suffix-based decisions in my source code. Don't like that06:37
_franck__stekern: those changes in or1200-generic depend on https://github.com/fjullien/fusesoc/commit/382f58cb75dd4fb0f03d92f8a91ef1f9d2e1b5e206:42
_franck__olofk: we should add src_files_c and src_files_sc to verilator section (plus remove source_type)06:47
olofkThere is some confusion here06:47
olofkWe need a switch to decide if verilator should generate a systemC model or a plain C++ model06:48
olofkBut in both cases the testbench code can be either systemC, C or C++ or a mix of all three06:49
olofksystemC is really just a c++ lib, right?06:49
stekernhmm, maybe I should 'watch' olofk/fusesoc06:49
_franck__olofk: that's what I think06:50
stekern_franck__: yes, but that's not merged yet, right?06:50
stekernI have a lot of changes to or1200-generic/tb.cpp too, but I was waiting for that to fall in06:51
olofkAnd if g++ can handle both c and c++ files, then we don't need to have different options for those, right?06:51
olofkSo then we only need a switch to add the systemC includes06:52
_franck__stekern: should be merge soon (it that true olofk ?)06:52
_franck__olofk: well, may be :)06:54
olofk_franck__: There's one thing in the patch that I'm not sure about06:55
olofkYou make a list of all source files and include files from all cores06:55
olofkWouldn't it be better to build the object files for each core separately. I'm worried that there might be conflicts otherwise06:56
olofkNot sure if it's a problem, but I wanted to discuss it first06:58
* _franck__ will be back in an hour as _franck_web_06:59
olofkHmm.. I guess it could be a Ãproblem if several cores define a constant with the same name, for example06:59
stekernolofk: g++ will not treat .c files as C07:02
olofkstekern: Sure about that? Look for "Options Controlling the Kind of Output" in the man page07:14
stekernempirical testing show otherwise07:17
stekernwell, maybe it threat .c and .cpp files differently, but 'g++ file.c' is not equivalent to 'gcc file.c'07:22
stekernproof: http://pastie.org/891808907:22
stekern(notice the mangled name)07:24
olofkThanks. I'm convinced07:35
olofkhmm.. I'm worried that things are going to get messy07:36
olofkNew battle plan. Each core produces it's object files separately, and these are combined in the final linker stage when the verilator makefile is run07:37
olofkfusesoc will provide options to do the most basic stuff and if something more fancy needs to be done in order to generate the object file, the core has to provide a makefile or script that takes care of the compilation07:39
olofkOh.. and happy Pi day everyone07:40
stekernisn't that only celebrated on the other side of the pond, where they write dates backwards?07:42
olofkI'll gladly change religion, nationality and the way I write dates if it gives me a reason to celebrate something :)07:46
olofkhmmm.. would it make sense to always generate an archive instead for each core's verilator section. That way each core can keep it's own messy details internally and only export a <core_name>.a07:49
blueCmdstekern: olofk: I'm having a colleuge create me a periphrial board for DE0 nano. This is what it contains currently: http://storage.googleapis.com/bluecmd/de0_or_schematic_draft.pdf . Can you think of anything that I would want that I have missed?11:07
blueCmdthe 2 Ethernet is to compare RGMII and SPI ethernet (ethoc vs. just spi core).11:08
stekernblueCmd: ethernet is the most important, but if I'd be doing a breakoutboard I'd thrown in a usb phy in there for the fun of it11:54
stekern... and perhaps a vga connector + dac11:56
stekernfor hours of scummvm fun ;)11:57
blueCmdhaha12:11
xenokilleris that there is a logic schematics of a processor??12:20
blueCmdxenokiller: no no, it's a breakout board12:21
blueCmdjust some random things I want to add to the de0 nano board12:21
stekernI think the question is unrelated to your schematic12:21
stekernsince he just joined12:21
xenokillerblueCmd ??12:21
stekernthere is rtl code (verilog/vhdl) serving as the "logic schematics"12:22
blueCmdaha12:22
blueCmdstekern: I don't see joins and stuff (/ignore JOIN PART QUIT or something like that)12:23
blueCmdso thanks for the heads up12:23
xenokillera real scheamtics don't exist??12:24
_franck_web_xenokiller: no. When you do complex HDL design, usually you don't use schematics.12:31
xenokillerok  thanks12:37
olofkblueCmd: Agree with what stekern said Perhaps an ac97/hda IC for audio also14:55
olofkWhat I would like to see is a nice programmable multi gigabit transceiver, like the one's that are built-in in high-end FPGAs, so we could do some SATA, PCIe and stuff like that14:57
olofkBut I would say that's out of the scope for this breakout board14:57
olofkBut a fast ADC would be nice. VGA+fast ADC could turn the nano into a decent oscilloscope14:59
blueCmdolofk: doesn't the DE0 nano have an ADC?15:40
olofkblueCmd: Don't know. Haven't got one15:44
stekernit does have an adc16:16
stekern_franck__: hooking up openocd to a 'cpu-less' adv_debugsys system and reading/writing ram per your suggestions works like a charm20:27
_franck__stekern: great to hear20:37
_franck__olofk: my verilator patch only worked because I had elf-loader files in the [vpi] section of elf-loader.core21:28
_franck__I'm trying to make it work now but it gets messy21:29
olofk_franck__: I've started looking at building an archive for each core instead21:29
_franck__ok great, I could be the way to go21:29
_franck__s/i/it21:30
joaocfernandeshi21:30
olofkjoaocfernandes: Hi21:30
_franck__joaocfernandes: hi21:30
joaocfernandesi have been also now trying to use your vlt improvement v2 branch franck21:31
_franck__also, that's not so good :(21:31
_franck__s/also/well21:32
joaocfernandesthe new core addition is working, i get elf-loader to compile cleanly21:32
joaocfernandesbut i have a problem with the path of the source files i had previsouly linked to bench/verilator/*21:32
joaocfernandesbesides that here is working21:32
_franck__did you try to remove [vpi] section from elf-loader.core ?21:33
_franck__olofk: can you explain me this in fex words: https://github.com/olofk/fusesoc/commit/21cd2cac147d1695afb880cd679289656cf03122 ?21:34
olofkIf you define a __str__() function in a class, you can do print(object) and get a nice output instead of a function pointer or whatever the default is21:36
_franck__ok, thanks21:36
olofkIt's not used yet, but the idea is that core-info should iterate through all known sections and let each section print itself21:36
olofkIf you want to get a preview, you can import Section in core.py and add this at the bottom of the file http://pastie.org/892014421:38
olofkand run core-info on a core21:38
joaocfernandesdo you guys experience some similar problem as this one in the self.src_files in Verilator.py http://pastebin.com/taD6UpVn21:39
stekernwtf, why did the change to the uart pins in this get merged? https://github.com/openrisc/orpsoc-cores/commit/3b0a330c8dd8aee87a975a5a6f2d9db3e7a8b1dd21:39
olofkstekern: Can't remember. Either we discussed it, or it was a poor review from my side21:41
joaocfernandesthe first file in the list haves the correct path (elf-loader core) , the second one is a file provided on the system src files section but the path is incorrect21:41
stekernwe discussed it and I was strongly against it and that was the end of the discussion (afair) ;)21:41
_franck__joaocfernandes: because export function in verilator.py is not correct and need to be fixed21:42
stekernit just costed me 1.5 hour of debugging, so I'm a bit annoyed...21:42
olofkstekern: Can you remember why the change was made at all? I don't mind changing it back if it makes more sense. I don't have a board so no strong opinions here from my side21:43
_franck__joaocfernandes: I'm working on it but it's not easy to have a clean approach. olofk is working on something different.21:43
olofkActually, it would be nice if we could get a system of core maintainers going21:43
stekernbecause hans thought they were placed nicer like that21:43
_franck__joaocfernandes: each core would provide an archive file and everything would be linked with the test bench21:44
stekernbut even it that is true, changing stuff like that around is always a very bad idea21:45
olofkstekern: Yes, that was ugly21:46
_franck__olofk: what do you think of  letting the core export verilator files (like it's done with vpi and verilog files) ?22:02
joaocfernandesokay after some debugging i think i understand a little better the problem now22:11
_franck__I think it is as simple as this: http://pastie.org/private/aflonnrdpqxbngl70ffbsq and change the verilator export() to only deal with tb_toplevel22:15
joaocfernandesif the processed cores could be distinguinshed between core-core and core-system when the verilator.py constructor is called  i think the only thing that is necessary to be diferent inside the for cores loop is the  self.src_files    atrib that will self.src_root in one case self.tb_root or something like this22:15
joaocfernandesself.src_files         += [os.path.join(self.src_root, core_name, f) for f in core.verilator.src_files]22:15
_franck__^ is okay for the build part22:17
_franck__I did this22:17
joaocfernandeswill try your solution now22:17
joaocfernandesit did improve , but not completely22:26
joaocfernandesi have to read this core.py22:26
joaocfernandesa good night everyone, thanks for the help _franck__22:29
stekernfusesoc/orpsoc-cores powered eco32 soc booting Linux on de0 nano: https://asciinema.org/a/816222:33
_franck__awesome22:34
_franck__you can now use the new fusesoc feature and create a subdir in de0 to hold de0-eco32 :)22:34
stekernyeah, we've got to get system reusage more friendly22:35
stekernright now I have two almost identical copies of or1200-generic (for verilator development) and the de0_nano systems22:36
olofkLooks like an interesting backlog, but I'm way too tired to look at it now22:39
olofkBut the archive generation in fusesoc is almost done22:39
_franck__http://pastie.org/private/sczcuia1bti9ustujcmyxq is almost working22:40
_franck__only have to deal with include files22:40
olofkIf anyone wants to see my work in progress, it's here http://pastie.org/892023622:41
olofkGood night22:41
_franck__good night22:41
_franck__jonmasters_: http://pastie.org/8920243 seems to work, need some more tests22:44
_franck__jonmasters_: sorry I meant joaocfernandes22:45
-!- Netsplit *.net <-> *.split quits: doomlord__23:44
-!- Netsplit *.net <-> *.split quits: rah, FreezingCold, chad_, arokux, rokka23:56
--- Log closed Sat Mar 15 00:00:17 2014

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!