Will the new boards have a TCXO? I think it might justify. Doesn't need to be an expensive one, since the extra precision is not critical: the only thing critical is the stability (maybe Stratum 3 compliant).
Kind regards, Samuel Lourenço
It's too late for the next batch of boards, but we could do that on the round after.
I did one more test on v2 silicon where I set the crystal divider to 1 and the multiplier to 16, in order to get 320MHz. This means that PLL corrections come 40x more frequently than they did in the previous tests, so there's less opportunity for jitter to develop. I ran the temperature from room ambient to 110 C and back down to room ambient.
I don't think there's more than 750ps of jitter here:
That's good to see. How does that vary with the XTAL Divider ? (aka PFD MHz)
The bigger the divider, the more jitter you get. I don't have a number, but dividing 20MHz by 40 results in 4ns of jitter, across temperature.
Actually, I've been measuring the jitter from my 20MHz function generator that I was using for the P2 jitter test, and it's about 1200ps. Maybe we are way less than 750ps. Hard to say, but it seems plenty good to me. This matter of the I/O pins being so much slower than the core, though, is something to evaluate.
I just had an epiphany: The reason the I/Os are working so much more consistently at high-frequency on the v2 silicon is because they were all skew-banded to within 1ns of eachother. Now, they all start missing data at nearly the same temp/frequency, confining their window of ambiguity between new and old data.
As temperature slowly rises while the part is running very fast, here is what the pin registers see, coming from the core:
1) New data
2) Ambiguous data
3) Old data, due to internal propagation delay within the 3.3V pad circuitry
Its good that you could see things similar to what we saw, Chip.
Since self heating has been greatly reduced, I don't think it will be much of a problem unless things are massively overclocked *and* the P2 is in an enclosure where the heat can't get away.
Chip, based on these observations, I can't wait to "listen" to the new VCO on my service monitor! As I recall, with the best divider /2, I saw about 3Khz of phase noise at 250Mhz. I bet we will see a full quieting signal with 0Khz of phase noise in the new silicon. I never saw a change in jitter based solely on heating, only by changing the divisor.
Chip, based on these observations, I can't wait to "listen" to the new VCO on my service monitor! As I recall, with the best divider /2, I saw about 3Khz of phase noise at 250Mhz. I bet we will see a full quieting signal with 0Khz of phase noise in the new silicon. I never saw a change in jitter based solely on heating, only by changing the divisor.
So excited about this refined version!
That's a great idea!
I had a little handheld radio that you could listen to any frequency with. I wonder where it is.
Well, I could just use an FM radio, I suppose. What warble's at 250MHz would probably do so at 100MHz, too.
It would be easy for me to test the two silicon versions like this.
Its good that you could see things similar to what we saw, Chip.
Since self heating has been greatly reduced, I don't think it will be much of a problem unless things are massively overclocked *and* the P2 is in an enclosure where the heat can't get away.
That's what I'm thinking.
We need to find out, though, if there's a frequency at which this new-to-old data ambiguity occurs at room temperature.
Does the lower power mean less ADC noise? It would be good to see some images of Sinc2/Sinc3/Scope instruction in action some time, the details of which have largely evaporated from my mind by now!
Yes how fast do you need to run the P2r2 for it to reach 67C at "typical" ambient temps with simple air based convective cooling I wonder. Hopefully it's something extreme and not in a useful zone of operation at 250MHz for HDMI etc.
You wouldn't get to 67 C with P2ES at all, in free air. I doubt you'd get there with P2D2, with the new efficiency of v2 silicon. So it's somewhat contrived fringe issue, but its always good to know just how much margin you have, when designing things.
I keep wracking my brain, trying to figure out if there's anything else I need to be worrying about, at this point. I'll probably transition back to working on Spin2 tomorrow.
I keep wracking my brain, trying to figure out if there's anything else I need to be worrying about, at this point. I'll probably transition back to working on Spin2 tomorrow.
Meanwhile, I discovered that I can signal 1080p24 in analog Y-Pb-Pr. The pixel rate is only 59.4MHz. 1080p30 works, as well, with a pixel rate of 74.25MHz.
All I have is a wireless mouse and it just flashes the LED on P56 when I plug it in. Does it not work with wireless mice?
I've not run it, but I find these comments
ersmith says : I've tried several mice now and they've worked fine. Unfortunately I'm having trouble with keyboards. I've tried two keyboards. The first wasn't detected properly (it triggered the DEV_UNKNOWN "Boot protocol keyboard/mouse not found") so perhaps it just doesn't support boot protocol?
The second was a wireless combo keyboard/mouse; the mouse part works fine, but only a few function keys are recognized and they're completely wrong (e.g. F1 is coming out as 'd' and F2 as backspace).
and garryj says : Yes, during device enumeration "boot protocol" interfaces must be defined. I have an early MS wireless keyboard/mouse combo where the keyboard supported boot protocol and the mouse did not. Are the keyboards wired, or wireless? If the device is wireless and BlueTooth it's likely it won't work, as it appears that BlueTooth devices that support boot protocol are pretty rare.
So it seems it pivots on the boot protocol support. A dusty drawer somewhere usually has a wired mouse ?
Meanwhile, I discovered that I can signal 1080p24 in analog Y-Pb-Pr. The pixel rate is only 59.4MHz. 1080p30 works, as well, with a pixel rate of 74.25MHz.
Great Chip. Now wondering who will be first to stream uncompressed or even lightly compressed 4:2:2 video from the P2 at that rate and in HD resolution? I guess some of the old PATA type HDD's might even be usable for doing large amounts of video storage at those transfer rates with a 16 bit bus. I think they used to transfer up to 133-166MB/s didn't they? What speeds they could actually sustain is an unknown though.
What other large storage (tens of GB's) could the P2 "easily" use that would support these HD video bandwidths I wonder.
I had to change >< to REV and also decrement the 2nd term, since the new REV is in terms of MSB position, not number of bits.
It doesn't light up the LEDs as described in the documentation, but it does report button, X, and Y changes serially at 2MB. So, it's obviously working.
I had to change >< to REV and also decrement the 2nd term, since the new REV is in terms of MSB position, not number of bits.
It doesn't light up the LEDs as described in the documentation, but it does report button, X, and Y changes serially at 2MB. So, it's obviously working.
Glad you got it working, and thanks for the notes regarding the V2 silicon PNut changes! My apologies for getting a bit lazy on the LED assignments whilst moving from FPGA->P2-Eval + Serial Host add-on.
How does the RCFAST, RCSLOW and Icc During reset and Static Icc compare with the previous ES1 ?
I think RCFAST and RCSLOW target MHz did not change, so any MHz/kHz changes there could indicate across-batch variations ?
Static Icc is likely unchanged ?
Icc During RESN=0 could be lower, if clock gating is applied ?
20 MHz is equivalent to RCFAST. So under half power for that.
It looks like a slight proportional increase at slower clock frequencies. So 20 kHz RCSLOW will likely be above the half power mark. The rest would be a wild guess I my behalf.
Chip: Did you ever hear from On Semi about when they can deliver chips in the production packages?
We're being held up by testing troubles.
On their test setup, they are getting huge currents on random VIO pins, on both dies and packaged parts. When we put a packaged chip on an Eval board, though, there are no high currents. It's not making any sense.
All my time has been going to resolve this problem.
Comments
It's too late for the next batch of boards, but we could do that on the round after.
The bigger the divider, the more jitter you get. I don't have a number, but dividing 20MHz by 40 results in 4ns of jitter, across temperature.
Actually, I've been measuring the jitter from my 20MHz function generator that I was using for the P2 jitter test, and it's about 1200ps. Maybe we are way less than 750ps. Hard to say, but it seems plenty good to me. This matter of the I/O pins being so much slower than the core, though, is something to evaluate.
As temperature slowly rises while the part is running very fast, here is what the pin registers see, coming from the core:
1) New data
2) Ambiguous data
3) Old data, due to internal propagation delay within the 3.3V pad circuitry
Since self heating has been greatly reduced, I don't think it will be much of a problem unless things are massively overclocked *and* the P2 is in an enclosure where the heat can't get away.
So excited about this refined version!
That's a great idea!
I had a little handheld radio that you could listen to any frequency with. I wonder where it is.
Well, I could just use an FM radio, I suppose. What warble's at 250MHz would probably do so at 100MHz, too.
It would be easy for me to test the two silicon versions like this.
That's what I'm thinking.
We need to find out, though, if there's a frequency at which this new-to-old data ambiguity occurs at room temperature.
You wouldn't get to 67 C with P2ES at all, in free air. I doubt you'd get there with P2D2, with the new efficiency of v2 silicon. So it's somewhat contrived fringe issue, but its always good to know just how much margin you have, when designing things.
Yes. In the case of DACs, though, it is always registered. Same with ADC.
Has the USB code been verified as OK on ES2 ?
No. Is there some of Garryj's code I could run?
Maybe here ?
http://forums.parallax.com/discussion/170149/p2-hosted-usb-keyboard-mouse
Thanks. I just loaded up the file and made some operator changes to get it to compile in PNut (|< became DECOD and >< became REV).
I un-commented the code that sets up for v2 silicon.
All I have is a wireless mouse and it just flashes the LED on P56 when I plug it in. Does it not work with wireless mice?
ersmith says : I've tried several mice now and they've worked fine. Unfortunately I'm having trouble with keyboards. I've tried two keyboards. The first wasn't detected properly (it triggered the DEV_UNKNOWN "Boot protocol keyboard/mouse not found") so perhaps it just doesn't support boot protocol?
The second was a wireless combo keyboard/mouse; the mouse part works fine, but only a few function keys are recognized and they're completely wrong (e.g. F1 is coming out as 'd' and F2 as backspace).
and garryj says :
Yes, during device enumeration "boot protocol" interfaces must be defined. I have an early MS wireless keyboard/mouse combo where the keyboard supported boot protocol and the mouse did not. Are the keyboards wired, or wireless? If the device is wireless and BlueTooth it's likely it won't work, as it appears that BlueTooth devices that support boot protocol are pretty rare.
So it seems it pivots on the boot protocol support. A dusty drawer somewhere usually has a wired mouse ?
Great Chip. Now wondering who will be first to stream uncompressed or even lightly compressed 4:2:2 video from the P2 at that rate and in HD resolution? I guess some of the old PATA type HDD's might even be usable for doing large amounts of video storage at those transfer rates with a 16 bit bus. I think they used to transfer up to 133-166MB/s didn't they? What speeds they could actually sustain is an unknown though.
What other large storage (tens of GB's) could the P2 "easily" use that would support these HD video bandwidths I wonder.
I had to change >< to REV and also decrement the 2nd term, since the new REV is in terms of MSB position, not number of bits.
It doesn't light up the LEDs as described in the documentation, but it does report button, X, and Y changes serially at 2MB. So, it's obviously working.
I looked under my son's bed and found just such a mouse.
Glad you got it working, and thanks for the notes regarding the V2 silicon PNut changes! My apologies for getting a bit lazy on the LED assignments whilst moving from FPGA->P2-Eval + Serial Host add-on.
I see garryj used it to declare constants like this:
' USB CRC constants: USB5_POLY = %0_0101 >< 5 ' USB5 polynomial is reflected when calculating CRCBTW: The forum search tool doesn't like >< for some reason...
I think RCFAST and RCSLOW target MHz did not change, so any MHz/kHz changes there could indicate across-batch variations ?
Static Icc is likely unchanged ?
Icc During RESN=0 could be lower, if clock gating is applied ?
20 MHz is equivalent to RCFAST. So under half power for that.
It looks like a slight proportional increase at slower clock frequencies. So 20 kHz RCSLOW will likely be above the half power mark. The rest would be a wild guess I my behalf.
Bump.
A brief mention that "the ADC and DAC stuff seems to work fine" but nothing specific on some of the interesting new features.
We're being held up by testing troubles.
On their test setup, they are getting huge currents on random VIO pins, on both dies and packaged parts. When we put a packaged chip on an Eval board, though, there are no high currents. It's not making any sense.
All my time has been going to resolve this problem.