Concept & Design of 3.3V Parallel 16-bit VGA Boards

[ElEctric_EyE]

I guess this is a question more for Arlet since I'm using his HVSync module, but anyone feel free to post.
I have both boards working, but I have a problem syncing 100% to the first board...
Presently, PVB2 is the output board and 100MHz master clock originates from it. PVB1 generates the HSync, VSync, and 45MHz pixel clock for PVB1&2. I'm seeing a good picture on PVB2 of a line and circle drawn by PVB1. No scrolling/noise, etc. But the hblank and vblank are not in-sync. Presently there is no way to pass these signals from board to board.
Is there any way to sync the 2 boards by just using the Pixel clock, Hsync and Vsync?

Code: Select all

// update registered outputs
always @(posedge clk) begin
	    hsync  <= HSYNCin; 		//hstate == SYNC;		
	    vsync  <= VSYNCin; 		//vstate == SYNC;		
	    hblank <= (vstate == VIDEO) & (hstate == VIDEO) & hcount_done;
	    vblank <= vstate != VIDEO;
	end

EDIT: A quick and dirty way that almost works is to have the FPGA PROM program the 1st board at a slower speed. PVB2 has a program speed of 22 and PVB1 a speed of 12. It almost works because the hblank has already begun to creep from the left and cuts about 20 pixels off. Both boards are close to being sync'd on power-up, but resetting either board throws them out of sync. This shouldn't be a problem in the short term

[Arlet]

If the master board sends the pixel clock, hsync, vsync, and pixel data to the slave board, it should be able to sync to that. Of course, it would require modification of the hvsync module to accept incoming hsync/vsync signals, and use them to synchronize its internal state.

[ElEctric_EyE]

Ok, just checking. I know you've said it at the beginning of this project. I will have to think on it some more, but 1 clock after (VSync & HSync)+HPORCH would be the start of the first pixel?

[Arlet]

Basically, watch the hsycn/vsync signals. If the hsync is asserted, force the horizontal state machine into the last cycle of SYNC state, and keep it there. When hsync is deasserted, let it run normally. Use the output hsync to generate the image.

Do the same for vsync.

Run master/slave in simulator to verify all slave signals are synchronized to master signals with the same delay.

Align pixel data to the same delay.

If you need more time for pixel data processing, add more delay to hsync/vsync. Not that its perfectly acceptable if the master/slave are not 100% in sync. What you want is a delay that's the same for all signals.

[ElEctric_EyE]

Good info, I will think on it. Thanks.

[ElEctric_EyE]

Arlet wrote:

... force the horizontal state machine into the last cycle of SYNC state, and keep it there...

How would I do that?

I was able to sync the 2 boards on power-up by using a common pixel clock, ignoring the hsyncin/vsyncin signals, and adjusting the horizontal back porch -16 cycles and horizontal front porch +16 cycles on the 2nd board. 1 board output a blue character 'b', the 2nd board a red 'b', resulting in purple. Resetting either board of course throws them out of sync.

[Arlet]

something like this

Code: Select all

if( incoming_hsync_asserted )
    hstate <= SYNC;
else
   .. normal hstate processing ..

The idea is that incoming hsync forces hstate in same condition. As soon as hsync is deasserted, the state machine continues normally. You need to do something similar for the counter.

As always, I recommend making a simulation with 2 instances of the VGA controller hooked together, so you can actually see the timing.

[ElEctric_EyE]

Arlet wrote:

... You need to do something similar for the counter...

I seem to have some success with the counters. The boards are sync'd now with this code, even when resetting either FPGA Program button, but screen not positioned correctly. Having trouble with setting the state machine below...

Code: Select all

