Wednesday, 2019-04-10

*** tpb has joined #vtr-dev00:00
*** awygle_ has quit IRC09:16
*** awygle has joined #vtr-dev09:16
*** awygle has quit IRC09:22
*** awygle has joined #vtr-dev09:23
litghostkem_: Is there a way to describe in a pb_type a 1 input 1 output mux that fans out to >1 blackboxes?22:54
litghostkem_: I think all 3 interconnect descriptions reduce to N muxes to each black box, rather than 1 mux which then fans out22:55
mithrolitghost: Take a look at "option 2" ->
tpbTitle: Best way to express "routing BELs" in vpr · Issue #284 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostmithro: You have the fanout backwards23:11
litghostmithro: So that won't work23:11
tpbTitle: Snippet | IRCCloud (at
litghostYa, you didn't read the question.  This about fanout AFTER the mux, e.g the mux output signal goes to multiple black boxes23:16
litghostThat example isn't fanout at all23:16
mithrolitghost: That has a MUX on a single input which it then fans out the value to multiple outputs?23:17
litghostmithro: But there is only a fan out of 123:17
litghostmithro: I'm saying say the mux chooses A5Q, then connect A5Q to 5 black boxes23:18
litghostmithro: E.g. fanout23:18
mithrolitghost: That is exactly what the xml I pasted above does....23:19
litghostmithro: Each connection is modelled as a mux, there is only 1 mux23:20
mithrolitghost: My example only has a single mux23:20
litghostmithro: A <direct> is actually a configurable signal.  I'm saying that the fanout is a net, e.g. a short23:20
litghostmithro: direct's do not model fanout, they model switches23:20
litghostmithro: VPR can choose to "connect" only the direct's that it wants too23:21
mithroThat doesn't seem right to me23:22
tpbTitle: vtr-verilog-to-routing/pb_type_graph.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at
litghostDIRECT_INTERC and MUX_INTERC literally use the same code to wire themselves23:26
litghostI guess that might be pins only :/23:27
litghostmithro: Ya, I just ran a test23:33
litghostmithro: direct's are consider configurable by VPR23:33
litghostmithro: It's possible that a "short" type is required to model what I want to represent, we'll see what kem_ says23:34
litghostmithro: Basically want we want to <direct input="a" output="b"> <short input="b" output="c"> <short input="b" output="d">, if  a signal appears on b, it will be sent to "c" and "d"23:36
litghostmithro: Right now VPR will happly pack a "d" == OPEN with a "c" == "net"23:36
mithroSeems like it would need to be fixed at ?23:38
tpbTitle: vtr-verilog-to-routing/cluster_router.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at
mithrolitghost: Maybe turn on PRINT_INTRA_LB_ROUTE define?23:39
litghostmithro: Is that an echo file, or #define only?23:39
mithro#define only it seems23:39
tpbTitle: vtr-verilog-to-routing/cluster_router.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at
tpbTitle: vtr-verilog-to-routing/cluster_router.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at
litghostmithro: That is only printed on routing failure, I'm having a case where a routing conflict was not detected23:41
litghostmithro: To be honest, I wasn't sure if VPR treated an "open" black box port as a don't care, but I don't think that is what is happening23:41

Generated by 2.13.1 by Marius Gedminas - find it at!