Hello and welcome to lecture seven. In this lecture we'll see how to bind properties or a module that contains properties with a module that contains design. The best practices of system Verilog assertions require or at least I suggest, that do not put your properties in the same module as the design module. First of all synthesis may have troubles, your manager may not like that practice. And most importantly, there is a construct called bind available in system Verilog assertions. So then you can keep your properties separate, totally separate in a different module, and then bind the properties module with the design module.

Let's see how that works. So binding properties, let's say you have a module called design module with it puts the clock and output dB. I've used the for design, as you will see the reason for that, and it's a very simple assignment. Now, the now the second module is your property module. This property module will have properties that work on this design in the design module. And the property module can only have inputs, I mean, it's a module so you can have anything you like.

But it doesn't make sense to have outputs on the property module. It wants to work on the inputs of the inputs that come from the design module. So it has been a PvP p clock as inputs, and it has a very simple property called RC one which says if p is true, it implies PV Doesn't matter, it's a very simple. And as you can see the output of the design module module DB goes as an input, but we haven't made the connection yet. I'm just showing you that the DB goes as an input PB, but we haven't done a bind yet. So this is where you do a bind.

For example, you have a module called test, bind property. And in this module, you instantiate the design module VM, and you connect the design ports with a test bench ports like we normally do, there's nothing new here. Now here's a keyboard bind, which is a key word from the SBA language as a matter of fact, is exists in system Verilog also, but you can bind the design module with the property module. give it an instance name And connect just like you would normally connect the Verilog modules or the instances. So, pa property module a can also design a PV connects to dB and P clocks connect to the clock. Now, since we are connecting a module to Module What that means is that bind the module will bind the module but all instances of the module because we are binding a module to a module as opposed to binding the instance of design module with the property module here all the design module instances will be tied to the property image module.

Here only the instance of the design module will be bound to the property module and again we connect the The ports, which you have to so that way, now in that case, db is connected to PV as you see. And that's why this relationship I was showing here. As I just said, you have to name the bind instance. And that's pretty much it is actually a very straightforward process. And with this process or this feature in place, I don't see any reason why you might want to put properties within the design module. And let's see, a little bit more on this topic.

So what I'm showing here is that I have the property module just like the previous slide, but here I'm calling the the poor da DVD cloud doesn't matter. You can call it anything. But I'll tell you why. I'm doing that. Desert property, which is the same as in the last slide, and I'm setting and covering the property. What I'm doing here is from within the property module, as opposed to from a separate module, we have three modules here design property, and wind module.

But what I'm doing in this slide is that within the property module, I'm binding that design module. And he has a design module, which has a named da DVD clock. As we saw in the previous, and I purposely named the property module purports to be the DVD clock so that when you bind design module with property module, you can simply say dot start, because this is a very simple example. But I can assure you, you will have hundreds of signals between the property module and the design module. And one of the ways to make sure that you're doing can make mistakes is called the property module ports. The names of these ports will be the same as a design module.

So all you have to do is just put dot star. For those who wants to know even further detail of mine, this is the details that I presented is sufficient, more than sufficient for system Verilog assertions. But the as I just said, this is where a lot of language also can use this particular feature. And you can read the system or log LRM to get even further detail, but you don't need any further detail for the system or assertions. Okay, so there's one more caveat here. Let's say here's my design module with the same ports as before, but I have internal registers and I work on these internal registers as well as the input port But I basically want to write an assertion on the registers which are internal to the design module, they are not the ports.

So how do I bind the internals of the design module with the property module. This is the same property module that we have said in the last two slides. It's called scope visibility. And this is an excellent feature that the designers put in very glad that they put in. And here's your test the third module called bind property, and everything is the same. This one connects the ports two ports, like we have seen in the previous slides.

Now, observe this one here bind design module to the property map module, given the instance name, but what I'm doing is here the property module pa and PB because there's a property that uses These two input boards, I'm connecting them directly to our DA DA DB. In other words, you don't have to drag rd and our DB to external ports in order to bind those to the property module. I just imagine you may have thousands of internal variables, then there is no way I mean first of all synthesis will die if you had so many ports coming out that design is not real estate because the design doesn't have all those ports. So, the scope visibility means that everything under the design module all the internals are available to the property module. Simply by connecting you have to have those connecting ports in the property module, which is okay property module is not going to be synthesized and all the internal registers are visible directly to the when you do the bind, so, understand this carefully It's an excellent feature.

