Hello and welcome to this lecture where I will discuss how to fire a concurrent assertion from our procedural block and also show you how multiple implications work in a property. So far we have seen only properties with single implication. So let's see how to fire and how to understand a concurrent assertion from a procedural blog. So, I have a simple property here called PRG with a relationship between request and grant. Now normally we would assert the property outside of a procedural law. And this is how we have been doing throughout the course.

And in this property there is an antecedent called be state equal to cycle start. If this is true fire the consequent Now also covering the property like we have done all this time. Now, inside a procedural blog, for example, always at posit of claw, you can have a condition here and in this case I have a condition here which is a same as a condition of the antecedent here, meaning you can have a very complex condition here after which you would like to assert the property. Now, here I've shown a very simple condition, which here acts like the antecedent of your property, when you find it or declare it outside of a procedural block. You can have a very complex condition here including a complex state machine and based on a certain state in your procedural code, after a certain condition you would like to fire the concurrent assertion.

So in that sense This entire condition acts like an antecedent. And you may not want to duplicate this condition as an antecedent when you find the assertion outside of procedural block. So it's a great benefit because it has a flexible control over when to fire an assertion. Now, note that you can cover a property that has been asserted inside a procedural block, there is no issue that the other point is that you can assert a property from a procedural block you can also cover a property from the procedural block. Now whenever we set a property, we need a sampling edge, a clock edge so to say so when you set a property procedurally, that clock is derived or inferred from the outer, always blog. When you have a clock define, so these pauses of clock ends up becoming the clock for this property, just like outside of the procedural block, you have a positive clock.

But the main question that we need to answer is this is a sequentially executing procedural block. Why this is a concurrent assertion. So how do these two work together? That's in the next slide. So in this slide, I am creating two properties PR one and PR two. Pr one says if C star is high fire request and grant specification, and we are to say is that on the falling edge of a straw, either right enable should fall or read enable should fall and I'm covering the property outside of the procedural block.

Now, inside the procedural block based on some condition, let's say check, right I am asserting or firing two properties one after the other. I'm saying assert property PR one and assert property PR two. So how will this work? Will PR to wait until PR one is complete and then fire? The simple answer is no. Both of these properties or however many you hire will all start executing concurrently, each one as a separate parallel thread to the procedural code.

So in other sense, when you assert a concurrent property from a procedural block, it is non blocking. So let's look at this log file. When c start is one, this property's antecedent is true. At the same time, a strobe goes from one to zero. So the antecedent of this PR two also is true. So both assertions will fire at the same time start executing at the same time, one clock later right and they will go zero which is the consequences of PR two.

And as soon as that happens because this is an R br two will pass no note that request have just gone high. So PR one is not complete but PR two is complete and it passes. So in other words, PR two did not wait for peer PR one to complete. And then one calculator, ISRO falls again and the execution or PR one is continuing from the previous talks and then grad falls here and at the same time read enable goes to zero. So when read enable goes to zero, we are to his company and when grant was granted goes high br one is complete. So, both properties will pass at the same time.

So, this clearly shows that when you fire two concurrent assertions or more from within a procedural block, they are non blocking and they will all fire at the same time. There are some error conditions and they are based on how you supplied the clock edge or the sampling age. So, for example, you can say okay fine, I'll say always begin. If some condition and then at pauses of crowdfire this property seems very logical, but that's an error. Because the claw for the set property here will always be derived only from the always statement and you cannot have any temporal domain is a statement before you are set up properly. And so, this is this shows that this is the right way to do it because the bondage of clock is in the same statement or it is with the always block or or you may save that you know after the condition is true at some other assertion of a given clock or some kind of an edge that you have set the property again, the point here is you cannot have a temporal domain statement before you set the property you cannot even have a pound one because as a temporal domain statement and this also will give you an error.

So, again, the clock for the concurrent assertion fire from a procedural block is always derived from the always statement Now, this is a different topic here. All this time I have shown you that when you are you have a property appear one and when you assert it, I will simply say, go to a task execute of a task either with bass or Wi Fi. I didn't this faint ask I normally just show a simple display statement. And that is fine. Here what I'm doing is because else fail task task is a regular system where log task, you can do whatever you like to do in this task, just like you were doing any other part of the system or log goal. But here What I'm saying is as soon as I get into this task, right away, I'm going to display that from faint as zero.

