Logxen

HDMI Wings

25 posts in this topic

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!

Share this post


Link to post
Share on other sites

Sweeeet! Can't wait to try these puppies out, thank you for putting these together.

 

Jack.

Share this post


Link to post
Share on other sites

these HDMI wings are very interesting.

 

on question, are they going to be working both ways, as input or output, HDMI-wise?

 

are they supposed to be for sale sometime?

Share this post


Link to post
Share on other sites

Yes, they should work for both input and output. Logxen is making up prototypes for Alvie and I to test out, once they are verified Logxen will manufacture a batch of them and we will sell them in the store.

 

Jack.

Share this post


Link to post
Share on other sites

Ok, here's the first prototypes:

 

Hdmi%20sata%20wings-sm.jpg

 

I've got a set like this going out to Jack and Alvie for testing. :)

1 person likes this

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

Alvie, you rock! (We should form a little mutual admiration society   :D )

 

Are you using the SERDES or DDR to drive that? If you need a SERDES one to keep the clock speeds down then let me know.

Share this post


Link to post
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

Share this post


Link to post
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...

1 person likes this

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
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. :)

Share this post


Link to post
Share on other sites

I can't wait till we have these available. :) Going to be really cool.

 

Jack.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Could someone please upload the source files for these wings? Or are there any plans to sell them anytime soon? :)

Share this post


Link to post
Share on other sites

Logxen just made an updated version of the HDMI wing and just mailed them out to Alvie and I for testing, initial results look good. Once we can get them verified we will put them up in the store.

 

Jack.

Share this post


Link to post
Share on other sites

Oh, it looks like we might have some prototypes available for people willing to help out with testing. If you are able to be available on Skype whenever Alvie or I have some new bit files for testing please let us know.

 

Thanks,
Jack.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

Jack,

have time to do some testing but not sure of timing to be on Skype. Please let me know how I can help.

Bob

Share this post


Link to post
Share on other sites

Are you guys sure the HDMI wing will work for input?  I don't see the 50 ohm pullup resistors to 3.3V on the LVDS data lines.

 

Magnus

 

post-36465-0-45886400-1390672847_thumb.p

Share this post


Link to post
Share on other sites

That is a good point.

 

I wonder if we can enable the resistors on the relevant inputs, like 100+100 UNTUNED_SPLIT_50. Once I get one of these wings I'll run some tests. But yes. I was not aware of that requirement (and Logxen either).

 

Alvie

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now