| --- Log opened Wed Mar 30 00:00:58 2016 | ||
| mithro | wallento / olofk / _franck__: Semi-serious question, how long do you think it would take a semi-decent engineer with some GCC experience to reproduce the current or1k support? Are we talking full time - 1 month, 3 months, 6 months, 1 year? | 01:14 |
|---|---|---|
| wallento | olofk: yep, your last thought was actually what I was thinking too | 01:16 |
| wallento | mithro: I have no clue. maybe jeremybennett can give a hint. They did the epiphany port IIRC | 01:18 |
| mithro | epiphany port? | 01:18 |
| mithro | jeremybennett: see the above question :) | 01:18 |
| mithro | olofk: Is there a way I could convince you to use MiSoC? :P | 01:21 |
| mithro | olofk: That was mostly a joke (but I would love to actually understand why it would be a bad idea :) | 01:22 |
| wallento | mithro: Thats the Adapteva processor | 01:27 |
| mithro | wallento: ahh, the thing on the Parallella board which also had the Zynq chip on it and the "kickstarter economics controversy" | 01:29 |
| wallento | yeah, but before the parallella part | 01:30 |
| wallento | :) | 01:30 |
| wallento | I think the complexity can be compared for OpenRISC | 01:31 |
| wallento | I tracked the recent changes on GCC6 from their port for OpenRISC | 01:31 |
| mithro | I feel like that chip's design has some unique challenges? Or does it not try to abstract away the bunch of little cores stuff? | 01:32 |
| wallento | it tries :) | 02:38 |
| jeremybennett | mithro: GCC has a humongous learning curve. When we hire engineers we generally allow one year full-time to train them before we unleash them on customer's GCC code. | 04:04 |
| jeremybennett | if you have that experience, then 3 months. Most of the work on OpenRISC GCC 4.5.1 for NASA (which IIRC took about 3 months) was fixing the problems caused by lack of experience in the original port. | 04:07 |
| olofk | mithro: I've been looking at MiSoC a bit, but to be honest, it doesn't really cater to any of my needs | 04:18 |
| olofk | It's a pain to integrate with other code and run simulations | 04:19 |
| olofk | I've been using _florent_'s LiteSATA in a customer project, but then we just generated the verilog and used it as any other verilog/vhdl core in the system | 04:21 |
| olofk | And also I've been spending most of my time on FuseSoC, so I really haven't had much time to play with other stuff. Although, I always had the intention to be able to reuse cores written in Migen somehow in FuseSoC | 04:22 |
| _florent_ | olofk: hi, I can totally understand, Migen/MiSoC is convenient for some projects (but not all) and it's still some time to invest | 05:13 |
| _florent_ | olofk: I'll probably try to generate cores with Migen/MiSoC in the future that could be used in FuseSoC | 05:14 |
| _florent_ | olofk: BTW, I did a quick test of FuseSoC on a Windows machine, the first instructions you gave me were working, but building the de0-nano design was failing due to incorrect paths in the Quartus project, I'll try to fix that and send a patch. | 05:14 |
| mithro | _florent_ / olofk: I was interested to better understand the integration process and if it could be made better | 05:18 |
| _florent_ | mithro: that wouldn't necessary be a bad idea to use MiSoC, but that's another tool and some time / investment / revalidation to do on things that are already existing | 05:28 |
| _florent_ | mithro: but on our side that's a really a good idea to reuse mor1kx for HDMI2USB if we want to run Linux | 05:29 |
| mithro | _florent_: Or maybe RISC-V if you get that into MiSoC | 05:29 |
| _florent_ | yes that's mostly done, I just need to get the IRQ working | 05:31 |
| mithro | I think we probably should start with or1k as Linux sounds further along? In theory the Linux "peripheral driver code" should be sharable between both architectures. | 05:35 |
| doomlord | wikipedia tells me openrisc has SIMD extentions? | 05:51 |
| mithro | _florent_: I've been working on getting the or1k gcc/binutils/etc into conda so they can can be pulled in the same way we do our lm32 set up. | 06:32 |
| mithro | _florent_: Getting binutils going was easy, still fiddling with GCC | 06:33 |
| wallento | doomlord: there have been vector extensions | 06:51 |
| wallento | but I think there is no version of the most active core implementation mor1kx | 06:52 |
| wallento | jeremybennett: Thanks for the info | 06:52 |
| wallento | we should do a kickstarter "Re-implement OpenRISC GCC port" and hire someone :) | 06:52 |
| doomlord | has openrisc been implemented in silicon | 06:54 |
| wallento | only closed versions of the core | 06:54 |
| doomlord | how much interest does it have compared to risc-v (seems like similar goals) | 06:54 |
| doomlord | 'compare and contrast: openrisc vs riscv' | 06:55 |
| wallento | risc-v has a lot of traction, because they make much noise and collected quite some money for a professional organization | 06:55 |
| wallento | openrisc is more of a community | 06:56 |
| wallento | technically, the openrisc ISA is a little bit rusty and a full 64 bit spec is pending | 06:56 |
| jeremybennett | doomlord: The wikipedia page lists some of the OpenRISC uses | 06:57 |
| wallento | risc-v is essentially the ISA | 06:57 |
| wallento | which is good | 06:57 |
| wallento | the rest is more about communities I would say | 06:57 |
| wallento | risc-v is largely controlled by berkeley and there is a virtual barrier it seems | 06:58 |
| wallento | but there are other projects, especially lowrisc | 06:58 |
| doomlord | i like the layered approach, core+extentions | 06:58 |
| wallento | that base on risc-v and are more in the spirit of a community-driven platform | 06:58 |
| wallento | you mean for the ISA? | 06:58 |
| wallento | thats what both have | 06:58 |
| doomlord | yes | 06:59 |
| wallento | but risc-v put a lot more thought into it | 06:59 |
| wallento | there were plans to create an OpenRISC 2 ISA | 07:00 |
| wallento | which started around the same time risc-v started | 07:00 |
| wallento | but I think it is not actively followed anymore | 07:00 |
| doomlord | i'm looking forward to the adapteva risc-v chip | 07:01 |
| wallento | I think this will take a lot of time | 07:01 |
| doomlord | many unknowns (and its unknown in what form it will be availalbe) | 07:01 |
| wallento | lowRISC is the frontrunner for a commercially available RISC-V based SoC | 07:01 |
| wallento | there are some tapeouts of microcontroller class SoCs I think | 07:02 |
| doomlord | it'll be interesting to see how far india gets with theirs | 07:02 |
| doomlord | but i guess that'll only be used for their servers and supercomputers | 07:03 |
| wallento | I have no clue what the timeline is there and if and when silicon will actually be available | 07:04 |
| olofk | wallento: Just read your wiki entry on module naming. I think we can drop the "name = <vendor>:<library>:<name>[@<version>]" variant. It's mainly a convenient way to write the vlnv | 16:04 |
| olofk | And another small detail. Missing version should mean version==0. | 16:06 |
| olofk | There is an issue with this when we want to use latest git version of a core | 16:08 |
| olofk | gentoo solves this by creating a version 9999 of some packages, which will then always be the latest version. | 16:08 |
| olofk | But this isn't really applicable for FuseSoC | 16:09 |
| olofk | so.... oh wait. It's probably better to write this down in the wiki instead :) | 16:09 |
| wallento | right, thats the idea | 16:12 |
| wallento | I would propose to drop the >= for the moment | 16:12 |
| wallento | it should be 'latest' vs. a specific version | 16:13 |
| wallento | I don't think there is that much of a use case for >=, because we will always fetch updates right? | 16:14 |
| olofk | Actually, there is. Many cores break API, so we often need to depend on a version range | 16:19 |
| olofk | Or if they don't break API, we still got a problem | 16:20 |
| olofk | Currently, a big problem is the vlog_tb_utils core | 16:20 |
| olofk | I released a new version of that | 16:20 |
| olofk | And both of them can't be in the dependency tree at the same time, since they provide the same files, and verilog has a flat namespace | 16:21 |
| olofk | So I need to swtich over all cores at once to the new version | 16:21 |
| olofk | Or depend on >= | 16:21 |
| olofk | wallento: I also propose using "" as default vendor and library instead of None | 16:41 |
| olofk | i.e. empty string | 16:41 |
| olofk | and letting <name> == ::<name>, to keep backwards compatibility | 16:42 |
| olofk | wallento: Can you explain why you wrote that only local directories will be searched, when using the simple name dependency style? | 16:48 |
| wallento | olofk: I think remote directories should stick to a full vendor-library-name | 17:00 |
| wallento | but we should clarify a bit what other remotes are possible beside librecores | 17:00 |
| wallento | thats the main one I have in mind | 17:00 |
| wallento | also philipp proposed we should make them indexable | 17:01 |
| wallento | I will put some thoughts with him into the librecores.org<->core git relation | 17:01 |
| wallento | and another thing I noticed for improvement is the case where I have multiple cores in one git | 17:01 |
| wallento | like oh or optimsoc | 17:02 |
| wallento | now the entire repository is checked out at for each core I think | 17:02 |
| -!- felix__ is now known as FelixVi | 21:30 | |
| --- Log closed Thu Mar 31 00:00:59 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!