This is just a numbering system to tell you which display statement is being executed by Then I wait for a claw and then I say that from a task one, then I wait for another clock, another clock and another clock. And then basically I fire five different display statements. So, when the property phase for example, and you have a task in which you have temporal domain execution, how is it going to work? Is the property going to wait in the failed task is over? The short answer is Yes, it will. You will have to be very careful if you put temporal domain execution control from either the past us or the failed task.

So, here's here's an example. After a request goes high on on at time 30 at time 72 clocks later grind should go high as demanded by this particular property, but it does not so We go to the faders. And right away we get this statement out saying display from feta zero. Okay, now one clock later we get this tape it failed task one. But now observe at time 110 request goes Hi again, here request goes Hi again. So this property should fire again.

But it won't, because you are still executing the fail tasks from the previous assertion of the property. So then you will continue to go through filters, two filters, three and filters four. But the fact that the quiz went high again, that means the property should have fired again, and then it should have passed at 150. Because granted one two clocks later, it won't, because you're still educating the fate as from the Fighting of the previous assertions. So you have to be very careful, because this fate as our past starts are blocky. And unless they're completed, these assert assert property is blocked.

And it doesn't matter if Dan descendant goes through again, it won't fire it. So be careful if you are going to put some kind of conditional temporal domain execution inside your task or past us, you will get effects that you may or may not understand. So revisit this slide if you're not sure. Also try it out in your simulation, and you will see what is presented here in this slide. Now, this is another copy. So far, what I have shown you is that let's say you have two sequences.

And I'm saying in property and blogs at posit o'clock is true Firebase sequence. I always stop here. I've only shown one implication, but you can have multiple implications you can say, if A is a slow it implies basic ones, one clock later if c is true that implies the sequence. This is perfectly legitimate assertion goal, but you need to know how this works and many people use this and successfully use it, but you need to know how it works. So for example, let's say A is true at time 175 Okay. So this sequence is fired as a consequent of this implication operator and one called later, b is equal to one as required here from one to five o'clock.

So then B sequence matches Okay. Now see what happens. One clock later you are expected See to be true barsy is not true, one clock later. So you may think let's say you did not have this part of the code. And you simply showed a implies B sequence one clock later C. And if c is not true, the property should fail. But it won't fail in this case, because C is now acting as an antecedent to the sequence.

Okay, so let's say C does go Hi, a couple of blocks later, as shown here. But so you maintain that okay, after the ABS sequence was fine, one clock later c goes high that acts as an antecedent to the sequence. So then, you know, you should look for the disagreements, but it won't because C was not true one clock after B segments and and the entire property was quote unquote discarded it will not wait till c goes true whenever and then fire the sequence, it will not hold the execution in the middle of a property with multiple implications. If C was not true after B sequence, then the entire properties again discarded and it will again wait for a to be true to fire the whole thing again. And next time they say is true and then B sequences true and C's true afterward call that the sequence implication consequent will be fired.

So you have to be very careful on how multiple implications work. You can use it effectively as long as you know how how they work. This is yet another dropping a topic I am mixing quite a few small topics. And this is a very simple topic, I'm all I'm saying is that this is a sequence very simple sequence as we have seen. But let's say with this particular sequence, you may require that 80 minutes asserted when B is asserted. And then a and b demon asserted when Caesar said, so when you read this specification, it may look a little daunting that oh my god, how am I going to model this particular specification, but it's very simple, just use sub sequences.

And all from this sequence. If I have to derive this specification, then all I'm going to say is a one crop letter A and B should be true, that means it should still be true and one crop later on Three should be true. So, using just simple Boolean equations, you can model complicated property. And then similarly here, I'm saying that A and B must get d asserted the very next clock after they are found asserted that is a specification. With simple Boolean equations again you can say a should be followed by a should be D asserted and B should be ascertained followed by both A and B should be DS at A and C should remain asserted. So, this is a very simple slide simpler, simpler simply to show you how to effectively use Boolean equations to tackle complex specifications.

And finally, this is a simple example of simulation performance efficiency. Normally what we do is for example, in this property will say if ready is true, then ready x should go Hi anytime From one crop to forever, it can go high anytime. And this is how we would model it. But it is advisable to avoid long or in finite time ranges. Because there are other ways you can do it. So, the same thing can be modeled with a goto operator, you can simply say that when ready is high ready it should go high at least once, which is the go to operator which is identical behavior as what is shown here, but this will simulate faster, the simulator does not have to track the clock, every every clock after one clock to forever yet it will simply check to see if ready, it goes high, at least once.

So, a simple hint on how simulation performance efficiency can be affected. That's all for this lecture. A few different topics habit and tackle. These are all important topics that will come in handy when you start getting into complex assertions. Thank you