02:42 <hackerfoo> I rebased add_io_for_x1y0, and fixed some problems in prjxray_create_edges.py, and now VPR seems to say it can't route anything to anything.

02:43 <hackerfoo> Or at least there are probably thousands of lines like:

02:43 <hackerfoo> Cannot route from SYN-VCC.VCC[0] (RR node: 0 type: SOURCE location: (79,130) class: 0) to BLK-TL-SLICEL.B2[0] (RR node: 5818 type: SINK location: (80,140) class: 8) -- no possible path

13:47 <sf-slack> <mkurc> I think I have found an issue with chained PIPs that cannot be activated separately in both prjxray and symbiflow. I've created a document describing the issue and my proposed solution. I'd like to have some feedback about it.

13:47 <sf-slack> <mkurc> https://docs.google.com/document/d/1q_4uxiSmHn4t9UmOfuWBLyesxZZOdEa2vyfbqPoKtf4

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

15:10 <litghost> mkurc: In general those kind of chained pips don't need isolation, as we can just treat one of the pips as a ppips, and leave the feature with the other pip

15:11 <litghost> mkurc: Also, if a pip isn't making a choice, it general has no bits at all

15:15 <sf-slack> <mkurc> @litghost: So eg. a fuzzer would need to know which pips are "grouped" and try to fuzz those groups together? Then the same information would need to be available to fasm2bels?

15:16 <litghost> no, fasm2bels walks through no-decision edges like this

15:17 <litghost> If there is only one edge leaving an output site pin (or edge coming to a input site pin), it always takes the edge

15:17 <litghost> It is only in places where a decision is required that fasm2bels consults the configuration of the pips

15:18 <litghost> In the particular example above, the feature might be wrong, and might need to be lumped with an IN_USE feature

15:20 <sf-slack> <mkurc> But I've observed the following: there are PLL inputs (all but clocks) which are connected to the tile outputs through non-pseudo pips. And there is no other way for those signals. And I had to manually activate those pips in fasm2bels to make it see connections.

15:20 <sf-slack> <mkurc> Since we cannot isolate activation of those pips in the fuzzer, probably bits activating them are inside the PLL's IN_USE feature.

15:21 <sf-slack> <mkurc> So even that there is no other way I had to make them explicitly enabled.

15:21 <sf-slack> <mkurc> But that's another story. In this case we can treat them as pseudo pips.

15:23 <litghost> In that case, if we know a sink (input site pin) is connected, and there is only one path from the interconnect switch box to the PLL, we should be able to make the route

15:45 <litghost> mkurc: Ah, you might need to update https://github.com/SymbiFlow/prjxray/tree/master/fuzzers/071-ppips to emit the ppip files for the new tiles

15:45 <tpb> Title: prjxray/fuzzers/071-ppips at master · SymbiFlow/prjxray · GitHub (at github.com)

15:46 <litghost> mkurc: Ya, we need to emit the ppip files for the new tiles for https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/fasm2bels/make_routes.py#L21 to reach the fabric

15:47 <tpb> Title: symbiflow-arch-defs/make_routes.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

16:14 <litghost> hackerfoo: Likely failure modes are either that the constant network didn't get connected or something broke in the lookahead (e.g. NaN propigation). For the first, https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/utils/rr_graph_walk can be used to verify that the graph actually has the connectivity. If that passes, route_diag with sink debugging turned on can be used to identify where in the route the

16:14 <litghost> router got lost

16:14 <tpb> Title: symbiflow-arch-defs/utils/rr_graph_walk at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

16:15 <sf-slack> <mkurc> @litghost Thanks, I'll try tomorrow with updated 071-ppips

16:15 <hackerfoo> litghost: Thanks

16:20 <litghost> hackerfoo: If you want a quick spot check, check the lookahead log (vpr_stdout.log in build/xc7/archs/artix7/devices/) and check if each segment found at least one instance of the segment

16:21 <litghost> hackerfoo: A warning is generated if it doesn't