// adjust down counter. Reload when it's done.
always @(posedge clk) begin
		  if( HSYNCin | hcount_done )
		  hcount <= { 1'b0, hload };
	     else
		  hcount <= hcount - 1;
end

Code: Select all

// adjust down counter. Reload when it's done.
always @(posedge clk) begin
	if( venable ) begin
	     if( VSYNCin | vcount_done )
		  vcount <= { 1'b0, vload };
	     else
		  vcount <= vcount - 1;
	end
end

I'm failing here, I'll post your hsync state machine, vsync is similar. The monitor is locked on, but there is no video. I have my additional code commented out in order for video to be displayed:

Code: Select all

// when down counter is done, go to next state
always @(posedge clk) begin
		//if (HSYNCin) hstate <= SYNC;
		
		if( hcount_done ) 
			case( hstate )
				VIDEO : hstate <= FRONT;
				FRONT : hstate <= SYNC;
				SYNC  : hstate <= BACK;
				BACK  : hstate <= VIDEO;
			endcase
end

[Arlet]

Start with just the horizontal synchronization, and check results in simulation, make sure the time offset is constant. Then add the vertical. Without seeing the waveforms, I'd be hesitant to say exactly how to do it.

[ElEctric_EyE]

Ok, after daily attempts, I almost got it! Lots of trial and error, I don't even come close to being called an engineer.

But, both boards are in sync now, as far as HSync, VSync, HBlank and VBlank.
I am now focusing in on the Horizontal and Vertical Front and Back Porch values on both boards, as these values will definately differ between boards, in order to make up for the delays so both pixel outputs will be 'centered'.
Low initial values of 2 for both boards' HFP, HBP allowed the whole screen to be seen without HB or VB to interfere. VFP and VBP remains the same so far even though I can see they're not vertically lined up either.

[ElEctric_EyE]

Success!
I finally realized HSYNC pulse could be changed to a near zero value on the first board since it is not the HSYNC pulse going to the monitor. This allowed me to add more to HBP, the left border, to finally sync both boards. Also, I had to add 11 cycles (pixels) to VBP on the first board, to adjust it vertically.
Interesting to note that HFP+HVIDEO+HSYNC+HBP has to be the same on both boards or the video is scrambled. VFP+VVIDEO+VSYNC+VBP can be different.

I only had success syncing the horizontal and vertical state machines to the VIDEO state when HSYNCin or VSYNCin were active.

I have to finish the v1.0i board. I will receive 3 boards. After a successful test I will start a new thread.

EDIT 9/11/13: v1.0i complete! Ordered 3 more boards. Just a couple changes: No 5v required, now 2 separate 3.3v supply inputs. 1 feeds the videoDAC only through a LC filter. No Flash memory, SD card and lost 1 testmode pushbutton. New faster 4.0ns SyncRAM with provisions for FPGA control of burst reads/writes and flow-thru or pipeline modes. Also most exciting, is the utilization of the 2 databus parity bits. So each pixel can be assigned 4 functions. The onboard can oscillator is no longer routed to 2 FPGA clocks and then offboard. Instead it feeds 1 FPGA clk, and the other FPGA clk receives an offboard clock.

EDIT 9/18/13: Boards are in. IC's are in. Will have to wait till next week for assembly of 3x PVB v1.0i.
EDIT 9/22/13: BAH! I ran out of the 96-pin main connectors. 2 boards have been soldered up. Waiting on connectors.

[ElEctric_EyE]

I found 1 more 96-pin r.angle connector I needed to make 3 boards functional today. I had overlooked it as a vertical type since it was still wrapped in packaging.
After the hotplate and some touching up, it is up and running. Now 3 boards are outputting good video. It is almost a cookie cutter system at this point, meaning I can copy and paste an entire project and change a few timing variables in the HVSYNC generator for each board and the pictures are lined up and in-sync with increased throughput. This was the goal of the parallel system.

For the horizontal delay, after hstart, I figured out each board seems to have 6 cycle delay. So the PVB(5) before the last output PVB(6) had a delay of 6, PVB(4) has a delay of 12 cycles.

The vertical delay seems to be 11 scanlines. For PVB(5) I adjusted this by changing the Vertical Back Porch from 30 to 41. PVB's(5&6) were in sync and lined up although slightly stretched vertically. This was the quick way to account for the vertical delay, not the correct way. Now with PVB(4) adding 11 cycles to 41 causes the monitor to intermittently lose sync.

How can I do the vertical delay correctly? I have a skull full of mush right now.

Some pics.

[ElEctric_EyE]

Now 4 of 6 boards constructed, tested and "working", plugged onto 1 mainboard backplane. The board on the very bottom is an early defunct backplane. I put it to work since it has identical holes for the vertical spacers, in order to strengthen the entire structure.

Some of my Verilog coding needs attention, more time is required to make them all funtional.

[ElEctric_EyE]

Redirected from here. I started to go off topic from n00b Verilog questions, which is what the thread was/and should be about.

Thank you for tolerating my struggles, I apologize for a seemingly repetitive posting. Though, this is the last thorn. It has been pricking me for 4 months now...

Arlet wrote:

...I don't understand why you have 5 and 11 cycles delay. Doesn't the delay depend on when the boards are switched on ?

All 4 boards are sync'd. After initial powerup, when resetting any one of the 4 boards, all 4 pixel streams are still sync'd on the final output board. But this final board is displaying a progressively skewed summation (after removing my previous delay attempts).

Soon I'll post a block diagram of how I have the signals routed, and also post your vga generator I modified.
I'm working on an accurate hand drawn diagram of the current system, something I don't do very often but probably should.

Also, each board has been programmed to draw a circle now. Same center, radius decreases by 2 pixels and colors go from Red, Green, Blue, Yellow. Should be easy to see when they are lined up.

[ElEctric_EyE]

I found a routing error in the hardware. It involves mixing versions 'h' and 'i'. Version 'h' had a design flaw where the output of the 100MHz can oscillator would go to 2 input pins of the FPGA and be routed off-board to be used as the main clock source, according to where it that pin is positioned on the backplane. The flaw is that the can oscillator can only drive 1 FPGA effectively.
When working with 2 version 'h' boards, I circumvented this problem by outputting the pixel clock from the board controlling the monitor to the previous video board's pixel clock "output", but made it an input instead. The problem with that was, the previous board's videoDAC clock was being driven by another board, not by the FPGA. So this was causing the skew.

I made corrections to both 'h' boards, so now they function like the 'i' boards.

Now I'm trying to make 1 board output a mainclock using a pin from the FPGA to drive 2 boards.

There may still be a problem in the near future trying to drive 5 FPGA's using 1 FPGA pin at 70MHz at 24mA (max).

Also, I tried running 2 boards each with their own oscillators enabled. There was tearing in the final picture.