Thursday, 2019-05-09

*** tpb has joined #vtr-dev00:00
acomodilitghost, kem_: So, it has been tricky to debug even with bisect. I still do not have the braking commit, but I found out that it is a packing related issue11:36
acomodilitghost, kem_: Apparently we have a non-deterministic situation now11:46
tpbTitle: Sign in to GitHub · GitHub (at
mithrokem_: We haven't organized a time to do the reformatting yet14:59
litghostkem_: Got a small PR
tpbTitle: Add useful error message on CHAN PTC check. by litghost · Pull Request #562 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostkem_: Improves an error message in check rr graph16:47
litghostkem_: Can you explain
tpbTitle: vtr-verilog-to-routing/check_rr_graph.cpp at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostkem_: I can understand requiring non-configurable un-buffered edges to be symmetric19:01
litghostkem_: But I have a case where I'm using pass-transistors, which are configurable/unbuffered19:01
litghostkem_: I don't see a reasonable to support the reverse direction if only the forward direction can be used19:01
litghostkem_: So why is that check there for configurable/non-buffering?19:02
kem_litghost: The RR graph always uses directed edges, and so a pass transistor (which can be driven from either direction) is represented by two directed edges (one in each direction). If there was only one of those edges then the router would never explore using the wire in the opposite direction.19:51
litghostkem_: I never want the router to explore the wire in the opposite direction19:52
kem_litghost: I think that check is a sanity check that the edge was used in the correct direction19:52
kem_litghost: If that is the case you probably want to use a mux style switch instead19:52
litghostkem_: But a mux isolates!  I want the non-isolating property for timing modelling19:53
kem_litghost: OK, but usually the directionality follows from isolation property (i.e. non-isolating switches are bi-directional)19:54
kem_litghost: Most modern FPGA architecture use direction/isolating switches, which correspond to a single forward edge in the RR graph19:55
litghostkem_: It is true that a pass transistor supports both directions, but from a routing graph standpoint it will result in a node that has 1 outbound node (the pass transistor), and 2 inbound nodes (a mux and the pass transistor in question)19:55
litghostkem_: In my case, the pass transistor is soley a timing model artificat19:56
litghostkem_: Consider the following model:19:58
litghostOPIN --(mux edge)--> CHAN (R != 0, C != 0) --(pass transistor edge)-->  CHAN (R != 0, C != 0) -(fanout to multiple mux edges with internal capacitance)->19:58
litghostkem_: In this case the two CHAN's and the pass transistor cannot be merged because the internal capacitance of the fanout makes the RC delay non-static19:58
litghostkem_: But adding a reverse edge between those two CHAN nodes is nonsense19:59
kem_litghost: The convention generally followed by VPR is to not model things at that level of detail and to abstract those into the switch type19:59
litghostkem_: Not possible in this case19:59
litghostkem_: I guess a short might work here, under the assumption that shorts support non-zero R, or that all pass transistors have R = 020:00
kem_litghost: They may, you'd have to check whether we explicitly forbid it or not20:01
litghostkem_: I changed the error to a warning, and nothing exploded, but that doesn't mean the timing model was being done correctly20:01
kem_litghost: The directed pass transistor which you are using to model the internal capacitance is not a case we've tried to model in VPR so far, hence why it probably flags the error check. Temporarily downgrading it to a warning seems reasonable.20:02
litghostkem_: I assume there is a way to get all net delays?20:02
litghostkem_: E.g. routing only20:02
kem_litghost: We have a summer student looking at adding C_internal to the switch properties which would allow this to be modelled without having to add extra nodes to the RR graph20:03
litghostkem_: The case I showed above still requires that pass transistor node even with the C_internal support20:03
litghost*pass transistor edge20:03
kem_litghost: Why? It would seem like a mux edge with Cinternal would be enough?20:04
litghostkem_: Because the RC loading from the first CHAN should see the entire downstream cap20:04
litghostkem_: Let me write out the equation, maybe it will make more sense, or you can point out my error20:05
kem_litghost: Sure, maybe add them to the discussion on the Cinternal bug.20:05
litghostkem_: I don't think any of this discussion is directly relevant to the Cinternal bug, but I could be wrong20:06
litghostkem_: Let's start with the RC delay of first mux edge20:07
litghostRC = R * (CHAN1 C + pass transistor C  + CHAN2 C + sum(Cinternal active fanout muxes)20:07
litghostkem_: Do you agree that is correct?20:07
kem_litghost: Yep, but you just have the delay calculators do the capacitance summing for you20:09
litghostkem_: Oh of course, I'm trying to prove why the pass transistor cannot be converted into a mux without changing the underlying model20:10
litghostkem_: I spent a couple hours yesterday trying to collapse that first mux, chan and pass transistor, and wasn't able to20:10
litghostkem_: If that first node has R = 0 and C = 0, everything get's simple20:11
litghostkem_: However my models aren't that simple20:11

Generated by 2.13.1 by Marius Gedminas - find it at!