| *** tpb has joined #symbiflow | 00:00 | |
| *** freeemint has quit IRC | 00:21 | |
| *** freeemint has joined #symbiflow | 00:21 | |
| *** Vonter_ has joined #symbiflow | 00:35 | |
| *** Vonter has quit IRC | 00:36 | |
| *** freeemint has quit IRC | 02:04 | |
| 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:42 |
|---|---|---|
| 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 | 02:43 |
| *** citypw has joined #symbiflow | 02:49 | |
| *** proteusdude has quit IRC | 03:12 | |
| *** proteusguy has joined #symbiflow | 03:48 | |
| *** adjtm has quit IRC | 07:14 | |
| *** OmniMancer has joined #symbiflow | 07:23 | |
| *** adjtm has joined #symbiflow | 07:53 | |
| *** bjorkintosh has quit IRC | 08:03 | |
| *** Bertl is now known as Bertl_zZ | 08:54 | |
| *** freemint has joined #symbiflow | 11:42 | |
| *** adjtm has quit IRC | 11:44 | |
| *** freemint has quit IRC | 12:16 | |
| *** bjorkintosh has joined #symbiflow | 12:23 | |
| *** adjtm has joined #symbiflow | 12:35 | |
| *** freemint has joined #symbiflow | 13:25 | |
| *** freemint has joined #symbiflow | 13:26 | |
| 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) | 13:47 |
| *** freemint has quit IRC | 14:38 | |
| *** Bertl_zZ is now known as Bertl | 14:40 | |
| 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:10 |
| litghost | mkurc: Also, if a pip isn't making a choice, it general has no bits at all | 15:11 |
| 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:15 |
| litghost | no, fasm2bels walks through no-decision edges like this | 15:16 |
| 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:17 |
| litghost | In the particular example above, the feature might be wrong, and might need to be lumped with an IN_USE feature | 15:18 |
| 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:20 |
| 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:21 |
| 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:23 |
| 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:45 |
| 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) | 15:47 |
| *** freemint has joined #symbiflow | 15:49 | |
| *** freemint has quit IRC | 15:58 | |
| *** freemint has joined #symbiflow | 15:59 | |
| *** freemint has quit IRC | 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:14 |
| *** freemint has joined #symbiflow | 16:14 | |
| sf-slack | <mkurc> @litghost Thanks, I'll try tomorrow with updated 071-ppips | 16:15 |
| hackerfoo | litghost: Thanks | 16:15 |
| 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:20 |
| litghost | hackerfoo: A warning is generated if it doesn't | 16:21 |
| litghost | hackerfoo: Warning will be "Segment %s(%d) found no start_node_in" | 16:22 |
| *** citypw has quit IRC | 16:22 | |
| *** freemint has quit IRC | 16:22 | |
| *** adjtm has quit IRC | 16:34 | |
| hackerfoo | litghost: There's 20 of those warnings. They look familiar. | 16:38 |
| * hackerfoo sent a long message: < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/fEqtJbKgwPKyhbOUJwVqfNnz > | 16:38 | |
| hackerfoo | Probably because of the blacklist. | 16:39 |
| litghost | hackerfoo: How would the blacklist cause segments to disappear? | 16:39 |
| 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:40 |
| 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:41 |
| 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:43 |
| 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:44 |
| litghost | hackerfoo: I'm writing up a bug explaining the current state, and what the long term fix is | 16:45 |
| 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:49 |
| hackerfoo | How would swapping x & y help? Wouldn't that give invalid coordinates? Maybe offset y and flip x around the center? | 16:50 |
| 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:51 |
| litghost | hackerfoo: Ah, I used the word transpose, but translate is probably a better description | 16:52 |
| hackerfoo | Isn't X mirrored? | 16:52 |
| 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:53 |
| 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:54 |
| 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:57 |
| hackerfoo | Okay. I'm looking at it | 16:59 |
| *** adjtm has joined #symbiflow | 17:03 | |
| *** OmniMancer has quit IRC | 17:11 | |
| sf-slack | <mkurc> CMT tiles L and R are different, at least those with PLLs | 17:22 |
| litghost | mkurc: Sorry, what's the context? | 17:25 |
| sf-slack | <mkurc> Sorry, I meant the attempt to mirror X coordinate to switch between clock regions | 17:26 |
| 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:29 |
| 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) | 17:30 |
| *** freemint has joined #symbiflow | 17:31 | |
| *** freemint has quit IRC | 18:17 | |
| *** freemint has joined #symbiflow | 18:53 | |
| *** freemint has quit IRC | 18:57 | |
| *** Bertl is now known as Bertl_oO | 19:12 | |
| *** cyndis has quit IRC | 19:26 | |
| *** freemint has joined #symbiflow | 19:29 | |
| *** alexhw has quit IRC | 19:35 | |
| *** alexhw has joined #symbiflow | 19:36 | |
| *** alexhw has quit IRC | 19:38 | |
| *** cyndis has joined #symbiflow | 19:43 | |
| *** freemint has quit IRC | 19:56 | |
| *** freemint has joined #symbiflow | 19:56 | |
| *** jidaigeist has joined #symbiflow | 20:18 | |
| *** freemint has quit IRC | 20:28 | |
| *** freemint has joined #symbiflow | 20:46 | |
| *** freemint has quit IRC | 21:09 | |
| *** freemint has joined #symbiflow | 21:14 | |
| *** freemint has quit IRC | 21:26 | |
| *** freemint has joined #symbiflow | 21:40 | |
| *** jidaigeist has quit IRC | 21:42 | |
| *** freemint has quit IRC | 21:49 | |
| *** alexhw has joined #symbiflow | 22:04 | |
| *** freemint has joined #symbiflow | 22:18 | |
| 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:20 |
| litghost | hackerfoo: Sorry, can you clarify? | 22:22 |
| litghost | hackerfoo: What are you trying to do? | 22:23 |
| litghost | hackerfoo: Conda package -> git revision? | 22:23 |
| 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:24 |
| 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:25 |
| hackerfoo | Okay. I guess I'll work on the pad -> VPR coordinates stuff then. | 22:26 |
| hackerfoo | Using the hex string as a commit doesn't seem to work. | 22:27 |
| hackerfoo | Oh well. I've lost enough time on this. I'll just work on other stuff. | 22:28 |
| * litghost hackerfoo: The conda package for the current VPR version was built here: https://travis-ci.com/SymbiFlow/conda-packages/jobs/237422548 | 22:29 | |
| 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:30 |
| 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:31 |
| litghost | hackerfoo: Ya, some parts of VPR just don't use multiple threads | 22:32 |
| hackerfoo | So much idling. It's frustrating. | 22:33 |
| hackerfoo | The conda version seemed to run faster, but I haven't looked into it further. | 22:34 |
| litghost | hackerfoo: When you build locally, does CMake report finding tbb library (intel's thread building blocks)? | 22:35 |
| 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:37 |
| 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:41 |
| 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:42 |
| hackerfoo | Thanks | 22:45 |
| *** freemint has quit IRC | 22:47 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!