On 4 Mar 2008, at 23:32, Timothy Normand Miller wrote:
First, don't bother with sanity checks in the hardware. It's the software driver developer's responsibility to put in the appropriate checks or indeed never generate bad numbers in the first place. There are rare occasions, where a bad value could physically fry something, where you might want to put in a check, but I don't think that's the case here.
I wasn't sure about the input to the DCM, and what it's output would be if the input is too fast. Got rid of the checks, but don't know how it'll behave after a reset. Essentially the DCM input will be 133 MHz at that point.
Also, your pre-divider looks like it's going to divide by 2N, not N.
Correct. If the divider is 4, one output clock cycle will take 8 input clock cycles. I figured this wasn't a big issue since if we want 96, we can easily set the divider to 48. This completely avoids the issue of how to deal with halves, etc.
For N=1, you just want to mux in the clock. For N=2, you toggle a register _every_ cycle. For even numbers, it's easy. For odd numbers, you alternate counting floor(N/2) and ceil(N/2). So, for N=2, the counts are 1, 1, 1, 1.... For N=3, the counts are 1, 2, 1, 2, 1, 2... Actually, you probably want to subtract 1 from all of the numbers I just gave, but you get the idea. Also, there are other optimizations we can make, but we'll start here.
Not an issue if we divide by 2N, right?
You probably have a similar bug with your divide-by-2-to-the-M post- divider.
I don't think so. If I want to divide by 1, I keep on setting the countdown to zero, thus essentially toggle the output every clock. Divide by 4 sets the countdown to 2, etc. I did make a typo there, the cases should be 1, 2, 4, 8, 16, 32, not 1 - 6.
For the DCM feedback, we don't care about the phase of this clock relative to anything else, but we do need a feedback. I think you can just wire CLK0 directly to CLKFB.
I'll find some docs about what this feedback is all about. But a wire connecting CLK0 to CLKFB will do the trick?
So anyway, I figure we don't have this implemented yet, and it's timeI get laughed at* for trying to write something in Verilog. Seeattached. *Any* comments are most welcome, I'm not even sure if I getthe concept of wires completely yet. ;)Ask questions. We'll answer. :)
Ok, this one I wasn't sure about:
valid_divisor[1] <= divisor1 > 0 && divisor1 < 7;
Is this syntactically correct? As in, if divisor is > 0 and < 7, will
valid_divisor[0] end up being 1?
valid_divisor[0] <= divisor0_reg > (sel_base? 22: 18);
And following the previous one, will it still work if there's a
conditional squeezed in there?
Also, I'm not passing lots of signals I'm using as clocks through a BUFG or anything. Should I? Say, divisor0_out for example.
Lastly I'm not sure if my naming convention is understandable. I personally don't really like the _reg bits. It just looks wrong :)
Cheers, Michael www.projectvga.org
vid_clock.v
Description: Binary data
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
