Useful Information for Final Projects
add matlab; matlab -ver 8.0
assign ram_clk = ~clk;
The period of a 65Mhz clock is 15ns. When propagation delay stack up in wrong direction (with a 15ns inverted clock, you have only 7.5ns of propagation delay budget), inverting the clock will no longer suffice. Fortunately, Nathan Ickes, the labkit designer took this into account and provided for deskewed clocks. However, using it can be tricky since the deskewed clock utilizes I/O flip-flops (OFDDRRSE) for the RAM and feedback clock outputs. These special primitives are actually part of the I/O driver circuitry on the FPGA. This means that you will not be able to use these inputs or outputs anywhere else in your code. The net result is that the clocks must go directly to the ram and not to any other instantiated module. His sample ramclock module must be part of the top level labkit module.
An example of correctly using ramclock is shown the updated sample NTSC Verilog .
Since the hold time for the ZBT is only 0.5ns, using deskewed clocks should make for a clean design. This document describes the details of the deskewing:
"Inside the FPGA, clocks are distributed using dedicated clock trees, which ensure that the clock signals reach every flip-flop relatively simultaneously. If the clock inputs of the ZBT memories are driven by outputs of the FPGA, then the clock signal at the memories will be delayed by the sum of the propagation delay through the FPGA output pins and the propagation delay of the PCB trace.
To correct this skew at the memory devices, we need to drive the ZBT clock inputs with a phase-shifted version of the clock, so that the rising clock edge reaches the memory devices at the same time that it reaches all the registers in the FPGA. To generate this phase-shifted clock, a delay-locked loop (DLL) is used. DLLs are fundamentally analog components. There is no way to infer a DLL using Verilog code, so they must be instantiated. The Xilinx library component containing a DLL is the digital clock manager, or DCM."
In many cases, the left most column of pixels in the image is wrong. That's because of the pipeline delays in getting the pixels to the video DAC. The clean rigorous approach is to delay hsync, vsync, blank and a control bit by the correct clock cycles. Then use the control bit to select the pixels to be sent to the video display. In this way, the pixel values will be in sync with the video control signals.