BTW I am fairly sure I posted the correct code. Did you check the CON section and not comments? Sorry cannot check on my phone.
it has
CON
_XTALFREQ = 12_000_000 ' crystal frequency
_XDIV = 12 ' crystal divider to give 1MHz
_XMUL = 180 ' crystal / div * mul
_XDIVP = 1 ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
That says
CON
_XTALFREQ = 12_000_000 ' crystal frequency
_XDIV = 4 ''''12 * 2 ' crystal divider to give 0.5MHz
_XMUL = 99 ''''297 '148.5MHz '168 * 2 ' crystal / div * mul
_XDIVP = 2 ''''1 ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
which has 3MHz PFD and 297MHz VCO
Another reference point, is XDIV 8, XMUL 99 and XDIVP of 1 for PFD of 1.5MHz and VCO of 148.5MHz
When the chip got too hot the pic started to break up..
Hmm... That must be a lot of jitter to do that. I wonder how much shift is actually needed on those 1080P monitors ? A scope is needed....
Does not really sound like PFD gain alone could do that, but it is sounding like a PLL issue.
There is another PLL flaw mechanism, which is deadband in the phase detector - detectors that seek to zero, on floating balance can end up with a flat spot/deadband, where small changes in phase give neither + or - pulses.
Because that is a timing difference, and around a null, it could be quite temperature dependent.
- but to be bad enough to lose sync, I don't know.... ?
Here is sample code that draws concentric single pixel rectangles on the screen at 1920x1080 @ 4bpp 148MHz.
I have adjusted the monitors x & y position to display all pixels.
The buffer is 506.25KB and is 1920x540 and is repeated on the display twice for a full screen.
This runs with a 12MHz ocsillator with /4, *99, /2 as suggested by Chip.
Very stable with little shimmering that I believe is the monitor display. The pixels are rock-steady. The board/chip does run quite hot, but runs fine without cooling. Ambient here is ~22C currently.
This runs with a 12MHz ocsillator with /4, *99, /2 as suggested by Chip.
Very stable with little shimmering that I believe is the monitor display. The pixels are rock-steady. The board/chip does run quite hot, but runs fine without cooling. Ambient here is ~22C currently.
Now it is looking more stable, can you try the other solution of /8 , *99, /1 ?
Curious how much PFD frequency change affects this.
Been too busy drawing clock lines on the display. 8 4 pixels per complete clock cycle display. 480 clocks per line
Rock steady. Quite tiny on my 23" display but I can read it. Put markers every 10 clocks with additional every 50.
I am using 2bpp with 4 colours white, blue, green, red. Currently using white on red background.
No worries. I thought you might have that board too.
Yes, there is six video rated DACs on the P123 board next to the FPGA. Chip has them configured to work with streamers/SETDACS somehow, but it's not documented in the main doc.
It samples P0-7 with the streamer, converts to digital waveforms (bug in P0 samples), then displays as VGA 1920x1080x1bpp @ 148.5MHz using the streamer, all in one cog. I have a builtin character font. Also, I change the foreground & background colors on the fly too.
It's not a complete debugger yet, but thought you may like to check out the code anyway.
I am using the P2D2
P0=HS
P1=B
P2=G
P3=R
P4=VS
This is the setup for 148.5MHz VGA 1920x1080 1bpp
Now the P2-Eval board is in the wild, is there a version for that PCB ?
It could be interesting to check the PLL jitter issues seen on P2D2 PCB, on the P2-Eval design, to see if the same problems are seen ?
The Xtal choice on the P2-Eval does not 'line up' too well with a high PFD and 148.5MHz ?
Perhaps 20M/7 is close enough, with a 480ppm error ? (one part in 2080)
With lower PFD, there are
20M/26 is 259ppm error
20M/33 is 102ppm error
20M/40 is exact, but now PFD is down to 0.5MHz
52/7 gives me 49 Hz.
This monitor (Samsung S24W450) seems to work with anything... Sync from 49 to 72 Hz. There is some shimmer though, best to focus on that...
Strange it should jump to 49Hz from 60, especially given that is slightly high at 148.5714 ?
There is also an opposite sign error of -532ppm
VCO = 141*(20/19) = 148.4210
PFD = (20/19) = 1.0526
And now, the monitor says 60 Hz with XDIV=40 and XMUL=297, like it should.
Also, looks like the active area is where it should be.
But, there's a lot of flicker...
And now, the monitor says 60 Hz with XDIV=40 and XMUL=297, like it should.
Also, looks like the active area is where it should be.
But, there's a lot of flicker...
Good to have an active area, do any of the higher PFD with 'some ppm' errors, work ? Trying to get a handle on what ppm deviations 148.5 can tolerate
In order of increasing ppm but also higher PFD, there are :
And now, the monitor says 60 Hz with XDIV=40 and XMUL=297, like it should.
Also, looks like the active area is where it should be.
But, there's a lot of flicker...
Before the respin, we need to address this PLL issue. It seems that maybe the feedback is too strong or too weak. Need to figure out which.
I think I know what the problem is. There is a second order RC filter on the charge pump for the VCO. The first R is proportional to the divisor. The second R is fixed. It needs to be proportional, too, in order to avoid ringing. That flicker is the VCO wandering above and below the reference frequency because the second R is not dampening enough.
XDIV=10 and XMUL=74 is slightly better as the monitor reports 1080p 60 Hz.
I only see the flicker on the screen that looks like a pie with a slice missing. Not completely sure why I see it only there... Might be optical illusion?
And now, the monitor says 60 Hz with XDIV=40 and XMUL=297, like it should.
Also, looks like the active area is where it should be.
But, there's a lot of flicker...
Before the respin, we need to address this flicker issue. It seems that maybe the feedback is too strong or to weak. Need to figure out which.
I have seen PLL's that deliberately avoid a perfect-balance situation.
The ones that have correction pulses vanish to zero, can have dead-bands in the transfer, which can give high jitter.
Avoiding perfect balance means the correction pulses never go right to zero, so has a small cost of some correction signal on the VCO control, but at the PFD rate.
Another test point would be to push up PFD to highest-available-xtal points, to confirm what PFD changes do.
Best I can find so far for that, is 13.5MHz (Higher values are less common)
Addit: Oscillators come in 37.125MHz and 49.5MHz and 74.25MHz for higher still PFDs ( and 148.5M for no divider needed)
- so it's a pity the P2-Eval board failed to get the suggested Oscillator footprint.
Besides that, there is Si5351A clock synthesiser, which I think there are P1 drivers for, that could allow any MHz, right up to 148.5 directly.
Comments
it has
CON
_XTALFREQ = 12_000_000 ' crystal frequency
_XDIV = 12 ' crystal divider to give 1MHz
_XMUL = 180 ' crystal / div * mul
_XDIVP = 1 ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
ahh... too many copies here...
That says
CON
_XTALFREQ = 12_000_000 ' crystal frequency
_XDIV = 4 ''''12 * 2 ' crystal divider to give 0.5MHz
_XMUL = 99 ''''297 '148.5MHz '168 * 2 ' crystal / div * mul
_XDIVP = 2 ''''1 ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
which has 3MHz PFD and 297MHz VCO
Another reference point, is XDIV 8, XMUL 99 and XDIVP of 1 for PFD of 1.5MHz and VCO of 148.5MHz
Hmm... That must be a lot of jitter to do that. I wonder how much shift is actually needed on those 1080P monitors ? A scope is needed....
Does not really sound like PFD gain alone could do that, but it is sounding like a PLL issue.
There is another PLL flaw mechanism, which is deadband in the phase detector - detectors that seek to zero, on floating balance can end up with a flat spot/deadband, where small changes in phase give neither + or - pulses.
Because that is a timing difference, and around a null, it could be quite temperature dependent.
- but to be bad enough to lose sync, I don't know.... ?
I have adjusted the monitors x & y position to display all pixels.
The buffer is 506.25KB and is 1920x540 and is repeated on the display twice for a full screen.
This runs with a 12MHz ocsillator with /4, *99, /2 as suggested by Chip.
Very stable with little shimmering that I believe is the monitor display. The pixels are rock-steady. The board/chip does run quite hot, but runs fine without cooling. Ambient here is ~22C currently.
Now it is looking more stable, can you try the other solution of /8 , *99, /1 ?
Curious how much PFD frequency change affects this.
Rock steady. Quite tiny on my 23" display but I can read it. Put markers every 10 clocks with additional every 50.
I am using 2bpp with 4 colours white, blue, green, red. Currently using white on red background.
The clocks use 2 pixels per sample. The traces are ports P0-7 and the streamer is sampling this
rep @.rep,#sample_length/2 add outa,#1 .repIf you look closely, the P0 sample is not 50/50 probably due to some internal P2 timing differences on when it samples the pin. ie +/-a bit.
The characters displayed are an 8x8 font with 240 characters/line and 135 lines on the 1920x1080 24" Acer monitor.
I have the foreground & background color pairs changing every 135 lines (8*135=1080) with proper sync
''+============================================================================+ ''+ DAC Streamer: VGA out with streamer (from hub on every clock cycle...) + ''+============================================================================+ '' setxfrq ##$8000_0000 ' sysclk sample rate '' rdfast ##long_length/16,##@buffer ' rdfast to wrap on xxKB bitmap (longs/16) '+-------[ Setup Streamer ]----------------------------------------------------+ vid loc ptra,#\@palette_pairs ' set 1st color palette setq2 #2-1 ' (only need 2) rdlong lut_start,ptra ' set next palette color mov ctr1,#135 ' & set row ctr setxfrq ##fset 'set transfer frequency to xxxMHz dirh #vsync 'make vsync pin output 'the next 4 lines may be commented out to bypass level scaling setcy ##intensity << 24 '\ r set colorspace for rgb setci ##intensity << 16 '| g setcq ##intensity << 08 '| b setcmod #%01_0_000_0 '/ enable colorspace conversion wrpin dacmode_s,#0 '\ enable dac modes in pins 0..3 wrpin dacmode_c,#1 '| wrpin dacmode_c,#2 '| wrpin dacmode_c,#3 '| setnib dira,#$f,#0 '/ & enable output rdfast ##w*h*bpp/32/16,##@video_buffer ' wraps ~253KB bitmap (longs/16) '+-------[ Display Screen ]----------------------------------------------------+ ' Field loop field outnot #vsync '\ vsync on mov x,#sync_blanks '| call #blank '| outnot #vsync '/ vsync off '----------------------------------------------- mov x,#top_blanks call #blank '----------------------------------------------- ' display visible screen 1bpp mov x,##h 'set visible lines loc ptra,#\@palette_pairs ' set 1st color palette mov ctr1,#1 ' & force new load below .visible xcont m_bs,#0 'horizontal sync (before sync) xcont m_sn,#1 'horizontal sync (sync) djnz ctr1,#.skip ' set new palette? setq2 #2-1 ' (only need 2) rdlong lut_start,ptra ' set next palette color add ptra,#2*4 ' next color pair mov ctr1,#135 ' & set row ctr .skip xcont m_bv,#0 'horizontal sync (before visible) xcont m_rf,#0 'visible line djnz x,#.visible 'another line? '----------------------------------------------- mov x,##bottom_blanks call #blank '----------------------------------------------- jmp #field 'loop '----------------------------------------------- ' display blank lines blank xcont m_bs,#0 'horizontal sync (before sync) xcont m_sn,#1 'horizontal sync (sync) xcont m_bv,#0 'horizontal sync (before visible) xcont m_vi,#0 'blank visible _RET_ djnz x,#blank '+-----------------------------------------------------------------------------+ ' Initialized data dacmode_s long %0000_0000_000_1011000000000_01_00000_0 'hsync is 123-ohm, 3.3V dacmode_c long %0000_0000_000_1011100000000_01_00000_0 'R/G/B are 75-ohm, 2.0V m_bs long $CF000000+before_sync m_sn long $CF000000+sync m_bv long $CF000000+before_visible m_vi long $CF000000+w 'visible 'm_rf long $6F000000+w '4bit RFLONG LUT 'm_rf long $5F000000+w '2bit RFLONG LUT m_rf long $4F000000+w '1bit RFLONG LUTI'm trying to output copied ADC readings onto DAC0 RCA socket to watch on my oscilloscope. It's electrically the same signal as VGA0 Blue pin.
PS: I've tried using that I've seen done in other code, but that messed with Prop Pin0 digital input that I am using. And it didn't give me any DAC signal anyway.
I don't have a P123 FPGA board but I seem to recall you need an external circuit to convert.
I am using the P2D2
P0=HS
P1=B
P2=G
P3=R
P4=VS
This is the setup for 148.5MHz VGA 1920x1080 1bpp
Yes, there is six video rated DACs on the P123 board next to the FPGA. Chip has them configured to work with streamers/SETDACS somehow, but it's not documented in the main doc.
It samples P0-7 with the streamer, converts to digital waveforms (bug in P0 samples), then displays as VGA 1920x1080x1bpp @ 148.5MHz using the streamer, all in one cog. I have a builtin character font. Also, I change the foreground & background colors on the fly too.
It's not a complete debugger yet, but thought you may like to check out the code anyway.
in the hsync routine. Looks like this is 32-bit immediate mode.
Doesn't this make a tiny signal?
Shouldn't #1 be #$FF ?
Now the P2-Eval board is in the wild, is there a version for that PCB ?
It could be interesting to check the PLL jitter issues seen on P2D2 PCB, on the P2-Eval design, to see if the same problems are seen ?
The Xtal choice on the P2-Eval does not 'line up' too well with a high PFD and 148.5MHz ?
Perhaps 20M/7 is close enough, with a 480ppm error ? (one part in 2080)
With lower PFD, there are
20M/26 is 259ppm error
20M/33 is 102ppm error
20M/40 is exact, but now PFD is down to 0.5MHz
_XTALFREQ to 20_000_000
_XDIV to 40
_XMUL to 297
_XOSC to $10
to work with P2 eval board (values conveniently listed in docs)
You have this working with PFD=0.5MHz ? How does that look for jitter effects ?
What about settings of
_XDIV to 7
_XMUL to 52
for PFD = 2.857MHz
PLL = 148.5714MHz
Is that 480 ppm error tolerated by VGA monitors ?
By "work", I mean monitor reports 1080p with 60 Hz refresh.
52/7 gives me 49 Hz.
This monitor (Samsung S24W450) seems to work with anything... Sync from 49 to 72 Hz. There is some shimmer though, best to focus on that...
There is also an opposite sign error of -532ppm
VCO = 141*(20/19) = 148.4210
PFD = (20/19) = 1.0526
Changed them to what's on this page:
https://timetoexplore.net/blog/video-timings-vga-720p-1080p
And now, the monitor says 60 Hz with XDIV=40 and XMUL=297, like it should.
Also, looks like the active area is where it should be.
But, there's a lot of flicker...
Good to have an active area, do any of the higher PFD with 'some ppm' errors, work ? Trying to get a handle on what ppm deviations 148.5 can tolerate
In order of increasing ppm but also higher PFD, there are :
Before the respin, we need to address this PLL issue. It seems that maybe the feedback is too strong or too weak. Need to figure out which.
(with porch settings changed as described earlier)
I only see the flicker on the screen that looks like a pie with a slice missing. Not completely sure why I see it only there... Might be optical illusion?
I have seen PLL's that deliberately avoid a perfect-balance situation.
The ones that have correction pulses vanish to zero, can have dead-bands in the transfer, which can give high jitter.
Avoiding perfect balance means the correction pulses never go right to zero, so has a small cost of some correction signal on the VCO control, but at the PFD rate.
Another test point would be to push up PFD to highest-available-xtal points, to confirm what PFD changes do.
Best I can find so far for that, is 13.5MHz (Higher values are less common)
XTAL - FL1350008CT-ND Diodes Inc 13.5MHZ 16PF SMD 2,961 stk ±20ppm ±20ppm 16pF 100 Ohms Fundamental -20°C ~ 70°C (3.20mm x 2.50mm)
Addit: Oscillators come in 37.125MHz and 49.5MHz and 74.25MHz for higher still PFDs ( and 148.5M for no divider needed)
- so it's a pity the P2-Eval board failed to get the suggested Oscillator footprint.
Besides that, there is Si5351A clock synthesiser, which I think there are P1 drivers for, that could allow any MHz, right up to 148.5 directly.
Can you connect one of these to XI?