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!*