Hello and welcome to our first squeeze this squeezes on writing assertions for a synchronous FIFO. As we had seen earlier in one of the lectures, I've already described to you how to write assertions for an asynchronous FIFO. So, the quiz here will make it actually simpler to write assertions for synchronous FIFO all the source code that you need to simulate a your the FIFO design are on my website definer.com slash Udemy lab files. So, let me just go there and show you what you will see when you go to this website. Once you go there, you will see that I have two labs one is synchronous FIFO and another is up down counter and this is what we are going to cover in this particular course. So this quiz is On synchronous FIFO.

And the files that you will see here, our README file for dot v five for underscore property.sv, test five for.sv and run check or God do file. Let me just show you the readme file first and explain to you what's in it. It has pretty much everything that you need to exercise this quiz. There's a level overview, and I will go into the detail of this level overview when we go back to the lecture slides, so I'll refrain from explaining it here. Same thing with a database like I was just saying, that is FIFO dot v. And this is the very long RTL for FIFO This is my own FIFO that I have created FIFO property.sv This is the file in which you will code your assertions and I will show you that file in a second and test 500 So this is my simple test bench that basically exercises the five for underscore property assertions as applied to five, four dot v. And in this test file, I also do the binding of Pfeiffer dot v with five underscore property dot s3.

So you got one more example of how to do binding, then the next thing you need to do is go to the assertions. And there are in this particular example, there are seven different assertions that you should try to code. And I will explain each of those again, when you go back to the lecture slides. And in the lecture slides, I'm already giving you the solution. But in the source code that I'm putting on the website here, I'm not putting the solution file. So you can look at the lecture slide file, look at the solution and type it in your property.sv file.

Even though you already know the solution is Still good for you to type it in, and and simulate. And I will go into further detail of how to write these assertions and how to find these different checks from the test file. And then that email also shows how to compile and simulate step by step. And I won't go through these steps right now, but I will show you how these steps work with the 500 score, property.sv and the.do file. So that's what we have in the readme file, pretty much everything you need, so you don't need to remember anything, even from the lecture slides. So let's look at some other files.

The the FIFO is my design of FIFO synchronous FIFO is a very simple file. You have the FIFO data out FIFO phone five empty FIFO right FIFO read, clock reset and five for data in and I won't go through the entire logic because this is your simple Verilog and you should be very easily able to decode it what are the things you will see in this file? Think think like if and def check one or if def check two if def check five, so on and so forth. So, what I did was in order to help you exercise the assertions that you write in the design itself, that means in the FIFO dot v itself, I have introduced some bugs. And based on the plus define plus check, one are checked or check fi or and so on and so forth, that you put in your.do file, I will show that you in a second that one of this bug will be introduced.

And that's the bug you need to catch with the assertion that you quote in your property.sp file. So that's how I have designed this quiz. And it should help you a lot. Now let me show the property.sp file. This is the file that you To modify, you don't use Fiverr dot v, you don't touch the test or just go five four.sv you only touch five folders called property.sv. Now in this file, you will see that I have different quote unquote checks.

So as you saw in the readme file, and also in the lecture slides, you're you're going to write seven different assertions for this particular FIFO. For each assertion, what are you going to do is specified right here in the source code itself, what kind of assertion you should write, but what I've done is, I've written a property, for example, check reset, then check Five, four, empty property 544, so on and so forth. But inside the property check reset, for example. I'm saying that advantage of clog bank reset implies the red pointer is zero. Now this is a dummy assertion this has nothing to do with checking the reset. I simply put this here, just to make sure that you can compile the code off the bat.

When you download all the files and you run your simulation that everything compiles and you you have a good sense of confidence. Now what you're going to do is you're simply going to remove this line, simply delete it, and then put your assertion the correct assertion here, and then run the do file. Let me show the do file. Now I used mentors, Cuesta simulator. So they have the concept of God profile. And this is a very, very simple setup.