And that will help you further to keep your properties separate from the design module. Now, as I said earlier, and in this course I've said that, let's say you're a VHDL design house, you use VHDL. But VHDL does not have system Verilog assertions, they don't support Verilog. Of course, it's VHDL. They do support PSL. And you can use PSL to write assertions for VHDL by system Verilog assertions as VA is becoming an industry standard.

And what if you want to use that? So let me show you how you do it. This is a VHDL, quote unquote module or as it's called in VHDL. For entity, here's your entity CPU. It has two inputs A and B. And here's the architecture of the answer.

TT CPU. This is how the server works. If you're not familiar with VHDL, don't worry, you don't need to become a guru. I'm just showing this for the VHDL users. So here's your entity and architecture for, for a given quote unquote module like in Verilog. Now, system Verilog assertions work only in Verilog, or system around.

So here's the CPU properties here they add CPU. Here's a very large system Verilog modules, CPU props, and there is some assertion in there. How do you bind VHDL or Verilog, the same way that we had seen before you create module. But in in the visual world, when you bind a VHDL, or Verilog, people say, hey, create a wrapper doesn't matter. It's the same concept that I just described to you before. Bind CPU CPU is your entity in VA server like a module.

Very low work to CPU props, which is your properties module, give it a name CPU SV a bind, and bind it just like it would do. In a very low D connects to a, he can actually be an A, and here's a signal c that connects to f. So this is no different from what we saw in Verilog hundred percent Verilog world. So this is the beauty of SV, you have a VHDL entity, yellow Verilog properties module. And you can find them pretty much the same way you mind the Verilog design module with the Verilog assertions module. Now, how this works is very, very dependent on each simulator. So I've taken the example of presa which allows mixed mode simulation between VHDL and Verilog.

Because you need that, aka your mind VSL Verilog and basically, after you compile your design, you say vcm top SV wrapper, and this SV wrapper with your top level design will be compiled and simulated. And because you are simulating the SV wrapper, which is part of V log star dot v, these bind will take place. That's all there is to it. I mean, you can have that died VHDL design, you can write all your solutions in variable and you can bind them and you can compile, I'm sure criticism from mentor I'm sure the synopsis or cadence will have a different way of compiling and elaborating this particular scenario. So again, here's here's a simple design Verilog or VHDL modules or entities in VHDL world, he has your test bench Verilog. This is your existing.

The point I'm trying to make here in this slide is let's say you have legacy design for we could never wrote assertions. Maybe yes, we didn't do an exist in those days. But you realize that you had found bugs, either in silicon hopefully not, or during verification, and you had a tough time debugging. And there's a good chance you missed a few bugs. Now if you want to write assertions, so again, just like I showed in previous slides, write the assertions, properties and bind. That's it.

The existing design doesn't have to change nothing happens to the existing design for two different modules. And you can also right in addition to the module assertions, interface assertion, the interface of assertions between two modes And at the i o of the chip. These interface assertions just just as a side note are probably some of the most useful assertions you write. Because this is where the protocols take place. Some of these are standard protocols at the chip boundary, but the internal a inter module assertions are all specific to the design, and those need to be verified. And so when you put this interface assertions here, the module assertions we are binding them.

And I'm taking a very simple approach here. You can experiment with different styles, but basically I'm saying that put the interface assertions in include fi with hierarchical referencing of the interface signals. And voila, you go, that will that will work. And this is the last point that if you're using system Verilog, you can embed the system interface as sessions into the so called interface block, which is part of system Verilog. So you can have an existing design or legacy design and you can still take full advantage of the assertions methodology. So that's pretty much it for this lecture, you have seen how very long and or VHDL designs can be bound to a properties module, how you can keep the properties module separate from the design module, which is the methodology I highly recommend.

Thanks a lot for attending this lecture, and I'll see you in the next lecture.