Monday, 2019-03-18

*** tpb has joined #symbiflow00:00
*** kraiskil has joined #symbiflow00:34
*** kraiskil has quit IRC00:39
*** citypw has joined #symbiflow03:11
*** Bertl is now known as Bertl_zZ04:11
*** kraiskil has joined #symbiflow07:45
*** kraiskil has quit IRC07:49
*** kraiskil has joined #symbiflow08:01
*** citypw has quit IRC09:15
*** aurodas has joined #symbiflow09:45
aurodasI am a student looking to participate in GSoC this year09:46
aurodasI have worked with FPGAs and I know Verilog & SystemVerilog09:47
aurodasare there other project ideas possible for GSoC other than the issues list specified?09:48
*** kraiskil has quit IRC10:01
*** kraiskil has joined #symbiflow10:17
*** OmniMancer has joined #symbiflow11:08
*** kraiskil has quit IRC12:08
*** Bertl_zZ is now known as Bertl14:01
*** OmniMancer has quit IRC14:26
*** citypw has joined #symbiflow14:33
*** sxpert has quit IRC15:23
*** aurodas has quit IRC15:23
*** sxpert has joined #symbiflow15:26
litghostaurodas: What is your interest area?  We have work at all levels of the tool chain15:28
*** citypw has quit IRC15:41
sf-slack1<acomodi> modes issue update: I am currently dealing with the creation of a VPR test to target the changes of I have added a regression test in `vtr/vtr_flow/tasks/regression_tests/vtr_reg_strong/` alongside with a small test architecture in `vtr/vtr_flow/arch/` and the .eblif file. I still couldn't get to reproduce the issue with the small test architecture16:58
tpbTitle: Sign in to GitHub · GitHub (at
sf-slack1<acomodi> litghost: this was the idea, right? I will push the test in a bit, which is not yet working as expected though, but it can give an idea if the direction is the correct one17:00
litghostacomodi: Yes, that was the idea.17:00
sf-slack1<acomodi> here's the commit relative to the initial work on the regression test
tpbTitle: WIP: Differing modes between lib_nets fix by acomodi · Pull Request #29 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
litghostacomodi: But if I understood your earlier message, that test case does not fail in the absence of #29?17:14
sf-slack1<acomodi> No, the test case is still conceptually wrong, I am trying to simulate the situation for which I have a mode conflict that should be solved with #2917:15
litghostacomodi: Can you start with the xc7 arch, and whittle it down?17:17
sf-slack1<acomodi> litghost: I still have to modify the test architecture to get to a situation for which there are a series of siblings pb_types which have the same parent, but they are using different `modes`17:17
sf-slack1<acomodi> litghost: Sounds good, I have been trying to generate an architecture from scratch, but probably the best way is actually to shrink the xc7 arch17:18
sf-slack1<acomodi> litghost: The only thing then would be to produce a .blif file compatible with the architecture, which should be manually produced, right?17:19
litghostacomodi: I would start with your blif, whittle the arch down, then whittle the blif down17:20
sf-slack1<acomodi> litghost: sounds good, thanks17:21
sf-slack1<tmichalak> update on the stabilization of the CI runs: they are still giving me a headache as they are not reproducible locally. However, I try to take one step at a time and solve other issues that are related to this topic, such as . I added a waiver to the DRC rules that caused the 056-pip-rem fuzzer to fail and opened a PR just18:53
sf-slack1for the purpose of running the CI. The first CI run passed for this PR, but this might just be pure luck.18:53
tpbTitle: Make the pip fuzzers able to handle DRC check failures · Issue #714 · SymbiFlow/prjxray · GitHub (at
sf-slack1<tmichalak> @litghost: I saw you and mithro use a kokoro:force-run tag here and there. Is that a better way of rerunning the CI build that pushing a bogus commit to the repo?18:55
litghosttmichalak: Ya18:56
sf-slack1<tmichalak> @litghost: is that a label that anyone can add or is it restricted to some users?18:57
litghosttmichalak: Unclear, but I expect anyone can use it19:01
sf-slack1<tmichalak> @mithro: I also wanted to look into, however not all items on the todo list are clear to me. Actually, I left my comments in the ticket. Could you elaborate on those points?19:02
tpbTitle: Issues · SymbiFlow/prjxray · GitHub (at
sf-slack1<tmichalak> @mithro: do you think that PR can be merged? I get to see a lot of these "jobserver unavailable" warning messages in the logs.19:04
tpbTitle: Fix makefiles to pass -j option by tmichalak · Pull Request #712 · SymbiFlow/prjxray · GitHub (at
*** vzcx has joined #symbiflow20:31
*** vzcx has quit IRC21:15
elmslitghost: What do you think the right path is for graph/graph2 channel/channel2 stuff? Do you is would be best to just rewrite the ice40 routing import using graph2 (and possibly  the database cache)? then we can just surplant
elmsIf so I think we need to build out testing and docstrings significantly in the new (2) approach.22:46
litghostelms: I don't think a move to include the database cache is required.  The observation I made during the xc7 routing import was that most of graph/channel were a distraction from what was actually required for routing import.  The only thing that is really necessarily is channel formation, IPIN/OPIN lookup and serialization.  Everything else was/is superfluous.22:48
litghostelms: In terms of what I think should be done for the ice40 routing import, I think the first step is to refactor the import to avoid the majority of either graph or graph2, as most of it's functionality is purely about the routing graph.  If we wanted to refactor that to use the sqlite format, okay, but I don't think that is strictly speaking required.22:49
litghostelms: In general, graph2 and channel2 are dramatic simplifications of graph and channel, burning away the unneeded parts.22:49
litghostelms: I do not recommend we rebuild the complexity present in the old libraries, that complexity was never required22:50
elmslitghost: not sure I follow. I'll have to look closer at graph2 to see what graph has and you are saying are not required. Do you recall examples of some unneeded things?22:51
litghostelms: Concrete example, modeling of BlockTypes.
tpbTitle: symbiflow-arch-defs/ at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostelms: All 300 lines of that code is not required at all22:52
litghostelms: The entire portion of graph2 related to BlockTypes and the grid can be found and
tpbTitle: symbiflow-arch-defs/ at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostelms: All that code is doing is providing IPIN/OPIN to node lookup22:55
litghostelms: Which is pretty much all that is required.22:55
elmsok. I'm in the ice40 routing import to remove HLC anyway. I'll look at reducing the some of that at the same time.22:56
elmslitghost: I think using the databasecache may be good just to keep structure similar across archs. It will hopefully make it easier for new archs if we can keep them closer  than we have in the past.22:58
litghostelms: I don't disagree, I just want to be clear that graph vs graph2 is orthogal to using the database22:58
elmslitsghost: yep, understood22:59
litghostelms: I think the simplest way to understand the difference between graph and graph2 is the number of methods.23:05 => 88 methods23:05 => 43 methods23:05 => 12 methods23:05 => 3 methods23:05
litghostelms: And I would claim the graph2/channel2 provides what is required to support routing import (as demostrated by the xc7 routing import).23:06

Generated by 2.13.1 by Marius Gedminas - find it at!