0:00:03.959,0:00:08.670
[Music]
0:00:08.670,0:00:21.900
Herald: Has anyone in here ever worked[br]with libusb or PI USB? Hands up. Okay. Who
0:00:21.900,0:00:32.168
also thinks USB is a pain? laughs Okay.[br]Sergey and Alexander were here back in at
0:00:32.168,0:00:38.769
the 26C3, that's a long time ago. I think[br]it was back in Berlin, and back then they
0:00:38.769,0:00:45.120
presented their first homemade, or not[br]homemade, SDR, software-defined radio.
0:00:45.120,0:00:49.440
This year they are back again and they[br]want to show us how they implemented
0:00:49.440,0:00:55.420
another one, using an FPGA, and to[br]communicate with it they used PCI Express.
0:00:55.420,0:01:01.589
So I think if you thought USB was a pain,[br]let's see what they can tell us about PCI
0:01:01.589,0:01:06.690
Express. A warm round of applause for[br]Alexander and Sergey for building a high
0:01:06.690,0:01:12.430
throughput, low latency, PCIe-based[br]software-defined radio
0:01:12.430,0:01:20.220
[Applause][br]Alexander Chemeris: Hi everyone, good
0:01:20.220,0:01:30.280
morning, and welcome to the first day of[br]the Congress. So, just a little bit
0:01:30.280,0:01:36.180
background about what we've done[br]previously and why we are doing what we
0:01:36.180,0:01:42.229
are doing right now, is that we started[br]working with software-defined radios and
0:01:42.229,0:01:51.930
by the way, who knows what software[br]defined radio is? Okay, perfect. laughs
0:01:51.930,0:01:59.140
And who ever actually used a software-[br]defined radio? RTL-SDR or...? Okay, less
0:01:59.140,0:02:06.329
people but that's still quite a lot. Okay,[br]good. I wonder whether anyone here used
0:02:06.329,0:02:16.940
more expensive radios like USRPs? Less[br]people, but okay, good. Cool. So before
0:02:16.940,0:02:22.630
2008 I've had no idea what software-[br]defined radio is, was working with voice
0:02:22.630,0:02:30.330
over IP software person, etc., etc., so I[br]in 2008 I heard about OpenBTS, got
0:02:30.330,0:02:40.080
introduced to software-defined radio and I[br]wanted to make it really work and that's
0:02:40.080,0:02:52.250
what led us to today. In 2009 we had to[br]develop a clock tamer. A hardware which
0:02:52.250,0:03:00.170
allows to use, allowed to use USRP1 to run GSM[br]without problems. If anyone ever tried
0:03:00.170,0:03:05.420
doing this without a good clock source[br]knows what I'm talking about. And we
0:03:05.420,0:03:10.550
presented this - it wasn't an SDR it was[br]just a clock source - we presented this in
0:03:10.550,0:03:18.530
2009 in 26C3.[br]Then I realized that using USRP1 is not
0:03:18.530,0:03:23.760
really a good idea, because we wanted to[br]build a robust, industrial-grade base
0:03:23.760,0:03:29.980
stations. So we started developing our own[br]software defined radio, which we call
0:03:29.980,0:03:41.290
UmTRX and it was in - we started started[br]this in 2011. Our first base stations with
0:03:41.290,0:03:51.590
it were deployed in 2013, but I always[br]wanted to have something really small and
0:03:51.590,0:03:59.510
really inexpensive and back then it wasn't[br]possible. My original idea in 2011, we
0:03:59.510,0:04:07.680
were to build a PCI Express card. Mini,[br]sorry, not PCI Express card but mini PCI
0:04:07.680,0:04:10.100
card.[br]If you remember there were like all the
0:04:10.100,0:04:14.470
Wi-Fi cards and mini PCI form factor and I[br]thought that would be really cool to have
0:04:14.470,0:04:22.490
an SDR and mini PCI, so I can plug this[br]into my laptop or in some embedded PC and
0:04:22.490,0:04:31.710
have a nice SDR equipment, but back then[br]it just was not really possible, because
0:04:31.710,0:04:37.939
electronics were bigger and more power[br]hungry and just didn't work that way, so
0:04:37.939,0:04:49.539
we designed UmTRX to work over gigabit[br]ethernet and it was about that size. So
0:04:49.539,0:04:57.300
now we spend this year at designing[br]something, which really brings me to what
0:04:57.300,0:05:05.289
I wanted those years ago, so the XTRX is a[br]mini PCI Express - again there was no PCI
0:05:05.289,0:05:10.460
Express back then, so now it's mini PCI[br]Express, which is even smaller than PCI, I
0:05:10.460,0:05:17.719
mean mini PCI and it's built to be[br]embedded friendly, so you can plug this
0:05:17.719,0:05:23.669
into a single board computer, embedded[br]single board computer. If you have a
0:05:23.669,0:05:28.020
laptop with a mini PCI Express you can[br]plug this into your laptop and you have a
0:05:28.020,0:05:35.210
really small, software-defined radio[br]equipment. And we really want to make it
0:05:35.210,0:05:39.430
inexpensive, that's why I was asking how[br]many of you have ever worked it with RTL-
0:05:39.430,0:05:44.169
SDR, how many of you ever worked with you[br]USRPs, because the gap between them is
0:05:44.169,0:05:53.740
pretty big and we want to really bring the[br]software-defined radio to masses.
0:05:53.740,0:05:59.550
Definitely won't be as cheap as RTL-SDR,[br]but we try to make it as close as
0:05:59.550,0:06:03.330
possible.[br]And at the same time, so at the size of
0:06:03.330,0:06:09.659
RTL-SDR, at the price well higher but,[br]hopeful hopefully it will be affordable to
0:06:09.659,0:06:17.460
pretty much everyone, we really want to[br]bring high performance into your hands.
0:06:17.460,0:06:22.539
And by high performance I mean this is a[br]full transmit/receive with two channels
0:06:22.539,0:06:28.289
transmit, two channels receive, which is[br]usually called 2x2 MIMO in in the radio
0:06:28.289,0:06:37.370
world. The goal was to bring it to 160[br]megasamples per second, which can roughly
0:06:37.370,0:06:44.110
give you like 120 MHz of radio spectrum[br]available.
0:06:44.110,0:06:53.111
So what we were able to achieve is, again[br]this is mini PCI Express form factor, it
0:06:53.111,0:07:01.639
has small Artix7, that's the smallest and[br]most inexpensive FPGA, which has ability
0:07:01.639,0:07:18.029
to work with a PCI Express. It has LMS7000[br]chip for RFIC, very high performance, very
0:07:18.029,0:07:27.449
tightly embedded chip with even a DSP[br]blocks inside. It has even a GPS chip
0:07:27.449,0:07:37.340
here, you can actually on the right upper[br]side, you can see a GPS chip, so you can
0:07:37.340,0:07:44.060
accually synchronize your SDR to GPS for[br]perfect clock stability,
0:07:44.060,0:07:51.389
so you won't have any problems running any[br]telecommunication systems like GSM, 3G, 4G
0:07:51.389,0:07:58.650
due to clock problems, and it also has[br]interface for SIM cards, so you can
0:07:58.650,0:08:06.330
actually create a software-defined radio[br]modem and run other open source projects
0:08:06.330,0:08:15.840
to build one in a four LT called SRSUI, if[br]you're interested, etc., etc. so really
0:08:15.840,0:08:22.080
really tightly packed one. And if you put[br]this into perspective: that's how it all
0:08:22.080,0:08:30.669
started in 2006 and that's what you have[br]ten years later. It's pretty impressive.
0:08:30.669,0:08:36.840
applause [br]Thanks. But I think it actually applies to
0:08:36.840,0:08:40.320
the whole industry who is working on[br]shrinking the sizes because we just put
0:08:40.320,0:08:48.890
stuff on the PCB, you know. We're not[br]building the silicon itself. Interesting
0:08:48.890,0:08:54.701
thing is that we did the first approach:[br]we said let's pack everything, let's do a
0:08:54.701,0:09:03.180
very tight PCB design. We did an eight[br]layer PCB design and when we send it to a
0:09:03.180,0:09:10.490
fab to estimate the cost it turned out[br]it's $15,000 US per piece. Well in small
0:09:10.490,0:09:18.940
volumes obviously but still a little bit[br]too much. So we had to redesign this and
0:09:18.940,0:09:26.712
the first thing which we did is we still[br]kept eight layers, because in our
0:09:26.712,0:09:32.810
experience number of layers nowadays have[br]only minimal impact on the cost of the
0:09:32.810,0:09:42.450
device. So like six, eight layers - the[br]price difference is not so big. But we did
0:09:42.450,0:09:52.190
complete rerouting and only kept 2-Deep[br]MicroVIAs and never use the buried VIAs.
0:09:52.190,0:09:57.240
So this make it much easier and much[br]faster for the fab to manufacture it and
0:09:57.240,0:10:03.740
the price suddenly went five, six times[br]down and in volume again it will be
0:10:03.740,0:10:18.140
significantly cheaper. And that's just for[br]geek porn how PCB looks inside. So now
0:10:18.140,0:10:25.140
let's go into real stuff. So PCI Express:[br]why did we choose PCI Express? As it was
0:10:25.140,0:10:33.310
said USB is a pain in the ass. You can't[br]really use USB in industrial systems. For
0:10:33.310,0:10:40.510
a whole variety of reasons just unstable.[br]So we did use Ethernet for many years
0:10:40.510,0:10:47.190
successfully but Ethernet has one problem:[br]first of all inexpensive Ethernet is only
0:10:47.190,0:10:51.780
one gigabit and one gigabit does not offer[br]you enough bandwidth to carry all the data
0:10:51.780,0:10:59.720
we want, plus its power-hungry etc. etc.[br]So PCI Express is really a good choice
0:10:59.720,0:11:06.420
because it's low power, it has low[br]latency, it has very high bandwidth and
0:11:06.420,0:11:11.380
it's available almost universally. When we[br]started looking into this we realize that
0:11:11.380,0:11:17.320
even ARM boards, some of ARM boards have[br]PCI Express, mini PCI Express slots, which
0:11:17.320,0:11:26.560
was a big surprise for me for example.[br]So the problems is that unlike USB you do
0:11:26.560,0:11:36.540
need to write your own kernel driver for[br]this and there's no way around. And it is
0:11:36.540,0:11:41.110
really hard to write this driver[br]universally so we are writing it obviously
0:11:41.110,0:11:45.300
for Linux because they're working with[br]embedded systems, but if we want to
0:11:45.300,0:11:51.030
rewrite it for Windows or for macOS we'll[br]have to do a lot of rewriting. So we focus
0:11:51.030,0:11:57.250
on what we want on Linux only right now.[br]And now the hardest part: debugging is
0:11:57.250,0:12:02.580
really non-trivial. One small error and[br]your PC is completely hanged because you
0:12:02.580,0:12:08.750
use something wrong. And you have to[br]reboot it and restart it. That's like
0:12:08.750,0:12:15.500
debugging kernel but sometimes even[br]harder. To make it worse there is no
0:12:15.500,0:12:19.400
really easy-to-use plug-and-play[br]interface. If you want to restart;
0:12:19.400,0:12:24.250
normally, when you when you develop a PCI[br]Express card, when you want when you want
0:12:24.250,0:12:31.050
to restart it you have to restart your[br]development machine. Again not a nice way,
0:12:31.050,0:12:39.420
it's really hard. So the first thing we[br]did is we found, that we can use
0:12:39.420,0:12:47.100
Thunderbolt 3 which is just recently[br]released, and it has ability to work
0:12:47.100,0:12:57.200
directly with PCI Express bus. So it[br]basically has a mode in which it converts
0:12:57.200,0:13:01.410
a PCI Express into plug-and-play[br]interface. So if you have a laptop which
0:13:01.410,0:13:09.450
supports Thunderbolt 3 then you can use[br]this to do plug and play your - plug or
0:13:09.450,0:13:16.480
unplug your device to make your[br]development easier. There are always
0:13:16.480,0:13:23.620
problems: there's no easy way, there's no[br]documentation. Thunderbolt is not
0:13:23.620,0:13:27.380
compatible with Thunderbolt. Thunderbold 3[br]is not compatible with Thunderbold 2.
0:13:27.380,0:13:33.760
So we had to buy a special laptop with[br]Thunderbold 3 with special cables like all
0:13:33.760,0:13:40.120
this all this hard stuff. And if you[br]really want to get documentation you have
0:13:40.120,0:13:47.500
to sign NDA and send a business plan to[br]them so they can approve that your
0:13:47.500,0:13:50.670
business makes sense.[br]laughter
0:13:50.670,0:13:58.640
I mean... laughs So we actually opted[br]out. We set not to go through this, what
0:13:58.640,0:14:05.340
we did is we found that someone is[br]actually making PCI Express to Thunderbolt
0:14:05.340,0:14:10.550
3 converters and selling them as dev[br]boards and that was a big relief because
0:14:10.550,0:14:16.740
it saved us lots of time, lots of money.[br]You just order it from from some from some
0:14:16.740,0:14:24.920
Asian company. And yeah this is how it[br]looks like this converter. So you buy it,
0:14:24.920,0:14:29.970
like several pieces you can plug in your[br]PCI Express card there and you plug this
0:14:29.970,0:14:38.330
into your laptop. And this is the with[br]XTRX already plugged into it. Now the only
0:14:38.330,0:14:50.160
problem we found is that typically UEFI[br]has a security control enabled, so that
0:14:50.160,0:14:56.700
any random thunderbold device can't hijack[br]your PCI bus and can't get access to your
0:14:56.700,0:15:01.740
kernel memory and do some bad stuff. Which[br]is a good idea - the only problem is that
0:15:01.740,0:15:06.730
there is, it's not fully implemented in[br]Linux. So under Windows if you plug in a
0:15:06.730,0:15:11.690
device which is which has no security[br]features, which is not certified, it will
0:15:11.690,0:15:16.510
politely ask you like: "Do you really[br]trust this device? Do you want to use it?"
0:15:16.510,0:15:21.940
you can say "yes". Under Linux it just[br]does not work. laughs So we spend some
0:15:21.940,0:15:25.730
time trying to figure out how to get[br]around this. Right, some patches from
0:15:25.730,0:15:30.370
Intel which are not mainline and we were[br]not able to actually get them work. So we
0:15:30.370,0:15:38.980
just had to disable all this security[br]measure in the laptop. So be aware that
0:15:38.980,0:15:46.610
this is the case and we suspect that happy[br]users of Apple might not be able to do
0:15:46.610,0:15:53.630
this because Apple don't have BIOS so it[br]probably can't disable this feature. So
0:15:53.630,0:16:01.820
probably good incentive for someone to[br]actually finish writing the driver.
0:16:01.820,0:16:08.130
So now to the goal: so we wanted to, we[br]want to achieve 160 mega samples per
0:16:08.130,0:16:13.550
second, 2x2 MIMO, which means two[br]transceiver, two transmit, two receive
0:16:13.550,0:16:24.040
channels at 12 bits, which is roughly 7.5[br]Gbit/s. So first result when we plug this
0:16:24.040,0:16:26.230
when we got this board on the fab it[br]didn't work
0:16:26.230,0:16:30.430
Sergey Kostanbaev mumbles: as expected[br]Alexander Chemeris: yes as expected so the
0:16:30.430,0:16:39.750
first the interesting thing we realized is[br]that: first of all the FPGA has Hardware
0:16:39.750,0:16:47.210
blocks for talking to a PCI Express which[br]was called GTP which basically implement
0:16:47.210,0:16:56.850
like a PCI Express serial physical layer[br]but the thing is the numbering is reversed
0:16:56.850,0:17:04.319
in the in PCI Express in FPGA and we did[br]not realize this so we had to do very very
0:17:04.319,0:17:10.619
fine soldiering to actually swap the[br]laughs swap the lanes you can see this
0:17:10.619,0:17:18.490
very fine work there.[br]We also found that one of the components
0:17:18.490,0:17:28.870
was deadbug which is a well-known term for[br]chips which design stage are placed at
0:17:28.870,0:17:35.960
mirrored so we mirrored occasionally[br]mirrored that they pin out so we had to
0:17:35.960,0:17:41.880
solder it upside down and if you can[br]realize how small it is you can also
0:17:41.880,0:17:49.419
appreciate the work done. And what's funny[br]when I was looking at dead bugs I actually
0:17:49.419,0:17:56.929
found a manual from NASA which describes[br]how to properly soldier dead bugs to get
0:17:56.929,0:18:00.679
it approved.[br]audience laughs
0:18:00.679,0:18:08.230
So this is the link I think you can go[br]there and enjoy it's also fun stuff there.
0:18:08.230,0:18:17.379
So after fixing all of this our next[br]attempt this kind of works. So next stage
0:18:17.379,0:18:23.340
is debugging the FPGA code, which has to[br]talk to PCI Express and PCI Express has to
0:18:23.340,0:18:28.320
talk to Linux kernel and the kernel has to[br]talk to the driver, driver has talked to
0:18:28.320,0:18:37.749
the user space. So peripherals are easy so[br]the UART SPIs we've got to work almost
0:18:37.749,0:18:44.799
immediately no problems with that, but DMA[br]was a real beast. So we spent a lot of
0:18:44.799,0:18:52.660
time trying to get DMA to work and the[br]problem is that with DMA it's on FPGA so
0:18:52.660,0:18:59.730
you can't just place a breakpoint like you[br]do in C or C++ or in other languages it's
0:18:59.730,0:19:07.480
real-time system running on system like[br]it's real-time hardware, which is running
0:19:07.480,0:19:16.351
on the fabric so you we had to Sergey was[br]mainly developing this had to write a lot
0:19:16.351,0:19:22.779
of small test benches and and test[br]everything piece by piece.
0:19:22.779,0:19:31.480
So all parts of the DMA code we had was[br]wrapped into a small test bench which was
0:19:31.480,0:19:39.720
emulating all the all the tricks and as[br]classics predicted it took about five to
0:19:39.720,0:19:47.679
ten times more than actually writing the[br]code. So we really blew up our and
0:19:47.679,0:19:54.529
predicted timelines by doing this, but the[br]end we've got really stable stable work.
0:19:54.529,0:20:03.760
So some suggestions for anyone who will[br]try to repeat this exercise is there is a
0:20:03.760,0:20:09.590
logic analyzer built-in to Xilinx and you[br]can use, it it's nice it's, sometimes it's
0:20:09.590,0:20:15.960
very helpful but you can't debug[br]transient box, which are coming out at
0:20:15.960,0:20:22.990
when some weird conditions are coming up.[br]So you have to implement some read back
0:20:22.990,0:20:28.809
registers which shows important statistic[br]like important data about how your system
0:20:28.809,0:20:35.340
behaves, in our case it's various counters[br]on the DMA interface. So you can actually
0:20:35.340,0:20:40.950
see kind of see what's happening with your[br]with your data: Is it received? Is it
0:20:40.950,0:20:46.269
sent? How much is and how much is[br]received? So like for example, we can see
0:20:46.269,0:20:53.559
when we saturate the bus or when actually[br]is an underrun so host is not providing
0:20:53.559,0:20:57.389
data fast enough, so we can at least[br]understand whether it's a host problem or
0:20:57.389,0:21:01.769
whether it's an FPGA, problem on which[br]part we do we debug next because again:
0:21:01.769,0:21:07.770
it's a very multi layer problem you start[br]with FPGA, PCI Express, kernel, driver,
0:21:07.770,0:21:15.340
user space, and any part can fail. so you[br]can't work blind like this. So again the
0:21:15.340,0:21:23.179
goal was to get 160 MSPS with the first[br]implementation we could 2 MSPS: roughly 60
0:21:23.179,0:21:30.220
times slower.[br]The problem is that software just wasn't
0:21:30.220,0:21:36.149
keeping up and wasn't sending data fast[br]enough. So it was like many things done
0:21:36.149,0:21:41.390
but the most important parts is: use real-[br]time priority if you want to get very
0:21:41.390,0:21:46.940
stable results and well fix software bugs.[br]And one of the most important bugs we had
0:21:46.940,0:21:54.240
was that DMA buffers were not freed in[br]proper time immediately so they were busy
0:21:54.240,0:21:59.429
for longer than they should be, which[br]introduced extra cycles and basically just
0:21:59.429,0:22:06.009
reduced the bandwidth.[br]At this point let's talk a little bit
0:22:06.009,0:22:14.389
about how to implement a high-performance[br]driver for Linux, because if you want to
0:22:14.389,0:22:20.870
get real real performance you have to[br]start with the right design. There are
0:22:20.870,0:22:26.610
basically three approaches and the whole[br]spectrum in between; like two approaches
0:22:26.610,0:22:33.649
and the whole spectrum in between, which[br]is where you can refer to three. The first
0:22:33.649,0:22:41.529
approach is full kernel control, in which[br]case kernel driver not only is on the
0:22:41.529,0:22:45.701
transfer, it actually has all the logics[br]of controlling your device and all the
0:22:45.701,0:22:52.490
export ioctl to the user space and[br]that's the kind of a traditional way of
0:22:52.490,0:22:57.669
writing drivers. Your your user space is[br]completely abstracted from all the
0:22:57.669,0:23:07.029
details. The problem is that this is[br]probably the slowest way to do it. The
0:23:07.029,0:23:14.340
other way is what's called the "zero cup[br]interface": your only control is held in
0:23:14.340,0:23:21.380
the kernel and data is provided, the raw[br]data is provided to user space "as-is". So
0:23:21.380,0:23:27.919
you avoid memory copy which make it[br]faster. But still not fast enough if you
0:23:27.919,0:23:34.279
really want to achieve maximum[br]performance, because you still have
0:23:34.279,0:23:40.980
context switches between the kernel and[br]the user space. The most... the fastest
0:23:40.980,0:23:47.289
approach possible is to have full user[br]space implementation when kernel just
0:23:47.289,0:23:53.059
exposed everything and says "now you do it[br]yourself" and you have no you have no
0:23:53.059,0:24:02.429
context switches, like almost no, and you[br]can really optimize everything. So what
0:24:02.429,0:24:08.850
is... what are the problems with this?[br]The pro the pros I already mentioned: no
0:24:08.850,0:24:13.539
no switches between kernel user space,[br]it's very low latency because of this as
0:24:13.539,0:24:20.980
well, it's very high bandwidth. But if you[br]are not interested in getting the very
0:24:20.980,0:24:27.940
high performance, the most performance, and[br]you just want to have like some little,
0:24:27.940,0:24:33.299
like say low bandwidth performance, then[br]you will have to add hacks, because you
0:24:33.299,0:24:36.710
can't get notifications of the kernel that[br]resources available is more data
0:24:36.710,0:24:45.570
available. It also makes it vulnerable[br]vulnerable because if user space can
0:24:45.570,0:24:55.310
access it, then it can do whatever it[br]want. We at the end decided that... one
0:24:55.310,0:25:02.590
more important thing: how to actually to[br]get the best performance out of out of the
0:25:02.590,0:25:10.299
bus. This is a very (?)(?) set as we want[br]to poll your device or not to poll and get
0:25:10.299,0:25:14.259
notified. What is polling? I guess[br]everyone as programmer understands it, so
0:25:14.259,0:25:18.019
polling is when you asked repeatedly: "Are[br]you ready?", "Are you ready?", "Are you
0:25:18.019,0:25:20.369
ready?" and when it's ready you get the[br]data immediately.
0:25:20.369,0:25:25.259
It's basically a busy loop of your you[br]just constantly asking device what's
0:25:25.259,0:25:33.350
happening. You need to dedicate a full[br]core, and thanks God we have multi-core
0:25:33.350,0:25:39.519
CPUs nowadays, so you can dedicate the[br]full core to this polling and you can just
0:25:39.519,0:25:45.539
pull constantly. But again if you don't[br]need this highest performance, you just
0:25:45.539,0:25:53.190
need to get something, then you will be[br]wasting a lot of CPU resources. At the end
0:25:53.190,0:26:00.429
we decided to do a combined architecture[br]of your, it is possible to pull but
0:26:00.429,0:26:05.500
there's also a chance and to get[br]notification from a kernel to for for
0:26:05.500,0:26:11.049
applications, which recover, which needs[br]low bandwidth, but also require a better
0:26:11.049,0:26:17.480
CPU performance. Which I think is the best[br]way if you are trying to target both
0:26:17.480,0:26:30.850
worlds. Very quickly: the architecture of[br]system. We try to make it very very
0:26:30.850,0:26:50.730
portable so and flexible. There is a[br]kernel driver, which talks to low-level
0:26:50.730,0:26:55.690
library which implements all this logic,[br]which we took out of the driver: to
0:26:55.690,0:27:01.309
control the[br]PCI Express, to work with DMA, to provide
0:27:01.309,0:27:09.360
all the... to hide all the details of the[br]actual bus implementation.
0:27:09.360,0:27:17.169
And then there is a high-level library[br]which talks to this low-level library and
0:27:17.169,0:27:22.179
also to libraries which implement control[br]of actual peripherals, and most
0:27:22.179,0:27:28.919
importantly to the library which[br]implements control over our RFIC chip.
0:27:28.919,0:27:35.119
This way it's very modular, we can replace[br]PCI Express with something else later, we
0:27:35.119,0:27:46.049
might be able to port it to other[br]operating systems, and that's the goal.
0:27:46.049,0:27:50.059
Another interesting issue is: when you[br]start writing the Linux kernel driver you
0:27:50.059,0:27:57.119
very quickly realize that while LDD, which[br]is a classic book for a Linux driver,
0:27:57.119,0:28:02.220
writing is good and it will give you a[br]good insight; it's not actually up-to-
0:28:02.220,0:28:08.609
date. It's more than ten years old and[br]there's all of new interfaces which are
0:28:08.609,0:28:14.809
not described there, so you have to resort[br]to reading the manuals and all the
0:28:14.809,0:28:20.409
documentation in the kernel itself. Well[br]at least you get the up-to-date
0:28:20.409,0:28:31.989
information. The decisions we made is to[br]make everything easy. We use TTY for GPS
0:28:31.989,0:28:38.090
and so you can really attach a pretty much[br]any application which talks to GPS. So all
0:28:38.090,0:28:45.970
of existing applications can just work out[br]of the box. And we also wanted to be able
0:28:45.970,0:28:54.879
to synchronize system clock to GPS, so we[br]get automatic log synchronization across
0:28:54.879,0:28:59.009
multiple systems, which is very important[br]when we are deploying many, many devices
0:28:59.009,0:29:07.090
around the world.[br]We plan to do two interfaces, one as key
0:29:07.090,0:29:15.919
PPS and another is a DCT, because DCT line[br]on the UART exposed over TTY. Because
0:29:15.919,0:29:20.259
again we found that there are two types of[br]applications: one to support one API,
0:29:20.259,0:29:25.539
others that support other API and there is[br]no common thing so we have to support
0:29:25.539,0:29:38.649
both. As we described, we want to have[br]polls so we can get notifications of the
0:29:38.649,0:29:48.130
kernel when data is available and we don't[br]need to do real busy looping all the time.
0:29:48.130,0:29:55.789
After all the software optimizations we've[br]got to like 10 MSPS: still very, very far
0:29:55.789,0:30:02.369
from what we want to achieve.[br]Now there should have been a lot of
0:30:02.369,0:30:06.570
explanations about PCI Express, but when[br]we actually wrote everything we wanted to
0:30:06.570,0:30:13.999
say we realize, it's just like a full two[br]hours talk just on PCI Express. So we are
0:30:13.999,0:30:17.760
not going to give it here, I'll just give[br]some highlights which are most
0:30:17.760,0:30:23.889
interesting. If you if there is real[br]interest, we can set up a workshop and
0:30:23.889,0:30:32.340
some of the later days and talking more[br]details about PCI Express specifically.
0:30:32.340,0:30:38.549
The thing is there is no open source cores[br]for PCI Express, which are optimized for
0:30:38.549,0:30:48.010
high performance, real time applications.[br]There is Xillybus which as I understand is
0:30:48.010,0:30:53.350
going to be open source, but they provide[br]you a source if you pay them. It's very
0:30:53.350,0:30:59.610
popular because it's very very easy to do,[br]but it's not giving you performance. If I
0:30:59.610,0:31:04.980
remember correctly the best it can do is[br]maybe like 50 percent bus saturation.
0:31:04.980,0:31:10.800
So there's also Xilinx implementation, but[br]if you are using Xilinx implementation
0:31:10.800,0:31:21.049
with AXI bus than you're really locked in[br]with AXI bus with Xilinx. And it also not
0:31:21.049,0:31:25.001
very efficient in terms of resources and[br]if you remember we want to make this very,
0:31:25.001,0:31:30.029
very inexpensive. So our goal is to you[br]... is to be able to fit everything in the
0:31:30.029,0:31:38.499
smallest Arctic's 7 FPGA, and that's quite[br]challenging with all the stuff in there
0:31:38.499,0:31:47.649
and we just can't waste resources. So[br]decision is to write your own PCI Express
0:31:47.649,0:31:53.039
implementation. That's how it looks like.[br]I'm not going to discuss it right now.
0:31:53.039,0:31:59.950
There are several iterations. Initially it[br]looked much simpler, turned out not to
0:31:59.950,0:32:06.100
work well.[br]So some interesting stuff about PCI
0:32:06.100,0:32:12.749
Express which we stumbled upon is that it[br]was working really well on Atom which is
0:32:12.749,0:32:17.460
our main development platform because we[br]are doing a lot of embedded stuff. Worked
0:32:17.460,0:32:26.479
really well. When we try to plug this into[br]core i7 just started hanging once in a
0:32:26.479,0:32:35.090
while. So after like several not days[br]maybe with debugging, Sergey found that
0:32:35.090,0:32:39.330
very interesting statement in the standard[br]which says that value is zero in byte
0:32:39.330,0:32:45.869
count actually stands not for zero bytes[br]but for 4096 bytes.
0:32:45.869,0:32:58.739
I mean that's a really cool optimization.[br]So another thing is completion which is a
0:32:58.739,0:33:03.639
term in PCI Express basically for[br]acknowledgment which also can carry some
0:33:03.639,0:33:12.429
data back to your request. And sometimes[br]if you're not sending completion, device
0:33:12.429,0:33:20.740
just hangs. And what happens is that in[br]this case due to some historical heritage
0:33:20.740,0:33:29.549
of x86 it just starts returning you FFF.[br]And if you have a register which says: „Is
0:33:29.549,0:33:35.470
your device okay?“ and this register shows[br]one to say „The device is okay“, guess
0:33:35.470,0:33:38.500
what will happen?[br]You will be always reading that your
0:33:38.500,0:33:46.590
device is okay. So the suggestion is not[br]to use one as the status for okay and use
0:33:46.590,0:33:52.790
either zero or better like a two-beat[br]sequence. So you are definitely sure that
0:33:52.790,0:34:03.659
you are okay and not getting FFF's. So[br]when you have a device which again may
0:34:03.659,0:34:10.440
fail at any of the layers, you just got[br]this new board, it's really hard, it's
0:34:10.440,0:34:17.639
really hard to debug because of memory[br]corruption. So we had a software bug and
0:34:17.639,0:34:25.099
it was writing DMA addresses[br]incorrectly and we were wondering why we
0:34:25.099,0:34:32.179
are not getting any data in our buffers at[br]the same time. After several starts,
0:34:32.179,0:34:41.159
operating system just crashes. Well, that's[br]the reason why there is this UEFI
0:34:41.159,0:34:47.199
protection which prevents you from[br]plugging in devices like this into your
0:34:47.199,0:34:52.270
computer. Because it was basically writing[br]data, like random data into random
0:34:52.270,0:35:00.299
portions of your memory. So a lot of[br]debugging, a lot of tests and test benches
0:35:00.299,0:35:10.589
and we were able to find this. And another[br]thing is if you deinitialize your driver
0:35:10.589,0:35:15.250
incorrectly, and that's what's happening[br]when you have plug-and-play device, which
0:35:15.250,0:35:22.119
you can plug and unplug, then you may end[br]up in a situation of your ... you are
0:35:22.119,0:35:28.039
trying to write into memory which is[br]already freed by approaching system and
0:35:28.039,0:35:35.960
used for something else. Very well-known[br]problem but it also happens here. So there
0:35:35.960,0:35:50.549
... why DMA is really hard is because it[br]has this completion architecture for
0:35:50.549,0:35:56.440
writing for ... sorry ... for reading[br]data. Writes are easy. You just send the
0:35:56.440,0:36:00.460
data, you forget about it. It's a fire-[br]and-forget system. But for reading you
0:36:00.460,0:36:10.420
really need to get your data back. And the[br]thing is, it looks like this. You really
0:36:10.420,0:36:16.020
hope that there would be some pointing[br]device here. But basically on the top left
0:36:16.020,0:36:24.240
you can see requests for read and on the[br]right you can see completion transactions.
0:36:24.240,0:36:29.890
So basically each transaction can be and[br]most likely will be split into multiple
0:36:29.890,0:36:38.900
transactions. So first of all you have to[br]collect all these pieces and like write
0:36:38.900,0:36:46.210
them into proper parts of the memory.[br]But that's not all. The thing is the
0:36:46.210,0:36:53.369
latency between request and completion is[br]really high. It's like 50 cycles. So if
0:36:53.369,0:36:58.990
you have a single, only single transaction[br]in fly you will get really bad
0:36:58.990,0:37:03.900
performance. You do need to have multiple[br]transactions in flight. And the worst
0:37:03.900,0:37:13.170
thing is that transactions can return data[br]in random order. So it's a much more
0:37:13.170,0:37:19.820
complicated state machine than we expected[br]originally. So when I said, you know, the
0:37:19.820,0:37:25.589
architecture was much simpler originally,[br]we don't have all of this and we had to
0:37:25.589,0:37:31.670
realize this while implementing. So again[br]here was a whole description of how
0:37:31.670,0:37:41.200
exactly this works. But not this time. So[br]now after all these optimizations we've
0:37:41.200,0:37:48.859
got 20 mega samples per second which is[br]just six times lower than what we are
0:37:48.859,0:37:59.599
aiming at. So now the next thing is PCI[br]Express lanes scalability. So PCI Express
0:37:59.599,0:38:07.220
is a serial bus. So it has multiple lanes[br]and they allow you to basically
0:38:07.220,0:38:14.350
horizontally scale your bandwidth. One[br]lane is like x, than two lane is 2x, four
0:38:14.350,0:38:20.160
lane is 4x. So the more lanes you have the[br]more performance you are getting out of
0:38:20.160,0:38:23.970
your, out of your bus. So the more[br]bandwidth you're getting out of your bus.
0:38:23.970,0:38:31.700
Not performance. So the issue is that[br]typical a mini PCI Express, so the mini
0:38:31.700,0:38:38.600
PCI Express standard only standardized one[br]lane. And second lane is left as optional.
0:38:38.600,0:38:46.099
So most motherboards don't support this.[br]There are some but not all of them. And we
0:38:46.099,0:38:52.370
really wanted to get this done. So we[br]designed a special converter board which
0:38:52.370,0:38:57.530
allows you to plug your mini PCI Express[br]into a full-size PCI Express and
0:38:57.530,0:39:06.790
get two lanes working. And we're also[br]planning to have a similar board which
0:39:06.790,0:39:12.660
will have multiple slots so you will be[br]able to get multiple XTRX-SDRs on to the
0:39:12.660,0:39:21.270
same, onto the same carrier board and plug[br]this into let's say PCI Express 16x and
0:39:21.270,0:39:29.059
you will get like really a lot of ... SDR[br]... a lot of IQ data which then will be
0:39:29.059,0:39:38.760
your problem how to, how to process. So[br]with two x's it's about twice performance
0:39:38.760,0:39:48.930
so we are getting fifty mega samples per[br]second. And that's the time to really cut
0:39:48.930,0:39:59.230
the fat because the real sample size of[br]LMS7 is 12 bits and we are transmitting 16
0:39:59.230,0:40:06.930
because it's easier. Because CPU is[br]working on 8, 16, 32. So we originally
0:40:06.930,0:40:13.770
designed the driver to support 8 bit, 12[br]bit and 16 bit to be able to do this
0:40:13.770,0:40:23.800
scaling. And for the test we said okay[br]let's go from 16 to 8 bit. We'll lose
0:40:23.800,0:40:32.960
some dynamic range but who cares these[br]days. Still stayed the same, it's still 50
0:40:32.960,0:40:41.980
mega samples per second, no matter what we[br]did. And that was a lot of interesting
0:40:41.980,0:40:49.580
debugging going on. And we realized that[br]we actually made another, not a really
0:40:49.580,0:40:58.720
mistake. We didn't, we didn't really know[br]this when we designed. But we should have
0:40:58.720,0:41:04.450
used a higher voltage for this high speed[br]bus to get it to the full performance. And
0:41:04.450,0:41:12.619
at 1.8 it was just degrading too fast and[br]the bus itself was not performing well. So
0:41:12.619,0:41:21.859
our next prototype will be using higher[br]voltage specifically for this bus. And
0:41:21.859,0:41:26.559
this is kind of stuff which makes[br]designing hardware for high speed really
0:41:26.559,0:41:32.210
hard because you have to care about[br]coherence of the parallel buses on your,
0:41:32.210,0:41:38.550
on your system. So at the same time we do[br]want to keep 1.8 volts for everything else
0:41:38.550,0:41:43.480
as much as possible. Because another[br]problem we are facing with this device is
0:41:43.480,0:41:47.069
that by the standard mini PCI Express[br]allows only like ...
0:41:47.069,0:41:51.220
Sergey Kostanbaev: ... 2.5 ...[br]Alexander Chemeris: ... 2.5 watts of power
0:41:51.220,0:41:58.369
consumption, no more. And that's we were,[br]we were very lucky that LMS7 has such so
0:41:58.369,0:42:04.460
good, so good power consumption[br]performance. We actually had some extra
0:42:04.460,0:42:10.049
space to have FPGA and GPS and all this[br]stuff. But we just can't let the power
0:42:10.049,0:42:14.880
consumption go up. Our measurements on[br]this device showed about ...
0:42:14.880,0:42:18.510
Sergey Kostanbaev: ... 2.3 ...[br]Alexander Chemeris: ... 2.3 watts of power
0:42:18.510,0:42:27.220
consumption. So we are like at the limit[br]at this point. So when we fix the bus with
0:42:27.220,0:42:31.420
the higher voltage, you know it's a[br]theoretical exercise, because we haven't
0:42:31.420,0:42:38.000
done this yet, that's plenty to happen in[br]a couple months. We should be able to get
0:42:38.000,0:42:47.330
to this numbers which was just 1.2 times[br]slower. Then the next thing will be to fix
0:42:47.330,0:42:55.550
another issue which we made at the very[br]beginning: we have procured a wrong chip.
0:42:55.550,0:43:05.270
Just one digit difference, you can see[br]it's highlighted in red and green, and
0:43:05.270,0:43:13.230
this chip it supports only a generation 1[br]PCI Express which is twice slower than
0:43:13.230,0:43:18.190
generation 2 PCI Express.[br]So again, hopefully we'll replace the chip
0:43:18.190,0:43:30.140
and just get very simple doubling of the[br]performance. Still it will be slower than
0:43:30.140,0:43:39.770
we wanted it to be and here is what comes[br]like practical versus theoretical numbers.
0:43:39.770,0:43:47.119
Well as every bus it has it has overheads[br]and one of the things which again we
0:43:47.119,0:43:51.279
realized when we were implementing this[br]is, that even though the standard
0:43:51.279,0:43:58.910
standardized is the payload size of 4kB,[br]actual implementations are different. For
0:43:58.910,0:44:08.390
example desktop computers like Intel Core[br]or Intel Atom they only have 128 byte
0:44:08.390,0:44:18.740
payload. So there is much more overhead[br]going on the bus to transfer data and even
0:44:18.740,0:44:29.180
theoretically you can only achieve 87%[br]efficiency. And on Xeon we tested and we
0:44:29.180,0:44:37.110
found that they're using 256 payload size[br]and this can give you like a 92%
0:44:37.110,0:44:45.130
efficiency on the bus and this is before[br]the overhead so the real reality is even
0:44:45.130,0:44:53.180
worse. An interesting thing which we also[br]did not expect, is that we originally were
0:44:53.180,0:45:02.849
developing on Intel Atom and everything[br]was working great. When we plug this into
0:45:02.849,0:45:10.720
laptop like Core i7 multi-core really[br]powerful device, we didn't expect that it
0:45:10.720,0:45:20.140
wouldn't work. Obviously Core i7 should[br]work better than Atom: no, not always.
0:45:20.140,0:45:26.369
The thing is, we were plugging into a[br]laptop, which had a built-in video card
0:45:26.369,0:45:44.750
which was sitting on the same PCI bus and[br]probably manufacturer hard-coded the higher
0:45:44.750,0:45:50.590
priority for the video card than for[br]everything else in the system, because I
0:45:50.590,0:45:56.300
don't want your your screen to flicker.[br]And so when you move a window you actually
0:45:56.300,0:46:04.099
see the late packets coming to your PCI[br]device. We had to introduce a jitter
0:46:04.099,0:46:14.750
buffer and add more FIFO into the device[br]to smooth it out. On the other hand the
0:46:14.750,0:46:20.099
Xeon is performing really well. So it's[br]very optimized. That said, we have tested
0:46:20.099,0:46:28.119
it with discreet card and it outperforms[br]everything by whooping five seven percent.
0:46:28.119,0:46:38.799
What you get four for the price. So this[br]is actually the end of the presentation.
0:46:38.799,0:46:43.839
We still have not scheduled any workshop,[br]but if there if there is any interest in
0:46:43.839,0:46:53.390
actually seeing the device working or if[br]you interested in learning more about the
0:46:53.390,0:46:58.260
PCI Express in details let us know we'll[br]schedule something in the next few days.
0:46:58.260,0:47:05.339
That's the end, I think we can proceed[br]with questions if there are any.
0:47:05.339,0:47:14.950
Applause[br]Herald: Okay, thank you very much. If you
0:47:14.950,0:47:17.680
are leaving now: please try to leave[br]quietly because we might have some
0:47:17.680,0:47:22.960
questions and you want to hear them. If[br]you have questions please line up right
0:47:22.960,0:47:28.819
behind the microphones and I think we'll[br]just wait because we don't have anything
0:47:28.819,0:47:34.990
from the signal angel. However, if you are[br]watching on stream you can hop into the
0:47:34.990,0:47:39.500
channels and over social media to ask[br]questions and they will be answered,
0:47:39.500,0:47:47.890
hopefully. So on that microphone.[br]Question 1: What's the minimum and maximum
0:47:47.890,0:47:52.170
frequency of the card?[br]Alexander Chemeris: You mean RF
0:47:52.170,0:47:55.940
frequency?[br]Question 1: No, the minimum frequency you
0:47:55.940,0:48:05.640
can sample at. the most SDR devices can[br]only sample at over 50 MHz. Is there a
0:48:05.640,0:48:09.190
similar limitation at your card?[br]Alexander Chemeris: Yeah, so if you're
0:48:09.190,0:48:15.650
talking about RF frequency it can go[br]from like almost zero even though that
0:48:15.650,0:48:27.289
works worse below 50MHz and all the way to[br]3.8GHz if I remember correctly. And in
0:48:27.289,0:48:34.880
terms of the sample rate right now it[br]works from like about 2 MSPS and to about
0:48:34.880,0:48:40.089
50 right now. But again, we're planning to[br]get it to these numbers we quoted.
0:48:40.089,0:48:45.720
Herald: Okay. The microphone over there.[br]Question 2: Thanks for your talk. Did you
0:48:45.720,0:48:48.630
manage to put your Linux kernel driver to[br]the main line?
0:48:48.630,0:48:53.519
Alexander Chemeris: No, not yet. I mean,[br]it's not even like fully published. So I
0:48:53.519,0:48:59.019
did not say in the beginning, sorry for[br]this. We only just manufactured the first
0:48:59.019,0:49:03.830
prototype, which we debugged heavily. So[br]we are only planning to manufacture the
0:49:03.830,0:49:10.290
second prototype with all these fixes and[br]then we will release, like, the kernel
0:49:10.290,0:49:16.700
driver and everything. And maybe we'll try[br]or maybe won't try, haven't decided yet.
0:49:16.700,0:49:18.310
Question 2: Thanks[br]Herald: Okay...
0:49:18.310,0:49:21.599
Alexander Chemeris: and that will be the[br]whole other experience.
0:49:21.599,0:49:26.099
Herald: Okay, over there.[br]Question 3: Hey, looks like you went
0:49:26.099,0:49:30.349
through some incredible amounts of pain to[br]make this work. So, I was wondering,
0:49:30.349,0:49:34.960
aren't there any simulators at least for[br]parts of the system, or the PCIe bus for
0:49:34.960,0:49:40.150
the DMA something? Any simulator so that[br]you can actually first design the system
0:49:40.150,0:49:44.630
there and debug it more easily?[br]Sergey Kostanbaev: Yes, there are
0:49:44.630,0:49:50.400
available simulators, but the problem's[br]all there are non-free. So you have to pay
0:49:50.400,0:49:57.109
for them. So yeah and we choose the hard[br]way.
0:49:57.109,0:49:59.520
Question 3: Okay thanks.[br]Herald: We have a question from the signal
0:49:59.520,0:50:03.180
angel.[br]Question 4: Yeah are the FPGA codes, Linux
0:50:03.180,0:50:07.650
driver, and library code, and the design[br]project files public and if so, did they
0:50:07.650,0:50:13.480
post them yet? They can't find them on[br]xtrx.io.
0:50:13.480,0:50:17.970
Alexander Chemeris: Yeah, so they're not[br]published yet. As I said, we haven't
0:50:17.970,0:50:24.579
released them. So, the drivers and[br]libraries will definitely be available,
0:50:24.579,0:50:28.589
FPGA code... We are considering this[br]probably also will be available in open
0:50:28.589,0:50:36.359
source. But we will publish them together[br]with the public announcement of the
0:50:36.359,0:50:42.220
device.[br]Herald: Ok, that microphone.
0:50:42.220,0:50:46.010
Question 5: Yes. Did you guys see any[br]signal integrity issues between on the PCI
0:50:46.010,0:50:50.009
bus, or on this bus to the LMS chip, the[br]Lime microchip, I think, this doing
0:50:50.009,0:50:51.009
the RF ?[br]AC: Right.
0:50:51.009,0:50:56.359
Question 5: Did you try to measure signal[br]integrity issues, or... because there were
0:50:56.359,0:51:01.130
some reliability issues, right?[br]AC: Yeah, we actually... so, PCI. With PCI
0:51:01.130,0:51:02.559
we never had issues, if I remember[br]correctly.
0:51:02.559,0:51:04.760
SK: No.[br]AC: I just... it was just working.
0:51:04.760,0:51:10.940
SK: Well, the board is so small, and when[br]there are small traces there's no problem
0:51:10.940,0:51:14.790
in signal integrity. So it's actually[br]saved us.
0:51:14.790,0:51:20.599
AC: Yeah. Designing a small board is easier.[br]Yeah, with the LMS 7, the problem is not
0:51:20.599,0:51:26.099
the signal integrity in terms of[br]difference in the length of the traces,
0:51:26.099,0:51:37.319
but rather the fact that the signal[br]degrades over voltage, also over speed in
0:51:37.319,0:51:44.010
terms of voltage, and drops below the[br]detection level, and all this stuff. We
0:51:44.010,0:51:47.220
use some measurements. I actually wanted[br]to add some pictures here, but decided
0:51:47.220,0:51:54.359
that's not going to be super interesting.[br]H: Okay. Microphone over there.
0:51:54.359,0:51:58.359
Question 6: Yes. Thanks for the talk. How[br]much work would it be to convert the two
0:51:58.359,0:52:05.610
by two SDR into an 8-input logic analyzer[br]in terms of hard- and software? So, if you
0:52:05.610,0:52:12.289
have a really fast logic analyzer, where[br]you can record unlimited traces with?
0:52:12.289,0:52:18.980
AC: A logic analyzer...[br]Q6: So basically it's just also an analog
0:52:18.980,0:52:27.040
digital converter and you largely want[br]fast sampling and a large amount of memory
0:52:27.040,0:52:30.900
to store the traces.[br]AC: Well, I just think it's not the best
0:52:30.900,0:52:40.300
use for it. It's probably... I don't know.[br]Maybe Sergey has any ideas, but I think it
0:52:40.300,0:52:47.549
just may be easier to get high-speed ADC[br]and replace the Lime chip with a high-
0:52:47.549,0:52:56.720
speed ADC to get what you want, because[br]the Lime chip has so many things there
0:52:56.720,0:53:01.450
specifically for RF.[br]SK: Yeah, the main problem you cannot just
0:53:01.450,0:53:09.099
sample original data. You should shift it[br]over frequency, so you cannot sample
0:53:09.099,0:53:16.619
original signal, and using it for[br]something else except spectrum analyzing
0:53:16.619,0:53:20.839
is hard.[br]Q6: OK. Thanks.
0:53:20.839,0:53:25.750
H: OK. Another question from the internet.[br]Signal angel: Yes. Have you compared the
0:53:25.750,0:53:32.240
sample rate of the ADC of the Lime DA chip[br]to the USRP ADCs, and if so, how does the
0:53:32.240,0:53:40.160
lower sample rate affect the performance?[br]AC: So, comparing low sample rate to
0:53:40.160,0:53:49.281
higher sample rate. We haven't done much[br]testing on the RF performance yet, because
0:53:49.281,0:53:58.440
we were so busy with all this stuff, so we[br]are yet to see in terms of low bit rates
0:53:58.440,0:54:03.190
versus sample rates versus high sample[br]rate. Well, high sample rate always gives
0:54:03.190,0:54:09.859
you better performance, but you also get[br]higher power consumption. So, I guess it's
0:54:09.859,0:54:14.019
the question of what's more more important[br]for you.
0:54:14.019,0:54:20.440
H: Okay. Over there.[br]Question 7: I've gathered there is no
0:54:20.440,0:54:25.319
mixer bypass, so you can't directly sample[br]the signal. Is there a way to use the same
0:54:25.319,0:54:31.720
antenna for send and receive, yet.[br]AC: Actually, there is... Input for ADC.
0:54:31.720,0:54:38.289
SK: But it's not a bypass, it's a[br]dedicated pin on LMS chip, and since we're
0:54:38.289,0:54:45.569
very space-constrained, we didn't route[br]them, so you can not actually bypass it.
0:54:45.569,0:54:50.359
AC: Okay, in our specific hardware, so in[br]general, so in the LMS chip there is a
0:54:50.359,0:54:58.170
special pin which allows you to drive your[br]signal directly to ADC without all the
0:54:58.170,0:55:02.950
mixers, filters, all this radio stuff,[br]just directly to ADC. So, yes,
0:55:02.950,0:55:06.869
theoretically that's possible.[br]SK: We even thought about this, but it
0:55:06.869,0:55:10.960
doesn't fit this design.[br]Q7: Okay. And can I share antennas,
0:55:10.960,0:55:15.700
because I have an existing laptop with[br]existing antennas, but I would use the
0:55:15.700,0:55:22.140
same antenna to send and receive.[br]AC: Yeah, so, I mean, that's... depends on
0:55:22.140,0:55:25.619
what exactly do you want to do. If you[br]want a TDG system, then yes, if you
0:55:25.619,0:55:30.869
want an FDG system, then you will have to[br]put a small duplexer in there, but yeah,
0:55:30.869,0:55:34.839
that's the idea. So you can plug this into[br]your laptop and use your existing
0:55:34.839,0:55:39.640
antennas. That's one of the ideas of how[br]to use xtrx.
0:55:39.640,0:55:41.799
Q7: Yeah, because there's all four[br]connectors.
0:55:41.799,0:55:45.400
AC: Yeah. One thing which I actually[br]forgot to mention is - I kind of mentioned
0:55:45.400,0:55:53.930
in the slides - is that any other SDRs[br]which are based on Ethernet or on the USB
0:55:53.930,0:56:02.309
can't work with a CSMA wireless systems,[br]and the most famous CSMA system is Wi-Fi.
0:56:02.309,0:56:09.259
So, it turns out that because of the[br]latency between your operating system and
0:56:09.259,0:56:17.569
your radio on USB, you just can't react[br]fast enough for Wi-Fi to work, because you
0:56:17.569,0:56:23.240
- probably you know that - in Wi-Fi you[br]carrier sense, and if you sense that the
0:56:23.240,0:56:29.579
spectrum is free, you start transmitting.[br]Does make a sense when you have huge
0:56:29.579,0:56:36.160
latency, because you all know that... you[br]know the spectrum was free back then, so,
0:56:36.160,0:56:43.730
with xtrx, you actually can work with CSMA[br]systems like Wi-Fi, so again it makes it
0:56:43.730,0:56:51.390
possible to have a fully software[br]implementation of Wi-Fi in your laptop. It
0:56:51.390,0:56:58.660
obviously won't work like as good as your[br]commercial Wi-Fi, because you will have to
0:56:58.660,0:57:03.839
do a lot of processing on your CPU, but[br]for some purposes like experimentation,
0:57:03.839,0:57:07.980
for example, for wireless labs and R&D[br]labs, that's really valuable.
0:57:07.980,0:57:11.400
Q7: Thanks.[br]H: Okay. Over there.
0:57:11.400,0:57:15.519
Q8: Okay. what PCB design package did you[br]use?.
0:57:15.519,0:57:17.819
AC: Altium.[br]SK: Altium, yeah.
0:57:17.819,0:57:22.940
Q8: And I'd be interested in the PCIe[br]workshop. Would be really great if you do
0:57:22.940,0:57:24.940
this one.[br]AC: Say this again?
0:57:24.940,0:57:28.069
Q8: Would be really great if you do the[br]PCI Express workshop.
0:57:28.069,0:57:32.720
AC: Ah. PCI Express workshop. Okay. Thank[br]you.
0:57:32.720,0:57:36.690
H: Okay, I think we have one more question[br]from the microphones, and that's you.
0:57:36.690,0:57:42.880
Q9: Okay. Great talk. And again, I would[br]appreciate a PCI Express workshop, if it
0:57:42.880,0:57:47.190
ever happens. What are these[br]synchronization options between multiple
0:57:47.190,0:57:55.089
cards. Can you synchronize the ADC clock,[br]and can you synchronize the presumably
0:57:55.089,0:58:04.609
digitally created IF? SK: Yes, so... so,[br]unfortunately, just IF synchronization is
0:58:04.609,0:58:10.279
not possible, because Lime chip doesn't[br]expose a low frequency. But we can
0:58:10.279,0:58:16.000
synchronize digitally. So, we have special[br]one PPS signal synchronization. We have
0:58:16.000,0:58:25.180
lines for clock synchronization and other[br]stuff. We can do it in software. So the
0:58:25.180,0:58:31.789
Lime chip has phase correction register,[br]so when you measure... if there is a phase
0:58:31.789,0:58:35.170
difference, so you can compensate it on[br]different boards.
0:58:35.170,0:58:39.309
Q9: Tune to a station a long way away and[br]then rotate the phase until it aligns.
0:58:39.309,0:58:41.819
SK: Yeah.[br]Q9: Thank you.
0:58:41.819,0:58:46.339
AC: Little tricky, but possible. So,[br]that's one of our plans for future,
0:58:46.339,0:58:52.819
because we do want to see, like 128 by 128[br]MIMO at home.
0:58:52.819,0:58:56.060
H: Okay, we have another question from the[br]internet.
0:58:56.060,0:59:00.450
Signal angel: I actually have two[br]questions. The first one is: What is the
0:59:00.450,0:59:07.710
expected price after a prototype stage?[br]And the second one is: Can you tell us
0:59:07.710,0:59:10.400
more about this setup you had for[br]debugging the PCIe
0:59:10.400,0:59:15.970
issues?[br]AC: Could you repeat the second question?
0:59:15.970,0:59:20.269
SK: It's ????????????, I think.[br]SA: It's more about the setup you had for
0:59:20.269,0:59:24.480
debugging the PCIe issues.[br]SK: Second question, I think it's most
0:59:24.480,0:59:31.200
about our next workshop, because it's a[br]more complicated setup, so... mostly
0:59:31.200,0:59:35.580
remove everything about its now current[br]presentation.
0:59:35.580,0:59:39.580
AC: Yeah, but in general, and in terms of[br]hardware setup, that was our hardware
0:59:39.580,0:59:47.890
setup, so we bought this PCI Express to[br]Thunderbolt3, we bought the laptop which
0:59:47.890,0:59:53.089
supports Thunderbolt3, and that's how we[br]were debugging it. So, we don't need, like
0:59:53.089,0:59:57.780
a full-fledged PC, we don't have to[br]restart it all the time. So, in terms of
0:59:57.780,1:00:06.650
price, we don't have the fixed price yet.[br]So, all I can say right now is that we are
1:00:06.650,1:00:18.349
targeting no more than your bladeRF or[br]HackRF devices, and probably even cheaper.
1:00:18.349,1:00:25.210
For some versions.[br]H: Okay. We are out of time, so thank you
1:00:25.210,1:00:45.079
again Sergey and Alexander.[br][Applause]
1:00:45.079,1:00:49.619
[Music]
1:00:49.619,1:00:54.950
subtitles created by c3subtitles.de[br]in the year 20??. Join, and help us!