<omnitechnomancer>
I guess you could move around something using a global clock and try to work out what is up from how the bits change?
<pepijndevos>
This is basically why I abandoned the pure fuzzing approach and aided the process with vendor data.
<pepijndevos>
Yea for global routing that's exactly what I've been doing
<pepijndevos>
For basic routing this would be near impossible though. Like, you don't know which wires exist and have no way of using a specific wire, so it'd be extremely difficult and fragile to try to coerce the IDE to use a particular pip and then figure out what the relevant change is.
<pepijndevos>
But that's basically what I'm doing for clock routing... like, if you use one dff it always use the same clock wire, so you have to use progessively more diffrent clocks and then figure out which one changed
<pepijndevos>
And yea for general routing I extracted a table of wirenames from the vendor tool, but I have yet to find such a table for the clock stuff, so for now all the IDs are a mess.
<pepijndevos>
It's like... oh yea route N324 to A6 and you have to figure out that this routes a certain clock pin to a certain clock wire
<pepijndevos>
The problem with global routing compared to inter-tile routing is that a lot is hardwired, so it does not show up in any bits or file at all, so far.