| lekernel | hmm... how does one generate and receive 1080p60 video signals? bit clock is 1485MHz, and artix-7 serdes are only 1250MHz (altera is worse) | 15:40 |
|---|---|---|
| lekernel | things like http://www.nxp.com/products/interface_and_connectivity/video_serdes/ seem pretty slow too | 15:40 |
| lekernel | ("3 lanes at 10x serialization rate up to 1.95 Gbit/s" of course, the 1.95 Gbit/s is all three channels combined) | 15:41 |
| lekernel | kintex has 1600MHz serdes but they are super expensive | 15:42 |
| Fallenou | maybe nobody does :) maybe they do 1080i60 or 1080p30 | 15:44 |
| lekernel | according to xrandr my laptop lcd is in 1080p50 | 15:45 |
| larsc | we use a hdmi phy which does serial->parallel | 15:47 |
| lekernel | things like this? http://www.siliconimage.com/products/product.aspx?pid=66 | 15:48 |
| lekernel | The Sil9002 discrete HDMI® PHY transmitter PHY is designed to work exclusively with Silicon Image's transmitter IP that is integrated by MPEG system-on-a-chip (SoC) silicon manufacturers. | 15:48 |
| larsc | lekernel: http://wiki.analog.com/resources/fpga/xilinx/kc705/adv7511 | 15:48 |
| larsc | our image transmitter IP is opensource | 15:50 |
| larsc | but it's just a dumb framebuffer | 15:50 |
| lekernel | ah, thanks! | 15:51 |
| Fallenou | larsc: you work at AD ? | 15:51 |
| lekernel | "The ADV7511 interface consists of a 16bit YCbCr 422" huh | 15:52 |
| lekernel | HDMI is RGB, no? | 15:52 |
| Fallenou | maybe it gets translated into rgb | 15:53 |
| lekernel | anyway, interesting that only adi seems to be making fast serdes ... | 15:53 |
| larsc | Fallenou: yes | 15:54 |
| lekernel | yes you can switch between YCbCr and RGB (ie disable the color space transform of the adi chip) | 15:54 |
| Fallenou | nice :) | 15:54 |
| larsc | lekernel: hdmi is both YCbCr and RGB | 15:54 |
| larsc | the adv7511 supports both YCbCr and RGB in and out | 15:54 |
| larsc | and has a CSC which allows you to convert if neccessary | 15:55 |
| lekernel | larsc: I'd actually love a dumb bidirectional high-speed serdes. just to solve the "slow FPGA I/O" problem. | 15:56 |
| lekernel | even a 1:2 serdes would do the trick | 15:56 |
| lekernel | (and require fewer pcb traces) | 15:57 |
| larsc | the adv7511 is not so dumb, input is only the video stream, but everything of the hdmi protocol is generated on the device | 15:58 |
| lekernel | yes, I see that, even HDCP | 15:59 |
| lekernel | http://avnetexpress.avnet.com/store/em/EMController/Xilinx/XC7K325T-1FBG676CES9919/_/R-5002959400059/A-5002959400059/An-0?action=part&catalogId=500201&langId=-1&storeId=500201&listIndex=-1&page=1&rank=5 | 16:18 |
| lekernel | $119 ?! | 16:18 |
| lekernel | others are $1k-$2k | 16:18 |
| lekernel | there's another one at $137 | 16:19 |
| lekernel | also with CES9919 | 16:19 |
| lekernel | are those 90% dysfunctional chips? :-) | 16:19 |
| larsc | hm: "1-$1,497.000" and "6-$149.7000" somebody put the decimal point at the wrong place? | 16:23 |
| lekernel | all CES9919 chips are much cheaper | 16:25 |
| lekernel | I guess they don't work | 16:25 |
| lekernel | this code isn't even listed on http://www.xilinx.com/support/documentation/7_series_errata.htm | 16:25 |
| larsc | maybe they just list it and hope somebody buys it by accident ;) | 16:29 |
| lekernel | so it seems that options are | 16:31 |
| lekernel | 1) artix-7 and 720p or 1080p30 only | 16:31 |
| lekernel | 2) artix-7 and fat, messy and slightly expensive chips for 1080p60 (which also remove the possibility of bidirectional hdmi ports) | 16:31 |
| lekernel | 3) very expensive kintex-7 | 16:32 |
| lekernel | for sampling you might be able to use two serdes and 180° clocks :) but it's kinda risky | 16:38 |
| lekernel | and for transmitting... maybe with some external buffering/muxing... if I want to play with 1.5GHz discrete logic on a PCB ;) | 16:41 |
| Alarm | git clone git://github.com/fallen/rtems-milkymist.git is dead ? | 19:23 |
| kristianpaul | migrated | 19:24 |
| kristianpaul | upstream | 19:24 |
| Alarm | upstream = ? | 19:34 |
| larsc | merged in the rtems project | 19:35 |
| larsc | rtems.org | 19:35 |
| Alarm | ok | 19:35 |
| lekernel | roh: does bootlab still exist? | 20:19 |
| lekernel | hey Lattice has 3200MHz SERDES | 20:49 |
| lekernel | http://www.latticesemi.com/documents/ds1021ea.pdf | 20:49 |
| lekernel | unless I read it wrong ... | 20:50 |
| Fallenou | hey I have an ECP3 board :) | 20:52 |
| lekernel | do they still sell them for cheap? | 20:54 |
| Fallenou | it was $99 | 20:54 |
| Fallenou | the versa kit | 20:55 |
| Fallenou | dunno if they still sell them | 20:55 |
| lekernel | it's $299 now | 20:55 |
| Fallenou | hum yep price gone up again | 20:56 |
| Fallenou | would you switch to lattice ? :) | 20:56 |
| lekernel | how's the software? I tried it a few years ago and it was much worse than ISE | 20:56 |
| Fallenou | well it's an ISE clone | 20:56 |
| Fallenou | I see almost no difference except the name | 20:57 |
| Fallenou | I had to use windows IIRC to flash the board | 20:57 |
| Fallenou | in a virtualbox it worked fine | 20:58 |
| lekernel | azonenberg: you there? | 20:58 |
| azonenberg | lekernel: yep | 20:58 |
| azonenberg | This is probably a better forum for this discussion than FB :P | 20:58 |
| lekernel | as far I know the S6 transceivers work indeed to 3+GHz, but only with signals that have an embedded clock | 20:59 |
| azonenberg | anyway so have you considered using spartan6 lxt serdes? | 20:59 |
| azonenberg | You're transmitting, right? | 20:59 |
| lekernel | serdes != transceiver | 20:59 |
| azonenberg | or do you need to receive too | 20:59 |
| lekernel | at least in xilinx terminology. now it could be that lattice calls serdes what xilinx calls transceiver | 20:59 |
| azonenberg | whats the difference? I know the GTPs can do clock recovery and the s6 serdes cannot | 21:00 |
| azonenberg | is that it? | 21:00 |
| azonenberg | but "can do" and "must do" arent the same thing | 21:00 |
| lekernel | yes, but can this clock recovery be disabled? | 21:00 |
| lekernel | and use a supplied clock instead? | 21:00 |
| lekernel | AFAIK in S6 the SERDES use an I/O clock generated by PLL+BUFPLL | 21:01 |
| lekernel | and the GTP contain their own PLL, recover clock from the incoming signal, and transfer the data to the fabric/user clock with built-in FIFOs and such | 21:02 |
| azonenberg | hmm, interesting | 21:02 |
| azonenberg | so the gtp is a serdes + clock recovery + other stuff | 21:02 |
| azonenberg | i've never used them | 21:02 |
| lekernel | I think you cannot clock the GTP from anything else than its built-in PLL that locks on the incoming signal, but I might be wrong | 21:03 |
| azonenberg | i looked briefly at IOSERDES | 21:03 |
| lekernel | and yes, the GTPs are big and complex beasts | 21:04 |
| azonenberg | But again, refresh my memory | 21:05 |
| azonenberg | what is the application here, do you need to accept video in? | 21:05 |
| azonenberg | i thought this was only for generating video | 21:05 |
| lekernel | IOSERDES are merely shift registers + layers of flip flops | 21:05 |
| azonenberg | because for *sending* vidoe, the IOSERDES should work fine | 21:06 |
| azonenberg | video* | 21:06 |
| lekernel | not in 1080p60 | 21:06 |
| azonenberg | and at higher speed, the GTPs should be usable | 21:06 |
| lekernel | won't the GTP enforce some encoding that permits clock recovery on the receiving side and is not what should be used for HDMI? | 21:07 |
| azonenberg | Thats what i'm wondering | 21:07 |
| azonenberg | does it mandate IBM 8b10b? | 21:07 |
| azonenberg | like i said i've never actually used the GTPs | 21:07 |
| lekernel | and yes I need to receive video too | 21:07 |
| azonenberg | Well in that case if the gtp requires clock recovery that wont work | 21:07 |
| azonenberg | phase-shifted sampling may or may not, but i'm inclined to say no | 21:08 |
| azonenberg | the limit is not just Fclk, it's setup/hold times too | 21:08 |
| azonenberg | which the incoming phase-shifted data will likely not respect | 21:08 |
| lekernel | ah and yes, Lattice's SERDES are Xilinx's transceivers | 21:08 |
| azonenberg | Can they be used as dumb SERDES? | 21:09 |
| azonenberg | if they run at 3.2 Gbps they're almost certainly CML + 8b10b as used in infiniband, SATA, etc | 21:09 |
| azonenberg | that seems to be turning into an industry standard for gigabit serial | 21:10 |
| azonenberg | HDMI is the lone holdout | 21:10 |
| Action: azonenberg wonders when we'll see a GTP-compatible video standard coming out | 21:10 | |
| lekernel | seems s | 21:10 |
| lekernel | o | 21:10 |
| lekernel | http://www.latticesemi.com/documents/tn1176.pdf | 21:10 |
| lekernel | they have generic SERDES and 8b10b modes | 21:11 |
| azonenberg | interesting | 21:11 |
| lekernel | maybe xilinx transceivers can work this way too... hmm | 21:11 |
| lekernel | but why doesn't the xilinx dvi demo use those? hmm | 21:11 |
| Action: azonenberg pulls UG386 | 21:11 | |
| lekernel | http://www.latticesemi.com/corporate/newscenter/newsletters/newsjanuary2011/ecp3hdmidviinterfacerefer.cfm | 21:12 |
| lekernel | LatticeECP3 FPGA devices to transmit and receive the TMDS signaling used by DVI and HDMI and achieving up to a full 1.65Gbps data rate in the low-cost FPGA. | 21:12 |
| azonenberg | interesting | 21:12 |
| lekernel | so, this is explicitly supported here | 21:12 |
| azonenberg | "The actual width of the port depends on the GTPA1_DUAL tiles INTDATAWIDTH setting (controls the width of the internal datapath), and whether or not the 8B/10B encoder is enabled." | 21:12 |
| lekernel | xilinx however: http://www.xilinx.com/support/documentation/application_notes/xapp495_S6TMDS_Video_Interface.pdf | 21:13 |
| azonenberg | So the s6 GTP should be capable of transmitting TMDS with the GTPs | 21:13 |
| lekernel | only 720p/1080i | 21:13 |
| azonenberg | not sure about receiving | 21:13 |
| azonenberg | and that appnote is supposed to be about using the lowest end chips | 21:14 |
| azonenberg | the LXT are higher end | 21:14 |
| azonenberg | he GTP transceiver includes an 8B/10B decoder to decode RX data without consuming | 21:14 |
| azonenberg | FPGA resources. The decoder includes status signals to indicate errors and incoming | 21:14 |
| azonenberg | control sequences. If decoding is not needed, the block can be disabled to minimize latency. | 21:14 |
| lekernel | lattice says it works for receiving too | 21:14 |
| azonenberg | Hmm | 21:15 |
| azonenberg | Is it possible to do clock recovery on TMDS data? | 21:15 |
| lekernel | what a horrible UI http://www.latticesemi.com/documents/UG36.pdf | 21:15 |
| azonenberg | LOL | 21:16 |
| azonenberg | anyway reading pages 150-160 of UG386 suggests it may be possible to use external clocking on the rx | 21:18 |
| azonenberg | not certain yet | 21:18 |
| larsc | lekernel: I think I've seen that demo at work today | 21:19 |
| larsc | that UI | 21:19 |
| larsc | I think a colleague of mine does HDMI RX with a lattice fpga | 21:20 |
| Fallenou | :) | 21:21 |
| lekernel | larsc: at what speed? | 22:13 |
| roh | lekernel: bootlab exists. but its only a few persons now | 23:00 |
| --- Wed Aug 8 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!