1 00:00:00,000 --> 00:00:14,309 *33C3 preroll music* 2 00:00:14,309 --> 00:00:17,380 Herald-Angel: Tim ‘mithro’ Ansell has come all the way from Australia 3 00:00:17,380 --> 00:00:24,510 to talk to us about ‘Dissecting HDMI’ and developing an open FPGA-based 4 00:00:24,510 --> 00:00:29,930 capture hardware for sharing talks outside of the room. 5 00:00:29,930 --> 00:00:34,680 And he will be explaining how to dissect it. And I’m looking forward 6 00:00:34,680 --> 00:00:38,620 to hearing the talk in a second. And so please give Tim 7 00:00:38,620 --> 00:00:41,330 a warm round of applause again. Thank you! 8 00:00:41,330 --> 00:00:50,520 *applause* 9 00:00:50,520 --> 00:00:56,149 Tim Ansell: Okay, hi, I’m Tim, and in theory, if my slides change 10 00:00:56,149 --> 00:01:02,550 you would see that. 11 00:01:02,550 --> 00:01:08,540 And I kind of have too many projects. And I’m gonna be discussing one of them. 12 00:01:08,540 --> 00:01:11,890 This is another project that I gave a lightning talk on earlier. 13 00:01:11,890 --> 00:01:18,720 If you didn’t see it, it’s an ARM microcontroller that goes in your USB port. 14 00:01:18,720 --> 00:01:22,000 People wanted to know when to hack on it. 15 00:01:22,000 --> 00:01:25,520 Tomorrow at 2 PM, apparently. 16 00:01:25,520 --> 00:01:28,990 So, the first that I want to say is I’m a software developer. 17 00:01:28,990 --> 00:01:33,340 I’m not a hardware designer, I’m not an FPGA developer, 18 00:01:33,340 --> 00:01:37,150 I’m not a professional in any of that. 19 00:01:37,150 --> 00:01:42,920 I develop software for full time. So this is my hobby. 20 00:01:42,920 --> 00:01:50,029 As well, this information comes from a couple of projects that I started 21 00:01:50,029 --> 00:01:55,260 but a lot of other people did the majority of the work and I’m just telling you 22 00:01:55,260 --> 00:02:00,180 about it because they are too shy to come up and talk about it themselves. 23 00:02:00,180 --> 00:02:05,430 So a big thank you to all these people who have helped me in various ways 24 00:02:05,430 --> 00:02:09,788 regarding this. And theses slides – 25 00:02:09,788 --> 00:02:13,700 any of the blue things are links, so if your playing it along at home 26 00:02:13,700 --> 00:02:18,840 you can get to them by that URL and click on these things. 27 00:02:18,840 --> 00:02:21,700 And there is probably other people I’ve forgotten, who are not on this list. 28 00:02:21,700 --> 00:02:24,530 I’m very sorry. 29 00:02:24,530 --> 00:02:31,980 So this title of this talk could be called “Software guy tries hardware and complains”. 30 00:02:31,980 --> 00:02:36,640 I’ve had a really hard time figuring out what to call this talk. 31 00:02:36,640 --> 00:02:41,210 And you’ll see some other attempts of naming this talk better. 32 00:02:41,210 --> 00:02:48,379 So a bit of history. How do I end up doing HDMI stuff? 33 00:02:48,379 --> 00:02:55,840 So TimVideos is a group of projects which are trying to make it easy 34 00:02:55,840 --> 00:03:02,780 to record and live-stream user groups and conferences like this event. 35 00:03:02,780 --> 00:03:07,400 However, we want to do it without needing the awesome team 36 00:03:07,400 --> 00:03:09,750 that is doing the recording here. 37 00:03:09,750 --> 00:03:12,950 These guys are really, really organized and professional. 38 00:03:12,950 --> 00:03:18,710 We want to do it where people have no experience at all with AV, 39 00:03:18,710 --> 00:03:22,110 and just can make it happen. 40 00:03:22,110 --> 00:03:28,930 And so this is how you record a conference or user group. 41 00:03:28,930 --> 00:03:31,750 I’m gonna be talking about these two things here, 42 00:03:31,750 --> 00:03:35,519 the HDMI2USB devices that we created. 43 00:03:35,519 --> 00:03:43,239 They are used in our setup both for camera capture and for capture of slides. 44 00:03:43,239 --> 00:03:48,680 And so HDMI2USB is FOSS hardware for doing HDMI capture 45 00:03:48,680 --> 00:03:54,880 and actually has a bit of history with the CCC 46 00:03:54,880 --> 00:04:00,700 because it was inspired by a speaker who spoke here. 47 00:04:00,700 --> 00:04:06,139 Bunnie spoke on his NeTV board 48 00:04:06,139 --> 00:04:08,830 which was an FPGA Man-in-the-Middle attack 49 00:04:08,830 --> 00:04:14,239 on HDCP-secured links. His talk is really awesome. It’s gonna be… 50 00:04:14,239 --> 00:04:17,488 that talk is way more technical than mine and gives you 51 00:04:17,488 --> 00:04:22,460 some really awesome details about the cool things he did to make that work. 52 00:04:22,460 --> 00:04:26,990 Mine is much more basic. You don’t need much experience with HDMI 53 00:04:26,990 --> 00:04:32,969 to follow my talk. Our device works like his does, 54 00:04:32,969 --> 00:04:38,740 except his was deliberately designed to not allow capture, 55 00:04:38,740 --> 00:04:41,669 our design allows capture. It effectively man-in-the-middles 56 00:04:41,669 --> 00:04:46,949 the presenters projector, between the presenters laptop 57 00:04:46,949 --> 00:04:54,859 and the projector, and provides a high-quality capture out the USB2 port. 58 00:04:54,859 --> 00:04:58,680 I use an FPGA to do that. This is because 59 00:04:58,680 --> 00:05:03,169 using FPGA makes hardware problems software problems, and as I said 60 00:05:03,169 --> 00:05:09,110 I’m a software developer, I prefer software problems to hardware problems. 61 00:05:09,110 --> 00:05:13,689 And the way it kind of works is it appears as a UVC webcam so that 62 00:05:13,689 --> 00:05:17,589 you can use it with Skype or Hangouts or any of those things without needing 63 00:05:17,589 --> 00:05:23,650 any drivers on sensible operating systems like MacOS and Linux. 64 00:05:23,650 --> 00:05:27,620 On Windows you need a driver that tells it to use the internal driver. 65 00:05:27,620 --> 00:05:30,309 It’s kind of weird. And also a serial port 66 00:05:30,309 --> 00:05:34,529 because we have the ability to switch which input goes to which output. 67 00:05:34,529 --> 00:05:38,610 It’s kind of like a matrix. 68 00:05:38,610 --> 00:05:42,690 And so this the open source hardware we designed. 69 00:05:42,690 --> 00:05:49,159 It’s in KiCAD, you can find it on Github. 70 00:05:49,159 --> 00:05:52,320 I’m quite proud of it. It’s quite a good little kit. 71 00:05:52,320 --> 00:05:58,049 We don’t use all the features of it yet, but it’s pretty awesome. 72 00:05:58,049 --> 00:06:00,520 And it’s in use! 73 00:06:00,520 --> 00:06:05,740 We used this technology to capture at a bunch of conferences: 74 00:06:05,740 --> 00:06:09,309 PyCon in Australia, linux.conf.au in Australia 75 00:06:09,309 --> 00:06:11,840 – as I said, I’m Australian. 76 00:06:11,840 --> 00:06:15,059 DebConf, though, are not Australian. 77 00:06:15,059 --> 00:06:22,789 They used it in – sorry – in South Africa, I think. 78 00:06:22,789 --> 00:06:24,969 And there are a whole bunch of other people around the world 79 00:06:24,969 --> 00:06:27,639 who are using this, which is pretty awesome. 80 00:06:27,639 --> 00:06:31,139 The main reason I wanted it to be open source was so that 81 00:06:31,139 --> 00:06:37,229 other people could use them and learn from them and fix problems, 82 00:06:37,229 --> 00:06:41,730 because there are a lot of problems we’ve run into. 83 00:06:41,730 --> 00:06:44,590 And the other thing is this is all full of Python. 84 00:06:44,590 --> 00:06:49,979 We do use Python 85 00:06:49,979 --> 00:06:54,500 to create the firmware for the FPGA, and all these other areas. 86 00:06:54,500 --> 00:06:58,399 If you wanna find out more about that go to my talk at Python AU 87 00:06:58,399 --> 00:07:02,679 which was recorded with the very device I’m talking about. 88 00:07:02,679 --> 00:07:05,419 *microphone noise* Oops, sorry! 89 00:07:05,419 --> 00:07:11,759 But as I said, this is going to include a lot of problems. 90 00:07:11,759 --> 00:07:15,789 The first one is: People still use VGA! 91 00:07:15,789 --> 00:07:19,429 This kind of makes me sad. 92 00:07:19,429 --> 00:07:23,849 Because VGA is not HDMI. It was invented in 1987 93 00:07:23,849 --> 00:07:25,960 and it’s an analog signal. 94 00:07:25,960 --> 00:07:29,709 Well, HDMI shares some history with VGA. 95 00:07:29,709 --> 00:07:34,669 You can’t use the same techniques for capturing HDMI that you can for VGA. 96 00:07:34,669 --> 00:07:40,729 So why do you still use it? It’s old and bad! 97 00:07:40,729 --> 00:07:46,279 We developed a VGA expansion board to effectively allow us to capture 98 00:07:46,279 --> 00:07:49,009 VGA using the same thing. 99 00:07:49,009 --> 00:07:52,699 By ‘developed’ I mean we have designed, and some exist 100 00:07:52,699 --> 00:07:55,849 but nobody’s actually finished the firmware to make them work yet. 101 00:07:55,849 --> 00:07:59,530 So, I’d love help there. 102 00:07:59,530 --> 00:08:03,889 There is also another problem: 103 00:08:03,889 --> 00:08:08,050 I want to do this all open source, as I said. 104 00:08:08,050 --> 00:08:12,189 The HDMI ecosystem has commercial cores you can buy 105 00:08:12,189 --> 00:08:16,089 and they work reasonably well, but you have to buy them 106 00:08:16,089 --> 00:08:19,550 and you don’t get the source code to them or if you do get the source code to them 107 00:08:19,550 --> 00:08:23,349 you can’t share them with other people. 108 00:08:23,349 --> 00:08:27,389 As well, I wanted to be open source because we wanted to solve 109 00:08:27,389 --> 00:08:31,479 all those problems that people have when plugging in their laptop 110 00:08:31,479 --> 00:08:34,320 and it not working. 111 00:08:34,320 --> 00:08:38,969 And the commercial cores aren’t designed to allow us to give the ability 112 00:08:38,969 --> 00:08:46,550 to do that – solve those problems permanently. 113 00:08:46,550 --> 00:08:48,500 So we create a new implementation! 114 00:08:48,500 --> 00:08:52,129 As anybody who has ever done a reimplementation or a new implementation 115 00:08:52,129 --> 00:08:59,430 or something, it means that you got new bugs which I all describe quite a bit. 116 00:08:59,430 --> 00:09:01,350 So this talk could be called 117 00:09:01,350 --> 00:09:06,399 ‘Debugging HDMI’ rather than ‘Dissecting HDMI’ because it includes 118 00:09:06,399 --> 00:09:11,590 a lot of information about how things went wrong. 119 00:09:11,590 --> 00:09:16,560 Ok, that’s kind of the introduction of why we are here and why I’m talking about this. 120 00:09:16,560 --> 00:09:22,540 So how does HDMI work? 121 00:09:22,540 --> 00:09:26,480 Well, HDMI is actually reasonably old now. 122 00:09:26,480 --> 00:09:30,700 It was created in 2002. 123 00:09:30,700 --> 00:09:37,290 It’s based on the DVI specification. DVI was created in 1999. 124 00:09:37,290 --> 00:09:41,279 So DVI is 17 years old. 125 00:09:41,279 --> 00:09:49,070 And DVI was designed to replace VGA and shares a lot of similar history. 126 00:09:49,070 --> 00:09:55,980 HDMI is backwards compatible with DVI electrically and protocol wise, 127 00:09:55,980 --> 00:09:58,529 but uses a different connector. 128 00:09:58,529 --> 00:10:02,750 This is a HDMI connector. You’ve probably seen them all before. 129 00:10:02,750 --> 00:10:10,220 If you look closely you see that there are 19 pins on the HDMI connector. 130 00:10:10,220 --> 00:10:13,300 That’s Pin 1. 131 00:10:13,300 --> 00:10:15,350 So what do all this pins do? 132 00:10:15,350 --> 00:10:18,470 There are five pins which are used for Ground. 133 00:10:18,470 --> 00:10:24,829 There is one pin which is used for Power, it gives you 5 volts at 50 milliamps. 134 00:10:24,829 --> 00:10:28,410 This isn’t much. You can’t do much with 50 milliamps 135 00:10:28,410 --> 00:10:35,779 except maybe some type of adapter, converter or power a whole microcontroller. 136 00:10:35,779 --> 00:10:39,290 Some Chinese devices try to draw like an amp from this. 137 00:10:39,290 --> 00:10:45,370 That’s not very good. So that’s another thing you should watch out for. 138 00:10:45,370 --> 00:10:51,519 There are three high speed data pairs which transmit the actual video data. 139 00:10:51,519 --> 00:10:57,730 And they share a clock pair. So that’s these pins here. 140 00:10:57,730 --> 00:11:02,369 And then there are five pins which are used for low speed data. 141 00:11:02,369 --> 00:11:06,740 So that’s all the pins on the HDMI connector. 142 00:11:06,740 --> 00:11:12,740 You might have noticed that there was a whole bunch of different things 143 00:11:12,740 --> 00:11:16,629 I said there. And you need to actually understand a whole bunch 144 00:11:16,629 --> 00:11:21,510 of different protocols to understand how HDMI works. 145 00:11:21,510 --> 00:11:27,710 There is bunch of low speed ones and there is a bunch of high speed ones. 146 00:11:27,710 --> 00:11:31,910 I’m not gonna talk about all of those protocols 147 00:11:31,910 --> 00:11:35,810 because there is just too many to go into an hour talk. 148 00:11:35,810 --> 00:11:38,390 The low speed protocol I’m not gonna talk about is 149 00:11:38,390 --> 00:11:42,339 CEC or Audio Return; and I’m not gonna talk about any of the 150 00:11:42,339 --> 00:11:48,010 Auxiliary Data protocol that is high speed, or HDCP. 151 00:11:48,010 --> 00:11:50,860 If you want HDCP go and look at bunnie’s talk. 152 00:11:50,860 --> 00:11:56,320 It’s much better than mine. But… or ethernet! 153 00:11:56,320 --> 00:12:02,460 What I will be talking about is the EDID and DDC protocols, 154 00:12:02,460 --> 00:12:06,290 The 8b/10b encoding of the pixel data 155 00:12:06,290 --> 00:12:10,140 and the 2b/10b encoding of the control data. 156 00:12:10,140 --> 00:12:14,010 Interesting enough this is actually DVI. 157 00:12:14,010 --> 00:12:20,740 I’m not telling you about HDMI, I’m really describing to you how DVI works. 158 00:12:20,740 --> 00:12:26,190 Again, many titles. 159 00:12:26,190 --> 00:12:29,690 Starting with the low speed protocol: 160 00:12:29,690 --> 00:12:33,009 EDID or DDC. 161 00:12:33,009 --> 00:12:37,789 I’m gonna use these two terms interchangeably, 162 00:12:37,789 --> 00:12:40,639 they’ve been so confused now that they are interchangeable, 163 00:12:40,639 --> 00:12:43,600 in my opinion. 164 00:12:43,600 --> 00:12:47,480 This is something they inherited from VGA. 165 00:12:47,480 --> 00:12:52,929 It was invented and added to VGA in August 1994. 166 00:12:52,929 --> 00:12:56,579 It was for plug and play of monitors so that you could plug in your monitor 167 00:12:56,579 --> 00:13:02,430 and your graphics card would just work rather than requiring you to tell 168 00:13:02,430 --> 00:13:08,050 your graphics card exactly what resolution and stuff your monitor worked at. 169 00:13:08,050 --> 00:13:12,879 It uses I2C [I squared C] and a small EEPROM. 170 00:13:12,879 --> 00:13:16,290 These are the pins that it uses. 171 00:13:16,290 --> 00:13:22,620 15 is the Clock pin and 16 is the Data pin, 172 00:13:22,620 --> 00:13:28,100 and then it uses the Ground, and the 5 Volts is used to power that EEPROM. 173 00:13:28,100 --> 00:13:32,790 And in some ways it also uses the 19 because 19 is how you detect 174 00:13:32,790 --> 00:13:37,640 that there is something there to read from. 175 00:13:37,640 --> 00:13:40,569 It uses I2C. 176 00:13:40,569 --> 00:13:46,190 I2C is a low speed protocol that runs at either 100 kHz or 400 kHz. 177 00:13:46,190 --> 00:13:50,860 Technically EDID is not I2C, but it is. 178 00:13:50,860 --> 00:13:55,850 It only supports the 100 kHz version, though, in theory, 179 00:13:55,850 --> 00:13:58,780 everything on this planet can be read at 400 kHz. 180 00:13:58,780 --> 00:14:03,029 It is also very well explained elsewhere, so I’m not going to explain in detail 181 00:14:03,029 --> 00:14:09,089 what I2C is or does, or how to implement it. 182 00:14:09,089 --> 00:14:16,470 The EEPROM is a 24 series. It’s found at I2C address 50. 183 00:14:16,470 --> 00:14:21,680 It’s 8 bits in size which gives you 256 bytes of data. 184 00:14:21,680 --> 00:14:28,240 Again, this EEPROM and how to talk to it is very well described on internet. 185 00:14:28,240 --> 00:14:31,310 So I’m not gonna to describe it here. If you’ve used EEPROMs 186 00:14:31,310 --> 00:14:36,430 over I2C it’s likely you’ve used a 24 series EEPROM. 187 00:14:36,430 --> 00:14:42,790 Probably bigger ones, 256 bytes is pretty small. 188 00:14:42,790 --> 00:14:45,930 So like a 16 bits one, 189 00:14:45,930 --> 00:14:51,899 but EDID supports only the 8 bits ones. 190 00:14:51,899 --> 00:14:55,020 The kind of interesting part of EDID is the data structure: 191 00:14:55,020 --> 00:14:58,649 it’s a custom binary format that describes 192 00:14:58,649 --> 00:15:02,040 what the contents of the EEPROM is. 193 00:15:02,040 --> 00:15:05,410 Again, Wikipedia has a really good description of this. 194 00:15:05,410 --> 00:15:07,860 So I’m not gonna go into much detail. 195 00:15:07,860 --> 00:15:12,951 But the important thing is that it describes resolution, frequency 196 00:15:12,951 --> 00:15:17,589 and format for talking to the monitor. 197 00:15:17,589 --> 00:15:20,720 This is really important because if you try and send 198 00:15:20,720 --> 00:15:25,470 the wrong resolution, frequency or format the monitor is not gonna understand it. 199 00:15:25,470 --> 00:15:28,579 This is kind of what EDID is used for. 200 00:15:28,579 --> 00:15:32,009 *sipping, sound of water bottle* 201 00:15:32,009 --> 00:15:38,269 So this is where things start getting a bit hairy. 202 00:15:38,269 --> 00:15:42,519 Presenters come up to the front and the first question you see anybody ask is: 203 00:15:42,519 --> 00:15:44,600 What resolution do I use? 204 00:15:44,600 --> 00:15:49,919 And they get a panel like this which has a bazillion of resolutions selected. 205 00:15:49,919 --> 00:15:55,379 And the thing is, despite your monitor saying that it supports 206 00:15:55,379 --> 00:15:59,920 many formats they lie. 207 00:15:59,920 --> 00:16:05,279 It turns out that projectors lie a lot more than normal displays. 208 00:16:05,279 --> 00:16:08,490 I don’t know why they are special. 209 00:16:08,490 --> 00:16:11,560 So this is what a supported format looks like. 210 00:16:11,560 --> 00:16:14,769 It’s really great. 211 00:16:14,769 --> 00:16:19,240 As well, I care about capturing the data. 212 00:16:19,240 --> 00:16:25,420 And so I want the things in the format that is 213 00:16:25,420 --> 00:16:27,229 easy for me to capture. 214 00:16:27,229 --> 00:16:31,600 I also don’t to be scaling peoples images and text 215 00:16:31,600 --> 00:16:34,509 because scaling looks really bad. So if someone selects 216 00:16:34,509 --> 00:16:39,889 like a really low resolution and we scale it up it looks really horrible. 217 00:16:39,889 --> 00:16:44,300 It makes text unreadable; and presenters are very denounced, 218 00:16:44,300 --> 00:16:47,980 especially at technical conferences, for using tiny, tiny fonts. 219 00:16:47,980 --> 00:16:51,720 And so we need to use as much resolution as we can. 220 00:16:51,720 --> 00:16:55,649 How we solve this is we emulate our own EEPROM in the FPGA 221 00:16:55,649 --> 00:16:58,680 and ignore what the projector tells us it can do. 222 00:16:58,680 --> 00:17:03,009 We tell the presenter that this is what we support. 223 00:17:03,009 --> 00:17:06,689 You might notice that it kind of solves the problem 224 00:17:06,689 --> 00:17:10,510 of what resolution we do. 225 00:17:10,510 --> 00:17:11,809 Offer a single solution… 226 00:17:11,809 --> 00:17:16,499 offer a single option makes it very hard to choose the wrong one. 227 00:17:16,499 --> 00:17:19,839 That’s good! We solved the problem! 228 00:17:19,839 --> 00:17:22,780 No, we haven’t solved the problem. 229 00:17:22,780 --> 00:17:25,390 We were recording PyCon AU and we found that 230 00:17:25,390 --> 00:17:31,120 some Mac laptops were refusing to work. 231 00:17:31,120 --> 00:17:34,570 To understand the cause of this you need to understand 232 00:17:34,570 --> 00:17:36,970 a little bit about how the world works. 233 00:17:36,970 --> 00:17:41,120 There are two major frequencies in the world: 50 Hz and 60 Hz. 234 00:17:41,120 --> 00:17:43,799 50 Hz is mainly used in the “Rest of the World” 235 00:17:43,799 --> 00:17:47,370 and 60 Hz is used in America and Japan and a few other places 236 00:17:47,370 --> 00:17:51,869 but that’s kind of a very rough thing. 237 00:17:51,869 --> 00:17:54,559 Laptop sold in Australia, Australia is 50 Hz. 238 00:17:54,559 --> 00:17:57,980 It’s part of the “Rest of the World”. You’d think the that the laptop 239 00:17:57,980 --> 00:18:02,270 could do 50 Hz. Plus everything is global these days, right? 240 00:18:02,270 --> 00:18:07,950 I can plug in my power pack for my laptop in the US or Australia, 241 00:18:07,950 --> 00:18:11,750 like, it should work everywhere right! 242 00:18:11,750 --> 00:18:15,200 No. Sad! 243 00:18:15,200 --> 00:18:19,940 We solved it by claiming that we were American 244 00:18:19,940 --> 00:18:24,770 and supporting 60 frames per second rather than 50 frames per second. 245 00:18:24,770 --> 00:18:28,400 So I guess a display with an American accent. 246 00:18:28,400 --> 00:18:32,700 We deployed this hotfix on the Friday evening. 247 00:18:32,700 --> 00:18:37,279 And on Saturday all the problems that we were having on Friday 248 00:18:37,279 --> 00:18:41,840 went away. So this is kind of the power of a open source solution 249 00:18:41,840 --> 00:18:45,980 and having complete control over your hardware. 250 00:18:45,980 --> 00:18:49,820 Nowadays we actually offer both 60 and 50 251 00:18:49,820 --> 00:18:53,600 because for display capture if you’re displaying stuff 252 00:18:53,600 --> 00:19:00,370 at 50 frames per second you’re probably speaking a lot faster than I am. 253 00:19:00,370 --> 00:19:05,650 It’s really weird, these 128 bytes are really hard 254 00:19:05,650 --> 00:19:11,510 and the number one cause of why a persons laptop 255 00:19:11,510 --> 00:19:14,880 can’t talk to the projector. 256 00:19:14,880 --> 00:19:18,240 It gets a trophy! 257 00:19:18,240 --> 00:19:23,809 To try and figure out why that is we created EDID.tv. 258 00:19:23,809 --> 00:19:27,090 It’s supposed to be a repository of EDID data. 259 00:19:27,090 --> 00:19:30,880 There is a Summer of Code project, Python/Django/Bootstrap 260 00:19:30,880 --> 00:19:34,270 and an EDID grabber tool that you can run on your laptop. 261 00:19:34,270 --> 00:19:37,070 I’d love help making this work better. 262 00:19:37,070 --> 00:19:41,700 Hasn’t had much love since the Summer of Code student made that work. 263 00:19:41,700 --> 00:19:45,940 But it would be really nice to have an open database of everybody’s EDID data 264 00:19:45,940 --> 00:19:51,250 out there. There are a bunch of closed ones. I can pay to buy one, 265 00:19:51,250 --> 00:19:55,630 but I’d really love to have an open one. 266 00:19:55,630 --> 00:19:59,750 As well maybe we don’t need the whole capture solution, 267 00:19:59,750 --> 00:20:02,690 maybe you can just override the EDID. 268 00:20:02,690 --> 00:20:08,700 The C3VOC here actually developed a version that overrides EDID for VGA. 269 00:20:08,700 --> 00:20:12,390 I have a design which works for HDMI. 270 00:20:12,390 --> 00:20:20,130 It just uses a low cost microprocessor to pretend to be an EEPROM. 271 00:20:20,130 --> 00:20:22,890 As well, DisplayPort is not HDMI. Don’t get these two confused, 272 00:20:22,890 --> 00:20:25,650 they are very, very different protocols. 273 00:20:25,650 --> 00:20:29,650 They have an Auxiliary Channel like EDID and CEC. 274 00:20:29,650 --> 00:20:34,090 I have boards to decode them here at CCC. 275 00:20:34,090 --> 00:20:37,140 So if you’re interested in that come and talk to me 276 00:20:37,140 --> 00:20:43,010 because we would really like to do similar things for DisplayPort. 277 00:20:43,010 --> 00:20:46,700 That is the slow speed data. 278 00:20:46,700 --> 00:20:49,929 *Sip from bottle* 279 00:20:49,929 --> 00:20:53,100 What about the high speed data? 280 00:20:53,100 --> 00:20:57,500 Each pixel on your screen is 281 00:20:57,500 --> 00:21:04,269 basically three colors in DVI standard: Red, Green, Blue. 282 00:21:04,269 --> 00:21:07,530 And each one is a byte in size. 283 00:21:07,530 --> 00:21:15,540 Each of the colors is mapped to a channel on the HDMI connector. 284 00:21:15,540 --> 00:21:20,429 You can kind of see the Red and the Green and the Blue channels. 285 00:21:20,429 --> 00:21:23,130 Each channel is differential pair. 286 00:21:23,130 --> 00:21:27,420 You get a Plus and a Negative and a Shield. 287 00:21:27,420 --> 00:21:35,460 And they use twisted pair to try and reduce the noise reception of these, 288 00:21:35,460 --> 00:21:38,760 because these are quite high speed. 289 00:21:38,760 --> 00:21:41,860 And they have a dedicated Shield to try and – again – reduce the noise 290 00:21:41,860 --> 00:21:47,090 that is captured. 291 00:21:47,090 --> 00:21:53,139 This is kind of where it gets to the ‘differential signaling’ part 292 00:21:53,139 --> 00:21:57,990 of the ‘TMDS’ that is the kind of code name 293 00:21:57,990 --> 00:22:05,220 for the internal protocol that is used on the high speed data. 294 00:22:05,220 --> 00:22:10,159 They also… all these channels share a Clock. 295 00:22:10,159 --> 00:22:13,830 That clock is called the Pixel Clock. 296 00:22:13,830 --> 00:22:17,169 But each of these channels is a serial channel. 297 00:22:17,169 --> 00:22:22,929 It transmits data at 10 bits. 298 00:22:22,929 --> 00:22:25,659 They… every 10 bits – sorry, 299 00:22:25,659 --> 00:22:31,620 every clock cycle there are 10 bits of data transmitted on each of these channels. 300 00:22:31,620 --> 00:22:34,950 There is a shared clock and each of the channels is running 301 00:22:34,950 --> 00:22:39,340 at effectively ten times that shared clock. 302 00:22:39,340 --> 00:22:41,970 This is kind of what the whole system looks like. 303 00:22:41,970 --> 00:22:45,440 You have your Red, Green, Blue channels. 304 00:22:45,440 --> 00:22:49,289 You take your 8 bits of input data on each channel 305 00:22:49,289 --> 00:22:53,850 and you convert it to the 10 bits 306 00:22:53,850 --> 00:22:56,710 that we’re going to transmit, and it goes across the cable 307 00:22:56,710 --> 00:23:01,169 and then we decode it on the other side. 308 00:23:01,169 --> 00:23:07,310 The question is: what does the 8 bit to 10 bit encoding 309 00:23:07,310 --> 00:23:11,980 look like and how do you understand that. 310 00:23:11,980 --> 00:23:17,149 It is described by this diagram here. It’s a bit small so I’ll bring it up. 311 00:23:17,149 --> 00:23:22,749 This is what it looks like. Yes… sure… 312 00:23:22,749 --> 00:23:27,729 …what? This diagram – like – 313 00:23:27,729 --> 00:23:32,380 I’ve spent hours looking at this, and it is an extremely hard diagram 314 00:23:32,380 --> 00:23:38,580 to decode. It’s very, very hard to understand. 315 00:23:38,580 --> 00:23:42,750 And it turns out the encoding protocol is actually quite easy! 316 00:23:42,750 --> 00:23:47,900 It’s three easy steps – approximately. 317 00:23:47,900 --> 00:23:52,059 So I’m going to show you all how to write an encoder or a decoder. 318 00:23:52,059 --> 00:23:55,279 That diagram is just for the encoder. 319 00:23:55,279 --> 00:24:00,729 They have a similar diagram that is not the inverse of this for decoding. 320 00:24:00,729 --> 00:24:03,980 Again, almost impossible to read. 321 00:24:03,980 --> 00:24:07,440 The three steps: First we’re going to do ‘Control’ or ‘Pixel’, 322 00:24:07,440 --> 00:24:11,260 choose which one to do. Then we’re going to either encode Control data 323 00:24:11,260 --> 00:24:15,969 or encode Pixel data. 324 00:24:15,969 --> 00:24:21,179 A couple of important points to go through first: 325 00:24:21,179 --> 00:24:24,480 The Input data – no matter how wide it is – 326 00:24:24,480 --> 00:24:29,120 is converted to 10 bit symbols. 327 00:24:29,120 --> 00:24:32,059 Data goes to symbols. When we’re talking about them 328 00:24:32,059 --> 00:24:36,760 being transmitted we talk about them in symbols, when it’s decoded into pixels 329 00:24:36,760 --> 00:24:40,130 we talk about them in data. 330 00:24:40,130 --> 00:24:45,760 As well, things need to be kept DC-balanced. 331 00:24:45,760 --> 00:24:48,480 I’ve rushed ahead. 332 00:24:48,480 --> 00:24:52,850 The question is: “Why 10 bits?” Our pixels were 8 bits. 333 00:24:52,850 --> 00:24:56,070 I will explain why in the Pixel Data section. 334 00:24:56,070 --> 00:24:59,060 But it’s important that all our symbols are the same size. 335 00:24:59,060 --> 00:25:05,159 We’re always transmitting 10 bits every clock cycle. 336 00:25:05,159 --> 00:25:08,530 Keeping DC-balanced: 337 00:25:08,530 --> 00:25:12,879 long runs of 1s and 0s are bad. 338 00:25:12,879 --> 00:25:15,909 There are lots of reasons for this. 339 00:25:15,909 --> 00:25:21,809 I tend to think of it like HDMI isn’t AC coupled 340 00:25:21,809 --> 00:25:27,280 but you can kind of think of it like AC coupled. 341 00:25:27,280 --> 00:25:30,389 It’s not to recover Clock. 342 00:25:30,389 --> 00:25:35,419 We have a clock pair that is used to give our Clock signal. 343 00:25:35,419 --> 00:25:38,059 There are lots of lies on internet that say that the reason 344 00:25:38,059 --> 00:25:42,649 we’re going to keep DC balance is because of Clock. 345 00:25:42,649 --> 00:25:47,549 But no, that’s not the case. 346 00:25:47,549 --> 00:25:52,320 So what does DC balance mean? 347 00:25:52,320 --> 00:25:57,110 A symbol which has lots of 1s or lots of 0s 348 00:25:57,110 --> 00:26:00,870 is going to be considered DC-biased 349 00:26:00,870 --> 00:26:05,270 if it has more 1s than 0s. 350 00:26:05,270 --> 00:26:08,769 This is kind of what it’s like: this symbol here 351 00:26:08,769 --> 00:26:12,530 has lots of 1s and if you add up all the 1s you can see it’s got 352 00:26:12,530 --> 00:26:16,919 quite a positive bias. If it was inverse and had lots of 0s 353 00:26:16,919 --> 00:26:19,509 it would have a negative DC bias. 354 00:26:19,509 --> 00:26:26,610 That cause… that DC bias over time causes us problems. 355 00:26:26,610 --> 00:26:32,380 That are the two important things we have to keep in mind when looking at the rest. 356 00:26:32,380 --> 00:26:34,429 *sound of bottle sip* 357 00:26:34,429 --> 00:26:37,710 The first thing we need to figure out is are we transmitting Control data 358 00:26:37,710 --> 00:26:39,940 or Pixel data. 359 00:26:39,940 --> 00:26:44,010 Turns out that what is happening in your display is, 360 00:26:44,010 --> 00:26:47,089 we are transmitting something that’s actually bigger 361 00:26:47,089 --> 00:26:50,909 than what you see on your screen. 362 00:26:50,909 --> 00:26:57,370 This not the scale. The Control data periods are much, much smaller. 363 00:26:57,370 --> 00:27:06,230 The Control data is in orange and the Pixel data is in purple-pink. 364 00:27:06,230 --> 00:27:12,260 So why does this exist? It exists because of old CRT monitors. 365 00:27:12,260 --> 00:27:16,620 And for those in the audience who where kind of born after CRT monitors, 366 00:27:16,620 --> 00:27:19,720 this is what they look like. 367 00:27:19,720 --> 00:27:23,350 The way they work is, they have an electron beam 368 00:27:23,350 --> 00:27:27,919 that scans across, highlighting the phosphorus. 369 00:27:27,919 --> 00:27:34,620 This electron beam can’t just be… get back to other side of the screen 370 00:27:34,620 --> 00:27:39,049 straight away, or get back to the top of the screen. And so these periods 371 00:27:39,049 --> 00:27:43,639 where we are transmitting Control data was to allow the electron beam 372 00:27:43,639 --> 00:27:47,470 to get back to the location where it needed to start 373 00:27:47,470 --> 00:27:53,160 transmitting the next set of data. 374 00:27:53,160 --> 00:27:56,079 That’s why it exists. Why do we care? 375 00:27:56,079 --> 00:27:59,090 Because the encoding schemes for Control and Pixel data 376 00:27:59,090 --> 00:28:03,820 are actually quite different. 377 00:28:03,820 --> 00:28:07,150 This is the main difference. I’m going to come back to this slide 378 00:28:07,150 --> 00:28:11,509 a bit later. But again, the important thing to see here is 379 00:28:11,509 --> 00:28:15,300 that despite the encoding scheme being quite different 380 00:28:15,300 --> 00:28:21,630 the output is 10 bits in size. 381 00:28:21,630 --> 00:28:25,389 That first step – choosing whether it’s Pixel or Control data – 382 00:28:25,389 --> 00:28:30,110 is described by this bit of the diagram. You might notice that’s 383 00:28:30,110 --> 00:28:34,309 not the first thing in the diagram. 384 00:28:34,309 --> 00:28:37,900 How do you convert Control data to Control symbols? 385 00:28:37,900 --> 00:28:41,419 First we need to know what Control data is. There are two bits, 386 00:28:41,419 --> 00:28:44,500 there is the HSync and the VSync signal. 387 00:28:44,500 --> 00:28:51,269 They provide basically the horizontal and vertical pixel sizes. 388 00:28:51,269 --> 00:28:55,460 They are kind of left over from VGA. We don’t actually need them 389 00:28:55,460 --> 00:29:01,100 in HDMI or DVI to know where the edges are 390 00:29:01,100 --> 00:29:06,710 because we can tell the difference between Control and Pixel data. 391 00:29:06,710 --> 00:29:11,890 But they kind of still exist because of backwards compatibility. 392 00:29:11,890 --> 00:29:15,860 This means that we have two bits of data that we need to convert to 10 bits of data. 393 00:29:15,860 --> 00:29:22,409 So, a 2b/10b scheme. 394 00:29:22,409 --> 00:29:27,270 How they do it is they just hand-picked four symbols that were going to be 395 00:29:27,270 --> 00:29:30,380 these Control data symbols. 396 00:29:30,380 --> 00:29:35,020 These are the four symbols. There’s some interesting properties with them. 397 00:29:35,020 --> 00:29:38,720 They are chosen to be DC-balanced. They roughly have the same number 398 00:29:38,720 --> 00:29:46,870 of 0s and 1s. So we don’t have to worry about the DC bias with these symbols very much. 399 00:29:46,870 --> 00:29:51,740 They are also chosen to have seven or more transitions from 0 to 1 400 00:29:51,740 --> 00:29:58,610 in them. This number of transitions 401 00:29:58,610 --> 00:30:03,230 is used to understand the phase relationship 402 00:30:03,230 --> 00:30:07,020 of the different channels. So if you remember this diagram, 403 00:30:07,020 --> 00:30:12,950 we have a cable going between the transmitter and the transceiver. 404 00:30:12,950 --> 00:30:16,360 These are, again, very high speed signals. 405 00:30:16,360 --> 00:30:22,130 And even if the transmitter was transmitting everything at the same time, 406 00:30:22,130 --> 00:30:28,240 the cable isn’t ideal and might delay some of the symbols. 407 00:30:28,240 --> 00:30:32,880 The bits on one channel [might take] longer than others. 408 00:30:32,880 --> 00:30:37,320 By having lots of these transmissions we can actually find 409 00:30:37,320 --> 00:30:41,590 the phase relationship between each of the channels and then 410 00:30:41,590 --> 00:30:47,559 recover the data. And so that’s why these Control symbols 411 00:30:47,559 --> 00:30:52,400 have a large number of transitions in them. 412 00:30:52,400 --> 00:30:56,750 More on that later when we get to the implementation. And I’m running out’ time. 413 00:30:56,750 --> 00:31:01,159 This part of the diagram is the Control data encoding. 414 00:31:01,159 --> 00:31:04,190 *sip from bottle* 415 00:31:04,190 --> 00:31:06,990 What about Pixel data and the Pixel symbols? 416 00:31:06,990 --> 00:31:13,740 Again, in DVI each channel of the Pixel is 8 bits. 417 00:31:13,740 --> 00:31:17,199 And the encoding scheme is described by the rest of the diagram. 418 00:31:17,199 --> 00:31:22,480 But again, it’s actually really, really simple. 419 00:31:22,480 --> 00:31:26,520 This encoding scheme is called 8b/10b, 420 00:31:26,520 --> 00:31:30,030 because it takes 8 bits converting it to 10 bits. 421 00:31:30,030 --> 00:31:33,880 However, there is a huge danger here because IBM also invented 422 00:31:33,880 --> 00:31:37,480 the 8b/10b scheme that is used in everything. 423 00:31:37,480 --> 00:31:41,080 This is used in DisplayPort, it’s used in PCI Express, it’s used in SATA, 424 00:31:41,080 --> 00:31:43,929 it’s used in pretty much everything on the planet. 425 00:31:43,929 --> 00:31:48,259 This is not the encoding TDMS uses. 426 00:31:48,259 --> 00:31:52,490 You can lose a lot of time trying to map this diagram 427 00:31:52,490 --> 00:31:56,560 to the IBM coding scheme, and going these are not the same. 428 00:31:56,560 --> 00:32:03,490 That is because they’re not the same. This is a totally different coding scheme. 429 00:32:03,490 --> 00:32:07,570 Encoding Pixel data is a two-step process. I did say it was three-ish steps 430 00:32:07,570 --> 00:32:12,270 to do this. The first step is we want to reduce 431 00:32:12,270 --> 00:32:18,110 the transitions in the data. 432 00:32:18,110 --> 00:32:20,429 How do we do this? – Sorry, why do we do this? 433 00:32:20,429 --> 00:32:23,570 Because this, again, is a high speed channel. 434 00:32:23,570 --> 00:32:27,529 We want to reduce the cross-talk between the lanes. 435 00:32:27,529 --> 00:32:30,669 They are actually quite close to each other. 436 00:32:30,669 --> 00:32:34,779 So by reducing the number of transitions we can reduce 437 00:32:34,779 --> 00:32:40,130 the probability that the signal propagates 438 00:32:40,130 --> 00:32:45,760 from one channel to the next. And how we do it? 439 00:32:45,760 --> 00:32:49,789 We’re gonna choose one of two encoding schemes. 440 00:32:49,789 --> 00:32:54,000 An XOR encoding scheme or an XNOR encoding scheme. 441 00:32:54,000 --> 00:32:57,740 How do we do the XOR encoding scheme? It’s actually pretty simple. 442 00:32:57,740 --> 00:33:00,679 We set the Encoded Bit same as the first Data Bit 443 00:33:00,679 --> 00:33:04,310 and then the next Encoded Bit is the first Encoded Bit 444 00:33:04,310 --> 00:33:09,649 XORed with the Data bit. 445 00:33:09,649 --> 00:33:14,000 And then we just repeat until we’ve done the 8 bits. 446 00:33:14,000 --> 00:33:16,159 So this is how we do the XOR encoding. 447 00:33:16,159 --> 00:33:20,149 The XNOR encoding is the same process, except instead of using XOR 448 00:33:20,149 --> 00:33:24,500 it uses XNOR. 449 00:33:24,500 --> 00:33:29,210 How do we choose which one of these to use? 450 00:33:29,210 --> 00:33:35,019 If the Input Data byte has fewer than four 1s 451 00:33:35,019 --> 00:33:39,919 we use the XOR. If it has more than four 1s we use the XNOR. 452 00:33:39,919 --> 00:33:43,059 And then there’s a tie-break (?) if you have even. 453 00:33:43,059 --> 00:33:47,850 The important thing here is that this method is determined by the Data byte only. 454 00:33:47,850 --> 00:33:53,000 There is no hidden state here or continuous change. 455 00:33:53,000 --> 00:33:59,710 Every pixel has a one-to-one mapping to an encoding. 456 00:33:59,710 --> 00:34:04,260 Then we append a bit on the end that indicates 457 00:34:04,260 --> 00:34:09,030 whether we chose XOR, XNOR encoding of that data. 458 00:34:09,030 --> 00:34:15,219 And so that converts our 8 bits Input Pixels 459 00:34:15,219 --> 00:34:21,500 to 9 bits of encoded data, effectively our 8-bit encoded sequence 460 00:34:21,500 --> 00:34:27,720 and then one bit to indicate whether we chose XOR, or XNOR encoding 461 00:34:27,720 --> 00:34:34,239 for that Data bit. So that’s it there. 462 00:34:34,239 --> 00:34:38,060 This encoding is actually very good at reducing transitions. 463 00:34:38,060 --> 00:34:43,520 On average, we had roughly eight transitions previously, 464 00:34:43,520 --> 00:34:48,900 now we have roughly three-ish, so it’s pretty cool. 465 00:34:48,900 --> 00:34:51,220 I have no idea how they figured this out. 466 00:34:51,220 --> 00:34:55,570 I’m assuming some very smart mathematicians where involved 467 00:34:55,570 --> 00:35:00,330 because discovering this is beyond me. 468 00:35:00,330 --> 00:35:02,280 And that describes the top part of this process. 469 00:35:02,280 --> 00:35:04,410 *sounds of scratching nose and beard* 470 00:35:04,410 --> 00:35:11,660 This is where, in the TMDS, the Transition Minimization comes from, 471 00:35:11,660 --> 00:35:14,220 that step there in the encoding process. 472 00:35:14,220 --> 00:35:16,310 But there is still one more step. 473 00:35:16,310 --> 00:35:22,370 We need to keep the channel DC-balanced, as I explained earlier. 474 00:35:22,370 --> 00:35:27,860 How can we do that? Because not all pixels are guaranteed to be 475 00:35:27,860 --> 00:35:32,160 at zero DC bias like the Control symbols are. 476 00:35:32,160 --> 00:35:37,320 We do it by keeping a running count of the DC bias we have, 477 00:35:37,320 --> 00:35:41,500 and then, if we have a positive DC bias 478 00:35:41,500 --> 00:35:45,890 and the symbol is also positively biased, we invert it. 479 00:35:45,890 --> 00:35:51,770 Or, if we have a negative DC bias and the symbol has a negative DC bias, 480 00:35:51,770 --> 00:35:55,910 we invert it. And the reason we do this is 481 00:35:55,910 --> 00:36:00,830 because when we invert a symbol we convert all the 1s to 0s which means 482 00:36:00,830 --> 00:36:05,790 a negative DC bias becomes a positive DC bias. 483 00:36:05,790 --> 00:36:10,800 As I said, we chose – because we are already negative and the thing was negative – 484 00:36:10,800 --> 00:36:17,940 we convert it to plus. It means we’re going to drive the running DC bias value 485 00:36:17,940 --> 00:36:22,620 back towards zero. We might overshoot, but the next stage 486 00:36:22,620 --> 00:36:27,100 we’ll keep trying to oscillate up and down, and on average over time 487 00:36:27,100 --> 00:36:31,380 we keep a DC bias of zero. 488 00:36:31,380 --> 00:36:36,870 And as I said. Then, to indicate whether or not we inverted 489 00:36:36,870 --> 00:36:42,740 or kept… the… straight through we inverted, 490 00:36:42,740 --> 00:36:48,080 we add another bit on the end. So that’s how get our 10 bit 491 00:36:48,080 --> 00:36:53,780 encoding scheme. We have the 8 bits of encoded data, 492 00:36:53,780 --> 00:36:58,800 then one bit indicating whether or not it used XOR/XNOR encoding, 493 00:36:58,800 --> 00:37:04,030 and then one bit to indicate whether or not we inverted the symbol. 494 00:37:04,030 --> 00:37:09,970 That describes this bottom part of the chart. 495 00:37:09,970 --> 00:37:14,510 Now you can see partly why this chart is kind of confusing. 496 00:37:14,510 --> 00:37:18,840 It’s no way in what I think of a what’s a logical diagram. 497 00:37:18,840 --> 00:37:21,610 This might be how you implement it in hardware if you really understand 498 00:37:21,610 --> 00:37:28,990 the protocol, but not a very good diagram for explaining what’s going on. And… 499 00:37:28,990 --> 00:37:31,590 *sip from bottle* 500 00:37:31,590 --> 00:37:34,190 As you see it’s actually pretty simple. 501 00:37:34,190 --> 00:37:40,360 In summary this is the interesting information 502 00:37:40,360 --> 00:37:45,390 about the two different encoding schemes. 503 00:37:45,390 --> 00:37:49,350 Because we minimized the transitions in the Pixel data 504 00:37:49,350 --> 00:37:53,020 we can actually tell Control and Pixel data apart 505 00:37:53,020 --> 00:37:56,360 by looking at how many transitions are in the symbol. 506 00:37:56,360 --> 00:38:00,840 If it has six or more transitions it must be a Control symbol. 507 00:38:00,840 --> 00:38:06,040 If it has four or less it must be a Pixel symbol. 508 00:38:06,040 --> 00:38:09,610 You now know how to encode TDMS data 509 00:38:09,610 --> 00:38:12,290 and how to decode TDMS data 510 00:38:12,290 --> 00:38:18,070 because if you want to decode you just do the process backwards. 511 00:38:18,070 --> 00:38:25,480 Congratulations! How do you actually implement this? 512 00:38:25,480 --> 00:38:28,290 You can just write the XOR logic 513 00:38:28,290 --> 00:38:31,252 and a little counter that keeps track of the DC bias 514 00:38:31,252 --> 00:38:34,780 and all that type of thing in FPGA. 515 00:38:34,780 --> 00:38:38,690 I’m not going to describe that because I don’t have much time. 516 00:38:38,690 --> 00:38:43,130 But if you followed the process that I have given you 517 00:38:43,130 --> 00:38:45,980 it should be pretty easy. 518 00:38:45,980 --> 00:38:50,990 But… and this is what we use currently. 519 00:38:50,990 --> 00:38:53,700 You could actually use a lookup table. What we are doing is 520 00:38:53,700 --> 00:38:58,380 converting 8 bits of data to 10 bits of data. 521 00:38:58,380 --> 00:39:03,760 That is a lookup table process, pretty easy. 522 00:39:03,760 --> 00:39:08,900 FPGAs are really good at doing ‘lookup table’-type processes, 523 00:39:08,900 --> 00:39:13,010 and it also allows you then to extend this system 524 00:39:13,010 --> 00:39:18,150 to those other protocols like the 4b/10b that is used 525 00:39:18,150 --> 00:39:20,890 for the Auxiliary data. 526 00:39:20,890 --> 00:39:24,770 So we are looking at that in the future. It uses a few more resources 527 00:39:24,770 --> 00:39:28,020 but it’s a lot more powerful. 528 00:39:28,020 --> 00:39:32,790 This is kind of what your encoder will look like, and your decoder. 529 00:39:32,790 --> 00:39:36,650 It’s quite simple, it takes in your 10 bits of data 530 00:39:36,650 --> 00:39:39,400 and outputs either your 8 bits of Pixel data 531 00:39:39,400 --> 00:39:43,700 or your 2 bits of Control data and the data type. 532 00:39:43,700 --> 00:39:47,190 This is kind of what if you went into our design and looked at it 533 00:39:47,190 --> 00:39:49,570 at high level, in the schematic, 534 00:39:49,570 --> 00:39:52,220 you’d probably see a block that looks like this. 535 00:39:52,220 --> 00:39:56,430 The encoder is slightly more complicated because you also have the DC bias count 536 00:39:56,430 --> 00:40:00,990 that you have to keep track of. But, again, 537 00:40:00,990 --> 00:40:03,720 the data goes in and the data comes out. 538 00:40:03,720 --> 00:40:08,810 That’s simple, right? 539 00:40:08,810 --> 00:40:12,260 This kind of extends to Auxiliary data, or if you get an error, 540 00:40:12,260 --> 00:40:15,490 like if you… There are 124 symbols 541 00:40:15,490 --> 00:40:18,930 that you can have in 10 bits of data. 542 00:40:18,930 --> 00:40:22,160 Not all of them are valid. So if you get one of these invalid symbols 543 00:40:22,160 --> 00:40:25,770 you know you have an error. 544 00:40:25,770 --> 00:40:30,270 However, things happen quite quickly 545 00:40:30,270 --> 00:40:34,520 when you times them by ten. And so our Pixel Clock 546 00:40:34,520 --> 00:40:39,150 for 640x480 is 25 MHz. When you times that by ten 547 00:40:39,150 --> 00:40:45,000 you get 250 MBits per channel. When you’re doing 720p 548 00:40:45,000 --> 00:40:48,580 you’re doing 750 MBits per channel. 549 00:40:48,580 --> 00:40:53,810 And 1080p is at 1500 MBits per channel. 550 00:40:53,810 --> 00:40:59,080 An FPGA is fast, but they’re not really that fast 551 00:40:59,080 --> 00:41:03,950 at a range that I can afford to buy. I’m sure the military has ones 552 00:41:03,950 --> 00:41:08,480 that go this fast, but I’m not as rich as them. 553 00:41:08,480 --> 00:41:12,180 But they do include a nice hack to solve this. 554 00:41:12,180 --> 00:41:15,310 They are called SerDes. They basically turn parallel data 555 00:41:15,310 --> 00:41:18,790 into serial data. 556 00:41:18,790 --> 00:41:21,830 This is what the boxes look like. 557 00:41:21,830 --> 00:41:24,230 You give them your TDMS parallel data 558 00:41:24,230 --> 00:41:27,940 and they convert it to high speed serial data for you. 559 00:41:27,940 --> 00:41:32,540 They are a little bit fiddly to use and your best option is to go and find 560 00:41:32,540 --> 00:41:37,400 a person who has already configured this for your FPGA 561 00:41:37,400 --> 00:41:39,900 and follow what they do. 562 00:41:39,900 --> 00:41:44,430 “Hamster” – Mike “Hamster” Field – has a really good documentation on 563 00:41:44,430 --> 00:41:49,940 how to use these in a Spartan6. These are also unique to your FPGA, 564 00:41:49,940 --> 00:41:54,140 so different FPGAs are going to have different control schemes. 565 00:41:54,140 --> 00:41:56,900 But if you are using a Spartan6 566 00:41:56,900 --> 00:42:02,390 then go and look up what Mike “Hamster” Field is 567 00:42:02,390 --> 00:42:07,770 doing for configuring these. 568 00:42:07,770 --> 00:42:14,190 Remember how I said, our system has a serial console. 569 00:42:14,190 --> 00:42:18,630 Because we have that system we can actually delve quite deep 570 00:42:18,630 --> 00:42:22,910 into what’s happening internally in the system. 571 00:42:22,910 --> 00:42:25,110 *sip from bottle* 572 00:42:25,110 --> 00:42:32,920 And print it out. This is debugging from one of our systems. 573 00:42:32,920 --> 00:42:35,140 You can see… 574 00:42:35,140 --> 00:42:40,550 The first thing is the phase relationship between each of the channels. 575 00:42:40,550 --> 00:42:44,790 The next one is whether we’re getting valid data 576 00:42:44,790 --> 00:42:49,770 on each of the channels and then we’ve got the error rate for that channel, 577 00:42:49,770 --> 00:42:54,370 whether all channels synchronized, and then some resolution information. 578 00:42:54,370 --> 00:43:00,200 You can see that this has got a 74 MHz Pixel Clock. 579 00:43:00,200 --> 00:43:05,080 There are three columns because there is Red, Green and Blue channels. 580 00:43:05,080 --> 00:43:09,230 This give us some very interesting debugging capabilities. 581 00:43:09,230 --> 00:43:13,210 If you plug in a cable and you’re getting errors 582 00:43:13,210 --> 00:43:17,240 on the Blue channel and nowhere else 583 00:43:17,240 --> 00:43:21,560 it’s highly likely there’s something wrong with that cable. 584 00:43:21,560 --> 00:43:25,500 This is a very powerful tool that allows us to figure out 585 00:43:25,500 --> 00:43:29,740 what’s going wrong in a system. 586 00:43:29,740 --> 00:43:35,270 It’s something you can’t really get with the commercial versions of this. 587 00:43:35,270 --> 00:43:39,060 But what about errors? Everything I’m talking about now 588 00:43:39,060 --> 00:43:42,040 is a little bit experimental, we haven’t actually implemented this. 589 00:43:42,040 --> 00:43:45,700 But it’s some ideas about what we can do because we now 590 00:43:45,700 --> 00:43:49,590 have complete control of our decoder. 591 00:43:49,590 --> 00:43:54,220 As I said, there’s 124 possible choices for 10 bit symbols, 592 00:43:54,220 --> 00:43:58,220 of which 460 are valid Pixel symbols, 593 00:43:58,220 --> 00:44:02,390 4 are valid Control symbols and 560 symbols 594 00:44:02,390 --> 00:44:05,060 should never ever be seen no matter what. 595 00:44:05,060 --> 00:44:11,890 That’s like 56% of our space that should never be seen. 596 00:44:11,890 --> 00:44:16,330 But it’s actually better than that! We know because of the running DC bias 597 00:44:16,330 --> 00:44:25,050 that there are 256 valid Pixel symbols 598 00:44:25,050 --> 00:44:31,150 at any one point. You can’t have the… if you’ve got a negative DC bias 599 00:44:31,150 --> 00:44:37,240 you can’t have a Pixel symbol which continues to drive you negative. 600 00:44:37,240 --> 00:44:43,710 Actually, 74% of our space at any time 601 00:44:43,710 --> 00:44:48,030 is not allowed to exist. 602 00:44:48,030 --> 00:44:52,070 This means that a huge number of the invalid symbols 603 00:44:52,070 --> 00:44:56,180 are only near one other valid symbol. 604 00:44:56,180 --> 00:45:01,530 And so we can actually correct them! We can go: “This symbol must have been 605 00:45:01,530 --> 00:45:04,950 this other symbol, because it’s not a valid symbol, 606 00:45:04,950 --> 00:45:08,840 it must be a bit error from this other symbol.” 607 00:45:08,840 --> 00:45:12,870 So we can correct these errors. This is quite cool. 608 00:45:12,870 --> 00:45:19,030 We can correct about 70% of 609 00:45:19,030 --> 00:45:21,970 single bit flip errors in Pixel data. 610 00:45:21,970 --> 00:45:28,510 But sadly there is some that we can’t. 611 00:45:28,510 --> 00:45:34,960 But we can detect that we got a invalid Pixel data. 612 00:45:34,960 --> 00:45:40,320 So the fact that there is an error is important. 613 00:45:40,320 --> 00:45:43,910 In this case we’ve got two pixels that we received correctly 614 00:45:43,910 --> 00:45:49,030 and we got a pixel that we know is a invalid value 615 00:45:49,030 --> 00:45:53,550 and then two more pixels that we received correctly. 616 00:45:53,550 --> 00:45:55,180 You can imagine this is a Blue channel, 617 00:45:55,180 --> 00:45:59,040 so the first ones were not very blue. 618 00:45:59,040 --> 00:46:03,010 Then there’s the decoded value for this is 619 00:46:03,010 --> 00:46:07,290 very, very blue, like very light blue and then some other ones. 620 00:46:07,290 --> 00:46:09,950 This looks really bad, right? 621 00:46:09,950 --> 00:46:15,480 This was probably a whole blue block. 622 00:46:15,480 --> 00:46:20,180 One pixel difference of that big, that size, 623 00:46:20,180 --> 00:46:24,030 is probably not a valid value, 624 00:46:24,030 --> 00:46:26,440 and so we can cover them up! 625 00:46:26,440 --> 00:46:29,680 We can go… the two pixels on either side 626 00:46:29,680 --> 00:46:32,320 and average them and fix that pixel. 627 00:46:32,320 --> 00:46:38,250 This allow us to correct a whole bunch more of errors that are occurring. 628 00:46:38,250 --> 00:46:41,460 And as we’re about to take this data 629 00:46:41,460 --> 00:46:45,940 and run it through a JPEG encoder 630 00:46:45,940 --> 00:46:49,620 this doesn’t actually affect the quality of the output 631 00:46:49,620 --> 00:46:53,150 all that much and allows to fix things that would otherwise 632 00:46:53,150 --> 00:46:59,810 be giant glaring glitches in the output. 633 00:46:59,810 --> 00:47:02,440 That’s some interesting information about 634 00:47:02,440 --> 00:47:09,490 how you do TDMS decoding and how we can fix some errors. 635 00:47:09,490 --> 00:47:12,560 The thing is, we can do it even better than this 636 00:47:12,560 --> 00:47:15,530 because it’s an open source project. 637 00:47:15,530 --> 00:47:19,600 Maybe you have some idea about how we can improve 638 00:47:19,600 --> 00:47:22,890 the SerDes performance. Maybe you have an idea about 639 00:47:22,890 --> 00:47:28,870 how to do TDMS decoding on much lower power devices 640 00:47:28,870 --> 00:47:33,540 than we use. It’s open source! You can look at the code 641 00:47:33,540 --> 00:47:39,100 and you can improve it. And we would love you to do it! 642 00:47:39,100 --> 00:47:43,450 The thing is that I have a lot of hardware but not much time. 643 00:47:43,450 --> 00:47:45,710 If you have lots of time and not much hardware, 644 00:47:45,710 --> 00:47:49,940 I think I can solve this problem. 645 00:47:49,940 --> 00:47:54,790 These are links to the HDMI2USB project 646 00:47:54,790 --> 00:47:58,840 and the TimVideos project; and all our code, our hardware, 647 00:47:58,840 --> 00:48:04,620 everything is on GitHub under open source licenses. 648 00:48:04,620 --> 00:48:11,110 And here is some bonus screen shots that I wasn’t able to fit in other locations. 649 00:48:11,110 --> 00:48:13,920 You can see these small errors. 650 00:48:13,920 --> 00:48:16,840 That one was kind of a big error. 651 00:48:16,840 --> 00:48:25,880 This is what happens when your DDR memory is slightly broken. 652 00:48:25,880 --> 00:48:31,800 Yeah… but – yeah! 653 00:48:31,800 --> 00:48:35,030 And that is my talk! 654 00:48:35,030 --> 00:48:42,990 *applause* 655 00:48:42,990 --> 00:48:45,250 Herald: Excellent! Thank you very much, mithro. 656 00:48:45,250 --> 00:48:48,850 As you’ve noticed, we have a couple of microphones standing around in the room. 657 00:48:48,850 --> 00:48:52,960 If you have any questions for mithro please line up behind the microphones 658 00:48:52,960 --> 00:48:57,950 and I will allow you to ask the questions. We have question from the Internet!? 659 00:48:57,950 --> 00:49:01,700 Signal Angel: Yes, thank you! Do you know if normal monitors 660 00:49:01,700 --> 00:49:04,650 do similar error recovery or hiding? 661 00:49:04,650 --> 00:49:08,910 Tim: I know of no commercial implementation that does 662 00:49:08,910 --> 00:49:12,720 any type of error correction. The solution for the commercial guys 663 00:49:12,720 --> 00:49:19,840 is to effectively never get errors. 664 00:49:19,840 --> 00:49:24,170 They can do that because 665 00:49:24,170 --> 00:49:26,700 they don’t have to deal with the angry speakers on the ground 666 00:49:26,700 --> 00:49:30,970 going wild as my slides look weird. 667 00:49:30,970 --> 00:49:34,760 And, as well, they are probably working with better quality hardware 668 00:49:34,760 --> 00:49:39,120 than we are using. We’re trying to make things as cheap as possible. 669 00:49:39,120 --> 00:49:43,720 And so we are pushing the boundaries of a lot of the devices we are using. 670 00:49:43,720 --> 00:49:48,250 So we are more likely to get errors than they are. 671 00:49:48,250 --> 00:49:51,580 Herald: We have quite a lot of questions. Remember – questions, not comments! 672 00:49:51,580 --> 00:49:55,520 Microphone number 1, please! 673 00:49:55,520 --> 00:50:11,260 *rustling sound from audience* *coughing* 674 00:50:11,260 --> 00:50:12,830 Tim: Yes! 675 00:50:12,830 --> 00:50:18,180 *unrecognizable question from audience* 676 00:50:18,180 --> 00:50:20,920 Sorry, I don’t quite understand what’s going on! *chuckles* 677 00:50:20,920 --> 00:50:27,400 Herald: Do we have a translation? 678 00:50:27,400 --> 00:50:29,890 Voice from audience: Audio Angel! 679 00:50:29,890 --> 00:50:34,220 Tim: Audio problem? 680 00:50:34,220 --> 00:50:45,490 *Herald speaks to person in front of stage in German* 681 00:50:45,490 --> 00:50:51,530 Tim: I’ll be around afterwards, If you want to chat to me, ahm… 682 00:50:51,530 --> 00:50:57,110 Herald: And we might do that… ah… write you on the computer afterwards. 683 00:50:57,110 --> 00:51:01,530 Second question from microphone number 3, please! 684 00:51:01,530 --> 00:51:05,500 Question: Hello? Ah, yes. Can you determine the quality of a HDMI cable, 685 00:51:05,500 --> 00:51:08,520 e.g. by measuring bit error rate of each three pairs 686 00:51:08,520 --> 00:51:11,350 and also some jitter on the clock, and that kind of…? 687 00:51:11,350 --> 00:51:13,970 Tim: Yes we can! 688 00:51:13,970 --> 00:51:18,100 The quality of a HDMI cable should be they’re zero bit errors. 689 00:51:18,100 --> 00:51:23,540 So anything that has non-zero bit errors we chop up and throw away. 690 00:51:23,540 --> 00:51:27,870 This gets interesting when you have very long cables. 691 00:51:27,870 --> 00:51:31,150 We can actually see that the longer the cable is 692 00:51:31,150 --> 00:51:37,160 the harder for them to keep zero bit errors. 693 00:51:37,160 --> 00:51:43,230 So yes, we can kind of judge the quality of the cable. 694 00:51:43,230 --> 00:51:47,500 But it’s also hard because 695 00:51:47,500 --> 00:51:51,460 it depends on what the sender is doing. 696 00:51:51,460 --> 00:51:54,750 If the sender is of a lower quality 697 00:51:54,750 --> 00:51:58,070 and the cable is low quality you might get bit errors. 698 00:51:58,070 --> 00:52:00,400 But if the sender is of a high quality 699 00:52:00,400 --> 00:52:06,810 and the cable is of a lower quality 700 00:52:06,810 --> 00:52:11,330 they might cancel each other out and still be fine. 701 00:52:11,330 --> 00:52:16,330 We can’t just go: “This is a good cable” 702 00:52:16,330 --> 00:52:20,880 because we don’t actually have any control over our… 703 00:52:20,880 --> 00:52:25,810 how powerful our sender is on this device. 704 00:52:25,810 --> 00:52:28,040 If we could kind of turn down the sender 705 00:52:28,040 --> 00:52:31,210 and see where things start going wrong that would be pretty cool. 706 00:52:31,210 --> 00:52:34,760 If anybody wants to look at building such a device 707 00:52:34,760 --> 00:52:37,910 I’d love to help you do that. 708 00:52:37,910 --> 00:52:41,300 Herald: We have another question from microphone number 5. 709 00:52:41,300 --> 00:52:44,880 Question: Your hardware, the HDMI2USB hardware… 710 00:52:44,880 --> 00:52:47,900 Tim: Yes! Question: Is it available for simply ordering 711 00:52:47,900 --> 00:52:51,970 or has it to be solder soldered by hand, or… 712 00:52:51,970 --> 00:52:56,280 Tim: You can not solder this board by hand unless you are much, much better 713 00:52:56,280 --> 00:53:01,790 than I am. It uses Ball Grid Array parts because it’s an FPGA. 714 00:53:01,790 --> 00:53:04,530 This is one here. You can buy them. 715 00:53:04,530 --> 00:53:10,020 We’re working with a manufacturer in India who builds them for us. 716 00:53:10,020 --> 00:53:15,280 We work with them, and it was pretty awesome. 717 00:53:15,280 --> 00:53:17,540 We’re also working on new hardware. I’ve got a whole bunch 718 00:53:17,540 --> 00:53:21,860 of FPGA hardware here that you can come and have a look at 719 00:53:21,860 --> 00:53:25,920 and I’ll probably move it out into the hallway afterwards. 720 00:53:25,920 --> 00:53:30,490 Again, if you’re interested in the hardware and you have a use case, 721 00:53:30,490 --> 00:53:35,100 chat to me! Because I like to solve problems 722 00:53:35,100 --> 00:53:39,460 of people who are not having hardware and my employer pays me too much. 723 00:53:39,460 --> 00:53:43,210 So I get to use my discretion refunds 724 00:53:43,210 --> 00:53:47,710 for helping out people doing open source stuff. 725 00:53:47,710 --> 00:53:54,500 *applause* 726 00:53:54,500 --> 00:53:59,220 Herald: We have at least four more questions. Microphone number 2, please! 727 00:53:59,220 --> 00:54:05,030 Question: Do you think it would be possible to get an 1080p image 728 00:54:05,030 --> 00:54:09,780 out of the open source hardware board you use? 729 00:54:09,780 --> 00:54:16,960 Tim: Yes, I do, but it requires us to do some hard work 730 00:54:16,960 --> 00:54:19,070 that we haven’t had time to do yet. 731 00:54:19,070 --> 00:54:26,990 And for us 720p at 60 frames per second is good enough. 732 00:54:26,990 --> 00:54:32,340 The USB connection 733 00:54:32,340 --> 00:54:36,290 is limited in bandwidth because we don’t have an H.264 encoder, 734 00:54:36,290 --> 00:54:43,020 we only have MJPEG. If somebody wants to write us a open source, say, WebM 735 00:54:43,020 --> 00:54:47,000 rather than H.264 encoder 736 00:54:47,000 --> 00:54:50,710 that might start become more interesting. We also have ethernet, Gigabit ethernet, 737 00:54:50,710 --> 00:54:56,470 on this board. It should be pretty ease to stream the data out the ethernet. 738 00:54:56,470 --> 00:54:59,140 I, again, need help. 739 00:54:59,140 --> 00:55:01,700 The ethernet controller works. We can telnet into the board 740 00:55:01,700 --> 00:55:07,050 and control it via Telnet. We just need somebody to 741 00:55:07,050 --> 00:55:11,470 actually connect the data, the high speed data side up. 742 00:55:11,470 --> 00:55:14,780 We use it for debugging and stuff. 743 00:55:14,780 --> 00:55:18,720 Mike “Hamster” Field again, really big thank you to him, 744 00:55:18,720 --> 00:55:22,490 he is an amazing designer, 745 00:55:22,490 --> 00:55:28,780 he built 1080p60 that is a little bit out-of-spec 746 00:55:28,780 --> 00:55:33,120 but actually works really well on hardware 747 00:55:33,120 --> 00:55:38,870 that is almost identical to ours. He also did the DisplayPort, 748 00:55:38,870 --> 00:55:43,490 like a 4k-DisplayPort which we can do on our board. 749 00:55:43,490 --> 00:55:49,630 If you only need one or two of the 1080p things 750 00:55:49,630 --> 00:55:52,670 DisplayPort connectors can be converted to HDMI quite easily 751 00:55:52,670 --> 00:55:56,500 and you can do that on them. 752 00:55:56,500 --> 00:55:58,850 Yes, I think that’s possible, but again: 753 00:55:58,850 --> 00:56:05,900 open source … hobbyist … need developers … 754 00:56:05,900 --> 00:56:07,990 Herald: We’ll take one question from the internet! 755 00:56:07,990 --> 00:56:12,870 Signal Angel: Thank you. Have you considered JPEG2000? 756 00:56:12,870 --> 00:56:17,860 Tim: No, I’ve not. And the main reason is that I want to be a webcam. 757 00:56:17,860 --> 00:56:25,780 I want to pretend to be a webcam. The UVC standard, which is the USB webcam standard, 758 00:56:25,780 --> 00:56:30,720 does not support JPEG2000. 759 00:56:30,720 --> 00:56:34,260 There’s no reason we couldn’t support JPEG2000 when connected to Linux, 760 00:56:34,260 --> 00:56:38,770 like we could fix the Linux driver to add JPEG2000 support. 761 00:56:38,770 --> 00:56:44,890 Again, I don’t know if there’s any good open source FPGA implementations 762 00:56:44,890 --> 00:56:52,670 of JPEG2000? So, that’s also a blocker. 763 00:56:52,670 --> 00:56:57,500 But if you’re interested in helping out – come and talk to me. 764 00:56:57,500 --> 00:57:01,780 As I said, I would very much love 765 00:57:01,780 --> 00:57:06,600 to chat to you and solve the problems you’re having 766 00:57:06,600 --> 00:57:11,540 with getting-going. As well, we have t-shirts. 767 00:57:11,540 --> 00:57:16,410 I’m wearing a t-shirt that we have, and I will send everybody who contributes 768 00:57:16,410 --> 00:57:23,780 a t-shirt. Whether that’s fixing our website, helping on documentation, 769 00:57:23,780 --> 00:57:28,050 helping people on IRC getting setup, anything. 770 00:57:28,050 --> 00:57:34,320 You don’t need to be an expert on FPGA stuff to help out. 771 00:57:34,320 --> 00:57:38,410 And we also are working on a little project to run MicroPython 772 00:57:38,410 --> 00:57:43,160 on FPGAs. So if you’re really into Python and you like MicroPython 773 00:57:43,160 --> 00:57:48,060 I would love to help you help us do that. 774 00:57:48,060 --> 00:57:53,260 It’s kind of working. We just need more powerful (?) support. So. 775 00:57:53,260 --> 00:57:56,230 Herald: We have two more questions from microphone number 1. 776 00:57:56,230 --> 00:57:59,480 Question: So, is there some sort of dedicated processor on that board, 777 00:57:59,480 --> 00:58:02,390 or do you use like a Microblaze in the FPGA? 778 00:58:02,390 --> 00:58:06,810 Tim: We use an open source soft core. One of three. 779 00:58:06,810 --> 00:58:11,820 We can change which soft core we’re using with a command line flag. 780 00:58:11,820 --> 00:58:16,390 We’re using either the LatticeMico32 781 00:58:16,390 --> 00:58:19,790 which is produced by Lattice Semiconductor. 782 00:58:19,790 --> 00:58:24,550 We can use the OpenRISC-1000 783 00:58:24,550 --> 00:58:28,530 or we can use a RISC-V processor. 784 00:58:28,530 --> 00:58:34,750 We generally default to LM32 because it’s the most performance 785 00:58:34,750 --> 00:58:40,430 for least FPGA resource trade-off. 786 00:58:40,430 --> 00:58:46,240 But if you like RISC-V or OpenRISC-1000 better 787 00:58:46,240 --> 00:58:51,920 for some reason, say, you want to run Linux on our soft core, 788 00:58:51,920 --> 00:58:58,450 then you can do that. With a one line command line change, yeah! 789 00:58:58,450 --> 00:59:03,730 We’re looking at adding J-Core support in early next year. 790 00:59:03,730 --> 00:59:07,910 J-Core is quite big, though, compared to LM32. So, 791 00:59:07,910 --> 00:59:11,520 it probably won’t fit on some of the very small devices. 792 00:59:11,520 --> 00:59:14,270 Question: So it’s a Lattice FPGA? 793 00:59:14,270 --> 00:59:21,250 Tim: It’s a Spartan6 FPGA. And our new boards will probably be Artix-7 794 00:59:21,250 --> 00:59:24,180 But we’re still in the process of making them exist yet. 795 00:59:24,180 --> 00:59:25,660 Question: Thanks. Tim: I’ve also been working with 796 00:59:25,660 --> 00:59:30,290 bunnie’s NeTV2, porting our firmware to that, 797 00:59:30,290 --> 00:59:33,460 which has been really awesome. He’s doing some cool work there, 798 00:59:33,460 --> 00:59:39,910 and he’s kind of inspired this whole development by showing that, 799 00:59:39,910 --> 00:59:43,420 yes, you could do this, and you shouldn’t be scared of it. 800 00:59:43,420 --> 00:59:45,820 Herald: Good, one more question from microphone number 1. 801 00:59:45,820 --> 00:59:53,880 Question: Yes. Do you have any plans for incorporating HD-SDI into your platform? 802 00:59:53,880 --> 00:59:58,560 Tim: Yes and no! We have plans and ideas 803 00:59:58,560 --> 01:00:01,650 that we could do it 804 01:00:01,650 --> 01:00:07,330 but HD-SDI 805 01:00:07,330 --> 01:00:13,230 and all of the SDI protocols are much harder for the consumer, 806 01:00:13,230 --> 01:00:17,330 generally to access, and we want to drive the costs of this down 807 01:00:17,330 --> 01:00:22,070 to as low as it can go. And… 808 01:00:22,070 --> 01:00:26,060 HDMI is a consumer electronic thing. You get it on everything. 809 01:00:26,060 --> 01:00:30,170 You get it on your like five-buck Raspberry Pi. 810 01:00:30,170 --> 01:00:35,120 HDMI is probably a really good solution for this. 811 01:00:35,120 --> 01:00:38,190 We haven’t developed any SDI cores or anything like that, 812 01:00:38,190 --> 01:00:43,330 so I can’t tell you like that we’re doing anything there 813 01:00:43,330 --> 01:00:49,460 but if somebody’s interested, again, I like to remove roll (?) blocks and 814 01:00:49,460 --> 01:00:53,230 we would love to have people work on that. 815 01:00:53,230 --> 01:00:56,260 Herald: We have one more question from the internet and we have two minutes left. 816 01:00:56,260 --> 01:01:01,810 Signal Angel: OK, thank you. The question is not related to HDMI but to FPGAs. 817 01:01:01,810 --> 01:01:06,170 FPGAs are programmed in a high level language like VERILOG or… 818 01:01:06,170 --> 01:01:11,030 after simulation you compile. So every vendor has created his own compiler 819 01:01:11,030 --> 01:01:15,990 for its own hardware. Are you aware of a move to open source compilers 820 01:01:15,990 --> 01:01:21,220 or to independent hardware? And do you see a benefit in open source FPGA compilers? 821 01:01:21,220 --> 01:01:27,450 Tim: Yes! If anybody knows 822 01:01:27,450 --> 01:01:30,590 about FPGAs you know they use proprietary compilers. 823 01:01:30,590 --> 01:01:35,510 And these proprietary compilers are terrible. 824 01:01:35,510 --> 01:01:39,560 I’m a software engineer. If I find a bug in gcc 825 01:01:39,560 --> 01:01:43,750 I can fix the bug. I’ve got those skills, and I can move forward or at least 826 01:01:43,750 --> 01:01:47,220 figure out why the hell the bug occurred. 827 01:01:47,220 --> 01:01:51,600 That is not the case with FPGA compilers. The FPGA compiler we use 828 01:01:51,600 --> 01:01:56,970 is non-deterministic. You can give it the same source code and it produces 829 01:01:56,970 --> 01:02:01,800 different output. I’d love somebody to reverse-engineer why that occurs 830 01:02:01,800 --> 01:02:07,470 because I’ve removed all the randomness from random sources from it 831 01:02:07,470 --> 01:02:11,890 and it still manages to do it! I’m really impressed. So, 832 01:02:11,890 --> 01:02:16,940 Clifford has done an open source FPGA tool chain 833 01:02:16,940 --> 01:02:21,980 for the Lattice iCEstick things. 834 01:02:21,980 --> 01:02:28,940 He said he’s gonna work on the Actrix7 FPGAs. 835 01:02:28,940 --> 01:02:34,180 Please donate to him and help him. I would… like… 836 01:02:34,180 --> 01:02:38,030 if that exists I owe people who… like a bazillion of beers, because 837 01:02:38,030 --> 01:02:43,270 the sooner I can get off proprietary tool chains the happier I will be, 838 01:02:43,270 --> 01:02:48,730 and it will make my hobby so much nicer. So, please help him! 839 01:02:48,730 --> 01:02:50,930 Herald: And do give Tim a big round of applause! 840 01:02:50,930 --> 01:02:54,510 *applause* 841 01:02:54,510 --> 01:02:58,300 *postroll music* 842 01:02:58,300 --> 01:03:18,501 *subtitles created by c3subtitles.de in the year 2017. Join, and help us!*