Okay. That was looking and seeing and comparing and hearing what's useful. This one is a little bit more specific though let me ask in between, do you have questions for this more basic stuff so far? You are on the lucky side because all the documents are available there. These are two slideshows. I gave even two more PDF documents to Dave because that is more background information. I have one info from last year, it has 70 pages and it's a shrinked version of a 200 page document. So, if you want to see it in detail, he has the documents available. No, I gave four in total, so one is still missing. Got it. Yeah, but that is from the webpage. So, go to, anyways it's available or regular document. So, we had the ETM training, this name is available. We see it in slide also. So, this one here, how many clocks did it to take? CPI means clocks per instruction, and we see it via our eyes that function, instructions statistics. So, the instructions statistics as a listing, looks like this and we have here already clocks and Clocks Per Instruction, as a result and info for you. But you need to know its trace buffer that we filled here and for this ISTAT you need always to add to trace buffer into the calculation. So, when you open up this window, I froze it that's the reason why it has the hash lines so it can be the same command. So, that is before you hit the plus-add button here, this one, plus-add. So, there's no database and that means you have zero here. Then when you take the trace buffer into consideration, into calculation, then we can calculate and then you have to info here. So, don't forget, if it is empty and yellow. Yellow means it's not good. It's not covered by the trace, then remember that ISTAT command needs to add. For sure you can also write in a command line ISTAT.add, that's the same. The script could do it for sure also. So, here we see high level language code and here was assemblage mixed so both is possible. Each of the lines and how often they were executed, well, we saw that on the slide before it was like 3,400 times so the whole application was in a loop. So, this one is like about 20 times more often executed. So, you can see 65,000 and 69,000 entries. This is the total number of clocks that are took and when we divide it again then it's about 99 or more than 99 that are took. So, it's quiet slow but don't forget that this year is high-level language display. Yeah, so the complete four-loop, this part of the four-loop took that long. To have the clock per instruction here, I marked in orange. The count is immediately there when you hit the Add button. But clocks per instruction is orange marked and that has as requirement that you activate the ETM to have also cycle accurate tracing. Only with cycle accurate tracing you will have this and for the green one. Is there unused code? So, it's a different problem that you have now there. The other one was something executed, how fast, and so on or often, how many clocks? Now the question is, you have something and it's good and now you are interested into security safety checks. So, the topic comes up, code coverage. Also code coverage is something that you can use with the Trace tool and after. Also here you, hit the Add button again to take the trace buffer into the calculation, you will have results and regarding the coverage it says, this range never executed, this range okay, and this one also never executed. Well, you saw I explained before when I'm tracing focused with trace-on trace-off, that I will not have all the code execution, I will have only a part, that is exactly what happened here. Only part due to trace-on and trace-off. So, I was tracing only this part. So, according to the trace buffer, the other parts were not executed, they weren't traced. So, it gives you a good information also regarding that, sometimes you cannot trace all of your application in ones. You need to run several times through your application and also one of the last slides tells about MCDC code coverage and 18 to 4B and everything before 17 and here 4C, that is what's not okay or not in the trace buffer. So, here you have okay part, 100 percent covered and well 100 percent covered. Here you have the information 40 percent executed. That is according not to the lines of this functions z, that is the total z, and a part of it was not a no-trace buffer so well, we have only 40 percent and if you calculated, here's the brown frame, it's a total of bytes. We say it has a total of a 128 bytes. So, executed 52, the half is 64 so it's less than half so it's 40 percent and you see it here. This 52 is exactly what's in the blue frame here. So, we make a relation like I said, you do not need to think so much about the numbers here because, well, we use the computer to calculate it so it will be correct. So, that is also something that customers use quite often. So, if you are working in some defense industry or some avionic industry or automotive industry, they have different standards. So, one standard in the avionic is like DO178C. One in the automotive industry is the 26262. So, they require that you document what your application is doing and if the code that you created is really necessary and used, because if you have some old that code inside, maybe there's somewhere a condition in you're if-else and somewhere or when interrupt is coming or somebody pushes a button or so and then this code that nobody expects ever to be executed again will be executed and you don't know what happens. So, that is why code coverage is done, and that is why we can check or the customers can check what parts of code are covered and maybe they need to push a button to see,"Oh, yeah. Then other code is also covered".
