6502.org http://forum.6502.org/ |
|
Concept & Design of 3.3V Parallel 16-bit VGA Boards http://forum.6502.org/viewtopic.php?f=10&t=2247 |
Page 35 of 41 |
Author: | ElEctric_EyE [ Sun Jun 09, 2013 10:24 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | ElEctric_EyE [ Sun Jun 09, 2013 11:17 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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: 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: 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 |
Author: | Arlet [ Mon Jun 10, 2013 6:05 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | ElEctric_EyE [ Mon Jun 10, 2013 10:48 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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: SRaddr <= RAMWE ? { CB0, Y, X } : vramCS ? cpuABopt : Vaddr; and RAM data bus:Code: ...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. |
Author: | ElEctric_EyE [ Tue Jun 11, 2013 4:32 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | Arlet [ Tue Jun 11, 2013 4:37 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | ElEctric_EyE [ Tue Jun 11, 2013 4:44 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | Arlet [ Tue Jun 11, 2013 5:02 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | ElEctric_EyE [ Sun Jun 16, 2013 12:32 am ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | Arlet [ Sun Jun 16, 2013 12:22 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
Which clock are you using to clock the data/address outputs ? The SyncRAM has non-zero setup/hold. |
Author: | ElEctric_EyE [ Sun Jun 16, 2013 3:33 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | Arlet [ Sun Jun 16, 2013 4:02 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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.
|
Author: | ElEctric_EyE [ Sun Jun 16, 2013 4:15 pm ] |
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards |
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. |
Author: | ElEctric_EyE [ Sun Jun 16, 2013 10:15 pm ] | |||
Post subject: | Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards | |||
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: ;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.
|
Page 35 of 41 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |