WEBVTT
00:00:00.000 --> 00:00:14.309
33C3 preroll music
00:00:14.309 --> 00:00:17.380
Herald-Angel: Tim ‘mithro’ Ansell
has come all the way from Australia
00:00:17.380 --> 00:00:24.510
to talk to us about ‘Dissecting HDMI’
and developing an open FPGA-based
00:00:24.510 --> 00:00:29.930
capture hardware for sharing
talks outside of the room.
00:00:29.930 --> 00:00:34.680
And he will be explaining how
to dissect it. And I’m looking forward
00:00:34.680 --> 00:00:38.620
to hearing the talk in a second.
And so please give Tim
00:00:38.620 --> 00:00:41.330
a warm round of applause
again. Thank you!
00:00:41.330 --> 00:00:50.520
applause
00:00:50.520 --> 00:00:56.149
Tim Ansell: Okay, hi, I’m Tim, and
in theory, if my slides change
00:00:56.149 --> 00:01:02.550
you would see that.
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.
00:01:08.540 --> 00:01:11.890
This is another project that
I gave a lightning talk on earlier.
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.
00:01:18.720 --> 00:01:22.000
People wanted to know
when to hack on it.
00:01:22.000 --> 00:01:25.520
Tomorrow at 2 PM, apparently.
00:01:25.520 --> 00:01:28.990
So, the first that I want to say is
I’m a software developer.
00:01:28.990 --> 00:01:33.340
I’m not a hardware designer,
I’m not an FPGA developer,
00:01:33.340 --> 00:01:37.150
I’m not a professional in any of that.
00:01:37.150 --> 00:01:42.920
I develop software for full time.
So this is my hobby.
00:01:42.920 --> 00:01:50.029
As well, this information comes from
a couple of projects that I started
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
00:01:55.260 --> 00:02:00.180
about it because they are too shy
to come up and talk about it themselves.
00:02:00.180 --> 00:02:05.430
So a big thank you to all these people
who have helped me in various ways
00:02:05.430 --> 00:02:09.788
regarding this. And theses slides –
00:02:09.788 --> 00:02:13.700
any of the blue things are links, so
if your playing it along at home
00:02:13.700 --> 00:02:18.840
you can get to them by that URL
and click on these things.
00:02:18.840 --> 00:02:21.700
And there is probably other people I’ve
forgotten, who are not on this list.
00:02:21.700 --> 00:02:24.530
I’m very sorry.
00:02:24.530 --> 00:02:31.980
So this title of this talk could be called
“Software guy tries hardware and complains”.
00:02:31.980 --> 00:02:36.640
I’ve had a really hard time figuring out
what to call this talk.
00:02:36.640 --> 00:02:41.210
And you’ll see some other attempts
of naming this talk better.
00:02:41.210 --> 00:02:48.379
So a bit of history.
How do I end up doing HDMI stuff?
00:02:48.379 --> 00:02:55.840
So TimVideos is a group of projects
which are trying to make it easy
00:02:55.840 --> 00:03:02.780
to record and live-stream user groups
and conferences like this event.
00:03:02.780 --> 00:03:07.400
However, we want to do it without
needing the awesome team
00:03:07.400 --> 00:03:09.750
that is doing the recording here.
00:03:09.750 --> 00:03:12.950
These guys are really, really organized
and professional.
00:03:12.950 --> 00:03:18.710
We want to do it where people have
no experience at all with AV,
00:03:18.710 --> 00:03:22.110
and just can make it happen.
00:03:22.110 --> 00:03:28.930
And so this is how you record
a conference or user group.
00:03:28.930 --> 00:03:31.750
I’m gonna be talking about
these two things here,
00:03:31.750 --> 00:03:35.519
the HDMI2USB devices that we created.
00:03:35.519 --> 00:03:43.239
They are used in our setup both for
camera capture and for capture of slides.
00:03:43.239 --> 00:03:48.680
And so HDMI2USB is FOSS hardware
for doing HDMI capture
00:03:48.680 --> 00:03:54.880
and actually has a bit of history
with the CCC
00:03:54.880 --> 00:04:00.700
because it was inspired by
a speaker who spoke here.
00:04:00.700 --> 00:04:06.139
Bunnie spoke on his NeTV board
00:04:06.139 --> 00:04:08.830
which was an FPGA Man-in-the-Middle attack
00:04:08.830 --> 00:04:14.239
on HDCP-secured links. His talk
is really awesome. It’s gonna be…
00:04:14.239 --> 00:04:17.488
that talk is way more technical
than mine and gives you
00:04:17.488 --> 00:04:22.460
some really awesome details about the
cool things he did to make that work.
00:04:22.460 --> 00:04:26.990
Mine is much more basic. You don’t
need much experience with HDMI
00:04:26.990 --> 00:04:32.969
to follow my talk.
Our device works like his does,
00:04:32.969 --> 00:04:38.740
except his was deliberately designed
to not allow capture,
00:04:38.740 --> 00:04:41.669
our design allows capture.
It effectively man-in-the-middles
00:04:41.669 --> 00:04:46.949
the presenters projector,
between the presenters laptop
00:04:46.949 --> 00:04:54.859
and the projector, and provides
a high-quality capture out the USB2 port.
00:04:54.859 --> 00:04:58.680
I use an FPGA to do that.
This is because
00:04:58.680 --> 00:05:03.169
using FPGA makes hardware problems
software problems, and as I said
00:05:03.169 --> 00:05:09.110
I’m a software developer, I prefer
software problems to hardware problems.
00:05:09.110 --> 00:05:13.689
And the way it kind of works is
it appears as a UVC webcam so that
00:05:13.689 --> 00:05:17.589
you can use it with Skype or Hangouts
or any of those things without needing
00:05:17.589 --> 00:05:23.650
any drivers on sensible operating
systems like MacOS and Linux.
00:05:23.650 --> 00:05:27.620
On Windows you need a driver that
tells it to use the internal driver.
00:05:27.620 --> 00:05:30.309
It’s kind of weird.
And also a serial port
00:05:30.309 --> 00:05:34.529
because we have the ability to switch
which input goes to which output.
00:05:34.529 --> 00:05:38.610
It’s kind of like a matrix.
00:05:38.610 --> 00:05:42.690
And so this the open source
hardware we designed.
00:05:42.690 --> 00:05:49.159
It’s in KiCAD, you can find it on Github.
00:05:49.159 --> 00:05:52.320
I’m quite proud of it.
It’s quite a good little kit.
00:05:52.320 --> 00:05:58.049
We don’t use all the features of it yet,
but it’s pretty awesome.
00:05:58.049 --> 00:06:00.520
And it’s in use!
00:06:00.520 --> 00:06:05.740
We used this technology to capture
at a bunch of conferences:
00:06:05.740 --> 00:06:09.309
PyCon in Australia,
linux.conf.au in Australia
00:06:09.309 --> 00:06:11.840
– as I said, I’m Australian.
00:06:11.840 --> 00:06:15.059
DebConf, though, are not Australian.
00:06:15.059 --> 00:06:22.789
They used it in – sorry –
in South Africa, I think.
00:06:22.789 --> 00:06:24.969
And there are a whole bunch of
other people around the world
00:06:24.969 --> 00:06:27.639
who are using this,
which is pretty awesome.
00:06:27.639 --> 00:06:31.139
The main reason I wanted it to be
open source was so that
00:06:31.139 --> 00:06:37.229
other people could use them
and learn from them and fix problems,
00:06:37.229 --> 00:06:41.730
because there are a lot of problems
we’ve run into.
00:06:41.730 --> 00:06:44.590
And the other thing is
this is all full of Python.
00:06:44.590 --> 00:06:49.979
We do use Python
00:06:49.979 --> 00:06:54.500
to create the firmware for the FPGA,
and all these other areas.
00:06:54.500 --> 00:06:58.399
If you wanna find out more about that
go to my talk at Python AU
00:06:58.399 --> 00:07:02.679
which was recorded with the very device
I’m talking about.
00:07:02.679 --> 00:07:05.419
microphone noise
Oops, sorry!
00:07:05.419 --> 00:07:11.759
But as I said, this is going
to include a lot of problems.
00:07:11.759 --> 00:07:15.789
The first one is:
People still use VGA!
00:07:15.789 --> 00:07:19.429
This kind of makes me sad.
00:07:19.429 --> 00:07:23.849
Because VGA is not HDMI.
It was invented in 1987
00:07:23.849 --> 00:07:25.960
and it’s an analog signal.
00:07:25.960 --> 00:07:29.709
Well, HDMI shares some history
with VGA.
00:07:29.709 --> 00:07:34.669
You can’t use the same techniques
for capturing HDMI that you can for VGA.
00:07:34.669 --> 00:07:40.729
So why do you still use it?
It’s old and bad!
00:07:40.729 --> 00:07:46.279
We developed a VGA expansion board
to effectively allow us to capture
00:07:46.279 --> 00:07:49.009
VGA using the same thing.
00:07:49.009 --> 00:07:52.699
By ‘developed’ I mean
we have designed, and some exist
00:07:52.699 --> 00:07:55.849
but nobody’s actually finished the
firmware to make them work yet.
00:07:55.849 --> 00:07:59.530
So, I’d love help there.
00:07:59.530 --> 00:08:03.889
There is also another problem:
00:08:03.889 --> 00:08:08.050
I want to do this
all open source, as I said.
00:08:08.050 --> 00:08:12.189
The HDMI ecosystem has
commercial cores you can buy
00:08:12.189 --> 00:08:16.089
and they work reasonably well,
but you have to buy them
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
00:08:19.550 --> 00:08:23.349
you can’t share them with other people.
00:08:23.349 --> 00:08:27.389
As well, I wanted to be open source
because we wanted to solve
00:08:27.389 --> 00:08:31.479
all those problems that people
have when plugging in their laptop
00:08:31.479 --> 00:08:34.320
and it not working.
00:08:34.320 --> 00:08:38.969
And the commercial cores aren’t designed
to allow us to give the ability
00:08:38.969 --> 00:08:46.550
to do that –
solve those problems permanently.
00:08:46.550 --> 00:08:48.500
So we create a new implementation!
00:08:48.500 --> 00:08:52.129
As anybody who has ever done a
reimplementation or a new implementation
00:08:52.129 --> 00:08:59.430
or something, it means that you got
new bugs which I all describe quite a bit.
00:08:59.430 --> 00:09:01.350
So this talk could be called
00:09:01.350 --> 00:09:06.399
‘Debugging HDMI’ rather than
‘Dissecting HDMI’ because it includes
00:09:06.399 --> 00:09:11.590
a lot of information about
how things went wrong.
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.
00:09:16.560 --> 00:09:22.540
So how does HDMI work?
00:09:22.540 --> 00:09:26.480
Well, HDMI is actually reasonably old now.
00:09:26.480 --> 00:09:30.700
It was created in 2002.
00:09:30.700 --> 00:09:37.290
It’s based on the DVI specification.
DVI was created in 1999.
00:09:37.290 --> 00:09:41.279
So DVI is 17 years old.
00:09:41.279 --> 00:09:49.070
And DVI was designed to replace VGA
and shares a lot of similar history.
00:09:49.070 --> 00:09:55.980
HDMI is backwards compatible with DVI
electrically and protocol wise,
00:09:55.980 --> 00:09:58.529
but uses a different connector.
00:09:58.529 --> 00:10:02.750
This is a HDMI connector.
You’ve probably seen them all before.
00:10:02.750 --> 00:10:10.220
If you look closely you see that
there are 19 pins on the HDMI connector.
00:10:10.220 --> 00:10:13.300
That’s Pin 1.
00:10:13.300 --> 00:10:15.350
So what do all this pins do?
00:10:15.350 --> 00:10:18.470
There are five pins
which are used for Ground.
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.
00:10:24.829 --> 00:10:28.410
This isn’t much.
You can’t do much with 50 milliamps
00:10:28.410 --> 00:10:35.779
except maybe some type of adapter,
converter or power a whole microcontroller.
00:10:35.779 --> 00:10:39.290
Some Chinese devices try
to draw like an amp from this.
00:10:39.290 --> 00:10:45.370
That’s not very good. So that’s another
thing you should watch out for.
00:10:45.370 --> 00:10:51.519
There are three high speed data pairs
which transmit the actual video data.
00:10:51.519 --> 00:10:57.730
And they share a clock pair.
So that’s these pins here.
00:10:57.730 --> 00:11:02.369
And then there are five pins
which are used for low speed data.
00:11:02.369 --> 00:11:06.740
So that’s all the pins
on the HDMI connector.
00:11:06.740 --> 00:11:12.740
You might have noticed that there was
a whole bunch of different things
00:11:12.740 --> 00:11:16.629
I said there. And you need to actually
understand a whole bunch
00:11:16.629 --> 00:11:21.510
of different protocols
to understand how HDMI works.
00:11:21.510 --> 00:11:27.710
There is bunch of low speed ones
and there is a bunch of high speed ones.
00:11:27.710 --> 00:11:31.910
I’m not gonna talk
about all of those protocols
00:11:31.910 --> 00:11:35.810
because there is just too many
to go into an hour talk.
00:11:35.810 --> 00:11:38.390
The low speed protocol
I’m not gonna talk about is
00:11:38.390 --> 00:11:42.339
CEC or Audio Return;
and I’m not gonna talk about any of the
00:11:42.339 --> 00:11:48.010
Auxiliary Data protocol
that is high speed, or HDCP.
00:11:48.010 --> 00:11:50.860
If you want HDCP go
and look at bunnie’s talk.
00:11:50.860 --> 00:11:56.320
It’s much better than mine.
But… or ethernet!
00:11:56.320 --> 00:12:02.460
What I will be talking about is
the EDID and DDC protocols,
00:12:02.460 --> 00:12:06.290
The 8b/10b encoding of the pixel data
00:12:06.290 --> 00:12:10.140
and the 2b/10b encoding
of the control data.
00:12:10.140 --> 00:12:14.010
Interesting enough this is actually DVI.
00:12:14.010 --> 00:12:20.740
I’m not telling you about HDMI, I’m
really describing to you how DVI works.
00:12:20.740 --> 00:12:26.190
Again, many titles.
00:12:26.190 --> 00:12:29.690
Starting with the low speed protocol:
00:12:29.690 --> 00:12:33.009
EDID or DDC.
00:12:33.009 --> 00:12:37.789
I’m gonna use these two terms
interchangeably,
00:12:37.789 --> 00:12:40.639
they’ve been so confused now
that they are interchangeable,
00:12:40.639 --> 00:12:43.600
in my opinion.
00:12:43.600 --> 00:12:47.480
This is something they inherited from VGA.
00:12:47.480 --> 00:12:52.929
It was invented and added
to VGA in August 1994.
00:12:52.929 --> 00:12:56.579
It was for plug and play of monitors
so that you could plug in your monitor
00:12:56.579 --> 00:13:02.430
and your graphics card would just work
rather than requiring you to tell
00:13:02.430 --> 00:13:08.050
your graphics card exactly what resolution
and stuff your monitor worked at.
00:13:08.050 --> 00:13:12.879
It uses I2C [I squared C]
and a small EEPROM.
00:13:12.879 --> 00:13:16.290
These are the pins that it uses.
00:13:16.290 --> 00:13:22.620
15 is the Clock pin and
16 is the Data pin,
00:13:22.620 --> 00:13:28.100
and then it uses the Ground, and the
5 Volts is used to power that EEPROM.
00:13:28.100 --> 00:13:32.790
And in some ways it also uses the 19
because 19 is how you detect
00:13:32.790 --> 00:13:37.640
that there is something there
to read from.
00:13:37.640 --> 00:13:40.569
It uses I2C.
00:13:40.569 --> 00:13:46.190
I2C is a low speed protocol that runs
at either 100 kHz or 400 kHz.
00:13:46.190 --> 00:13:50.860
Technically EDID is not I2C,
but it is.
00:13:50.860 --> 00:13:55.850
It only supports the 100 kHz version,
though, in theory,
00:13:55.850 --> 00:13:58.780
everything on this planet
can be read at 400 kHz.
00:13:58.780 --> 00:14:03.029
It is also very well explained elsewhere,
so I’m not going to explain in detail
00:14:03.029 --> 00:14:09.089
what I2C is or does,
or how to implement it.
00:14:09.089 --> 00:14:16.470
The EEPROM is a 24 series.
It’s found at I2C address 50.
00:14:16.470 --> 00:14:21.680
It’s 8 bits in size which gives
you 256 bytes of data.
00:14:21.680 --> 00:14:28.240
Again, this EEPROM and how to talk to it
is very well described on internet.
00:14:28.240 --> 00:14:31.310
So I’m not gonna to describe it here.
If you’ve used EEPROMs
00:14:31.310 --> 00:14:36.430
over I2C it’s likely
you’ve used a 24 series EEPROM.
00:14:36.430 --> 00:14:42.790
Probably bigger ones,
256 bytes is pretty small.
00:14:42.790 --> 00:14:45.930
So like a 16 bits one,
00:14:45.930 --> 00:14:51.899
but EDID supports only
the 8 bits ones.
00:14:51.899 --> 00:14:55.020
The kind of interesting part of EDID
is the data structure:
00:14:55.020 --> 00:14:58.649
it’s a custom binary format that describes
00:14:58.649 --> 00:15:02.040
what the contents of the EEPROM is.
00:15:02.040 --> 00:15:05.410
Again, Wikipedia has a really
good description of this.
00:15:05.410 --> 00:15:07.860
So I’m not gonna go
into much detail.
00:15:07.860 --> 00:15:12.951
But the important thing is that it
describes resolution, frequency
00:15:12.951 --> 00:15:17.589
and format for talking to the monitor.
00:15:17.589 --> 00:15:20.720
This is really important because
if you try and send
00:15:20.720 --> 00:15:25.470
the wrong resolution, frequency or format
the monitor is not gonna understand it.
00:15:25.470 --> 00:15:28.579
This is kind of what EDID is used for.
00:15:28.579 --> 00:15:32.009
sipping, sound of water bottle
00:15:32.009 --> 00:15:38.269
So this is where things
start getting a bit hairy.
00:15:38.269 --> 00:15:42.519
Presenters come up to the front and
the first question you see anybody ask is:
00:15:42.519 --> 00:15:44.600
What resolution do I use?
00:15:44.600 --> 00:15:49.919
And they get a panel like this which
has a bazillion of resolutions selected.
00:15:49.919 --> 00:15:55.379
And the thing is, despite your monitor
saying that it supports
00:15:55.379 --> 00:15:59.920
many formats they lie.
00:15:59.920 --> 00:16:05.279
It turns out that projectors lie
a lot more than normal displays.
00:16:05.279 --> 00:16:08.490
I don’t know why they are special.
00:16:08.490 --> 00:16:11.560
So this is what a supported format
looks like.
00:16:11.560 --> 00:16:14.769
It’s really great.
00:16:14.769 --> 00:16:19.240
As well, I care about
capturing the data.
00:16:19.240 --> 00:16:25.420
And so I want the things
in the format that is
00:16:25.420 --> 00:16:27.229
easy for me to capture.
00:16:27.229 --> 00:16:31.600
I also don’t to be scaling
peoples images and text
00:16:31.600 --> 00:16:34.509
because scaling looks really bad.
So if someone selects
00:16:34.509 --> 00:16:39.889
like a really low resolution and
we scale it up it looks really horrible.
00:16:39.889 --> 00:16:44.300
It makes text unreadable; and
presenters are very denounced,
00:16:44.300 --> 00:16:47.980
especially at technical conferences,
for using tiny, tiny fonts.
00:16:47.980 --> 00:16:51.720
And so we need to use as much
resolution as we can.
00:16:51.720 --> 00:16:55.649
How we solve this is we emulate
our own EEPROM in the FPGA
00:16:55.649 --> 00:16:58.680
and ignore what the projector
tells us it can do.
00:16:58.680 --> 00:17:03.009
We tell the presenter that this is
what we support.
00:17:03.009 --> 00:17:06.689
You might notice that it kind of
solves the problem
00:17:06.689 --> 00:17:10.510
of what resolution we do.
00:17:10.510 --> 00:17:11.809
Offer a single solution…
00:17:11.809 --> 00:17:16.499
offer a single option makes it
very hard to choose the wrong one.
00:17:16.499 --> 00:17:19.839
That’s good! We solved the problem!
00:17:19.839 --> 00:17:22.780
No, we haven’t solved the problem.
00:17:22.780 --> 00:17:25.390
We were recording PyCon AU
and we found that
00:17:25.390 --> 00:17:31.120
some Mac laptops were
refusing to work.
00:17:31.120 --> 00:17:34.570
To understand the cause of this
you need to understand
00:17:34.570 --> 00:17:36.970
a little bit about how the world works.
00:17:36.970 --> 00:17:41.120
There are two major frequencies
in the world: 50 Hz and 60 Hz.
00:17:41.120 --> 00:17:43.799
50 Hz is mainly used
in the “Rest of the World”
00:17:43.799 --> 00:17:47.370
and 60 Hz is used in America
and Japan and a few other places
00:17:47.370 --> 00:17:51.869
but that’s kind of a very rough thing.
00:17:51.869 --> 00:17:54.559
Laptop sold in Australia,
Australia is 50 Hz.
00:17:54.559 --> 00:17:57.980
It’s part of the “Rest of the World”.
You’d think the that the laptop
00:17:57.980 --> 00:18:02.270
could do 50 Hz. Plus everything
is global these days, right?
00:18:02.270 --> 00:18:07.950
I can plug in my power pack
for my laptop in the US or Australia,
00:18:07.950 --> 00:18:11.750
like, it should work everywhere right!
00:18:11.750 --> 00:18:15.200
No. Sad!
00:18:15.200 --> 00:18:19.940
We solved it by claiming
that we were American
00:18:19.940 --> 00:18:24.770
and supporting 60 frames per second
rather than 50 frames per second.
00:18:24.770 --> 00:18:28.400
So I guess a display
with an American accent.
00:18:28.400 --> 00:18:32.700
We deployed this hotfix
on the Friday evening.
00:18:32.700 --> 00:18:37.279
And on Saturday all the problems
that we were having on Friday
00:18:37.279 --> 00:18:41.840
went away. So this is kind of
the power of a open source solution
00:18:41.840 --> 00:18:45.980
and having complete control
over your hardware.
00:18:45.980 --> 00:18:49.820
Nowadays we actually offer both 60 and 50
00:18:49.820 --> 00:18:53.600
because for display capture
if you’re displaying stuff
00:18:53.600 --> 00:19:00.370
at 50 frames per second you’re
probably speaking a lot faster than I am.
00:19:00.370 --> 00:19:05.650
It’s really weird, these
128 bytes are really hard
00:19:05.650 --> 00:19:11.510
and the number one cause
of why a persons laptop
00:19:11.510 --> 00:19:14.880
can’t talk to the projector.
00:19:14.880 --> 00:19:18.240
It gets a trophy!
00:19:18.240 --> 00:19:23.809
To try and figure out why that is
we created EDID.tv.
00:19:23.809 --> 00:19:27.090
It’s supposed to be
a repository of EDID data.
00:19:27.090 --> 00:19:30.880
There is a Summer of Code project,
Python/Django/Bootstrap
00:19:30.880 --> 00:19:34.270
and an EDID grabber tool that
you can run on your laptop.
00:19:34.270 --> 00:19:37.070
I’d love help making this work better.
00:19:37.070 --> 00:19:41.700
Hasn’t had much love since
the Summer of Code student made that work.
00:19:41.700 --> 00:19:45.940
But it would be really nice to have an
open database of everybody’s EDID data
00:19:45.940 --> 00:19:51.250
out there. There are a bunch
of closed ones. I can pay to buy one,
00:19:51.250 --> 00:19:55.630
but I’d really love to have an open one.
00:19:55.630 --> 00:19:59.750
As well maybe we don’t need
the whole capture solution,
00:19:59.750 --> 00:20:02.690
maybe you can just override the EDID.
00:20:02.690 --> 00:20:08.700
The C3VOC here actually developed
a version that overrides EDID for VGA.
00:20:08.700 --> 00:20:12.390
I have a design which works for HDMI.
00:20:12.390 --> 00:20:20.130
It just uses a low cost microprocessor
to pretend to be an EEPROM.
00:20:20.130 --> 00:20:22.890
As well, DisplayPort is not HDMI.
Don’t get these two confused,
00:20:22.890 --> 00:20:25.650
they are very, very different protocols.
00:20:25.650 --> 00:20:29.650
They have an Auxiliary Channel
like EDID and CEC.
00:20:29.650 --> 00:20:34.090
I have boards to decode them
here at CCC.
00:20:34.090 --> 00:20:37.140
So if you’re interested in that
come and talk to me
00:20:37.140 --> 00:20:43.010
because we would really like to do
similar things for DisplayPort.
00:20:43.010 --> 00:20:46.700
That is the slow speed data.
00:20:46.700 --> 00:20:49.929
Sip from bottle
00:20:49.929 --> 00:20:53.100
What about the high speed data?
00:20:53.100 --> 00:20:57.500
Each pixel on your screen is
00:20:57.500 --> 00:21:04.269
basically three colors
in DVI standard: Red, Green, Blue.
00:21:04.269 --> 00:21:07.530
And each one is a byte in size.
00:21:07.530 --> 00:21:15.540
Each of the colors is mapped to
a channel on the HDMI connector.
00:21:15.540 --> 00:21:20.429
You can kind of see the Red and
the Green and the Blue channels.
00:21:20.429 --> 00:21:23.130
Each channel is differential pair.
00:21:23.130 --> 00:21:27.420
You get a Plus and a Negative
and a Shield.
00:21:27.420 --> 00:21:35.460
And they use twisted pair to try
and reduce the noise reception of these,
00:21:35.460 --> 00:21:38.760
because these are quite high speed.
00:21:38.760 --> 00:21:41.860
And they have a dedicated Shield to
try and – again – reduce the noise
00:21:41.860 --> 00:21:47.090
that is captured.
00:21:47.090 --> 00:21:53.139
This is kind of where it gets to
the ‘differential signaling’ part
00:21:53.139 --> 00:21:57.990
of the ‘TMDS’ that is
the kind of code name
00:21:57.990 --> 00:22:05.220
for the internal protocol that is used
on the high speed data.
00:22:05.220 --> 00:22:10.159
They also…
all these channels share a Clock.
00:22:10.159 --> 00:22:13.830
That clock is called the Pixel Clock.
00:22:13.830 --> 00:22:17.169
But each of these channels
is a serial channel.
00:22:17.169 --> 00:22:22.929
It transmits data at 10 bits.
00:22:22.929 --> 00:22:25.659
They… every 10 bits – sorry,
00:22:25.659 --> 00:22:31.620
every clock cycle there are 10 bits of data
transmitted on each of these channels.
00:22:31.620 --> 00:22:34.950
There is a shared clock and
each of the channels is running
00:22:34.950 --> 00:22:39.340
at effectively
ten times that shared clock.
00:22:39.340 --> 00:22:41.970
This is kind of what
the whole system looks like.
00:22:41.970 --> 00:22:45.440
You have your Red, Green, Blue channels.
00:22:45.440 --> 00:22:49.289
You take your 8 bits of input data
on each channel
00:22:49.289 --> 00:22:53.850
and you convert it to the 10 bits
00:22:53.850 --> 00:22:56.710
that we’re going to transmit,
and it goes across the cable
00:22:56.710 --> 00:23:01.169
and then we decode it on the other side.
00:23:01.169 --> 00:23:07.310
The question is: what does
the 8 bit to 10 bit encoding
00:23:07.310 --> 00:23:11.980
look like and how do you understand that.
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.
00:23:17.149 --> 00:23:22.749
This is what it looks like.
Yes… sure…
00:23:22.749 --> 00:23:27.729
…what? This diagram – like –
00:23:27.729 --> 00:23:32.380
I’ve spent hours looking at this,
and it is an extremely hard diagram
00:23:32.380 --> 00:23:38.580
to decode.
It’s very, very hard to understand.
00:23:38.580 --> 00:23:42.750
And it turns out the encoding
protocol is actually quite easy!
00:23:42.750 --> 00:23:47.900
It’s three easy steps – approximately.
00:23:47.900 --> 00:23:52.059
So I’m going to show you all how
to write an encoder or a decoder.
00:23:52.059 --> 00:23:55.279
That diagram is just for the encoder.
00:23:55.279 --> 00:24:00.729
They have a similar diagram that
is not the inverse of this for decoding.
00:24:00.729 --> 00:24:03.980
Again, almost impossible to read.
00:24:03.980 --> 00:24:07.440
The three steps: First we’re
going to do ‘Control’ or ‘Pixel’,
00:24:07.440 --> 00:24:11.260
choose which one to do. Then we’re
going to either encode Control data
00:24:11.260 --> 00:24:15.969
or encode Pixel data.
00:24:15.969 --> 00:24:21.179
A couple of important points
to go through first:
00:24:21.179 --> 00:24:24.480
The Input data
– no matter how wide it is –
00:24:24.480 --> 00:24:29.120
is converted to 10 bit symbols.
00:24:29.120 --> 00:24:32.059
Data goes to symbols.
When we’re talking about them
00:24:32.059 --> 00:24:36.760
being transmitted we talk about them
in symbols, when it’s decoded into pixels
00:24:36.760 --> 00:24:40.130
we talk about them in data.
00:24:40.130 --> 00:24:45.760
As well, things need
to be kept DC-balanced.
00:24:45.760 --> 00:24:48.480
I’ve rushed ahead.
00:24:48.480 --> 00:24:52.850
The question is: “Why 10 bits?”
Our pixels were 8 bits.
00:24:52.850 --> 00:24:56.070
I will explain why
in the Pixel Data section.
00:24:56.070 --> 00:24:59.060
But it’s important that all our symbols
are the same size.
00:24:59.060 --> 00:25:05.159
We’re always transmitting 10 bits
every clock cycle.
00:25:05.159 --> 00:25:08.530
Keeping DC-balanced:
00:25:08.530 --> 00:25:12.879
long runs of 1s and 0s are bad.
00:25:12.879 --> 00:25:15.909
There are lots of reasons for this.
00:25:15.909 --> 00:25:21.809
I tend to think of it like
HDMI isn’t AC coupled
00:25:21.809 --> 00:25:27.280
but you can kind of think of it
like AC coupled.
00:25:27.280 --> 00:25:30.389
It’s not to recover Clock.
00:25:30.389 --> 00:25:35.419
We have a clock pair that is used
to give our Clock signal.
00:25:35.419 --> 00:25:38.059
There are lots of lies on internet
that say that the reason
00:25:38.059 --> 00:25:42.649
we’re going to keep DC balance
is because of Clock.
00:25:42.649 --> 00:25:47.549
But no, that’s not the case.
00:25:47.549 --> 00:25:52.320
So what does DC balance mean?
00:25:52.320 --> 00:25:57.110
A symbol which has lots of 1s
or lots of 0s
00:25:57.110 --> 00:26:00.870
is going to be considered DC-biased
00:26:00.870 --> 00:26:05.270
if it has more 1s than 0s.
00:26:05.270 --> 00:26:08.769
This is kind of what it’s like:
this symbol here
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
00:26:12.530 --> 00:26:16.919
quite a positive bias.
If it was inverse and had lots of 0s
00:26:16.919 --> 00:26:19.509
it would have a negative DC bias.
00:26:19.509 --> 00:26:26.610
That cause… that DC bias over time
causes us problems.
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.
00:26:32.380 --> 00:26:34.429
sound of bottle sip
00:26:34.429 --> 00:26:37.710
The first thing we need to figure out is
are we transmitting Control data
00:26:37.710 --> 00:26:39.940
or Pixel data.
00:26:39.940 --> 00:26:44.010
Turns out that what is happening
in your display is,
00:26:44.010 --> 00:26:47.089
we are transmitting something
that’s actually bigger
00:26:47.089 --> 00:26:50.909
than what you
see on your screen.
00:26:50.909 --> 00:26:57.370
This not the scale. The Control data
periods are much, much smaller.
00:26:57.370 --> 00:27:06.230
The Control data is in orange
and the Pixel data is in purple-pink.
00:27:06.230 --> 00:27:12.260
So why does this exist?
It exists because of old CRT monitors.
00:27:12.260 --> 00:27:16.620
And for those in the audience
who where kind of born after CRT monitors,
00:27:16.620 --> 00:27:19.720
this is what they look like.
00:27:19.720 --> 00:27:23.350
The way they work is,
they have an electron beam
00:27:23.350 --> 00:27:27.919
that scans across,
highlighting the phosphorus.
00:27:27.919 --> 00:27:34.620
This electron beam can’t just be…
get back to other side of the screen
00:27:34.620 --> 00:27:39.049
straight away, or get back to the top of
the screen. And so these periods
00:27:39.049 --> 00:27:43.639
where we are transmitting Control data
was to allow the electron beam
00:27:43.639 --> 00:27:47.470
to get back to the location
where it needed to start
00:27:47.470 --> 00:27:53.160
transmitting the next set of data.
00:27:53.160 --> 00:27:56.079
That’s why it exists.
Why do we care?
00:27:56.079 --> 00:27:59.090
Because the encoding schemes
for Control and Pixel data
00:27:59.090 --> 00:28:03.820
are actually quite different.
00:28:03.820 --> 00:28:07.150
This is the main difference.
I’m going to come back to this slide
00:28:07.150 --> 00:28:11.509
a bit later. But again, the
important thing to see here is
00:28:11.509 --> 00:28:15.300
that despite the encoding scheme
being quite different
00:28:15.300 --> 00:28:21.630
the output is 10 bits in size.
00:28:21.630 --> 00:28:25.389
That first step – choosing whether
it’s Pixel or Control data –
00:28:25.389 --> 00:28:30.110
is described by this bit of the diagram.
You might notice that’s
00:28:30.110 --> 00:28:34.309
not the first thing in the diagram.
00:28:34.309 --> 00:28:37.900
How do you convert Control data
to Control symbols?
00:28:37.900 --> 00:28:41.419
First we need to know what
Control data is. There are two bits,
00:28:41.419 --> 00:28:44.500
there is the HSync and the VSync signal.
00:28:44.500 --> 00:28:51.269
They provide basically
the horizontal and vertical pixel sizes.
00:28:51.269 --> 00:28:55.460
They are kind of left over from VGA.
We don’t actually need them
00:28:55.460 --> 00:29:01.100
in HDMI or DVI to know
where the edges are
00:29:01.100 --> 00:29:06.710
because we can tell the difference
between Control and Pixel data.
00:29:06.710 --> 00:29:11.890
But they kind of still exist
because of backwards compatibility.
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.
00:29:15.860 --> 00:29:22.409
So, a 2b/10b scheme.
00:29:22.409 --> 00:29:27.270
How they do it is they just hand-picked
four symbols that were going to be
00:29:27.270 --> 00:29:30.380
these Control data symbols.
00:29:30.380 --> 00:29:35.020
These are the four symbols. There’s
some interesting properties with them.
00:29:35.020 --> 00:29:38.720
They are chosen to be DC-balanced.
They roughly have the same number
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.
00:29:46.870 --> 00:29:51.740
They are also chosen to have
seven or more transitions from 0 to 1
00:29:51.740 --> 00:29:58.610
in them. This number of transitions
00:29:58.610 --> 00:30:03.230
is used to understand
the phase relationship
00:30:03.230 --> 00:30:07.020
of the different channels.
So if you remember this diagram,
00:30:07.020 --> 00:30:12.950
we have a cable going between
the transmitter and the transceiver.
00:30:12.950 --> 00:30:16.360
These are, again, very high speed signals.
00:30:16.360 --> 00:30:22.130
And even if the transmitter was
transmitting everything at the same time,
00:30:22.130 --> 00:30:28.240
the cable isn’t ideal and might
delay some of the symbols.
00:30:28.240 --> 00:30:32.880
The bits on one channel
[might take] longer than others.
00:30:32.880 --> 00:30:37.320
By having lots of these transmissions
we can actually find
00:30:37.320 --> 00:30:41.590
the phase relationship between
each of the channels and then
00:30:41.590 --> 00:30:47.559
recover the data. And so
that’s why these Control symbols
00:30:47.559 --> 00:30:52.400
have a large number
of transitions in them.
00:30:52.400 --> 00:30:56.750
More on that later when we get to the
implementation. And I’m running out’ time.
00:30:56.750 --> 00:31:01.159
This part of the diagram is the
Control data encoding.
00:31:01.159 --> 00:31:04.190
sip from bottle
00:31:04.190 --> 00:31:06.990
What about Pixel data
and the Pixel symbols?
00:31:06.990 --> 00:31:13.740
Again, in DVI each channel
of the Pixel is 8 bits.
00:31:13.740 --> 00:31:17.199
And the encoding scheme is described
by the rest of the diagram.
00:31:17.199 --> 00:31:22.480
But again, it’s actually
really, really simple.
00:31:22.480 --> 00:31:26.520
This encoding scheme is called 8b/10b,
00:31:26.520 --> 00:31:30.030
because it takes 8 bits
converting it to 10 bits.
00:31:30.030 --> 00:31:33.880
However, there is a huge danger
here because IBM also invented
00:31:33.880 --> 00:31:37.480
the 8b/10b scheme
that is used in everything.
00:31:37.480 --> 00:31:41.080
This is used in DisplayPort, it’s used
in PCI Express, it’s used in SATA,
00:31:41.080 --> 00:31:43.929
it’s used in pretty much everything
on the planet.
00:31:43.929 --> 00:31:48.259
This is not the encoding TDMS uses.
00:31:48.259 --> 00:31:52.490
You can lose a lot of time
trying to map this diagram
00:31:52.490 --> 00:31:56.560
to the IBM coding scheme,
and going these are not the same.
00:31:56.560 --> 00:32:03.490
That is because they’re not the same.
This is a totally different coding scheme.
00:32:03.490 --> 00:32:07.570
Encoding Pixel data is a two-step process.
I did say it was three-ish steps
00:32:07.570 --> 00:32:12.270
to do this.
The first step is we want to reduce
00:32:12.270 --> 00:32:18.110
the transitions in the data.
00:32:18.110 --> 00:32:20.429
How do we do this? –
Sorry, why do we do this?
00:32:20.429 --> 00:32:23.570
Because this, again, is
a high speed channel.
00:32:23.570 --> 00:32:27.529
We want to reduce the cross-talk
between the lanes.
00:32:27.529 --> 00:32:30.669
They are actually quite close
to each other.
00:32:30.669 --> 00:32:34.779
So by reducing the number
of transitions we can reduce
00:32:34.779 --> 00:32:40.130
the probability that the signal propagates
00:32:40.130 --> 00:32:45.760
from one channel to the next.
And how we do it?
00:32:45.760 --> 00:32:49.789
We’re gonna choose one
of two encoding schemes.
00:32:49.789 --> 00:32:54.000
An XOR encoding scheme
or an XNOR encoding scheme.
00:32:54.000 --> 00:32:57.740
How do we do the XOR encoding scheme?
It’s actually pretty simple.
00:32:57.740 --> 00:33:00.679
We set the Encoded Bit
same as the first Data Bit
00:33:00.679 --> 00:33:04.310
and then the next Encoded Bit
is the first Encoded Bit
00:33:04.310 --> 00:33:09.649
XORed with the Data bit.
00:33:09.649 --> 00:33:14.000
And then we just repeat until
we’ve done the 8 bits.
00:33:14.000 --> 00:33:16.159
So this is how we do the XOR encoding.
00:33:16.159 --> 00:33:20.149
The XNOR encoding is the same process,
except instead of using XOR
00:33:20.149 --> 00:33:24.500
it uses XNOR.
00:33:24.500 --> 00:33:29.210
How do we choose
which one of these to use?
00:33:29.210 --> 00:33:35.019
If the Input Data byte
has fewer than four 1s
00:33:35.019 --> 00:33:39.919
we use the XOR. If it has more
than four 1s we use the XNOR.
00:33:39.919 --> 00:33:43.059
And then there’s a tie-break (?)
if you have even.
00:33:43.059 --> 00:33:47.850
The important thing here is that this
method is determined by the Data byte only.
00:33:47.850 --> 00:33:53.000
There is no hidden state here
or continuous change.
00:33:53.000 --> 00:33:59.710
Every pixel has a one-to-one
mapping to an encoding.
00:33:59.710 --> 00:34:04.260
Then we append a bit
on the end that indicates
00:34:04.260 --> 00:34:09.030
whether we chose XOR,
XNOR encoding of that data.
00:34:09.030 --> 00:34:15.219
And so that converts
our 8 bits Input Pixels
00:34:15.219 --> 00:34:21.500
to 9 bits of encoded data, effectively
our 8-bit encoded sequence
00:34:21.500 --> 00:34:27.720
and then one bit to indicate whether
we chose XOR, or XNOR encoding
00:34:27.720 --> 00:34:34.239
for that Data bit. So that’s it there.
00:34:34.239 --> 00:34:38.060
This encoding is actually very good
at reducing transitions.
00:34:38.060 --> 00:34:43.520
On average, we had roughly
eight transitions previously,
00:34:43.520 --> 00:34:48.900
now we have roughly three-ish,
so it’s pretty cool.
00:34:48.900 --> 00:34:51.220
I have no idea how they figured this out.
00:34:51.220 --> 00:34:55.570
I’m assuming some very smart
mathematicians where involved
00:34:55.570 --> 00:35:00.330
because discovering this is beyond me.
00:35:00.330 --> 00:35:02.280
And that describes the top part
of this process.
00:35:02.280 --> 00:35:04.410
sounds of scratching nose and beard
00:35:04.410 --> 00:35:11.660
This is where, in the TMDS, the
Transition Minimization comes from,
00:35:11.660 --> 00:35:14.220
that step there in the encoding process.
00:35:14.220 --> 00:35:16.310
But there is still one more step.
00:35:16.310 --> 00:35:22.370
We need to keep the channel
DC-balanced, as I explained earlier.
00:35:22.370 --> 00:35:27.860
How can we do that? Because
not all pixels are guaranteed to be
00:35:27.860 --> 00:35:32.160
at zero DC bias
like the Control symbols are.
00:35:32.160 --> 00:35:37.320
We do it by keeping a running count
of the DC bias we have,
00:35:37.320 --> 00:35:41.500
and then, if we have a positive DC bias
00:35:41.500 --> 00:35:45.890
and the symbol is also
positively biased, we invert it.
00:35:45.890 --> 00:35:51.770
Or, if we have a negative DC bias
and the symbol has a negative DC bias,
00:35:51.770 --> 00:35:55.910
we invert it.
And the reason we do this is
00:35:55.910 --> 00:36:00.830
because when we invert a symbol we
convert all the 1s to 0s which means
00:36:00.830 --> 00:36:05.790
a negative DC bias
becomes a positive DC bias.
00:36:05.790 --> 00:36:10.800
As I said, we chose – because we are already
negative and the thing was negative –
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
00:36:17.940 --> 00:36:22.620
back towards zero.
We might overshoot, but the next stage
00:36:22.620 --> 00:36:27.100
we’ll keep trying to oscillate up and
down, and on average over time
00:36:27.100 --> 00:36:31.380
we keep a DC bias of zero.
00:36:31.380 --> 00:36:36.870
And as I said. Then, to indicate
whether or not we inverted
00:36:36.870 --> 00:36:42.740
or kept… the…
straight through we inverted,
00:36:42.740 --> 00:36:48.080
we add another bit on the end.
So that’s how get our 10 bit
00:36:48.080 --> 00:36:53.780
encoding scheme.
We have the 8 bits of encoded data,
00:36:53.780 --> 00:36:58.800
then one bit indicating whether or not
it used XOR/XNOR encoding,
00:36:58.800 --> 00:37:04.030
and then one bit to indicate whether
or not we inverted the symbol.
00:37:04.030 --> 00:37:09.970
That describes this bottom part
of the chart.
00:37:09.970 --> 00:37:14.510
Now you can see partly
why this chart is kind of confusing.
00:37:14.510 --> 00:37:18.840
It’s no way in what I think
of a what’s a logical diagram.
00:37:18.840 --> 00:37:21.610
This might be how you implement it
in hardware if you really understand
00:37:21.610 --> 00:37:28.990
the protocol, but not a very good diagram
for explaining what’s going on. And…
00:37:28.990 --> 00:37:31.590
sip from bottle
00:37:31.590 --> 00:37:34.190
As you see it’s actually pretty simple.
00:37:34.190 --> 00:37:40.360
In summary this is
the interesting information
00:37:40.360 --> 00:37:45.390
about the two different encoding schemes.
00:37:45.390 --> 00:37:49.350
Because we minimized
the transitions in the Pixel data
00:37:49.350 --> 00:37:53.020
we can actually tell
Control and Pixel data apart
00:37:53.020 --> 00:37:56.360
by looking at how many transitions
are in the symbol.
00:37:56.360 --> 00:38:00.840
If it has six or more transitions
it must be a Control symbol.
00:38:00.840 --> 00:38:06.040
If it has four or less
it must be a Pixel symbol.
00:38:06.040 --> 00:38:09.610
You now know
how to encode TDMS data
00:38:09.610 --> 00:38:12.290
and how to decode TDMS data
00:38:12.290 --> 00:38:18.070
because if you want to decode
you just do the process backwards.
00:38:18.070 --> 00:38:25.480
Congratulations!
How do you actually implement this?
00:38:25.480 --> 00:38:28.290
You can just write the XOR logic
00:38:28.290 --> 00:38:31.252
and a little counter
that keeps track of the DC bias
00:38:31.252 --> 00:38:34.780
and all that type of thing
in FPGA.
00:38:34.780 --> 00:38:38.690
I’m not going to describe that
because I don’t have much time.
00:38:38.690 --> 00:38:43.130
But if you followed the process
that I have given you
00:38:43.130 --> 00:38:45.980
it should be pretty easy.
00:38:45.980 --> 00:38:50.990
But… and this is what we use currently.
00:38:50.990 --> 00:38:53.700
You could actually use a lookup table.
What we are doing is
00:38:53.700 --> 00:38:58.380
converting 8 bits of data
to 10 bits of data.
00:38:58.380 --> 00:39:03.760
That is a lookup table process,
pretty easy.
00:39:03.760 --> 00:39:08.900
FPGAs are really good at
doing ‘lookup table’-type processes,
00:39:08.900 --> 00:39:13.010
and it also allows you then
to extend this system
00:39:13.010 --> 00:39:18.150
to those other protocols
like the 4b/10b that is used
00:39:18.150 --> 00:39:20.890
for the Auxiliary data.
00:39:20.890 --> 00:39:24.770
So we are looking at that in the future.
It uses a few more resources
00:39:24.770 --> 00:39:28.020
but it’s a lot more powerful.
00:39:28.020 --> 00:39:32.790
This is kind of what your encoder
will look like, and your decoder.
00:39:32.790 --> 00:39:36.650
It’s quite simple,
it takes in your 10 bits of data
00:39:36.650 --> 00:39:39.400
and outputs either
your 8 bits of Pixel data
00:39:39.400 --> 00:39:43.700
or your 2 bits of Control data
and the data type.
00:39:43.700 --> 00:39:47.190
This is kind of what if you went
into our design and looked at it
00:39:47.190 --> 00:39:49.570
at high level, in the schematic,
00:39:49.570 --> 00:39:52.220
you’d probably see a block
that looks like this.
00:39:52.220 --> 00:39:56.430
The encoder is slightly more complicated
because you also have the DC bias count
00:39:56.430 --> 00:40:00.990
that you have to keep track of.
But, again,
00:40:00.990 --> 00:40:03.720
the data goes in
and the data comes out.
00:40:03.720 --> 00:40:08.810
That’s simple, right?
00:40:08.810 --> 00:40:12.260
This kind of extends to Auxiliary data,
or if you get an error,
00:40:12.260 --> 00:40:15.490
like if you…
There are 124 symbols
00:40:15.490 --> 00:40:18.930
that you can have in 10 bits of data.
00:40:18.930 --> 00:40:22.160
Not all of them are valid.
So if you get one of these invalid symbols
00:40:22.160 --> 00:40:25.770
you know you have an error.
00:40:25.770 --> 00:40:30.270
However, things happen quite quickly
00:40:30.270 --> 00:40:34.520
when you times them by ten.
And so our Pixel Clock
00:40:34.520 --> 00:40:39.150
for 640x480 is 25 MHz.
When you times that by ten
00:40:39.150 --> 00:40:45.000
you get 250 MBits per channel.
When you’re doing 720p
00:40:45.000 --> 00:40:48.580
you’re doing 750 MBits per channel.
00:40:48.580 --> 00:40:53.810
And 1080p is at 1500 MBits per channel.
00:40:53.810 --> 00:40:59.080
An FPGA is fast, but
they’re not really that fast
00:40:59.080 --> 00:41:03.950
at a range that I can afford to buy.
I’m sure the military has ones
00:41:03.950 --> 00:41:08.480
that go this fast, but
I’m not as rich as them.
00:41:08.480 --> 00:41:12.180
But they do include a nice hack
to solve this.
00:41:12.180 --> 00:41:15.310
They are called SerDes.
They basically turn parallel data
00:41:15.310 --> 00:41:18.790
into serial data.
00:41:18.790 --> 00:41:21.830
This is what the boxes look like.
00:41:21.830 --> 00:41:24.230
You give them your TDMS parallel data
00:41:24.230 --> 00:41:27.940
and they convert it to
high speed serial data for you.
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
00:41:32.540 --> 00:41:37.400
a person who has already configured this
for your FPGA
00:41:37.400 --> 00:41:39.900
and follow what they do.
00:41:39.900 --> 00:41:44.430
“Hamster” – Mike “Hamster” Field – has
a really good documentation on
00:41:44.430 --> 00:41:49.940
how to use these in a Spartan6.
These are also unique to your FPGA,
00:41:49.940 --> 00:41:54.140
so different FPGAs are going to have
different control schemes.
00:41:54.140 --> 00:41:56.900
But if you are using a Spartan6
00:41:56.900 --> 00:42:02.390
then go and look up what
Mike “Hamster” Field is
00:42:02.390 --> 00:42:07.770
doing for configuring these.
00:42:07.770 --> 00:42:14.190
Remember how I said,
our system has a serial console.
00:42:14.190 --> 00:42:18.630
Because we have that system
we can actually delve quite deep
00:42:18.630 --> 00:42:22.910
into what’s happening
internally in the system.
00:42:22.910 --> 00:42:25.110
sip from bottle
00:42:25.110 --> 00:42:32.920
And print it out.
This is debugging from one of our systems.
00:42:32.920 --> 00:42:35.140
You can see…
00:42:35.140 --> 00:42:40.550
The first thing is the phase relationship
between each of the channels.
00:42:40.550 --> 00:42:44.790
The next one is whether
we’re getting valid data
00:42:44.790 --> 00:42:49.770
on each of the channels and then
we’ve got the error rate for that channel,
00:42:49.770 --> 00:42:54.370
whether all channels synchronized,
and then some resolution information.
00:42:54.370 --> 00:43:00.200
You can see that this has got
a 74 MHz Pixel Clock.
00:43:00.200 --> 00:43:05.080
There are three columns because
there is Red, Green and Blue channels.
00:43:05.080 --> 00:43:09.230
This give us some very interesting
debugging capabilities.
00:43:09.230 --> 00:43:13.210
If you plug in a cable
and you’re getting errors
00:43:13.210 --> 00:43:17.240
on the Blue channel and nowhere else
00:43:17.240 --> 00:43:21.560
it’s highly likely there’s
something wrong with that cable.
00:43:21.560 --> 00:43:25.500
This is a very powerful tool
that allows us to figure out
00:43:25.500 --> 00:43:29.740
what’s going wrong in a system.
00:43:29.740 --> 00:43:35.270
It’s something you can’t really get
with the commercial versions of this.
00:43:35.270 --> 00:43:39.060
But what about errors?
Everything I’m talking about now
00:43:39.060 --> 00:43:42.040
is a little bit experimental,
we haven’t actually implemented this.
00:43:42.040 --> 00:43:45.700
But it’s some ideas about
what we can do because we now
00:43:45.700 --> 00:43:49.590
have complete control of our decoder.
00:43:49.590 --> 00:43:54.220
As I said, there’s 124 possible choices
for 10 bit symbols,
00:43:54.220 --> 00:43:58.220
of which 460 are valid Pixel symbols,
00:43:58.220 --> 00:44:02.390
4 are valid Control symbols
and 560 symbols
00:44:02.390 --> 00:44:05.060
should never ever be seen no matter what.
00:44:05.060 --> 00:44:11.890
That’s like 56% of our space
that should never be seen.
00:44:11.890 --> 00:44:16.330
But it’s actually better than that!
We know because of the running DC bias
00:44:16.330 --> 00:44:25.050
that there are 256 valid Pixel symbols
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
00:44:31.150 --> 00:44:37.240
you can’t have a Pixel symbol
which continues to drive you negative.
00:44:37.240 --> 00:44:43.710
Actually, 74% of our space at any time
00:44:43.710 --> 00:44:48.030
is not allowed to exist.
00:44:48.030 --> 00:44:52.070
This means that a huge number
of the invalid symbols
00:44:52.070 --> 00:44:56.180
are only near one other valid symbol.
00:44:56.180 --> 00:45:01.530
And so we can actually correct them!
We can go: “This symbol must have been
00:45:01.530 --> 00:45:04.950
this other symbol,
because it’s not a valid symbol,
00:45:04.950 --> 00:45:08.840
it must be a bit error
from this other symbol.”
00:45:08.840 --> 00:45:12.870
So we can correct these errors.
This is quite cool.
00:45:12.870 --> 00:45:19.030
We can correct about 70% of
00:45:19.030 --> 00:45:21.970
single bit flip errors in Pixel data.
00:45:21.970 --> 00:45:28.510
But sadly there is some that we can’t.
00:45:28.510 --> 00:45:34.960
But we can detect that we got
a invalid Pixel data.
00:45:34.960 --> 00:45:40.320
So the fact that there is an error
is important.
00:45:40.320 --> 00:45:43.910
In this case we’ve got two pixels
that we received correctly
00:45:43.910 --> 00:45:49.030
and we got a pixel that we know
is a invalid value
00:45:49.030 --> 00:45:53.550
and then two more pixels
that we received correctly.
00:45:53.550 --> 00:45:55.180
You can imagine this is a Blue channel,
00:45:55.180 --> 00:45:59.040
so the first ones were not very blue.
00:45:59.040 --> 00:46:03.010
Then there’s the decoded value for this is
00:46:03.010 --> 00:46:07.290
very, very blue, like very light blue
and then some other ones.
00:46:07.290 --> 00:46:09.950
This looks really bad, right?
00:46:09.950 --> 00:46:15.480
This was probably a whole blue block.
00:46:15.480 --> 00:46:20.180
One pixel difference
of that big, that size,
00:46:20.180 --> 00:46:24.030
is probably not a valid value,
00:46:24.030 --> 00:46:26.440
and so we can cover them up!
00:46:26.440 --> 00:46:29.680
We can go…
the two pixels on either side
00:46:29.680 --> 00:46:32.320
and average them and fix that pixel.
00:46:32.320 --> 00:46:38.250
This allow us to correct a whole bunch
more of errors that are occurring.
00:46:38.250 --> 00:46:41.460
And as we’re about to take this data
00:46:41.460 --> 00:46:45.940
and run it through a JPEG encoder
00:46:45.940 --> 00:46:49.620
this doesn’t actually affect
the quality of the output
00:46:49.620 --> 00:46:53.150
all that much and allows to fix
things that would otherwise
00:46:53.150 --> 00:46:59.810
be giant glaring glitches in the output.
00:46:59.810 --> 00:47:02.440
That’s some interesting information about
00:47:02.440 --> 00:47:09.490
how you do TDMS decoding
and how we can fix some errors.
00:47:09.490 --> 00:47:12.560
The thing is, we can do it
even better than this
00:47:12.560 --> 00:47:15.530
because it’s an open source project.
00:47:15.530 --> 00:47:19.600
Maybe you have some idea
about how we can improve
00:47:19.600 --> 00:47:22.890
the SerDes performance.
Maybe you have an idea about
00:47:22.890 --> 00:47:28.870
how to do TDMS decoding on
much lower power devices
00:47:28.870 --> 00:47:33.540
than we use. It’s open source!
You can look at the code
00:47:33.540 --> 00:47:39.100
and you can improve it.
And we would love you to do it!
00:47:39.100 --> 00:47:43.450
The thing is that I have a lot of hardware
but not much time.
00:47:43.450 --> 00:47:45.710
If you have lots of time
and not much hardware,
00:47:45.710 --> 00:47:49.940
I think I can solve this problem.
00:47:49.940 --> 00:47:54.790
These are links to the HDMI2USB project
00:47:54.790 --> 00:47:58.840
and the TimVideos project;
and all our code, our hardware,
00:47:58.840 --> 00:48:04.620
everything is on GitHub
under open source licenses.
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.
00:48:11.110 --> 00:48:13.920
You can see these small errors.
00:48:13.920 --> 00:48:16.840
That one was kind of a big error.
00:48:16.840 --> 00:48:25.880
This is what happens when
your DDR memory is slightly broken.
00:48:25.880 --> 00:48:31.800
Yeah…
but – yeah!
00:48:31.800 --> 00:48:35.030
And that is my talk!
00:48:35.030 --> 00:48:42.990
applause
00:48:42.990 --> 00:48:45.250
Herald: Excellent!
Thank you very much, mithro.
00:48:45.250 --> 00:48:48.850
As you’ve noticed, we have a couple of
microphones standing around in the room.
00:48:48.850 --> 00:48:52.960
If you have any questions for mithro
please line up behind the microphones
00:48:52.960 --> 00:48:57.950
and I will allow you to ask the questions.
We have question from the Internet!?
00:48:57.950 --> 00:49:01.700
Signal Angel: Yes, thank you!
Do you know if normal monitors
00:49:01.700 --> 00:49:04.650
do similar error recovery or hiding?
00:49:04.650 --> 00:49:08.910
Tim: I know of no commercial
implementation that does
00:49:08.910 --> 00:49:12.720
any type of error correction.
The solution for the commercial guys
00:49:12.720 --> 00:49:19.840
is to effectively never get errors.
00:49:19.840 --> 00:49:24.170
They can do that because
00:49:24.170 --> 00:49:26.700
they don’t have to deal with
the angry speakers on the ground
00:49:26.700 --> 00:49:30.970
going wild as my slides look weird.
00:49:30.970 --> 00:49:34.760
And, as well, they are probably working
with better quality hardware
00:49:34.760 --> 00:49:39.120
than we are using. We’re trying
to make things as cheap as possible.
00:49:39.120 --> 00:49:43.720
And so we are pushing the boundaries
of a lot of the devices we are using.
00:49:43.720 --> 00:49:48.250
So we are more likely to get
errors than they are.
00:49:48.250 --> 00:49:51.580
Herald: We have quite a lot of questions.
Remember – questions, not comments!
00:49:51.580 --> 00:49:55.520
Microphone number 1, please!
00:49:55.520 --> 00:50:11.260
rustling sound from audience
coughing
00:50:11.260 --> 00:50:12.830
Tim: Yes!
00:50:12.830 --> 00:50:18.180
unrecognizable question from audience
00:50:18.180 --> 00:50:20.920
Sorry, I don’t quite understand
what’s going on! chuckles
00:50:20.920 --> 00:50:27.400
Herald: Do we have a translation?
00:50:27.400 --> 00:50:29.890
Voice from audience: Audio Angel!
00:50:29.890 --> 00:50:34.220
Tim: Audio problem?
00:50:34.220 --> 00:50:45.490
Herald speaks to person
in front of stage in German
00:50:45.490 --> 00:50:51.530
Tim: I’ll be around afterwards,
If you want to chat to me, ahm…
00:50:51.530 --> 00:50:57.110
Herald: And we might do that… ah…
write you on the computer afterwards.
00:50:57.110 --> 00:51:01.530
Second question from
microphone number 3, please!
00:51:01.530 --> 00:51:05.500
Question: Hello? Ah, yes. Can you
determine the quality of a HDMI cable,
00:51:05.500 --> 00:51:08.520
e.g. by measuring bit error rate
of each three pairs
00:51:08.520 --> 00:51:11.350
and also some jitter on the clock,
and that kind of…?
00:51:11.350 --> 00:51:13.970
Tim: Yes we can!
00:51:13.970 --> 00:51:18.100
The quality of a HDMI cable should be
they’re zero bit errors.
00:51:18.100 --> 00:51:23.540
So anything that has non-zero bit errors
we chop up and throw away.
00:51:23.540 --> 00:51:27.870
This gets interesting
when you have very long cables.
00:51:27.870 --> 00:51:31.150
We can actually see that
the longer the cable is
00:51:31.150 --> 00:51:37.160
the harder for them
to keep zero bit errors.
00:51:37.160 --> 00:51:43.230
So yes, we can kind of judge
the quality of the cable.
00:51:43.230 --> 00:51:47.500
But it’s also hard because
00:51:47.500 --> 00:51:51.460
it depends on what the sender is doing.
00:51:51.460 --> 00:51:54.750
If the sender is of a lower quality
00:51:54.750 --> 00:51:58.070
and the cable is low quality
you might get bit errors.
00:51:58.070 --> 00:52:00.400
But if the sender is of a high quality
00:52:00.400 --> 00:52:06.810
and the cable is of a lower quality
00:52:06.810 --> 00:52:11.330
they might cancel each other out
and still be fine.
00:52:11.330 --> 00:52:16.330
We can’t just go: “This is a good cable”
00:52:16.330 --> 00:52:20.880
because we don’t actually have
any control over our…
00:52:20.880 --> 00:52:25.810
how powerful our sender is on this device.
00:52:25.810 --> 00:52:28.040
If we could kind of turn down the sender
00:52:28.040 --> 00:52:31.210
and see where things start going wrong
that would be pretty cool.
00:52:31.210 --> 00:52:34.760
If anybody wants to
look at building such a device
00:52:34.760 --> 00:52:37.910
I’d love to help you do that.
00:52:37.910 --> 00:52:41.300
Herald: We have another question
from microphone number 5.
00:52:41.300 --> 00:52:44.880
Question: Your hardware,
the HDMI2USB hardware…
00:52:44.880 --> 00:52:47.900
Tim: Yes!
Question: Is it available for simply ordering
00:52:47.900 --> 00:52:51.970
or has it to be solder soldered by hand,
or…
00:52:51.970 --> 00:52:56.280
Tim: You can not solder this board by
hand unless you are much, much better
00:52:56.280 --> 00:53:01.790
than I am. It uses Ball Grid Array parts
because it’s an FPGA.
00:53:01.790 --> 00:53:04.530
This is one here.
You can buy them.
00:53:04.530 --> 00:53:10.020
We’re working with a manufacturer in India
who builds them for us.
00:53:10.020 --> 00:53:15.280
We work with them,
and it was pretty awesome.
00:53:15.280 --> 00:53:17.540
We’re also working on new hardware.
I’ve got a whole bunch
00:53:17.540 --> 00:53:21.860
of FPGA hardware here
that you can come and have a look at
00:53:21.860 --> 00:53:25.920
and I’ll probably move it out
into the hallway afterwards.
00:53:25.920 --> 00:53:30.490
Again, if you’re interested
in the hardware and you have a use case,
00:53:30.490 --> 00:53:35.100
chat to me!
Because I like to solve problems
00:53:35.100 --> 00:53:39.460
of people who are not having hardware
and my employer pays me too much.
00:53:39.460 --> 00:53:43.210
So I get to use my discretion refunds
00:53:43.210 --> 00:53:47.710
for helping out people
doing open source stuff.
00:53:47.710 --> 00:53:54.500
applause
00:53:54.500 --> 00:53:59.220
Herald: We have at least four more
questions. Microphone number 2, please!
00:53:59.220 --> 00:54:05.030
Question: Do you think it would be
possible to get an 1080p image
00:54:05.030 --> 00:54:09.780
out of the open source
hardware board you use?
00:54:09.780 --> 00:54:16.960
Tim: Yes, I do, but it requires
us to do some hard work
00:54:16.960 --> 00:54:19.070
that we haven’t had time to do yet.
00:54:19.070 --> 00:54:26.990
And for us 720p at 60 frames
per second is good enough.
00:54:26.990 --> 00:54:32.340
The USB connection
00:54:32.340 --> 00:54:36.290
is limited in bandwidth because
we don’t have an H.264 encoder,
00:54:36.290 --> 00:54:43.020
we only have MJPEG. If somebody wants
to write us a open source, say, WebM
00:54:43.020 --> 00:54:47.000
rather than H.264 encoder
00:54:47.000 --> 00:54:50.710
that might start become more interesting.
We also have ethernet, Gigabit ethernet,
00:54:50.710 --> 00:54:56.470
on this board. It should be pretty ease
to stream the data out the ethernet.
00:54:56.470 --> 00:54:59.140
I, again, need help.
00:54:59.140 --> 00:55:01.700
The ethernet controller works.
We can telnet into the board
00:55:01.700 --> 00:55:07.050
and control it via Telnet.
We just need somebody to
00:55:07.050 --> 00:55:11.470
actually connect the data,
the high speed data side up.
00:55:11.470 --> 00:55:14.780
We use it for debugging and stuff.
00:55:14.780 --> 00:55:18.720
Mike “Hamster” Field again,
really big thank you to him,
00:55:18.720 --> 00:55:22.490
he is an amazing designer,
00:55:22.490 --> 00:55:28.780
he built 1080p60 that is
a little bit out-of-spec
00:55:28.780 --> 00:55:33.120
but actually works really well on hardware
00:55:33.120 --> 00:55:38.870
that is almost identical to ours.
He also did the DisplayPort,
00:55:38.870 --> 00:55:43.490
like a 4k-DisplayPort which
we can do on our board.
00:55:43.490 --> 00:55:49.630
If you only need one or two
of the 1080p things
00:55:49.630 --> 00:55:52.670
DisplayPort connectors can be
converted to HDMI quite easily
00:55:52.670 --> 00:55:56.500
and you can do that on them.
00:55:56.500 --> 00:55:58.850
Yes, I think that’s possible,
but again:
00:55:58.850 --> 00:56:05.900
open source … hobbyist …
need developers …
00:56:05.900 --> 00:56:07.990
Herald: We’ll take one question
from the internet!
00:56:07.990 --> 00:56:12.870
Signal Angel: Thank you. Have you
considered JPEG2000?
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.
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,
00:56:25.780 --> 00:56:30.720
does not support JPEG2000.
00:56:30.720 --> 00:56:34.260
There’s no reason we couldn’t support
JPEG2000 when connected to Linux,
00:56:34.260 --> 00:56:38.770
like we could fix the Linux driver
to add JPEG2000 support.
00:56:38.770 --> 00:56:44.890
Again, I don’t know if there’s any good
open source FPGA implementations
00:56:44.890 --> 00:56:52.670
of JPEG2000? So, that’s also a blocker.
00:56:52.670 --> 00:56:57.500
But if you’re interested in helping out
– come and talk to me.
00:56:57.500 --> 00:57:01.780
As I said, I would very much love
00:57:01.780 --> 00:57:06.600
to chat to you and solve
the problems you’re having
00:57:06.600 --> 00:57:11.540
with getting-going.
As well, we have t-shirts.
00:57:11.540 --> 00:57:16.410
I’m wearing a t-shirt that we have, and
I will send everybody who contributes
00:57:16.410 --> 00:57:23.780
a t-shirt. Whether that’s fixing our
website, helping on documentation,
00:57:23.780 --> 00:57:28.050
helping people on IRC
getting setup, anything.
00:57:28.050 --> 00:57:34.320
You don’t need to be an expert
on FPGA stuff to help out.
00:57:34.320 --> 00:57:38.410
And we also are working on
a little project to run MicroPython
00:57:38.410 --> 00:57:43.160
on FPGAs. So if you’re really into Python
and you like MicroPython
00:57:43.160 --> 00:57:48.060
I would love to help you help us do that.
00:57:48.060 --> 00:57:53.260
It’s kind of working. We just need more
powerful (?) support. So.
00:57:53.260 --> 00:57:56.230
Herald: We have two more questions from
microphone number 1.
00:57:56.230 --> 00:57:59.480
Question: So, is there some sort of
dedicated processor on that board,
00:57:59.480 --> 00:58:02.390
or do you use like a Microblaze
in the FPGA?
00:58:02.390 --> 00:58:06.810
Tim: We use an open source soft core.
One of three.
00:58:06.810 --> 00:58:11.820
We can change which soft core
we’re using with a command line flag.
00:58:11.820 --> 00:58:16.390
We’re using either the LatticeMico32
00:58:16.390 --> 00:58:19.790
which is produced
by Lattice Semiconductor.
00:58:19.790 --> 00:58:24.550
We can use the OpenRISC-1000
00:58:24.550 --> 00:58:28.530
or we can use a RISC-V processor.
00:58:28.530 --> 00:58:34.750
We generally default to LM32
because it’s the most performance
00:58:34.750 --> 00:58:40.430
for least FPGA resource trade-off.
00:58:40.430 --> 00:58:46.240
But if you like RISC-V
or OpenRISC-1000 better
00:58:46.240 --> 00:58:51.920
for some reason, say, you want
to run Linux on our soft core,
00:58:51.920 --> 00:58:58.450
then you can do that. With a one line
command line change, yeah!
00:58:58.450 --> 00:59:03.730
We’re looking at adding
J-Core support in early next year.
00:59:03.730 --> 00:59:07.910
J-Core is quite big, though,
compared to LM32. So,
00:59:07.910 --> 00:59:11.520
it probably won’t fit on some
of the very small devices.
00:59:11.520 --> 00:59:14.270
Question: So it’s a Lattice FPGA?
00:59:14.270 --> 00:59:21.250
Tim: It’s a Spartan6 FPGA. And our new
boards will probably be Artix-7
00:59:21.250 --> 00:59:24.180
But we’re still in the process
of making them exist yet.
00:59:24.180 --> 00:59:25.660
Question: Thanks.
Tim: I’ve also been working with
00:59:25.660 --> 00:59:30.290
bunnie’s NeTV2, porting
our firmware to that,
00:59:30.290 --> 00:59:33.460
which has been really awesome.
He’s doing some cool work there,
00:59:33.460 --> 00:59:39.910
and he’s kind of inspired this whole
development by showing that,
00:59:39.910 --> 00:59:43.420
yes, you could do this,
and you shouldn’t be scared of it.
00:59:43.420 --> 00:59:45.820
Herald: Good, one more question
from microphone number 1.
00:59:45.820 --> 00:59:53.880
Question: Yes. Do you have any plans for
incorporating HD-SDI into your platform?
00:59:53.880 --> 00:59:58.560
Tim: Yes and no!
We have plans and ideas
00:59:58.560 --> 01:00:01.650
that we could do it
01:00:01.650 --> 01:00:07.330
but HD-SDI
01:00:07.330 --> 01:00:13.230
and all of the SDI protocols are
much harder for the consumer,
01:00:13.230 --> 01:00:17.330
generally to access, and we want
to drive the costs of this down
01:00:17.330 --> 01:00:22.070
to as low as it can go. And…
01:00:22.070 --> 01:00:26.060
HDMI is a consumer electronic thing.
You get it on everything.
01:00:26.060 --> 01:00:30.170
You get it on your
like five-buck Raspberry Pi.
01:00:30.170 --> 01:00:35.120
HDMI is probably
a really good solution for this.
01:00:35.120 --> 01:00:38.190
We haven’t developed any SDI cores
or anything like that,
01:00:38.190 --> 01:00:43.330
so I can’t tell you like
that we’re doing anything there
01:00:43.330 --> 01:00:49.460
but if somebody’s interested, again,
I like to remove roll (?) blocks and
01:00:49.460 --> 01:00:53.230
we would love to have people work on that.
01:00:53.230 --> 01:00:56.260
Herald: We have one more question from
the internet and we have two minutes left.
01:00:56.260 --> 01:01:01.810
Signal Angel: OK, thank you. The question
is not related to HDMI but to FPGAs.
01:01:01.810 --> 01:01:06.170
FPGAs are programmed in a high level
language like VERILOG or…
01:01:06.170 --> 01:01:11.030
after simulation you compile. So every
vendor has created his own compiler
01:01:11.030 --> 01:01:15.990
for its own hardware. Are you aware of
a move to open source compilers
01:01:15.990 --> 01:01:21.220
or to independent hardware? And do you see
a benefit in open source FPGA compilers?
01:01:21.220 --> 01:01:27.450
Tim: Yes! If anybody knows
01:01:27.450 --> 01:01:30.590
about FPGAs you know
they use proprietary compilers.
01:01:30.590 --> 01:01:35.510
And these proprietary compilers
are terrible.
01:01:35.510 --> 01:01:39.560
I’m a software engineer.
If I find a bug in gcc
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
01:01:43.750 --> 01:01:47.220
figure out why the hell the bug occurred.
01:01:47.220 --> 01:01:51.600
That is not the case with FPGA compilers.
The FPGA compiler we use
01:01:51.600 --> 01:01:56.970
is non-deterministic. You can give it
the same source code and it produces
01:01:56.970 --> 01:02:01.800
different output. I’d love somebody
to reverse-engineer why that occurs
01:02:01.800 --> 01:02:07.470
because I’ve removed all the randomness
from random sources from it
01:02:07.470 --> 01:02:11.890
and it still manages to do it!
I’m really impressed. So,
01:02:11.890 --> 01:02:16.940
Clifford has done an open source
FPGA tool chain
01:02:16.940 --> 01:02:21.980
for the Lattice iCEstick things.
01:02:21.980 --> 01:02:28.940
He said he’s gonna work
on the Actrix7 FPGAs.
01:02:28.940 --> 01:02:34.180
Please donate to him and help him.
I would… like…
01:02:34.180 --> 01:02:38.030
if that exists I owe people who…
like a bazillion of beers, because
01:02:38.030 --> 01:02:43.270
the sooner I can get off proprietary
tool chains the happier I will be,
01:02:43.270 --> 01:02:48.730
and it will make my hobby so much nicer.
So, please help him!
01:02:48.730 --> 01:02:50.930
Herald: And do give Tim
a big round of applause!
01:02:50.930 --> 01:02:54.510
applause
01:02:54.510 --> 01:02:58.300
postroll music
01:02:58.300 --> 01:03:18.501
subtitles created by c3subtitles.de
in the year 2017. Join, and help us!