IRC logs for #openrisc Thursday, 2016-04-14

--- Log opened Thu Apr 14 00:00:20 2016
-!- Netsplit *.net <-> *.split quits: fotis, _florent_, bentley`, dalias, stekern_, knz_, kaaliakahn02:08
-!- Netsplit over, joins: kaaliakahn02:15
olofkwallento: I can imagine that. I've been thinking a fair bit about this :)02:22
olofkThere are some housekeeping tasks I would like to do first actually02:22
olofkI want to deprecate the .system file and move everything to .core02:24
olofkAnd the coremanager needs to be made a bit more flexible too02:28
olofkI want to02:28
olofkbe able to match on name, if there aren't any conflicts02:29
olofke.g, have a dependency on wb_ram is ok, as long as there aren't several cores with that name, but different vendor+library02:30
olofkThis will make the migration much easier02:31
olofkHmm... But we can't deprecate the .system files straight away, so we need to support that for a while as well02:33
olofkAll the more reason to deprecate it ASAP I guess, so we won't have to support it forever02:33
olofkAnd if we implement the multiple testbenches feature, we can deprecate the simulator section, which is currently the only section (except for provider, but that one is a bit special) that is not described in section.py02:35
olofkBut I guess we can begin with just defining the VLNV components in the main section for future use. When we do that, we should also make sure to fetch them from the IP-XACT file if there is one02:36
olofkStep 2 would be to extend the coremanager to handle VLNV dependencies02:36
wallentoolofk: why deprecate system? I think it makes perfectly sense to have it as some kind of entry point02:49
wallentowhat I did not implement so far is the handling of dependencies02:50
wallentolike you said02:50
wallentoto support legacy files02:50
wallentoI will add it later02:50
olofkwallento: The original idea of the .system files was that it should be possible to have several hw implementations of a core, but that doesn't really work in practice, so it's just a lot of extra handling to manager the .system files as well03:13
wallentoyes, I agree its extra work03:13
olofkI'm moving more in the direction of having defined "targets" in the .core files instead, where a target is an FPGA implementation or a testbench03:13
wallentoit is somehow helpful as a toplevel thing03:13
wallentookay, that makes sense03:13
wallentoI will track your changes in my work then03:14
olofkI should really really write this stuff down :/03:14
wallentoso the "targets" will then be what is listed by list-systems, right?03:25
olofkwallento: Haven't thought of that03:33
olofkDon't really use list-systems myself to be honest :)03:33
wallentoyeah, I just discovered it yesterday ;)03:33
wallentowhile testing the naming03:33
olofkBut I think that once we have everything in the .core file it will be easier to just export everything a json or yaml for external tools to consume03:34
wallentoyes, but it would be great to have a list of clear entry point, because fusesoc build <any core name> does not work03:35
wallentobut agree, one file is much better03:35
olofkThat will also take care of the property API I've been thinking of. Instead of asking for properties, we can just dump the json/yaml and pick out what we want03:35
olofkTrue. list-systems does have that benefit03:35
wallentowe currently move the OpTiMSoC build to fusesoc03:36
wallentousing the new naming03:36
olofkSo, then yes, we should list the (build) targets in list-systems to keep backwards-compatiblity03:36
olofkAh. Cool03:36
olofkI'm still not convinced that we should allow the v:l:n@v format though. It's a convenience feature, but it makes it a bit more complicated in cases where we want to get parts of the vlnv from a IP-XACT file and override parts of it in the .core file03:37
wallentoyou mean as a name? or dependency?03:38
wallentoI think there is nothing we can't solve. I also see some issues with librecores then, but I will move it forward, no code that can't be removed again03:39
wallentoby the way: what is in core and system files thats not in IPXACT?03:39
wallentoah, shit, I found a critical thing now03:40
olofkThe biggest item is dependencies, and that's something I really don't think we should put in the IP-XACT files, even as an extension03:40
wallentousing ../verilog in a core file does not work..03:40
olofkThe other smaller things are scope and usage of filesets (although groups in IP-XACT might replace usage)03:40
olofkSome filetypes aren't defined in IP-XACT either, such as verilog 2005 and vhdl 200803:41
wallentookay, great, I was just wondering for librecores to use some kind of overlapping information to generate either03:41
olofkI think we should encourage people to use IP-XACT, and let the .core files handle the rest03:41
wallentoregarding my issue: should I remove all relative path navigation from the path or is it just forbidden to have ../?03:41
wallentoyes, that sounds like a good approach03:42
olofkWhy doesn't that work?03:42
wallentobecause it clashes with other modules03:42
wallentoin dst_dir03:42
olofkah yes. The export function breaks03:42
olofkOf course you can't reference files outside of your core :)03:42
wallentoin OpTiMSoC each core has the same structure: verilog/ and scripts/ip.core03:43
wallentookay, we will just move the core files up03:43
olofkYes. I agree that it would be nice to hide the .core files in a subdir in some cases, but right now I don't want to risk the added complexity of that03:43
wallentoyes, makes sense03:44
olofkFucking unbelievable. Two days after I downloaded Xilinx 2015.3 they released 2015.4.04:22
olofkTwo days ago we decided to migrate to 2015.404:23
olofkToday the released 2016.104:23
olofkAnother 6GB download ahead :)04:23
olofkThis is weird. Vivado refuses to install since it says I'm on a 32-bit platform04:33
olofkApparently it runs uname -i and expects to get "x86_64"04:33
olofkBut on my machine that returns GenuineIntel, while uname -m returns x86_6404:33
olofkHow can this be?04:34
olofkok, so on a ubuntu machine uname -i returns x86_64. This is weird04:40
olofkTrying to add a ghdl backend, but my code just makes it crash :(05:07
--- Log closed Thu Apr 14 08:06:04 2016
--- Log opened Thu Apr 14 08:06:12 2016
-!- Irssi: #openrisc: Total of 47 nicks [0 ops, 0 halfops, 0 voices, 47 normal]08:06
-!- Irssi: Join to #openrisc was synced in 13 secs08:06
wallentoolofk: one concern I have regarding the dependencies on name only (*:*:name)08:54
wallentoShouldn't we force users to write proper files that avoid conflicts from the beginning?08:55
wallentoespecially if we integrate a librecores backend a ram named module may mean anything..08:55
wallentoor do you mean that if only a name is given it should be sufficient to write name instead of ::name, because thats the case already09:01
olofkwallento: I mean both actually. name would be a shortcut for ::name (for backwards compatibility), and if there is only one component with a given name, we should use that, even if we don't specify vendor and library11:02
olofkI'm starting to understand that this last point might clash with your librecores API ideas. Is that correct? I haven't fully understood your plan here11:03
wallentookay, the first is already an, it is backward compatible. I can add the second one, but we should probably throw a warning11:03
wallentoyes, that would clash11:03
wallentofor the first we can index, so it returns all .core files11:04
wallentobut I would assume there are conflicts then11:04
olofkFor things like gpio, or uart I assume there will be conflicts, but I don't envision that we will have too many wb_ram or elf-loader cores :)11:04
wallentoI have two elf-loaders already ;)11:05
wallentoand I renamed optimsoc's wb_ram to sram some years back because of conflicts ;)11:05
olofkMaybe we could allow this relaxed matching only for local cores then11:05
wallentoyes, that is something we can add11:05
wallentoso if it is local only, the user can leave out v and l, right?11:06
wallentoso, I am not against it, but I suspect it diffuses and one of us will be the first to whine because our own toolflow selected the wrong module ;)11:06
wallentobut lets see where it gets us11:06
olofkBut if there are several modules with the same name, this isn't supposed to work11:07
olofkWe should get a warning or error then11:07
wallentoyep, agreed11:07
wallentoI will not add it today, but we should open an issue for this11:07
wallentoits part of dependency resolution11:07
wallentothere are other things like versioning too, I think11:07
olofkBut this discussion is also why I want to think hard before adding new features. There are already some problematic parts of FuseSoC that is caused by early design decisions :/11:07
olofkYeah. Versioning is important11:08
wallentoI would also propose to think about something like a common function or module for generating path names11:08
olofkTo get things started, I think we could begin with just adding the vlnv parameters to the main section, and add code to get them from the IP-XACT file11:09
wallentoI have changed to core.sanitized_name at many places now which all seem to do more or less the same11:09
wallentothe stuff for the core files is completed11:09
olofkI saw that in your patches. Didn't really understand the reason for it. Can you explain11:09
wallentomost of the tools hate colons in names11:09
wallentopath names11:10
olofkHmm.. I think I'm a bit off then. Where do we get colons in names?11:10
wallentoso it converts vendor:library:name to vendor_library_name11:10
wallentobecause the core "name" is this triplet currently11:10
wallentoI changed it initially to vendor/library/name11:11
wallentobut then the whole stuff just blew up11:11
olofkah ok. So it's used when creating the structure in the build tree11:11
wallentoyep, its only about the output tree11:11
olofkCool. Yeah. That's good11:11
olofk_ or - works for me11:11
wallentocool, at least for the moment this should be okay, of course everyone can construct a conflicting name, but I would not overengineer this for now11:12
olofkIn theory we could get a clash though, but it's unklikely11:12
olofkNo problem changing that later on as you say11:12
olofkI  still wonder if we should do something about the .system files first though11:15
olofkMaybe we can just require that the .system file has the same name as the .core file for now11:15
olofkAnd internally, we just append the stuff in .system to the .core file11:16
olofkYeah, that could be a good intermediate step11:16
olofkIt makes the migration path easier. We treat the stuff in .system as if it was just appended to the .core file11:17
wallentoyes, thats a great idea11:26
-!- dalias_ is now known as dalias11:41
wallentoolofk: hooray, OpTiMSoC verilated simulations work now with FuseSoC and the new naming scheme12:07
olofkwallento: Awesome!12:27
wallentophilipp wrote most of the core files, I will forward ;)12:28
olofkNah.. Take the credit yourself instead :)12:29
olofkwallento: I see that you carry an internal mor1kx in OpTiMSoC. Is it much different from upstream?12:52
wallentoits like snapshots12:53
wallentosome old stuff we want to get rid off12:53
wallentoits historical12:53
wallentobecause I developed the multicore extensions there before merging12:53
olofkah ok. I see12:53
wallentothere also is a wrapper module around it which is even older, was called or1200_wrapper before and my first lines of verilog code I have written12:54
wallentoin 2009 :)12:54
wallentowe are cleaning all this stuff up in the next12:54
olofkwallento: I'm moving forward with the .system file deprecation. A few problems remain, but it looks mostly good17:22
olofkandrzejr: I'm aware that I haven't pulled your providers yet. It's on my todo list still17:40
-!- Netsplit *.net <-> *.split quits: kaaliakahn23:32
-!- Netsplit over, joins: kaaliakahn23:39
--- Log closed Fri Apr 15 00:00:22 2016

Generated by 2.15.2 by Marius Gedminas - find it at!