Spartan® Family FPGAs

[abhishekkar]

Hello everyone,

We are working with the spartan 6 FPGA board for our senior design. We are running in to problems with displaying any sort of image through the HDMI ports. Since the board is relatively new, the reference materials on the board is pretty scarce.

We are trying to use the xps_tft controller to get the raw data from the DDR2 memory (image files) and display it to HDMI out port (J2).

The problem is the output of the xps_tft controller is in DVI and the output we require is HDMI. Mapping the ports from the xps_tft contoller to the HDMI pins on the board is confusing.

The demo programs for the board do not use the xps_tft controller but uses a custom DVI (pattern generator)  ip core.

A reference xps_tft program that works on the atlys would be greatly appreciated.

please help

Thanks

[eteam00]

We are running in to problems with displaying any sort of image through the HDMI ports.  We are trying to use the xps_tft controller to get the raw data from the DDR2 memory (image files) and display it to HDMI out port (J2).  The problem is the output of the xps_tft controller is in DVI and the output we require is HDMI. Mapping the ports from the xps_tft contoller to the HDMI pins on the board is confusing.

The only significant differences between DVI and HDMI, for your purposes, are as follows:

• Connector - easily solved with DVI-D to HDMI adapters, which are readily available.
• "ANC" data - mostly audio - is supported in the blanking intervals in HDMI signaling.

Do you have a running 'reference design' which outputs HDMI?  If so, then make small changes from this reference design, one at a time, until you arrive at the signal format you desire.  By making small changes, one at a time, you can focus your debugging attention on the few changes which were made since the last successful iteration.  If you make broad sweeping changes and the resulting design doesn't work, this will lead to frustration and wasted effort.

Do you know with certainty that the image files you are using conform to the display capabilities of the monitor(s) you are using?  Read the HDMI 1.3 specification (it is available for free download) for which image formats are REQUIRED by all (conforming) HDMI monitors ("sinks").  You should be choosing one of those required formats for your initial design.

- Bob Elkind

[abhishekkar]

Hello again,

Here is the status of what we have done so far so that our efforst dont seem inadequate to you:

1. We HAVE read the manual over and over again

2. We have read the XPS_TFT manual over and over again

3. The The global UCF files only contain constraints for HDMI which is set to have 6 data bits along with clock positive and negative and SCL, SDA.

4. When the xps_tft ip core is added to the design the ports only incorporate the DVI constraints on its own and adds 11 data bits, clock, SDA,SCL, Vsync and Hsync. So the data bits in the ip core does not really map with the ones we are provided with in the UCF file.

IN UCF FILE:

# onboard HDMI OUT

 NET "HDMIOUTCLKP" LOC = "B6"; # Bank = 0, Pin name = IO_L8P,  Sch name = TMDS-TX-CLK_P

 NET "HDMIOUTCLKN" LOC = "A6"; # Bank = 0, Pin name = IO_L8N_VREF,  Sch name = TMDS-TX-CLK_N

 NET "HDMIOUTD0P"  LOC = "D8"; # Bank = 0, Pin name = IO_L11P,  Sch name = TMDS-TX-0_P

 NET "HDMIOUTD0N"  LOC = "C8"; # Bank = 0, Pin name = IO_L11N,  Sch name = TMDS-TX-0_N

 NET "HDMIOUTD1P"  LOC = "C7"; # Bank = 0, Pin name = IO_L10P,  Sch name = TMDS-TX-1_P

 NET "HDMIOUTD1N"  LOC = "A7"; # Bank = 0, Pin name = IO_L10N,  Sch name = TMDS-TX-1_N

 NET "HDMIOUTD2P"  LOC = "B8"; # Bank = 0, Pin name = IO_L33P,  Sch name = TMDS-TX-2_P

 NET "HDMIOUTD2N"  LOC = "A8"; # Bank = 0, Pin name = IO_L33N,  Sch name = TMDS-TX-2_N

 NET "HDMIOUTSCL"  LOC = "D9"; # Bank = 0, Pin name = IO_L34P_GCLK19, Sch name = TMDS-TX-SCL

 NET "HDMIOUTSDA"  LOC = "C9"; # Bank = 0, Pin name = IO_L34N_GCLK18, Sch name = TMDS-TX-SDA

I've also added a screen capture of the ports along with this message.

5. The reference program that xilinx provided used a completely different ip core which seemed hardware specific somehow. It was called 'DVI_pattern_generator'. There was no sign of xps_tft anywhere. And we cant get to any such source or files that would allow us to change any variable information. Like you said, our first idea was definately to try and modify the values so as to generate any random pattern of color bars on the screen. but ths is easier said than done as it seems to be hard coaded .

