 Good morning, everyone. I hope you have enough time to wake up during the previous talk. I thank you Fabian for waking you up. I am going, well, first, who am I? I have to make two disclosures here. First, I am the wrong person in the wrong place. I am not a software guy. The second one, the initially this talk was submitted for the debugging tools, deaf rooms, but then for whatever reason, relocated here. So I am not really sure how relevant it will be for you. And what I'm doing for living, instead of software development, I am designing hardware, embedded hardware, and using software to bring up this hardware to make it run. But since for the last five, 10 years, most of work is concentrated on the FPGA systems, the problem is not only how to bring this software running, but how to bring all the hardware platform for this software up and running, including the software or integrated hardcore CPU processors. So today, I'm going to talk, just make a short overview how it's possible to debug not software, but to do the hardware debugging, but to do it with a free and open software. And fortunately enough, it's possible all the pieces are here. And I can just summarize the entire presentation in one word. All the free software, all the pieces are here. But integration between them is really missing. So you have to assemble puzzle from different pieces together just to make anything running. And how many of you in this audience know what the FPGA is or have used FPGA? Wow. OK. Then perhaps you know everything I'm going to tell next and even quite possible that you know it much more than I do. Nevertheless, a few words why I think that software developers should care about the FPGAs? Because those are, of course, some pretty hard statements, which are not 100% true. But for the last 10 years, all the modern architecture, CPU architectures are pretty much stuck in their development. And to get any performance, you have to go to non-standard architectures or to custom hardware accelerators or to reconfigurable hardware to accelerate it. And for the last 30 years, 40 years already, all the hardware development is based on two languages. Both of them are, say, niche languages, VHDL and Verilog. And the preferable one depends on what site of Atlantics you are at. Well, there are some variations. So there are people in the States who know with VHDL. There are people in Europe who write some Verilog. But generally, depending on what site of Atlantics you are, you are choosing one or the other language. But unfortunately, compared to the software progress what we saw through the last 20 years, those two languages are still very, very old. Despite the new standards Verilog 2008, VHDL 2011, and the Common One 2020, those technologies are pretty much looking behind. And the industry itself is very conservative about taking any new approaches. So why this is needed for software developers? Because we have to make run our software on mailable, changeable, programmable, and heterogeneous architectures. And because the industry needs some kick from outside to move forward. Otherwise, they will stay there with their absolute tools forever. As I said, the free software is available and very actively developed under active development for the RTL designers and both VHDL and Verilog are supported. I'm not that much in the Verilog HDL, so we'll talk afterwards about the VHDL. But nevertheless, Verilator, Icarus Verilogs are excellent fast simulators, compiler from Verilog to CC++ or just an interpreting simulator. And Yosses is an excellent system which provides the full path from the Verilog RTL description down to the hardware. Unfortunately, only for the supported hardware architectures, but it's going to be extended and it's under active development. So everything is good here. And it's much more convenient for software people and for hardware people as well. Before you go to the hardware, you have to simulate it first. And if you can catch half of your errors in simulation, that's good. If you can catch 90% of your errors in simulation, that's even better because you have another 90% related to the hardware platforms. So better to separate them. And for VHDL simulation, there is a nice compiler. It's a part of the GNU compiler suite. It's a GHDL and it's written on the niche language on Ada. So there is actually not only embedded software but a quite conventional PC software written on Ada, which is a bit surprising and making it a bit more difficult to read. And there is a nice GUI front-end to look at because the hardware people are not speaking the same language as software, so we do not compile anything. We synthesize and place and route it. And we are not running print half debugging. We are looking to the Blinken LEDs. I hope they are still Blinken. Yes, I'm not sure how visible it is but we will come later to it. That's a quite common way to debug hardware. It's just Blinken. But of course there is a GUI front-end to look on the traces and it's much more pleasant to the eyes than the Blinken LEDs afterwards. Since we are going first to simulate, this is a very small snippet of the code. I'm going to debug and simulate. It's a simple generator, data pattern generator to run tests again and to test it and it supports two modes. In one it's a simple binary counter and in the more advanced mode, it's a linear feedback shift register. And as you see, the code itself is just eight, 10 lines with all the boilerplate code around it. And VHDL is quite verbose language. It's around 45, 50 lines in the file. But the same file can be simulated, run on the GHDL and traces can be viewed in GUI. And the physical is the very same file, can be later on compiled, synthesized and placed on the road for FPGA and then we can debug it on the hardware. That's a nice and not quite readable screenshot and now I will try to switch to the, oh, okay, it's here. So we are going to LED mode, oops. As you see, as the screen, oh, yeah, it's even better than a PDF. Just run GHDL several times to synthesize several blocks and run a simulation for a while. And now if we start to make without magic, okay? Oh, it's here. Exactly what you saw on the screenshot and we can see two separate, oops. If I can scroll it now. Uh-huh, I can. Uh-huh, we see those two different running modes, the binary count one and the linear feedback shift register. You see the one is Vulkan through the register here and zero, albeit zero is a possible state for the binary counter of course and it's a dead state for the linear feedback shift register. So if you move to that one, for the software developers, I think all the work is done here. We have a code, we can compile it, we can run the simulation, we can get a picture. It's working, we are done. Not quite true for the hardware. So, oops, sorry for that. So we have to go for the, down to the real hardware. And at this place we are completely, we have completely to surrender to the vendor tools because except for the uses and latest and some low-end Xilinx platform, there is no way to place and route and to generate a bit stream for the real hardware, for the real FPGA. I really hope that sometime soon it will change for, at least for some Altera Intel FPGAs. If someone of you will contribute to that. And for the on chip on hardware debugging, there are tools from all the vendors. Altera has a signal tap, Xilinx chip scope, Synopsys has identity RTL debugger, which is running on, I think all the FPGA families supported by Synopsys. Micro-SAMY microchip have their own smart debug features. So you actually can look inside the running hardware, running FPGA chip and get the same traces to look for the signals and in some advanced cases like the smart debuck is, you can even try to toggle some signals or to tweak some signals in the running system and see how your hardware react on this. What is the problem with those tools? I think that stated in their very first line, their proprietary and their vendor specific. So if by some crazy decision of hardware designer, you have two different FPGAs from different vendors on the same board, you basically have to have two completely different parallel setups of all the development and debugging tools. Somehow, magically, if you're lucky enough, connected to the same hardware and hopefully used in parallel. Haven't ever seen working it in practice. Unfortunately, even if you have to debug several or two separate pieces inside the same FPGA, it's already challenging with the vendor tools. If you have two different vendors and of course support engineers and field application engineers will just ask you, ah, you're using the different FPGA? Sorry, we can't help you. And that's a problem. And of course, especially if you are not working in the university or industrial environment, there is a cost for the licenses. And sometime it's acceptable and quite reasonable. Sometime they are charging a premium amount for basically non-working tools. But fortunately, but we can learn from them, we can look at them and maybe do some somewhat better job. And what we can learn from those tools is they are less common denominator, how to connect to the hardware. All those tools are talking to the hardware through the IEEE 1149.1. It's also I think something or so-called JTEC standard. It's simple four-wire interface to talk to. Initially it's been intended for the hardware testing, for the interconnectivity on the board testing, but now it's overused for the CPU cores debugging, for microcontroller debugging, for flash and programmable logic interface and programming, configuring, debugging it. So it's, I would say that it's most widely used and the least common denominator for all the interfaces. And there is a software support there are two, somewhat different, somewhat separate, somewhat competing projects to talk to different interfaces hardware debuggers. So besides the software running on the host system to talk to the hardware, you need some converter from the whatever interface you have on your development station. It's usually it's nowadays it's either USB or there are some converters based on the networking, either net connections, but you need some converter to talk to the hardware. So USB to JTEC converter. And some of them are integrated in the development board. Some of them are even integrated into the final products and the embedded systems. Sometimes it's just a small external boxes. And both UR, JTEC and OpenOCD provide support for, I don't know, something like around 50, 100 of different interfaces. And they are pretty flexible, provide the driver API work and you can write the plugin to support your own interface. And then of course it's interesting to look what is available as a free software for the GUI counterpart of those vendor tools. And there is an excellent interesting project of CROC. Its prime intention is to provide a free and open source interface for the real hardware. So it means for the digital multimeters, signal generators, logic analyzers, oscilloscopes. And for that matter, it supports a lot of vendor systems and big and expensive tech electronics, Agilent, HP, all the stuff. But it's also reasonably easy to provide a plugin driver for it so it can talk to the logic analyzer which is built in inside the FPGA. Since FPGA is very flexible, you can just take some more VHDL code or some more VRLO code and build a logic analyzer inside the FPGA using its internal resources and connect it to different signals inside the FPGA itself. And vendor tools such as their signal tap, chip scope, synopsis, smart debug, they are working exactly at this level. They are instantiating a separate logic analyzer instance inside your system connected to the signals you are pointed to, you are interested to look at. And then after that you is able to look inside your running system to figure out what's going on there. And then of course you can use all those tools with pretty much any board you have or any FPGA platforms you have because they are free. And this one is just an example of one of the boards. What is, yeah, and it's still blinking. You see it's running a binary counter mode, I hope. And as we, yes, it's a binary counter still. And as we saw on the VHDL snapshot, it can run in second mode. I will try to switch it now. So, yep, hope it's visible. It's a linear feedback shift register so the bits are moving. But in this mode, of course, you can debug in something with eight bits, debugging something with 32 bits with the LEDs would be possible. And yesterday downstairs I saw an excellent replica of PDP 11 console where you have 32 toggle switches, 32 LEDs, and you can actually download code and debug it this way. But with modern architectures, with hundreds of registers, that would be a little bit painful and too slow. So all the tools, all the pieces are actually available and there are different projects to connect them together. But what you have to do to make it running is to assemble them and to make them talk to each other. Because URG Tech, URG Tech has its own interface library to talk to it. Open OCD provides an RPC interface, but to this interface you have to talk TICL, which is another example of 40 years old language, I think. And it's very, very favorable by both VHDL and VRLog designers. So they don't know much about the make files really. What they have is they have a VRLog code or VHDL code and then TICL scripts to set up and compile it. And to follow this tradition, Open OCD provides an RPC talking TICL. But which is nice and there is an example of how to talk to this interface from Python. And what I've done for this demonstration, I wrote a simple driver for the Open OCD, for LibcGROC to talk to the Open OCD TICL interface. So there is a plugin for the GUI, for the PulseView, for LibcGROC, which talks through the TICL interface to the Open OCD, which in turn talks through USB to the USB to JTEC converter, which in turn talks through the JTEC to the logic analyzer inside the FPGA. And yes, all this code is free and available on GitHub page and it's even running. And what we can get running this code is this nice snapshot, screenshot of the SIGGROC PulseView showing basically the same picture. For whatever reason, when I've made a screenshot, they are mirrored compared to the one with the simulation results. On the simulation screenshot, we had a binary counter first and linear feedback shift register afterwards. Here we have a linear feedback shift register and binary counter. And I also think that bit order is swapped. But what, it happens. And now let's see if I can make it run on live. On live. Here in the FPGA code demo and actual FPGA file is also here. It's a bit bigger than the small snapshot I've shown. It's initialization logic, but here is the actual code we are, we've been simulating and now we are debugging on the real hardware. And if we run S-O-V-G-TEC server. OCD are just a configuration files integral for the open OCD and which describe how to interface to all the pieces which are interface to use and how to talk to it. Yes, it's running and it sees the real hardware talking to it. So now we can just take a separate window okay, hope it's right. So that's a magic to run the pulse view and substitute it with the freshly built patched Seagrog library where we should be able to see the nice device. Let's see if it's still working. Okay. We have to find the device and it's here. V-G-TEC is just another piece of the vendor specific code to make it possible to talk from the J-TEC interface of the FPGA to their custom J-TEC connected logic inside the FPGA. But it's easy to be replaced and we have to talk over the network to our server and it's running on the same machine. Just different numbers. We scan for it. Yes, it's here. That's nice. Now we can set up a trigger for something interesting as our dead state for the feedback shift register which is all zeros and it takes me some time. Oops. Okay, probably it's not all zeros but nevertheless. And now we can switch it just to make it run faster and zoom in. So it's a linear feedback shift register but running now not blinking at two hertz which are suitable for debugging on the LEDs but running at a full speed. I think the system clock frequency is 25 mech errors at the moment so it's just an external clock. So what we see is that it's possible with the free and open software tools to look inside the running FPGA. And I'm really pleased that the demo is working life. It's nice to have a small demo but the real question is where we move next and what important things to be done. I think the most important thing to be done is an integration between tools because nobody would ever be able to convince any hardware developer or any FPGA developer for the debugging to switch from the vendor tools you're using with one particular FPGA to the open source tools. If you have to take this part, it's written in C, you have to compile it yourself with your own page library, then you have to take this part and write a configuration file on Tickle, then you have to take that part and yeah, it's written on Ada, you have to compile it for your system as well and then you're probably, if everything goes well, you have to connect it to your hardware and then you can debug your hardware. No, it would take me weeks, it takes months to debug, only the debugging tool chain. So some nice integration and that's something to debug in standards and interfaces. IEEE standards take real long time to get accommodated and then of course an integration with the GDB. In this sense, it's pretty good because Open OCD supports the GDB, remote debugging interface and many, many different hardware cores but still missing the integration with software support and all these code, all the examples are available on the GitHub page, you can link to it, you can send patches, you can download and start playing with it and any questions you might have. Thank you for your attention. Oh, yes, please. In terms of debugging and hardware, you usually trade off visibility for speed. Do you see value in simulation for finding these kind of like basic hardware bugs? So the question is the visibility versus speed during on hardware debugging. Yes, with some time it's a problem and simulation is good to catch the logic errors but it cannot catch all the hardware and racing conditions problems. What is good with the instrumentation running on the FPGA itself on hardware debugging, you are let's say less restricted by the speed because JTEC here is running it's something like one megahertz and the real signals we saw captured are running full speed 25 megahertz, they could run 100 megahertz and actually this demonstration came from the actual project I've spent last year working on on the micro-SMI FPGA where the actual signals were coming at a gigabit data rate but it still was possible to capture them at the gigabit rate on the part of the FPGA then buffer it, re-synchronize and look through the slow available debugging interfaces. So yes, there are such problems, no simulation can solve all of them on hardware debugging is needed for that and it makes it easier somewhat. Okay, sorry, we cannot have more questions. I'm sorry but yeah, you're welcome to drop a message or just stop by later.