I noted there is some slight jitter in the pics although I didn't notice on the monitor. The first row of samples are all 2 pixels wide high and 2 pixels wide low but I noticed the pic has some with 3 pixels high. The pic is from the P2-ES board IIRC. I believe this is to do with the pins changing state as they are being sampled - some pins seem to be more pronounced which is to be expected.
Oh, and I checked... It uses just over a 1KB, but this could be shrunk to maybe 800B as it's not really optimised properly.
'P2-EVAL
_XTALFREQ = 20_000_000 ' crystal frequency
_XDIV = 4 '\ '\ crystal divider to give 5.0MHz
_XMUL = 29 '| 145 MHz '| crystal / div * mul to give 145MHz
_XDIVP = 1 '/ '/ crystal / div * mul /divp to give 145MHz
_XOSC = %10 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
{{'P2D2
_XTALFREQ = 12_000_000 ' crystal frequency
''_XDIV = 12 * 2 '\ ' crystal divider to give 0.5MHz
''_XMUL = 297 '| 148.5MHz ' crystal / div * mul
''_XDIVP = 1 '/ ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
_XDIV = 4 '\ '\ crystal divider to give 3.0MHz
_XMUL = 99 '| 148.5MHz '| crystal / div * mul to give 297MHz
_XDIVP = 2 '/ '/ crystal / div * mul /divp to give 148.5MHz
_XOSC = %01 'OSC ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
}}
_XSEL = %11 'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
_XPPPP = ((_XDIVP>>1) + 15) & $F ' 1->15, 2->0, 4->1, 6->2...30->14
_CLOCKFREQ = _XTALFREQ / _XDIV * _XMUL / _XDIVP ' internal clock frequency
_SETFREQ = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2 ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00 ' setup oscillator
_ENAFREQ = _SETFREQ + _XSEL ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss ' enable oscillator
'' 1920x1080 60Hz mode @ 148.5MHz from https://timetoexplore.net/blog/video-timings-vga-720p-1080p
'' ----------------------------------------------------------------------------------
PIXEL_CLK = _CLOCKFREQ '
H_DISP = 1920
H_FPORCH = 88
H_SYNC = 44
H_BPORCH = 148
V_DISP = 1080
V_FPORCH = 4 +32 'tweek
V_SYNC = 5
V_BPORCH = 36 -32 'tweek
'' ----------------------------------------------------------------------------------
Would 150MHz work on the P2-EVAL? That's just a 1% error.
'P2-EVAL
_XTALFREQ = 20_000_000 ' crystal frequency
_XDIV = 2 '\ '\ crystal divider to give 10.0MHz
_XMUL = 15 '| 150 MHz '| crystal / div * mul to give 150MHz
_XDIVP = 1 '/ '/ crystal / div * mul /divp to give 150MHz
_XOSC = %10 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
Has anyone tried VGA on a COG other than COG #0? I can't seem to get it to work on my P2-ES board -- I can take the exact same code and with "coginit #0, #@entry" it works, but coginit #N, #@entry" does not if N <> 0.
If I recall correctly in the FPGA the DACs were only connected to COG #0. Did that restriction somehow carry over to the P2 eval silicon?
It says each cog has 4 DAC channels which are restricted to pins with the same two LSBs, so
DAC0 channel only drives pins %xxxx00, DAC only %xxxx01, etc. So any cog can drive any pin, but
when a cog wants to drive several pins it has to choose pins with distinct lower two bits.
Well that's my reading, and I'm not clear if this is restricted to streaming DAC modes or all...
So I finally came around to try this (from the first post) out on my SyncMaster F2380. After realising that the crystal setup was for the P2D2 and then making the changes for the eval board, the screen finally synced to the signal and displayed graphics.
After looking at the different "effects" for a while it started to shimmer (as you all have noticed), but the strange thing is that it breifly becomes rock stable whenever there is pixel manipulation taking place. Some effect transistions take longer time and that gives the time to notice it. Just an observation that may be giving some clues to the problem. Strange indeed!
So I finally came around to try this (from the first post) out on my SyncMaster F2380. After realising that the crystal setup was for the P2D2 and then making the changes for the eval board, the screen finally synced to the signal and displayed graphics.
After looking at the different "effects" for a while it started to shimmer (as you all have noticed), but the strange thing is that it breifly becomes rock stable whenever there is pixel manipulation taking place. Some effect transistions take longer time and that gives the time to notice it. Just an observation that may be giving some clues to the problem. Strange indeed!
I've made a few changes to the PLL loop filter which should improve its operation quite a bit. Next silicon will be better.
For those still trying to absorb pad-ring I/O pin config for driving the DAC from either SETDACS or the Streamers, the pin config needed is referred to as COG_DAC mode. Chip details it in the PAD I/O sheet and I've listed it in my write up - https://forums.parallax.com/discussion/comment/1452036/#Comment_1452036
Namely
for %TT = %01 and %MMMMM = %00000, %101_VV_xxxxSSSS = COG_DAC mode
%SSSS = Cog/streamer select: sets DAC level (registered?)
Place the desired cog number in %SSSS of each pin config that will have its DAC operated by that cog.
EDIT: That is the %P...P and %TT bits shown there only. The rest of the WRPIN config bits will likely be all zero. %MMMMM has to be zero.
So I finally came around to try this (from the first post) out on my SyncMaster F2380. After realising that the crystal setup was for the P2D2 and then making the changes for the eval board, the screen finally synced to the signal and displayed graphics.
After looking at the different "effects" for a while it started to shimmer (as you all have noticed), but the strange thing is that it breifly becomes rock stable whenever there is pixel manipulation taking place. Some effect transistions take longer time and that gives the time to notice it. Just an observation that may be giving some clues to the problem. Strange indeed!
What time frames are you talking here, for 'good' vs 'bad' ?
Can you run the pixel manipulation so it always runs, but does not change the display, to see if it is processor activity that is driving the improvement ?
COG activity does affect power, in current P2, but not by a great deal.
Comments
I noted there is some slight jitter in the pics although I didn't notice on the monitor. The first row of samples are all 2 pixels wide high and 2 pixels wide low but I noticed the pic has some with 3 pixels high. The pic is from the P2-ES board IIRC. I believe this is to do with the pins changing state as they are being sampled - some pins seem to be more pronounced which is to be expected.
Oh, and I checked... It uses just over a 1KB, but this could be shrunk to maybe 800B as it's not really optimised properly.
'P2-EVAL _XTALFREQ = 20_000_000 ' crystal frequency _XDIV = 4 '\ '\ crystal divider to give 5.0MHz _XMUL = 29 '| 145 MHz '| crystal / div * mul to give 145MHz _XDIVP = 1 '/ '/ crystal / div * mul /divp to give 145MHz _XOSC = %10 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF {{'P2D2 _XTALFREQ = 12_000_000 ' crystal frequency ''_XDIV = 12 * 2 '\ ' crystal divider to give 0.5MHz ''_XMUL = 297 '| 148.5MHz ' crystal / div * mul ''_XDIVP = 1 '/ ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30) _XDIV = 4 '\ '\ crystal divider to give 3.0MHz _XMUL = 99 '| 148.5MHz '| crystal / div * mul to give 297MHz _XDIVP = 2 '/ '/ crystal / div * mul /divp to give 148.5MHz _XOSC = %01 'OSC ' %00=OFF, %01=OSC, %10=15pF, %11=30pF }} _XSEL = %11 'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms) _XPPPP = ((_XDIVP>>1) + 15) & $F ' 1->15, 2->0, 4->1, 6->2...30->14 _CLOCKFREQ = _XTALFREQ / _XDIV * _XMUL / _XDIVP ' internal clock frequency _SETFREQ = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2 ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00 ' setup oscillator _ENAFREQ = _SETFREQ + _XSEL ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss ' enable oscillator '' 1920x1080 60Hz mode @ 148.5MHz from https://timetoexplore.net/blog/video-timings-vga-720p-1080p '' ---------------------------------------------------------------------------------- PIXEL_CLK = _CLOCKFREQ ' H_DISP = 1920 H_FPORCH = 88 H_SYNC = 44 H_BPORCH = 148 V_DISP = 1080 V_FPORCH = 4 +32 'tweek V_SYNC = 5 V_BPORCH = 36 -32 'tweek '' ----------------------------------------------------------------------------------150MHz (/2*15/1) is more stable.
145MHz (/4*29/1) is more stable.
BTW the P2-ES chip doesn't get as hot as the original P2 epoxy chip from OnSemi.
If I recall correctly in the FPGA the DACs were only connected to COG #0. Did that restriction somehow carry over to the P2 eval silicon?
Way I remember it, each cog is hardwired to one set of 4 pins.
Why do you need to tell it what cog it is?
Thanks Chip! That did the trick.
DAC0 channel only drives pins %xxxx00, DAC only %xxxx01, etc. So any cog can drive any pin, but
when a cog wants to drive several pins it has to choose pins with distinct lower two bits.
Well that's my reading, and I'm not clear if this is restricted to streaming DAC modes or all...
That's good. Much better this way...
And it did not work out, they are still changing …
Enjoy!
Mike
After looking at the different "effects" for a while it started to shimmer (as you all have noticed), but the strange thing is that it breifly becomes rock stable whenever there is pixel manipulation taking place. Some effect transistions take longer time and that gives the time to notice it. Just an observation that may be giving some clues to the problem. Strange indeed!
I've made a few changes to the PLL loop filter which should improve its operation quite a bit. Next silicon will be better.
Namely
Place the desired cog number in %SSSS of each pin config that will have its DAC operated by that cog.
EDIT: That is the %P...P and %TT bits shown there only. The rest of the WRPIN config bits will likely be all zero. %MMMMM has to be zero.
Do you have the 'before' and 'after' simulation run plots for that change ?
What time frames are you talking here, for 'good' vs 'bad' ?
Can you run the pixel manipulation so it always runs, but does not change the display, to see if it is processor activity that is driving the improvement ?
COG activity does affect power, in current P2, but not by a great deal.
I will make some plots as soon as I can.
Straightening up the loop filter cleaned up a lot of bad behavior.