| *** tpb has joined #symbiflow | 00:00 | |
| *** epony has joined #symbiflow | 00:11 | |
| *** Degi_ has joined #symbiflow | 00:30 | |
| *** Degi has quit IRC | 00:31 | |
| *** Degi_ is now known as Degi | 00:31 | |
| *** epony has quit IRC | 00:42 | |
| *** krogozinski has quit IRC | 00:43 | |
| *** krogozinski has joined #symbiflow | 00:44 | |
| *** cr1901_modern1 has joined #symbiflow | 00:50 | |
| *** cr1901_modern has quit IRC | 00:53 | |
| *** cr1901_modern1 has quit IRC | 00:54 | |
| *** cr1901_modern has joined #symbiflow | 00:55 | |
| *** epony has joined #symbiflow | 01:13 | |
| *** epony has quit IRC | 01:26 | |
| *** epony has joined #symbiflow | 02:48 | |
| *** gsmecher has joined #symbiflow | 03:09 | |
| *** epony has quit IRC | 03:24 | |
| *** gsmecher has quit IRC | 04:03 | |
| *** cr1901_modern has quit IRC | 05:51 | |
| *** kgugala_ has joined #symbiflow | 06:00 | |
| *** kgugala has quit IRC | 06:04 | |
| *** ZipCPU has quit IRC | 06:19 | |
| *** kgugala has joined #symbiflow | 06:19 | |
| *** ZipCPU has joined #symbiflow | 06:19 | |
| *** kgugala has quit IRC | 06:19 | |
| *** kgugala_ has quit IRC | 06:20 | |
| *** kgugala has joined #symbiflow | 06:20 | |
| *** perillamint has quit IRC | 08:23 | |
| *** y2kbugger has quit IRC | 08:24 | |
| *** ovf has quit IRC | 08:24 | |
| *** tannewt has quit IRC | 08:24 | |
| *** elms has quit IRC | 08:26 | |
| *** perillamint has joined #symbiflow | 08:30 | |
| *** y2kbugger has joined #symbiflow | 08:30 | |
| *** tannewt has joined #symbiflow | 08:30 | |
| *** ovf has joined #symbiflow | 08:30 | |
| *** elms has joined #symbiflow | 08:30 | |
| *** TMM has quit IRC | 09:47 | |
| *** TMM has joined #symbiflow | 09:47 | |
| *** cr1901_modern has joined #symbiflow | 10:31 | |
| -_whitenotifier-3- [fpga-interchange-schema] gatecat opened issue #44: Macro (and similar) placement constraints - https://git.io/JOFkR | 10:44 | |
| *** kgugala_ has joined #symbiflow | 11:37 | |
| *** kgugala has quit IRC | 11:37 | |
| mithro | This is so cool -> https://github.com/nobodywasishere/sphinx-pcbdraw | 11:41 |
|---|---|---|
| tnt | mithro: the issue is you need svg drawing version of all the components you use to look decent ... it can't use the 3d models from kicad. | 12:02 |
| mithro | gatecat: Are Issues #43, #42 and #40 on FPGA Interchange Schema related? | 12:44 |
| mithro | gatecat: I guess that should have been pull requests -- and Issues #44 / #41? | 12:45 |
| gatecat | mithro: yes and #42 contains #40 in it | 12:45 |
| gatecat | issue #44 is a wider issue | 12:45 |
| mithro | gatecat: My current thinking (and it's open to changing) is that "Macros" are actually just a shorthand for a given set of BELs configured a certain way. The synthesis tool should expand the macros into the BELs so that the PnR tool doesn't need to care. There might be a reason for the synthesis tool to indicate to the PnR tool that these BELs are all part of a "macro" and the PnR tool should keep them together.... | 12:53 |
| gatecat | there are some problems here with the logical netlist, among other things | 12:53 |
| gatecat | in any event, doing macro expansion in PnR is not onerous, and keeps the whole flow neater as it is fully netlist compatible with the vendor tools throughout then | 12:54 |
| mithro | Well in some ways, this is our chance to change vendor tools behaviour -- so it would be good to think about how we want things to be done verses how the vendor tools do them | 12:56 |
| gatecat | I personally think this way is neater | 12:56 |
| mithro | gatecat: Is the macro expansion likely to be identical for all PnR tools? | 12:58 |
| gatecat | it depends, as some tools might want to represent hierarchy in different ways (or indeed never expand the macro but place it as one unit) | 12:59 |
| gatecat | the names of the subcells that it expands into is well defined and basically the same throughout | 12:59 |
| gatecat | I personally think that netlist compatibility with existing flows is important, for the simple reason of avoiding the need for extra synthesis steps for interchange flows which will make them appear inherently messier | 13:01 |
| mithro | gatecat: Thinking about #44 -- I'm on the side of "describe the device" with potential "hints for place and route tooling" | 13:02 |
| gatecat | mithro: right, the big question is how much in the way of "hints for place and route tooling" you have | 13:02 |
| gatecat | that's the whole premise behind #44 | 13:02 |
| mithro | gatecat: Can we separate them though? IE The place and route tool should still *work* when the hints data is discarded, it just has to potentially work harder? | 13:03 |
| gatecat | that's basically the state of things at the moment | 13:03 |
| gatecat | it already will figure things out from the site routing - the problem isn't just having to work harder, but also that it currently doesn't figure things out but effectively bruteforces them so there are QoR issues too | 13:04 |
| gatecat | although this is partly due to some wider and nextpnr-specific issues with how the post-placement refinement works | 13:04 |
| mithro | gatecat: For the RAM128XD example -- what could you add an example of what the "right" version would look like verse the "quirky" placement? | 13:06 |
| gatecat | mithro: updated | 13:10 |
| mithro | @gatecat Where are the RAM blocks in your first diagram? | 13:11 |
| gatecat | in totally different sites | 13:11 |
| gatecat | (the key thing to highlight was how LUT route-throughs enable a questionable placement of the MUXFs) | 13:12 |
| mithro | gatecat: Isn't this the issue that the MUX was placed without considering delay? | 13:13 |
| gatecat | yes, the lack of timing data and strong pull from the IO probably isn't helping | 13:13 |
| gatecat | but still, it will take a lot of luck for it to end up in the right site | 13:14 |
| gatecat | and without placement constraints, it will be a hard job for SA to swap them all at once (but this more of a nextpnr specific issue) | 13:14 |
| mithro | gatecat: I would be very surprised if the delay between the LUT output and the MUX input direct path is anything but the fastest? | 13:15 |
| gatecat | right, but there are always other things pulling the muxes and LUTs in the other direction | 13:15 |
| gatecat | the placer has other objectives than the delay (which isn't in the data at all atm...) of that one path | 13:15 |
| mithro | What are the other objectives? | 13:16 |
| gatecat | all the other nets | 13:17 |
| *** kgugala has joined #symbiflow | 13:17 | |
| *** kgugala_ has quit IRC | 13:20 | |
| mithro | @gatecat I still think I'm missing something here, the 4 nets that are involved on that MUX are the two inputs, the select and the output right? The two inputs are direct output from the LUTs right? | 13:21 |
| gatecat | yes, correct | 13:21 |
| mithro | https://docs.google.com/drawings/d/1lsQoNXkf-aCgTQ1Wo5tHRLiBWuo2yscUpKxD9wb07qY/edit | 13:27 |
| tpb | Title: RAM128X1D Placement - Google Zeichnungen (at docs.google.com) | 13:27 |
| gatecat | mithro: imagine a simple chain: input->LUT->mux->output - the natural placement will be the LUT and mux at 1/3 and 2/3 respectively | 13:28 |
| gatecat | because there's nothing specifically telling the placer - and you can argue that it should see the dedicated path, and I agree that's fair but isn't happening atm - that the LUT and mux should actually belong together | 13:29 |
| *** epony has joined #symbiflow | 13:36 | |
| mithro | gatecat: `D2_1` must be much greater than `D1_1`, right? | 13:36 |
| gatecat | mithro: yes, and of course an ideal placer should take that into account, but everything is based on heuristics and sometimes those don't work quite as well as you want | 13:37 |
| mithro | gatecat: I guess this is the advantage of the current VPR approach of clustering things together before placement | 13:39 |
| gatecat | sure | 13:39 |
| gatecat | the big question is to what extent the interchange format should contain explicit hints for that clustering; and other similar problems like global clock structures (e.g. https://github.com/SymbiFlow/nextpnr/issues/263) | 13:40 |
| *** rj has joined #symbiflow | 14:36 | |
| *** epony has quit IRC | 14:43 | |
| *** rj has quit IRC | 14:59 | |
| *** rj has joined #symbiflow | 15:04 | |
| *** nickoe has quit IRC | 15:35 | |
| *** rj has quit IRC | 15:57 | |
| *** rj has joined #symbiflow | 15:59 | |
| *** gsmecher has joined #symbiflow | 16:13 | |
| *** epony has joined #symbiflow | 16:19 | |
| *** toshywoshy has quit IRC | 16:54 | |
| *** toshywoshy has joined #symbiflow | 16:59 | |
| *** epony has quit IRC | 17:06 | |
| *** umarcor|2 has quit IRC | 17:10 | |
| *** umarcor|2 has joined #symbiflow | 17:10 | |
| *** umarcor has joined #symbiflow | 17:13 | |
| *** umarcor|2 has quit IRC | 17:13 | |
| *** umarcor|2 has joined #symbiflow | 17:17 | |
| *** umarcor has quit IRC | 17:17 | |
| *** nickoe has joined #symbiflow | 17:20 | |
| *** tnt has quit IRC | 18:05 | |
| *** tnt has joined #symbiflow | 18:06 | |
| CarlosEDP | Got my first PR merged! Thanks mithro! https://github.com/SymbiFlow/yosys-symbiflow-plugins/pull/106 | 20:30 |
| CarlosEDP | How is tha packaging and versioning for these plugins? Like.. when will Yosys ship with it? | 20:31 |
| *** epony has joined #symbiflow | 20:32 | |
| *** rj has quit IRC | 21:56 | |
| *** epony has quit IRC | 22:06 | |
| Lofty | CarlosEDP: "it won't" | 22:43 |
| CarlosEDP | Humm... is there any instructions on how to package it with a toolchain? | 23:16 |
| *** epony has joined #symbiflow | 23:16 | |
| CarlosEDP | * Humm... are there any instructions on how to package it with a toolchain? | 23:20 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!