24 MHz - w=3 (w=2 fails)
200MHz - w=4 (w=3 varies per pin so is on the edge)
300MHz - w=5 (w=4 varies per pin so is on the edge)
Do we know if that is solely on IN or OUT side, or some combinations of both ?
If there are per-pin differences, it likely follows that there are per-temperature differences too.
If marginal cases on the OUT path, could cause jitter at some MHz/Temperature combinations - if this is mostly in the PAD IO, this may also effect Smart Pin generation modes, as well as streamer, in addition to normal IO opcodes.
Maybe this is another contributor to the VGA noise seen ?
.. An I/O pin is big and slow compared to internal signals... Just to implement ESD protection on the I/O pad, you incurr 1000x the capacitive loading of the core-side signals.
Just how slow is the IO path, to Verilog Logic, & how does that vary with temperature (Which I guess includes all Smart Pin IO and Streamer and opcodes ?)
I guess that means another clock delay could appear due to capacitive loading.
Hmm, I've just done a new set of runs and got really outrageously bad results on the FPGA. It might be the first time I've done a large sweep and compared them though.
The lower 40 pins are acting consistently as per all previous statements, but above that things get weird. In some tests they are slow while in others they are crazy fast. There can be 3 clocks difference from the expected outcome.
PS: Even at 20 MHz the pins above #39 are not conforming.
eg: 20 MHz with I/O clocking enabled. WRPIN ##%100<<14
Is that the latest FPGA, or the 'silicon-matching' FPGA ?
The 2 sysclk quata seems strange, (even more at 20MHz) as you would expect one more clock to pass any threshold ?
.. An I/O pin is big and slow compared to internal signals... Just to implement ESD protection on the I/O pad, you incurr 1000x the capacitive loading of the core-side signals.
Just how slow is the IO path, to Verilog Logic, & how does that vary with temperature (Which I guess includes all Smart Pin IO and Streamer and opcodes ?)
I guess that means another clock delay could appear due to capacitive loading.
Yes, not just capacitive loading, but propagation delay within the 3.3V circuitry eats time. Maybe 3ns each way.
Note how the >39 pins are erratic. This hasn't occurred with any other combination of OUT fed back.
Evanh, I don't think these things are anything to get concerned about. The FPGA compiles differently each time, and because I didn't make any timing constraints, pin timing is going to vary with each compile.
Okay, ignoring that there is erratic performance at 80 MHz, the additional 2-clock difference can't be assigned to lose timing. 20 MHz showed the same 2 clocks but without the erratic 3rd clock.
Okay, ignoring that there is erratic performance at 80 MHz, the additional 2-clock difference can't be assigned to lose timing. 20 MHz showed the same 2 clocks but without the erratic 3rd clock.
There's gotta be something new wrong with v33j.
Does what you are seeing make sense if you consider these two things:
1) an extra flop exists now between the physical pin and the smart pin circuitry
2) paths are unconstrained, so there will be timing differences among pins
Here's scope snap of above 80 MHz test of "OUT fed back".
I've zoomed in on two of the pulses of pin42. And added an extra DRVL #38 and OUTH #38 to compare timing. Orange trace is pin38.
Note the equal sized 200 ns pulse lengths for both traces and the single instruction 25 ns phase difference. This is correct of course. But the software testing shows at least an extra two clocks, or 25 ns, for pin42 (green trace). And at 20 MHz it's still two extra clocks, or 100 ns.
Does what you are seeing make sense if you consider these two things:
1) an extra flop exists now between the physical pin and the smart pin circuitry
2) paths are unconstrained, so there will be timing differences among pins
So my answer is no.
PS: Just to reiterate. I'm now chasing a new problem that has shown only in v33j. It's not the jitteriness I'm looking at here. Although I'd dearly love them to be related because they are both an input problem.
To compare with the earlier v32i graphs, here's all six v33j graphs with extra pins up to #61. It's notable that for the four pins above the push buttons, the behaviour reverts to same as pins below #40.
Thanks to Evanh for going over this problem with me on a text chat, where I ran his code to see these strange results.
This made no sense, but after an hour of running his tests and chatting about the strange results, I realized that I had eliminated some smart pins on the Prop123-A9 and BeMicro-A9 images, in order to get them to fit into the FPGA. So, mystery solved! No problem, after all, thank goodness. ON Semi has been carrying forward with the current design and they are deep into place and route, already.
Thanks, Evanh, for noticing this strangeness. This could have been a huge bug.
It's funny. Looking back, it is obvious now that that group of pins never moved their timing when adjusting the pin config. I was totally focused on the relative relationship from expected.
As for the original concern with uncertainty I guess must be as Chip has been saying - the speed of the physical pin turn around. It is clearly completely speed dependant and, for the functioning smartpins, it doesn't show up when OUT feedback is config'd; which bypasses the physical pin drivers and buffers. Or at least it doesn't show up in the FPGA.
I'll have my replacement P2ES EVAL board in a couple of days. I'll test that overclocked.
As for the original concern with uncertainty I guess must be as Chip has been saying - the speed of the physical pin turn around. It is clearly completely speed dependant and, for the functioning smartpins, it doesn't show up when OUT feedback is config'd; which bypasses the physical pin drivers and buffers. Or at least it doesn't show up in the FPGA.
I'll have my replacement P2ES EVAL board in a couple of days. I'll test that overclocked.
Right, done some tests with the replacement P2ES EVAL board and yep, it's amazing how far this effect can go. Eg: The long tracks on the board for the uSD and flash chip are slowing down the upper few pins even more than the rest. At 350 MHz needs w=6 for those few. Or, with clocked I/O, w=8 is required. And those are without the extra flop that is added in the respin.
And again, OUT fed back, even at 350 MHz, is clean at w=2.
Comments
I've covered this before. The FPGA I/O buffer pair takes a total of 2.5 nanoseconds.
PS: And I think that time includes the routing in the ring circuit I put together. Maybe not.
Do we know if that is solely on IN or OUT side, or some combinations of both ?
If there are per-pin differences, it likely follows that there are per-temperature differences too.
If marginal cases on the OUT path, could cause jitter at some MHz/Temperature combinations - if this is mostly in the PAD IO, this may also effect Smart Pin generation modes, as well as streamer, in addition to normal IO opcodes.
Maybe this is another contributor to the VGA noise seen ?
Just how slow is the IO path, to Verilog Logic, & how does that vary with temperature (Which I guess includes all Smart Pin IO and Streamer and opcodes ?)
I guess that means another clock delay could appear due to capacitive loading.
The lower 40 pins are acting consistently as per all previous statements, but above that things get weird. In some tests they are slow while in others they are crazy fast. There can be 3 clocks difference from the expected outcome.
PS: Even at 20 MHz the pins above #39 are not conforming.
Is that the latest FPGA, or the 'silicon-matching' FPGA ?
The 2 sysclk quata seems strange, (even more at 20MHz) as you would expect one more clock to pass any threshold ?
FPGA testing with v32i image and 80 MHz, Clocked I/O:
FPGA testing with v32i image and 80 MHz, Unclocked I/O:
FPGA testing with v32i image and 80 MHz, OUT fed back:
Are the pins near the borders affected by temperature?
Yes, not just capacitive loading, but propagation delay within the 3.3V circuitry eats time. Maybe 3ns each way.
Note how the >39 pins are erratic. This hasn't occurred with any other combination of OUT fed back.
Evanh, I don't think these things are anything to get concerned about. The FPGA compiles differently each time, and because I didn't make any timing constraints, pin timing is going to vary with each compile.
There's gotta be something new wrong with v33j.
Does what you are seeing make sense if you consider these two things:
1) an extra flop exists now between the physical pin and the smart pin circuitry
2) paths are unconstrained, so there will be timing differences among pins
It also by-passes that extra flop because the number of clocks measured is the same for both v32 and v33.
EDIT: Here's the testing source
I've zoomed in on two of the pulses of pin42. And added an extra DRVL #38 and OUTH #38 to compare timing. Orange trace is pin38.
Note the equal sized 200 ns pulse lengths for both traces and the single instruction 25 ns phase difference. This is correct of course. But the software testing shows at least an extra two clocks, or 25 ns, for pin42 (green trace). And at 20 MHz it's still two extra clocks, or 100 ns.
So output timing looks good. Not so for inputs.
EDIT: Detailed phase difference.
PS: Just to reiterate. I'm now chasing a new problem that has shown only in v33j. It's not the jitteriness I'm looking at here. Although I'd dearly love them to be related because they are both an input problem.
v33j image in FPGA at 20 MHz, Clocked I/O:
v33j image in FPGA at 20 MHz, Unclocked I/O:
v33j image in FPGA at 20 MHz, OUT fed back:
v33j image in FPGA at 80 MHz, Clocked I/O:
v33j image in FPGA at 80 MHz, Unclocked I/O:
v33j image in FPGA at 80 MHz, OUT fed back:
And I confirmed it really is 5 MHz. 400 ns per instruction. 3200 ns pulse length.
EDIT: Added source
This made no sense, but after an hour of running his tests and chatting about the strange results, I realized that I had eliminated some smart pins on the Prop123-A9 and BeMicro-A9 images, in order to get them to fit into the FPGA. So, mystery solved! No problem, after all, thank goodness. ON Semi has been carrying forward with the current design and they are deep into place and route, already.
Thanks, Evanh, for noticing this strangeness. This could have been a huge bug.
It certainly is good it was just the FPGA only.
I'll have my replacement P2ES EVAL board in a couple of days. I'll test that overclocked.
I know it's a bit late, but maybe this migt have helped.
https://forums.parallax.com/discussion/164621/detecting-avualable-smart-pins-on-fpga
And updated smartpin checking source. Instructions have changed in two years!
EDIT: Changed search order to use a DJNF instead of REP + ADD
Right, done some tests with the replacement P2ES EVAL board and yep, it's amazing how far this effect can go. Eg: The long tracks on the board for the uSD and flash chip are slowing down the upper few pins even more than the rest. At 350 MHz needs w=6 for those few. Or, with clocked I/O, w=8 is required. And those are without the extra flop that is added in the respin.
And again, OUT fed back, even at 350 MHz, is clean at w=2.