6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Mon Apr 29, 2024 3:24 pm

All times are UTC




Post new topic Reply to topic  [ 155 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 11  Next
Author Message
PostPosted: Wed Sep 26, 2012 3:04 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
OK Finally got it working! Closeup of the upperleft portion of the monitor. This is ramping RGB from high to low. Noise issue is gone as well.
Image

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 4:12 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
External control of the PROM select and FPGA /Program works as expected. 2 different patterns were programmed and selected successfully. Good news is PROM 1 & 2 designations on the board matches up with ISE. When ISE initiates the JTAG scan it shows the leftmost PROM (1), the middle PROM (2) and the FPGA on the right.

I think it's time to solder in the SyncRAM and try to come up with some simple HDL to try reading from it.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 4:43 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8155
Location: Midwestern USA
ElEctric_EyE wrote:
OK Finally got it working! Closeup of the upperleft portion of the monitor. This is ramping RGB from high to low. Noise issue is gone as well.
Image

Looks like designer vertical window blinds. :D Good job!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 5:10 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Well done!


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 6:26 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Guys, thanks! Very excited here. I soldered in the .65mm SyncRAM. Overdid it with the solder and used braid to get excess off. I like this technique! Will use it from now on. PVB powers up and runs still and no smoke...

Now I've been busy with some code and cannot use a testbench since there's no way to simulate the RAM. But I have made a successsful symbol with all the I/O's present, so the ISE tool must think it knows what I want to do. I've tried to approach it logically. Here goes:
Code:
module SRAMif( output reg [20:0] SRA = 0,
               output reg WEn = 1,
               output reg SRCLK = 0,
               output reg SRCS = 0,
               input [15:0] SRD,
               output reg [4:0] Red_data,
               output reg [5:0] Green_data,
               output reg [4:0] Blue_data,
               input clk50,
               input pclk,
               input hstart,
               input vstart,
               input hblank
               );
reg [15:0] SRDtemp;
reg countflag;

always @(posedge clk50)
      SRCLK <= ~SRCLK;      //pixel clk is SyncRAM clk
      
always @(posedge clk50)
   if ( hstart & vstart )   //reset address counter at top left of screen
      SRA <= 0;
      
always @(posedge clk50)
   if ( pclk )
      if ( hstart )
         countflag <= 1;   //countflag active in display area
      else if ( hblank )
         countflag <= 0;
      
always @(posedge clk50)
   if ( countflag )
      SRA <= SRA +1;         //increment RAM address counter
      
always @(posedge clk50)
   if ( pclk & countflag )
         SRDtemp <= SRD;   //latch incoming data

always @(posedge clk50)
   if ( pclk & countflag )
      begin
         Red_data <= SRDtemp [15:11];      //outgoing data to videoDAC
         Green_data <= SRDtemp [10:5];
         Blue_data <= SRDtemp [4:0];
      end
   
endmodule

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 6:43 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
Guys, thanks! Very excited here. I soldered in the .65mm SyncRAM. Overdid it with the solder and used braid to get excess off. I like this technique!

If you use too much solder, sometimes little blobs get stuck behind the pins. These can be nasty, as they are hard to see, and since they're only barely touching the pins, they don't always melt when you touch the pins with the iron. If that happens, you can fix it by adding some extra solder, and then use one of those hand held solder suckers to get it out. That's why I started to use the other technique I mentioned: load up a piece of braid, and use that as a brush to "paint" the solder on the pins. This avoids the problem in the first place.

In any case, try not to use really dry braid. If it works too well, it sometimes leaves too little on the pin. Instead, if it gets saturated, only cut off the end, but leave the half-saturated part. It's a matter of trial and error and experience to see how much you need.


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 7:19 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet wrote:
...In any case, try not to use really dry braid. If it works too well, it sometimes leaves too little on the pin. Instead, if it gets saturated, only cut off the end, but leave the half-saturated part. It's a matter of trial and error and experience to see how much you need.

Yeah, I used dry braid and it really took up the solder. I went back over the pins with the solder tip. We'll see if I was successful...

Last post with code passed syntax check and was able to make a symbol, but it did not synthesize. SRA was a reserved name, so had to change it, also SRCS was wrong value. I did not have the SyncRAM address outputs registered like I did with the databus outputs and got a multiple driver error. So I fixed it, and it passes sythesis. I tried it out. Getting totally random pixels all the time. Timing not right. But it's something!

Code:
module SRAMif( output reg [20:0] SRAddr = 0,               //SyncRAM address bus
               output reg WEn = 1,         //SyncRAM R/W, always read
               output reg SRCLK = 0,         //SyncRAM clock         
               output reg SRCS = 1,         //SyncRAM chip select
               input [15:0] SRD,            //SyncRAM databus
               output reg [4:0] Red_data,      //
               output reg [5:0] Green_data,      //videoDAC databus, always write
               output reg [4:0] Blue_data,      //
               input clk50,            //50MHz main clock
               input pclk,               //25MHz pixel clock
               input hstart,
               input vstart,
               input hblank
               );
reg [20:0] SRAddrtemp;
reg [15:0] SRDtemp;
reg countflag;

always @(posedge clk50)
      SRCLK <= ~SRCLK;      //pixel clk is SyncRAM clk
      
always @(posedge clk50)
   if ( pclk )
      if ( hstart )
         countflag <= 1;   //countflag active in display area
      else if ( hblank )
         countflag <= 0;
      
always @(posedge clk50)
   if ( hstart & vstart )   //reset address counter at top left of screen
      SRAddrtemp <= 0;
   else if ( countflag )
      SRAddrtemp <= SRAddrtemp +1;         //increment RAM address counter
      
always @(posedge clk50)
   if ( pclk & countflag )
         SRDtemp <= SRD;   //latch incoming data

always @(posedge clk50)
   if ( pclk & countflag )
      begin
         Red_data <= SRDtemp [15:11];      //outgoing data to videoDAC
         Green_data <= SRDtemp [10:5];
         Blue_data <= SRDtemp [4:0];
      end
      
always @(posedge clk50)
   if ( pclk & countflag )
      SRAddr <= SRAddrtemp;   //outgoing address
   
endmodule


Image

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 7:23 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Are the pixels stable, or are they flickering ?


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 7:25 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Always changing, like my address counter is not being reset.

EDIT: I will go back to the simulator and see how your HVSync module works.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 7:34 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Here's a verilog model of the RAM


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 8:08 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Thanks for looking that up. I'm sure i will need that in time, but now I know my problem is that the RAM counter is not being reset. My logic for resetting it using hstart and vstart is wrong. I must determine how to tell it the last pixel has been displayed. Maybe I could generate this signal from within your vga.v HVSynv module?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Sep 26, 2012 10:16 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Here's a problem:
Code:
   if ( hstart & vstart )   //reset address counter at top left of screen

The hstart and vstart pulses don't happen at the same time. Try resetting the address counter just based on vstart. The vstart signal comes early, so you can prepare the data path. At hstart, you start incrementing.

You'll still have artifacts because the code doesn't compensate for all the pipeline delays, but at least you should have a stable picture.


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 27, 2012 12:06 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet wrote:
...You'll still have artifacts because the code doesn't compensate for all the pipeline delays, but at least you should have a stable picture.

Arlet, thanks for your tip.
I'm aiming for a stable pixel generation (i.e. data from a fast read-only memory (in my initial test), non-FPGA Block Memory, but similar) and should be able to achieve it at such a low pixel clock (25 MHz, 40ns access time) without even looking at timing diag's. Hopefully this pass-thru synchronous RAM has a 6.5ns delay, not pipelined like the other versions of this Synchronous RAM.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 27, 2012 12:36 am 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
EEyE:

This comment is not going to help, but I suggest that you use a single clock for the SRAM. Your comment on the following code says it, so I would recommed using pclk as the clock source for the SRAM.

Code:
always @(posedge clk50)
      SRCLK <= ~SRCLK;      //pixel clk is SyncRAM clk


However, instead of using an assignment statement (and its potential path delays), I would suggest clocking the SRAM in the following manner:

Code:
always @(posedge clk50)
      SRCLK <= ~pclk;      //pixel clk is SyncRAM clk


This will allow pclk == 1 to function as the enable for input FFs in the IOBs, which appears to be already included in your SRAM interface module.

====================================================

Thinking on this a bit more, I suggest that you need to look at the path delays in the IOB relative to the SRCLK and pclk. My understanding of the signal timing means that your use of the same phase of the clock (pclk and SRCLK should be in-phase) means that you are sampling the data in the middle of the cycle instead at the end of the cycle. I expect that the data may not be stable at that point, or if it is, you have not applied a NO_DELAY attribute on the input buffer of the FPGA. In either case, the data is clearly not stable, unless of course the SRAMs are not initialized.

The changes I suggested above should alleviate this timing issue.

_________________
Michael A.


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 27, 2012 12:08 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
That does help. pclk and SRCLK need to be the same. I will just rename 1 and adjust the ucf accordingly. But I think what's happening presently is that with a 2MB RAM and 640x480=311040 pixels, the data being written to the videoDACs is overlapping on the display, since my address counter does not have the correct logic to reset to 0 at the end of the last pixel. That's enough memory for 6.7 displays.

Hopefully will have time tonight to try yours and Arlet's suggestions. Thanks!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 155 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 11  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: