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.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