6. finally, i guess our main concern now is to successfully map the ports in the ip core (xps_tft) to the ports provided to us in the UCF file.

7. PS. the monitor works fine

I hope that explained our dilemma much clearer than before.

Any response would be greatly appreciated..

thanks

[eteam00]

3. The The global UCF files only contain constraints for HDMI which is set to have 6 data bits along with clock positive and negative and SCL, SDA.

You should have 4 TMDS_33 pairs, including a pair for the clock.  Your .UCF snippet reflects this.  The signals are exactly the same for both DVI-D and HDMI, including the I2C interface (SCL/SDA), both electrically and for timing and coding.

When the xps_tft ip core is added to the design the ports only incorporate the DVI constraints on its own and adds 11 data bits, clock, SDA,SCL, Vsync and Hsync. So the data bits in the ip core does not really map with the ones we are provided with in the UCF file.

I have not used the xps_tft ip core.  I know that it is used for the Xilinx video development boards, which use the Chrontel CH7301C DVI/HDMI encoder.  If you are generating output for the Chrontel device, the signals are completely different from native DVI/HDMI interface.

Is the Atlys board schematic available for download?

I think you should be looking at the XAPP495 reference design for low-level formatting, and perhaps skip the xps_tft core entirely.  A link to the reference design is in the XAPP495 .PDF document (page 14), and XAPP495 references the Atlys board as the hardware platform used for verification of the XAPP495 code.  There is no direct link to the reference design code, as this is 'protected' by Xilinx user password and auth.

Hope this helps...

- Bob Elkind

[joelby]

The Atlys schematic states that it's a TMDS141RHAR. The Atlys built-in self test application just uses the XAPP495 reference files (dvi_out_native_testpattern_0), though with a different test pattern generator (not written in Verilog/VHDL). XAPP495 includes a hdclrbar.v test pattern generator and UCF files for the Atlys.

[eteam00]

Joelby, you sound quite knowledgeable on the subject of the Atlys board.

Any clue whether the xps_tft ip core is used in the Atlys reference design?  I suspect not, but I have no personal knowledge on the matter.  Since the OP is having trouble with this core on the Atlys board, it would be a big help to him to know that he doesn't need it.

- Bob Elkind

[joelby]

Hi Bob,

That's a good question, actually! The Atlys manual says, "EDK designs can use the xps_tft IP core (and its associated driver) to access the HDMI ports. The xps_tft core reads video data from the DDR2 memory, and sends it to the HDMI port for display on an external monitor." As far as I can tell, the two EDK reference designs don't actually use xps_tft but rather something based on XAPP495.

I'm pretty sure that xps_tft could not be made to work. There's certainly no CH7301C video encoder present. The IP core and chip both use a 12-bit DVI signal bus, while the TMDS141 on the Atlys seems to just be a buffer for the four differential pairs and SCL/SCA.

I have a suspicion that the manual is just plain wrong. I'll wager that the paragraph has been erroneously copied from the Digilent Genesys manual (this board does have the CH7301C). It's even been updated in a suspicious manner - the Atlys manual says that the IP core supports 1080P, but Xilinx states that it's only good for 640x480. The Genesys manual doesn't make such lofty claims.

It might be worth asking Digilent to confirm all of this and update the manual if necessary.

In the meantime, I'd stick to XAPP495!

(edit: I've emailed Digilent and will report back on what they say)

[eteam00]

(edit: I've emailed Digilent and will report back on what they say)

You da man!  You've done your good deed for the day!

- Bob Elkind

[abhishekkar]

Hey Joelby,

you are indeed very informative on the board.  The documentation from Xilinx by far is horrendous and this

is not the first time we have faced this. We had the same issues while working with the Virtex II pro board.

We did try following the xapp 495 test program. It wasnt an XPS program. So we tried to implement it through the ISE editor. The issue here is that the test program involves receiving an HD signal from a source and transmit it to the HDMI out port. We do not want to use an external HD source, instead we want to read the images from the DDR2 memory. When we tried to modify the vhdl/verilog codes and remove all the receive  related code, it barked back with various forms of errors. we are still trying to modify it but we are failing. A little clarification would really help..

thanks 

[joelby]

I haven't had much to do with XPS, but you should be able to use the video output IP core provided in the Digilent reference implementation. It is basically the XAPP495 design, converted into an XPS-friendly core (if such a thing makes sense).

You will just need to supply the part that reads from RAM and converts the image to the correct signals. The XAPP495 test pattern implementation should give some clues as to the inputs you will need if the application note wasn't explicit (I haven't read it closely).

If you can tell us what the errors that ISE was giving you were, we may be able to help with those.