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

Topics relating to PALs, CPLDs, FPGAs, and other PLDs used for the support or creation of 65-family processors, both hardware and HDL.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

Arlet wrote:
I'm not sure how ISE would interpret that. I do think merging them in one module would be a good idea.

Have you tried reducing the clock ? You could try running the design at 10 MHz and see if that works better. At 10 MHz, the propagation delays would be small enough to meet setup times, so you can focus on functional correctness.
I have now just this morning tried reducing the cpu clock by 1/4th of the vga and SyncRAM clocks, and the read worked! Which I guess proves my interface modules is working, just the timing is off? I was 10 min's late for work, so I didn't have time to check the ISim waveforms. I will do that tonight.

What is needed to align the cpu reads? Not as simple as a PLL phase shift for the cpu clock when everything is running at the same speed?

EDIT: Reducing the cpu speed by 1/2 always works when reading and writing to external memory. I will post the simple software I use to copy an 8x8 pixel character from origin (0,0) to (8,0) before I retire tonight.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

Too tired for further testing today, but here is the software I use to copy the character from external videoRAM and paste that data right next to the original. The original character is written by a separate PLTCHR software routine.... The indirect W comes into play here for an easy time with copy/pasting indirect indexed style, which is needed since the LSB is the X, and the MSB is the Y in the HVSYNC generator. This is .b core compatible BTW...

Code: Select all

                  LDA #$00
                  STA SCRHI               ;y position
                  STA SCRLO               ;x position
                  LDX #$08                ;use X reg for easy test for end of y position
CHSH2             LDY #$00
                  LDWi $0008              ;LDW #$0008
CHSH              LDA (SCRLO),Y
                  STAiw (SCRLO),W         ;STA (SCRLO),W
                  INW
                  INY
                  CPY #$0008
                  BNE CHSH
                  INC SCRHI
                  DEX
                  BNE CHSH2
Also, my interface module has changed (never got around to the state machine!!!), sorry for the lack of comments. Also this module is still separate from the HVSYNC generator, so the bidirectional bus to/from the external video SyncRAM appears to be successfully routed to 2 modules. 1 read only, 1 read/write:

Code: Select all

module SRAMif( input clk,
					input [15:0] cpuDO,
					input vramCS,						//cpu is reading/writing to videoRAM
					input cpuWE,
					input RAMWE,						//LineGen is drawing
					input CB0,							//Control Bit 0 from cpu to control page 0 or 1, when page flipping
					input CB1,							//Control Bit 1 from cpu to control page flipping or scrolling
					input CB2,							//Control Bit 2 scrolling horizontal or vertical
					inout [15:0] SRD,
					input [15:0] QACCout,			//pixel color from cpu
					input [9:0] X,						//LSB of LineGen address
					input [9:0] Y,						//MSB
					input [20:0] Vaddr,				//pixel clock address from HVSync Generator
					input [31:0] cpuAB,
					output reg [20:0] SRaddr,
					output reg [15:0] SRDO,			//to cpu
					output reg SRWEn
					);

reg [15:0] SRDI;
reg SRWEn2;

always @(posedge clk) begin
	SRWEn2 <= SRWEn;
		if (RAMWE && !vramCS) begin
						  SRDO <= 16'h0000;
						  SRDI <= QACCout;
		end
		if (!RAMWE && (vramCS && cpuWE)) begin
						  SRDO <= 16'h0000;
						  SRDI <= cpuDO;	  
		end
		if (RAMWE && (vramCS && cpuWE)) begin
						  SRDO <= 16'h0000;
						  SRDI <= QACCout;	  
		end
		if (!RAMWE && (vramCS && !cpuWE)) begin					//reading from RAM
						  SRDI <= 16'hZZZZ;
						  SRDO <= SRD;
		end
	 else 		  	  SRDO <= 16'h0000;
end

reg [20:0] cpuABopt;

