<hackerfoo>
litghost: Do you mind if I add a link to the README?
<litghost>
Sure
<litghost>
It is worth noting that some of the reasons MUXF7/8 were being used can be converted to use the "BEL" attribute
<litghost>
However it is likely a decent amount of work to fix this in every fuzzer
az0re has joined #symbiflow
<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.
<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.
<hackerfoo>
I don't see how the router could get confused and use general routing fabric after leaving a clock buffer.
<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.
<hackerfoo>
I guess I could try looking at picosoc or something complicated like that with fasm2v.
az0re has quit [Remote host closed the connection]
adjtm_ has quit [Read error: Connection reset by peer]
adjtm has joined #symbiflow
<litghost>
> I don't see how the router could get confused and use general routing fabric after leaving a clock buffer.
<tpb>
Title: Clock signals routed through INT tiles · Issue #1153 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
az0re has joined #symbiflow
<hackerfoo>
litghost: Thanks
<litghost>
hackerfoo: One thing that we want from 2 phase routing is routing of clocks connections without any other connections, and then looking the
<litghost>
m
<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
<litghost>
But it is an example of the type of failure you were seeking
<hackerfoo>
If clocks just need to be routed first, it seems that assigning clock networks the maximum criticality would work.
<hackerfoo>
Two stage routing seems to be a solution for a lack of explicit clock buffers.
<litghost>
hackerfoo: Yes and no
<litghost>
hackerfoo: Even if clocks are routed first (via sorting), they will still be eligable for ripup if they are not frozen
TheHolyC has quit [Max SendQ exceeded]
TheHolyC has joined #symbiflow
<hackerfoo>
I see. I don't think two stage routing is suitable, since it will only freeze up to the virtual clock network root.
<litghost>
Ya
<litghost>
We may need/want to implement an extension on what was commited
<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.
<hackerfoo>
Just route clocks, lock the routes, then route everything else.
<litghost>
Ya
<litghost>
There is the additional, sutabler issue of making sure the router doesn't non-dedicated networks
<litghost>
But I don't think the existing VPR code has any concept of clock specific networks
<hackerfoo>
I thought that's what `--clock_modeling dedicated_network` was.
<hackerfoo>
VPR identifies global nets, at least.
<litghost>
I'm not totally confident, but I believe that modifies the rr graph generator
<litghost>
We don't use that
<litghost>
We supply the rr graph
<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;
<hackerfoo>
I'll have to check.
<litghost>
But we never use global pins in VPR
<litghost>
global pins are magic
<litghost>
For example, VPR can just assume that all IPINs can be tied to 0/1
<litghost>
Which obviously won't work for us
<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)?
<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.
titanbiscuit has quit [Ping timeout: 268 seconds]
titanbiscuit has joined #symbiflow
adjtm has quit [Remote host closed the connection]