*** tpb has joined #vtr-dev | 00:00 | |
*** ZipCPU has quit IRC | 05:51 | |
*** ZipCPU has joined #vtr-dev | 06:24 | |
mithro | kem_: 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 before | 06:46 |
---|---|---|
mithro | It's kind of pretty to watch :-P | 06:47 |
mithro | https://usercontent.irccloud-cdn.com/file/rbnnuuay/image.png | 06:50 |
mithro | elms: ^ | 06:51 |
*** elms has quit IRC | 06:56 | |
*** elms has joined #vtr-dev | 07:22 | |
*** ZipCPU has quit IRC | 07:25 | |
*** ZipCPU has joined #vtr-dev | 09:49 | |
*** ZipCPU has quit IRC | 10:52 | |
*** ZipCPU- has quit IRC | 12:07 | |
*** ZipCPU has joined #vtr-dev | 12: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 IRC | 17:02 | |
mithro | kem_: 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-dev | 17:31 | |
*** digshadow has quit IRC | 17:32 | |
*** digshadow has joined #vtr-dev | 18:02 | |
*** digshadow has quit IRC | 18:27 | |
*** digshadow has joined #vtr-dev | 18: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 positioning | 18:38 |
mithro | kem_: 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 |
mithro | kem_: 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_type | 18:40 |
mithro | kem_: It could be a case of not setting the directs correct and the rr_graph overriding | 18:40 |
kem_ | mithro: The detection occurs after packing at the start of placement | 18:41 |
mithro | kem_: That fails when you have multiple IO tile types but want to use an io placement file | 18:41 |
kem_ | mithro: There is an echo file produced which shows which macros were detected, I think it is "place_macros.echo" | 18:41 |
mithro | kem_: 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 |
mithro | kem_: 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 implementation | 18:44 |
mithro | kem_: 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 |
mithro | kem_: Any chance you'll get time to look at https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/365 soon? | 18:49 |
tpb | Title: Support packing when modes provide different routing by mithro · Pull Request #365 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 18:49 |
kem_ | mitrho: Haven't had a chance yet, but hopefully soon | 18:52 |
*** digshadow has quit IRC | 19:04 | |
*** digshadow has joined #vtr-dev | 20:45 | |
*** digshadow has quit IRC | 20:54 | |
*** digshadow has joined #vtr-dev | 21:36 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!