Papilio Pro + Logic Wing VGA Pins


austinmags

Recommended Posts

I was running through the FPGA tutorial by Hamster; hit a hard stop on the VGA chapter. I'm essentially trying to generate a 640x480 60Hz signal which displays a red screen. The monitor consistently reports no signal; I've verified the cable and monitor work independently of the board.

 

My clock appears to be correct; I've used a variety of test configurations to validate I have a 25MHz clock.

 

I'm now measuring signals directly out of the VGA connector on the Logic Wing; the VSYNC signal has been verified, but HSYNC is not produced on the expected VGA connector pin (13) given the Papilio Pro constraints. (I'm measuring using a voltmeter - get 3.3 volts when measuring vsync, 0 when measuring hsync).

 

I'm wondering if either I have a defective test, board, or incorrect constraints for the Papilio Pro / Logic Wing. Any help / guidance would be much appreciated of how to proceed.

 

My diagnostic code:

entity VgaDiscoverer isPort (clk : in std_logic;vga_vsync : out std_logic;vga_hsync : out std_logic;switches : in std_logic_vector(7 downto 0));end VgaDiscoverer;architecture Behavioral of VgaDiscoverer isbeginprocess(clk)beginvga_vsync <= switches(0);vga_hsync <= switches(1);end process;end Behavioral;
 

 

My constraints:

NET CLK LOC="P94" | IOSTANDARD=LVTTL | PERIOD=31.25ns;NET switches(0) LOC = "P114" | IOSTANDARD=LVTTL;NET switches(1) LOC = "P115" | IOSTANDARD=LVTTL;NET switches(2) LOC = "P116" | IOSTANDARD=LVTTL;NET switches(3) LOC = "P117" | IOSTANDARD=LVTTL;NET switches(4) LOC = "P118" | IOSTANDARD=LVTTL;NET switches(5) LOC = "P119" | IOSTANDARD=LVTTL;NET switches(6) LOC = "P120" | IOSTANDARD=LVTTL;NET switches(7) LOC = "P121" | IOSTANDARD=LVTTL;NET vga_vsync LOC="P99" | DRIVE = 2;NET vga_hysnc LOC="P97" | DRIVE = 2;
Link to comment
Share on other sites

Here is my constraints (for the Papilio One)

NET "clk" LOC = "P89" | IOSTANDARD = LVCMOS25 | PERIOD = 31.25ns ;NET Blue(1)     LOC="P78"  | IOSTANDARD=LVTTL; NET Blue(2)     LOC="P71"  | IOSTANDARD=LVTTL; NET Green(0)    LOC="P68"  | IOSTANDARD=LVTTL; NET Green(1)    LOC="P66"  | IOSTANDARD=LVTTL;NET Green(2)    LOC="P63"  | IOSTANDARD=LVTTL;NET Red(0)      LOC="P61" | IOSTANDARD=LVTTL;NET Red(1)      LOC="P58" | IOSTANDARD=LVTTL;NET Red(2)      LOC="P54" | IOSTANDARD=LVTTL;NET vSync       LOC="P85" | IOSTANDARD=LVTTL;NET hSync       LOC="P83" | IOSTANDARD=LVTTL;

Are you missing your constraint for your clock signal? Many I time I have forgotten to add one....

 

Have a look at the pinout report (under the design summary window) - I've sometime seen ISE completely ignore UCF files, and you have to remove it from the project and re-add it.

 

If you are still stuck you can send me the source in an email... 

 

Mike

Link to comment
Share on other sites

Hi, thanks Mike for the offer. I've sent a compressed version of my project over to you.

Also, after fighting with the online editor, I managed to get an updated and correct version of my diagnostic test.

Real puzzler. Hoping one day to generate an actual VGA signal somewhere...

Link to comment
Share on other sites

OK, on Mike's suggestion, I've looked more carefully at the design report. I see the problem:

-> HSYNC (vga_hsync) is not being assigned pin 97 -- but some other random pin 140. Interesting.

I've removed and re-added my constraints file. With no change.

Is 97 not valid for the Papilio Pro and specifically for VGA HSYNC on the Logic Wing?

Link to comment
Share on other sites

Look very carefully at "vga_hysnc" in your constraints file - say the letters one by one!

 

I couldn't resist - as I am dyslexic!

 

You must have the setting that allows this to work turned on. Normally unmatched constraints are an error and cause a fatal  error.

Link to comment
Share on other sites

More information. My design properties are:

* Family: Spartan6

* Device: XC6SLX9

* Package: TQG144

* Speed: -3

97 is obviously a valid IO pin on that chip. Google is not being very precise with its suggestions when I search for reasons why a constrained pin may be assigned to a different one.

Feel like this is a dumb user mistake on my part -- but it's elusive.

Link to comment
Share on other sites

It's really easy to do, I've been on the verge of tearing my hair out multiple times trying to debug issues like that. Another favorite is doing a bunch of manipulation on a variable, then inadvertently assigning it some hardcoded value and wondering why the math I'm using isn't working.

Link to comment
Share on other sites

My 'favorite' error is having a clock constraint with the timing info but not giving it a "LOC" attribute - everything simulates perfectly but nothing works as the clock is assigned to a random pin.

 

No matter how much you simulate it will never work :-)

Link to comment
Share on other sites

Do you guys not use a template? Do you always type out a new .ucf every single time? I always start with the same .ucf template that has every single pin fully defined but commented out (except the clock, since I always need a clock). Then I just uncomment the pins I need. No typos, no fuss.

 

The only time there is potential for error is when creating a .ucf for the first time for a new board.

Link to comment
Share on other sites

