11:31 <sf-slack> <tmichalak> Hello everyone, I was looking into the last obstacle that keeps us from entirely getting rid of the harness design.bit in the symbiflow-arch-defs, namelly some bits missing in zynq7 (https://github.com/SymbiFlow/prjxray/issues/746). I posted my crosscheck in the issue. Seems that we are missing few bits for CLK_BUFG_REBUF, RIOB33 and RIOB33_SINGLE. Maybe we could change the harness design to use only the RIOB bits

11:31 <sf-slack> we already solved?

11:31 <tpb> Title: unknown bit in zynq7 harness · Issue #746 · SymbiFlow/prjxray · GitHub (at github.com)

11:33 <sf-slack> <tmichalak> There is also one bit that I haven't seen before, namely there is no segment in the tilegrid.json with this baseaddress that has more than 28 frames and the minor address in this case is 29

11:39 <sf-slack> <tmichalak> @litghost: About the GFAN fuzzer, I saw one commit of yours (https://github.com/SymbiFlow/prjxray/commit/3c764a65e14d34aca0821a75d64ef401fe5e8f71) which reverts the MAKETODO_FLAGS so that the 054-pip-fan-alt fuzzer only solves the FAN_ALT.GFANs. Before the revert it solved BYP_ALT.GFANs as well. Maybe this is a regression that is causing conflicts mithro spotted:

11:39 <sf-slack> https://github.com/SymbiFlow/prjxray/issues/567#issuecomment-472617151 ?

11:39 <tpb> Title: Revert 054 fuzzer. · SymbiFlow/prjxray@3c764a6 · GitHub (at github.com)

11:39 <tpb> Title: INT FAN_ALT[0-9].GFAN0 solutions are still unstable · Issue #567 · SymbiFlow/prjxray · GitHub (at github.com)

12:26 <sf-slack> <mkurc> I've added support for explicitly instantiated DRAMs to the `tests/9-scalable_proc` design. This will allow Symbiflow bitstreams to be processed by `fasm2bels` which currently has problems with BRAMs. https://github.com/SymbiFlow/symbiflow-arch-defs/pull/510

12:26 <tpb> Title: Selectable ROM implementation (BRAM or DRAM) for the "9-scalable_test" design by mkurc-ant · Pull Request #510 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

14:08 <sf-slack> <acomodi> litghost, mithro: I have started to deal with the equivalent tile type implementation in VPR. There still are some unclear parts which are probably pushing me in the wrong direction. First of all I need to analyze how the placer works and what information it gets from the packer to perform the task.

14:12 <litghost> acomodi: I strongly suggest you write up your plans e.g. light design. The you can share it with mithro, the vtr devs and myself

14:18 <sf-slack> <acomodi> litghost: Ok, I have started writing a doc, but I still need to understand how and what are the VPR parts that will be affected by this feature as currently there is no reasonable plan that I could write up

14:19 <litghost> acomodi: Sure. vtr-dev's (once it is not finals season) might be able to provide useful guidance

14:20 <sf-slack> <mkurc> @litghost: I added a section "Proposed algorithm" to the document describing the grid split. Could you look at it and tell whether this is a correct approach. I summed up all necessary steps there regardless of how they are to be implemented.

14:20 <sf-slack> <mkurc> https://docs.google.com/document/d/1xvoga0CCXdNYolZU7GukBtFu2eE2XGYs04d7aRW5dM0

14:20 <tpb> Title: Google Docs - create and edit documents online, for free. (at docs.google.com)

14:29 <litghost> mkurc: I've summarized which steps are unnecessary.

16:26 <sf-slack> <mkurc> @litghost: Thanks.

18:45 <dhiraj240> hello, i had commented on https://github.com/SymbiFlow/symbiflow-arch-defs/issues/14 and this is my PR https://github.com/SymbiFlow/symbiflow-arch-defs/pull/508

18:45 <tpb> Title: Make xml_deps.py satsify pep8 · Issue #14 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

18:46 <dhiraj240> I haven't got any reply, i apologize if i have committed something wrong from my part.

20:52 <elms> mitho: litghost: In the past we have used yapf exclusively. This is a formatter only. Do we also want a linter running on our python?

20:52 <litghost> elms: I use a linter personally. I don't think we want to fail CI on lint, I'd rather rely on unittests.

20:53 <litghost> elms: I currently use pyflakes

20:55 <elms> litghost: I know you have given me feedback on things a linter would catch. So if we are going to expect that we should integrate it as a pre-submit step.

20:55 <elms> mithro: ^^ apparently I can't type your nick correctly

20:58 <litghost> elms: Example? Are thinking of naming convention errors?

20:59 <elms> litghost: yes and I think maybe unused imports

21:07 <mithro> elms: I'm always confused between the different internal Yosys names

21:09 <elms> +mithro I agree but not sure a manual list is maintainable. Maybe if descriptions are integrated with yosys. We can generate gate level schematics...or I have seen those at some point. Not sure if that would help elucidate though.

21:10 <mithro> elms: We could move to generating the Yosys output from the spreadsheet?

21:10 <elms> mithro: not sure what I was expecting the '+'

21:10 <elms> mithro: yeah maybe

21:11 <mithro> elms: You can export the spreadsheet as JSON pretty easily

21:11 <elms> mithro: probably worth mapping it out manually and then figuring a solution after the info is captured in once place.

21:12 <elms> mithro: Any thoughts on a using a python linter?

21:12 <mithro> elms: We should use yapf atleast...

21:13 <elms> So that formats and I have a local change to do that. But I was thinking a stronger linter to check for naming convention and unused variables/imports etc.

21:26 <mithro> elms: Yeah, pyflakes isn't bad

22:29 <mithro> elms: https://docs.google.com/document/d/1Pd_ygB0PvSq_gPEYIm8sJEF-mYY2nk3kLsazLVL21uw/edit

22:29 <tpb> Title: VtR Python API Design Doc - Google Docs (at docs.google.com)

22:46 <litghost> mithro: I was able to completely replicate the constant routing graph issue in the testarch, case for case. mux and short's both fail by default, and mux with high bb_factor succeeds, and short with high bb_factor fails

22:47 <litghost> mithro: Please review https://github.com/SymbiFlow/symbiflow-arch-defs/pull/515 , I have two PR's after it to get to the failing test case

22:47 <tpb> Title: Add 10x10 test arch and add const sources. by litghost · Pull Request #515 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

22:48 <mithro> litghost: so I think you have two bugs right?

22:49 <mithro> litghost: one for the short with high bb_factor failing

22:49 <litghost> mithro: E.g. change how we generate the constant grid and explore why VPR isn't finding a route?

22:50 <litghost> mithro: Ah sure, yes. The bb_factor should've helped the short case, but it didn't

22:50 <mithro> litghost: one for this not working with low bb_factor?

22:50 <mithro> Just waiting for a bus, will look at when on the bus

22:51 <litghost> mithro: Right. For now I'll keep them in one VPR issue and we can split them if the vtr-dev's want to

22:51 <litghost> mithro: I noticed we never connected the carry chain on the testarch, should I add a PR to do so?

22:52 <mithro> Well, the first issue is clearly a bug that should be fixed - the second requires a bunch more thought?

22:52 <litghost> mithro: It's not clear to me how much this represents a bug in how we generate the channels in the rrgraph versus a bug in the router

22:53 <litghost> mithro: I'd like the vtr-dev's to make a call around that

22:53 <mithro> The first issue about short verse mux is just a straight bug?

22:54 <mithro> They should behave the same in this case I'm pretty sure...

23:14 <litghost> mithro: For https://github.com/SymbiFlow/symbiflow-arch-defs/pull/515, do you need me to resolve the "too many variations in the test arch problem"? I'm not sure it has a good answer. I am planning to remove the old cgen stuff before merging

23:14 <mithro> litghost: No

23:14 <mithro> litghost: Removing the cgen stuff would probably be good

23:28 <mithro> litghost: I did a quick braindump of areas I was exploring with the testarch stuff -> https://docs.google.com/document/d/1_bXSSp5mYx43OT1MYO7K8ni-580mVRonOZmyKzji_2g/edit?usp=sharing

23:28 <tpb> Title: Test Architectures - Exploring Options - Google Docs (at docs.google.com)

23:38 <litghost> mithro: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/516 is the next PR for the constant routing stuff. The PR after this adds the global constant routing network

23:38 <tpb> Title: Convert testarch to graph2 library. by litghost · Pull Request #516 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

23:43 <mithro> litghost: If I understand the issue correctly, the problem is this -> https://docs.google.com/drawings/d/1P-_r5eF1d5eXGhshIwqI-EtSzA3WNNMAUDndIsNwi3M/edit

23:43 <tpb> Title: vpr bb_box issue with rr_graph - Google Drawings (at docs.google.com)

23:44 <litghost> mithro: Turns out u-turn is not required. The example in the test arch only has the cross-bar global network, and it is still enough to trigger the bug.

23:44 <litghost> mithro: Simply by virtue of putting the cross bar outside the ROI breaks the mux case

23:44 <litghost> mithro: In the short case, I need to look deeper, but I believe the router is taking the N rather than N-1 channel, and then stops

23:47 <mithro> litghost: That second section make sense?

23:48 <litghost> mithro: Correct

23:49 <litghost> mithro: The one thing to added is that there is another channel path that lies in between, but because the IPIN is only on the LEFT (or RIGHT), only one of the two channels is a "good" path

23:49 <litghost> mithro: I'm not totally sure, but I believe this channel that lies on the other side of the tile, but is not connected, is what is "breaking" the short case

23:58 <mithro> litghost: How does that look?

23:59 <litghost> mithro: Mostly correct, I replaced a short between the constant network and the IPIN at the sink

23:59 <litghost> mithro: Otherwise correct