| *** tpb has joined #vtr-dev | 00:00 | |
| *** pointfree has quit IRC | 01:27 | |
| *** pointfree has joined #vtr-dev | 01:30 | |
| *** pointfree has quit IRC | 01:40 | |
| *** pointfree has joined #vtr-dev | 01:56 | |
| litghost | kem_: If you get a chance, take a look at https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/553 | 16:37 |
|---|---|---|
| tpb | Title: Non-uniform pin direction connectivity · Issue #553 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 16:37 |
| litghost | kem_: I think I know how to fix the relevant issue, but I would apprecate your thoughts before I start modifying VPR | 16:38 |
| *** acomodi has joined #vtr-dev | 16:48 | |
| *** acomodi has quit IRC | 18:58 | |
| kem_ | litghost: I took a quick read through the issue | 20:25 |
| kem_ | litghost: It sounds like the pin feasibility thing is a real issue which should be fixed | 20:25 |
| kem_ | litghost: The RR graph checks are just warnings that something is unusual with the RR graph. In this case, why would there be an IPIN/OPIN which doesn't go anywhere? | 20:26 |
| kem_ | litghost: I'm tempted to keep the warnings in there because they could flag real issues | 20:27 |
| kem_ | litghost: For your RR graph, couldn't you just run a pruning pass before VPR which would remove IPIN/OPINs which aren't connected to any CHANX/CHANY? I think that would eliminate the warning in VPR. | 20:28 |
| litghost | kem_: Is it legal to be missing rr graph IPIN or OPIN nodes that corripsond to pin locations? | 20:33 |
| litghost | kem_: I bet it might cause the rendering to exploded | 20:33 |
| litghost | explode* | 20:34 |
| litghost | kem_: If we can just omit unused IPIN/OPIN nodes, that would work nicely, but I think it probably is violating some assumptions | 20:34 |
| kem_ | litghost: I was thinking from the router's point of view, it should be fine if the dangling IPIN/OPIN are swept | 20:37 |
| kem_ | litghost: Its very possible that the graphics may not like it | 20:38 |
| litghost | kem_: Agreed | 20:38 |
| litghost | kem_: While I have you here, I'm tracking an issue where the cluster appears to be keeping stale data between E_DETAILED_ROUTE_AT_END_ONLY (which fails) and then proceeding into E_DETAILED_ROUTE_INVALID | 20:39 |
| litghost | kem_: * E_DETAILED_ROUTE_FOR_EACH_ATOM, | 20:39 |
| litghost | kem_: When I start the cluster with E_DETAILED_ROUTE_FOR_EACH_ATOM instead of E_DETAILED_ROUTE_AT_END_ONLY it packs succesfully | 20:40 |
| litghost | kem_: When it starts with E_DETAILED_ROUTE_AT_END_ONLY, it fails, then falls back to E_DETAILED_ROUTE_FOR_EACH_ATOM, which then fails | 20:40 |
| litghost | kem_: My best guess is some stale data is left around between clustering attempts | 20:40 |
| litghost | kem_: Any ideas of where to look? | 20:41 |
| litghost | kem_: The approach I'm taking is converting everything that is immutable to have correct "const" tagging, and then looking closely at whatever is left | 20:41 |
| kem_ | litghost: I'm not sure off the top of my head | 20:42 |
| kem_ | litghost: The const tagging approach seems reasonable | 20:42 |
| litghost | kem_: Okay, I'll keep digging. Because the cluster starting with E_DETAILED_ROUTE_FOR_EACH_ATOM works, there has to be a bug in the switch from E_DETAILED_ROUTE_AT_END_ONLY to E_DETAILED_ROUTE_FOR_EACH_ATOM | 20:43 |
| litghost | kem_: The failure I'm seeing is on the seed molecule, which fails, even though it is going into an empty cluster of a type that can accept it | 20:43 |
| litghost | kem_: And the fact that starting with E_DETAILED_ROUTE_FOR_EACH_ATOM works tells me something about the switch must be carrying over | 20:44 |
| kem_ | litghost: Yep I agree it should be consistent. I would expect if you did ROUTE_AT_END_ONLY followed by ROUTE_FOR_EACH_ATOM, it would produce the same result as only doing ROUTE_FOR_EACH_ATOM. | 20:45 |
| litghost | kem_: Agreed. ROUTE_AT_END_ONLY should be a fast path | 20:45 |
| litghost | kem_: Might actually be worth making a test specifically about that, but that would require a big refactoring of the cluster | 20:46 |
| litghost | kem_: Then again the clusterer needs a refactoring anyways :) | 20:46 |
| hackerfoo | Is there a good way to represent chained muxes while letting the router control them? | 20:48 |
| hackerfoo | This is what I have, but none of these are implementable currently: | 20:49 |
| * hackerfoo uploaded an image: Screenshot from 2019-05-02 11-14-47.png (96KB) < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/QVCWOFXygEzJOlTWtMYPCpNZ > | 20:49 | |
| hackerfoo | If not, I'd like to add support at some point. | 20:50 |
| *** vup has joined #vtr-dev | 21:14 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!