Calculating clock speed

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want to use a SAM4S to drive an SVGA screen (800 x 600) in monochrome. The RGB foreground/background values are set by an ADG733 analog switch. I only need to put out whether each dot is foreground /background into the ADG733. Its output and the horizontal and vertical sync pulses are fed into the monitor. At 60Hz timing the pixel clock is 40 MHz but I believe the monitor will sync to a slower clock. The data will be read out of an array in memory so it only has to set one output pin value at the pixel frequency.

It takes clock cycles to increment the array pointer and set the pin value but I do not know how many so I do not know how fast the system clock has to run to make this work. Would someone give me an idea of how to calculate this? Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To do it in code would mean you would have three clocks per pixel. I'd suggest that is near impossible. How to calculate? Write the code to do the work then measure. You could count the instruction cycles as well. At best you've got three instructions assuming a 120MHz clock and each instruction takes 1 clock. The reality is the write to the port will take 2.

Next might be spi but i think the spi machine has at least 1 clock of idle for each transfer. There's the usart in sync mode as well. The dma controller might be able to assist.

I'd suggest using an external shift register chip to do the grunt work of shifting the bits. For an 8 bit one that would mean you have to load it every 200ns, so that might be doable. There's always the possibility of chaining them for 16 or 24 bits thus making things easier time wise.

Last Edited: Thu. Nov 12, 2015 - 08:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had hoped the speed of the SAM4S would be enough. I have an SAM4S Explained board that I could try some code. An FPGA is ideal for the task as it is just a cascaded series of counters running at the dot clock but I have not been able to find much information on how to program one into what I need. A lot of information on slices, LUTs, et cetera but nothing on putting these together into what I need.

One approach was to use a serial RAM to store the video frame with a clock to send the data to the ADG733 then a couple of dividers to generate the horizontal and vertical sync pulses. The problem is loading the SRAM. The input is from a MGA signal which at 9 x 11 character dots, 80 columns and 24 rows (720 x 264 pixels) needs to be mapped into 800 x 600 pixels.

This might be simpler than I thought, I just checked a monitor, apparently all VGA monitors will sync to a 640 x 480 60Hz signal so I do not have to do the size conversion. If that is correct then all that needs to be done is change the MGA TTL video signal into the RGB analog signal which can be done with just the ADG733.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A fpga is like a box of Lego. You use a language like VHDL or Verilog to describe the logic you want to implement. The manufacturer provides tools to take this and compile it into data (bitstream) that gets loaded into the device. Most are ram based so this happens at power up from a serial memory device or via a micro-controller.

The challenge of manipulating an external video source is the dot clock. Either you need the original dot clock or you need to recover it - usually by using a PLL. Otherwise your dot clock is asynchronous to the source dot clock so your sampling of the pixels is haphazard. This causes some interesting artefacts.
There is probably specific chips that will take the video in and recover the timing for you.
The sam4 would have no trouble generating the sync signals.

There are boards like this:
http://www.amazon.com/Gonbes-GBS8200-Arcade-Converter-Latest/dp/B014MK85VE
That do the conversion magic for you. I use these on my old-skool video game boards.

Last Edited: Thu. Nov 12, 2015 - 09:33 PM