 My name is Matt Rannisday, I work for Intel and thanks for coming to my talk, SIGROC using logic to debug logic. How many people here have actually heard of SIGROC before? Okay, how many people have used it? Okay, so there's a few people. So basically SIGROC is a project to enable, instead of using proprietary software for your cell scopes and logic analyzers, basically have a common framework that you can use so you don't rely on proprietary software and their formats on data. Some of the devices we support is like logic analyzers, cell scopes, other analog devices. It has a common framework, device metadata and interfacing to the devices. It's not just one application, it actually has various libraries, back-ends, protocol decoders, some third-party firmware for some logic analyzers, and graphical front-end which I'll show a demo later on. It says it aims to make a common framework for various logic analyzers on other debugging devices. Like I said, it's not just one package, there's a whole lot. It's like a lib SIGROC. It's pretty much the heart and brains of the application. It handles interfacing to the devices, the output format and the control. There's lib SIGROC decode which is a Python 3 interface that allows you to write Python protocol decoders for any of your traces. There's also the client application. It's command-aligned back-end. There's also utils that do FPH bitstream rips out of the logic analyzer software so you can run a SIGROC. There's a collection of dumps from various captures of devices, I2C, SCAN, bus, SPI, etc. We also have a firmware for some logic, basically salelogic clones and actually the actual device. It's basically a microcontroller that can do logic analyzing. We have that and PulseView which is a QT front-end for lib SIGROC. It makes everything nice. It's pretty recent development. Here's pretty much how everything is done. I have to cut off a little bit there. The hardware interface, we have lib SIGROC that interfaces to the devices and puts output back to the client command line, the GUI. We have plugins for Python and also SWIG which you can write for any of your own scripting languages. There's, I should say, those bindings. The plugins actually for collectD which I'll get into later. And also libSIGROC decode which you can pass anything you're tracing into decode protocols. This is not a complete list binding me, it's just some of the devices I've worked with. Logic analyzers, the open logic interface one I've used a lot. The salelogic 16 is another one. And for oscilloscopes, they're a little more of the RIGOL DS-1052E. It's a cheap one, about 50 megahertz. It's a decent one. And some of the other supported devices, we have mixed mode devices, digital multimeters, analog devices, like thermometers, hydronometers, light meters. The full list is available on the SIGROC Wiki. Here's a screenshot of the, it's kind of blurry. But there's a screenshot of the Wiki page. There are all the devices we support, like salemometers, oscilloscopes, multimeters. There's a whole list. Feel free to add to this if you get a chance. Now, the one advantage of the SIGROC is we have an output format that's device agnostic. It's interchangeable between devices. So basically, usually when you have a proprietary application that comes with your logic analyzer, you're pretty much stuck using that. So whatever you trace with, it's going to be the same, no matter what. It's a simple hex dump, actually, the actual channel dumps, like the buffers off a logic analyzer. And it's compressed using zip algorithms. So you can see compression rates of 100 times of repeating samples. And traces can actually be broken into chunks, which is useful when you're using the GUI. And if you want to do protocol decoding in real time, you need to have a set data to run the protocol decoder on. And if you want to keep tracing continuously, that's one way you can do it. Or you could have multiple devices outputting to the same format file. The common metadata is useful for clients. And protocol decoding keeps basic data, I'll show you right here. Like the sample rate, what probes are used, the actual labels for each of the probes. How many groups are enabled, see there's a capture file of logic one. Which device was used, and also what version. And here's an example of one of the output files unzipped. And you can see a hex dump of logic one. So three there would be probe one and zero are high, so that's transmit and receives high. And you see it's two, which means I received one low. So this is a UART dump of a GPS module. Other supported formats, we have value change dump, which is kind of a verilog thing. Analog for digital multimeters and oscilloscopes. Comma separated values, which is not very useful. We don't think it's quite large, but it's very exportable. The new plot, that's pretty self-explanatory. You can output your waveforms in a nice graphical format. And also some various vendors, specific ones like the open logic sniffer. It's output and the chrono view logic, you know, measure eight output. The only else one was actually helpful with debugging pulse view. When it was crashing, I just want to see a graphical representation. And sometimes it was easier to do it that way. Sorry about you constantly feeding back into the... Now, some of the units that I... Some of the logic, the open logic sniffer is one of the units I use. It's very inexpensive. It's completely open source hardware. It can do 100 megahertz sampling, but not really, because the probes are kind of noisy. You know, 200 megahertz sampling, but only using a double data rate hack, where it's sampling up high and low of a clock, but only on the FPGA's logic level, which is like 1.2 volts. Nice advantage it has hardware triggers, running length encoding, external clock. Disadvantage of this one is it's a dead project. It really hasn't been updated in two to three years. It only has a 24k sample buffer, and high speed traces are pretty much useless without run length encoding. Here's a picture of it. You can see it's pretty spartan. And actually, that's a spartan on there, FPGA. Yeah. Another one that... Another one, I don't actually have the logic one, but it's $150, although the clones are pretty much the same thing, only you can find it much cheaper in that. Yeah, Cypress FX, too much control on there, so we have that SigRoc firmware, which you can load onto it. Basically, it gets loaded on over USB the first time you do a trace or the first time it gets initialized. The one I do have right here, actually, is a Saley Logic 16. It's a little twice as expensive. The first one can only do 24 megahertz on 16 channels, no, 8 channels. This one can do 3 at 100 megahertz, kind of, but it's USB 2, so there's no hardware buffer on the device, so it's piping over USB as fast as it can. So it's kind of skeptical it's actually doing that. It's only software only triggers, so basically you have to filter it on the software side. See, this is a little more professional on the last one, so... Yes, protocol decoders. That's the main advantage of SigRoc is a lot of applications that you get with Logic Analytics. You can do protocol decoding, but it's pretty rare. We have a feature, you can do stackable ones, so you can take an I2C dump and pipe it into another one below it with a certain device. Some examples would be like I2C into a weed nunchuck. Instead of seeing just a bunch of commands, you could actually see the actual up, down pressed on the output. We support all the common protocols, like I2C, SPY, CAN, OneWire, UART, and it can be done with the client or the GUI. Depending on what you're debugging, one or the other can be more useful. For UART stuff, we do want to see a string coming out of a UART dump. You want to use a client. For instance, if you want to see something that's an I2C commands that's piped into another protocol decoder, but there are some times where it's useful to see it in the GUI, which is if you want to see the GPS data along with the pulse per second, you want to see it when it goes high and low. I2C, GPY expander, if you want to see the I2C commands and you want to confirm that the outputs are high or low. Since, like I said, the protocol decoders are written in Python, so it's pretty easy to basically use one of the boiler plates we already have. The annotations come in both the output and input. I kind of word that wrong there, but that allows you to stack protocols. You would basically, for the I2C protocol decoder, you label the output as I2C, then if you have another protocol decoder, you would have it, I only accept input from I2C or SPI, and you could deduce what you want to do, how to process that data. Most decoders are pretty much state machines, and they should be, if you basically say, I'm going to start, if I'm going to start command, I should expect this command next, and then after that, obviously you need some error checking. Like I said with the FX2 chipset devices, the open source firmware is available. Like I said, the one disadvantage is the microcontroller doesn't actually keep any of the actual data that's loaded. You have to load it every time. Same thing with the salient logic. The FBG-A gets the bit stream piped over the first time you do a trace. I mean, various low-end logic analysis uses this, and it's good enough for 90% of most people's uses for debugging low-speed buses like I2C, SPI. I mean, once you require over 24 microhertz sampling clock, you're going to have to go a little higher end anyways. As you can see, this is pretty basic design. Some features that don't exist currently at SigRock what we'd like to do in the future, a lot of them have to do with triggering. Serial triggers would be nice. For instance, currently we only support parallel triggers, so basically you have probes that go higher or low, and it would trigger the trigger stage. In serial, you would basically select one probe and tie it with an external clock, so if you wanted to see a SPI command, just kick off a trigger, you would use that. Also, multi-stage would be another one. We don't have that yet. Now, software triggers, like I said, there's a lot of logic analyzers that don't actually do any hardware, but it does have an advantage. You can do more extensible triggering without hacking the veralog on a lot of the like the open logic sniffer or a lot of other ones. Nice to have analog digital channel conversion right now. For instance, if you had like a four port oscilloscope and you wanted to change one port to digital logic, obviously you can get a mixed mode device, but you just want to use one probe as a digital input. Multiple devices per capture, and nice to have pulse for you to have some analog support right now. It's only digital signals. Yes, bindings. We have Python that's pretty explanatory. Swig, you can basically write for any scripting language you wanted to later on. Now, the collectee, it's basically a graphing. Basically, you can do a graph from it. You can do a circular database updates. And I'll show you a graph later for this. I mean, use cases to be like sound lever meter or carbon monoxide monitoring in near a furnace. There's pretty much, I don't remember the device. What is it? Did you use to trace this? Or was that? Okay. What? Did you read the numbers? It was everything, maximum 70 dB. That's boring. And this is basically what one of the configs would look like for the collectee. You have a plug-in. You pick the driver. The connection is a USB or serial over USB. And updates once a second. Nothing really to see here. Pulse view, yeah. Before, we really didn't have any GUI for SIGRAC, and it was kind of holding everything back because we liked the command line for a lot of time. And previous attempts kind of were buggy, but Joel's been doing a lot of work on that. It allows, I mean, visual displaying of samples and actual protocol decoding. Here's a screenshot in case my demo fails. So this is what it looks like. So it's deep. You can see the CAN probe, and you can see the decoding up there of the actual protocol. The continuous samples, for this logic 16, you can totally do continuous samples. But there's USB timeout issues, I've noticed. So you really don't get that all the time. Hopefully USB 3 will have a version of that. Saley will come out of logic 16 with USB 3 interface. Run length encoding is a good solution, but they're hold-ups you can be tracing forever effectively if you have the wrong settings, and nothing changes. Trigger types are important because, for instance, whether it's serial or parable, external clocking is useful. That doesn't have an external clock input, but the open logic sniffer does, which is very handy for stuff that you don't want to have the internal clock of your device. You want to actually have the clock of the bus. Now, chaining with external triggers in and out, you can do that with the open logic sniffer, which might not seem... I mean, it's already 32 probes, but the problem is it can only debug at one logic level. So if you had two, you could have tied together. One would be debugging a 3.3-volt logic signal, and another would be 1.8. Now, with one length encoding, there's a few things that we kind of ran into. It's interesting. For instance, if you're debugging two probes, you might enable only one channel group, which seems okay, but the problem is the value is going to be 8 bits, but the count's going to be 8 bits. So if you have a signal that's not changing, you're running through that buffer really fast. Now, sometimes it makes sense to enable a second group, so you have 16 or 15 bits depending, and you have a 16 or 15-bit count, even though you're not using those other value bits. Now, simple microcontrollers can be used as logic analyzers like with FX2. You can also use the Bigel Bones PRU, for instance. Multiple devices chained for different logic levels, like I said. Okay, now, let's see. Get to the demo. Basically, I'm going to show you an example of using the command line that's when it's more useful than the UI. Protocol decoding. And with pulse fuel, I'll show you a display of samples and actually the tracing of the GPS module, which doesn't have a fix because we're inside a building, but that's what it looks like right here. I forgot to name the probes. What? Which one? Oh, it was the correct other way. So that did trace the GPS module here. There's no fix, so it's going to be kind of useless, but kind of broad-rate. So basically, this is going to set through the UART protocol decoder. Then it's going to pass it off to the UART dump, which will show strings of the actual UART data. And as you see, there's no GPS coordinates, so there's no fix. There's one more thing on the client that I'd like to show. This is quite a few devices on an I2C bus. Now, the problem is you only want to debug one device, but you have multiple things talking on the same bus. So we're going to pass it through an I2C protocol decoder. Then we're going to set it through a filter one, and then we're going to send it through a real-time clock decoder. So that's basically it. It's a little more user-readable than seeing... This is a little more user-readable than seeing a waveform, Sana, the GUI, actually. Now... Now we'll see the same thing, and now here's a GPS dump of an actual... actually, when it got a fix. So it picked up the probes. I'm going to add 600, and that's pretty much the bytes. Basically, open this again. So I get the probe named kind of lazy, so... but I can do it trace now. And you can see it, but... that pulse per second is not correct, so it didn't get a lock, so it doesn't have to be useless. Okay, so things that the community can help us with is setting us, like, protocol dumps of various protocols, nothing too ancient or weird for submission. Some examples we like to see is, like, DMX, lighting, MIDI, various GPS modules, and I2C. It's the first step to writing a protocol decoder, even if you don't want to write one. Basically, you can help us out with just giving us traces. Basically, if you find bugs, because there are a lot of bugs, especially in the GUI right now, but... no offense. But report that anything you find, just don't get mad and not report it, because it does help. Contribute to the Wiki. I mean, post breakdowns of various logic analyzer and oscilloscopes that you might have, or protocols that communicate to those devices. Free hardware is always helpful, but... and as always, public patches are welcome. So questions went through pretty fast, but I didn't work ecosystems in there. So it's slightly corrected what Matt said. PulseFeed does have basic support for analog, but we haven't really used it on anything much beyond the outside input driver. So it's kind of basic, and I don't have any oscilloscopes. Do you have triggers, things like that? Yeah, we do have some oscilloscopes, which are already used to support the same sort of triggering on the same parameters. Is there any open hardware oscilloscope? Is it available? First, there is one, the oscillogram. Yeah, oscillogram. I'm just computing in Switzerland. It's also FX2 based. It really goes up to all the same limits as any FX2 device, it's limited by USB. So it's probably just a megabit or something. The default that they... or what they advertise it with is 6MHz, but it will go higher. Is it the one that's basically using the Android smartphone? Yeah. If you have a scape that has some piece of bandwidth that you like to support it, it probably would take somewhere like you more than a few hours to drive it because there's only three or four hundred miles. Is it coming together right? Yeah. Well, no, I can't do that. I have a little oscilloscope. It's like a pick with a screen. And I tried to integrate that in the A-pad scale. And it seemed like the oscilloscope support would work better than that. It's better. You can use it quite a bit. When I lived with the Ryder one... Any more questions? I'm one of the network guys. So I have to use wirechart for them. Doesn't it start with putting this into wirechart and using wirecharts because the height over it goes? I don't think so, has there? No, no. Basically, it's... it's kind of almost doable. The problem with wirechart is that they have the scene language recorded in the LUA decoder. Yeah. Well, you'd have to interface with both of those. You'd have full wirechart support. But we've always envisioned when we have enough vertical decoders in the SIGROT decode at some point it's going to become pointless to add another level on top because of wirechart and all that stuff. So that's which is probably what you mean. So yeah, at some point we'll have to look at it because it's all doable. And the other thing is that SIGROT is kind of like a pipe and that plays really well with units. And so, in a way, if you can get data out of it in any format it's convenient to use it. It's up to your imagination to do what you think could help you demonstrate. Yeah, yeah. Maybe any clue. Maybe it's something easy. I have one. It's actually quite easy to do and can do that quite fast. Any more questions? I saw you had USB up there for protocol. What kind of hardware do you hook up to for doing USB analysis? Which one do we have? Supported. This was done with this fairly low-end logic analyzers which means USB 1.0 and very low speeds. But I guess you're talking about USB analyzers and such? Or decos and such? I don't know. Because some get you on the low-level packets but basically we haven't really tried to feed one into the other. It should be doable. I have no excuse. I actually have a vehicle. Not even used it yet. If you don't use it I'll take it. But is it actually a problem of people with high bandwidth here providing 2 million bucks or information or what's the reason for being limited to, let's say, USB 1.1.0? It's just a simple hand. Simple. As soon as you hit USB 2.0 you're talking about 480 megabit raw. That means more than that. And you need some sort of storage because you can't shift that live over another USB bus. So it's just really a hand. Well actually that's what the vehicle is about. It samples the USB at USB clock. Contrasts it on 10 ships with computer over a specialized USB port. Why do you need a vehicle though? One vehicle, sir. I don't know what to say but the 480 has not actually used USB port for that. I don't even know which one. In the hardware it was a single port. I never use it in single because it provides little software for the vehicle. And the FX2 hourly is in the FPGA right? All the hourly mentioned here takes place in the FPGA on the logic analyzer right? The FX2 doesn't actually it just has a tiny little 851 cord very slow. It runs at 12 megahertz or something like that. And basically the USB shipping functionality it doesn't have 851 at all. It has no way Any more questions? Alright, thanks. Thanks for coming.