always @* 													//optimize the videoRAM address for plotting (X,Y) in the (LSB,MSB) for indirect indexed
	 begin													//CB1 = 0, page flipping
			cpuABopt    [20] <= CB0;					//bank bit
			cpuABopt [19:10] <= cpuAB [31:16];		//Y[9:0]
			cpuABopt   [9:0] <= cpuAB [15:0];		//X[9:0]
			
			SRaddr <= RAMWE ? { CB0, Y, X } : vramCS ? cpuABopt : Vaddr;
			SRWEn <= !(RAMWE || (vramCS && cpuWE));		//0 = write to RAM
	end
	
assign SRD = SRWEn2 ? 16'hZZZZ : SRDI;				//I/O MUX'd latch to SyncRAM databus. High 'Z' during a read	

endmodule
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

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

Post by Arlet »

What exactly goes wrong at higher speeds ?

I looked at the code, and I'm not sure how this is supposed to work. If I understand it correctly, you have 3 modules accessing the RAM, but how are these coordinated in case of simultaneous attempts ?

It may be easier to start with a simpler module that just hooks up the CPU to the RAM, and then try to write some test data and read it back. Leave out the video business until then.

Also, I recommend making one multi-ported module to interface the SRAM, but just make generic ports with address/data buses, and no pixel translation or bank flipping. Then add these features to another module that attaches to this one. That way this module only has to deal with memory access, and not all the other stuff.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

Arlet wrote:
...I looked at the code, and I'm not sure how this is supposed to work. If I understand it correctly, you have 3 modules accessing the RAM, but how are these coordinated in case of simultaneous attempts ?...
3 modules access the RAM, I had overlooked my previous statement of 2 modules. RAMWE is a write only to the RAM, it has priority of the RAMs addr:

Code: Select all

SRaddr <= RAMWE ? { CB0, Y, X } : vramCS ? cpuABopt : Vaddr;
and RAM data bus:

Code: Select all

...if (RAMWE && !vramCS) begin
                    SRDO <= 16'h0000;
                    SRDI <= QACCout;
      end...
if (RAMWE && (vramCS && cpuWE)) begin
                    SRDO <= 16'h0000;
                    SRDI <= QACCout;    
      end
Arlet wrote:
What exactly goes wrong at higher speeds ?...
It seems to be reading the data meant for the videoDAC. When I clear the screen and plot the 1st character to be copied @origin(0,0), it's plotting background color @origin(8,0). An interesting note: When I don't do a clearscreen or plot a character, and run the copy/paste routine, it fills the 8x8 block with one pixel color. Looks like maybe the very first pixel of the scanline.

Thanks for your suggestions, I'll see if I can work on it after I let the ideas sink in to my thick skull.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

Been multitasking this morning. But I have confirmed now my suspicion from my last post. So when it is reading from the RAM, the address the RAM is getting appears to be not from the cpu, but from the HVSync module. The very first pixel on every read. I will look at my logic and run some more Sims.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

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

Post by Arlet »

That's what I wondered about. I don't see any logic that deals with collisions between different users. If you want the HVSync module to have higher priority than the CPU, that's okay, but then the CPU request needs to be stalled by deasserting RDY, and delaying it to the next cycle. Similarly when you assign the CPU higher priority, then the HVSync module needs to be stalled.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

Arlet wrote:
...Similarly when you assign the CPU higher priority, then the HVSync module needs to be stalled.
Ah, I understand that now. Thanks!

EDIT: That is a fairly basic design principle I overlooked, and it keeps happening because this whole design is in my head. I will go back like I used to do and design with a schematic on paper, then write the Verilog to match.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

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

Post by Arlet »

Usually I have 3 wires between the memory module and another module: a request signal that marks the request of a transaction, an ack signal that indicates the request is being processed, and (in case of a read) a valid signal that indicates the requested data is valid.

When the requester sees the ack, it should pull down the request signal in the next clock, unless it means to continue a burst.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

I just about have the screen capture utility installed so I can show some waveforms soon from ISim.

Today after work I was looking the waveforms from the project and noticed, according the SyncRAM datasheet, that that clock was inverted. So I fixed it and the videoDAC clock. They should be the same, but I generate 2 separate identical signals from the PLL, so if I need to delay one further I can.

The last clock to consider is the cpu clock. It is the same speed (70MHz, 14.28ns cycle time) as the pixel clock going to the videoDAC and SyncRAM. I made it so that the cpu clock goes high about 3.5ns prior. This is an attempt to take into account for the FPGA delay for the softcore cpu.

