Rob Finch wrote:
What kind of connector are you using? Does it connect directly to the FPGA through circuit traces? Using a ribbon cable for instance will pick up a lot of noise.
What does the timing circuit look like? Are the sync signals registered outputs? Are the ram address signals registered? Is the address the output of synchronous or ripple counters? It looks like there may be some sort of delay in one of the counter bits. There is a little glitch 16 rows apart.
Using a mercury II (Xilinx Artix 7) connected to one of the DVI PMOD's for the icebreaker. the PMOD is connected through jumper wires that are ~100mm long. I get nearly the exact same interference running a 25mhz (640*480) clock as the 40mhz 800*600 clock.
The mercury II has a 50mhz oscillator driving the PLL putting out 200mhz for the main FPGA clock and another @ 40mhz for the video. The counters are just registers that get incremented at the rising edge of the Vid clock. All outputs are registered and pipelined through a clock cycle to allow time for the read of the memory.
This is the sequence of events
1. On rising edge of the Vid Clock the following takes place sequentially.
A. the "next{vSync | hSync | DE | RGB} registers are copied to the corresponding output registers
B. counters are incremented
C. counters are mapped to memory address output register
D. SRAM CE is pulled low.
D. next{vSync | hSync | DE} registers are set based upon the current values of the counters.
2. on the falling edge of Vid Clock the value of the SRAM data lines are stored to the nextRGB register.
Timing wise it should be plenty of time. The counters look like this
reg [15:0] hcounter = 16'b0;
always @(posedge vClk) begin
if (//some logic) begin
hcounter <= hcounter +1;
end
end
My source code was attached as a zip to the first post. I didn't want the post to be too long so I didn't imbed. I can imbed if that helps?