<pepijndevos>
mystery is where mystery bits come from [thinky face]
<omnitechnomancer>
Elder Gods?
<pepijndevos>
yea, probably
<pepijndevos>
It's soooo weird...
<pepijndevos>
So there are these two bits in the general area where other global config bits are
<pepijndevos>
And they are set in a blinky vendor bitstream
<pepijndevos>
but I'm trying to reproduce it in my fuzzers and failing.
<pepijndevos>
Tempted to just hardcode it somehow...
<omnitechnomancer>
Hmmmm
<pepijndevos>
Verified my conditional breakpoint triggers when the mystery bit is set, and then ran the full fuzzer without it getting triggered
<omnitechnomancer>
hmmmmm, what do these mystery bits do I wonder
<pepijndevos>
That makes two of us
<omnitechnomancer>
what is the breakpoint conditioned on?
<pepijndevos>
bitmap[3][-2]
<pepijndevos>
maybe I'll call these bits IS_BLINKY_A and IS_BLINKY_B
<omnitechnomancer>
heh
<pepijndevos>
I added like half a blinky to my fuzzer, still nope.
<pepijndevos>
I think I'll first verify that setting these bits actually makes the thing work.
<pepijndevos>
And wth maybe just hardcode them.
<daveshah>
Are you using an otherwise similar flow (eg config settings etc) between the blinky and the other fuzzers?
<pepijndevos>
i... think so
<pepijndevos>
hm worth doublechecking
FabM has quit [Quit: Leaving]
<daveshah>
Another random thought is that it could be related to use of dedicated clock input pins
<pepijndevos>
Nah, the first thing I looked at is what changed when enabling a dedicated clock input. That should also be triggered by the fuzzers then
<pepijndevos>
One weird thing I'm noticing is a GSR (global set reset) instance tied to VCC...
<pepijndevos>
This is something I have not fuzzed yet.
<pepijndevos>
Doing some digging through the vendor fuse file...
<pepijndevos>
the two bits are actually from entirely different tables.
<pepijndevos>
One has just a single entry, the other has pretty much all of the other global config bits.
<pepijndevos>
Added the mystery bits, no change. So they must be some unrelated config bs.
<pepijndevos>
So something about the clock routing appears actually wrong.
<pepijndevos>
I'm thinking I'm adding *too much* aliases somehow. Because I can correctly decode vendor bitstreams, but not generate working ones.
<pepijndevos>
So I imagine I created some connection that does not exist in reality, and nexpnr thinks stuff is connected, while it's not.
<pepijndevos>
I'll refactor the clock fuzzer tomorrow...
<daveshah>
That seems plausible
<daveshah>
Could also accidentally be treating a real pip as an alias and not outputting bits for it correctly?
<pepijndevos>
in that case it would not decode correctly, right?
<pepijndevos>
(btw I wrote a "repacker" that just unpacks a bitstream and writes all bels and pips back, and that works)
<omnitechnomancer>
I remember when I was fuzzing routing I had to change it to use a tile in the middle of the grid or it assumes the edge cases work everywhere, which results in bad pnr