| *** tpb has joined #vtr-dev | 00:00 | |
| acomodi | litghost, 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 issue | 11:36 |
|---|---|---|
| acomodi | litghost, kem_: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/700. Apparently we have a non-deterministic situation now | 11:46 |
| tpb | Title: Sign in to GitHub · GitHub (at github.com) | 11:46 |
| mithro | kem_: We haven't organized a time to do the reformatting yet | 14:59 |
| litghost | kem_: Got a small PR https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/562 | 16:47 |
| tpb | Title: Add useful error message on CHAN PTC check. by litghost · Pull Request #562 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 16:47 |
| litghost | kem_: Improves an error message in check rr graph | 16:47 |
| litghost | kem_: Can you explain https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/vpr/src/route/check_rr_graph.cpp#L520 | 19:00 |
| tpb | Title: vtr-verilog-to-routing/check_rr_graph.cpp at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 19:00 |
| litghost | kem_: I can understand requiring non-configurable un-buffered edges to be symmetric | 19:01 |
| litghost | kem_: But I have a case where I'm using pass-transistors, which are configurable/unbuffered | 19:01 |
| litghost | kem_: I don't see a reasonable to support the reverse direction if only the forward direction can be used | 19:01 |
| litghost | kem_: 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 |
| litghost | kem_: I never want the router to explore the wire in the opposite direction | 19:52 |
| kem_ | litghost: I think that check is a sanity check that the edge was used in the correct direction | 19:52 |
| kem_ | litghost: If that is the case you probably want to use a mux style switch instead | 19:52 |
| litghost | kem_: But a mux isolates! I want the non-isolating property for timing modelling | 19: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 graph | 19:55 |
| litghost | kem_: 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 |
| litghost | kem_: In my case, the pass transistor is soley a timing model artificat | 19:56 |
| litghost | kem_: Consider the following model: | 19:58 |
| litghost | OPIN --(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 |
| litghost | kem_: 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-static | 19:58 |
| litghost | kem_: But adding a reverse edge between those two CHAN nodes is nonsense | 19: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 type | 19:59 |
| litghost | kem_: Not possible in this case | 19:59 |
| litghost | kem_: I guess a short might work here, under the assumption that shorts support non-zero R, or that all pass transistors have R = 0 | 20:00 |
| kem_ | litghost: They may, you'd have to check whether we explicitly forbid it or not | 20:01 |
| litghost | kem_: I changed the error to a warning, and nothing exploded, but that doesn't mean the timing model was being done correctly | 20: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 |
| litghost | kem_: I assume there is a way to get all net delays? | 20:02 |
| litghost | kem_: E.g. routing only | 20: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 graph | 20:03 |
| litghost | kem_: The case I showed above still requires that pass transistor node even with the C_internal support | 20:03 |
| litghost | *pass transistor edge | 20:03 |
| kem_ | litghost: Why? It would seem like a mux edge with Cinternal would be enough? | 20:04 |
| litghost | kem_: Because the RC loading from the first CHAN should see the entire downstream cap | 20:04 |
| litghost | kem_: Let me write out the equation, maybe it will make more sense, or you can point out my error | 20:05 |
| kem_ | litghost: Sure, maybe add them to the discussion on the Cinternal bug. | 20:05 |
| litghost | kem_: I don't think any of this discussion is directly relevant to the Cinternal bug, but I could be wrong | 20:06 |
| litghost | kem_: Let's start with the RC delay of first mux edge | 20:07 |
| litghost | RC = R * (CHAN1 C + pass transistor C + CHAN2 C + sum(Cinternal active fanout muxes) | 20:07 |
| litghost | kem_: Do you agree that is correct? | 20:07 |
| kem_ | litghost: Yep, but you just have the delay calculators do the capacitance summing for you | 20:09 |
| litghost | kem_: Oh of course, I'm trying to prove why the pass transistor cannot be converted into a mux without changing the underlying model | 20:10 |
| litghost | kem_: I spent a couple hours yesterday trying to collapse that first mux, chan and pass transistor, and wasn't able to | 20:10 |
| litghost | kem_: If that first node has R = 0 and C = 0, everything get's simple | 20:11 |
| litghost | kem_: However my models aren't that simple | 20:11 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!