Hello to veg lecture number four. In lecture number three we saw immediate assertions. And in this lecture we'll discuss start with the basics of the concurrent assertions. In the rest of the course, this is these are the symbols that I'll be using the the top most high going arrows, so to say is what I call level sensitive Hi, these are my own symbols and this iPad would be the best way to convey the timing diagrams. What level sensitive high means is that at a given clock, so the clock ages in the middle of this arrow, that the signal was high before the clock edge, and the signal is high after the clock edge. And this becomes important when we go into the detail of sampling edge into the value of the signal that's being evaluated.

In the pre lb region, just keep this aside for now. Similarly, the downward arrow says that the signal was low before the clock edge and it is low after the clock edge. Now these are our regular timing diagram edges that you're familiar with. Now this means that a pause edge is expected on the signal, pause edges expected on the signal. Similarly a negative is expected on this signal. Now in order to see whether a property is is passing in a given timing diagram, I will use a green arrow going high means the property passes and red arrow going low means the property fails.

Okay, let's start with the very basics. here's the here's the specification. It says that at pauses of claw If cycle start is high, again high before the clock and high after the clock at this clock edge if see start is high, eight implies that rack is high at the same clock, and that grant is high two clocks later. If this spec is met, then at this clock edge, the property will be considered to pass. So, let's see. First, you declare a sequence.

A sequence is the key word and sequence is the keyboard. You give it a name. This sequence says that requests being true at the sampling edge, sampling edge or clock edge, I will intermittently use them, but they mean the same thing only that a sampling edge can be synchronous clock age which is what normally people use or for example, it can be a gated clock, which is asynchronous, but the point is it has to be an edge. So, at this bar the edge of clock requests being true that to clock later grant is true not bound bound to means to sampling edges or to clock edges, they cannot be level sensitive control. Do not confuse this with bound to which is two time units in Verilog there is this extra pound here So, the chances of misunderstanding are low. So, you have declared a sequence then you declare a property, property and property or keywords.

The property says that at positive clock if see start is true. Start the evaluation if cease artists True, it implies saga, it implies that Exxon should hold. Now this implication is known or overlapping implication. And we'll see what the difference is between non overlapping and overlapping. overlapping here means that the same clock at the start is high, that request must be high. So here's a property, then you have to assert the property property on it on its own is just placeholder, it's not going to fire.

So when you asserted you're triggering it, and he has a syntax. You give it a label. And just like with immediate assertions, you are better off giving a label ELS, the simulator will assign one for you. And that label may not make sense to you. So you assert the problem. 40 give it the name of PR one in parenthesis and declare that if the property passes, you will execute this display statement.

Pretty much like any immediate ELS, you will execute this procedural statement. I'm just going to leave this ad. At this stage, you have a sequence, you have a property and you assert the property and you give it a label. Now, I'm continuing with the same example to highlight some of the other points I just explained that you must have an edge at which the property is to be evaluated. You cannot have level sensitive and most of the time people use a synchronous edge. You can have an asynchronous edge But I will caution you right now that you have to truly understand how the assertions get evaluated on an asynchronous age.

But as long as it's an edge, the language is no problem, it will allow you that. Now the other key important concept here is that SR is a signal, a variable request is also a variable. And so he's gonna or signals. The CSR is evaluated as positive clock. The sequence doesn't have a clock, but it inherits the clock from this property. And we'll see a bit more on that.

And so all the three variables in start request and grant will be evaluated at pauses of clock and you have this action blocks as they are called. There is a past action block Property passes ELLs, there's a fail action block if the property fails. One important note which is slowly happening in the industry is that the simple assertions as I call it, are synthesizable. What that means is a simple assertion like this one will be synthesized, converted to gates and it you can you can, it ends up becoming part of your design. And you can go to FPGA emulation or even accelerator for that matter. And so, once the assertion is synthesized unless it's in the design in the FPGA, if it fires, for example, if it passes, I don't think we really care but if it fails, how do you know that it is fake?

There are so many ways that the EDR vendors have implemented Their own methodology on on letting you know that no assertion has failed. So for example here, what I've done is I've taken a 16 bit register, and I'm assigning it a value. And then through FPGA you can scan out this value. And if the value is F, you know that this particular assertion fee, which is this is the easiest way to debug. And since the assertions again are being synthesize is a great boon to productivity and debug ability. Okay, what I've done is he had I had request and Grant has only two signals.

In this slide I have added a little bit more complication. Before we go into this, I want to point out that this see starts something that appears before the implication operator is called antecedent. This is the implication operator. And then anything that appears after the implication operator is called consequent. So you will hear me say antecedent fire, consequent fail, so on and so forth. So you know what that means.

