Thursday, 2019-05-02

*** tpb has joined #vtr-dev00:00
*** pointfree has quit IRC01:27
*** pointfree has joined #vtr-dev01:30
*** pointfree has quit IRC01:40
*** pointfree has joined #vtr-dev01:56
litghostkem_: If you get a chance, take a look at
tpbTitle: Non-uniform pin direction connectivity · Issue #553 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostkem_: I think I know how to fix the relevant issue, but I would apprecate your thoughts before I start modifying VPR16:38
*** acomodi has joined #vtr-dev16:48
*** acomodi has quit IRC18:58
kem_litghost: I took a quick read through the issue20:25
kem_litghost: It sounds like the pin feasibility thing is a real issue which should be fixed20: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 issues20: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
litghostkem_: Is it legal to be missing rr graph IPIN or OPIN nodes that corripsond to pin locations?20:33
litghostkem_: I bet it might cause the rendering to exploded20:33
litghostkem_: If we can just omit unused IPIN/OPIN nodes, that would work nicely, but I think it probably is violating some assumptions20:34
kem_litghost: I was thinking from the router's point of view, it should be fine if the dangling IPIN/OPIN are swept20:37
kem_litghost: Its very possible that the graphics may not like it20:38
litghostkem_: Agreed20:38
litghostkem_: 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_INVALID20:39
litghostkem_: * E_DETAILED_ROUTE_FOR_EACH_ATOM,20:39
litghostkem_: When I start the cluster with E_DETAILED_ROUTE_FOR_EACH_ATOM instead of E_DETAILED_ROUTE_AT_END_ONLY it packs succesfully20:40
litghostkem_: When it starts with E_DETAILED_ROUTE_AT_END_ONLY, it fails, then falls back to E_DETAILED_ROUTE_FOR_EACH_ATOM, which then fails20:40
litghostkem_: My best guess is some stale data is left around between clustering attempts20:40
litghostkem_: Any ideas of where to look?20:41
litghostkem_: The approach I'm taking is converting everything that is immutable to have correct "const" tagging, and then looking closely at whatever is left20:41
kem_litghost: I'm not sure off the top of my head20:42
kem_litghost: The const tagging approach seems reasonable20:42
litghostkem_: 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_ATOM20:43
litghostkem_: 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 it20:43
litghostkem_: And the fact that starting with E_DETAILED_ROUTE_FOR_EACH_ATOM works tells me something about the switch must be carrying over20: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
litghostkem_: Agreed.   ROUTE_AT_END_ONLY should be a fast path20:45
litghostkem_: Might actually be worth making a test specifically about that, but that would require a big refactoring of the cluster20:46
litghostkem_: Then again the clusterer needs a refactoring anyways :)20:46
hackerfooIs there a good way to represent chained muxes while letting the router control them?20:48
hackerfooThis 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) < >20:49
hackerfooIf not, I'd like to add support at some point.20:50
*** vup has joined #vtr-dev21:14

Generated by 2.13.1 by Marius Gedminas - find it at!