Hello and welcome to this lecture. In this lecture we'll see how you may end up getting a false positive using the clock delay range operator if you're not careful, and we'll also see how to solve that problem using local variables. So let's start with a very simple property. And this property and as you have seen before, since our look assertions is a multi threaded language, so in this property, I'm saying that when ready is true, it implies at at that time with overlapping operator, that ready act must arrive from within one clock to five clocks, very simple property. But let me show you what happens. So he has ready, ready and claw.

Now let's say that he arrives at this clock and within one to five clocks 123 and four clock, let's say ready arrives when that happens the property will pass. But let's say that ready also arrives at the very next clock as shown yet in as well as also looks for RadioShack within one to five clocks and it says one two and three, three clock later already. So, it also passes. But how do you know that this ready either came for s one or s two for example ready I came for s one but it never came for s two you will still see a pass indication because as to have no idea that the radio game for as one. So this is a false positive. And this is very dangerous.

It's not a limitation of the language. It's just a way the multi threaded concepts or semantics of the language works. So you have to be very careful when you use clock delay range operator for false positives. So let me show you a simulation log on how this false positive can come. So add at 30 at 20. Ready becomes one.

And then at the next clock, we recognize it and enter v enter the sequence already arrives. So that's the first ready now we move along and then a second ready comes at 70. And we enter the sequence and we say second ready is detected. But at 90 radio comms and vote ready is will be considered acknowledged, and the property will pass. This is a real simulation log from my test bench. And as you can clearly see that the property passes on a single radio for border radius.

So how do we solve this problem? That's where the local variables come into picture. So the way to solve this problem is for every ready, you need to create a ready num, some number associated with ready in your test bench. And also for every ready act, you need to create another number that's associated with a ready EQ. This is very similar to ID bass bus, for example in axi reads or writes can be pipelined. Before one raid is over, you can issue another read and the Only way your hardware would know, or data came for which read is when an ID is associated with each read.

So the concept is the same here. So what I'm doing here is I'm creating a sequence ready, check, and I'm declaring a local variable called local data. Then in the sequence as we have seen with local variables, local variables must be attached to an expression. Since I don't have an expression, I simply say true. One, take B one, and at that time, remember or store the readiness that you created in your test went into local data. Also, notice that with any expression, you can attach any sub routine.

So here I'm simply attaching $1 display. So as a side note, this is a very useful way that you can put dollar this way statements in your sequences or properties to help you debug as you simulate your design. So I am storing writing them into local data, then I have to wait for one to five blocks. And then I'm checking to see that radio has arrived. And if radio is true, then I also check to see that that radio num is the same as the one that was stored in local data. So, this way, we know that this radio economic is associated with this ready and when you do this, you will not get a false positive because we are checking for every readiness, the associated radiate now.

So in our in our case, when first ready, comes, let's say ready now We ready equal to one and then when ready He comes reject to see that ready act now numbers also want and then less seven ready comes again and let's set for that we do not get ready then during the property when we are waiting for one to five clogs, you will see that if readin act numb did calm and it is still one than the property should fail. So this is how you will solve the problem using local variables. And this is a very important concept you must understand and see how local variables can help you with pipeline multithreaded assertions in system our log. So here's just a simple log. First radio arrives. And here this display statement is is coming.

It's coming from the display Man that is that I just shown short here, enter sequence local ready now we call the local data. So, first ready arrives then after some time when ready arrives, the sequence checks to see that is ready act number corresponds to the force ready now any of that is true then the property passes. So now we have made sure that the ready act that arrived is indeed for ready number one and then when second radio arrives we we check to see whenever ready arrives again like here that the red Vietnam do is equal to ready now. So now we know that they're ready, arrived for the second ready and if the numbers do not match the property phase so in this As of course I have may decide that they're ready now my ready economic match and the property passes. So please revisit the slides if you're not sure how it works.

And make sure that you take care of false positives in your design. That's all for this lecture. Thank you.