| *** tpb has joined #vtr-dev | 00:00 | |
| *** digshadow has quit IRC | 03:21 | |
| *** digshadow has joined #vtr-dev | 03:40 | |
| jhol | digshadow: I started making a list of everything I find that needs to be in the rr_graph: https://docs.google.com/document/d/1kTehDgse8GA2af5HoQ9Ntr41uNL_NJ43CjA32DofK8E/edit?usp=sharing | 12:11 |
|---|---|---|
| tpb | Title: Config list - Google Docs (at docs.google.com) | 12:11 |
| jhol | is this useful? - if so I'll keep adding any muxes and wires I encounter | 12:11 |
| jhol | could do with some tidying | 12:11 |
| jhol | perhaps you could use it as a check-list for the things that need to go into the rr_graph | 12:12 |
| mithro | jhol: Morning | 14:51 |
| jhol | mithro: hi | 14:51 |
| mithro | jhol: How are things going? Did my email summary make sense? | 14:52 |
| mithro | kem_: When you have 30m -> 1h I could use some help understanding some very strange behaviour myself and digshadow are seeing around "fc" tag | 14:52 |
| jhol | mithro: yeah, thanks for the email | 14:54 |
| jhol | I've just been tinkering with the 3-bit counter a little more today | 14:54 |
| jhol | got it to route properly, now | 14:54 |
| jhol | more adjustments to the way modes are done | 14:55 |
| mithro | jhol: Oh? | 14:55 |
| mithro | Please do share! | 14:55 |
| mithro | jhol: Did you end up putting together those more simple tests? | 14:55 |
| jhol | http://www.clifford.at/icestorm/logic_tile.html | 14:55 |
| tpb | Title: Project IceStorm LOGIC Tile Documentation (at www.clifford.at) | 14:55 |
| jhol | so in the first paragraph of the Logic Block section... | 14:56 |
| jhol | it mentions that CLK, CLKEN input and SR input are shared, but the bypass flip-flop mux, whether SR does set or reset, and the synchronous/asynchronous mode are indifividually configurable | 14:57 |
| mithro | Each logic tile has a logic block containing 8 logic cells. Each logic cell contains a 4-input LUT, a carry unit and a flip-flop. Clock, clock enable, and set/reset inputs are shared along the 8 logic cells. So is the bit that configures positive/negative edge for the flip flops. But the three configuration bits that specify if the flip flop should be used, if it is set or reset by the set/reset input, and if the set/reset is | 14:57 |
| mithro | synchronous or asynchronous exist for each logic cell individually. | 14:57 |
| jhol | this means that the whole tile needs modes for NegClk, Enable/Disable, and Yes/No to Set/Reset | 14:58 |
| jhol | and the individual LUTFFs need configs for Set or Reset and Sync/Async | 14:58 |
| mithro | jhol: Yes, that makes sense | 14:58 |
| jhol | -- I've got that implemented now, and VPR place my 3-bit counter into two tiles as it should do | 14:58 |
| mithro | jhol: WOOT! | 14:58 |
| jhol | then I've been hacking around some carry-chain issues, and it gets through to the end | 14:59 |
| jhol | 1-sec, I will push code | 14:59 |
| jhol | https://github.com/jhol/symbiflow-arch-defs/commits/modes-fixes2 | 15:00 |
| tpb | Title: Commits · jhol/symbiflow-arch-defs · GitHub (at github.com) | 15:00 |
| jhol | also, your "tests: Make yosys write $true/$false/$undef definitions" was a helpful fix | 15:02 |
| mithro | jhol: Oh - it was you who had seen that problem too? | 15:03 |
| mithro | I thought it was digshadow but he was very confused when I started chatting to him about it... | 15:03 |
| jhol | well not as such, but now VPR is able to spawn a LUT4 so it can implement a $false for my counter | 15:03 |
| jhol | -- now -- with your patch | 15:03 |
| jhol | so the $false + 1x LUT4 + 2x SB_DFFs go in 1 tile, and the SB_DFFE go in the other | 15:04 |
| mithro | jhol: Did you figure out SB_DFFE verse SB_DFF? | 15:07 |
| jhol | I'm going to chat to clifford later | 15:08 |
| jhol | it's not really an issue, just an observation | 15:08 |
| mithro | What is the difference between them? | 15:08 |
| jhol | so a SB_DFFE is a D-flip flop, with an extra clock enable pin | 15:09 |
| jhol | at the moment yosys always seems to implement counters by using the clk to toggle a SR_DFF for bit 0, then then using that signal to drive the EN pin in a SR_DFFE for bit 1 and driving that with the clock as well | 15:09 |
| jhol | for higher bits, it just adds more SR_DFFs in a carry chain | 15:09 |
| jhol | so my question was just about WHY yosys implements the circuit this way, and this if optimal behaviour | 15:10 |
| jhol | *and if this is... | 15:10 |
| mithro | jhol: I would love someone to write that up :-P | 15:10 |
| mithro | jhol: And then they could also do a YouTube video about it ;-) | 15:11 |
| jhol | yeah - I'm tempted to do one about VPR | 15:11 |
| mithro | jhol: Let's leave the vpr one until we have working ice40 and artix-7 support :-) | 15:11 |
| jhol | the only thing is that software-only videos risk being a bit dry | 15:11 |
| jhol | yeah | 15:12 |
| jhol | an artix-7 video would be beyond awesome | 15:12 |
| mithro | jhol: I think if we can get the ice40 working, the artix-7 won't be far behind | 15:13 |
| jhol | amazing - you guys have been doing great things | 15:13 |
| mithro | jhol: In some ways I think the Artix-7 stuff was closer to being working before you started on the ice40 stuff | 15:14 |
| jhol | really? that's so exciting | 15:14 |
| mithro | jhol: But we switched back to the ice40 because we have a known timing model for that | 15:15 |
| jhol | so you want to hear my big comment about symbiflow-arch-defs? | 15:15 |
| mithro | jhol: The Makefile system sucks and needs to be rewritten? :-P | 15:15 |
| jhol | yes: the XML+XSLT+Makefile stuff is cumbersome | 15:15 |
| jhol | my approach was better | 15:15 |
| mithro | jhol: My eventual approach is to have everything in verilog and generate the XML from that | 15:16 |
| mithro | jhol: Take a look at the slice-l carry 4 on the artix-7 | 15:16 |
| jhol | I just did it all with a python script | 15:16 |
| jhol | https://github.com/jhol/icestorm/blob/vtr-py/icebox/vtr.py | 15:16 |
| tpb | Title: icestorm/vtr.py at vtr-py · jhol/icestorm · GitHub (at github.com) | 15:16 |
| jhol | beutifully expressive - no repetition | 15:17 |
| jhol | easy to edit without developer conflicts | 15:17 |
| mithro | jhol: Yeah - you are probably right, once we have things working we can loop back to ways to improve the repo | 15:17 |
| jhol | that 387 lines implements all the SB_DFF modes, and takes a stab at the interconnect | 15:17 |
| jhol | also has RAM and PIOs | 15:18 |
| jhol | multiple things are busted, but structurally it does the job very concisely | 15:18 |
| mithro | jhol: Yeap | 15:18 |
| mithro | jhol: If I had known about your vtr-py before we started, then we probably would have gone that route | 15:19 |
| jhol | yeah - I worked on it starting 2016, but I never go anything good enough to publish | 15:19 |
| mithro | jhol: But alas Clifford did not mention you had done anything and I didn't find it when searching... | 15:19 |
| mithro | jhol: So, you just said I could blame you for the xml mess? :-P | 15:20 |
| jhol | I'm sorry :( | 15:20 |
| mithro | jhol: If you get the ice40 PLB working your forgiven ;-) | 15:21 |
| mithro | jhol: I'm open to the idea of moving to a vtr-py like thing in the future | 15:21 |
| jhol | what are we doing about the PIOs? | 15:21 |
| mithro | jhol: Ignoring them? :-P | 15:21 |
| jhol | can we ignore them? | 15:22 |
| jhol | that's where the global injectors live | 15:22 |
| mithro | jhol: "Sticking our head in the sand until we can't ignore them any longer" :-) | 15:22 |
| jhol | I would think getting the <pb_type> for them better would be pretty easy | 15:22 |
| jhol | at the moment you've got PIO-LR and PIO-TB, but really there needs to be 4x PIOs - one for each side | 15:23 |
| mithro | jhol: Probably | 15:23 |
| mithro | jhol: But don't get distracted by that yet :-P | 15:23 |
| jhol | no - I'm going to test the router with more things | 15:24 |
| jhol | also, you saw this, right?: https://docs.google.com/document/d/1kTehDgse8GA2af5HoQ9Ntr41uNL_NJ43CjA32DofK8E/edit?usp=sharing | 15:24 |
| tpb | Title: Config list - Google Docs (at docs.google.com) | 15:24 |
| mithro | jhol: Yeah! That is pretty good | 15:24 |
| jhol | there are so many things to remember to put in the rr_graph, including things deeply burried inside the PLBs | 15:25 |
| jhol | I'm not sure I've got everything there- but I think it might help to check those things off as they're coded up in python | 15:25 |
| mithro | jhol: Yeap! | 15:30 |
| mithro | jhol: See privmsg | 15:35 |
| kem_ | mithro: I might be able to do later this afternoon (otherwise probably tomorrow afternoon) to discuss Fc related stuff | 15:37 |
| mithro | kem_: Okay, when is afternoon for you? :-P | 15:38 |
| mithro | kem_: My morning is pretty busy, but I would be free in like ~3 hours from now.... | 15:40 |
| kem_ | mithro: OK, that might work. I've got meetings before hand which may run long. Hopefully they should be done by 3 or 4pm Eastern. | 15:43 |
| mithro | kem_: I can do 4pm eastern easily | 15:45 |
| mithro | kem_: How about we just pencil that in now and if things change just mention it? | 15:45 |
| kem_ | mithro: Sounds good! | 15:46 |
| mithro | jhol: Started adding some questions to your doc :-) | 15:50 |
| daveshah | jhol: I've cleared up a couple of the IO questions in the doc | 15:58 |
| *** q3k has joined #vtr-dev | 16:39 | |
| *** digshadow has quit IRC | 17:51 | |
| *** digshadow has joined #vtr-dev | 18:25 | |
| mithro | Hey kem_, myself and digshadow are around now -- happy to chat any time from now | 19:48 |
| kem_ | mithro: OK I'm free now | 19:57 |
| mithro | kem_: I was thinking we would do it via IRC, but we can do VC if you think that would be easier? | 19:58 |
| kem_ | mithro: Either works for, me if we'll be sending files back and forth IRC is probably easiest | 19:59 |
| mithro | Okay, let's start here and move if we need | 20:00 |
| kem_ | mithro: Ok | 20:00 |
| mithro | kem_: So myself and digshadow have been trying to understand how the fc parameter affects connection from pins to the fabric | 20:01 |
| mithro | kem_: It is my understanding that <fc in_type="abs" in_val="1" out_type="abs" out_val="1"/> should connect each in pin and each out pin to one track of each segment type? | 20:02 |
| kem_ | mithro: Not quite | 20:02 |
| kem_ | mithro: That would connect to one track/segment in the entire channel | 20:03 |
| kem_ | mithro: If you explicitly want one to each segment type you'd need to use <fc_override> | 20:03 |
| mithro | kem_: But each pin *should* be connected to one track | 20:04 |
| mithro | IE No pins should be unconnected? | 20:04 |
| kem_ | mithro: Yes that sounds correct in general | 20:04 |
| mithro | kem_: Okay - let me check that I wasn't imagining things from last night | 20:05 |
| mithro | kem_: But I'm pretty sure that isn't happening in our email | 20:05 |
| kem_ | mithro: There are some corner cases where that may not be the case (e.g. a direct connects where the target block doesn't exist) | 20:05 |
| mithro | kem_: https://usercontent.irccloud-cdn.com/file/OxokPIBA/image.png | 20:06 |
| mithro | kem_: That architecture has <fc in_type="abs" in_val="1" out_type="abs" out_val="1"/> in the purple block type | 20:07 |
| mithro | But pins 0, 1, 2 seem to be connected to 4 tracks each, while 3,4,5 seem to be connected to none | 20:07 |
| mithro | kem_: In fact we get the following in the log output | 20:08 |
| mithro | Warning 3: in check_rr_node: RR node: 25 type: OPIN location: (3,1) pin: 7 pin_name: BLK_TI-LUTFF.OUT[1] has no out-going edges. | 20:08 |
| kem_ | mithro: Interesting | 20:08 |
| mithro | Error 1: in check_rr_graph: node 41 (IPIN) at (3,2) block=BLK_TI-LUTFF side=RIGHT has no fanin. | 20:08 |
| mithro | kem_: Ha - that is not a good interesting :-P | 20:09 |
| mithro | kem_: I can share the architecture XML - it's pretty simple | 20:09 |
| kem_ | mithro: Yeah send along the architecture and I'll take a look | 20:09 |
| mithro | kem_: But your expectation would be that each one of those pins connected to at least one track? | 20:10 |
| kem_ | mitrho: Yes unless I'm completely miss-understanding :) | 20:10 |
| mithro | kem_: Okay - that is the conclusion we came too too | 20:10 |
| kem_ | mithro: One thing to note is that in a uni-directional routing architecture tracks are assigned in pairs (one in each direction), so I'm not surprised to see things connections which are multiples of 2 | 20:11 |
| mithro | digshadow: kem seems to agree with our theory! :-P | 20:12 |
| kem_ | mithro: Are you doing anything with multiple pin locations? For example the same pin on multiple sides of the block? | 20:13 |
| mithro | kem_: Nope! All pins are on the right side | 20:13 |
| digshadow | mithro: cool | 20:14 |
| mithro | kem_: https://gist.github.com/mithro/17a4a3b6cc22c6a340f23933a109ca5d | 20:19 |
| tpb | Title: Makefile · GitHub (at gist.github.com) | 20:19 |
| kem_ | mithro: Which device are you using? | 20:21 |
| mithro | kem_: 2x4 | 20:21 |
| mithro | kem_: Just confirmed that 4x4 also has the same behaviour... | 20:21 |
| mithro | https://www.irccloud.com/pastebin/1Dno9flx/ | 20:22 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 20:22 |
| kem_ | mithro: Yep, I can reproduce the behavior | 20:23 |
| mithro | kem_: Great! | 20:27 |
| mithro | kem_: I have to run away to another meeting, but digshadow is still looking into this | 20:27 |
| kem_ | mithro: OK I'll take a look too and see if I can track the cause down | 20:27 |
| digshadow | kem_: ping my nick if you have any questions, sounds like you have enough info to investigate your side | 20:29 |
| digshadow | In the meantime I'll be using our rr_graph library to create a custom, simple interconnect | 20:29 |
| kem_ | digshadow: will do | 20:30 |
| mithro | kem_: I tried changing the fc abs value to 2 and similar and it still didn't make any sense to me | 20:32 |
| kem_ | mithro: I've tried a couple similar tweaks with the same result. Using an equivalent fc frac also shows problems | 20:34 |
| digshadow | mithro: FYI added note to the large track with ticket: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/88 | 20:38 |
| tpb | Title: Investigate high channel width on test · Issue #88 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 20:38 |
| mithro | kem_: Any theories on what is going on/ | 21:03 |
| mithro | kem_: Some info / notes I collected | 21:04 |
| mithro | https://www.irccloud.com/pastebin/Irxi3P01/ | 21:04 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 21:04 |
| kem_ | mithro: I've found the root cause, just thinking about the best way to fix it | 21:06 |
| mithro | kem_: Oh? I would love to know | 21:06 |
| kem_ | mithro: Internal to build_rr_graph() the fc specifications from the architecture file are converted to per-pin absolute Fc values | 21:07 |
| mithro | kem_: When I looked at the arch.echo - the fc_value_type output seemed to make sense there... | 21:08 |
| kem_ | mithro: Right now this process is leaving some of the pins with an Fc value of zero, which is why they have no connections | 21:09 |
| mithro | digshadow - BTW I don't think I shared this -> https://gist.github.com/mithro/3d6ec5ff0e2eea7fa8ae23caffabc50c | 21:09 |
| tpb | Title: Convert rr_graph file from Verilog-To-Routing into GraphViz `.dot` file · GitHub (at gist.github.com) | 21:09 |
| kem_ | mithro: You can see this if you add '#define VERBOSE' to rr_graph.cpp | 21:09 |
| kem_ | mithro: It produces output like the following when run: | 21:10 |
| kem_ | mithro: Fc Actual Values: type = BLK_TI-LUTFF, pin = 3, seg = 0 (span), Fc_out = 0, Fc_in = 0. | 21:10 |
| kem_ | mithro: which matches what's in the GUI | 21:11 |
| mithro | FYI I also also investigating some weirdness around IO blocks but ended up at this yak shave :-P | 21:11 |
| mithro | digshadow: See what kem_ said above -- could be very useful to you | 21:13 |
| kem_ | mithro: The challenge is that the easy fix makes the specified and actual Fc values quite different... | 21:15 |
| kem_ | mithro: So I'm tempted to forbid very low Fc values in cases where it is infeasible/not well defined, and throw an error | 21:16 |
| kem_ | mithro: So in the case of your architecture setting the Fc values to 2 ensures the pins all get connected | 21:21 |
| mithro | kem_: have to run away again | 21:31 |
| mithro | But why doesn't abs 1 work? | 21:31 |
| kem_ | mithro: We try to balance the Fc values within a single port. But in uni-dir architectures (since we assign tracks in pairs) we don't actually have enough pins to balance without leaving some pins disconnected | 21:34 |
| kem_ | mithro: In the case where the absolute Fc is very low (e.g. 1) | 21:35 |
| kem_ | mithro: Stepping back from this bug in particular, the semantics of the Fc specification are a bit odd, since if you ask for Fc abs = 1 on a uni-dir arch, you get an architecture with Fc abs = 2*K, where K is the number of wire types in the architecture | 21:37 |
| kem_ | mithro: I'm thinking to set the minimum absolute Fc to 2*K to avoid this, since things aren't really well defined for abs Fc < 2*K (at least given how the rr graph generator is currently implemented). | 21:39 |
| digshadow | kem_: I guess what throws me off on this, if I'm understanding correction, is that I would expect type=abs,val=1 to connect each pin to at least one track. But if I'm understanding correctly, it connects one track to all pins | 21:56 |
| digshadow | correctly | 21:57 |
| kem_ | digshadow: Your expectation is correct, that is the behaviour that makes sense | 21:57 |
| digshadow | I am unclear from above the relation between us having incorrect expectations vs bug in VPR | 21:58 |
| kem_ | digshadow: It's definitely a bug in VPR | 21:59 |
| digshadow | Are you saying that it doesn't do that today, but should, except there are some complications to make that work the way that would be intuitive? | 21:59 |
| digshadow | due to algorithm limitations | 21:59 |
| kem_ | digshadow: Yep that's a good summary | 22:00 |
| digshadow | perfect, thanks | 22:00 |
| digshadow | okay, let me re-read now with that in mind | 22:00 |
| digshadow | one thing that would help clarify would be to better understand the unidirection arch components. I don't understand why you can't have an odd number of tracks. Is there a resource you can point me at? | 22:01 |
| kem_ | It's not a fundamental limitation of uni-dir architectures, you could build an architecture with an odd number of tracks (although there wouldn't be much motivation too). | 22:06 |
| kem_ | It is however a restriction/simplification made within the VPR's rr graph generator | 22:07 |
| digshadow | gotcha | 22:07 |
| kem_ | This gives an overview of uni-dir support in VPR (although I'm not sure it talks about odd vs even channel widths): http://www.eecg.toronto.edu/~jayar/pubs/luu/luutrets11.pdf | 22:08 |
| kem_ | It also has references to the original work on uni-dir architectures | 22:08 |
| digshadow | cool will take a look | 22:08 |
| digshadow | ah did vpr start out as strictly bidir? | 22:08 |
| kem_ | Yes, historically FPGAs used bidir architectures, but unidir is almost uniformly better so most modern FPGAs us unidir | 22:10 |
| digshadow | Got it | 22:12 |
| digshadow | Okay, so uni-dir will assign one to inc and one to dec | 22:13 |
| kem_ | Yep | 22:13 |
| digshadow | so fabs=1 is unreasonable, since it should be either 0 or 2 | 22:13 |
| digshadow | how does the number of wire types factor in? are you expecting it to assign to each of the different segment types? | 22:14 |
| mithro | I would have expected that fabs=1 connects you to one of each direction? | 22:14 |
| digshadow | mithro: eh well they are two separate wires | 22:14 |
| mithro | True | 22:15 |
| kem_ | mithro: That's what the code currently tries to do, but it is somewhat inconsistent... | 22:15 |
| mithro | kem_: Okay | 22:15 |
| kem_ | On the subject of wiretypes, we currently try to ensure each block pin connects to at least one wire of each type | 22:17 |
| kem_ | So on a unid-dir with K wire types and Fc abs=1, you actually get 2*K connections per pin | 22:17 |
| kem_ | Which is also somewhat inconsistent with the concept behind Fc... | 22:18 |
| digshadow | kem_: got it | 22:18 |
| digshadow | Hmm yeah I'm not sure that Fc is really behaving like I was expecitng | 22:18 |
| kem_ | Yeah, hence why I'm trying to think of a better way to handle these cases | 22:19 |
| mithro | kem_: I think the fc=1 connecting a pin to one track of /each/ type seems a pretty logical interpretation | 22:21 |
| mithro | kem_: But I would also be happy with fc=1 connect a pin to one track in total | 22:21 |
| mithro | kem_: But it should never connect a pin to no tracks :-P | 22:21 |
| kem_ | Agreed! | 22:22 |
| mithro | kem_: Shall we leave the ball in your court to solve? | 22:23 |
| mithro | kem_: Oh - does fc_overrides work the way we would expect? | 22:23 |
| mithro | kem_: <fc_override fc_type="abs" fc_val="1" segment_name="short"><fc_override fc_type="abs" fc_val="1" segment_name="long"> do the right thing at the moment? | 22:24 |
| kem_ | mithro: probably not | 22:24 |
| mithro | kem_: What about fc=2? | 22:25 |
| kem_ | mithro: fc_overrides and the defaults are handled the same way. Internally the defaults and overrides are expanded into a single set of pins + seg Fc constraints | 22:25 |
| kem_ | mithro: Trying fc=2 fixes the architecture you sent, although I haven't tried with overrides | 22:26 |
| mithro | kem_: Well, just discovered that fc_override for a segment name that doesn't exist do not cause vpr to fail.... | 22:26 |
| kem_ | mithro: We're probably a missed error check for that case :( | 22:27 |
| mithro | kem_: Okay - with fc=2, I get each pin connected to on pair of uni directional wires per type | 22:28 |
| digshadow | kem_: we found a few other things too, but I figured I'd bring them up later to not derail the main conversation | 22:29 |
| mithro | https://usercontent.irccloud-cdn.com/file/BCAWXIar/image.png | 22:29 |
| mithro | BTW - I think it would be nice to color-code the wires to different types | 22:29 |
| mithro | kem_: Maybe we should just say if the architecture has uni-directional wires fc must be mod 2 ? | 22:30 |
| kem_ | mithro: Yep, that's what I'm adding now | 22:30 |
| mithro | kem_: Ha - great minds think alike :-P | 22:31 |
| mithro | kem_: It would also be nice for the pins which are connected to "long lines" which are not drawn (IE pin 8 and 9) had some type of indicator too | 22:31 |
| kem_ | mithro: I think 8 and 9 are clock pins, which is why they aren't connected to anything | 22:32 |
| kem_ | mithro: We are actually starting to look at clock networks so hopefully they will be connected to something soon :) | 22:33 |
| digshadow | kem_: unrelated if we are taking a break from the main issue, we also observed that you could have num_pb on a top level pb_type | 22:39 |
| digshadow | would you expect an error to be thrown for this? | 22:39 |
| digshadow | mithro: also don't forget to rename BEL/BLK if you haven't done that yet | 22:40 |
| kem_ | digshadow: Yes that should probably be an error | 22:41 |
| digshadow | kem_: I'll file a bug then | 22:42 |
| kem_ | digshadow: Thanks | 22:42 |
| kem_ | digshadow: There is a separate 'capacity' attribute which is conceptually similar and active only at the top level | 22:43 |
| mithro | kem_: So - should things fail if there is a mixture of bidir / unidir segment types? | 22:44 |
| kem_ | mithro: I haven't tried it, but I expect the rr graph generator assumes only one of bidir/unidir | 22:45 |
| mithro | kem_: Yeap, it seems to just pick the first one | 22:46 |
| kem_ | mithro: I think the router should be OK with a mixed bidir/unidir architecture (it's the same code for both routing types). | 22:46 |
| mithro | kem_: okay | 22:48 |
| *** digshadow has left #vtr-dev | 22:49 | |
| *** digshadow has joined #vtr-dev | 23:08 | |
| digshadow | kem_: also unrelated, I'm unclear why you need to specify --route_chan_width when reading an rr_graph. Doesn't the rr_graph define this and not vpr? | 23:10 |
| kem_ | digshadow: I think that's mostly just a historic artifact. | 23:14 |
| kem_ | digshadow: VPR always took this from the command-line (or calculated it from binary search) so we just required it be specified | 23:14 |
| kem_ | digshadow: when an rr graph was loaded, which allowed us to do some consistency checks that the <channel> info was consistent | 23:15 |
| digshadow | got it | 23:19 |
| digshadow | I think there was also something related to fc, but I can't recall specifically. Along the lines of presumably fc doesn't matter when you give an rr_graph | 23:20 |
| kem_ | That sounds correct. When you load an rr graph the rr graph generator is bypassed so the Fc values won't be used. | 23:22 |
| kem_ | The only possible exception might be placement macros. I think we look for fc=0 to identify placement macros (e.g. carry chains) which must be kept together during placement to ensure they can be connected via dedicated routing. | 23:23 |
| digshadow | okay, thats good to know | 23:26 |
| digshadow | mithro: I'm clicking on pins in the vtr GUI, they only report 1 edge per connection. I'd be expecting n + 1 to connect to the net source | 23:40 |
| mithro | digshadow: Hrm | 23:40 |
| mithro | digshadow: Got look and see where that comes from? | 23:40 |
| digshadow | I'll dump the rr_graph and see what it looks like | 23:40 |
| digshadow | kem_: rr_graph has id in some locations and index in some others to refer to identifiers. Thoughts on standardizing the name? | 23:51 |
| kem_ | digshadow: I'd lean towards 'id' (since how things are stored is an implementation detail) | 23:56 |
| digshadow | mithro: also I asked a while back why ptc is in loc for <node>. its presumably because the block type is inferred from the location | 23:56 |
| digshadow | kem_: okay, so I'll file a ticket on that then | 23:56 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
