[Open-graphics] video controller output clock

[André Pouliot]

Michael Meeuwisse wrote:
> I continued digging a little, the vid_control module has vid_clock as 
> an input, module video_wrapper uses this module and also has vid_clock 
> as an input. Right now, the s3_top_level maps vid0_clock or vid1_clock 
> to these inputs, but these signals are somewhat odd;
Actually they are correct. The clock enter the the video_wrapper and 
after that also enter the vid_control the direction seem ok. The 
direction of the signal when coming from a top module, are keep in the 
level below. When connecting 2 device on the same level, the 
source(output) must be in oppositions with the receiver(input).

> BUFG Vid0_BUFG (
>     .I(vid0_clock_ext),
>     .O(vid0_clock)
>     );
>
> vid0_clock_ext is once again, an input:

Normal we receive the clock from the top and we want to force it on the 
clock tree. The BUFG is the definition of a device inside the spartan3 
to force the signal to use one of the global clock tree.

>
> // Tempory hack to make everything pass synthesis
>     input mem_clock_ext,
>     input vid0_clock_ext,
>     input vid1_clock_ext,
>
> Am I deducting correctly that this comment is an elegant "TODO", and 
> the clocks aren't dynamic yet?
>
I'm the one who added these signal, the clock weren't connected yet in 
s3_top_level and I was trying to solve some of the problem present for 
the synthesis and simulation. So I added the signal necessary to make 
everything pass and to be sure to have those signal on the clock tree. 
But no they aren't dynamic yet. To have a dynamic clock rate I was 
thinking we would use the DCM, but apparently on the spartan3 there 
isn't any port to change the frequency configuration at runtime like the 
DCM present in the V4 and above.

> On 4 Mar 2008, at 02:24, Timothy Normand Miller wrote:
>
>> The simplest way is to have a high frequency into a divider.  But
>> that's kinda limited.  Another thing you can do is take the DCM
>> output, run that through a divider, and then use the output of that as
>> feedback.
>
> The problem is that the frequencies needed don't really have a common 
> divider, unless you start running several GHz. Say, for example, we 
> want some basic ones;
>
> 640x480 @ 60Hz = 25.175 MHz (say 25, works just as fine)
> 800x600 @ 60Hz = 40 MHz
> 1024x768 @ 60Hz = 65 MHz
>
> I guess we could do something like, run at 130 MHz. Then we get
> 640x480 - divide by 5.2 (count to 5, every fifth time count to 6?)
> 800x600 - divide by 3.25 (count to 3, every fourth time count to 4?)
> 1024x768 - divide by 2
>
> Correcting the clock like that all the time is bound to give odd 
> display results. So I don't know how to do it, but a divider sounds 
> imho impossible.
When searching for the right frequency for a video display there is not 
only the period for the signal on the screen but also the blanking time 
that you must factor in. We have 2 reference clock with different 
frequency we just have to select the signal using a BUFGMUX  who would 
allow to have either one used. The 2 clock available on the card for the 
video are one who is 44.647MHz and the other 14.318Mhz. Normally with 
those we should have a range wide enough of frequency for some video 
configuration. 

To make the system dynamic actually I don't really see how except by 
implementing the BUFGMUX and the clock divider using logic. We could 
always generate a higher frequency using the DCM but it's parameter are 
fix at compile time. The easier solution if the board isn't finished 
would probably having an external PLL who could be programmed.