kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 245 seconds]
citypw has joined #symbiflow
Bertl is now known as Bertl_zZ
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 246 seconds]
kraiskil has joined #symbiflow
citypw has quit [Quit: Leaving]
aurodas has joined #symbiflow
<aurodas> hello!
<aurodas> I am a student looking to participate in GSoC this year
<aurodas> I have worked with FPGAs and I know Verilog & SystemVerilog
<aurodas> are there other project ideas possible for GSoC other than the issues list specified?
kraiskil has quit [Ping timeout: 250 seconds]
kraiskil has joined #symbiflow
OmniMancer has joined #symbiflow
kraiskil has quit [Ping timeout: 255 seconds]
Bertl_zZ is now known as Bertl
OmniMancer has quit [Quit: Leaving.]
citypw has joined #symbiflow
sxpert has quit [Ping timeout: 245 seconds]
aurodas has quit [Quit: Page closed]
sxpert has joined #symbiflow
<litghost> aurodas: What is your interest area? We have work at all levels of the tool chain
citypw has quit [Ping timeout: 245 seconds]
<sf-slack1> <acomodi> modes issue update: I am currently dealing with the creation of a VPR test to target the changes of https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/29. 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 architecture
<tpb> Title: Sign in to GitHub · GitHub (at github.com)
<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 one
<litghost> acomodi: Yes, that was the idea.
<sf-slack1> <acomodi> here's the commit relative to the initial work on the regression test https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/29/commits/3ec13e42bd492e1d8d12ab0a14f6a5b66b2a9e33
<tpb> Title: WIP: Differing modes between lib_nets fix by acomodi · Pull Request #29 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)
<litghost> acomodi: But if I understood your earlier message, that test case does not fail in the absence of #29?
<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 #29
<litghost> acomodi: Can you start with the xc7 arch, and whittle it down?
<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`
<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 arch
<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?
<litghost> acomodi: I would start with your blif, whittle the arch down, then whittle the blif down
<sf-slack1> <acomodi> litghost: sounds good, thanks
<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 https://github.com/SymbiFlow/prjxray/issues/714 . I added a waiver to the DRC rules that caused the 056-pip-rem fuzzer to fail and opened a PR https://github.com/SymbiFlow/prjxray/pull/728 just
<sf-slack1> for the purpose of running the CI. The first CI run passed for this PR, but this might just be pure luck.
<tpb> Title: Make the pip fuzzers able to handle DRC check failures · Issue #714 · SymbiFlow/prjxray · GitHub (at github.com)
<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?
<litghost> tmichalak: Ya
<sf-slack1> <tmichalak> @litghost: is that a label that anyone can add or is it restricted to some users?
<litghost> tmichalak: Unclear, but I expect anyone can use it
<sf-slack1> <tmichalak> @mithro: I also wanted to look into https://github.com/SymbiFlow/prjxray/issues/713, 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?
<tpb> Title: Issues · SymbiFlow/prjxray · GitHub (at github.com)
<sf-slack1> <tmichalak> @mithro: do you think that PR https://github.com/SymbiFlow/prjxray/pull/712 can be merged? I get to see a lot of these "jobserver unavailable" warning messages in the logs.
<tpb> Title: Fix makefiles to pass -j option by tmichalak · Pull Request #712 · SymbiFlow/prjxray · GitHub (at github.com)
vzcx has joined #symbiflow
vzcx has quit [Remote host closed the connection]
<elms> litghost: 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 graph.py?
<elms> If so I think we need to build out testing and docstrings significantly in the new (2) approach.
<litghost> elms: 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.
<litghost> elms: 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.
<litghost> elms: In general, graph2 and channel2 are dramatic simplifications of graph and channel, burning away the unneeded parts.
<litghost> elms: I do not recommend we rebuild the complexity present in the old libraries, that complexity was never required
<elms> litghost: 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?
<tpb> Title: symbiflow-arch-defs/graph.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> elms: All 300 lines of that code is not required at all
<tpb> Title: symbiflow-arch-defs/graph2.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> elms: All that code is doing is providing IPIN/OPIN to node lookup
<litghost> elms: Which is pretty much all that is required.
<elms> ok. I'm in the ice40 routing import to remove HLC anyway. I'll look at reducing the some of that at the same time.
<elms> litghost: 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.
<litghost> elms: I don't disagree, I just want to be clear that graph vs graph2 is orthogal to using the database
<elms> litsghost: yep, understood
<litghost> elms: I think the simplest way to understand the difference between graph and graph2 is the number of methods.
<litghost> graph.py => 88 methods
<litghost> channel2.py => 3 methods
<litghost> graph2.py => 12 methods
<litghost> channel.py => 43 methods
<litghost> elms: And I would claim the graph2/channel2 provides what is required to support routing import (as demostrated by the xc7 routing import).
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow