Thursday, 2019-03-21

*** tpb has joined #symbiflow00:00
*** futarisIRCcloud has joined #symbiflow00:12
*** citypw has joined #symbiflow03:17
*** OmniMancer has joined #symbiflow05:24
*** Bertl_oO is now known as Bertl_zZ05:39
*** citypw has quit IRC06:28
*** citypw has joined #symbiflow06:40
sf-slack1<mkurc> Have anyone tried to run the "graphics mode" in VPR ? I tried appending `--disp on` to VPR command line with no effect. It does not work with VPR from Conda neither it does with VPR built locally (even when I'm getting "EasyGL: graphics enabled" during compilation).09:42
*** citypw has quit IRC10:11
*** kraiskil has joined #symbiflow10:45
*** OmniMancer has quit IRC11:23
*** OmniMancer has joined #symbiflow11:25
*** OmniMancer has quit IRC11:40
*** Bertl_zZ is now known as Bertl11:47
*** OmniMancer1 has joined #symbiflow12:11
sf-slack1<mkurc> Never mind, i got it working. Needed to append `--disp on` to VPR args in `xc7/make/arch_define.cmake` file.12:30
sf-slack1<acomodi> litghost: I am merging the upstream VPR master with the current symbiflow master+wip status on a separate branch. I have noticed that there are some conflicts related with one of your commits on VPR upstream. My question is: which ones should we keep?
tpbTitle: Add metadata support to architecture and rr_graph XML. (#473) · verilog-to-routing/[email protected] · GitHub (at
sf-slack1<acomodi> litghost: for now I have kept all the upstream changes you have commited12:41
sf-slack1<tmichalak> Good time of day everyone. I have a question regarding Namelly, I want to focus on modifying the harness generation to output all bits outside of ROI and add them to the required_features. My question is, what is the difference between what should be and what we have now. The current create_design_json script already does add the features, from the input12:45
sf-slack1fasm, which are outside of the ROI to the required_features.12:45
*** kraiskil has quit IRC13:19
sf-slack1<acomodi> litghost: nevermind, I have missed your comment saying that metadata is already upstream. I will select the upstream then and discard the symbiflow changes during a conflict13:27
*** tux3_ has quit IRC13:59
*** tux3 has joined #symbiflow14:00
*** futarisIRCcloud has quit IRC14:31
sf-slack1<tmichalak> I am also looking into the RAMB36 support ( I guess, that basically the main effort here is to add the xml files, as done for RAMB18 in .15:02
tpbTitle: RAMB36 not implemented · Issue #438 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack1<acomodi> litghost: by using the upstream metadata PR now `ice40_hlc.cpp` and `fasm.cpp` have at compile time (mostly because there was a switch from pointer to non-pointer for `t_metadata_dict`)15:04
sf-slack1<acomodi> litghost: have *issues at compile time15:15
litghostAcomodi: delete hlc and use the fast from my pr15:17
litghosttmichalak: Correct15:19
*** OmniMancer1 has quit IRC15:19
litghosttmichalak: For, design_json should have all features outside of the ROI, rather than just the features inside the ROI frame usage15:20
tpbTitle: Issues · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghosttmichalak: If that is indeed what it does, then great15:23
sf-slack1<tmichalak> @litghost: did you assume that the required features were added manually to the design.json so far?15:25
litghosttmichalak: I believe I wrote the design json script to detect features that were outside of the ROI, but including the ROI's frame address.  Instead we should include all features outside the roi, period.  We should also generate an error if any unknown bits are detected, rather than just ones that lie inside the ROI15:26
sf-slack1<tmichalak> @litghost: yes, you are correct, we do check if the base address is in roi, so this should be a very small change15:33
sf-slack1<acomodi> all vpr strong tests passed after merged, I have deleted `hlc` folder and checked out `fasm` with your PR (fasm2 branch)15:37
sf-slack1<acomodi> I'll open a PR on symbi/vtr15:37
sf-slack1<mkurc> @litghost: I have a question regarding splitting a top level CLB into two identical SLICEs. When I do that I will have to rename all the wires that are related to the slice (and possibly pips). They are unique within a CLB and cannot stay unique if the new top-level SLICE tile is going to be universal. How will this affect FASM generation ?15:38
sf-slack1<mkurc> I will not be able to do the same trick as it is done now with writing correct fasm prefixes into pb_type definitions as there will be one pb_type per SLICE (universal)15:39
sf-slack1<mkurc> I guess I will have to add some kind of fasm translation stage before fasm2frames. Is it a desired approach ?15:40
sf-slack1<mkurc> Otherwise I do not see a way how we can have universal SLICE tiles without modifying the VPR code.15:40
litghostmkurc: There was never a need to rename any wires or split wires to handle the tile split.  There simply need to be a mapping between the VPR tile IPIN/OPINs and the prjxray site pins.15:45
litghostmkurc: At the root level, we can simply emit <tile>.<site> rather <tile>15:46
sf-slack1<mkurc> Ok, I'll look into how IPINs/OPINs are generated.15:52
sf-slack1<tmichalak> @litghost: so conceptually we need this kind of changes:
tpbTitle: add bits outside ROI to required features by tmichalak · Pull Request #736 · SymbiFlow/prjxray · GitHub (at
litghostIpins and opins correspond to the site rather than the tile15:55
litghostSo a universal slicel should work15:55
sf-slack1<acomodi> litghost: opened the PR. We do not care about the DCO error regarding the sign-offs right?16:00
tpbTitle: VTR: upstream merge by acomodi · Pull Request #30 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
litghostacomodi: Correct16:02
sf-slack1<acomodi> I have noticed that `Generating rr_graph_xc7a50t_test.rr_graph.real.xml` target is run always, even though nothing in the environment changes16:30
sf-slack1<mkurc> I have noticed that too. I guess that it is because of the `channels.db` being changed by multiple targets being run.16:31
litghostacomodi/mkurc: There are two channels.db files to handle that.  Sounds like a bug in the CMake dependency tree16:32
sf-slack1<acomodi> litghost, mkurc: it is worth investigating because build times are increased by a non-negligible amount, I'll look into that16:40
litghostacomodi: Totally.  It should be a straight forward CMake fix16:40
litghostacomodi: If not let me know16:40
*** Bertl is now known as Bertl_oO16:59
*** kraiskil has joined #symbiflow17:05
sf-slack1<acomodi> litghost: murax has issues with routing. It is taking many iterations to solve `Overused RR Nodes` (bouncing between 3, 2 and 1 for the last 30 iterations)17:06
litghostacomodi: :(  Might be another regression.  Double check that VPR before the PR is good for sanity purposes.17:07
litghostacomodi: Then bisect17:07
sf-slack1<acomodi> litghost: Sure, I'll try to disable `round_robin_prepacking` and check if that is the issue17:10
*** kraiskil has quit IRC17:11
sf-slack1<acomodi> litghost: here's the fix for the channel.db deps
tpbTitle: xc7: fix channel.db dependencies by acomodi · Pull Request #487 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostacomodi: Of course, perfect, thanks17:13
*** kraiskil has joined #symbiflow17:24
*** kraiskil has quit IRC17:41
*** kraiskil has joined #symbiflow19:01
sf-slack1<acomodi> litghost: I can confirm that `round_robin_prepacking` introduces an issue with routing that needs a huge number of iterations without finding a feasible solution19:15
sf-slack1<acomodi> Without rr it takes 15 iterations19:16
sf-slack1<acomodi> I should investigate on this, because it seems pretty odd that rr introduces this behavior which wasn't there before the upstream merge19:18
sf-slack1<acomodi> Anyways, tomorrow I'll test murax on HW and check if it correctly works19:19
litghostacomodi: Sounds good.  I recommend you file an issue on one of our trackers and report your findings and progress.19:38
*** futarisIRCcloud has joined #symbiflow21:24
tpbTitle: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at
*** kraiskil has quit IRC22:34
*** kraiskil has joined #symbiflow22:50

Generated by 2.13.1 by Marius Gedminas - find it at!