The lesson I took away from this experience is simply not to use the aul option. I don't remember where I learned to use it, but it was allowing me to avoid a slight annoyance with the risk of something much more annoying and harder to diagnose.

Also, I'm training myself to read the design report each time (well at least scanning certain parts of it)... imagine that!

Next, I need to develop a habit of actually doing a simulation instead of loading up the board and using hard signals to verify and debug it.

Link to comment
Share on other sites

The simulator is pretty awesome. It has helped me countless times debug tricky situations and I highly recommend it. The only problem with it is that debugging complex systems like for example arcade games it can take a very long time to simulate the system if your bug only appears 2 seconds or more after power on. Oh and the software is very prone to crashing for no good reason.

Link to comment
Share on other sites

  • 6 months later...

Sorry to resurrect this thread after so long, but it felt like the most appropriate place to ask this:

 

In Hamster's book, the UCF looks like this (it says it's for the Papilio One, but it looks like it's actually for the Basys 2):

NET "HSYNC" LOC = "J14" | DRIVE = 2;NET "VSYNC" LOC = "K13" | DRIVE = 2;NET "Red<2>" LOC = "F12" | DRIVE = 2;NET "Red<1>" LOC = "D13" | DRIVE = 2;NET "Red<0>" LOC = "C14" | DRIVE = 2;NET "Green<2>" LOC = "G14" | DRIVE = 2;NET "Green<1>" LOC = "G13" | DRIVE = 2;NET "Green<0>" LOC = "F14" | DRIVE = 2;NET "Blue<2>" LOC = "J13" | DRIVE = 2;NET "Blue<1>" LOC = "H13" | DRIVE = 2;

But Hamster's email from above (for the Papilio One), shows this:

NET Blue(1)     LOC="P78"  | IOSTANDARD=LVTTL;NET Blue(2)     LOC="P71"  | IOSTANDARD=LVTTL;NET Green(0)    LOC="P68"  | IOSTANDARD=LVTTL;NET Green(1)    LOC="P66"  | IOSTANDARD=LVTTL;NET Green(2)    LOC="P63"  | IOSTANDARD=LVTTL;NET Red(0)      LOC="P61" | IOSTANDARD=LVTTL;NET Red(1)      LOC="P58" | IOSTANDARD=LVTTL;NET Red(2)      LOC="P54" | IOSTANDARD=LVTTL;NET vSync       LOC="P85" | IOSTANDARD=LVTTL;NET hSync       LOC="P83" | IOSTANDARD=LVTTL;

I'm wondering about the change from using DRIVE=2 to using IOSTANDARD=LVTTL.

 

I see on github that the vga chapter was last updated Dec 2012, so Hamster's email is more recent. 

 

I've looked at the Xilinx datasheet for what "DRIVE" does, and I see it's a directive for current limiting. That certainly sounds like a great thing to do when interfacing with a monitor. Should I be using DRIVE? I also saw in the datasheet that it seems to imply that maybe you can use both (but maybe I read it wrong).  So should I perhaps be doing, for example:

NET vSync       LOC="P85" | IOSTANDARD=LVTTL | DRIVE=2;

Can anyone clarify before I go hooking this thing up to my monitor?

 

Thanks!

-Alan

Link to comment
Share on other sites

For most uses, drive doesn't matter. It is how much "shove" the I/O pin will deliver (i.e. perhaps how many output transistors will be switched on). It is more about signal integrity than current limiting.

 

For long traces or when a trace has lots of connections then higher drive may be required. Apparently too much drive on short traces can cause issues due to EMI and excessive signal bounce.

Link to comment
Share on other sites

Just to chime in here.

 

A lot of the projects floating around came from other places, or had bits and pieces borrowed from other projects. It's common to see variations in things like the drive level because as hamster says, it doesn't really matter for this application. Some developers chose to use one setting, some chose something else, some copied whatever was in the source they were copying from. You'll probably notice some variation in overall brightness/gamma by changing the drive strength of the RGB signals but unless it's side by side or over a long cable run you probably won't notice. CRT monitors are more likely to be affected due to the wider dynamic range they offer.

Link to comment
Share on other sites

If i get a chance I might do a little project tonight and check out the short-circuit current through a pin at different drive strengths. I'm pretty sure they will all be the same regardless of setting.

 

My (poor) understanding is that drive strength is an indication of the current that can be sourced/sunk and still keep the voltage within spec while also keeping the switching time in spe.

 

It is done this way because using too much drive on all pins can cause excessive noise and cause the IO voltage rails to sag. Have a look at the Simultaneously Switching Output numbers in ds099-3.pdf - at 12ma you are only supposed to switch one "FAST" pin per VCCo/Gnd pair, but at 2mA slow you can switch 16 pins (for the VQ100 package).

 

It is quite likely that at high resolutions a higher drive will make a VGA output a little sharper. However, it is also equally likely that the more abrupt transistion could cause reflections and ghosting, like when you use poor quality VGA extension cables (as the resistor DAC may not be perfectly matched to the cable impedence)... maybe that too is worthy of an experiment or two!

Link to comment
Share on other sites

Did some testing using a Spartan3E-250 (not perfect - my meter's fuse is blown :) ).

 

Into 82.5 ohm, a  pin with IOSTANDARD of LVTTL  and drive of 2mA will source 13mA

 

Into 82.5 ohm, a pin with IOSTANDARD of LVTTL  and drive of 8mA will source 28.7mA

 

Into 82.5 ohm, a pin with IOSTANDARD of LVTTL  and drive of 12mA will source 29.8mA

 

 

For 2mA setting, short circuit to ground seems to source about 15 mA, for the 12mA setting it seems to be about 50 or 60 mA.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.