Thursday, 2018-06-21

*** tpb has joined #vtr-dev00:00
*** ZipCPU has quit IRC05:51
*** ZipCPU has joined #vtr-dev06:24
mithrokem_: Was there a change to the placer recently? The GUI is now showing the placer rearranging the placement of tiles which I'm pretty sure I haven't seen before06:46
mithroIt's kind of pretty to watch :-P06:47
mithroelms: ^06:51
*** elms has quit IRC06:56
*** elms has joined #vtr-dev07:22
*** ZipCPU has quit IRC07:25
*** ZipCPU has joined #vtr-dev09:49
*** ZipCPU has quit IRC10:52
*** ZipCPU- has quit IRC12:07
*** ZipCPU has joined #vtr-dev12:23
kem_mithro: Nothing too recently. Perhaps the circuits you were testing on before were too small? The placer tends to find a 'good' solution for small circuits so fast that you may not have noticed. On larger circuits you do get to see the placement evolve over time. You can also click 'Toggle Nets' and watch how the placer unravels the rats nest of wires.13:05
*** digshadow has quit IRC17:02
mithrokem_: How do a I get the placer to understand "direct" connections? IE There are cases were the placer *must* put something in a certain location? Is this a pack_pattern thing?17:08
*** digshadow has joined #vtr-dev17:31
*** digshadow has quit IRC17:32
*** digshadow has joined #vtr-dev18:02
*** digshadow has quit IRC18:27
*** digshadow has joined #vtr-dev18:36
kem_mithro: The placer should understand direct connections from a delay perspective (e.g. if a direct connect is faster than regular routing)18:36
kem_mithro: They can also be used to for non-forced connections (e.g. where the direct connects have non-zero Fc)18:37
kem_mithro: The placer does have the concept of a placement macro, which is a set of blocks which must be moved together in some fixed relative positioning18:38
mithrokem_: This is a case of were I have "pin" objects directly connected to "IO tiles" -- so I do think it's a case of needing a placement macro?18:39
kem_mithro: I believe the way we define/detect macros are pin-to-pin direct connections with Fc=0 (i.e. no possible way to get into general routing)18:39
mithrokem_: When does this detection happen?18:40
kem_mithro: Usually I've seen that modeled by just putting the "pin" inside the "IO tile" pb_type18:40
mithrokem_: It could be a case of not setting the directs correct and the rr_graph overriding18:40
kem_mithro: The detection occurs after packing at the start of placement18:41
mithrokem_: That fails when you have multiple IO tile types but want to use an io placement file18:41
kem_mithro: There is an echo file produced which shows which macros were detected, I think it is "place_macros.echo"18:41
mithrokem_: Oh is there a way to get the packer to output post-packing blifs?18:42
kem_mithro: Not really, just the .net file.18:42
mithrokem_: it looks like it use to support something like that?18:43
kem_mithro: Its probably not what you want. I think it was just a BLIF representation which munged together the input blif netlist (e.g. primitives) with the intra-block routing routing implementation18:44
mithrokem_: Well, that is kind of close to what I want -- ideally I want a BLIF which outputs each block as a .subckt file I think...18:45
kem_mithro: I don't think that is actually what it does. I think it writes out a flattened form of that, but which includes the explicit intra-block routing resources.18:48
mithrokem_: Any chance you'll get time to look at soon?18:49
tpbTitle: Support packing when modes provide different routing by mithro · Pull Request #365 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
kem_mitrho: Haven't had a chance yet, but hopefully soon18:52
*** digshadow has quit IRC19:04
*** digshadow has joined #vtr-dev20:45
*** digshadow has quit IRC20:54
*** digshadow has joined #vtr-dev21:36

Generated by 2.13.1 by Marius Gedminas - find it at!