| *** tpb has joined #vtr-dev | 00:00 | |
| *** digshadow has quit IRC | 00:49 | |
| *** digshadow has joined #vtr-dev | 00:50 | |
| mithro | daveshah / digshadow / kem_: Just tested the output on real hardware and it worked! | 02:26 |
|---|---|---|
| mithro | According to icetime -- vpr - Total path delay: 7.28 ns (137.33 MHz), arachne - Total path delay: 10.84 ns (92.21 MHz) | 02:27 |
| mithro | However I'm not sure that makes much sense because I just have "random" values in the ice40 description... I guess it does just try and minimize them.... | 02:27 |
| mithro | Took me a while to realize that iceblink != icestick | 02:32 |
| digshadow | mithro: nice! thats great news | 02:50 |
| mithro | digshadow: Did you get anywhere with that rr_graph fixes? | 02:50 |
| digshadow | no | 02:52 |
| *** digshadow has quit IRC | 03:00 | |
| *** digshadow has joined #vtr-dev | 03:04 | |
| *** digshadow has quit IRC | 03:33 | |
| kem_ | mithro: Awesome! | 12:39 |
| kem_ | mithro: I would add, that if the timing model you've given VPR in the architecture file/RR graph is effectively 'random' then I'd expect to see further performance improvements with an accurate timing model | 12:40 |
| mithro | kem_: Yeah - it's mostly random I would say | 16:50 |
| mithro | kem_: when you have a moment, I have a question about clustering | 16:57 |
| daveshah | mithro: Congrats on the PnR! | 17:56 |
| daveshah | Let me know when you want help with icetime stuff | 17:57 |
| daveshah | I might need to learn a bit myself, but I can always ping clifford | 17:57 |
| mithro | daveshah: How's now :-P | 17:57 |
| daveshah | Sure, I can start giving you some pointers now | 17:57 |
| mithro | daveshah: So there are two major parts right | 17:57 |
| mithro | daveshah: The "routing timing" and the "internal to a block" timing | 17:58 |
| daveshah | Yes, exactly | 17:58 |
| mithro | daveshah: Where is the data stored? | 17:58 |
| daveshah | Although icetime uses the same model for both of those | 17:58 |
| daveshah | For the routing cells are used for buffers/muxes too | 17:58 |
| mithro | by "model" what does that mean? | 17:58 |
| daveshah | The data is at https://github.com/cliffordwolf/icestorm/blob/master/icefuzz/timings_hx1k.txt | 17:59 |
| tpb | Title: icestorm/timings_hx1k.txt at master · cliffordwolf/icestorm · GitHub (at github.com) | 17:59 |
| daveshah | mithro: the model in both cases is a cell | 17:59 |
| daveshah | With rising and falling delays from each input to output plus setup and hold checks if applicable | 17:59 |
| daveshah | You can make an HTML database view with the icefuzz makefile | 18:00 |
| mithro | daveshah: By model - you just mean an object which has a path delay between In / Out + checks? | 18:00 |
| daveshah | mithro: yea | 18:00 |
| daveshah | The checks only apply if clocked of course | 18:00 |
| mithro | daveshah: That isn't published on the site? | 18:00 |
| daveshah | mithro: No, I'll ping clifford | 18:00 |
| daveshah | For what it's worth, using cells for IO muxes is a fairly primitive model. More advanced approaches would use a loading model, etc | 18:02 |
| daveshah | But it's basically how icecube2 does it too | 18:02 |
| mithro | daveshah: Lets start with primitive :-P | 18:03 |
| daveshah | There are some heuristics as to which cell to pick for a connection in icecube, and to an extent in icetime too I think | 18:03 |
| daveshah | Primitives are definitely where to start | 18:03 |
| daveshah | May as well make a script to get the timing data and put it into the XML | 18:03 |
| mithro | daveshah: I actually mean let's start with simple modelling :-) | 18:03 |
| mithro | daveshah: I was going to just hand port over some values first to see how it maps | 18:04 |
| daveshah | Well, we don't have any data for the iCE40 for anything more anyway | 18:04 |
| mithro | daveshah: Then once I have a hand coded version write a script to generate one | 18:04 |
| daveshah | Sounds good | 18:04 |
| sorear | Loading model = distributed RC? | 18:04 |
| daveshah | Yeap | 18:05 |
| daveshah | In some way or another | 18:05 |
| daveshah | Need to poke about with ecp5 timings | 18:05 |
| daveshah | Each wire can have only 0, 1 or 2 loads in ecp5 before a buffer | 18:05 |
| daveshah | So loading model is either really simple or not needed at all | 18:05 |
| daveshah | Otherwise it's very regular so it's just a case of finding the delay cost of every mux arc and through every cell | 18:06 |
| daveshah | Bit of linear algebra needed because you can't run the vendor timing analysis over a partial path, so you'll have to create lots of full paths and compare | 18:06 |
| daveshah | mithro: BTW comparing the icetime Verilog outout to the routing is probably a good place to start working out where different timing cells are inserted | 18:09 |
| mithro | daveshah: Maybe we should start with the FF and LUT timing? | 18:09 |
| daveshah | mithro: definitely | 18:09 |
| daveshah | They are the LogicCell40 entry in the timing data | 18:10 |
| daveshah | https://github.com/cliffordwolf/icestorm/blob/master/icefuzz/timings_hx1k.txt#L50 | 18:10 |
| tpb | Title: icestorm/timings_hx1k.txt at master · cliffordwolf/icestorm · GitHub (at github.com) | 18:10 |
| mithro | All the cells have the same timing? | 18:10 |
| daveshah | Numbers are min:typ:max | 18:10 |
| daveshah | Yep, it's a repeated structure after all | 18:11 |
| mithro | daveshah: Are there any simulation models for the stuff icetime outputs? | 18:11 |
| daveshah | mithro: yes, inside icecube | 18:11 |
| daveshah | I don't think there are any open source ones | 18:11 |
| mithro | daveshah: But we don't have any open source ones? | 18:11 |
| mithro | daveshah: From what I can see of the Artix-7 there are about 7 models for the slices depending on what is near the slice... | 18:12 |
| daveshah | mithro: luckily not the case in ice40 | 18:12 |
| daveshah | mithro: the icetime verilog output is intended for use with a STA tool, not a simulator | 18:12 |
| daveshah | hence the lack of open models (thats what icebox_vlog is for) | 18:12 |
| mithro | STA? | 18:12 |
| daveshah | static timing analysis | 18:12 |
| daveshah | i.e. opentimer | 18:12 |
| daveshah | which we hope will be the open source sign-off timing tool | 18:13 |
| daveshah | of SymbiFlow | 18:13 |
| mithro | daveshah: VPR seems to output the right post routing data need for opentimer from what I can see | 18:14 |
| daveshah | mithro: oh, thats | 18:14 |
| daveshah | *thats nice | 18:14 |
| daveshah | we have been wanting to try opentimer at some point | 18:14 |
| daveshah | I think icetime+opentimer should work somehow, but may never have been tested... | 18:15 |
| daveshah | you might need to get the delays into the right format, but the netlist should be OK at least | 18:15 |
| mithro | daveshah: VPR outputs the .v and .sdf with specify annotations | 18:18 |
| daveshah | mithro: not sure if OpenTimer does support sdf actually | 18:19 |
| daveshah | something to investigate in the future | 18:20 |
| kem_ | davesha: I've actually worked a little bit with OpenTimer. It basically expects the standard ASIC fileformats: verilog netlist, liberty cell delay models, and SPEF parasitics (wire resistance/capacitance). | 19:05 |
| daveshah | kem_: how was your overall experience? Do you think it would be something useful to add at the end of a VPR flow for more advanced analysis? | 19:07 |
| kem_ | davesha: It's a very ASIC oriented tool. The 'signoff' timing analyzer in FPGA vendor tools is usually quite a bit simpler; since the vendor's FPGA timing model is fairly abstracted from the real devices anyway. | 19:08 |
| daveshah | kem_: good to know. Clifford and I have been considering it but it sounds like it will probably be overkill and hard to get the data into the right format | 19:09 |
| kem_ | davesha: Yeah, I agree likely overkill | 19:10 |
| kem_ | davesha: I actually wrote a new STA engine for VPR which is designed to be a modular library re-usable in other tools | 19:10 |
| kem_ | mithro: If you have clustering questions I'm around for the next half-hour or so | 19:16 |
| mithro | kem_: so with clustering, the clustering code understands that it can't route these atoms in the same cluster but it doesn't seem to start a new cluster for them - it just fails | 19:17 |
| kem_ | mithro: Have your tried with --debug_clustring on? | 19:18 |
| kem_ | mithro: It should try to open a new cluster if they didn't fit previously | 19:18 |
| mithro | Yeah, that is how I know it says the routing is invalid | 19:18 |
| kem_ | mithro: It should also retry in all the top-level block-types which are potentially legal for that primitive type | 19:19 |
| mithro | kem_: Yeah - that is what I thought the code should do -- but it doesn't seem to be.... | 19:19 |
| kem_ | mithro: Is it possible the atom is not legal in any of block types? That would be the case where it would give-up | 19:20 |
| kem_ | mithro: Perhaps an architecture specification bug? | 19:20 |
| mithro | kem_: entirely possible | 19:21 |
| daveshah | mithro: what are you trying to pack | 19:23 |
| mithro | daveshah: Your FF example | 19:23 |
| daveshah | mithro: that is of course a bit of a torture test | 19:23 |
| daveshah | Which FF is failing? | 19:24 |
| mithro | kem_: Let me get the debug clustering output | 19:25 |
| kem_ | mithro: Sure | 19:25 |
| kem_ | mithro: Also does the architecture use any pack-patterns? | 19:25 |
| mithro | kem_: Not really | 19:26 |
| mithro | kem_: I should see that as atoms which have been built into molecules right? | 19:26 |
| kem_ | mithro: Correct | 19:26 |
| mithro | I'm not seeing any molecules in the prepack .echo file | 19:27 |
| mithro | https://www.irccloud.com/pastebin/Zpq2gMiK/ | 19:29 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 19:29 |
| mithro | kem_: The SB_DFFNESS can't be packed into the same cluster as the SB_DFF | 19:30 |
| kem_ | mithro: That's the architectural constraint right? That posedge/negedge can't be in the same block? | 19:31 |
| daveshah | kem_: yes the NegClk config bit is set per tile not per cell | 19:32 |
| kem_ | mithro: Ok, how are you modelling that in your arch file? | 19:32 |
| kem_ | mithro: The way I'd go about it is to have two top level <mode>s, one for posedge (containing the SB_DFF instances), and another mode for negedge (containing the SB_DFFNE) | 19:33 |
| mithro | kem_: A model which has two modes, one which connects CLK to POSCLK and one which connects CLK to NEGCLK -- the POSCLK is then routed to the SB_DFF and NEGCLK to the SB_DFFN | 19:34 |
| mithro | kem_: Why isn't the $auto$simplemap.cc:420:simplemap_dff$86 being moved to "complex block 5" ? | 19:35 |
| kem_ | mithro: I think it has to do with how the architecture is being modelled | 19:36 |
| mithro | kem_: FYI the prepacking output looks like this | 19:36 |
| mithro | https://www.irccloud.com/pastebin/jiXHStdd/ | 19:36 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 19:37 |
| kem_ | mithro: It sounds like you have a mode per-DFF instance in the cluster; so the packer assumes it is legal to 'place' put it there. However it is illegal due to the routing constraints, and it gives up since it now thinks that *any* cluster will be illegal | 19:37 |
| kem_ | mithro: I think the fix is to hoist the posedge/negedge mode to the top-level | 19:38 |
| kem_ | mithro: Basically have two modes which encapsulate all the DFF primitives | 19:38 |
| kem_ | mithro: One mode (e.g. posedge) has only SB_DFF primitive sites | 19:38 |
| kem_ | mithro: The other mode (e.g. negedge) has only SB_DFFNE primitive sites | 19:38 |
| mithro | kem_: Can we just get the packer to not assume that *any* cluster will be illegal? | 19:39 |
| kem_ | mithro: Potentially possible, but hard to come-up with stopping conditions in the general case then... | 19:40 |
| kem_ | mithro: I think using two mutually exclusive posedge/negedge modes is really the right approach, as davesha pointed out, there is only one config bit, and hence only one decision for the packer to make | 19:41 |
| mithro | I would expect the packer to eject the SB_DFFN from the cluster | 19:42 |
| mithro | Then it starts a new cluster and packs the SB_DFFNs together | 19:43 |
| kem_ | mithro: It would if there were no legal sites for SB_DFFNEs given the cluster's current mode configuration | 19:43 |
| kem_ | mithro: But as you described your architecture, the packer is viewing each DFF site as either a SB_DFF or a SB_DFFNE (i.e. it has a choice for each DFF) instead of a single choice between all SB_DFF or all SB_DFFNE | 19:44 |
| mithro | kem_: I can think of many packing problems were the only issue is internal routing | 19:44 |
| kem_ | mithro: I think in those cases the packer should re-try in a new cluster | 19:46 |
| mithro | Yeah | 19:47 |
| mithro | It seems that at the moment a routing failure just causes the clustering to stop | 19:47 |
| mithro | kem_: so I just need to change the if statement which makes the packer stop at a routing failure? | 20:07 |
| kem_ | mithro: The packer has multiple stages (it does it's own internal placement and routing within the cluster), and multiple levels of legality checks. I suspect what is happening is that the routing failure is just a coincidental symptom of a placement issue (i.e. DFFs must be all posedge, or all negedge). | 21:44 |
| kem_ | mithro: Can send along the test case to reproduce? I can try to take a look when I've got a moment. | 21:45 |
| mithro | kem_: Sure | 21:45 |
| mithro | kem_: I'll have a dig a bit further first | 21:46 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!