So now, the waveforms I see in ISim are in-line with the SyncRAM datasheet, and writing to the SyncRAM is good to go as it was before. But I do not count on luck anymore.

I will attempt some pics next.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

Here are the 3 clocks SRCLK= SyncRAM, PCLKout=videoDAC, & clk2=65Org16.d FPGA softcore from ISim. The first 2 go off FPGA through DDR FF's, clk2 is the internal 65Org16.d softcore clock. I will have more tomorrow, sorry very late here.
Attachments
sram.pixel.cpu_clks.jpg
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

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

Post by Arlet »

Which clock are you using to clock the data/address outputs ? The SyncRAM has non-zero setup/hold.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

Arlet wrote:
Which clock are you using to clock the data/address outputs ?...
I'm not sure how to answer your question. Which data/address outputs? FPGA to SyncRAM? or SyncRAM to FPGA?
Arlet wrote:
...The SyncRAM has non-zero setup/hold.
The address and data are present almost a half cycle before the SyncRAM clock goes high. I think I'm safe there.
I'll have more timing pics tonight for a write and read.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

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

Post by Arlet »

ElEctric_EyE wrote:
I'm not sure how to answer your question. Which data/address outputs? FPGA to SyncRAM? or SyncRAM to FPGA?
FPGA to SyncRAM.
Quote:
The address and data are present almost a half cycle before the SyncRAM clock goes high. I think I'm safe there. I'll have more timing pics tonight for a write and read.
Ok, good. Maybe you can reduce the setup time later, but for now it's good to be extra safe. I'm surprised the SyncRAM doesn't have zero setup/hold times.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

FPGA to SyncRAM is clocked by clk2. clk2 runs the cpu and blockRAMs. I forget if it is running the SRAMif module, I'm away from the project at the moment. It is skewed/i.e. phase shifted to account for the FPGA delay.
EDIT: The SRAMif module is clocked by clk2.
ElEctric_EyE
Posts: 3260
Joined: 02 Mar 2009
Location: OH, USA

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

Post by ElEctric_EyE »

This is the program I am running for simulation purposes only, to try to figure out where the problem lies. It sets some control bits, but does not clear screen or plot a character. Those functions do work, out of simulation, as they are write only. I skip them for simulation because they take a great many cycles to complete... So here I am copying a 8x8 pixel character starting @(8,0) and pasting @(16,0):

Code: Select all

                          ;CB0 : PAGE FLIP CONTROL
                          ;CB1 : 1 = SCROLL, 0 = PAGE FLIP
                          ;CB2 : 1 = SCROLL HORIZONTAL, 0 = VERTICAL
                          ;CB3 : TBD - to be determined
START:            LDA #$1000              
                  TAZP                    ;SET ZEROPAGE @$1000_0000
                  LDA #$1001
				      TASP                    ;SET STACKPAGE @$1001_0000
                                          ;
                  CCB0                    ;0 = VIDEO PAGE 0, 1 = VIDEO PAGE 1
                  CCB1                    ;0 = PAGE FLIPPING, 1 = SCROLLING
                  CCB2                    ;0 = VERTICAL, 1 = HORIZONTAL

                  LDA #$00
                  STA SCRHI               ;y position
                  LDA #$08
                  STA SCRLO               ;x position
                  LDX #$08                ;use X reg for easy test for end of y position
CHSH2             LDY #$00
                  LDWi $0008              ;LDW #$0008
CHSH              LDA (SCRLO),Y
                  STAiw (SCRLO),W         ;STA (SCRLO),W
                  INW
                  INY
                  CPY #$0008
                  BNE CHSH
                  INC SCRHI
                  DEX
                  BNE CHSH2
                  
ENDALL            JMP ENDALL
The first pic shows IR(opcode) $b1 which is LDA(SCRLO),Y in the program. The next pic shows IR(opcode) $92 which is STAiw (SCRLO),w. Everything seems to be inline for the SyncRAM as far as I can tell. And like I previously mentioned, when clk2 is running half speed everything works perfect! TIA for some pointers.
Attachments
LDAiw.jpg
STAiw.jpg
Post Reply