So there's a very good chance you should be able to take these few lines from the.do file and apply it To your favorite simulator So what I'm doing is inside the property.sp file I have if def check one and then inside the god do file I have plus define plus check one. So when you run simulation for example for Cuesta, you say V log minus SP five four dot v, five for underscore property.sv, test underscore five four.sv and plus define plus check one. So plus define plus check one is going to pick up this particular assertion and simulate is not going to look at any other assertion. I want you to try one assertion at a time so that you you're fully confident in making sure that that assertion works before you go to the next one. So and this Plessy fine press check one will also affect the FIFO dot v like I was showing FIFO dot v will introduce a bug and this assertion, with the check one if they've checked one, Bill Gates That bug.

Now in order to simulate character is very straightforward you go inside the.do file and instead of instead of check one you change check one, two, check two, and that will pick up if def check two, and so on and so forth up to if def checks seven. So all you have to do to exercise different assertions, you simply go inside the.do file and replace, check one, check two or three or four or five. If you want to exercise more than one at a time, then the waiver of works is a plus define plus check one plus check two plus check three. And if you want to exercise all just put all the checks. So that's all it's very simple and then you do v same this is the question again, you have to say minus assert debug minus coverage minus C, and so on and so forth, and then run up to the end of the simulation.

So the the again, to reiterate the file that You will change is the property file, in this case Five, four underscore property.sv. And, and the.do file where you pick up, either check one, check two, or check three, so on and so forth. So that's what you'll get when you go to my website, you'll you'll have all the files, you don't need to rewrite anything just save each of these file, download and save each of this file, you simply need to click on the file and the file comes up. And then you simply save it as and now you have the entire database. Now let's go back to the lecture. Okay, so synchronous FIFO.

So what are we trying to do here? It's a simple synchronous FIFO. It's very common, either you that was synchronous or asynchronous. And what we are going to do is put assertions directly at the at the depth of the FIFO. So, if anything goes wrong within the FIFO, we will know. Again, the you will basically learn about various Pfeiffer sessions.

You will also learn about use of Boolean expressions and sample value functions. As part of this exercise. The FIFO is eight bits wide, and eight deep. Eight, Edwards FIFO FIFO inputs are FIFO, write FIFO, read, clock reset and FIFO data in and FIFO outputs are five for full, five for empty and five for data out. If you are familiar with fiber designs, this is a very typical five for design and FIFO port list. Here again, here's your FIFO seven words eight bit wide.

Here's your five for data in. Here's your five for data out here. clock and reset know that this is a synchronous vice versa there is only one clock as opposed to asynchronous FIFO, where you had a right clock enter rate clock, here's your reset. If you're if you're here in the FIFO is of FIFO is empty, there's nothing and if you're here for school you cannot write anymore and after this you can read anymore and this is the read pointer and this is the right pointer. So this is your FIFO and the the spec say that right pointer increments by one every time I write is posted to the FIFO on a five four write request, which makes sense and read pointer decrement by one every time of four read request comes in. And then in order to have the correct notion of FIFO full and empty you need to have account.

So it maintains a count that increments on a right and decrements on a read It is used to signify for full and FIFO empty conditions. So, when FIFO count is greater than or equal to seven five portfolios are certain, you have already written the eighth location. So you cannot write anymore. So FIFO is full. And similarly, if you have already read the zero location, then five, four empty is inserted. So this is the definition of your duty.

Now, let's look at what kind of assertions we need to write to check this FIFO. This is what I just showed you in the readme file, you have three different files. Now, let's look at the assertions that we need to go to make sure that this FIFO works as intended. First check. First thing we need to check is that on a reset, rate pointer, right pointer, count five for empty and five for full are all zero. As simple as this may look, this kind of assertions actually catch a lot of bugs because there's a good chance of that has not been initialized in RTL and you'll catch it.

Second assertion is that FIFO empties asserted when FIFO count is zero. And in in most of the assertions disable this property if reset is still asserted, if reset is low in this case, so, I may write in assertion to see that vi for MP is asserted when FIFO count is zero. Similarly, right in assertion to see that high for full is asserted, anytime FIFO count is greater than seven and visible the property of reset is illustrated. And check that if I fall is fall in you attempt to write but not read that right pointer does not change. Because right pointer is already at five four fold you if you're trying to write something and if right pointer changes then you have a bug. Because you cannot write any more than there is no reason for right pointer to change.

