HDMI Wings


Logxen

Recommended Posts

I've got some protos for a simple HDMI Wing for Papilio Pro on order and I'm cleaning up the design for an HDMI+CEC Wing. HDMI requires 4 differential pairs but luckily the Papilio Pro layout is set up very well for differential applications. It will be able to support up to two simple HDMI Wings attached to Wing C and up to two HDMI+CEC Wings attached to Wings A and B. This will allow prototyping with up to 4 HDMI ports on the same board! \o/ Here are some pcb renders of the HDMI Wings:

 

HDMICECWing-Proto1.png  HDMIWing-Proto1.png

 

 

I also went and looked through the differential mapping on the Papilio One... by a stroke of luck the HDMI+CEC Wing should be compatible with Wing AL+BH, so even the Spartan-3 can have some HDMI love!

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

I'm happy to inform that not only the wing works, but also we have now a basic 640x480@60Hz output with that HDMI using ZPUino 2.0, and we can inclusive display an image loaded from SmallFS.

 

I'll post some pictures later. A huge thanks to Hamster for his DVID examples!

 

Good work Logxen!

Link to comment
Share on other sites

:) hey Hamster!

 

Still using the DDR, SERDES will come next if needed.

 

Since the memory BW is not much, I guess 720p is the best I can aim for. Let's see if ODDR2 can handle that. The other issue will be the FIFO... it's easy when all clocks are in phase as in this design (CPU 100Mhz, Pixel clock 25Mhz, bitclock 125Mhz). For 720p things get a bit more complicated....

 

The main issue is CPU<->Pixel clock, as you know. They should be tightly related, even when using advanced FIFO techniques.

 

I'll let you know progress, and, of course, the design which uses your dvid.vhd and tmds_encoder.vhd. The toplevel is from ZCoreV3, which already had all VGA timings and memory DMA for framebuffer.

 

Alvie

Link to comment
Share on other sites

hamster: indeed this does not meet timing for 720p (74.25MHz pix clock). Some issues are in my FIFO (although it does not care about timings - it will work with even almost-zero setup), but the serializer is not happy....

 Slack (setup path):     -0.280ns (requirement - (data path - clock path skew + uncertainty))    Source:               hdmi_inst/mydvid/latched_green_3 (FF)    Destination:          hdmi_inst/mydvid/shift_green_3 (FF)    Requirement:          2.693ns    Data Path Delay:      1.800ns (Levels of Logic = 1)    Clock Path Skew:      -0.670ns (1.513 - 2.183)    Source Clock:         hdmi_clk_pix rising at 0.000ns    Destination Clock:    hdmi_clk_p rising at 2.693ns    Clock Uncertainty:    0.503ns      Clock Uncertainty:          0.503ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE      Total System Jitter (TSJ):  0.070ns      Discrete Jitter (DJ):       0.558ns      Phase Error (PE):           0.222ns    Maximum Data Path at Slow Process Corner: hdmi_inst/mydvid/latched_green_3 to hdmi_inst/mydvid/shift_green_3      Location             Delay type         Delay(ns)  Physical Resource                                                         Logical Resource(s)      -------------------------------------------------  -------------------      SLICE_X20Y60.CQ      Tcko                  0.525   hdmi_inst/mydvid/latched_green<4>                                                         hdmi_inst/mydvid/latched_green_3      SLICE_X18Y58.B4      net (fanout=1)        0.926   hdmi_inst/mydvid/latched_green<3>      SLICE_X18Y58.CLK     Tas                   0.349   hdmi_inst/mydvid/shift_red_4_BRB1                                                         hdmi_inst/mydvid/Mmux_GND_243_o_latched_green[9]_mux_6_OUT41                                                         hdmi_inst/mydvid/shift_green_3      -------------------------------------------------  ---------------------------      Total                                      1.800ns (0.874ns logic, 0.926ns route)                                                         (48.6% logic, 51.4% route)   

Clock skew looks very high. Same for jitter. I wonder if this can be improved...

Note: I haven't tried to plug the HDMI from this one yet... might work, might not...

Link to comment
Share on other sites

  • 2 months later...

Impressed! I don't know if you agree, but I am just amazed that FPGAs allow us to squirt over 2Gb/s (for 720p) down cables.

 

Having this on a wing so multiple channels can be driven is pretty neat - All I need now is a really good reason to transfer large amounts of data between boards.

 

Maybe a graphics subsystem on one board, being controlled from another!

Link to comment
Share on other sites

  If you just want to communicate between two fpga in a generic manner I would suggest the sata wings. Sata is 2 differential pairs which works out perfect for one send lane and one receive lane. Additionally sata cables are much cheaper than hdmi cables and many of us even have extras lying around at this point.

 

  Fyi, the simple hdmi wing is 4 differential pairs.

 

  I've oft thought the set could use a quad sma wing to be complete but I don't know that there is any interest. :)

Link to comment
Share on other sites

  • 1 month later...

Alvie is close with an HDMI controller and I started playing around with a VGA to HDMI symbol for the Papilio Schematic Library. Maybe we will see some more movement with this in the next couple of weeks. Once we get some kind of working solution Logxen can make a batch of these boards.

 

Jack.

Link to comment
Share on other sites

  • 4 weeks later...

Well, I don't own a Papilio (yet), but ordered a Pipistrello with which I wanted to try some on-the-fly image enhancement algorithms and CEC commanding. Maybe - if I find the time - even some pattern recognition, which certainly will require larger areas of FPGA logic and RAM. In both cases I will post my experiences in this forum :) .

So I would need at least one HDMI input wing for the Pipistrello. If an extra compilation for the lx45 isn't the problem, I would be happy to help with testing!

Link to comment
Share on other sites

  • 4 months later...

Alvie, I assume that you are using the Serialisers in for the HDMI output? If not, I've got a fully working 720p (75MHz pixel clock) that is working and is using them.

 

The good thing is that this needs only a 2x clock (150MHz) in the fabric rather than 5x clock needed if using DDR registers. This makes meeting timing a lot easier.

 

I'll try to get my wiki updated sometime soon. The biggest differences from the XAPP495 design is that I don't use a BRAM based FIFO between the encoders and serialisers, but a LUT based one, freeing up one more BRAM block for other uses.

 

Till then, if you want the code just drop me an email.

Link to comment
Share on other sites

Hey Mike,

 

I tried using the serializers for 720p, but I had not much time to test them.

 

My main issue right now is that I lose sync a lot if I don't use the video guard bands - but if I use them, they show up on display. I still have to figure out why this happens, perhaps I really need to send out an AVI infoframe.

 

Regarding your code, I'd like to take a look if you don't mind. There are a few thinks I don't master yet in the serializers.

Link to comment
Share on other sites

Project OSERDES2 project is up on my Wiki. http://hamsterworks.co.nz/mediawiki/index.php/DVI-D_Serdes

 

You can run the input side at any sensible speed greater than the pixel frequency as long as you don't underflow/overflow the FIFO. (e.g. if the FIFO is not full you could grab a memory burst of pixels from SDRAM @ 100MHz. expand them to 24 bits and then send the to the FIFO).

 

You could even make the FIFO have different input and output widths, allowing multiple pixels to be pushed into the FIFO each cycle - great if the memory interface is x16 and you are using 8-bit pixels.

 

Cheers

 

Mike

Link to comment
Share on other sites

Archived

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