Hello, and welcome to lecture number 20. This is a short lecture, which I have devoted specifically to asynchronous FIFO assertions that are synchronous workflows. And obviously they're asynchronous ciphers. We will cover for synchronous FIFO into one of the quizzes. But asynchronous FIFO is very important because I'm pretty sure in your designs, you will come across asynchronous five fours all the time. And one of the key places where you put your assertions This is a general rule of thumb.
The key places where you put your assertions are around FIFO or around both types of iPhones because that's where majority of the bugs emerge. Okay, let's look at an asynchronous FIFO. Let me show you this diagram here first. This is a a deep FIFO it has right clock recall Reset, because there is a right clock and there is a read clock. They both work off of different clocks, or they can work off of the same clock, but there are differences in their phases. For example, because of that this is an asynchronous FIFO.
You we'll have five for data in you have five for data out. This is a five five empty condition obviously, and this is the five for full condition. And this is the five for right pointer, this is where five four will write. And this is the FIFO read pointer, which is where, which is from where Pfeiffer will read. Now, most of the assertions for a given FIFO synchronous or asynchronous are very straightforward. But in asynchronous FIFO as I just say, the write and read clocks are asynchronous, which means that the most important property to change Is that a data transfer from right to retroarch.
In other words, whenever we write something at the right pointer, whenever read pointer reaches that same right pointer, that the data that we wrote must be the data that we read. If there is a bug, then those two data will not match. So let's see the different type of assertions that we will write for this asynchronous FIFO. First, let's check for FIFO empty condition. So, what does that mean? It means if the FIFO is empty, then the read pointer does not change.
That means you cannot read from an empty FIFO that's another way to look at it. So here's the property to check for it. At fathers have read blog no direct clock is different from right clock, which is quite specific to an asynchronous FIFO synchronous FIFO will not have that issue. Select positive read clock, disable if read clock reset is asserted, always choose your disable if condition very carefully. Otherwise you will have performance implications during a simulation, because you don't want to find your property unnecessarily. So here I'm disabling this property.
Whenever there is a read clog reset asserted. Then what I'm doing is I'm checking to see that if the FIFO is empty, empty is one of the variables in your design. It implies that at next clock at next pauses of read clock again, if past value of read pointer is unknown, always make sure that when you look at the past value That is not unknown. Otherwise you're going to compare past unknown value with current known value and things will fail. So, if it is not unknown, then we want to make sure that the current rate pointer is the same as the pass rate pointer, which means read pointer did not change. And that's exactly what we are looking for in this particular property, to see that if the five four is empty, we do not read we do not read means your read pointed has not changed.
So this is a simple assertion that you can write or you can pretty much use this particular assertion for your FIFO. Similarly, if the FIFO is for data, right, pointer does not change. This is identical to the previous assertion only that we are now going to deal with right clock. Right clock reset, and if it's full, then it bothers your clock. See, right is in advance is posted. So here we are simply checking to see that the right pointer is the same as the right pointer.
So these are identical in terms of FIFO foolin FIFO empty conditions. Now, let's look at the very interesting assertion or condition that we need to check. Like I said at the beginning of the lecture, that the most important thing you need to check in an asynchronous assertion is that data that is written at a right pointer or when data is written on a given slot of the FIFO is the same data that is read when read pointer reaches that right pointer, because the read the read clock and the right clock are asynchronous, and you're crossing the clock boundary. So this is one of the most important assertions you Right. Okay, let's start at the bottom. I'm asserting a property called Data check, and I'm sending it a right pointer hierarchically embedded into my design.
The idea here is that again, I'm giving the data check property quote unquote genetic parameterised so that I can always send it different right pointers from different parts of the design. And I don't need to change my code property itself. So I'm going to call data check with a given right pointer. Property data check defines two local variables PTR pointer and data of type integer. Then at the pauses of right talk, right clock because we are going to deal with right pointer in this particular condition. So you have to be very careful which clock you're dealing with.
Again, disable the condition If the right plug reset or read clock reset is asserted whenever a reset for write or read clock is asserted, we don't want to deal with this property, we don't want to continue any further. If that is not the case, and if right is enabled that we are indeed writing, and we need to make sure that the right for the FIFO is not full. If this is true, then what we are going to do is we are going to take the right pointer and store it into the local variable PTR. We are also going to take the right data basically the FIFO in whatever the data that's on the FIFO in data input and store it into the local variable data. And as always, I always attach a sub routine which is a display and basically show what's going on. Now what we have done is we have stored the right pointer and we have stored the right data If this is true, that means we have completed a write, then we need to make sure that whatever we read from that particular location is the same as what was written to that location.
So what I'm going to do is I'm going to call a sequence called read detect. And I'm going to send it the right pointer, which was stored into the local variable PTR. In this and I'll get to first met in a second. Now in this sequence, what we are saying is okay, when the sequences involved, we are going to make sure that from now from time, quote, unquote, clock zero to clock forever. It read is enabled, and five is not empty. Again, we want to make sure that you're not going to read from an empty FIFO reasonable and FIFO is not empty and the read pointer equal to pointer.
So, we are going to wait for this condition to match forever if you are reading and whenever read pointer is equal to right pointer, because right pointer was against wrote into pointer and the pointer was sent to read detect. So, now what we have done is we have waited till right pointer becomes equal to read pointer. If that is the case, then and back now to the first match, what I'm saying is the very first time this condition, shine is met because it can meet multiple times we are going to wait forever. I don't care. I just want the very first match of this particular expression, this expression that I want to move forward. So the very first time read pointer is equal to right pointer will come here and we'll make sure that five out meaning the data output or, or the data that is being read is the same data that were written this data.
If you see here again, this is the data in which we store the data that was written. So as soon as this condition is met, meaning as soon as right pointer is equal to the read pointer, we are going to make sure that the data that is read out is the same as data that are written. So study this carefully is not that complicated, but this is how you would make sure that the asynchronous FIFO crosses the right and read clock. Clock boundaries. That's pretty much it. As I said, this is a short lecture and I have exposed to you a very important property, you can literally take this property and apply it to your asynchronous FIFO for your project.
Thanks for attending the lecture, and I'll see you in the next lecture soon.