On 10/17/06, Simon Persson <[EMAIL PROTECTED]> wrote:
For my video controller I looked at some code from Xilinx for inspiration, didn't copy anything except the timing numbers. The copyright notice for that code:
Well, it would likely be hard to claim copying, since you're just using facts, but just to be safe, you may want to acquire the numbers from another source and rewrite that bit from scratch.
I've been playing around with this the last couple of evenings, I have an analog_monitor.v together with test case working. But with the dvi I ran in to the situation where on one clock edge the same data is read into two registers that are in series. The first being the outgoing pixel data and the second one the incoming in the "monitor" code. I feel silly for not thinking about this sooner... but is it the clock or data that will be delayed? How will that be done? The de-skew feature of the SiI178 doesn't seem enough. Generally, how is this problem of pure transmission (no combinatorial delay) solved?
I think what we do is delay the clock 90 degrees after the data. So, data, then rising edge, then next data, then falling edge, in 90 degree increments to complete the full cycle. Also, it's very important that all output signals be in registers in the I/O buffers. This minimizes timing skew. You almost never want to deal with an I/O without registering it first in the iob, although we do have to do that a bit in cases like #frame and #irdy in PCI. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
