1 (edited by WoS 2013-10-16 15:50:11)

Topic: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

For using the video converter block, an exact ratio between SYSCLK and VIDCLK is needed to sync on the very same video frame rate. For this purpose I set up a small program. The base search algorithm (C++) comes from Mike, I ported it to JAVA (including some further range checking/limitations for the allowed PLL output frequencies and incorporating the clock divider of the clock module of the Replay framework) and set up a simple GUI.

Basically it is required to set the desired video output (currently only one is supported) and the system clock and native video size (in H-pixels and V-lines) from the core. It then calculates several possible settings for M,N,P for the PLL on the Replay board. One can then select a line out of the list which fits best - usually nearest to the ideal clock the core should run for best (gaming) experience. It did not do any extra work like sorting the results and removing double entries, I expect this can be much easier done by the user by just looking at it instead of blowing up the application code for such stuff...

It is developed using the latest ADT environment, works on Android (>=2.3.3) or should work on any free/commercial emulator on Win, Mac, Linux (just search the web, there are several ones). I tested it on a "real" Nexus 7 II, a "real" POV Mobii 10.1 with custom ROM (VegaComb) and on the BlueStacks emulator on Win 7. This should allow to use it on most OS w/o significant increase of my development efforts. And I have to say it was surprisingly easy for me to set it up...

Sources and pre-compiled APK file is on SVN under /src/sw/tools/ReplayPllCalc. The application looks like this:
http://www.pin4.at/tmp/ReplayPllCalc_small.png

The Mvid/Nvid/Pvid parameters are used for the PLL/clock output on y4 (setting VIDCLK), the Msys/Nsys/Psys parameters correspond to y0 (setting SYSCLK). Maybe I'll do some more update on this, because SYSCLK can be somewhat misleading. For now I ment the "effective" system clock the target core needs (to generate its video signal, to be precise), practically the SYSCLK is just CLK_A (or y0 at the PLL output) divided by 4 (by a DCM in the clock generator/distribution unit of the Replay framework), which needs to be gated using an additionally generated clock enable signal (for now it can be set to :3 or :4 in my tool).

This is needed as the SYSCLK needs to be faster/as fast as the max. possible SPI clock from the ARM processor to handle this interface. In a future release I may also check that this is fulfilled and having a proposed clock gating ratio as output instead of an user input here...

/WoS

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

How to setup PLLs for ZX-Spectrum with PAL color subcarrier and 14MHz ULA clock?

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

For the Horizontal and Veritcal pixel count... is it just the visible pixels or does it include the blank?  I only ask because I'm looking at your Galaga code right now and it looks like you used the PLL config calues in the snapshot below but the pixel values don't look right.  I figure I must be missing something...
wink

-Adam
==============
www.onecircuit.com
==============

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

Its the count of pixel per line between two H-sync (including "not existent" pixels) and count of lines for the whole frame (including "not existent" lines, so to say).

Basically the pixel clock [Hz] divided by this pixel per line divided by this count of lines per frame gives the frame rate [Hz].

Or the other way around: you can measure the time between two H-sync and divide by the pixel clock to get the pixel/line and you can measure the time between two V-sync and divide by the time of two H-sync and you get the line/frame.

Ok, usually measurement is not needed, as they are typically derived from some deterministic, digital  H- and V- counters generating the video timing, so you just need to check the reload valued of them. But measurement can be used as verification method...

/WoS

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

