@ozpropdev - If I use $BF for instance I end up with a very slow jitter so that the frequency sits close around 60MHz but it's not steady as it is with the pure binary dividers.
btw - $9F seems to be jitter free at 50MHZ.
My test setup is to output a 1MHz signal on a pin and then hubset and observe the frequency and jitter. My system always responds to a serial break so I can easily restore control to my console.
1 PIN 1 MHZ
$9F HUBSET
The other way to read it easier is to output 80 kHz and then read kHz as MHz on the scope.
Using same code on pins 1 through 4 always gives a non-zero result. I'm software pulsing the OUT line with a OUTH, take a reading, then OUTL, and another reading.
I'm at the same time sampling the neighbour's IN, which is configured to show me what the test pin's state is.
@ozpropdev - If I use $BF for instance I end up with a very slow jitter so that the frequency sits close around 60MHz but it's not steady as it is with the pure binary dividers.
btw - $9F seems to be jitter free at 50MHZ.
Peter
To be honest I hadn't noticed the jitter in my limited tests at different speeds.
I ran Chip's VGA 640 * 480 demo from 30MHz to 80 MHz in the 5 MHz steps and it all seemed to work Ok.
My monitor might be compensating (hiding) any jitter.
I did the same in a basic serial Tx test from 5 to 80 MHz to verify the 5MHz steps.
All my testing otherwise runs at the max 80MHz.
Ah, you mean timing paths getting stretched into the next clock, right?
The ASIC's timing will be tighter, but to get really exact timing, turn on the clocked modes (WRPIN ##%0000100000000<<8,#pin). The clocked modes register input and output states right on the pin, itself.
Hasn't helped at all. In fact there is even more variations now.
But maybe the most interesting part is it appears to be 100% repeatable. Each run produces the same set of answers. Even Oz posted identical results to me.
Take a look at pins 1 and 2 below. The rise propagation time differs from the fall propagation time but each rerun is completely consistent. It doesn't seem to be a borderline case.
Here's a dump of the lower 60 61 Smartpins. Physical pins 55-57 ($37-$39) seem to be stuck high so that the Z counter accumulates while OUT is low. Maybe a faulty board.
Everything else is fitting what we expect for the moment.
Yes this caught me out early on.
Pins 57..55 input/outputs are split.
The outputs are routed to the header and the inputs are routed to the pushbuttons.
Evanh, you are seeing varying numbers of cycles in your measurements, when you should have a consistent value, since your tests are all identical, right? I haven't loaded any of your code, yet, but I'm wondering if you get inconsistent results even at low frequencies. Is that the case?
Perhaps turning on clocking doesn't cause a timing simplification, because one logic cone just replaces another.
I might be able to remedy this by making timing assignments on the I/O pins, like I had to for the DACs. I just did so and am compiling now.
When I started the coding for this test, I wasn't actually expecting the Smartpins to show the same issue .... I'm now pondering what will happen if one smartpin toggles another.
Okay. I think this is to be expected. The ASIC will not be this loosey-goosey. So, is there really a problem?
I guess I'm not clear about, confident, of that outcome. I can accept the Cogs having this but the Smartpins should be tight enough I'd have thought.
The inputs are all immediately registered when they come in from the pins. It's the outputs that may be causing this.
If you stimulate PinA via the OUTA/OUTB bit, there should be no timing problem. Driving the pin to an output state and then echoing back that state is probably what is taking all the time. Can you please check that?
The instructions used are OUTH and OUTL. I take readings for each. That's doing what you've asked I believe.
The pin direction doesn't change for the duration of each pin being tested.
The Smartpin compares (xor) the OUT signal (from the OUTH/L instruction) with the pin's input signal that follows. The number of clocks they are different for is the accumulated reading.
Then you would be eliminating that analog round trip around the physical pin (in one clock) and you shouldn't see any weirdness at any frequency, because everything would be synchronous.
This blurring is due to the analog pin being driven to a state via its output circuitry, then reading back through its input circuitry, in insufficient time to meet hold timing on the input register.
It looks like my timing assignments are absorbed, finally, so I'm recompiling for the Prop123-A9 with 8 cogs, 512KB, and 64 smart pins. I'll have this posted in the morning.
Comments
EDIT: Good catch there Oz. Totally fixed that problem. Thanks.
EDIT2: So the lesson there is any previous state bits of a Smartpin is retained through a new setup unless they're explicitly set.
SmartPin mode = %01111, Count highs pin# reset pause high......later low.......later 9 00000000 00000000 00000000 00000002 00000002 00000004 ---------\___________________/-------------------\_________00000026 8 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 7 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 6 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 5 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 4 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 3 00000000 00000000 00000000 00000002 00000002 00000004 ---------\___________________/-------------------\_________00000026 2 00000000 00000000 00000000 00000002 00000002 00000004 ---------\___________________/-------------------\_________00000026 1 00000000 00000000 00000000 00000002 00000002 00000004 ---------\___________________/-------------------\_________00000026 0 00000000 00000000 00000000 00000002 00000002 00000004 ---------\___________________/-------------------\_________00000026And (At 40 MHz Sysclock):
SmartPin mode = %01111, Count highs pin# reset pause high......later low.......later 9 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 8 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 7 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 6 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 5 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 4 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 3 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 2 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 1 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 0 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026EDIT: In other words, what affects Chip's example here http://forums.parallax.com/discussion/comment/1426177/#Comment_1426177 is also affecting the much tighter Smartpin circuit.
Which means the supposedly long run routes aren't causing any issues.
Did you try other clock speeds?
@60 Mhz (HUBSET #$BF)
SmartPin mode = %01111, Count highs pin# reset pause high......later low.......later 9 00000000 00000000 00000000 00000001 00000001 00000003 ---------\___________________/-------------------\_________00000026 8 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 7 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 6 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 5 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 4 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 3 00000000 00000000 00000000 00000001 00000001 00000003 ---------\___________________/-------------------\_________00000026 2 00000000 00000000 00000000 00000002 00000002 00000003 ---------\___________________/-------------------\_________00000026 1 00000000 00000000 00000000 00000001 00000001 00000002 ---------\___________________/-------------------\_________00000026 0 00000000 00000000 00000000 00000001 00000001 00000003 ---------\___________________/-------------------\_________00000026btw - $9F seems to be jitter free at 50MHZ.
My test setup is to output a 1MHz signal on a pin and then hubset and observe the frequency and jitter. My system always responds to a serial break so I can easily restore control to my console. The other way to read it easier is to output 80 kHz and then read kHz as MHz on the scope.
After the WRPIN, Did you do the 'WYPIN #0,#0' to count A-highs.
And what about the WXPIN to establish the period?
I'm thinking there might be some old X and Y states left over after booting.
To be honest I hadn't noticed the jitter in my limited tests at different speeds.
I ran Chip's VGA 640 * 480 demo from 30MHz to 80 MHz in the 5 MHz steps and it all seemed to work Ok.
My monitor might be compensating (hiding) any jitter.
I did the same in a basic serial Tx test from 5 to 80 MHz to verify the 5MHz steps.
All my testing otherwise runs at the max 80MHz.
Yep. That's exactly what it was. Oz got me sorted there.
Now the real timing issue with the pins needs sorted. Or at least confirmed that the final ASIC won't have the same differences between pins.
Differences between pins? What do you mean? The ASIC will be like the FPGA with 8 cogs, 512K hub, and 64 smart pins.
Ah, you mean timing paths getting stretched into the next clock, right?
The ASIC's timing will be tighter, but to get really exact timing, turn on the clocked modes (WRPIN ##%0000100000000<<8,#pin). The clocked modes register input and output states right on the pin, itself.
I'm at work at the moment ... so will be some hours to test.
The C, I, and O bits (P[8..6]) are supported.
But maybe the most interesting part is it appears to be 100% repeatable. Each run produces the same set of answers. Even Oz posted identical results to me.
Take a look at pins 1 and 2 below. The rise propagation time differs from the fall propagation time but each rerun is completely consistent. It doesn't seem to be a borderline case.
SmartPin mode = %01111, Count highs pin# reset pause high......later low.......later 9 00000000 00000000 00000000 00000004 00000004 00000008 ---------\___________________/-------------------\_________00000026 8 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 7 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 6 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 5 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 4 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 3 00000000 00000000 00000000 00000004 00000004 00000008 ---------\___________________/-------------------\_________00000026 2 00000000 00000000 00000000 00000003 00000003 00000007 ---------\___________________/-------------------\_________00000026 1 00000000 00000000 00000000 00000003 00000003 00000007 ---------\___________________/-------------------\_________00000026 0 00000000 00000000 00000000 00000004 00000004 00000008 ---------\___________________/-------------------\_________00000026Here's a dump of the lower 60 61 Smartpins. Physical pins 55-57 ($37-$39) seem to be stuck high so that the Z counter accumulates while OUT is low. Maybe a faulty board.
Everything else is fitting what we expect for the moment.
Pins 57..55 are wired to the pushbuttons on the P123-A9 board.
Pins 57..55 input/outputs are split.
The outputs are routed to the header and the inputs are routed to the pushbuttons.
Perhaps turning on clocking doesn't cause a timing simplification, because one logic cone just replaces another.
I might be able to remedy this by making timing assignments on the I/O pins, like I had to for the DACs. I just did so and am compiling now.
SmartPin mode = %01111, Count highs pin# reset pause high......later low.......later 09 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 08 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 07 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 06 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 05 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 04 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 03 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 02 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 01 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026 00 00000000 00000000 00000000 00000003 00000003 00000006 ---------\___________________/-------------------\_________00000026- With registered pins, it's 3 clocks per transition.
- Without registered pins, it's 1 clock per transition.
At 80 MHz,
- With registered pins, it's 3 or 4 clocks per transition.
- Without registered pins, it's 1 or 2 clocks per transition.
I guess I'm not clear about, confident, of that outcome. I can accept the Cogs having this but the Smartpins should be tight enough I'd have thought.
The inputs are all immediately registered when they come in from the pins. It's the outputs that may be causing this.
If you stimulate PinA via the OUTA/OUTB bit, there should be no timing problem. Driving the pin to an output state and then echoing back that state is probably what is taking all the time. Can you please check that?
The pin direction doesn't change for the duration of each pin being tested.
The Smartpin compares (xor) the OUT signal (from the OUTH/L instruction) with the pin's input signal that follows. The number of clocks they are different for is the accumulated reading.
Then you would be eliminating that analog round trip around the physical pin (in one clock) and you shouldn't see any weirdness at any frequency, because everything would be synchronous.
This blurring is due to the analog pin being driven to a state via its output circuitry, then reading back through its input circuitry, in insufficient time to meet hold timing on the input register.