Well, few people really, which is why you can get 4:3 and 5:4 monitors of average quality fairly cheap. Altough those often don't have DVI / HDMI anyways.
Would 1080i work though?
The P2 can signal 1080p over 3 pins in analog. Pixel rate is 148.5MHz.
Since the new revision uses half the power and gets barely warm at 390MHz, I guess that it is possible to raise the nominal frequency from 180MHz to 240MHz, with margin for overclocking?
I mean, 240MHz would be an important milestone, and higher specs would mean higher sales, possibly. But I'm just speculating. I'm eager to see the new specs.
By the way, when will the new boards be available for sale?
Since the new revision uses half the power and gets barely warm at 390MHz, I guess that it is possible to raise the nominal frequency from 180MHz to 240MHz, with margin for overclocking?
I mean, 240MHz would be an important milestone, and higher specs would mean higher sales, possibly. But I'm just speculating. I'm eager to see the new specs.
By the way, when will the new boards be available for sale?
Kind regards, Samuel Lourenço
Yes, we've got huge temperature margins in the design. We designed for -40C to 85C ambient temperature. For the hot end, we figured on a junction temperature of 150C, allowing for lots of self-heating. 150C is 65C over 85C. With this reduced power dissipation, we don't need 65C of margin, but since it's there, it means we could run way faster than 175MHz or boost the 85C figure up a ways. We will eventually work with ON Semi to determine a 2-D graph of ambient temperature vs. max frequency.
When the new boards will be available depends on when we get real packaged chips, not these glob-tops. That is looking like a few weeks, at least, maybe a month.
All day I worked on a reduced-power I/O test program for ON Semi's wafer prober, so we don't burn up the probe cards again. I've got the program's 1.8V core current down to 52mA, from the original 440mA. It should be way safer to use on the prober now.
Imagine how expensive and delicate this probe card must be. Wouldn't want to damage this thing.
This gave an opportunity to push the PLL to extremes to see if it jitters badly.
I set the crystal divider to 64, so that 20MHz becomes 312.5KHz. Then, I multiply it in the VCO by 256 to get 80MHz. That VCO frequency is then used directly for the system clock... No pixel shimmying, at all. I tried a range of PLL configurations and I can't get any visible shimmying. So, the PLL seems to be in order now.
Here's the code:
'*************************************
'* VGA 640 x 480 x 16bpp 5:6:5 RGB *
'*************************************
CON
intensity = 80 '0..128
fclk = 80_000_000.0
fpix = 25_000_000.0
fset = (fpix / fclk * 2.0) * float($4000_0000)
vsync = 4 'vsync pin (all FPGA boards now)
DAT org
'
'
' Setup
'
hubset clkinit1 'set clock to 80MHz
waitx clkwait
hubset clkinit2
rdfast ##640*350*2/64,##$1000 'set rdfast to wrap on bitmap
setxfrq ##round(fset) 'set transfer frequency to 25MHz
setcy ##intensity << 24 'r set colorspace for rgb
setci ##intensity << 16 'g
setcq ##intensity << 08 'b
setcmod #%01_0_000_0 'enable colorspace conversion (may be commented out)
wrpin dacmode_hsy,#0<<6 + 0 'enable dac mode in pin 0 for hsync
wrpin dacmode_rgb,#2<<6 + 1 'enable dac modes in pins 1..3 for rgb
drvl #3<<6 + 0 'enable dac outputs
'
'
' Field loop
'
field mov x,#90 'top blanks
call #blank
mov x,#350 'set visible lines
line call #hsync 'do horizontal sync
xcont m_rf,#1 'visible line
djnz x,#line 'another line?
mov x,#83 'bottom blanks
call #blank
drvnot #vsync 'sync on
mov x,#2 'sync blanks
call #blank
drvnot #vsync 'sync off
jmp #field 'loop
'
'
' Subroutines
'
blank call #hsync 'blank lines
xcont m_vi,#0
_ret_ djnz x,#blank
hsync xcont m_bs,#0 'horizontal sync
xzero m_sn,#1
_ret_ xcont m_bv,#0
'
'
' Initialized data
'
clkinit1 long %1_111111_0011111111_1111_10_00 '20MHz / 1 * 4 * 1 = 80MHz
clkinit2 long %1_111111_0011111111_1111_10_11
clkwait long 20_000_000 / 200
dacmode_hsy long %0000_0000_000_1011000000000_01_00000_0 '123-ohm 3.3V
dacmode_rgb long %0000_0000_000_1011100000000_01_00000_0 '75-ohm 2.0V
m_bs long $7F010000+16 'before sync
m_sn long $7F010000+96 'sync
m_bv long $7F010000+48 'before visible
m_vi long $7F010000+640 'visible
m_rf long $BF050000+640 'visible rfword rgb16 (5:6:5)
x res 1
y res 1
'
'
' Bitmap
'
orgh $1000 - 70 'justify pixels at $1000
file "birds_16bpp.bmp" 'rayman's picture (640 x 350)
I just did another experiment where I divided the 20MHz crystal by 64 and then multiplied it by 80 to get 25MHz. Still, no pixel shimmying. This is significant because at lower VCO frequencies, things are less stable. I can't see any instability, which is surprising to me.
So, the chip is running at 25MHz, outputting a VGA display with that same pixel rate, and drawing only 33mA at 1.8V.
This IQ modulator was broken in the first silicon because of a Verilog sign-extension misunderstanding. It's working now. It's useful for RF modulation, not just TV. I need to get a picture of it generating a modulated sine wave, so it will be more clear.
Very nice Chip. All we need now is HDMI generation to be proven and the P2 should then have the three most common video interfaces nailed, certainly at 480/576 line resolutions, and higher with analog outputs. Highly versatile. Love how little instruction code these video COGs need now with the P2 instruction set.
Here is the IQ modulator running. It keeps outputting a sine of some amplitude, phase, and frequency, until you change it. In the picture, it's alternating between 10MHz and 40MHz. The P2 is running at 320MHz. Note that the scope view spans only 0.5us.
Here's the code, kind of hacked from the NTSC example:
CON
s = 127 'scale DAC output (s = 0..128)
r = s * 1000 / 1646 'precompensate for modulator expansion of 1.646
mody = ((+000*s/128) & $FF) << 24 + ((+000*s/128) & $FF) << 16 + ((+000*s/128) & $FF) << 8 + 128
modi = ((+000*r/128) & $FF) << 24 + ((-000*r/128) & $FF) << 16 + ((-000*r/128) & $FF) << 8 + 128
modq = ((+120*r/128) & $FF) << 24 + ((-000*r/128) & $FF) << 16 + ((+000*r/128) & $FF) << 8 + 128
video_pin = 8
DAT org
'
'
' Setup
'
hubset clkinit1 'set clock to 320MHz
waitx clkwait
hubset clkinit2
setcfrq ##$20000000
setcy ##mody 'set colorspace converter coefficients
setci ##modi
setcq ##modq
setcmod #%11_1_0000 'set colorspace converter to YIQ mode (composite)
wrpin dacmode,#video_pin 'enable dac mode in pin
drvl #video_pin 'enable dac output
'
'
' Field loop
'
field
xcont m_cb1,c_cb1
setcfrq ##$20000000
xcont m_cb2,c_cb1
setcfrq ##$08000000
jmp #field
'
'
' Initialized data
'
clkinit1 long %1_000000_0000001111_1111_10_00 '20MHz / 1 * 16 * 1 = 320MHz
clkinit2 long %1_000000_0000001111_1111_10_11
clkwait long 20_000_000 / 200
dacmode long %0000_0000_000_1011100000000_01_00000_0
m_cb1 long $7F010000+100
m_cb2 long $7F010000+50
c_cb1 long $FF0000_01
Very nice Chip. All we need now is HDMI generation to be proven and the P2 should then have the three most common video interfaces nailed, certainly at 480/576 line resolutions, and higher with analog outputs. Highly versatile. Love how little instruction code these video COGs need now with the P2 instruction set.
Agreed Roger, with so little code it's easy to understand. The complexities are hidden by the hardware!
With Composite Video, VGA, and with fingers crossed HDMI, we have an extremely powerful little processor! The internal DACs round it off nicely.
If the PLLs are the bottleneck are you going to take another pass at them to up that speed even more? It's probably unnecessary, but a 400Mhz clock speed without cooling would certainly give the Prop2 one more cool thing to brag about
@threadz,
Don't expect another respin for P2 unless something very serious is found. Each respin is expensive, and another 6-9 month delay.
This is way more than was ever expected which was 160MHz although we were quietly hoping for 200MHz.
We are way above expectations!
Many of us would have been happy with the first "ES" iteration. I guess the only show-stopper problem was with the verilog handling of the -ve sign. This next silicon is just way beyond what we were even hoping for after the "ES" silicon.
Even if we get another P2 variant (less cogs/ram/pins), I doubt that I would take the risk to tweek anything else. The motto "don't fix what ain't broke" comes to mind here.
Oh... for some reason i was thinking silicon tweaks had a few weeks turnaround for small batches. Like PCBs i guess... idk what I was thinking of.
Regardless, doubling the expectation to 320Mhz is impressive and the silicon keeping up with 400Mhz+ with thermal management is even cooler (pun intended) so I'm far from disappointed.
@Rayman, In most places the 40m band is at least partially available to amateur broadcasters, largely due to commercial services in that range shutting down to due to lack of use. 7.0-7.1Mhz offers great range, sometimes 1500km+ and decent throughput with not that much atmospheric interference.
Plus, with the P2's smart pins, streamers, and many cogs, you could plausibly occupy the entire baud at once. Fun!
@threadz,
Don't expect another respin for P2 unless something very serious is found. Each respin is expensive, and another 6-9 month delay.
This is way more than was ever expected which was 160MHz although we were quietly hoping for 200MHz.
We are way above expectations!
Many of us would have been happy with the first "ES" iteration. I guess the only show-stopper problem was with the verilog handling of the -ve sign. This next silicon is just way beyond what we were even hoping for after the "ES" silicon.
Even if we get another P2 variant (less cogs/ram/pins), I doubt that I would take the risk to tweek anything else. The motto "don't fix what ain't broke" comes to mind here.
That is my opinion, too. The first iteration could already pass perfectly as a finished product, and was above expectations. But this last respin solves important bugs and opens new possibilities in terms of speed and current consumption. If all tests pass, then is ready for launch at this point, IMHO.
Glad to see IQ modulator working...
Now, I'm wondering what frequencies I can use around the house without getting in trouble...
I was thinking the old 49MHz cordless phone / walkie talkie band would work. Of course, it would be nice to receive signals as well. The ADC is limited to low MHz. Possibly P2 + SA602 would make a neat little SDR. The ADC has 40 dB of gain control!
I just did another experiment where I divided the 20MHz crystal by 64 and then multiplied it by 80 to get 25MHz. Still, no pixel shimmying. This is significant because at lower VCO frequencies, things are less stable. I can't see any instability, which is surprising to me.
So, the chip is running at 25MHz, outputting a VGA display with that same pixel rate, and drawing only 33mA at 1.8V.
Possibly, the clock gating has reduced the total ground/supply noise, on simple tests, which has further helped the VCO noise effects ?
More COGs running could impact this ?
Did you try one of the higher pixel rate VGA demo's ?
Sometimes the pixel jitter is more obvious at higher clock speeds.
Here is baseband NTSC being output over a single pin in DAC mode:
There should be quite wide security market applications for P2, where cameras need text inserted to label & timestamp, and some simple movement detection could decide on recording the cameras..
Comments
If so, could do SVGA at ~330 MHz...
The P2 can signal 1080p over 3 pins in analog. Pixel rate is 148.5MHz.
Good question, I've not seen confirmed word on if the bug-fixes, fixed... Given the nature of everything else, the inference is yes..
Since the new revision uses half the power and gets barely warm at 390MHz, I guess that it is possible to raise the nominal frequency from 180MHz to 240MHz, with margin for overclocking?
I mean, 240MHz would be an important milestone, and higher specs would mean higher sales, possibly. But I'm just speculating. I'm eager to see the new specs.
By the way, when will the new boards be available for sale?
Kind regards, Samuel Lourenço
Yes, we've got huge temperature margins in the design. We designed for -40C to 85C ambient temperature. For the hot end, we figured on a junction temperature of 150C, allowing for lots of self-heating. 150C is 65C over 85C. With this reduced power dissipation, we don't need 65C of margin, but since it's there, it means we could run way faster than 175MHz or boost the 85C figure up a ways. We will eventually work with ON Semi to determine a 2-D graph of ambient temperature vs. max frequency.
When the new boards will be available depends on when we get real packaged chips, not these glob-tops. That is looking like a few weeks, at least, maybe a month.
Imagine how expensive and delicate this probe card must be. Wouldn't want to damage this thing.
This gave an opportunity to push the PLL to extremes to see if it jitters badly.
I set the crystal divider to 64, so that 20MHz becomes 312.5KHz. Then, I multiply it in the VCO by 256 to get 80MHz. That VCO frequency is then used directly for the system clock... No pixel shimmying, at all. I tried a range of PLL configurations and I can't get any visible shimmying. So, the PLL seems to be in order now.
Here's the code:
'************************************* '* VGA 640 x 480 x 16bpp 5:6:5 RGB * '************************************* CON intensity = 80 '0..128 fclk = 80_000_000.0 fpix = 25_000_000.0 fset = (fpix / fclk * 2.0) * float($4000_0000) vsync = 4 'vsync pin (all FPGA boards now) DAT org ' ' ' Setup ' hubset clkinit1 'set clock to 80MHz waitx clkwait hubset clkinit2 rdfast ##640*350*2/64,##$1000 'set rdfast to wrap on bitmap setxfrq ##round(fset) 'set transfer frequency to 25MHz setcy ##intensity << 24 'r set colorspace for rgb setci ##intensity << 16 'g setcq ##intensity << 08 'b setcmod #%01_0_000_0 'enable colorspace conversion (may be commented out) wrpin dacmode_hsy,#0<<6 + 0 'enable dac mode in pin 0 for hsync wrpin dacmode_rgb,#2<<6 + 1 'enable dac modes in pins 1..3 for rgb drvl #3<<6 + 0 'enable dac outputs ' ' ' Field loop ' field mov x,#90 'top blanks call #blank mov x,#350 'set visible lines line call #hsync 'do horizontal sync xcont m_rf,#1 'visible line djnz x,#line 'another line? mov x,#83 'bottom blanks call #blank drvnot #vsync 'sync on mov x,#2 'sync blanks call #blank drvnot #vsync 'sync off jmp #field 'loop ' ' ' Subroutines ' blank call #hsync 'blank lines xcont m_vi,#0 _ret_ djnz x,#blank hsync xcont m_bs,#0 'horizontal sync xzero m_sn,#1 _ret_ xcont m_bv,#0 ' ' ' Initialized data ' clkinit1 long %1_111111_0011111111_1111_10_00 '20MHz / 1 * 4 * 1 = 80MHz clkinit2 long %1_111111_0011111111_1111_10_11 clkwait long 20_000_000 / 200 dacmode_hsy long %0000_0000_000_1011000000000_01_00000_0 '123-ohm 3.3V dacmode_rgb long %0000_0000_000_1011100000000_01_00000_0 '75-ohm 2.0V m_bs long $7F010000+16 'before sync m_sn long $7F010000+96 'sync m_bv long $7F010000+48 'before visible m_vi long $7F010000+640 'visible m_rf long $BF050000+640 'visible rfword rgb16 (5:6:5) x res 1 y res 1 ' ' ' Bitmap ' orgh $1000 - 70 'justify pixels at $1000 file "birds_16bpp.bmp" 'rayman's picture (640 x 350)And here's the output:
So, the chip is running at 25MHz, outputting a VGA display with that same pixel rate, and drawing only 33mA at 1.8V.
Here's the code:
'******************************* '* NTSC 256 x 192 x 8bpp-lut * '******************************* CON f_color = 3_579_545.0 'colorburst frequency f_scanline = f_color / 227.5 'scanline frequency f_pixel = f_scanline * 400.0 'pixel frequency for 400 pixels per scanline f_clock = 80_000_000.0 'clock frequency f_xfr = f_pixel / f_clock * float($7FFF_FFFF) f_csc = f_color / f_clock * float($7FFF_FFFF) * 2.0 s = 90 'scale DAC output (s = 0..128) r = s * 1000 / 1646 'precompensate for modulator expansion of 1.646 mody = ((+38*s/128) & $FF) << 24 + ((+75*s/128) & $FF) << 16 + ((+15*s/128) & $FF) << 8 + (110*s/128 & $FF) modi = ((+76*r/128) & $FF) << 24 + ((-35*r/128) & $FF) << 16 + ((-41*r/128) & $FF) << 8 + (100*s/128 & $FF) modq = ((+27*r/128) & $FF) << 24 + ((-67*r/128) & $FF) << 16 + ((+40*r/128) & $FF) << 8 + 128 video_pin = 0 DAT org ' ' ' Setup ' hubset clkinit1 'set clock to 80MHz waitx clkwait hubset clkinit2 rdfast #0,##$1000-$400 'load .bmp palette into lut mov x,#0 rep @.end,#$100 rflong y shl y,#8 wrlut y,x add x,#1 .end rdfast ##256*192/64,##$1000 'set rdfast to wrap on bitmap setxfrq ##round(f_xfr) 'set transfer frequency setcfrq ##round(f_csc) 'set colorspace converter frequency setcy ##mody 'set colorspace converter coefficients setci ##modi setcq ##modq setcmod #%11_1_0000 'set colorspace converter to YIQ mode (composite) wrpin dacmode,#video_pin 'enable dac mode in pin drvl #video_pin 'enable dac output ' ' ' Field loop ' field mov x,#35 'top blanks call #blank mov x,#192 'set visible lines line call #hsync 'do horizontal sync xcont m_rf,#0 'visible line xcont m_av,#1 'after visible spacer djnz x,#line 'another line? mov x,#27 'bottom blanks call #blank mov x,#6 'high vertical syncs .vlow xcont m_hl,#2 xcont m_hh,#1 djnz x,#.vlow mov x,#6 'low vertical syncs .vhigh xcont m_ll,#2 xcont m_lh,#1 djnz x,#.vhigh mov x,#6 'high vertical syncs .vlow2 xcont m_hl,#2 xcont m_hh,#1 djnz x,#.vlow2 jmp #field 'loop ' ' ' Subroutines ' blank call #hsync 'blank lines xcont m_vi,#0 xcont m_av,#1 _ret_ djnz x,#blank hsync xcont m_sn,#2 'horizontal sync xcont m_bc,#1 xcont m_cb,c_cb _ret_ xcont m_ac,#1 ' ' ' Initialized data ' clkinit1 long %1_000000_0000000011_1111_10_00 '20MHz / 1 * 4 * 1 = 80MHz clkinit2 long %1_000000_0000000011_1111_10_11 clkwait long 20_000_000 / 200 dacmode long %0000_0000_000_1011100000000_01_00000_0 m_sn long $7F010000+29 'sync m_bc long $7F010000+7 'before colorburst m_cb long $7F010000+18 'colorburst m_ac long $7F010000+40 'after colorburst m_vi long $7F010000+256 'visible m_av long $7F010000+50 'after visible (400 total) m_rf long $7F080000+256 'visible rflong 8bpp lut m_hl long $7F010000+15 'vertical sync high low m_hh long $7F010000+185 'vertical sync high high (200 total) m_ll long $7F010000+171 'vertical sync low low m_lh long $7F010000+29 'vertical sync low high (200 total) c_cb long $507000_01 'colorburst reference color x res 1 y res 1 ' ' ' Bitmap ' orgh $1000 - $436 'justify pixels at $1000, pallete at $1000-$400 file "bitmap.bmp"This IQ modulator was broken in the first silicon because of a Verilog sign-extension misunderstanding. It's working now. It's useful for RF modulation, not just TV. I need to get a picture of it generating a modulated sine wave, so it will be more clear.
Here's the code, kind of hacked from the NTSC example:
Yes, I'll get to the HDMI tomorrow.
Agreed Roger, with so little code it's easy to understand. The complexities are hidden by the hardware!
With Composite Video, VGA, and with fingers crossed HDMI, we have an extremely powerful little processor! The internal DACs round it off nicely.
Don't expect another respin for P2 unless something very serious is found. Each respin is expensive, and another 6-9 month delay.
This is way more than was ever expected which was 160MHz although we were quietly hoping for 200MHz.
We are way above expectations!
Many of us would have been happy with the first "ES" iteration. I guess the only show-stopper problem was with the verilog handling of the -ve sign. This next silicon is just way beyond what we were even hoping for after the "ES" silicon.
Even if we get another P2 variant (less cogs/ram/pins), I doubt that I would take the risk to tweek anything else. The motto "don't fix what ain't broke" comes to mind here.
Now, I'm wondering what frequencies I can use around the house without getting in trouble...
Regardless, doubling the expectation to 320Mhz is impressive and the silicon keeping up with 400Mhz+ with thermal management is even cooler (pun intended) so I'm far from disappointed.
Plus, with the P2's smart pins, streamers, and many cogs, you could plausibly occupy the entire baud at once. Fun!
That is quite impressive!
That is my opinion, too. The first iteration could already pass perfectly as a finished product, and was above expectations. But this last respin solves important bugs and opens new possibilities in terms of speed and current consumption. If all tests pass, then is ready for launch at this point, IMHO.
Kind regards, Samuel Lourenço
Better than expected, always a good place to be!
I was thinking the old 49MHz cordless phone / walkie talkie band would work. Of course, it would be nice to receive signals as well. The ADC is limited to low MHz. Possibly P2 + SA602 would make a neat little SDR. The ADC has 40 dB of gain control!
Possibly, the clock gating has reduced the total ground/supply noise, on simple tests, which has further helped the VCO noise effects ?
More COGs running could impact this ?
Did you try one of the higher pixel rate VGA demo's ?
Sometimes the pixel jitter is more obvious at higher clock speeds.
There should be quite wide security market applications for P2, where cameras need text inserted to label & timestamp, and some simple movement detection could decide on recording the cameras..