Hello and welcome to quiz number two, increase number one, we saw synchronous FIFO. And in the quiz two we will tackle and up down counters. The the source code for the entire quiz is available on my website define view.com slash Udemy lab files. So let's just go there first and let me explain to you what you can expect on the website. Okay, so on my web page, as you saw increased one you have synchronous vi for files. And for this quiz up down counter, you will have a readme as a counter.vi.

A counter underscore property.sv counter.vi is a simple design that I created of a counter counter underscore property dot s This is where you code your assertions. And test underscore counter.sv is a simple test file that I created in such a way that you can test out different checks, different assertions that are coded in property.sv. And I'll share these files in a second. And the.do file is basically a file that compiles and simulates the design. I have created that for the Questor simulator, but you can very easily adopt that to your favorite simulator. So let's start with the readme file.

So in the readme file, what you will see is the level overview, the lab database, what kind of assertions you need to put in your code and how to compile and simulate. I will going to the design specification. When we go back to the lecture slides, the database is something I just explained to you. And the checkers are the assertions that you need to write. I will again go through that when we go back to the lecture, slide and how to compile and simulate. Let me explain that to you via a couple of files.

Oops. Okay, let's. So let me show you counter underscore property.sv file. In this file, you will see different there are three assertions that I'd like you to model. And here's the check number one, assertion number one, then you have a session number two, an assertion number three. If you notice around each assertion I have an IF def check one if def check two and if def check three.

And I will show you how they relate to the.do file. So if we look@the.do file what I'm doing is I have a simple compile and simulate command for Cuesta it is V log for combine and we save for simulation. Now during compile, if you see I have plus define plus check one. So this is defined as you know in Verilog will pick up this code if def check one. And if and it will exercise this particular assertions as your son. The if you want to exercise check to then you simply go into your.do file and replace check one, which I do and so on and so forth.

And as in Verilog. Let's say you want to exercise all the three assertions that At the same time during simulation, then you simply say plus define press check one, plus check two plus check three. So this is the relationship between the.do file for simulation and your property.sp file. And I will go into the detail of these assertions when we go back to the lecture slides. In this file in this file, as you see what I've done is, here's your property. And I've given it a meaningful name already.

And in this property, what I've done is put a dummy statement, a dummy segment I've put so that when you download all the files and you fire the.do file, everything should compile. This is just a way to make sure that you have downloaded all the correct files. But when you design or model your assertion, what you're going to do is you're going to remove this file. I'm going to remove this line completely and put your code here If everything else has already been done for you, similarly, for the second recession also I have the same dummy line, this line does nothing, you simply remove this line and put your code in here and similarly for check three. So, this is the property dot CSV file. Now, let's go go back to our lecture slides.

So, the overview is there is a symbol of GM counter and counter assertions deployed directly at the source can greatly reduce the time to debug as we know in five fall so, we basically applied the assertion directly at the lowest level of FIFO specs. Similarly, we are going to apply the assertions at the lowest level of Congress facts count fivefold synchronous, asynchronous so on and so forth state machines, state transitions. These are the places where you will get the maximum bang for your buck when you put assertions. So the specs for the assertion are very simple. It simply says the counter is eight bit data input an eight bit data output. When the load count is asserted, it's an active low signal that means when is zero, data is loaded, and output to data out right away.

Now when count enable is high, it's enabled and when they when we say that do the counting, and if the UP DOWN counter is high, we basically count up data out equal to data out press one, if the UP DOWN counter is low, then we basically count down data out equal to data out minus one. And when the count enable is low, we do not count but we preserve the data. So as you are familiar The down counter is a very straightforward spec and I have designed this counter into counter dot v that you can look up the files are what I have already explained and here are the checks or the assertions that we are going to model. First assertion is check that when reset is asserted that data is zero. In most of your designs, you will have assertions around reset and as simple as they are, you will find on in initialize flops on initialized registers and so on and so forth and that will affect either the internal data path or external interface buses.

So, as simple as this as assertion nodes, it will give you a lot of value. The second assertion is that if load count is DSR date and count Unable is not enabled, then the data will be held in this previous state previous value. data cannot change if counter enable is not asserted or enabled. And the last assertion is, which is the most interesting assertion as we'll see. If load count is DSR date, meaning equal to one, and count enable is enabled. Okay, so now, basically we're saying do the counting.

And if the abdomen counter is one, the count goes up. If I've gone counter is zero, the count goes down. And we not never want to check the properties if reset is low. So now what I've done is I'm giving you the solution in this lecture slide. But in the source code file, there is a dummy line as I was just explaining to you so all you have to do is literally retype these properties into that file and simulate. Now that will look redundant and it will not allow you to exercise.

