On 3/4/08, Michael Meeuwisse <[EMAIL PROTECTED]> wrote: > > 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?
I think you will want to have the odd numbers for more precise control over the frequencies you get. Also, don't worry that the duty cycle isn't 50/50. The DCM will fix that. > > > > 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. You TOGGLE it every clock, which divides by 2. > 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? Yup. > > > >> So anyway, I figure we don't have this implemented yet, and it's > >> time > >> I get laughed at* for trying to write something in Verilog. See > >> attached. *Any* comments are most welcome, I'm not even sure if I > >> get > >> the 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[1] end up being 1? Yes. BTW, only clock on clocks. Then use 'if' to decide whether or not to assign. > 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? Yup. > 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. The final clock output should go through a BUFG. > Lastly I'm not sure if my naming convention is understandable. I > personally don't really like the _reg bits. It just looks wrong :) I tend to use Hungarian-like notation only on module ports so that you can tell the direction from an instance (with pass by name) what the directions are. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
