| --- Log opened Thu Apr 14 00:00:20 2016 | ||
| -!- Netsplit *.net <-> *.split quits: fotis, _florent_, bentley`, dalias, stekern_, knz_, kaaliakahn | 02:08 | |
| -!- Netsplit over, joins: kaaliakahn | 02:15 | |
| olofk | wallento: I can imagine that. I've been thinking a fair bit about this :) | 02:22 |
|---|---|---|
| olofk | There are some housekeeping tasks I would like to do first actually | 02:22 |
| olofk | I want to deprecate the .system file and move everything to .core | 02:24 |
| olofk | And the coremanager needs to be made a bit more flexible too | 02:28 |
| olofk | I want to | 02:28 |
| olofk | be able to match on name, if there aren't any conflicts | 02:29 |
| olofk | e.g, have a dependency on wb_ram is ok, as long as there aren't several cores with that name, but different vendor+library | 02:30 |
| olofk | This will make the migration much easier | 02:31 |
| olofk | Hmm... But we can't deprecate the .system files straight away, so we need to support that for a while as well | 02:33 |
| olofk | All the more reason to deprecate it ASAP I guess, so we won't have to support it forever | 02:33 |
| olofk | And 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.py | 02:35 |
| olofk | But 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 one | 02:36 |
| olofk | Step 2 would be to extend the coremanager to handle VLNV dependencies | 02:36 |
| wallento | olofk: why deprecate system? I think it makes perfectly sense to have it as some kind of entry point | 02:49 |
| wallento | what I did not implement so far is the handling of dependencies | 02:50 |
| wallento | like you said | 02:50 |
| wallento | to support legacy files | 02:50 |
| wallento | I will add it later | 02:50 |
| olofk | wallento: 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 well | 03:13 |
| wallento | yes, I agree its extra work | 03:13 |
| olofk | I'm moving more in the direction of having defined "targets" in the .core files instead, where a target is an FPGA implementation or a testbench | 03:13 |
| wallento | it is somehow helpful as a toplevel thing | 03:13 |
| wallento | okay, that makes sense | 03:13 |
| wallento | I will track your changes in my work then | 03:14 |
| olofk | I should really really write this stuff down :/ | 03:14 |
| wallento | so the "targets" will then be what is listed by list-systems, right? | 03:25 |
| olofk | wallento: Haven't thought of that | 03:33 |
| olofk | Don't really use list-systems myself to be honest :) | 03:33 |
| wallento | yeah, I just discovered it yesterday ;) | 03:33 |
| wallento | while testing the naming | 03:33 |
| olofk | But 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 consume | 03:34 |
| wallento | yes, but it would be great to have a list of clear entry point, because fusesoc build <any core name> does not work | 03:35 |
| wallento | but agree, one file is much better | 03:35 |
| olofk | That 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 want | 03:35 |
| olofk | True. list-systems does have that benefit | 03:35 |
| wallento | we currently move the OpTiMSoC build to fusesoc | 03:36 |
| wallento | using the new naming | 03:36 |
| olofk | So, then yes, we should list the (build) targets in list-systems to keep backwards-compatiblity | 03:36 |
| olofk | Ah. Cool | 03:36 |
| olofk | I'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 file | 03:37 |
| wallento | you mean as a name? or dependency? | 03:38 |
| wallento | I 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 again | 03:39 |
| wallento | by the way: what is in core and system files thats not in IPXACT? | 03:39 |
| wallento | ah, shit, I found a critical thing now | 03:40 |
| olofk | The biggest item is dependencies, and that's something I really don't think we should put in the IP-XACT files, even as an extension | 03:40 |
| wallento | using ../verilog in a core file does not work.. | 03:40 |
| olofk | The other smaller things are scope and usage of filesets (although groups in IP-XACT might replace usage) | 03:40 |
| olofk | Some filetypes aren't defined in IP-XACT either, such as verilog 2005 and vhdl 2008 | 03:41 |
| wallento | okay, great, I was just wondering for librecores to use some kind of overlapping information to generate either | 03:41 |
| olofk | I think we should encourage people to use IP-XACT, and let the .core files handle the rest | 03:41 |
| wallento | regarding my issue: should I remove all relative path navigation from the path or is it just forbidden to have ../? | 03:41 |
| wallento | yes, that sounds like a good approach | 03:42 |
| olofk | Why doesn't that work? | 03:42 |
| wallento | because it clashes with other modules | 03:42 |
| wallento | in dst_dir | 03:42 |
| olofk | ah yes. The export function breaks | 03:42 |
| olofk | Of course you can't reference files outside of your core :) | 03:42 |
| wallento | in OpTiMSoC each core has the same structure: verilog/ and scripts/ip.core | 03:43 |
| olofk | aha | 03:43 |
| wallento | okay, we will just move the core files up | 03:43 |
| olofk | Yes. 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 that | 03:43 |
| wallento | yes, makes sense | 03:44 |
| olofk | Fucking unbelievable. Two days after I downloaded Xilinx 2015.3 they released 2015.4. | 04:22 |
| olofk | Two days ago we decided to migrate to 2015.4 | 04:23 |
| olofk | Today the released 2016.1 | 04:23 |
| olofk | Another 6GB download ahead :) | 04:23 |
| olofk | This is weird. Vivado refuses to install since it says I'm on a 32-bit platform | 04:33 |
| olofk | Apparently it runs uname -i and expects to get "x86_64" | 04:33 |
| olofk | But on my machine that returns GenuineIntel, while uname -m returns x86_64 | 04:33 |
| olofk | How can this be? | 04:34 |
| olofk | ok, so on a ubuntu machine uname -i returns x86_64. This is weird | 04:40 |
| olofk | Trying 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 secs | 08:06 | |
| wallento | olofk: one concern I have regarding the dependencies on name only (*:*:name) | 08:54 |
| wallento | Shouldn't we force users to write proper files that avoid conflicts from the beginning? | 08:55 |
| wallento | especially if we integrate a librecores backend a ram named module may mean anything.. | 08:55 |
| wallento | or do you mean that if only a name is given it should be sufficient to write name instead of ::name, because thats the case already | 09:01 |
| olofk | wallento: 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 library | 11:02 |
| olofk | I'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 here | 11:03 |
| wallento | okay, the first is already an, it is backward compatible. I can add the second one, but we should probably throw a warning | 11:03 |
| wallento | yes, that would clash | 11:03 |
| olofk | ok | 11:03 |
| wallento | for the first we can index librecores.org, so it returns all .core files | 11:04 |
| wallento | but I would assume there are conflicts then | 11:04 |
| olofk | For 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 |
| wallento | I have two elf-loaders already ;) | 11:05 |
| olofk | haha | 11:05 |
| wallento | and I renamed optimsoc's wb_ram to sram some years back because of conflicts ;) | 11:05 |
| olofk | Maybe we could allow this relaxed matching only for local cores then | 11:05 |
| wallento | yes, that is something we can add | 11:05 |
| olofk | oh | 11:05 |
| wallento | so if it is local only, the user can leave out v and l, right? | 11:06 |
| wallento | so, 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 |
| wallento | but lets see where it gets us | 11:06 |
| olofk | But if there are several modules with the same name, this isn't supposed to work | 11:07 |
| olofk | We should get a warning or error then | 11:07 |
| wallento | yep, agreed | 11:07 |
| wallento | I will not add it today, but we should open an issue for this | 11:07 |
| wallento | its part of dependency resolution | 11:07 |
| wallento | there are other things like versioning too, I think | 11:07 |
| olofk | But 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 |
| olofk | Yeah. Versioning is important | 11:08 |
| wallento | I would also propose to think about something like a common function or module for generating path names | 11:08 |
| olofk | To 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 file | 11:09 |
| wallento | I have changed core.name to core.sanitized_name at many places now which all seem to do more or less the same | 11:09 |
| wallento | the stuff for the core files is completed | 11:09 |
| olofk | I saw that in your patches. Didn't really understand the reason for it. Can you explain | 11:09 |
| wallento | most of the tools hate colons in names | 11:09 |
| wallento | path names | 11:10 |
| olofk | Hmm.. I think I'm a bit off then. Where do we get colons in names? | 11:10 |
| wallento | so it converts vendor:library:name to vendor_library_name | 11:10 |
| wallento | because the core "name" is this triplet currently | 11:10 |
| wallento | I changed it initially to vendor/library/name | 11:11 |
| wallento | but then the whole stuff just blew up | 11:11 |
| olofk | ah ok. So it's used when creating the structure in the build tree | 11:11 |
| wallento | yep, its only about the output tree | 11:11 |
| olofk | Cool. Yeah. That's good | 11:11 |
| olofk | _ or - works for me | 11:11 |
| wallento | cool, at least for the moment this should be okay, of course everyone can construct a conflicting name, but I would not overengineer this for now | 11:12 |
| olofk | In theory we could get a clash though, but it's unklikely | 11:12 |
| olofk | :) | 11:12 |
| olofk | No problem changing that later on as you say | 11:12 |
| olofk | I still wonder if we should do something about the .system files first though | 11:15 |
| olofk | Maybe we can just require that the .system file has the same name as the .core file for now | 11:15 |
| olofk | And internally, we just append the stuff in .system to the .core file | 11:16 |
| olofk | Yeah, that could be a good intermediate step | 11:16 |
| olofk | It makes the migration path easier. We treat the stuff in .system as if it was just appended to the .core file | 11:17 |
| wallento | yes, thats a great idea | 11:26 |
| -!- dalias_ is now known as dalias | 11:41 | |
| wallento | olofk: hooray, OpTiMSoC verilated simulations work now with FuseSoC and the new naming scheme | 12:07 |
| wallento | https://github.com/optimsoc/sources/tree/fusesoc | 12:07 |
| olofk | wallento: Awesome! | 12:27 |
| wallento | philipp wrote most of the core files, I will forward ;) | 12:28 |
| olofk | Nah.. Take the credit yourself instead :) | 12:29 |
| olofk | wallento: I see that you carry an internal mor1kx in OpTiMSoC. Is it much different from upstream? | 12:52 |
| wallento | its like snapshots | 12:53 |
| wallento | some old stuff we want to get rid off | 12:53 |
| wallento | its historical | 12:53 |
| wallento | because I developed the multicore extensions there before merging | 12:53 |
| olofk | ah ok. I see | 12:53 |
| wallento | there 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 written | 12:54 |
| wallento | in 2009 :) | 12:54 |
| wallento | we are cleaning all this stuff up in the next | 12:54 |
| olofk | wallento: I'm moving forward with the .system file deprecation. A few problems remain, but it looks mostly good | 17:22 |
| olofk | andrzejr: I'm aware that I haven't pulled your providers yet. It's on my todo list still | 17:40 |
| -!- Netsplit *.net <-> *.split quits: kaaliakahn | 23:32 | |
| -!- Netsplit over, joins: kaaliakahn | 23:39 | |
| --- Log closed Fri Apr 15 00:00:22 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!