But believe me, the one while you're typing, you will think about how the property is written. And more importantly, I highly encourage you to write assertions in a different way, the same assertion. There is no one way to write an assertion. And if you try to write it in a different way, and if it passes, then you're definitely learned a little bit more about DSP. And I'm going to give you an example of that with the assertion number three. I've written the same thing in two different ways.

So let's look at the first assertion very straightforward. At clock disable, if reset is high, and Bangor said if the reset is low Then we go ahead and make sure that the data output is low. That's all we, we just want to make sure that data output is initialized all low. And that we are set the property. If it fails, we do a display. So you have seen so many examples like this.

So this is a very straightforward one. In this one, we have to check that if load count is high, that means it's DS are dead, we are not going to load the count. And the count enable is low, that means it's not enabled, then the data out should hold is previous value. So what I'm doing is, if this condition is true, that means if my antecedent is true, then I'm going to check for data out that means the current data out is equal to the past data out very simple. So that way we know that data out remained the same state as a previous one, when the load count was high and counter enable was low. So, the current data cannot change from the previous data if this condition is met.

And then we set the property. This is also rather straightforward, but it shows you how to effectively use dollar past. Now, this is an interesting one. The and I have purposely coded that into two different ways just to make a point that there is no one way to write an assertion. So here we are saying that if load count is to assert a and count is enabled, that means Okay, now with these two conditions, we need to start counting. If I've done count and count is one, then you know that count goes up, and if it's low, the count goes down.

So here, this this particular, oops, this particular property, property counter underscore is one way to do it. And I will explain that the same thing can be done in another way. And I call the property count, counter underscore count underscore local. So let's look at the first way of doing things. If this condition is met, if load count is high and count enable is high, it implies that if up down counter is high, we need to count up. In other words, the current data should be one less than the past data.

That means from past data, we have counted one up, it's kind of a reverse logic. But I just wanted to show you how you can use the past data to to make sure that the count is going up. Similarly, for the count to go down from previous data, the current data should be 100 So that way we know for sure that the count has gone down. It's a reverse reverse kind of a logic. So read this carefully, and you will know what I'm trying to do. I'm looking at the past data.

And, and then I'm checking the current data. It's opposite of what you may think. Now this is simply to showcase that it can be done using dollar pass data out and simulate this and make sure you understand this code. It's already I just type this in in place of the so far down the line in the source code and see that count goes up or down goes down. But I have a much better way of coding the same thing. This is a bit convoluted, but let's look at how you can code this with a local variable, which is much more intuitive.

And I also wanted to make point that local variables are definitely variable For, for coding a lot of different types of assertions. Okay, so what I've done is I have declared a local variable called local underscore data of type logic. And it's basically an eight bit bus. And here we are looking at the same condition like we saw load count and count enable. But what we are doing is with this expression, I'm also going to store the current data out into local data. Okay.

And then, if this condition is true, if my antecedent is true, then I'm going to say if uptown count is high, then one clock later data out should be equal to the data that I had stored plus one, which is much more intuitive than what I just showed you before. So if you are looking at the past data, then you have to subtract one if you are looking at the current data Then you have to add one, when you add one, you can very clearly see that it's intuitive that the counter is going up. And if it's slow, then the the, the the current data should one clock later, whatever the data that you have stored, the current data should be one less than what data you had stored. So you can very clearly see that with the local data, it's it's much more forward thinking when you look at the past.

And again, I'm showing this to you, not to confuse you. But just to let you know that yes, you can look at the past data and do the check on the current data. Or you can store the current data and one clock later, you can check to see if the count did go up or go down. So please, again, type this code into your source code files that you download and simulate. And when you're typing, you will definitely try to enter And better while you're recording the video recording. And I can assure you there's a third way to code the same check.

And you can think about that and try that out too. So folks, that's pretty much the end of grades number two. And again, here's my link to my website. And with this last quiz, we are pretty much done with the entire course. The here's the book that I published in 2014. And it has 2009 and some of 2012 features in this book 2012 was not quite confirmed by the IQL committee, so we could not put those into the into the book.

Please check out this book is available on Springer and Amazon Pretty much what you saw in this course, you will find very great detailed description of the same concepts. Well, that's pretty much all folks. It's been a pleasure discussing all these lectures with you, and I wish you the best in your happy asserting and ever. And again, you can always email me or you can phone me, I have no problem with that. Or most importantly Udemy allows you to pose the questions directly when you take the course. And that I think is the best way to contact me.

But I'll be more than happy to answer your questions. Thank you so much for attending the course and I wish you the best