| --- 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 |
|---|---|---|
| stekern | poke53281: is it good to advise people to eat bananas that does not look good? | 03:38 |
| analognoise | Hi 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 |
| analognoise | Which version of the ORP would be best to start with? | 03:49 |
| stekern | analognoise: as you have noticed, there are several different or1k implementations, the ones best supported are or1200 and mor1kx | 04:48 |
| stekern | or1200 is the original implementation, more stable, but not much development apart from critical bug fixes goes into this | 04:49 |
| stekern | mor1kx is a more modern implementation, that is faster and smaller | 04:49 |
| stekern | to use either of those, you can use the reference systems in https://github.com/openrisc/orpsoc-cores/ | 04:50 |
| stekern | which depends on https://github.com/olofk/fusesoc | 04:50 |
| stekern | LoneTech: trying to fool quartus with /* synthesis preserve */ didn't work | 04:55 |
| stekern | it's funny, I can work around it by adding a comb mux at the RAM output | 04:56 |
| analognoise | Thank you so much | 05:31 |
| analognoise | Fusesoc is the piece I had not seen yet! | 05:31 |
| analognoise | Ugh. Total noob with this device. Thanks for your help. :) | 05:31 |
| analognoise | Sheesh | 05:32 |
| analognoise | There 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 mor1kx | 05:36 |
| analognoise | [21:48:59] <stekern> or1200 is the original implementation, more stable, but not much development | 05:36 |
| analognoise | apart from critical bug fixes goes into thisrn[21:49:26] <stekern> mor1kx is a more modern implementation, that is faster and smaller | 05: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/fusesoc | 05:36 |
| analognoise | [21:55:43] <stekern> LoneTech: trying to fool quartus with /* synthesis preserve */ didn't work | 05:36 |
| analognoise | Whoops | 05:36 |
| analognoise | I was copying that to a text file | 05:36 |
| analognoise | :) | 05:36 |
| stekern | olofk: your first confused user! | 05:56 |
| stekern | ;) | 05:56 |
| olofk | cool | 06:10 |
| -!- olofk is now known as orpsoc | 06:12 | |
| orpsoc | Hehe... this will throw them off :) | 06:12 |
| * orpsoc is deprecated | 06:20 | |
| -!- orpsoc is now known as olofk | 06:20 | |
| olofk | If I give a .c file to g++, will it run a plain C compilation with gcc instead? | 06:33 |
| olofk | man pages seems to indicate that, but c++ is a bit of black magic for me | 06:34 |
| dalias | no idea :) | 06:35 |
| dalias | sounds like a bad idea tho | 06:35 |
| olofk | Well, 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 |
| olofk | So if g++ handles that itself, I trust that more than the patch I just got | 06:36 |
| olofk | and I don't want suffix-based decisions in my source code. Don't like that | 06:37 |
| _franck__ | stekern: those changes in or1200-generic depend on https://github.com/fjullien/fusesoc/commit/382f58cb75dd4fb0f03d92f8a91ef1f9d2e1b5e2 | 06:42 |
| _franck__ | olofk: we should add src_files_c and src_files_sc to verilator section (plus remove source_type) | 06:47 |
| olofk | There is some confusion here | 06:47 |
| olofk | We need a switch to decide if verilator should generate a systemC model or a plain C++ model | 06:48 |
| olofk | But in both cases the testbench code can be either systemC, C or C++ or a mix of all three | 06:49 |
| olofk | systemC is really just a c++ lib, right? | 06:49 |
| stekern | hmm, maybe I should 'watch' olofk/fusesoc | 06:49 |
| _franck__ | olofk: that's what I think | 06:50 |
| stekern | _franck__: yes, but that's not merged yet, right? | 06:50 |
| stekern | I have a lot of changes to or1200-generic/tb.cpp too, but I was waiting for that to fall in | 06:51 |
| olofk | And if g++ can handle both c and c++ files, then we don't need to have different options for those, right? | 06:51 |
| olofk | So then we only need a switch to add the systemC includes | 06: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 about | 06:55 |
| olofk | You make a list of all source files and include files from all cores | 06:55 |
| olofk | Wouldn't it be better to build the object files for each core separately. I'm worried that there might be conflicts otherwise | 06:56 |
| olofk | Not sure if it's a problem, but I wanted to discuss it first | 06:58 |
| * _franck__ will be back in an hour as _franck_web_ | 06:59 | |
| olofk | Hmm.. I guess it could be a Ãproblem if several cores define a constant with the same name, for example | 06:59 |
| stekern | olofk: g++ will not treat .c files as C | 07:02 |
| olofk | stekern: Sure about that? Look for "Options Controlling the Kind of Output" in the man page | 07:14 |
| stekern | empirical testing show otherwise | 07:17 |
| stekern | well, maybe it threat .c and .cpp files differently, but 'g++ file.c' is not equivalent to 'gcc file.c' | 07:22 |
| stekern | proof: http://pastie.org/8918089 | 07:22 |
| stekern | (notice the mangled name) | 07:24 |
| olofk | Thanks. I'm convinced | 07:35 |
| olofk | hmm.. I'm worried that things are going to get messy | 07:36 |
| olofk | New battle plan. Each core produces it's object files separately, and these are combined in the final linker stage when the verilator makefile is run | 07:37 |
| olofk | fusesoc 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 compilation | 07:39 |
| olofk | Oh.. and happy Pi day everyone | 07:40 |
| stekern | isn't that only celebrated on the other side of the pond, where they write dates backwards? | 07:42 |
| olofk | I'll gladly change religion, nationality and the way I write dates if it gives me a reason to celebrate something :) | 07:46 |
| olofk | hmmm.. 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>.a | 07:49 |
| blueCmd | stekern: 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 |
| blueCmd | the 2 Ethernet is to compare RGMII and SPI ethernet (ethoc vs. just spi core). | 11:08 |
| stekern | blueCmd: 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 it | 11:54 |
| stekern | ... and perhaps a vga connector + dac | 11:56 |
| stekern | for hours of scummvm fun ;) | 11:57 |
| blueCmd | haha | 12:11 |
| xenokiller | is that there is a logic schematics of a processor?? | 12:20 |
| blueCmd | xenokiller: no no, it's a breakout board | 12:21 |
| blueCmd | just some random things I want to add to the de0 nano board | 12:21 |
| stekern | I think the question is unrelated to your schematic | 12:21 |
| stekern | since he just joined | 12:21 |
| xenokiller | blueCmd ?? | 12:21 |
| stekern | there is rtl code (verilog/vhdl) serving as the "logic schematics" | 12:22 |
| blueCmd | aha | 12:22 |
| blueCmd | stekern: I don't see joins and stuff (/ignore JOIN PART QUIT or something like that) | 12:23 |
| blueCmd | so thanks for the heads up | 12:23 |
| xenokiller | a 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 |
| xenokiller | ok thanks | 12:37 |
| olofk | blueCmd: Agree with what stekern said Perhaps an ac97/hda IC for audio also | 14:55 |
| olofk | What 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 that | 14:57 |
| olofk | But I would say that's out of the scope for this breakout board | 14:57 |
| olofk | But a fast ADC would be nice. VGA+fast ADC could turn the nano into a decent oscilloscope | 14:59 |
| blueCmd | olofk: doesn't the DE0 nano have an ADC? | 15:40 |
| olofk | blueCmd: Don't know. Haven't got one | 15:44 |
| stekern | it does have an adc | 16:16 |
| stekern | _franck__: hooking up openocd to a 'cpu-less' adv_debugsys system and reading/writing ram per your suggestions works like a charm | 20:27 |
| _franck__ | stekern: great to hear | 20:37 |
| _franck__ | olofk: my verilator patch only worked because I had elf-loader files in the [vpi] section of elf-loader.core | 21:28 |
| _franck__ | I'm trying to make it work now but it gets messy | 21:29 |
| olofk | _franck__: I've started looking at building an archive for each core instead | 21:29 |
| _franck__ | ok great, I could be the way to go | 21:29 |
| _franck__ | s/i/it | 21:30 |
| joaocfernandes | hi | 21:30 |
| olofk | joaocfernandes: Hi | 21:30 |
| _franck__ | joaocfernandes: hi | 21:30 |
| joaocfernandes | i have been also now trying to use your vlt improvement v2 branch franck | 21:31 |
| _franck__ | also, that's not so good :( | 21:31 |
| _franck__ | s/also/well | 21:32 |
| joaocfernandes | the new core addition is working, i get elf-loader to compile cleanly | 21:32 |
| joaocfernandes | but i have a problem with the path of the source files i had previsouly linked to bench/verilator/* | 21:32 |
| joaocfernandes | besides that here is working | 21: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 |
| olofk | If 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 is | 21:36 |
| _franck__ | ok, thanks | 21:36 |
| olofk | It's not used yet, but the idea is that core-info should iterate through all known sections and let each section print itself | 21:36 |
| olofk | If 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/8920144 | 21:38 |
| olofk | and run core-info on a core | 21:38 |
| joaocfernandes | do you guys experience some similar problem as this one in the self.src_files in Verilator.py http://pastebin.com/taD6UpVn | 21:39 |
| stekern | wtf, why did the change to the uart pins in this get merged? https://github.com/openrisc/orpsoc-cores/commit/3b0a330c8dd8aee87a975a5a6f2d9db3e7a8b1dd | 21:39 |
| olofk | stekern: Can't remember. Either we discussed it, or it was a poor review from my side | 21:41 |
| joaocfernandes | the 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 incorrect | 21:41 |
| stekern | we 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 fixed | 21:42 |
| stekern | it just costed me 1.5 hour of debugging, so I'm a bit annoyed... | 21:42 |
| olofk | stekern: 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 side | 21: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 |
| olofk | Actually, it would be nice if we could get a system of core maintainers going | 21:43 |
| stekern | because hans thought they were placed nicer like that | 21:43 |
| _franck__ | joaocfernandes: each core would provide an archive file and everything would be linked with the test bench | 21:44 |
| stekern | but even it that is true, changing stuff like that around is always a very bad idea | 21:45 |
| olofk | stekern: Yes, that was ugly | 21: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 |
| joaocfernandes | okay after some debugging i think i understand a little better the problem now | 22: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_toplevel | 22:15 |
| joaocfernandes | if 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 this | 22:15 |
| joaocfernandes | self.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 part | 22:17 |
| _franck__ | I did this | 22:17 |
| joaocfernandes | will try your solution now | 22:17 |
| joaocfernandes | it did improve , but not completely | 22:26 |
| joaocfernandes | i have to read this core.py | 22:26 |
| joaocfernandes | a good night everyone, thanks for the help _franck__ | 22:29 |
| stekern | fusesoc/orpsoc-cores powered eco32 soc booting Linux on de0 nano: https://asciinema.org/a/8162 | 22:33 |
| _franck__ | awesome | 22:34 |
| _franck__ | you can now use the new fusesoc feature and create a subdir in de0 to hold de0-eco32 :) | 22:34 |
| stekern | yeah, we've got to get system reusage more friendly | 22:35 |
| stekern | right now I have two almost identical copies of or1200-generic (for verilator development) and the de0_nano systems | 22:36 |
| olofk | Looks like an interesting backlog, but I'm way too tired to look at it now | 22:39 |
| olofk | But the archive generation in fusesoc is almost done | 22:39 |
| _franck__ | http://pastie.org/private/sczcuia1bti9ustujcmyxq is almost working | 22:40 |
| _franck__ | only have to deal with include files | 22:40 |
| olofk | If anyone wants to see my work in progress, it's here http://pastie.org/8920236 | 22:41 |
| olofk | Good night | 22:41 |
| _franck__ | good night | 22:41 |
| _franck__ | jonmasters_: http://pastie.org/8920243 seems to work, need some more tests | 22:44 |
| _franck__ | jonmasters_: sorry I meant joaocfernandes | 22:45 |
| -!- Netsplit *.net <-> *.split quits: doomlord__ | 23:44 | |
| -!- Netsplit *.net <-> *.split quits: rah, FreezingCold, chad_, arokux, rokka | 23: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!