Wednesday, 2018-08-01

*** tpb has joined #vtr-dev00:00
*** digshadow has quit IRC04:51
*** digshadow has joined #vtr-dev05:11
*** digshadow has quit IRC06:25
*** digshadow has joined #vtr-dev06:30
*** digshadow has quit IRC12:53
*** digshadow has joined #vtr-dev13:02
kem_mithro: a) If you're getting mismatches with the .net file, I'd suggest looking through the code that writes out the .net file. The relevant part seems to be:
tpbTitle: vtr-verilog-to-routing/output_clustering.cpp at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
kem_mithro: b) The current master code supports a single linear chain, where each pack pattern edge has only a fan-out of 116:06
kem_mithro: If the carry chain matches that, then things should work (which is what the VTR architectures do)16:07
kem_mithro: If I recall correctly the issue on the ice40 is that there is more flexibility on the carry-chain (i.e. muxes to/from general inputs) which confuse the packer's router since it doesn't understand that some of the connections have more limited flexibility outside the block (i.e. Fc=0 for the block-level CIN/COUT pins)16:09
kem_mithro: Now it is possible to tweak the intra-block RR graph to make the packer router 'understand' those constraints, and I did put that code into the generalized_pack_patterns branch16:10
kem_mithro: But that uncovers another problem, it is now possible for the input BLIF file to have a connection, for example on ICE40, where a LUT has the carry signal as an input. This is legal in the architecture (since it has the mux), but would require multi-fanout pack patterns.16:13
kem_mithro: Otherwise the packer may put the LUT in a different logic block, and there would be no way to route the carry signal to that LUT (since it's part of the dedicated carry chain).16:14
kem_mithro: The rest of the work on  the generalized_pack_patterns branch was trying to add support for multi-fanout pack patterns, which turns out to be much more involved...16:15
mithroFor (a) I've been looking at the cluster output code but I'm having trouble understanding exactly how the internal interconnections (IE the bits inside an <interconnect> block) are marked as being used16:18
kem_mithro: I'm not sure I quite follow then? There should be edges in the intra-block routing corresponding to the switches, and if those edges are used by a net that should mean that the corresponding switch is turned on?16:22
mithroI'll be at a computer shortly and then I'll link you16:26
mithroOkay, at a computer now16:31
mithroSo, the t_pb_route object contains the internal routing that is being used inside a tile?16:33
mithroThe t_pb_route on the t_pb object is a flat array -- t_pb_route is an array of size [t_pb->pb_graph_node->total_pb_pins] ?16:35
mithroThe t_pb_route objects have a driver_pin_id (which is an int) and a list of sink_pb_pin_ids which is a vector of ints and a pb_graph_pin16:36
mithroThe pb_graph_pin is a pointer to a part of the netlist16:38
mithroHowever I think the part I don't quite understand is that a t_pb is a hierarchy of the pb_type objects -- how do I convert between t_pb objects and the pin_ids?16:40
mithroThe t_pb_route objects don't have any references to t_pb objects16:42
mithrokem_: The conversion between the ints for the pin_ids and the t_pb objects I think is what is causing me issues16:46
kem_mithro: Yeah that stuff pretty confusing.16:51
kem_mithro: I have to re-figure it out each time I go into the cluster routing... which I try to avoid doing :)16:52
mithrokem_: Good to know it isn't just me :-P16:53
kem_mithro: I think I wrapped that up in a look-up class:
tpbTitle: vtr-verilog-to-routing/vpr_utils.h at cd6d0ac2ea931485a6c64101416d12c77c682c40 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithrokem_: Is there an example of using that somewhere?16:54
kem_mithro: Let me find one...16:54
tpbTitle: vtr-verilog-to-routing/clb_delay_calc.inl at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
kem_mithro: It's used in a couple of different places, but that's one I'm somewhat more familiar with16:57
kem_mithro: It's the delay calculation code which traces the intra-block routing adding up the annotated delays for timing analysis16:58
mithrokem_: Okay, I think I see how to walk the t_pb_route and get the pins -- the question is how do these pins relate to the <interconnect> definitions?17:01
mithrokem_: I think this diagram explains the carry chain issue ->
tpbTitle: Verilog to Routing (VtR / VPR) - Carry Chain + Pack Patterns - Google Drawings (at
kem_mithro: Yep, from the edge you should be able to get back to the interconnect17:05
kem_mithro: Your diagrams make sense. The blue connections are problematic because they have fanout > 1 which isn't supported in master17:07
mithrokem_: I added a bigger example of closer to the real situation17:19
mithrokem_: The part in purple is the really hard to deal with bit -- it's where the only way to get the the carry output onto the fabric is via using the tile *above* the current one17:22
mithrokem_: Which leads me to another question, I want to create the architectures in this diagram -- how do I make odin-ii produce a blif file for this architecture?17:27
kem_mithro: So the top two figures basically show what VPR currently supports, a single linear carry chain with fanout = 1 on all edges17:29
kem_mithro:  The middle two show a carry chain with fanout > 1 (not supported on master)17:29
kem_mithro: The bottom expands the fanout > 1 case across blocks17:30
mithrokem_: I was thinking I could convert the middle type into the top type at the mapping phase in yosys17:30
kem_mithro: Possibly, I guess it depends what the blue connections connect too, and whether they use a dedicated connection internal to the block, or can reach the inter-block routing17:33
kem_mithro: Can you clarify what the pink/purple arrow in the bottom figure means?17:33
mithrokem_: The pathway the signal needs to take to get onto the fabric17:34
kem_mithro: OK that makes sense. So the signal path is through the carry block, across the carry block and into a LUT.17:35
kem_mithro: There is probably one more possibility not shown in the diagram. The start/end blocks are marked as CARRYs (dashed). They could actually be any primitive type.17:36
kem_mithro: That is you could, for example, have a LUT driving the carry chains CIN or sinking the COUT17:39
kem_mithro: Essentially, what is needed is support for pack patterns which are trees, instead of strict chains17:47
kem_mithro: The existing code is tightly coupled to the chain concept and doesn't do a very good job of isolating the idea of the pattern, from the detection and implementation code17:48
kem_mithro: In the generalized_pack_patterns branch I tried to isolate things better17:48
kem_mithro: The first thing it does is build a model of the pack pattern17:50
kem_ICE40 style pack pattern graph
kem_mithro: In the image it's assuming a block with only two adders17:52
kem_mithro: '*' indicates a wildcard block (could be another adder, or LUT/FF etc)17:52
kem_mithro: and the dashed edges indicate that matching that connection is optional17:53
kem_mithro: It then goes through and finds sub-graphs of the netlist which match the pattern17:55
mithrokem_: Okay, I'm afraid you lost me with that graph diagram17:56
kem_mithro: Essentially the graph describes a pattern which is then matched against the input netlist17:57
kem_mithro: So #0 can be any block (wildcard)17:58
kem_mithro: So #1 can optionally be driven by that block to #1's cin pin17:58
kem_mithro: A candidate adder would become part of the pattern if it's cin was driven by #1's cout17:59
kem_mithro: and so on17:59
mithrokem_: You mean the candidate block would become part of a molecule because of the pack pattern?17:59
kem_mithro: Correct18:00
kem_mithro: The matching code will greedily try to find the largest matches in the netlist18:02
mithrokem_: So looking at my diagrams -- on Figure - X18:04
kem_mithro: So if an adder had matched as #1, and it had a .names/LUT with a connection from #1's cout to the LUTs 4th input that LUT would be added to the molecule as #418:04
mithroDo I need to mark the connections that go from BLOCK->CARRY with a pack_pattern property?18:04
kem_mithro: It depends18:05
*** litghost has quit IRC18:05
*** litghost has joined #vtr-dev18:05
kem_mithro: If the signals from the BLOCKs can reach the inter-block routing fabric, no18:05
kem_mithro: Effectively, if there are ways to get the BLOCK -> CARRY and CARRY -> BLOCK signals from the general fabric (which depends on the architecture) then, no18:07
kem_mithro: The packer would detect and place the CARRY blocks as a chain18:07
kem_mithro: And the other blocks would be packed as normal (since their signals can get to/from the inter-block routing)18:08
mithrokem_: The orange arrows can't reach the fabric18:08
kem_mithro: Then they need to be part of the pack pattern18:08
kem_mithro: Otherwise the packer could put them in different blocks which would be unroutable18:09
mithrokem_: So Figure - D1 explains this?18:22
mithrokem_: Basically any time a path can't be connected to the general fabric, you need a pack_pattern?18:23
mithrokem_: And a special case is when the connection is to a pin on the tile which can't be connected to the fabric?18:24
kem_mithro: Effectively yes, I believe that is the case.18:24
kem_mithro: The packer otherwise assumes that it can get a primitives signals to/from the inter-block routing. If it can't then it needs to be told to keep them together.18:25
mithrokem_: And I think that explains the error messages that I've been getting about the fact that an pin of an internal block is unable to be routed to a top level pin...18:26
kem_mithro: That would make sense18:26
kem_mithro: It is probably possible to infer some of the pack patterns just from the architecture description, but no one has done that yet. And there are probably subtle/complex cases where you still want to manually define them18:27
mithrokem_: It actually there already seems to be some type inferring in the code? There is a talk about "forced connections" a bit?18:27
kem_mithro: If I recall correctly that is something different, more related to the idea of an optional connection on a pattern18:30
mithrokem_: How does it know when a pack pattern is optional verse required?18:30
kem_mithro: I think the code in master treats chains as optional and everything as as required18:30
kem_mithro: The optional is because you may have a chain in the netlist with fewer bits (e.g. 6 bits) but your architecture has more bits per logic block (e.g. 10 bits). Hence extending the chain is optional.18:31
mithrokem_: That requires you to be able to get a signal in/out of the carry chain CO/CIN?18:32
kem_mithro: Potentially, often the chain's COUT is unused and left disconnected18:34
mithrokem_: Ahh18:35
mithrokem_: So, it feels like the quickest solution to make things work might be to convert Figure - B2 style carry output to Figure - A2 style in tech mapping in Yosys18:36
kem_mithro: Yes that seems like the quickest way18:38
mithrokem_: Then we can loop back to fixing up support in VTR18:38
kem_mithro: Makes sense18:38
mithrokem_: BTW Do you have a way of taking the .net output and converting it into something more "human readable" ?18:39
kem_mithro: Nope :(18:41
mithrokem_: At some point I'll get frustrated enough and write a little Python script :-P18:41
mithrokem_: Okay, I'm going to head to lunch and then give another try at the t_pb_route and interconnect stuff afterwards19:03

Generated by 2.13.1 by Marius Gedminas - find it at!