<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).
citypw has quit [Ping timeout: 252 seconds]
kraiskil has joined #symbiflow
OmniMancer has quit [Ping timeout: 245 seconds]
OmniMancer has joined #symbiflow
OmniMancer has quit [Ping timeout: 245 seconds]
Bertl_zZ is now known as Bertl
OmniMancer1 has joined #symbiflow
<sf-slack1>
<mkurc> Never mind, i got it working. Needed to append `--disp on` to VPR args in `xc7/make/arch_define.cmake` file.
<tpb>
Title: Add metadata support to architecture and rr_graph XML. (#473) · verilog-to-routing/vtr-verilog-to-routing@dd861ea · GitHub (at github.com)
<sf-slack1>
<acomodi> litghost: for now I have kept all the upstream changes you have commited
<sf-slack1>
<tmichalak> Good time of day everyone. I have a question regarding https://github.com/SymbiFlow/symbiflow-arch-defs/issues/418. 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 input
<sf-slack1>
fasm, which are outside of the ROI to the required_features.
kraiskil has quit [Ping timeout: 245 seconds]
<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 conflict
tux3_ has quit [Ping timeout: 250 seconds]
tux3 has joined #symbiflow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<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`)
<sf-slack1>
<acomodi> litghost: have *issues at compile time
<litghost>
Acomodi: delete hlc and use the fast from my pr
<litghost>
tmichalak: If that is indeed what it does, then great
<sf-slack1>
<tmichalak> @litghost: did you assume that the required features were added manually to the design.json so far?
<litghost>
tmichalak: 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 ROI
<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 change
<sf-slack1>
<acomodi> all vpr strong tests passed after merged, I have deleted `hlc` folder and checked out `fasm` with your PR (fasm2 branch)
<sf-slack1>
<acomodi> I'll open a PR on symbi/vtr
<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 ?
<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)
<sf-slack1>
<mkurc> I guess I will have to add some kind of fasm translation stage before fasm2frames. Is it a desired approach ?
<sf-slack1>
<mkurc> Otherwise I do not see a way how we can have universal SLICE tiles without modifying the VPR code.
<litghost>
mkurc: 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.
<litghost>
mkurc: At the root level, we can simply emit <tile>.<site> rather <tile>
<sf-slack1>
<mkurc> Ok, I'll look into how IPINs/OPINs are generated.
<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 changes
<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.
<litghost>
acomodi/mkurc: There are two channels.db files to handle that. Sounds like a bug in the CMake dependency tree
<sf-slack1>
<acomodi> litghost, mkurc: it is worth investigating because build times are increased by a non-negligible amount, I'll look into that
<litghost>
acomodi: Totally. It should be a straight forward CMake fix
<litghost>
acomodi: If not let me know
Bertl is now known as Bertl_oO
kraiskil has joined #symbiflow
<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)
<litghost>
acomodi: :( Might be another regression. Double check that VPR before the PR is good for sanity purposes.
<litghost>
acomodi: Then bisect
<sf-slack1>
<acomodi> litghost: Sure, I'll try to disable `round_robin_prepacking` and check if that is the issue
<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 solution
<litghost>
Huh
<sf-slack1>
<acomodi> Without rr it takes 15 iterations
<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 merge
<sf-slack1>
<acomodi> Anyways, tomorrow I'll test murax on HW and check if it correctly works
<litghost>
acomodi: Sounds good. I recommend you file an issue on one of our trackers and report your findings and progress.