Going insane - Xilinx VGA controller...

Dear Group,

I am designing an LCD controller, straight VGA using a 6.5" TFT (60Hz
and a 25MHz dot clock) with a 32MBit SDRAM frame buffer (using two
Xilinx block RAMs as alternate line buffers).

Xilinx ISE 7.1 development environment.

I also designed the hardware: a BlackFin BF532 CPU/ROM/SDRAM with a
Xilinx Spartan-3 (XC3S400-4PQ208C) handling the general I/F
requirements and VGA display. It is a 4-layer PCB with a 25MHz master
clock.

Until now, all my coding has been with VHDL and everything has
simulated correctly.

Come on now... Just how difficult can it be? Or so I thought.

Well, everything works just fine for about 200ms (correct syncs etc...)
and then things go dead for 800ms -- no syncs, nothing. And then things
spring back to life for another 200ms ad nauseam...

The internal clocks are running fine (I have some spare signals on the
FPGA to which I can bind some debug signals).

Since I am pretty much a newbie to VHDL, I figured I would design a
replacement VGA module using gate-level logic (counters, comparators
and so on)  but it generates exactly the same results.

The power supplies appear to be clean. The BlackFin continues to work
with a command-line UBOOT serial link.

This project has taken 6-weeks longer than it needed to. I look an
idiot (which I probably am) and only the thought of how much pleasure
it would give my mother-in-law stops me from 'doing myself in'...

Any kind or informative suggestions would be very much appreciated.

Regards & seasonal greetings to all.

Peter

There isn't enough info in your post to provide any detailed debugging
opinion, but it looks like you must have misunderstood something in
either the way that the Blackfin or TFT interfaces works as both
your VHDL code and your gate-level code fail in the same way.

You have a repeatable and consistent problem which is much better than
a random failure so you should be able to track down the culprit.

If you included a JTAG port on your PCB that is connected to the 3S400
then I would suggest that you try inserting a ChipScope ILA debug core
into your design.  This will give you the ability to probe and trigger
on the internal buses to see where the failure is.  If you don't already
have a license for this you can get a 60-day full feature eval at
http://www.xilinx.com/chipscope that should be plenty of time to find
and correct your problem.

Ed

peter.halford@alarmip.com wrote:
> Dear Group,
> 
> I am designing an LCD controller, straight VGA using a 6.5" TFT (60Hz
> and a 25MHz dot clock) with a 32MBit SDRAM frame buffer (using two
> Xilinx block RAMs as alternate line buffers).
> 
> Xilinx ISE 7.1 development environment.
> 
> I also designed the hardware: a BlackFin BF532 CPU/ROM/SDRAM with a
> Xilinx Spartan-3 (XC3S400-4PQ208C) handling the general I/F
> requirements and VGA display. It is a 4-layer PCB with a 25MHz master
> clock.
> 
> Until now, all my coding has been with VHDL and everything has
> simulated correctly.
> 
> Come on now... Just how difficult can it be? Or so I thought.
> 
> Well, everything works just fine for about 200ms (correct syncs etc...)
> and then things go dead for 800ms -- no syncs, nothing. And then things
> spring back to life for another 200ms ad nauseam...
> 
> The internal clocks are running fine (I have some spare signals on the
> FPGA to which I can bind some debug signals).
> 
> Since I am pretty much a newbie to VHDL, I figured I would design a
> replacement VGA module using gate-level logic (counters, comparators
> and so on)  but it generates exactly the same results.
> 
> The power supplies appear to be clean. The BlackFin continues to work
> with a command-line UBOOT serial link.
> 
> This project has taken 6-weeks longer than it needed to. I look an
> idiot (which I probably am) and only the thought of how much pleasure
> it would give my mother-in-law stops me from 'doing myself in'...
> 
> Any kind or informative suggestions would be very much appreciated.
> 
> Regards & seasonal greetings to all.
> 
> Peter
> 

> Come on now... Just how difficult can it be? Or so I thought.
>
> Well, everything works just fine for about 200ms (correct syncs etc...)
> and then things go dead for 800ms -- no syncs, nothing. And then things
> spring back to life for another 200ms ad nauseam...
>
> The internal clocks are running fine (I have some spare signals on the
> FPGA to which I can bind some debug signals).
>

? Frame Store address generation - if you fail to reset a frame store 
pointer you will walk through memory and probably through hyperspace ...

> Any kind or informative suggestions would be very much appreciated.

Open a bottle or two and chill out - let your subconscious work on it !


>
> Regards & seasonal greetings to all.
> 

Bottle is already open...

Living in Greece, can I suggest how nice: CAIR sparkling-wine is. It is
methode-Champagnoise (meaning it is made in the same way as the
sparkling wine from the Champagne region of France), but at a fraction
of the cost. Actually, it is made in Rhodes (a rather large Island here
in Greece).

