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

Reply to
peter.halford
Loading thread data ...

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

formatting link
that should be plenty of time to find and correct your problem.

Ed

snipped-for-privacy@alarmip.com wrote:

Reply to
Ed McGettigan

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

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

Reply to
Dave

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

Reply to
peter.halford

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

Reply to
Jim Granville

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

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

Reply to
Sylvain Munaut

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.

Reply to
bh

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

formatting link

------------------------------------------------------

Reply to
dp

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

Reply to
peter.halford

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
Reply to
Phil Hays

Dear Group,

I know how annoying it is when one posts blocks of HDL, but I would really appreciate someone telling me why this code does not work -- or at least, a pointer to my stupidity!!!

This HDL is supposed to generate standard -ve syncs plus an early 'newline' signal to a specialised SDRAM controller which writes a complete line of octets into alternate block-RAMs in my Spartan-3 device.

It then attempts to display them by generating alternate read enables (based on the current vertical line).

Tomorrow I am going to rewrite the code using discrete processes (one for each sync signal etc...).

library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_unsigned.all; use IEEE.numeric_std.all;

entity VidCont is generic( DATA_WIDTH : natural := 16; -- video data width VADDR_WIDTH : natural := 10 -- Video FIFO (blockRAM) address width ); port( -- Interface clk : in std_logic; -- Master clock @25MHz rst : in std_logic; -- Reset -- Video blockRAM side VIAddr : out std_logic_vector(VADDR_WIDTH-1 downto 0);

-- Video line buffer address VADIn : in std_logic_vector(DATA_WIDTH-1 downto 0);

-- Data from 'A' block RAM VEnA : out std_logic; -- Enable 'A' FIFO VBDIn : in std_logic_vector(DATA_WIDTH-1 downto 0);

-- Data from 'B' block RAM VEnB : out std_logic; -- Enable 'B' FIFO NewLine : out std_logic; -- Initiate line read burst -- TFT interface VRed : out std_logic_vector(5 downto 0); -- 6-bit red VGreen : out std_logic_vector(5 downto 0); -- 6-bit green VBlue : out std_logic_Vector(5 downto 0); -- 6-bit blue VDE : out std_logic; -- Data-enable VVSync : out std_logic; -- Vertical synch. VHSync : out std_logic; -- Horizontal synch. -- Debug signal... Debug : out std_logic ); end VidCont;

architecture arch of VidCont is

constant YES : std_logic := '1'; constant NO : std_logic := '0'; constant HI : std_logic := '1'; constant LO : std_logic := '0'; constant ONE : std_logic := '1'; constant ZERO : std_logic := '0';

-- TFT timing parameters... constant tHP : natural := 800; -- Horizontal sync. period constant tWH : natural := 96; -- Horizontal sync. width constant tVP : natural := 525; -- Vertical sync. period constant tWV : natural := 2; -- Vertical sync. width constant tHV : natural := 640; -- Active horizontal period constant tHBP : natural := tWH+40; -- End of H back porch (start of active area) constant tHFP : natural := tHBP+tHV; -- Start of H front porch (end of active area) constant tVV : natural := 480; -- Active vertical period constant tVBP : natural := tWV+33; -- End of V back porch (start of active area) constant tVFP : natural := tVBP+tVV; -- Start of V front porch (end of active area)

-- Horizontal & vertical counters... signal hCount_x, hCount_r : natural range 0 to tHP+1; -- Horizontal column count signal vCount_x, vCount_r : natural range 0 to tVP+1; -- Address counters... signal hAddr_x, hAddr_r : std_logic_vector(VIAddr'range); -- Horizontal address -- Data enable flags... signal hDEm3_x, hDEm3_r : std_logic; -- Early (-3) horizontal data enable signal hDEm2_r : std_logic; -- Early (-2) latched horizontal data enable signal hDEm1_r : std_logic; -- Early (-1) latched horizontal data enable signal hDE_r : std_logic; -- Horizontal data enable signal vDEm2_x, vDEm2_r : std_logic; -- Early (-2) vertical data enable signal vDEm1_r : std_logic; -- Early (-1) vertical data enable signal vDE_r : std_logic; -- Vertical data enable signal nlBurst_x, nlBurst_r : std_logic; -- Newline burst strobe signal IVEnA_x, IVEnA_r : std_logic; -- Block RAM 'A' read enable signal IVEnB_x, IVEnB_r : std_logic; -- Block RAM 'B' read enable -- Syncs... signal IVSync_x, IVSync_r : std_logic; -- Vertical sync signal IHSync_x, IHSync_r : std_logic; -- Horizontal sync signal AltLine_x, AltLine_r : std_logic; -- Source flipper -- RGB data... signal RGB_x, RGB_r : std_logic_vector(VADIn'range); -- Demultiplexed and latched RGB data

begin

-- Attach signals to outputs... VIAddr

Reply to
peter.halford

Hi Peter, It would appear from your VHDL code that you're sending sync signals out of your entity that are generated from combinational logic. I would suggest that this is BAD. Look at this line:-

IHSync_x

Reply to
Symon

Doesn't completely fit the symptoms, but is it possible there are reflections on the clock input? What you are doing is not only dividing the clock, but providing a clean clock from WITHIN the FPGA. Of course, you also could have an extremely slow path in the design somewhere, but that would have to be a huge amount of combinatorial logic or maybe some very slow external path like a RAM, to make it work at 12.5 MHz but fail at 25.

Jon

Reply to
Jon Elson

Dear Symon,

Today I rewrote the entire module using procedural code and now everything is working perfectly!!!

It is odd how the code would work for a bit and then stop for another bit...

Anyhow, this is how one learns to make things work...

Many thanks to you and to all who offered help.

Regards, Peter

PS. It is p-ing down here in torrents!!! Corfu is the greenest island in Greece for a very good reason!!!

Reply to
peter.halford

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.