16:22 <litghost> hackerfoo: Warning will be "Segment %s(%d) found no start_node_in"

16:38 <hackerfoo> litghost: There's 20 of those warnings. They look familiar.

16:39 <hackerfoo> Probably because of the blacklist.

16:39 <litghost> hackerfoo: How would the blacklist cause segments to disappear?

16:40 <litghost> hackerfoo: Anyways, those warnings from the lookahead generation are almost certainly the problem, now the question is why

16:40 <litghost> hackerfoo: Did you shift the grid at all?

16:40 <hackerfoo> No

16:40 <litghost> hackerfoo: Ah, I know what the problem is. You are using the lower right rather than upper left CMT

16:41 <litghost> hackerfoo: And right now the lookahead search locations are fixed, because I just hacked it up

16:41 <litghost> hackerfoo: For now, update the search locations with the x/y transpose

16:41 <litghost> hackerfoo: We really should replace the segment search algorithm with something smarter

16:43 <litghost> hackerfoo: For background, the lookahead needs to sample the segments to produce the segment delays. Currently the search grid locations are fixed (which is wrong in the long term). The correct solution is to sample the grid in a generic fashion (e.g. pick a segment from the upper left, upper right, etc).

16:44 <hackerfoo> Which file/script do I need to modify?

16:44 <litghost> hackerfoo: For now, update https://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/vpr/src/route/connection_box_lookahead_map.cpp#L332 to the transpose of the upper left CMT to the lower right CMT

16:44 <tpb> Title: vtr-verilog-to-routing/connection_box_lookahead_map.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

16:44 <hackerfoo> Okay, thanks.

16:45 <litghost> hackerfoo: I'm writing up a bug explaining the current state, and what the long term fix is

16:49 <litghost> hackerfoo: https://github.com/SymbiFlow/vtr-verilog-to-routing/issues/281

16:49 <tpb> Title: Connection box lookahead segment search is fixed · Issue #281 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

16:50 <hackerfoo> How would swapping x & y help? Wouldn't that give invalid coordinates? Maybe offset y and flip x around the center?

16:51 <litghost> hackerfoo: Not swapping, shifting

16:51 <hackerfoo> Okay

16:51 <litghost> hackerfoo: Basically you moved the routing region from x1 -> x2 and y1 -> y2, in theory a straight forward translation of the sampling coordinates should work

16:52 <litghost> hackerfoo: Ah, I used the word transpose, but translate is probably a better description

16:52 <hackerfoo> Isn't X mirrored?

16:53 <litghost> hackerfoo: I'd have to check. However most of the segments that failed to be sampled are very common (e.g. general interconnect), so the precise locations are not sensitive

16:54 <litghost> hackerfoo: The one's that are most important to mirror are the coordinates that HCLK network start and the BRAM address network (BRAM_CASCADE)

16:54 <litghost> hackerfoo: If you only care about getting back to a working buttons test, the HCLK and BRAM sampling is unimportant

16:57 <litghost> hackerfoo: I have a couple fixs to prjxray_create_edges.py to finish debugging, and then I can switch gears and revisit generalizing the lookahead sampling. If you have some ideas for generalizing the lookahead sampling, you could also take the bug.

16:59 <hackerfoo> Okay. I'm looking at it

17:22 <sf-slack> <mkurc> CMT tiles L and R are different, at least those with PLLs

17:25 <litghost> mkurc: Sorry, what's the context?

17:26 <sf-slack> <mkurc> Sorry, I meant the attempt to mirror X coordinate to switch between clock regions

17:29 <litghost> mkurc: Ah sure. The current segment definitions do not include anything special for the PLL, so it doesn't require sampling. That will likely need to change, but for now is not an issue

17:29 <sf-slack> <mkurc> Ok

