1. Home
  2. Field-Programmable Gate Arrays
  3. Interfacing externally clocked data to an FPGA (Spartan 3)

Interfacing externally clocked data to an FPGA (Spartan 3)

Hi,

First time poster here. I'm using Xilinx's cheap Spartan 3 Starter Kit Board to create a simple VGA "controller" (framebuffer output) that I want to interface to 8051 and Z80 systems I've constructed myself (breadboard projects.)

I'm having serious trouble implementing writes to the on-board SRAM because there appears to be some sort of conflict with the display refresh which causes data to occasionally be misplaced in the frame buffer (several dozen pixels per frame.)

After a couple weeks (!!) of debugging and experimentation (too much stuff to list in this first post), I believe I've narrowed the problem down to one of the following issues:

  1. Writes are supposed to pre-empt reads in my VHDL state machine. Perhaps there is some sort of conflict. If there is, it is not obvious. My state machine is pretty tight and unless the toolchain is synthesizing glitchy logic, there should be no problem.

  1. Data is input from the external CPU (Z80 or 8051) via a simple 5-bit port: 3 bits of color data, an address pointer reset bit, and a clock bit. The Z80 will write a 0 and then a 1 to the clock bit and on the rising edge of this pin, the FPGA is to latch the data and initiate a write. It appears that the transition from low-to-high may be problematic for the FPGA or once a write is complete, the internal signal is not deasserted quickly enough (but this really shouldn't cause any problems -- it would just write over and over again to the same spot.)

I've tried to sync the input pin clock to the FPGA's 50MHz clock (which my state machines run off of) but no luck there.

  1. My 2-cycle write sequence to SRAM might be wrong. But I doubt it because I've verified it against working code and I've synthesized simpler circuits which prove that RAM is being read and written correctly.

I've tried a number of things including adding a pin to disable the display (thus stopping all reads) which the Z80 can control. Even when the display is off and I write to the FPGA, these bad pixels appear. It's not physical noise, that's almost for sure. The pixels are always colored the same as in the image -- in fact, they're often missing from the image and moved somewhere else.

Here's some of the relevant VHDL (I hope the formatting is preserved, I'm using Google Groups):

(Please note how I am clearing the sram_do_write signal -- I think this may be part of the problem but there's no easy way to rectify it.)

process(input) begin if input(4)'event and input(4) = '1' then if input(3) = '1' then -- reset address write_addr

Reply to
Bart
Loading thread data ...

"Bart" schrieb im Newsbeitrag news: snipped-for-privacy@o13g2000cwo.googlegroups.com...

[snip]

generic advice, if in such trouble as you are then it is usually VERY helpful to "look" into the FPGA, so get the ChipScope eval, add the ILA to some of the signals and look whats actually happening.

you can use one DCM to get say 150MHz and use that ILA clock so you would see several samplings per each system clock sample

Antti

Reply to
Antti Lukats

Bart -

Have you checked the quality of the input(4) signal? If it is slow or has noise, glitches, etc the ram write address could get incremented multiple times for each write operation.

Also, you mentioned trying to synchronize the sram_do_write signal to the 50MHz clock - you must do that! Otherwise, you've got an async signal feeding into your state machine - just a matter of time before it screws up.

Hope this helps!

John Providenza

Reply to
johnp

I would suggest to try to get a simplified system to run at first. Use internal SRAM as frame buffer. This will not be enough for full screen, but that does not matter at first, considering the magnitude of your difficultied.

The internal SRAM is dual ported so you can write with one state machine and read with another, using different clocks. If you still see problems, it is very likely that the quality of the input signal is the problem.

If not, you have a problem with synchronization or SRAM access. Try to think of a design change that can separate the two.

Kolja

Reply to
Kolja Sulimma

John and Kolja: The quality of the input signal is something I suspected initially but I ruled out any major interference problems early on. Here's my line of thinking:

- The bad pixels are always the same color as the image data. Corrupted colors do not occur. If I create a white background with a blue box in the center, there will be some white pixels scattered inside the box and blue pixels scattered around outside.

- Each time the input is clocked (by the external Z80), the internal write pointer is incremented. If there were any glitches on this line, the image would be offset and for my test cases (boxes and such), it would be very noticable.

What I initially wanted to do to fix the problem is write some code like this:

if clk_50mhz'event and clk_50mhz = '1' then -- main clock if input_clk_prev = '0' and input_clk = '1' then -- input clock detected. sample the data end if; input_clk_prev signal feeding into your state machine - just a matter of time before

This is probably the issue. Last night, I may have fixed it. What's unusual is that I had tried similar code before to synchronize the signal and it failed to make a difference.

I'll try to show you what I did. I don't have my code with me at the moment so this is going off of memory. Any thoughts on whether this is a sound method? Is it too much of a kludge?

process(input, clk_50mhz) begin if input(4)'event and input(4) = '1' then -- input(4) is input CLK do_write

Reply to
Bart

Bart -

I suspect the problem is that you are supplying no setup/hold time on the sram address bus. Also, no hold time on the data bus: sram_addr

Reply to
johnp

Hi, Your problem is here: if clk_50mhz'event and clk_50mhz = '1' then -- main clock if input_clk_prev = '0' and input_clk = '1' then -- input clock detected. sample the data end if; input_clk_prev

Reply to
wtxwtx

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.