| *** tpb has joined #vtr-dev | 00:00 | |
| kem_ | mithro: Yes, I believe it means complex block 2 (since I think that warning is issued after packing) | 01:15 |
|---|---|---|
| kem_ | mithro: Also, I think that warning is a false positive for output blocks (it's warning that they have no connected outputs, which is true for an output pad) | 01:17 |
| mithro | Yeah | 01:20 |
| mithro | kem_: so it seems that there is issues when you have muxes on the carry chain | 01:21 |
| mithro | kem_: the packer will select the carry input for a signal and then complain it can't route onto that signal when doing routing | 01:22 |
| mithro | kem_: I assume we have to do something to tell vpr to only use the carry chain inputs for carry logic? | 01:23 |
| kem_ | mithro: for the false positive warning, can you file bug on it? I though I'd fixed it, or perhaps I only fixed it in my head :) | 01:24 |
| mithro | Sure! | 01:24 |
| mithro | It also seems that the router can rearrange inputs? | 01:25 |
| mithro | S/can/can't/ | 01:25 |
| kem_ | mithro: Which inputs? To the a clusterÉ | 01:25 |
| kem_ | ? | 01:25 |
| mithro | Inputs to a block/tile | 01:26 |
| kem_ | mithro: That is what the equivalent='true' attribute on a block port enables | 01:27 |
| kem_ | mithro: Setting a port as equivalent effectively means 'there is a full crossbar behind this' so it's OK to swap inputs around | 01:28 |
| kem_ | mithro: The carry-chain with mux is interesting. I'm not sure we've tried something like that before. Do you have an example? | 01:30 |
| mithro | Basically the input to the carry logic can either be the I0 pin (shared with the LUT) or the CIN pin | 01:32 |
| mithro | kem_: So, it can only swap inputs with a full crossbar? | 01:32 |
| kem_ | mithro: For input swapping a full crossbar is what equivalent models -- effectively it means any input pin to this port can be moved to any other input pin (which is guaranteed by having a full cross-bar internally for all the pins in that port) | 01:35 |
| kem_ | mithro: Of course you can model less than a full crossbar by using multiple smaller ports which are equivalent within themselves | 01:36 |
| mithro | okay | 01:36 |
| kem_ | mithro: This is one of those limitations which comes from the current split between the logic block rr graph, and routing rr graph. If the router had full visibility into the logic block rr graph it can swap things around according to the rr graph connectivity | 01:37 |
| kem_ | mithro: *could swap* | 01:38 |
| mithro | kem_: yeah | 01:38 |
| mithro | kem_: Is anyone working on something like that? | 01:38 |
| kem_ | mithro: Not at the moment, but it is a long term goal. Probably something worth discussing at the next VTR meeting. | 01:40 |
| mithro | kem_: Okay | 01:41 |
| kem_ | mithro: For the carry chain mux, I have a suspicion what the issue is | 01:41 |
| mithro | kem_: Shall I log a issue about it? | 01:41 |
| kem_ | mithro: That would be good | 01:41 |
| mithro | kem_: It's probably cause by the fact that the carry-chain input path is probably much lower delay... | 01:43 |
| mithro | Or that would be my guess.... | 01:43 |
| kem_ | mithro: I suspect its more fundamental than that | 01:43 |
| mithro | kem_: Okay | 01:43 |
| kem_ | mithro: The packer currently assumes that any logic block input is reachable from the global routing network (it uses this if it needs to feedback a signal but there isn't enough internal routing). | 01:44 |
| mithro | kem_: How does it deal with carry's then? | 01:44 |
| mithro | (which are not connected to the internal routing)? | 01:45 |
| kem_ | mithro: I think so far we've only modelled architectures which the only thing which connect to carry chain pins are carry chains (i.e. no mux on the carry chain) | 01:45 |
| mithro | kem_: Okay | 01:46 |
| kem_ | mithro: Conceptually the fix is fairly straight forward. We just need to update the logic block internal routing graph to consider the Fc overrides and leave the CIN pin disconnected to the 'global routing' node. | 01:47 |
| kem_ | mithro: If you can file a bug and testcase to reproduce, I can try to take a look next week | 01:48 |
| mithro | kem_: Okay will do | 01:49 |
| mithro | kem_: Will log both bugs shortly | 01:51 |
| mithro | kem_: Is there a way to get the clock to route like a normal signal? | 01:54 |
| kem_ | mithro: Someone is look at that right now actually. It's the first step towards properly modelling the clock network. | 02:03 |
| kem_ | mithro: We may have some progress on that for the next VTR meeting | 02:04 |
| *** mithro has quit IRC | 16:03 | |
| *** mithro has joined #vtr-dev | 16:29 | |
| *** maartenBE has quit IRC | 23:07 | |
| *** maartenBE has joined #vtr-dev | 23:44 | |
| *** maartenBE has quit IRC | 23:48 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!