1. Home
  2. Field-Programmable Gate Arrays
  3. Debugging ideas.

Debugging ideas.

Hi all, I am having problems debugging my memory controller. My initial idea is to capture a frame and display the same frame continuously. But I see problems in the pattern captured (some spots with colours that arent expected to be there). When I simulate the controller it works as it is expected. I understand that the timing has to be right and I modified everything so that its alright. The input pattern is a simulated timing generator to generate vga timing (640 x 480 @ 60Hz).

I think that the problem lies with an asynchronous fifo used to buffer data at 25Mhz. The controller can take data from here at 100Mhz and write into memory. Can anyone see a potential problem with this? I use an async fifo for output buffering and there is no problem here. Also can i use 2 clocks in the same module? some 'always' loops operating at

1 clock and the others at another clock?

Can someone think of a test that I do to figure out the problems? I tried using different lenght fifos, with and without fifo and digging into memory location and can do some minor corrections but I am not able to spot any major mistake. Any help is greatly appreciated.

Thanks Subhasri.K

Reply to
Subhasri krishnan
Loading thread data ...

Provide a counter that writes 1,2,3 etc on the transmit side of the memory controller. Write a checker that raises a flag when you get anything out of sequence.

If you have chipscope, then this may give you enough of a trigger that you can 'scope your datapath. If you don't on the other hand, then you probably want to write some datapath sampling code (For instance, that writes data into a blockram, and stops writing when your trigger condition is reached). This assumes that you have a mechanism to get data out of your chip. (Should be obvious, but in your checker, you should make sure the data is qualified correctly when checking :))

Jeremy

Reply to
Jeremy Stringer

I am not understanding what you are saying. See if I am correct:

- You are having trouble with your memory interface (to a framebuffer).

- The memory controller is running at 4x the dot clock (100Mhz)

- There are bad pixels in certain areas?

If so then I would suggest looking at the VHDL code that is responsible for reading in the data and placing it into an internal buffer in the FPGA. The random wrong dots suggest this would be a problem (it could also suggest that you may be pushing the memory too far).

-Isaac

Reply to
Isaac Bosompem

hi, thanks for the quick replies. the dots werenot completely random. they lined up on my screen. how do i test if i am pushing the memory too much? the theoretical max. speed is 166Mhz. I use 100Mhz. I dont think that should be pushing the limit but is it possible it is? thanks

Isaac Bosompem wrote:

Reply to
Subhasri krishnan

Verify that by running static timing at 100MHz.

Consider syncing that interface to 100Mhz and using a synch fifo.

Not without working out synchronization at the boundaries.

-- Mike Treseler

Reply to
Mike Treseler

Reply to
Subhasri krishnan

I suggest an approach where everything runs off the same clock (100 MHz?). The synchronous FIFO then becomes very simple, just a state machine that controls the two BlockRAM ports, one for writing, one for reading. All the mysterious trickery of asynchronous FIFO flag control disappears, since everything happens on common clock edges. In general, using multiple clocks should always be the tool of last resort. Synchronous, single-clock designs are far easier to create and especially to debug. Peter Alfke, Xilinx Appplications.

Reply to
Peter Alfke

Reply to
Subhasri krishnan

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.