IRC logs for #openrisc Wednesday, 2016-03-30

--- Log opened Wed Mar 30 00:00:58 2016
mithrowallento / 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
wallentoolofk: yep, your last thought was actually what I was thinking too01:16
wallentomithro: I have no clue. maybe jeremybennett can give a hint. They did the epiphany port IIRC01:18
mithroepiphany port?01:18
mithrojeremybennett: see the above question :)01:18
mithroolofk: Is there a way I could convince you to use MiSoC? :P01:21
mithroolofk: That was mostly a joke (but I would love to actually understand why it would be a bad idea :)01:22
wallentomithro: Thats the Adapteva processor01:27
mithrowallento: ahh, the thing on the Parallella  board which also had the Zynq chip on it and the "kickstarter economics controversy"01:29
wallentoyeah, but before the parallella part01:30
wallento:)01:30
wallentoI think the complexity can be compared for OpenRISC01:31
wallentoI tracked the recent changes on GCC6 from their port for OpenRISC01:31
mithroI 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
wallentoit tries :)02:38
jeremybennettmithro: 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
jeremybennettif 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
olofkmithro: I've been looking at MiSoC a bit, but to be honest, it doesn't really cater to any of my needs04:18
olofkIt's a pain to integrate with other code and run simulations04:19
olofkI'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 system04:21
olofkAnd 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 FuseSoC04: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 invest05:13
_florent_olofk: I'll probably try to generate cores with Migen/MiSoC in the future that could be used in FuseSoC05: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 better05: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 existing05:28
_florent_mithro: but on our side that's a really a good idea to reuse mor1kx for HDMI2USB if we want to run Linux05:29
mithro_florent_: Or maybe RISC-V if you get that into MiSoC05:29
_florent_yes that's mostly done, I just need to get the IRQ working05:31
mithroI 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
doomlordwikipedia 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 GCC06:33
wallentodoomlord: there have been vector extensions06:51
wallentobut I think there is no version of the most active core implementation mor1kx06:52
wallentojeremybennett: Thanks for the info06:52
wallentowe should do a kickstarter "Re-implement OpenRISC GCC port" and hire someone :)06:52
doomlordhas openrisc been implemented in silicon06:54
wallentoonly closed versions of the core06:54
doomlordhow much interest does it have compared to risc-v (seems like similar goals)06:54
doomlord'compare and contrast: openrisc vs riscv'06:55
wallentorisc-v has a lot of traction, because they make much noise and collected quite some money for a professional organization06:55
wallentoopenrisc is more of a community06:56
wallentotechnically, the openrisc ISA is a little bit rusty and a full 64 bit spec is pending06:56
jeremybennettdoomlord: The wikipedia page lists some of the OpenRISC uses06:57
wallentorisc-v is essentially the ISA06:57
wallentowhich is good06:57
wallentothe rest is more about communities I would say06:57
wallentorisc-v is largely controlled by berkeley and there is a virtual barrier it seems06:58
wallentobut there are other projects, especially lowrisc06:58
doomlordi like the layered approach, core+extentions06:58
wallentothat base on risc-v and are more in the spirit of a community-driven platform06:58
wallentoyou mean for the ISA?06:58
wallentothats what both have06:58
doomlordyes06:59
wallentobut risc-v put a lot more thought into it06:59
wallentothere were plans to create an OpenRISC 2 ISA07:00
wallentowhich started around the same time risc-v started07:00
wallentobut I think it is not actively followed anymore07:00
doomlordi'm looking forward to the adapteva risc-v chip07:01
wallentoI think this will take a lot of time07:01
doomlordmany unknowns (and its unknown in what form it will be availalbe)07:01
wallentolowRISC is the frontrunner for a commercially available RISC-V based SoC07:01
wallentothere are some tapeouts of microcontroller class SoCs I think07:02
doomlordit'll be interesting to see how far india gets with theirs07:02
doomlordbut i guess that'll only be used for their servers and supercomputers07:03
wallentoI have no clue what the timeline is there and if and when silicon will actually be available07:04
olofkwallento: 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 vlnv16:04
olofkAnd another small detail. Missing version should mean version==0.16:06
olofkThere is an issue with this when we want to use latest git version of a core16:08
olofkgentoo solves this by creating a version 9999 of some packages, which will then always be the latest version.16:08
olofkBut this isn't really applicable for FuseSoC16:09
olofkso.... oh wait. It's probably better to write this down in the wiki instead :)16:09
wallentoright, thats the idea16:12
wallentoI would propose to drop the >= for the moment16:12
wallentoit should be 'latest' vs. a specific version16:13
wallentoI don't think there is that much of a use case for >=, because we will always fetch updates right?16:14
olofkActually, there is. Many cores break API, so we often need to depend on a version range16:19
olofkOr if they don't break API, we still got a problem16:20
olofkCurrently, a big problem is the vlog_tb_utils core16:20
olofkI released a new version of that16:20
olofkAnd 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 namespace16:21
olofkSo I need to swtich over all cores at once to the new version16:21
olofkOr depend on >=16:21
olofkwallento: I also propose using "" as default vendor and library instead of None16:41
olofki.e. empty string16:41
olofkand letting <name> == ::<name>, to keep backwards compatibility16:42
olofkwallento: Can you explain why you wrote that only local directories will be searched, when using the simple name dependency style?16:48
wallentoolofk: I think remote directories should stick to a full vendor-library-name17:00
wallentobut we should clarify a bit what other remotes are possible beside librecores17:00
wallentothats the main one I have in mind17:00
wallentoalso philipp proposed we should make them indexable17:01
wallentoI will put some thoughts with him into the librecores.org<->core git relation17:01
wallentoand another thing I noticed for improvement is the case where I have multiple cores in one git17:01
wallentolike oh or optimsoc17:02
wallentonow the entire repository is checked out at for each core I think17:02
-!- felix__ is now known as FelixVi21: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!