 What is electronic design? Okay, all of us have been studying design all these days and teaching design all these days. We must ask ourselves the question, what do you mean by electronic design? What is this activity called electronic design? Okay, there is no book answer or correct answer for this that you write, you know like they say, what is physics? Physics is the science of matter, energy and their interactions, correct 2 marks, none of this. Okay. This is, we have to apply our minds and think what is design? What is electronic design? And as I said there is no only correct answer whatever you feel, this is my answer to this question. Okay, so my answer is this that given specifications, there is no electronic design if you are not given accurate specifications, specifications must be complete. So given specifications, we want to develop a circuit and what is a circuit? Like connecting known electronic devices, okay, such that the circuit meets the given specifications, right. That means what are specifications? Specifications are a description of the behavior of the circuit, okay. So suppose you want somebody to design an 8085, so you will say design a circuit which will read instructions like this clock circuit, it will put ALI, high ALI, low etc., you are describing behavior, okay and then you will say when the instruction or this bit pattern is presented, it will move the contents of A register to B register etc., etc., right. So these specifications are essentially description of the desired behavior of the circuit. That is the starting point. What is the end point? I will say you connect this register to this and this register to this and connect this transistor here and put clock here etc., etc. Then this circuit will have the behavior that you want, correct? Then that has been done, the design has been completed, okay. So this is my definition of what electronic design is. Now there are many keywords here which we now have to understand. What are the keywords? First of all, we are saying known electronic devices, right. Where do you stop the design? You do not have to go down to a single transistor. For example, you are doing a board design. Now I need not go beyond a D flip flop. I will say, okay, use a 7474 here or use a 4013 here. That is where my design ends, right. So where does the design end? Where I reach an interconnection of devices which are already known, right. Now what is already known is a variable that depends on the context. For example, suppose I am doing VLSI design and my company already has a copy of the ARM processor. Then if I am designing an MP3 player, then the ARM processor is a known component. I do not really have to design the ARM processor. I just put it down and that is called IP core-based design. So essentially, if known components become more and more complex, then I can design more and more complex circuits because my design stops when I reach a known component and an entire microprocessor is now for me a known component. Essentially you are doing board design on a chip, right. This is what you would have done on a board design. You would look at it and say I think an 8051 will do it. Therefore when does your board design stop? You do not have to design the innards of the 8051. You say I will put an 8051 here and therefore 8051 is a known component, okay. So once you reach known components and known components only, there is nothing unknown. Then your design is finished. So that is one part there. The other part is specifications. You might make the charge that I have defined something in terms of something else which is as are known, okay. So what are specifications? My definition is not complete unless I have told you what are known devices and what are specifications, right. So known devices, we have now had a discussion, we have a good feeling of what known devices are. We should now know what we mean by specifications, right. So the specifications refer to the description of the desired behaviour of this, right. Specifications must be complete, right. So you must have complete description unless this is complete. I may make something which has those specified behaviour but it may do other things which are quite bad and you may not be acceptable to you. Then my design is not complete, okay. So electronic design is the activity of connecting known devices to produce acceptable behaviour and the starting point is the description of the behaviour, okay. Hardware description languages are designed to meet this requirement, okay. Therefore I need to mix two things which appear very incompatible with each other. One is a behaviour description and the other is a simulation of a known circuit, right. Circuits are described differently, behaviour is described differently. Circuits are diagrams, behaviour is some algorithm, some logic. Now how can I merge these two and come up with something? That is what hardware description languages do, okay. That is the purpose of hardware description languages. So electronic design is the process of converting a behavioural description. What is the behavioural description? Which says what happens when? Kind of description. To a structural description. What is the structural description? What is connected to what, right? And when the behaviour of these two is the same, then my design is complete, okay. That is electronic design. Now what is the problem with this? Now we have understood it. Now electronic design is all complete, we can all go home. The problem is that designs have become very complex, right. So every year new technology comes. In every 18 months, we can put twice the number of devices on a chip and our market expects devices which are twice as complex every 18 months from us. And if we do not meet that expectation, we will be outdated, okay. So new microprocessors come, they work at higher clocks, they have new memories come, they have higher capacity and so on. And if that expectation is not met, then no design is required, okay. You will be out of business. So therefore this complexity is now becoming very huge. The problem is unfortunately that the human mind is not improving at the same rate as the technology, okay and unfortunately it is the human mind which is required to translate this behaviour to circuit. So how do I manage this? That is the major problem. So the major problem of modern design is conquest over complexity, okay. Now one obvious way of conquering complexity is divide and rule, okay. Rather than talking in the air, let us take a specific example. Let us say that somebody was to come and tell us design in 1885. We all know 1885. It is not a big deal, it uses 15,000 transistors. That is nothing compared to modern designs, okay. A Pentium uses something like 10 to the power 8 transistors. About 100 million transistors, tens of millions or 100 million transistors. I am not asking for much, I am asking for 15,000 transistors. So the expectation will be by this afternoon design the 1885 and that should be done. When the original designers of 1885 came together, they took about 15 man years, okay. But at that time all these advanced tools were not there, right. So now with the modern tools, just do it, okay, don't take an afternoon, take a week. We are suddenly afraid, no, no, it may be a very simple circuit. But I can't up and design in 1885 like that. It's too complex, okay. It may be only 13,000 transistors for you, but 13,000 transistors is too many for me. That is because the human mind has a limitation of handling a certain number of objects at a given time. And typically, there may be geniuses. But ordinary human minds, they handle tens of devices at a time, okay, not more than that. If you have more than 10 objects to handle, then it becomes just too complex for you, okay. An example is a game of chess. I don't know how many of you play. So in a game of chess initially, there are 32 pieces there. That's too many for you to comprehend and to keep track of. So therefore initial moves are all stylized. Somebody has worked it out painfully, etc. So you pick one out of 10 or 20 choices, right. So you want 10 or 20 choices, no more. You pick one out of them and then follow it. Till some Mardhar occurs, the number of pieces is now reduced to about say 20. Now you can start applying your mind, okay. So this is the trick. At a given time, handle no more than 10 to 20, right. So this is called hierarchical design. When a complicated design is given to you, break it up into no more than 10 to 20 parts. So, okay, you say 1885, you describe the behavior, all right. It has an ALU, okay, not very complicated. It has a register file. You told me that these are the registers, I need a register file. It has a certain way of reading from the bus, so it has a bus interface unit, okay. It has an interface controller, all right. Now it looks somewhat manageable, okay. So I'll have a register file, I'll have an ALU, I'll have an instruction decoder, I'll have a bus interface unit and now I have to figure out how to connect them, okay. If I do all of this, then I have the design of 1885, right. So already I'll start feeling better that this task can be managed. So the way to conquer complexity is by hierarchy, okay and I'll go top down. Next I say, all right, what is this, all right. I don't worry about other things. My team has been asked to design the ALU. So what does this ALU do? Not much. Just add, subtract, not even multiply, okay. Just add, subtract some logic operations and and or XOR, okay. That I know how to do. I know how to make an adder. I know how to convert an adder to a subtractor. I know how to do and and or XOR. Not a big deal. Not is also okay. I know how to rotate. Then what else is there? Put all these things together, your ALU is ready, okay. Then somebody says, what about the register file? Not a big deal. I'll take eight D flip flops and connect a gate at the input, gate at the output, connect it to the bus. If this register is to be loaded, then the input should be turned on. If this register is the source, then the output should be turned on. So I'll decode the address of this register, okay. And there are eight of these possibles. So I'll have a three-bit code and depending on whether it is input or output, one of eight switches need to be turned on, register file is not a big deal, okay. Similarly decode or similarly other things. You start doing it at that level. Things start becoming manageable. And that is the only way that we can do complicated design. Therefore, a hardware description language should be one which allows you to work like this, okay. You can't work at a circuitry level, right. Whenever things become complex, then graphical descriptions become too difficult, okay. Remember, how did all these languages, how did scripts evolve? Script evolves like a picture, okay. You drew some picture or some concept and so on that this is a man or this is sky or whatever. But soon it turns out that the complexity is so high that you can't use pictorial representations, okay. Similarly, a circuit diagram is a pictorial representation of the actual circuit. Pictorial descriptions won't do. We need text descriptions. When things become complicated, things become abstract, then you need a language and not pictures. And as a result, the same thing is true of electronic design that you go from circuit diagrams to hardware description languages when the complexity becomes too much. So that is what the hardware description language solves. So these are the things. You need hierarchical design. We have already established that with the ATT5 example. You need modular architecture. So that once you have said ALU, it should not depend, ALU's design of ALU should not change if somebody changes the registered file design, right. So that different people can take on different things and quickly do it. So this design should be modular. It should be text-based rather than pictorial. And you should be able to reuse existing resources, okay. So suppose a register has been made, then tomorrow you want to design an AT51. You should not be required to start from scratch, okay. You are not using the entire AT85 design but your company has been very successful with an AT85. Let's say we go back 20 years and you are in Intel. Now you want to come out with AT51, it should not be required to start from scratch, okay. Register files are similar, ALU has similar functions, some additional functions. You should be able to compose it out of the same building bricks, okay. So therefore each of these entity of design should be reusable, okay. These are the requirements of a hardware description book and we take a page out of the software designer's book because this is what we have learned from software people. Software people have managed high complexity for a long time and this is what they do. They use libraries. So you can reuse functions in different these things. You do hierarchical design. You have programs calling subroutines, calling other subroutines and so on. You do hierarchical design. You have modular architecture. The change of one subroutine should not change another function and so on. So all this is what we learned from software designers. Therefore our description should resemble software. Unfortunately this is taken too far. Many people teach hardware description language as if it is a programming language and that way you are invulking disaster, okay. Because it is anything but. There is something to be learned from software. It is like a hardware description language does look, feel and smell like a software language but it is anything but. It is very different from a software and how is it different is the next thing that we should, okay. We come to this that hardware is actually different from software. Fine we will learn from software but that is not where we stop. There are other things. How is hardware different? Why is hardware description different? First hardware components are concurrent. Software things happen one after the other. Only one thing is happening at a time. Whereas in hardware different blocks are operating all at the same time and interacting with each other, okay. So to describe the behavior of something which is so parallel, requires constructs which are inherently different from the constructs which are required to describe a sequential algorithm, okay. So that is concurrency. Second, the behavior, the timing is a indivisible part of hardware description. Whereas timing is not, you know, you may have a slow computer. You may have a fast computer. The correctness of the program is determined by the result that it produces, okay. May produce it in more time, may produce it in less time, okay. But the programming language is not concerned about it. The hardware on which this language will run, that is separate. But the programming language need not be concerned with time, it never is. On the other hand, hardware crucially depends on time. Which pulse will come before the other can totally alter the behavior of your hardware. And therefore, it is not software. It is different and these things must be incorporated into the very construction of the language. It should not be like a software program. And those who teach hardware description languages like a programming language are producing students who will be unemployable really because they don't understand. They will often commit mistakes and everybody commits mistakes. But the problem is that they will commit mistakes and never realize the kind of mistakes that they are committing. I will take perhaps a few examples of the kind of mistakes which are not understood by those people who teach hardware description like programming languages, okay. So these hardware description languages need to have the ability to behave. Something may be described behaviorally. Let's say that the register file has already been described structurally. I will reduce it down to transistors. But my instruction decoder is described only behaviorally. Now whether the whole thing is working or not, I need to put it all together, right. So therefore, I need to have a language which can put together elements where some are behavioral, some are structural and overall mixed, right. That capability must be inherent and that's why hardware description languages always have behavioral and structural parts. I already said that timing is integral to hardware description, right. This is, by the way, there is one kind of software where timing is important. That's called real-time software, okay. In fact, if you read any book on real-time software, they say it is like hardware because timing is important, okay. For example, suppose you have a microprocessor in the anti-locking brakes of a system, of a car, right. Now this program determines the force to be applied to the brake pads given the current situations. Now it may arrive at the correct value, but not arrive at the correct value fast enough and the car may crash. It doesn't help you very much that it finally found out how much pressure should have been applied to the pads if by that time the car has crashed. So when you have a system like that, then that's called a real-time system, okay. And hardware is always a real-time system. Hardware design is always a real-time system. So we must understand time, okay, or delay. Let's see how do you describe delays? So here is the simplest possible example of a delay. You have a pulse at the input and the output should be a delayed version of this pulse by 30 microseconds. Now essentially this is an example in VHDL, but don't worry about the actual structure almost in any language. This is what happens. I am saying assigned to out the same waveform as in, but with a delay of 30 microseconds, right. What do we understand from this in hardware terms? If we stopped it here, then we will really not understand hardware. Then we would be treating it like a programming language, okay. So let us see. Suppose I open out this black box into its hardware constituents. And this is one possible way that I can put down the hardware, okay. Let's say there is this RC delay with a delay of 30 microseconds and a buffer, right. This RC delay will lose the TTL logics or whatever logic levels because of the RC, right. The output will not be sharp anymore. Therefore I need to put a buffer, okay. And RC will provide the delay. Now this will meet my specifications of this circuit, right. The buffer is non-inverting. So output is the same as the input with a delay of 30 microseconds or is it? Let's look at it. Let's say that I give it two pulses. The first pulse is much narrower than 30 microseconds. The second pulse is much wider than 30 microseconds, okay. Now let's see what happens. This is an integrator. So when this pulse goes high, it starts integrating up. However, before it has gone much further, this pulse goes low again, right. As a result, this point being low, this capacitor now starts discharging through this, right. So as a result, in 30 microseconds time, this will go up a little bit but since the pulse did not last a full 30 microseconds, it will come down, okay. And therefore this guy will treat it as if it has been zero throughout, right. So at the output, this little wiggle will actually disappear. On the other hand, if the pulse is much wider, then with a 30 microsecond time constant, this will charge up, stay there and when the pulse comes down, it will start discharging. Now because this acts as a discriminator of a low level and a high level, the output will be a 9 square pulse somewhere depending on where the discrimination level is. And now you will get a delayed pulse, pulse delayed by 30 microseconds, okay. So the pulse much narrower than the delay has vanished. Now this is how hardware behaves. Should we say that all delays are like this? Answer is no. Let us look at opening out that black box in a different way, okay. This was my black box, delay of 30 microseconds. Now instead of implementing my delay by that RC circuit, I implement it like this, okay. I give it to an LED here. I have a long optical fiber whose length corresponds to a 30 microsecond delay and then I convert this light back to digital level at the output, right. This black box also should be described the same way. That output equal to in after 30 microseconds, correct. Now let us see what is the behavior of this black box to the same input, okay. Now of course this pulse will also appear at the output because there will be a flash of light which is brief. This flash of light will eventually appear 30 microseconds later at the other end of the fiber and this longer flash will also appear as a longer flash at the end of the optical fiber. If that did not happen, you would never be able to send messages from here to Delhi. The delay is so long, hundreds of kilometers, the delay is really long there, right. And yet pulses which last nanoseconds are sent. So in this case, the narrow pulse does not vanish, okay. So therefore there are delays and there are delays. We must describe these delays differently, okay. So hardware is a strange object, should not be treated. If you just thought of it like software, you would have said that assign to this variable this value after so much time, okay but that would not do. In fact the thing has changed qualitatively because of the way that the delay is implemented, okay. You must understand time very properly and in fact these delays are called inertial delay and transport delay accordingly and you must specify it the same. Now very often you are not worried about timing at the start of the design, okay. You just want to know the correctness of your logic. So then if you do not specify a delay, what should the hardware take it, okay. Now by default the delay is taken as 0, okay the default value of delay if you do not specify is taken as 0 but that cannot be physically right, okay because there may be race conditions and if pulses arrive in different order that will cause problems. So what the hardware description language actually does is that it takes 0 delay to be a delta delay, okay. The assumption is no hardware can update its output in 0 time, okay there is a definite amount of time of delay from input to output. If you are not worried about it then I agree to play along with you and I will call it 0 delay but as far as my internal operations are concerned I will define a special unit of time called a delta delay, okay. So this delta delay is something whose value is reported to be 0 when the final timings are reported but as far as my internal operation is concerned I will assume that all things which are a result of something that the delay between cause and effect is always a delta delay at least. So if you say 0 I will put it as a delta delay and keep detailed accounting that the time is 30 microseconds and 5 deltas, okay and then when you ask when did this happen I will say it happened at 30 microseconds at that time I will put delta equal to 0 but for internal operation I know that something which happened at 30 microseconds plus 2 delta occurred much earlier than 30 microseconds plus 5 delta and there was a 3 delta time in between where one was true and the other was false, okay and if that has specific consequences then I should take into account those kinds of consequences. For example the one input is coming to the clock the other is going to reset. Did clock come first or did the reset come first, okay did clock go away first did reset go away first correspondingly the output could be a 1 or 0, okay the overall delay can be 0 but the output result itself will become wrong if I do not take this scheduling into account therefore I must have the concept of delta delay which is special to hardware description languages. This by the way is the source of much headache to all the students who learn HDL as if it is a programming language, okay because what happens is that you say assign 0 to A and if A equal to 0 to this now because they are so used to software they feel that A equal to 0 is correct indeed it is not what when you say assign 0 to A A has not become 0 a 0 is scheduled to be given to A in the future after a delta time if you test the value of A before that delta has occurred then you will find that it is actually non-zero, okay so these students just like used to be used to software writing say why is it misbehaving A I am saying assign 0 to A and if A equal to 0 to this and it is not doing it, okay that is because you have learnt hardware description like software whereas it is not software you have to take that into account and test the value of A only after the assignment is complete only in the next delta. So therefore the language has this responsibility now to remember to assign values in the future when the assignment is encountered it is not immediately assigned, right so it keeps what is called a transaction register a transaction queue what is a transaction it is like saying that I place an order but the equipment arrives later, okay so that is a transaction somebody has to keep track that this order has been placed this money has been paid whether that thing has finally arrived or not, okay so this whole thing constitutes a transaction now the hardware description language keeps a time ordered list of transactions, okay and things are executed in the order of their time so for example if you have let us say AND gate one input is 1 the other input is 0 now at some time the zero input goes to 1 then the output should become 1 AND gate the other input is 1 this has gone from 0 to 1 output should go from 0 to 1 you do not directly assign a 1 to the output you have to take down a note that after a gate delay make the output equal to 1 so during that gate delay many other things may be happening all around the circuit you have to do those first and then make the output of this AND gate 1 otherwise you will get wrong results right so therefore you need to have the capability of storing these pending events all the time okay and that is called a transaction a list of transactions and you must understand it in terms of transactions and assignment is not immediate it is not like assignment to a variable it is a transaction okay so it is like a little black diary you have so when somebody says give 10 bucks so you say and you write down in a diary give 10 bucks at this time but your wallet still contains those 10 bucks when the time comes then you will give that 10 bucks so if somebody says if your wallet has more than this much amount do this or less than this much amount then do this then if it is treated like a programming language you may come to the wrong result okay so that that that is the difference between programming languages and hardware description languages how do we handle concurrency that many things are happening at the same time because after all the program can do only one thing at a time we are simulating it on a computer so the computer can do only one thing at a time whereas you want everything to happen at the same time so the answer is that we have a separate variable called time and we keep the value of this variable frozen now we can do all things and only when everything is completed we advance the value of this variable as a result even though we did that sequentially as far as the time tracking is concerned they would all have occurred at the same value of time because the value of this time variable was kept frozen okay so this is how this is even driven software always works like this we discussed this for IRCM also so you have a time variable you hold the time variable constant you place a transaction when something comes and then advance the time to the earliest next time when something needs to be done okay so this is called event sensitive handling so let us take this practical example okay what do I have I have a NAND gate here there is one input which is direct and the other input which goes through an inverter the inverter has a delay of 8 units the NAND has a delay of 6 units okay so I have a slow inverter a fast NAND let us see what happens now if you were to analyze it without time then you will come to the wrong result right why because at least one of the inputs must be 1 and the other must be 0 okay if A is 1 then the other input is 0 if A is 0 then A is 0 so at least one of the inputs must be 0 at a given time therefore the output this being a NAND output should always be 1 okay in reality that is not so what happens is that when A goes from 0 to 1 this becomes 1 immediately but there is a delay of 8 units of time before this becomes 0 therefore for 8 units of time both inputs are 1 and the output has a 0 going glitch okay this example will illustrate how that glitch is correctly reproduced during simulation okay otherwise if we treated it like a programming language you will always come up as a logic simulator we will always come up with the wrong result okay so that is why this example is illustrative so I have a time ordered transaction list what is a transaction list this says make the input 0 at 0 time make the input 1 at 20 this is also a transaction and make the input 0 at 50 right these are the three transactions which are pending so I enter them here in this transaction list and order them by time at 0 make A equal to 0 I do not know what A was before that is unknown okay so at 0 make A equal to 0 at 20 make A equal to 1 and at 50 make A equal to 0 okay these are the only transactions that I know what I do I first make a sensitivity list okay this is what we had discussed for IRCM also we simulate only partial circuits only a circuit whose inputs have changed should be resimulated right so we notice that the any event on A will cause resimulation of the inverter as well as the NAND any change on A then the output of the inverter and NAND must be recalculated after recalculation it may come out the same that does not matter but recalculation must be done on the other hand any change on B only the NAND needs to be recalculated okay so we say it by saying that inverter as well as the NAND are sensitive to A whereas the NAND is also sensitive to B okay and now we keep our time order here next we advance the time to 0 okay now at 0 what is the pending transaction make input equal to 0 okay so you update and make A equal to 0 now the old value of A B C were unknown new value of A is now 0 therefore A has had an event okay A value has changed earlier it was unknown now it is 0 therefore I must re-evaluate all gates which are connected to A who is sensitive to A both okay so therefore if when I do the inverter its delay is 8 so it says make B1 at 8 units of time current time is 0 delay is 8 input has become 0 therefore I calculate and say make B1 at 8 units of time correct and when I evaluate the NAND I do not care what the other input is if one input has become 0 then the output must be 1 right I already know the output so I say make C equal to 1 at 6 units of time right these two I insert into my transaction queue right and take out the transaction that I have already handled so make A equal to 0 I take out see this is the transaction queue before and this is after so I take out 0 and insert at 6 make C equal to 1 and at 8 make B equal to 1 and the remaining transactions remain what that then I am through with 0 what is the next earliest time at which something happens 6 right this is the earliest time in my transaction queue so at 6 what should I do I should make C equal to 1 right that is the diary that I my diary says at when the time says 6 makes equal to 1 so that is what I do the current time is 6 A was previously 0 now remains 0 B was previously X remains X right but C should now be made 1 at 6 okay and that nobody sensitive to C so no recalculation needs to be done so I removed this transaction at 6 right I have made C equal to 1 right so notice this C has gone to 1 here I am constructing the waveform here A is 0 and remains 0 B is still X and C has gone to 1 here okay at 8 at 6 next what is the earliest thing remaining at 8 what should I do at 8 I should make B equal to 1 right so at 8 B goes from X to 1 therefore B has had an event who is sensitive to B only the NAND okay so I must recalculate the NAND so A is 0 B is 1 right so what should be the output of the NAND it should be 1 if either input is 0 output should be 1 so I scheduled the value 1 at current time plus 6 right the delay is 6 what is the current time 8 so 8 plus 6 that means at 14 makes equal to 1 okay I do not care if C is already 1 so I insert at 14 makes equal to 1 notice that C is already 1 but I do not care I insert that at 14 makes equal to 1 and then I am done I can remove this transaction right so this is my remaining transaction list now when is the next earliest time when something happens 14 right and what do I have to do makes equal to 1 so that is what I do I have arrived at time 14 the old value of C is 1 and the new value of C is 1 there is no event nothing has changed even if there was an event nobody was sensitive to C right so no re-evaluation is required okay so C remains 1 okay notice A is 0 B remains 1 now and C remains 1 now what is the next transaction at 20 at this time at 20 make A equal to 1 right so you make A equal to 1 at 20 so these are the old values at 14 0 1 1 and at 20 you make A equal to 1 so A has an event correct A has changed who is sensitive to A both inverter and the NAND so I must evaluate both of them so what is the value of B because this is 0 B must become 1 at current time plus 8 right what is the current time 20 so I must schedule at 28 the value of B becoming 0 right input has become 1 input has become 1 from 0 at 20 so the output should become 0 at 28 that is the behavior of the inverter right so therefore at 28 make B equal to 0 when I do the NAND what happens A is 1 and B is 1 so the output should be 0 this is an NAND at what time at 26 right current time is 20 and the delay is 6 so at 26 makes equal to 0 correct these two transactions I insert here and take off this 20 because I have already handled the 20 right so at 26 makes equal to 0 at 28 make B equal to 0 and this 50 A equal to 0 remains correct alright these are the waveforms at A we have had this transaction and now my C has become 0 at 26 right that is the next transaction so I advance the time to 26 and makes equal to 0 C has an event but nobody is sensitive to C therefore all I do is that makes equal to 0 and then advance to the next time what is the next time B should become 0 right so I come to next time at 28 B become 0 26 B was 1 at 28 B become 0 so B has an event if B has an event who cares the NAND right so if B is 0 then 6 times of unit later make it 1 so therefore makes equal to 1 at 34 right so we insert this in the time ordered queue next time is 34 I make C equal to 1 C has had an event but nobody is sensitive to C so therefore C which had gone to 0 now becomes 1 this is that glitch we have correctly reproduced it okay next event is 50 A become 0 right that is the only thing left when A becomes 0 both must be re-evaluated therefore that means make B equal to 1 at 58 and makes C equal to 1 at 56 right and take off this 50 transaction right both and inverter and NAND must be re-evaluated so then at 56 C equal to 1 at 58 B equal to 1 then I advance the time to 56 do the same thing at 58 make B equal to 1 and this is my final at when my transaction list is empty then I have finished my work okay so therefore this hardware description language behaves differently if you had just use assignments to C at the same time without this delay you would have never got this glitch and that is indeed the behavior of this hardware you would not do it if you treated it like a programming language okay and as a student you would never understand why this glitch is coming in a hardware description language if you wrote the corresponding C program the C does not never shows it always shows that the output to be 1 but it is only the hardware description language which will show this glitch okay I think we will stop here