So for Galaga as an example.. if I look at the design, hsync drops right after hcount is 0x12F and rises right after hcount = 0x14F.  hcount's range is from 0x000 to 0x17F.  So that means hsync is high for 0x15F (351) cycles. 
Since the clock that drives hcount is the same as the pixel clock.. wouldn't the # of pix per line be 351?
(In the picture above it's 384)

-Adam
==============
www.onecircuit.com
==============

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

Ah, now I see what you mean. We aim for matching the frame rate of the embedded core and the Replay video generator.

The frame rate is given by the PERIOD of the h/v syncs. The period is given from one rising edge to the next rising edge (or from falling to falling) - and NOT some "active time" from the rising to the falling edge (or falling to rising).

ajcrm125 wrote:

hcount's range is from 0x000 to 0x17F

... this has exactly a length/count of 384 clocks

And that's what is required to calculate the dividers to match the frame rate. Similar for V sync, just check the line counter range...

/WoS

7 (edited by Macro 2014-09-15 13:23:55)

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

I've been trying to work out this clock lark, and *think* I have it sussed but would like someone to confirm or correct my understanding if possible.

now I am looking at Galaxian, which has an 18.432Mhz crystal, 6.144Mhz dot clock and 384 x 264 resolution (including blanking etc.) - which conveniently is the same as Galaga

so from the galaga ini file

# y0 - FPGA DRAM/sys clk
# y1 - Coder
# y2 - FPGA aux/audio clk
# y3 - Expansion Main
# y4 - FPGA video
# y5 - Expansion Small
# OUTPUT_y = (27 * Nx / Mx) / PDy     (if YSy=1, PSy selects PLL "x")
#

#         PLL1      PLL2      PLL3      1/2/4..PLL1/2/4 0..byp.    outp. divider          outp.enable
#         M1   N1   M2   N2   M3   N3   ps0 ps1 ps2 ps3 ps4 ps5 pd0 pd1 pd2 pd3 pd4 pd5 ys0 ys1 ys2 ys3 ys4 ys5
CLOCK =    30,  91, 125,1024,  33, 280,  2,  4,  4,  0,  1,  0,  3, 16,  5,  1,  3,  1,  1,  1,  1,  0,  1,  0

now I recognise some of these figures from the PLL program, which helps a bit, so working out gives me

PLL1 = (27 * 91 / 30) = 81.9
PLL2 = (27 * 1024 / 125) = 221.184 Mhz
PLL3 = (27 * 280 / 33) = 229.09 Mhz

y0 = 221.184 / 3 = 73.728 Mhz
y1 = 229.09 / 16 = 14.31 Mhz
y2 = 229.09 / 5 = 45.81 Mhz
y4 = 81.9 /3 = 27.3 Mhz

I guess that y0 is the feed to the FPGA (CLK_A ?)

divide by 4 = 18.432

now from looking at the clockgen code - the comment says Clk_a / 4 / G_Divider = 1Us, which would make me think it should be 18 (it is set to 11 in the source)


basically is this correct, and does it mean I use clk_sys as the clocking signal for my galaxian entity

* except * - now looking further, I need the clock to be 36.864Mhz anyway, so

PLL2 = (27 * 2048 / 375) = 147.458 Mhz
y0 = 147.458 / 1 = 147.458

divide by 4 = 36.864Mhz

the dot clock is still 6.144Mhz, so I assume I can leave the video clock as it was

(not that I am getting anything resembling a screen display yet!)

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

Yes, I'd say you can leave it. But best is to set up a simulation and check it out there, no long simulations needed to check the clock system.

Macro wrote:

now from looking at the clockgen code - the comment says Clk_a / 4 / G_Divider = 1Us, which would make me think it should be 18 (it is set to 11 in the source)

Oh, good point, very likely I missed updating this one - even in othe other cores. Will have a look.

Quick guess: might be the solution on the PS/2 issues reported, as the resulting 1us strobe is exactly used in the ps2 module of the replay lib...

/WoS

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

well, I think I have worked out what I am doing wrong in the video section, so will fix that and then see if I get a screen display or any sort.

10

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

Just as a hint: you can use the AUX_IO(15) down to AUX_IO(4) as output on your core for debugging of the FPGA design. It goes to the I/O connections at the back of your replay board (the field of 0,1 inch connector field with some 5V/3.3V/GND connections between).

This is more than enough to put e.g. most important signals for clocks, sync, blanking, etc. there to easily acquire them with an oscilloscope or logic analyzer...

/WoS

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

ah, good plan - I better add something to the case to bring those to the outside world (or maybe just connect the logic analyser to them permanently!)

12 (edited by JimDrew 2014-09-27 21:43:02)

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

ACK!  This means that I can make an adapter right now for a floppy drive for the Amiga core and IEC connector for the VIC20/C64 cores!?!?!  I didn't know those were available as general I/O.  Are those AUX_IO lines 1.5v, 3.3v, or 5v signal levels?

13

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

12x I/O, 3.3V and unprotected connection to the FPGA pads. I initially used it also to connect a sd2iec and a 1541 before I had the implementation on the Replay itself. This pins are the same as on the expansion connector, so it may also collide if another expansion board is used on the Replay. See schematics page 7 on the left.

So I'd propose to use it only for measurements/debugging of cores to avoid damage (I soldered some pinstripes there to connect a LA).

/WoS

14 (edited by JimDrew 2014-09-28 01:48:04)

Re: Howto: calculating PLL params for dedicated SYSCLK/VIDCLK

The lines would need to be level shifted for retro hardware, which would protect the FPGA.  If Mike makes an expansion connector available then that would be great, but in the mean time a simple level shifter board for the 12 I/Os could give us immediate access to real floppy drive support for the Amiga core, and a IEC interface for your VIC-20/C64 cores.