And this going back to this one, all I'm pointing out here, that it can be a very useful and very complex Boolean expression. And it's interpreted the same as a conditional expression of the procedural if statement. And just like a procedural if statement, if the Boolean expression evaluates to X or Z or zero, then is considered to be false. That means the property will fail. So that's all in this particular slide. And one more point here.

That this Boolean expression can also include function calls. So the point is that in the sequence you can have temporal domain like we have on Pong too. And you can have very sophisticated expressions, including function calls. Going back to the implication operator, like I was telling you that this this slide, let's let's go back here, here I have a sequence with this particular Boolean expression. In this slide, what I've got and in this slide, this will an expression occurs in a sequence and then we call the sequence here. What I'm trying to point out is that you don't have to have a sequence in your design of your assertions.

You don't have to have it. You can take that entire Boolean expression and put that directly into the property. If it is a simple expression, Then it's okay for you to do this. But I highly recommend that a complex property should be broken down into smaller sequences. When you read a given spec, the spec may look daunting and you may start scratching your head on how am I going to model this assertion. Take smaller portions of the spec, create sequences of those smaller portions, and then tie them all together.

How hierarchical sequences do it we'll see more about that. And then tie them all together and then in a property defined and what I call intelligent antecedent, and fire the consequent, which will have a sequence here which we'll call one sequence, which may call another sequence on and so forth. So I will show you exactly how I break down complex specs into smaller sequences and then design the assertion it'll be much easier to design and much easier to debug. So, what we have seen is you have Boolean expressions, those are used in sequences Boolean expressions can also be used directly in a property like I just showed you, but this is what I call the language hierarchy, try to follow this hierarchy for you to be able to design assertions VDS that is the property and then that is the assert statement. That is also a cover statement that is also in a zoo and there is also an expense, you can insert a property cover a property assume your property and expect and we will see cover as you might expect in much more detail in coming up lectures.

Again, going back to the implication operator Like I said in a previous slide, this single dash here is the symbol for overlapping operator. And overlapping means that whenever the antecedent fires that the consequences start segregating or start firing at the same sampling edge, which is pauses of clock here. As you can see in our example, that this implies that whenever see start is high the request must be high and then to clock rate again must be opposite to that or not opposite, but a variation of that is non overlapping operator and the difference between the symbol is here you have a dash while here you have an equal to sign. What now, what non over non overlapping operator says is that, if at a sampling age which is pauses clock here antecedent is true. If See, start is true, they're starting the next clock, not the same clock, starting the next log you sample request to be high.

And then to grok later use sample grant to be high. And the word sample is important. If you want, I won't use the word detect sample because you will see what sampling means at the sampling edge in the prepon region. We haven't covered that yet. So just keep that in your back pocket. So yeah, that's a different region overlapping overlapping is it's the consequence starts at the same clock age.

Why non overlapping is where the consequence starts at the next clock edge. Let me show you a very simple use. Now. overlapping means started. The same clock edge sample start consequently the same profit. But if you put bound bound one, that means start at the same clock edge, but wait for one clock before you start executing the consequent, which is the same as you can see as non overlapping operator.

And I'm pointing this out, which I'll explain in just a second. So, the point is here if you use this, it is the same as non overlapping operator. Now, let me give you a project wide hint or suggestion. As you can see, overlapping operator is a subset of non overlapping in a project wide methodology, if you don't have guidelines then some people may use non overlapping some people may use overlapping some people may use overlapping with upon ones some won't when you are debugging unless and until you have another screen with exact assertion in front of you, if you're looking at the timing diagram you do not know what is expected Is it the overlapping that is expected or non overlapping. So, my suggestion is that use overlapping it is a common denominator use overlapping and then use found one one if you want the effect of non overlapping, you cannot go from non overlapping to overlapping but you can go from overlapping to non overlapping and then project wide methodology you can suggest that everyone uses only the overlapping operator and then use upon point one if you want the effect of non overlapping that then when you're debugging you know that the antecedent and the consequent are The implied the implication relationship is overlapping all the time.

And that will definitely help you even design and debug your assertions project wide. So I'm going to leave this at this stage. You saw the basics of the concurrent assertions, you saw the sequence, you saw the property, you saw how to assert an assertion, you saw the implication operator and the difference different styles of implication operator, you will we will see a lot more on sequences and properties an antecedent and consequent. So thanks a lot for attending this lecture and I will soon see you in the next lecture.