However, all I can think is that somehow the BlackFin is resetting the
array. Unfortunately, I didn't write any of the code nor UBOOT, so I
guess tomorrow (they're very small legs and too much CAIR) I will look
at all of the FPGA control signals...

Please keep the suggestions coming (apart that is from YOU,
mother-in-law).

Peter

peter.halford@alarmip.com wrote:
> Dear Group,
> 
> I am designing an LCD controller, straight VGA using a 6.5" TFT (60Hz
> and a 25MHz dot clock) with a 32MBit SDRAM frame buffer (using two
> Xilinx block RAMs as alternate line buffers).
> 
> Xilinx ISE 7.1 development environment.
> 
> I also designed the hardware: a BlackFin BF532 CPU/ROM/SDRAM with a
> Xilinx Spartan-3 (XC3S400-4PQ208C) handling the general I/F
> requirements and VGA display. It is a 4-layer PCB with a 25MHz master
> clock.
> 
> Until now, all my coding has been with VHDL and everything has
> simulated correctly.
> 
> Come on now... Just how difficult can it be? Or so I thought.
> 
> Well, everything works just fine for about 200ms (correct syncs etc...)
> and then things go dead for 800ms -- no syncs, nothing. And then things
> spring back to life for another 200ms ad nauseam...
> 
> The internal clocks are running fine (I have some spare signals on the
> FPGA to which I can bind some debug signals).
> 
> Since I am pretty much a newbie to VHDL, I figured I would design a
> replacement VGA module using gate-level logic (counters, comparators
> and so on)  but it generates exactly the same results.
> 
> The power supplies appear to be clean. The BlackFin continues to work
> with a command-line UBOOT serial link.
> 
> This project has taken 6-weeks longer than it needed to. I look an
> idiot (which I probably am) and only the thought of how much pleasure
> it would give my mother-in-law stops me from 'doing myself in'...
> 
> Any kind or informative suggestions would be very much appreciated.
> 
> Regards & seasonal greetings to all.

  As you seem to have a behaving system some of the time, lock onto 
that, and expand on what you DO know - viz: try and be get better values 
for the 200ms and 800ms - things like how many frames, exactly; and is 
it a precise 1 second repeat. and how dead is dead.. Syncs gone, or 
changed, ? (etc)
  Are the syncs precisely correct ? - it's not something like the 
montior just not quite being able to hold-onto things ?

  That's many, many frames, so sounds unlike a gate level issue.

  Then look around at what it is in the system that changes at precisely 
those times....

  -jg

peter.halford@alarmip.com wrote:
> Dear Group,
> 
> I am designing an LCD controller, straight VGA using a 6.5" TFT (60Hz
> and a 25MHz dot clock) with a 32MBit SDRAM frame buffer (using two
> Xilinx block RAMs as alternate line buffers).

Is the SDRAM connected directly on the SP3 ? Could you provide a little
more on how things are connected, dataflow, ...

> Come on now... Just how difficult can it be? Or so I thought.
> 
> Well, everything works just fine for about 200ms (correct syncs etc...)
> and then things go dead for 800ms -- no syncs, nothing. And then things
> spring back to life for another 200ms ad nauseam...

What in your design can make the sync not happen ?

For examples, what if pixel are not fetched in time ? would that stop
sync ? For e.g., I know in the last VGA controller I made, nothing
excepted reset or a unlocked DCM could make the sync go away ... But
that's dependent on how you do things, you should know your design to
know what condition can make it stop produce sync.


Sylvain

<peter.halford@alarmip.com> wrote in message
news:1135270697.315589.100480@g44g2000cwa.googlegroups.com...
> Dear Group,
>
> I am designing an LCD controller, straight VGA using a 6.5" TFT (60Hz
> and a 25MHz dot clock) with a 32MBit SDRAM frame buffer (using two
> Xilinx block RAMs as alternate line buffers).

I'm not so sure about LCDs, but one thing I found surprising with
a VGA display was that the HSYNC and VSYNC were not sufficient
to keep the display active... I needed to drive the blanking controls
as well. (You might think that it just wouldn't blank, but it appears
as if the SYNC signals are ignored if blanking is not active.)

Probably not your problem, but if you're at a complete loss for
something to look at, you might give it a try.

Good luck. Let us know what it turns out to be.

> However, all I can think is that somehow the BlackFin is resetting the
> array. Unfortunately, I didn't write any of the code nor UBOOT, so I
> guess tomorrow (they're very small legs and too much CAIR) I will look
> at all of the FPGA control signals...

Could there be some sort of COP (watchdog) circuit which
resets things periodically (because it does not get some service it
expects, that is)?

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Dear All,

Many thanks for all your suggestions...

I have tried dividing my incoming 25MHz clock by 2 and voilla!
everything works, albeit 50% slower...

So now I guess I will have to divide the incoming clock by 2, multiply
it and re-divide it.

Any ideas why this could be happening?

Regards to all,
Peter

peter halford wrote:


>I have tried dividing my incoming 25MHz clock by 2 and voilla!
>everything works, albeit 50% slower...
>
>So now I guess I will have to divide the incoming clock by 2, multiply
>it and re-divide it.
>
>Any ideas why this could be happening?

If you can run the clock at a slower speed and everything works, then
you might have one of several problems.  My first suspection would be:
There is a logic path longer than the normal time between clocks.

I assume you have a period constrant.  Yes?

Do you have all FFs in the IOBs?  And/or checking setup time on all
inputs?

Do you have any asynchronous sets or resets?


-- 
Phil Hays