On 8 Mar 2008, at 05:22, Patrick McNamara wrote:
1. How precise does the actual clock frequency need to be? 640x480x60
is specified as 25.175MHz with standard blanking intervals.  How close
to we have to be?  Is 25MHz close enough?  That's a 0.7% error.
Somebody that know more about the technicalities of monitors and video
equipment may be able to answer.

From experience I can tell that 25MHz works just fine, but I'm not sure sensitive higher frequencies are.

2.  At reset divisor0 and divisor1 are set to 0.  This is an invalid
value for both. What happens to the clock generator with these values?
Should we initialize to a good value?  The first question I can answer
when I get a moment to study the code under simulation. The second is a
design question for which I want opinions.  If we do initialize it, to
what frequency?

I already added that as a TODO, I can't find any information about it. But that's maybe because I'm not trying hard enough or looking for the wrong things. My guess is that the input clock is too fast, the DCM will never lock, and the output will be nothing. My fear is that the DCM doesn't like it and gets fried - but I doubt it.

3. Does Xilinx have a Verilog DCM simulation model? I haven't made it
to their site to check so by the time someone answers this, I may
already know.  If not, can we write one in pure Verilog?  I think the
answer is no. If both answers are no, then I will work on a VPI module to emulate the DCM so that we can actually simulate the video controller
properly.

I couldn't find any information about that it /didn't/ exist, so I guess that if you simulate in Webpack it 'just works'. I'm not really experienced with simulation clocks - does anyone know how to simulate a couple of billion cycles without actually displaying each and every one of them?

Patrick M


Cheers,

Michael
www.projectvga.org

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

Reply via email to