Similarly FIFO is empty Then the recorder should not change because you're already at the zero with Word, you cannot go out to say negative, you cannot go anywhere. So red pointer should not change. If red pointer changes, then you have a bug. And then of course, write a proper property to warn on five or full and warn on fire for empty. So these are the seven different assertions that you should attempt to write. But since I'm a nice guy, I'm already giving you the solutions for this seven.

But still, you will go download the source code that I just showed you. And in the property dot CSV file, there are dummy lines, you're going to remove those dummy lines and then basically apply this or rewrite the solutions that I have given here. And even that will help you a lot with simulation and getting some get your feet wet. With assertions. So let's look at the first check. The first check says that on reset all these pointers should be zero.

So it's a very simple assertion, we are going to give it a meaningful name property check, reset, at pauses of clock. If reset is, if reset is asserted is an active low signal, save reset is low, eight implies that at the same clock, all of these pointers are zero, we have put a logical end in the middle for each of them. And then we are going to assert the property and display if it fails. That's pretty much it. It's a very simple, very simple assertion, and it should check for your initial condition. Next property is checked that feifei empties asserted the same clock that FIFO count is zero.

And I just noticed here I found a slide I have forgotten to put here count equal to zero. So please add that here. See I just found my own bug. The second assertion is that FIFO MPs asserted the same clock that FIFO count is zero. So, this is this is very simple at pauses of clock, if count is equal to zero, it implies that pi four is empty, and five for empty and count these are all different signals and variables in your design. The third assertion says that five should be full whenever the FIFO count is greater than seven.

So property five full orders of clock if count is greater than five for depths minus one it implies by football. Now I purposely put five for depth here, so that because I forgot After going over the parameters in the design, and I wanted to make sure that I try to keep the property as generic as possible. So the FIFO depth changes from let's say eight to 16, then this property is still meaningful without changing anything here. So these are very simple assertions. Let's move forward and look at some more assertions. And now here we are saying that if if FIFO is full, and you attempt to write but not read, because if I first fool and if you try to read, that's okay.

But if you attempt to write on a five, four fold, the right pointer should not change. So here's the property again, give very meaningful name 545. All right, stable right pointer. And we are here saying that at pauses of clock, five, a five four is is full and five plays right and FIFO is not reading Eight implies that right pointer is stable. Stable means the right pointer was a certain value, which is basically seven in this case. And it's still seven or still the same as the last value.

And that means the right pointer has not changed. And in that case, our assertion has been met. So please take this code, write it up in your property.sp file and simulate. So here you can see a sample value function being used. Similarly for a FIFO is empty in your attempt to read but not right. If you can obviously write when the fire for example, because you're supposed to fill up the FIFO and so if the FIFO is empty, the read pointer does not change.

So here the property is 5.0 Each stable read pointer. And this is very similar to the right pointer. Your Five, four is empty. And if you're doing a FIFO read, and if it's not a FIFO, right that the read pointer should remain stable from the last talk. It has not changed. And this will catch to make sure this simple assertions actually catch a lot of bugs.

You'll be surprised how many bugs you'll find in a FIFO. That's my personal experience, five flows, state machines, counters. And then obviously, the high level assertions on bus interfaces bus protocol is where you catch the bugs. Now, here's the simple thing that we want to make sure that if I first fall that we will not right. So basically we are saying a property right on full FIFO FIFO. Fall implies bang FIFO right.

That means you're not going to write if you If you end up violating this, then basically you're trying to overflow the FIFO, which is not allowed in this design. There is no back pressure point here. So it's it's a buck. And similarly, a FIFO is empty, then you should not read from an MP FIFO. So on the property read on MP FIFO, at pauses of clock, five, four is empty implies do not read bank FIFO. Read.

So these are very simple assertions. And I want you to start slowly but surely, make sure that you are able to simulate, you have all the files you need to simulate. And one of the other things I'd like to point out is, there's not just one way to write an assertion. You can write assertions in many ways. For example, instead of dollar stable, try to use dollar pass. How will you use dollar pass for example, and, and so on and so forth.

So don't just restrict yourself to the solution that I have given experiment trying with some other features and see if the assertion still catches the bug. So that's pretty much it for this lab for the synchronous FIFO. And again, go to my website and you will get all the files that you need. So thank you for attending this quiz. And I will see you in the next lecture which is our second quiz.