IRC logs for #openrisc Friday, 2016-04-15

--- Log opened Fri Apr 15 00:00:22 2016
olofkwallento: Was this supposed to be in the patch?
wallentoolofk: oh, shit, sorry, no02:59
wallentothat was in a long git add -p session02:59
wallentoI will send an updated one02:59
wallentoolofk: fixed it and rebased05:55
olofkwallento: Cool. I'll hope to work a bit on this over the weekend06:25
wallentogreat, it seems I am done with the naming for now06:28
wallentoverilator works06:28
wallentoand I will test verilator today06:28
olofkwallento: I pushed a patch yesterday that probably requires some changes in your vivado backend06:36
olofkSorry. Forgot to tell you06:36
wallentoOkay, I will check06:36
olofkCheck the changes in quartus and ise06:36
wallentoyep, will do, thanks06:37
olofk's just that I'm using FileList instead of PathList in, so all file lists will be a list of File instead of a list of str06:37
wallentoah, I see06:38
wallentoyes, will update the vivado PR06:38
wallentoolofk: not needed, because I already used filesections in vivado08:25
wallentothere are no special files in the backend section08:25
wallentobut they are supplied as filesets with file_type=xdc08:26
olofkwallento: Ah. Nice!08:37
-!- Netsplit *.net <-> *.split quits: wallento, julzmb, clopez_, robtaylor, simoncook11:26
-!- wallento_ is now known as wallento11:26
-!- Netsplit over, joins: robtaylor11:30
-!- Netsplit *.net <-> *.split quits: Amadiro12:13
-!- Netsplit over, joins: Amadiro12:19
-!- Netsplit *.net <-> *.split quits: mwfc, Amadiro, rohitksingh13:27
-!- Netsplit *.net <-> *.split quits: julzmb13:27
-!- Netsplit *.net <-> *.split quits: wallento, sandeepkr13:28
-!- Netsplit *.net <-> *.split quits: kaaliakahn, aburgess, heroux13:28
-!- wallento_ is now known as wallento13:28
-!- Netsplit over, joins: rohitksingh13:38
olofkwallento: Are you happy with the vivado backend so I can start testing and reviewing it?14:38
olofkandrzejr: I'm (finally) looking at your provider patches and going to try them out with a few cores of my own14:58
olofkI don't like this part in the tcl script -> set_property part xc7a100tcsg324-1 [current_project]14:59
olofkWould like to think if we can provide a way to not hardcode the device here14:59
olofkNot sure we can do that actually though14:59
olofkhmm... the device is already specified in the xci file, so we can't really target different devices anyway15:02
olofkCrappy Xilinx IP15:02
olofkBut I think we could probably generate the tcl file actually. So instead of specifying a tcl file, we can have options for target language and part15:04
olofkOTOH, a tcl file gives us more freedom to do other stuff if that is needed15:05
wallentoolofk: yes, no further changes15:05
olofkwallento: Cool. I'll do that when I have looked at the provider patches15:05
wallentothe tcl files are minimal for vivado15:06
wallentobecause it tracks dependencies on its own15:06
wallentoyou could run some command that build the IP15:06
olofkwallento: That's good. I think we should leave as much as possible to the user to support a wider range of flows15:06
wallentobut vivado handles this pretty good15:06
olofkFuseSoC is supposed to get out of the way when it can :)15:06
wallentoeven does it in multiple jobs15:06
wallentothe next days I will have a look of merging the parts with xsim too15:07
wallentoso maybe you want to wait for this15:07
wallentobut for synthesis I am happy for now15:07
olofkwallento: Wait with the vivado stuff or the provider stuff?15:07
wallentowith vivado15:08
wallentoI did not look at the provider so far15:08
wallentothe provider generates the IP, right?15:08
wallentoto provide the output files to other flows15:08
olofkvivado is pretty integrated, but I think we should keep the synth and sim flows separated for now15:08
olofkYep, that's correct15:08
wallentoyes, that is good15:09
wallentoI will prepare the readthedocs patch also soon15:09
olofkandrzejr: I think we could create a tcl file that sets some variables (xci_file and core_name perhaps?) and prepend that to the script file. Then your tcl file would look like this instead15:10
olofkBut this could be done later on15:11
olofkwallento: Nice! Every piece of documentation is welcome15:11
olofkhmm.. I wonder if we can read the part from the xci file15:21
andrzejrolofk, I've basically copied configuration files "as is". Each core generator is different in some way and it would be difficult to generalize it.15:29
andrzejrunless you want plugins like "coregen-mig" etc.15:30
olofkandrzejr: No, you're right, I want something generic15:31
olofkFuck it. It works, and you can just set stuff in the tcl file, so I'll pull it :)15:32
olofkoh.. but one thing. We don't want to copy all files in the directory. Only the ones we specify in xci_file and script_file15:33
olofkI had a dir with lots of xci files. It copied all of them and then complained that there were multiple xci files in the same dir15:34
olofkShould I just update your patch?15:34
andrzejrThis was needed for MIG generator. Xilinx coregen was not happy without some extra files, even though they were not referenced by anything.15:36
andrzejrnot sure about the logicore, I only used it for a relatively simple core:15:40
olofkandrzejr: I think we should instead reference all needed files15:41
olofkah yes. mig needs the .prj file15:41
olofkI wonder if we could just use filesets in the provider section. That would make it more uniform15:53
olofkAnother option would be to just add an extra_files parameter15:53
wallentoisn't xci plain IPXACT?16:28
olofkyes and no :)16:36
olofkIt's a IP-XACT design file, not a component file16:37
olofkWhen you run it through the Vivado IP generator you get HDL files (or a netlist) and an IP-XACT component file16:37
olofkBut unfortunately the files are often so full of vendorextensions so that they are hardly usable outside of Vivado16:38
olofkPeter Gielda from AntMicro has apparently managed to open up some Xilinx IP-XACT file in Kactus, changed stuff, saved it and still been able to read it in Vivado, so they aren't breaking the standard completely though16:39
olofkSo the xci file isn't that usable outside of Vivado16:41
olofkBut the generated xml (IP-XACT component file) could potentially be useful for FuseSoC to pick up the filesets from16:42
olofkNow the next problem is that there are four revisions of IP-XACT (1.4, 1.5, 2009 and 2014) and tools often just support one or a few of them16:43
olofkCool! I managed to get FuseSoC to read the filesets from Vivado-generated IP-XACT file16:53
olofkWith a few hacks :)16:53
olofk1. FuseSoC complains if it can't find the XML file, but the file isn't created until the provider runs. This should be fixed so that the provider runs first of all16:54
olofkAnd my ugly hack to detect the IP-XACT version didn't work for this file. Need to find a better ugly hack. If I hardcoded to 2009 it works16:55
olofkSo once that works, we don't need to list all the HDL files in the .core file with a logicore provider. Only need to reference the IP-XACT component file16:56
olofkLife's good! :)16:56
olofkAnd I need to sleep. More investigation tomorrow16:56
olofkandrzejr: I think we could just go with a extra_files parameter to list the other files we need in the logicore provider instead of copying everything16:57
olofkIf that is fixed, I'm happy to pull that one16:57
olofkwallento: Does the vivado backend detect xci files from dependencies? (Haven't checked)16:58
wallentoolofk: yes17:37
wallentoany file with usage = vivado and file_type = xci17:38
wallentoactually I use it in submodules17:38
wallentobecause you cannot have multiple xci files in one output folder17:38
jumbois there any reasonably priced, typically recommended FPGA board I should get for just trying out OpenRISC and playing around with it some? I'd like VGA output20:56
--- Log closed Sat Apr 16 00:00:23 2016

Generated by 2.15.2 by Marius Gedminas - find it at!