17:30 <litghost> mkurc: I think fixing https://github.com/SymbiFlow/vtr-verilog-to-routing/issues/281 with a generalized sampling strategy rather than continuing to add fixed locations is probably the path forward. If we find that the generalize algorithm is problematic, then the sampling coordinates should be moved to a command line argument so we can adjust the sampling locations for different grids

17:30 <tpb> Title: Map/connection box lookahead segment search is fixed · Issue #281 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

22:20 <hackerfoo> How do I get a revision for a Conda PACKAGE_SPEC? I'm looking for a working version of VPR to modify, and symbiflow/vtr/master+wip doesn't seem to work.

22:22 <litghost> hackerfoo: Sorry, can you clarify?

22:23 <litghost> hackerfoo: What are you trying to do?

22:23 <litghost> hackerfoo: Conda package -> git revision?

22:24 <hackerfoo> I wanted to "fix" the bug we talked about earlier today.

22:24 <hackerfoo> But I get this with master+wip and master+wip~: ERROR: Error 1: /home/dusty/src/symbiflow-arch-defs/build/xc7/archs/artix7/devices/xc7a50t-basys3-roi-virt/arch.timing.xml:418 Failed to find port named 'A' on block 'BLK-TL-SLICEL'

22:25 <litghost> hackerfoo: Ya, I asked acomodi to fix that, but he hasn't finished his PR yet (see https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1017)

22:25 <tpb> Title: updated symbiflow archs to integrate the newly added tiles tag in VTR by acomodi · Pull Request #1017 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

22:25 <litghost> hackerfoo: Anyways, the git revision is embedded in the conda package spec

22:26 <hackerfoo> Okay. I guess I'll work on the pad -> VPR coordinates stuff then.

22:27 <hackerfoo> Using the hex string as a commit doesn't seem to work.

22:28 <hackerfoo> Oh well. I've lost enough time on this. I'll just work on other stuff.

22:30 <hackerfoo> I also can't seem to convince vtr's build system to produce an executable that uses multiple cores, despite having the dependencies and VPR_NUM_WORKERS.

22:30 <hackerfoo> litghost: Thanks

22:31 <litghost> hackerfoo: Um, you mean "make -j$(nproc)"?

22:31 <litghost> hackerfoo: VPR_NUM_WORKERS affects the execution of VPR itself, not the build system?

22:31 <hackerfoo> No, I mean when running VPR.

22:31 <hackerfoo> make -j`nproc` works fine.

22:32 <litghost> hackerfoo: Ya, some parts of VPR just don't use multiple threads

22:33 <hackerfoo> So much idling. It's frustrating.

22:34 <hackerfoo> The conda version seemed to run faster, but I haven't looked into it further.

22:35 <litghost> hackerfoo: When you build locally, does CMake report finding tbb library (intel's thread building blocks)?

22:37 <litghost> hackerfoo: I believe https://github.com/SymbiFlow/vtr-verilog-to-routing/commit/c478c2b00131b6f6a4a20d34a43f08f2e95d3336 is the commit used for https://travis-ci.com/SymbiFlow/conda-packages/jobs/237422548, unclear what is happening with the "git describe" output

22:37 <tpb> Title: Travis CI - Test and Deploy with Confidence (at travis-ci.com)

22:37 <hackerfoo> I didn't check this time, but I did install that dependency last time I ran into it. Maybe it can't find it again for some reason.

22:41 <litghost> hackerfoo: The string in the conda PACKAGE_SPEC is the hash, but because of mithro's octupus merge strategy, it might not have gotten retrieved from github

22:41 <litghost> hackerfoo: I had to run "git fetch origin c478c2b00" to actually pull the revision down

22:42 <litghost> hackerfoo: Replace "origin" with whatever remote points to https://github.com/SymbiFlow/vtr-verilog-to-routing

22:42 <tpb> Title: GitHub - SymbiFlow/vtr-verilog-to-routing: SymbiFlow WIP changes for Verilog to Routing -- Open Source CAD Flow for FPGA Research (at github.com)

22:45 <hackerfoo> Thanks