| *** tpb has joined #symbiflow | 00:00 | |
| *** jjjaaaccckkk has joined #symbiflow | 00:08 | |
| az0re | cool, thanks | 00:31 |
|---|---|---|
| *** Bertl_oO is now known as Bertl_zZ | 01:23 | |
| *** duck23 is now known as duck2 | 01:41 | |
| *** proteus-guy has quit IRC | 03:12 | |
| jjjaaaccckkk | why reverse the 7 series and not ultrascale(+)? | 03:25 |
| *** proteus-guy has joined #symbiflow | 03:52 | |
| *** jjjaaaccckkk has quit IRC | 04:02 | |
| *** jjjaaaccckkk has joined #symbiflow | 04:09 | |
| az0re | obviously $$$ | 05:05 |
| *** proteus-guy has quit IRC | 05:53 | |
| *** proteus-guy has joined #symbiflow | 06:36 | |
| *** OmniMancer has joined #symbiflow | 06:48 | |
| *** proteus-guy has quit IRC | 07:15 | |
| *** proteus-guy has joined #symbiflow | 07:27 | |
| *** citypw has joined #symbiflow | 08:34 | |
| daveshah | Having looked at it myself, there's nothing intrinsically more complicated about UltraScale+ | 08:40 |
| daveshah | But 7-series was obviously a simpler and cheaper place to start, and much of the infrastructure would be applicable to both | 08:41 |
| *** rvalles_ has quit IRC | 09:33 | |
| *** rvalles_ has joined #symbiflow | 09:47 | |
| *** Bertl_zZ is now known as Bertl | 10:53 | |
| *** citypw has quit IRC | 11:05 | |
| *** citypw has joined #symbiflow | 11:05 | |
| *** proteus-guy has quit IRC | 11:09 | |
| *** citypw has quit IRC | 11:09 | |
| *** citypw has joined #symbiflow | 11:10 | |
| *** citypw has quit IRC | 11:38 | |
| *** mario_h has joined #symbiflow | 12:23 | |
| *** mario_h has quit IRC | 12:38 | |
| *** OmniMancer has quit IRC | 12:45 | |
| *** killruana_ has quit IRC | 13:48 | |
| *** killruana has joined #symbiflow | 13:59 | |
| *** az0re has quit IRC | 16:32 | |
| jjjaaaccckkk | thanks. should i be good to use Vivado 2018.2? quickstart says 2017.2 | 18:30 |
| hackerfoo | jjjaaaccckkk I think fuzzing requires 2017.2 | 19:03 |
| hackerfoo | https://freenode.irclog.whitequark.org/symbiflow/2019-09-27 | 19:07 |
| tpb | Title: #symbiflow on 2019-09-27 — irc logs at whitequark.org (at freenode.irclog.whitequark.org) | 19:07 |
| hackerfoo | It might be worth filing issues so we know what breaks on later versions of Vivado. | 19:09 |
| litghost | There is already an issue | 19:10 |
| litghost | https://github.com/SymbiFlow/prjxray/issues/14 | 19:12 |
| tpb | Title: MUXF8 vivado compatibility · Issue #14 · SymbiFlow/prjxray · GitHub (at github.com) | 19:12 |
| hackerfoo | litghost: Do you mind if I add a link to the README? | 19:15 |
| litghost | Sure | 19:15 |
| litghost | It is worth noting that some of the reasons MUXF7/8 were being used can be converted to use the "BEL" attribute | 19:17 |
| litghost | However it is likely a decent amount of work to fix this in every fuzzer | 19:17 |
| *** az0re has joined #symbiflow | 20:02 | |
| hackerfoo | Does anyone have an example where VPR fans out a clock before it should? I'm not sure why VPR would fan out too early after a clock buffer. | 20:19 |
| * hackerfoo uploaded an image: clock_network.jpg (345KB) < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/FQMsuINXtKBpKuXbJWRizdRl > | 20:25 | |
| hackerfoo | For example, I made this simple design to see where VPR might go wrong. The clock specific wires are highlighted from the BUFG to the clock sinks. | 20:26 |
| hackerfoo | I don't see how the router could get confused and use general routing fabric after leaving a clock buffer. | 20:28 |
| hackerfoo | Two stage routing seems to put a virtual clock source at a clock buffer, but those have to be instantiated and placed anyway, so it seems like the placer should already do what two stage clock routing would do. | 20:30 |
| hackerfoo | I guess I could try looking at picosoc or something complicated like that with fasm2v. | 20:33 |
| *** az0re has quit IRC | 20:46 | |
| *** adjtm_ has quit IRC | 21:01 | |
| *** adjtm has joined #symbiflow | 21:01 | |
| litghost | > I don't see how the router could get confused and use general routing fabric after leaving a clock buffer. | 21:07 |
| litghost | https://github.com/SymbiFlow/symbiflow-arch-defs/issues/1153#issuecomment-572195411 | 21:07 |
| tpb | Title: Clock signals routed through INT tiles · Issue #1153 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 21:07 |
| *** az0re has joined #symbiflow | 21:08 | |
| hackerfoo | litghost: Thanks | 21:08 |
| litghost | hackerfoo: One thing that we want from 2 phase routing is routing of clocks connections without any other connections, and then looking the | 21:08 |
| litghost | m | 21:08 |
| litghost | hackerfoo: It is worth noting that the issue shown above is not going to be fixed via 2 phase routing, but instead correcting a bug in the graph import | 21:08 |
| litghost | But it is an example of the type of failure you were seeking | 21:08 |
| hackerfoo | If clocks just need to be routed first, it seems that assigning clock networks the maximum criticality would work. | 21:12 |
| hackerfoo | Two stage routing seems to be a solution for a lack of explicit clock buffers. | 21:12 |
| litghost | hackerfoo: Yes and no | 21:15 |
| litghost | hackerfoo: Even if clocks are routed first (via sorting), they will still be eligable for ripup if they are not frozen | 21:15 |
| *** TheHolyC has quit IRC | 21:52 | |
| *** TheHolyC has joined #symbiflow | 21:52 | |
| hackerfoo | I see. I don't think two stage routing is suitable, since it will only freeze up to the virtual clock network root. | 22:03 |
| litghost | Ya | 22:04 |
| litghost | We may need/want to implement an extension on what was commited | 22:04 |
| hackerfoo | This seems like an easier problem to solve, since there's no need to insert a virtual root, which is what I'm stuck on. | 22:05 |
| hackerfoo | Just route clocks, lock the routes, then route everything else. | 22:05 |
| litghost | Ya | 22:06 |
| litghost | There is the additional, sutabler issue of making sure the router doesn't non-dedicated networks | 22:06 |
| litghost | But I don't think the existing VPR code has any concept of clock specific networks | 22:07 |
| hackerfoo | I thought that's what `--clock_modeling dedicated_network` was. | 22:08 |
| hackerfoo | VPR identifies global nets, at least. | 22:11 |
| litghost | I'm not totally confident, but I believe that modifies the rr graph generator | 22:12 |
| litghost | We don't use that | 22:12 |
| litghost | We supply the rr graph | 22:13 |
| hackerfoo | I think nets that are connected to global pins (including clocks) are marked global (read_xml_arch_file.cpp:678): PhysicalTileType->is_pin_global[pin_count] = port.is_clock || port.is_non_clock_global; | 22:18 |
| hackerfoo | I'll have to check. | 22:18 |
| litghost | But we never use global pins in VPR | 22:19 |
| litghost | global pins are magic | 22:19 |
| litghost | For example, VPR can just assume that all IPINs can be tied to 0/1 | 22:19 |
| litghost | Which obviously won't work for us | 22:20 |
| hackerfoo | I see. So this is from VPR ignoring clocks and pretending that every clock pin is connected directly to the clock network (clock_modeling == IDEAL)? | 22:22 |
| hackerfoo | At any rate, it shouldn't be hard to identify nets that connect to clock buffers, so I could do that first, and then later try to force them on clock specific nodes if needed. | 22:29 |
| *** titanbiscuit has quit IRC | 23:23 | |
| *** titanbiscuit has joined #symbiflow | 23:23 | |
| *** adjtm has quit IRC | 23:41 | |
| *** adjtm has joined #symbiflow | 23:41 | |
| *** az0re has quit IRC | 23:50 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!