Introduction to Hardware Description Languages Video Lecture | Embedded Systems (Web) - Computer Science Engineering (CSE)

modern electronic design has become very
complex and traditional design styles
therefore are inadequate to carry out
these complex designs most of these
designs these is in particular in the
digital domain are all done using
hardware description languages in this
module we shall look at hardware
description languages in general and
then we'll have a brief discussion on
specific hardware description languages
in this lecture we'll look at the
underlying principles of all hardware
description languages hardware
description languages have evolved over
time and the standards have changed
however in this course we shall look
essentially what is the core of these
designs or design styles you are
encouraged to practice designing using
these and excellent textbooks and
tutorial material is available on these
I shall mention some of these as we go
along and when we come to specific
hardware description languages but in
today's lecture we want to look at the
general underlying principles behind
hardware description languages and how
they are connected to the modern design
process let's begin with asking
ourselves the basic question what is
electronic design there is no textbook
answer to this however since the
hardware description languages are so
closely linked to the requirements of
electronic design we should surely think
about this question a little bit so what
is electronic design to my mind and this
is not necessarily an encyclopedic
definition electronic design is that
given specifications we want to develop
a circuit by connecting known electronic
devices such that the circuit meets the
given specifications the whole design
process begins with somebody giving us
specifications that I want an electronic
circuit which will turn such-and-such
lights on or which will turn this relay
on or will display such and such thing
when such a thing happens these are all
specifications a designer is then
supposed to sit down and think up an
electronic circuit which will which is
essentially just an interconnection of
known electronic devices such that this
circuit has the behavior which meets the
specifications to me this is electronic
design however this is a somewhat lacks
definition what are specifications we
have introduced a new term
specifications and we should actually
understand what specifications are
specifications refer to the description
of the desired behavior of the circuit
obviously there has to be a standardized
way in which we specify the desired
behavior there is another term that we
have used in this definition that is
known devices what are known devices
known devices are those whose behavior
can be modeled by known equation or
allgor algorithms with known values of
parameters essentially what it means is
that if the model and the model
parameters of a device are known then
this device is known the model and model
parameters could be a device level at
sub circuit level or even at module
level that depends on the level at which
we are simulating this once we have the
model equations then we can put many
such Newton devices together and since
we know the behavior of each one of
these components and indeed the way that
they are interconnected given a
good-enough simulation program we can
now predict the behavior of this
interconnected circuit and then we can
see whether the behavior
of this interconnected circuit is the
same as the specifications so therefore
if we have a standardized way of giving
the specifications and then a program
which takes devices whose models are
known and can put these together and
predict the behavior of the entire
interconnected circuit then we'll be
able to know before making the circuit
whether our circuit is likely to meet
the specifications or not
so therefore in some way electronic
design is really the process of
converting a behavioral description what
is the behavioral description it
describes what happens when kind of
things to a structural description what
is a structural description what is
connected to what and how so we begin
with specifications which is nothing but
a behavioral description it says that if
the door is opened then the light comes
on or whatever so that is a behavioral
description what happens when kind of
description and the process of
electronic design is the conversion of
this kind of description to an
equivalent description of electronic
devices and their connection which is a
structural description after conversion
to structural description we may need to
do one more step which is physical
design which involves choosing device
sizes placement of blocks routing of
interconnect lines etc this part is
already done for us if the design is on
an FPGA on the other hand if it is want
to design an ESIC or indeed a custom
circuit then these parts will have to be
explicitly done however most of the work
of design is essentially converting this
specification to an interconnection so
what's the problem with this thing what
is the main challenge the main challenge
for modern electronic design is that the
circuits being designed these days
stream leak complex it's not so easy to
take this huge complex specification and
to translate it to a circuit and while I
see technology has moved at a rapid pace
capabilities of human brain have
remained the same
there is no scaling of the human brain
and we cannot handle too many objects at
the same time therefore we must break
down a complex design into a small
number of manageable objects at this
time we don't know how to design these
objects however we can set down the
specification of what each one of these
objects will do then we see that if we
had say job such objects what would the
interconnection such objects will do
will it meet the specifications or not
at the end of it if each object is still
too complex to handle the above process
has to be repeated recursively that
means we take the object and then divide
it down into sub modules as we did for
the whole circuit and we continued this
process till we find that the whole
description contains only the known
devices so in other words initially we
design this circuit by breaking down
into modules and these need not be known
objects these are some things which are
yet to be designed however for example
you might take a microprocessor the
microprocessor might be thought of as a
combination of registers L used bus
interface unit instruction decoder or
what have you right now we don't know
how to design the inter instruction
decoder or the register file or the bus
interface unit or what have you
however we can write down that we intend
to design an ALU which is the capab
which is which has essentially the
capabilities which we desire the bus
interface unit should have such an such
behavior and assume that in due course
we will have the design of these things
done so we can pretend that these
modules are in fact known devices
currently they are not but it is
reasonable to assume that
our new devices we have a behavioral
model of these and we can treat these
and known devices then we complete the
circuit design as if these known devices
were available once the circuit works to
our specifications we are happy with it
then we look down on these objects and
say whether these objects are really
known or not if they are not then we
further apply the same process to them
till they have been simplified to a
level where they consist of transistors
flip-flops or whatever all of which are
known devices once we have done then we
have reduced the entire circuit to an
interconnection of known devices and
that is indeed the design procedure
however the complexity is high and
therefore systematic procedures have to
be developed to handle this complexity
so how do we learn how to handle this
complexity and we can take a page out of
the software designers book after all
very complex software has been written
for quite some time what have they done
well we must adopt hierarchical design
we have already seen an example of this
that means you design this circuit in
terms of modules then design these
modules in terms of sub modules and so
on so there is a hierarchy of complexity
the architecture must be modular that
means the changes to one particular
module should not affect the design of
other modules the description should be
text-based
rather than pictorial because then we
can use standard parsing techniques
programs and so on to handle these
descriptions and we must reuse the
existing resources so for example if the
design of an ALU is already available we
can just add on other things to design
our microprocessor in fact if the design
of a microprocessor is already available
we can build a much more complex circuit
by using one or indeed even
all of these microprocessors so
therefore we must reuse existing
resources these are the lessons that we
have learned from software in software
the design is hierarchical subroutines
are written to be modular so that if you
change the subroutine the rest of the
program need not change and the
description is text-based and we have
libraries and we do not rewrite
libraries every time you write a new
program we use the libraries so these
are the techniques which have been used
by software designers for a long time
and even for complex hardware designer
designs we must use these techniques so
how is the hierarchical design carried
out we have agreed that the design
process has to be hierarchical a complex
circuit is then converted to a
structural description of blocks which
have not yet been designed we had just
discussed this however these blocks can
be described behaviorally they have not
been designed that means their
structural design is not known but their
behavior that means their specification
has been set down so at this stage the
complex circuit is converted to a
structural description of blocks which
have not yet been designed but whose
desk behavior can be described each of
these blocks is then designed as if it
was an independent design problem of
lower complexity this process is
continued till all blocks are broken
down into known devices it is essential
that any departure from proper operation
is detected early when the complexity
level is low therefore once we go from
one level of hierarchy to a next more
detailed a hierarchical level at that
time we must make sure that everything
works properly at the less complex
hierarchy level and therefore if we have
to design a language which will handle
all these tasks then the hardware
description language must be able to
simulate a system whose components have
been designed to different levels of
detail for example I have a circuit
I break it down into modules a b and c
and i say that if the modules a b and c
work as desired then my circuit will
work now I design a to a higher level of
detail and before I proceed any further
I would like to put this more detailed
description of a with the less detailed
descriptions of B and C put them all
together and see that the whole circuit
works properly
therefore the hardware description
language must be able to simulate a
system whose components have been
designed to different levels of detail
however let's not get carried away
in emulating software after all hardware
is different from software these are the
major differences of hardware hardware
from software first of all hardware
components are concurrent all parts work
at the same time whereas traditional
software is sequential it executes one
instruction at a time therefore only one
part of a very complex piece of software
is active at a given time in case of
hardware multiple parts are active and
interacting description of hardware
behavior has timing as an integral part
changes in timing can change the entire
behavior of the hardware if the set
input comes first or the reset input
comes first can change the eventual
behavior of a flip-flop
therefore the hardware is time sensitive
the timing of every signal is crucial to
the operation of this hardware on the
other hand traditional software is not
real time sensitive it may run slow but
it will eventually produce the same
results therefore the design of complex
Hardware involves many more basic
concepts be
those of programming languages all the
concepts of programming languages will
be used in hardware description
languages but we must now introduce
other live other components of hardware
description languages which take care of
these requirements which are peculiar
which are specific to hardware
description languages and two of these
are major one is the timing is integral
part of hardware and second that various
components of hardware are active at the
same time
so therefore this parallel operation of
different components is something which
is peculiar to hardware description
other than that hardware description
languages are going to look very much
like software indeed so much so that
sometimes we do not take the pains to
understand that a hardware description
is inherently different from software
and tend to think of it as a software
program which can often lead to very
serious problems therefore in this
lecture we are underlining those
concepts which are specific to hardware
so let's look at hardware description
languages and see what are the abilities
that these must have hardware
description languages need the ability
to describe a circuit of course but also
to simulate the behavior of the circuit
and behavioral structural and mixed
levels and finally to synthesize as far
as possible
the structural description from
behavioral description so if we have a
hardware description languages language
here we would like eventually to have
these capabilities that means we should
be able to describe a very complex
circuit no mean feat by itself but
having described the very complex
circuit we must be able to simulate it
and the simulation should be possible if
all parts of this are described
structure
behaviorally or in a mixed way also once
the description is in a standardized
form which design tools can understand
then all the mechanical work of
converting a behavioral description to
structural description should be done by
a program to the extent possible and
this activity is called synthesis when
hardware is described specifically in a
particular way which permits a
synthesizer to convert this behavioral
description to structural description
then that kind of design is called
synthesizable hardware description not
all description needs to be
synthesizable however much of useful
hardware design must be synthesizable
however there is a large part of
hardware description languages which is
not synthesizable which is meant for
testing debugging circuits and so on so
therefore we must learn both kinds of
hardware description language and we
must be aware that this part is
synthesizable and this is not and for
what is the non synthesizable part to be
used the basic concepts involved in
hardware description language are timing
concurrency because we have seen that
the part which is peculiar to hardware
is that different components of this are
working concurrently and the hardware
stimulation process which itself
involves several stages these stages are
analysis that means you analyze the
given description elaboration that means
you build up the circuit from the
components that have been described and
finally the simulation the simulation
step itself needs two distinct phases
first is signal update that means you
bring the signals to their current
values and because signals have changed
you must find out which components of
this very complex circuit need real
simulation Andrey simulate only those
this Rhys emulation will cause changes
in signal values and therefore you will
go around this loop updating signals at
every time and then Rhys emulator only
those components of the circuit which
need a simulation so this is this is how
the simulation will proceed it will
proceed in a loop and in phased manner
that means all signals will be updated
first then will analyze these updated
signals to say which signals have
changed and if inputs have not changed
the output will not change therefore
those parts of the complex circuit
description need not be real a woken
however when the inputs have changed we
must go to those blocks which must be
Rhys immolated we simulate only those
blocks and find out as a result of this
visa Malaysian which signals will now
change so this whole cycle continues
till the circuits settle down to its
final values we shall actually see a
tutorial of this because it is very
important to see this for a very simple
circuit to see exactly what is going on
behind the scenes when you use hardware
description languages and what our
hardware description language is used
for well these are used for description
and description of interfaces
description of behavior and description
of structure these are also used for
describing test benches which
essentially test the circuit to see
whether it meets specification or not
and these are also used for synthesis
where if we have been careful in our
description of the circuit then rather
than we reducing the behavioral
description to a structural description
a program can be let loose
on this description and a program itself
will convert this behavioral description
to a structural description let us look
at the basic components which are
different from software in a little more
little more detail and timing is one of
those so let's look at delays and see
how delays are actually handled in
hardware description languages how do we
describe delays well the actual syntax
is not material at this stage when we
look at specific description languages
then we'll look at the syntax right now
the syntax need not bother us however we
choose some specific syntax here this
happens to be VHDL syntax and C how do
we describe delays so I have an input
signal in hardware and I want to
describe this delay of 30 microseconds
let's say and the output is essentially
the signal when it has been delayed by
30 microseconds we need to examine this
very important question that is this
description unambiguous let's see why I
raised this question that they indeed
that this very simple description good
at all be ambiguous
so let us implement this delay in a
circuit and here is a circuit notice
that this circuit is not all digital
this delay part is in fact analog and
these waveforms are somewhat stylized
these are not actual waveforms however
the input is digital and so is the
output this is a discriminator it looks
at the voltage at level X and if it is
below some threshold it outputs a
digital zero if it is above some
threshold it outputs a digital one
assume
and the values of this delay element R
and C are so adjusted that we get an
overall delay of 30 microseconds now
assume that we apply an input to this
black box inside the black box in this
circuit our black box of delay equal to
30 microsecond has this circuit and we
applied to that circuit this waveform
this waveform has a pulse which is much
narrower than 30 microseconds and
another pulse which is much wider than
30 microseconds and let us figure out in
our minds what is expected to happen
when the input is held at zero then of
course this capacitor is already
discharged initially and it remains at
zero so the input remains at zero as the
input rises to one it starts charging
this capacitor through this resistor
however the time constant of this is
large and the pulse is relatively narrow
as a result the charging process has not
proceeded too far
when the pulse actually comes down
because the pulse comes down this point
is now connected to ground and therefore
the capacitor starts discharging so the
capacitor discharges as I said before
this diagram is somewhat stylized the
actual waveforms will be exponential
charge and exponential discharge as you
very well know at this point the wider
pulse arrives and the capacitor starts
charging again and because the pulse is
wide enough this charging will now be
complete when the pulse goes down the
capacitor will start discharging and if
this level lasts long enough the
discharging will be complete along this
charging and discharging waveform
we will pass that discrimination level
of this discriminate as long as the
voltage is below that discrimination
level the output will remain at zero
however as soon as the voltage exceeds
that discrimination level the output
will become one and will remain one as
long as the voltage at the input that
node X remains higher than the
discrimination level once it falls below
the discrimination level then the output
will come down to zero as a result we
can expect to get a pulse like this at
the output notice that the input is
fully digital and so is the output this
point X is completely internal to that
black box and what has happened well the
narrow pulse has vanished but the white
pulse appears in a delayed form as we
wanted okay
this vanishing of the narrow pulse is
somewhat unexpected it is not clear from
the description whether this is desired
or not we could have just as well
implemented that delay in a different
way so here is our black box again and
somehow we are able to see inside this
black box and what do we find inside
that black box in order to implement a
delay of 30 microseconds somebody has an
interface here which converts the
digital signal to light this light is
coupled to a long optical fiber which
introduces a delay of 30 microseconds
and there is an output circuit which
converts this light back to a digital
circuit what do you think will happen
now this input this narrow pulse will
result in a narrow flash of light
this white pulse will result in a wider
flash of light and both these flashes
will arrive here 30 microseconds let it
these light flashes will then be
converted to an electrical signal and we
will get an exact replica of the input
at the output delayed by the amount of
delay which corresponds to the length of
this optical fiber presumably adjusted
to give us a 30 microseconds delay so
notice that our black box does not
behave the same in the two cases both
cases were designed to introduce a delay
of 30 microseconds in the first case
this narrow pulse vanished in the second
case it did not therefore just saying
that you delay by 30 microseconds is not
adequate for accurate description of
physical systems then we have learnt
that there are two kinds of delay one
kind in which pulses which are much
narrower than the delay who vanish and
the other in which they do not these
kinds of delays are called inertial and
transport delays so the same amount of
delay which was in our example 30
microseconds can result in qualitatively
different phenomenon in one case the
narrow pulse vanishes in the other it
does not so therefore we must define two
different kinds of delay inertial delay
is the RC kind of delay the first
circuit that we saw which swallows
pulses much narrower than the delay
allow amato transport delay is the
optical fiber kind of delay which lets
all pulses pass through irrespective of
their width in most hardware description
languages delays are inertial by the
for because these are normally caused by
RC kind of circuits however there are
cases for example specifying an input
which are then transport by default so
if you do not specify the delay at all
then the amount is taken to be zero and
the kind is taken to be inertia however
you do have the option of not only
specifying the amount of delay like 30
microseconds here but also the kind of
delay and if you so choose
you can specify either inertial or
transport kind of delay if you do not
specify the kind it will be taken in
most circumstances as inertial and if
you do not specify the amount it will be
taken as zero we should now look at the
other
thing which is specific to hardware
description and that is how to handle
concurrency now to represent real
Hardware signal assignment have to be
associated with a delay when a value is
assigned to a signal the target signal
does not acquire the assigned value
immediately the value is acquired after
some day therefore there are two values
associated with any signal one is its
current value and the other which is
potentially different it could be the
same it could be different but which is
potentially different is the value that
it will acquire in near future that
means when you assign a new value to a
signal it does not acquire this new
value immediately indeed you put a
marker on that signal saying after this
much delay this signal should acquire
this value this marker is called a
transaction thus when an assignment is
made we imply that the target signal
will will acquire in future will acquire
this value after so much delay of this
type so the acquisition of a new value
is not automatic however if you do not
specify a delay then as we said that the
amount of delay will be taken to be zero
however we must understand the case of
zero delay a little carefully when a
transaction is placed on a signal the
default type of delay is inertial and
the default amount of delay is zero in
fact inside the language
this delay is not in not made zero in
fact it is implemented as a small delay
which is called a delta and then when we
report the result we take the limit
taking Delta equal to zero so why do we
take this roundabout way if the user
wants is zero delay then just let's give
him zero delay why do we take this
indirect way of actually implementing a
delay and eventually making that delay
equal to zero and the reason for this is
that channeling is very important in
simulating hardware it is very important
to know what occurred before what and
what occurred after what
therefore for scheduling purposes we
keep track of these Delta delays
something might occur at time T
something with a zero delay will cause a
signal change and that signal change
will take effect at t plus delta this
change may cause yet another change and
that change will occur at t plus 2 Delta
the cause and effect will always have a
delta time difference therefore if we
ever have to resolve which signal is
earlier and which is later which is
important at times then internally we
always know which was the cause and
which is the effect which signal arrived
a delta time earlier and which signal
arrived a delta time later finally when
we report back to the user what is
happening the user always wanted zero
delay and it is only at this time that
we put Delta equal to zero and report
the final results as if Delta was zero
but internally we keep track of all
these deltas and
treat as if Delta is nonzero remember
the actual value of Delta is unimportant
it is some infinitesimally small time
the only point which matters is at how
many deltas did this signal acquire its
value so that we can do a time ordering
the time ordering of signals is indeed
very important in hardware description
languages and as long as events are
ordered in time things are fine if the
user doesn't want to specify a delay so
be it
we shall order it in time using Delta
delays so this concept is very specific
to hardware description languages you
will not see such a concept in any
programming language and indeed lack of
understanding of hardware description
languages very often Springs from the
lack of understanding of this Delta
delay concept now let's see how we
handle concurrency concurrency is
handled by following an event-driven
architecture so in a concurrent system
many things can happen at the same time
it is not as if one latch is being set
many signals might change at the same
time however since we will be writing a
hardware description language which will
run on a computer we can efficiently
handle only one thing in real-time at a
given time therefore we need to control
the passage of time in simulation we are
doing various things one after the other
but we wanted to appear as if all the
things appeared at the same time
therefore we need to control the passage
of time and we managed it by treating
the time as a global variable things
which happen simultaneously
are in reality handled one after the
other
we keep the value of this global
variable time the same then the time
value is incremented explicitly after
all the events which occur at the
current time have been handled so in
other words the actual time as it passes
when the program is running has no value
whatsoever as far as this simulation
time is concerned the simulation time is
changed discretely it is brought to a
level then in whatever time that it
takes in real life we handle all the
events which are said to have occurred
at this time and then we increment the
time value inside the variable time is
incremented to the next time value
therefore as far as the results of
simulation are concerned it appears that
all the previous events before
incrementing the value of the time
occurred and the same value of time
obviously the value of the time variable
represents the time during the operation
of the concurrent system and has nothing
to do with the actual time taken by a
computer to simulate the system you may
have a slow computer you may have a fast
computer and the actual amount of time
taken to simulate may be different we
are not talking about that time we are
talking of the time which is being
simulated for the behavior of the
circuit okay and that is handled in this
special way so let's see how hardware
simulation then precedes we have given a
description in a text form conforming to
a particular syntax described by some
hardware language so the first step is
when we want to run that simulation the
syntax of this hardware description is
checked and interpreted only if the
syntax is correct and makes sense to the
language that will proceed to the next
step the next step is called elaboration
this is a preparatory step which sets up
hierarchically described system for
simulation so there are many things
which are done at this level even though
the description follows a hierarchy we
flattened the hierarchy because
eventually the circuit is the same the
circuit doesn't know that it was
designed following this hierarchy the
circuit is the final circuit so we
flattened the hierarchy for structural
descriptions components are expanded
till the circuit is reduced to an
interconnection of single simple
components which are described
behaviorally and then we set up data
structures which described sensitivity
list of all elemental components so we
know which component receives which
signals as the input and this
sensitivity list says that if this
signal changes then rece immolate this
component remember the circuit is very
complex and we cannot afford to simulate
all components at all the time which we
resell it only those components whose
inputs have changed or in other words if
there is a change in a signal to which
this particular component is sensitive
and only after analysis and elaboration
this simulation is actually carried out
the simulated simulation itself is a
two-step process as I had described
earlier so what does analysis do it
checks for syntax and semantics syntax
is the grammar of the language semantics
is the meaning of the model you analyze
each design unit separately you place
analyzed units in a working library and
generally in an implementation dependent
internal form to enhance the efficiency
remember your description was a text
description and it need not be kept in
this form then you go to elaboration
step builds up a detailed circuit from a
hierarchical description you flatten the
design hierarchy you create ports which
are interfaces with other blocks create
signals and processes for each
instantiated component you copy the
component template to this particular
instance remember you may not have just
one flip-flop you describe a flip-flop
for once and now you may place say 20
flip-flops in your circuit each instance
is different the description occurs only
once but the actual copying has to be
done at the elaboration level you are
elaborating the entire circuit so you
take the template as the description and
make copies of this template for each
instance of the flip-flop and you repeat
this recursively till we are left only
with behaviorally described atomic
modules whatever these can these may be
for example basic gates might be our
atomic modules anything which occurs in
our library might be our atomic module
or indeed single transistors might be
our atomic modules the end result of
elaboration is a flat hierarchy free
collection of signal nets connected to
behaviorally described modules through
defined ports these define ports
describe which way the signal is flowing
is it an input to a module or an output
to a module so this is what elaboration
will do and finally we go to even driven
simulation we maintain a time ordered
queue of signals which are waiting to
acquire their assigned values if you
recall our discussion our discussion on
delta x now you realize how important
that is because for the user many events
might have occurred at the same time but
for the hardware description language
their time ordering is very important
and therefore we maintain a time ordered
queue of signals which are waiting to
acquire their assigned values
now we go to the earliest entry in this
cube and the time variable is given a
value which is equal to the earliest
entry in this time ordered Q all signals
which are waiting for acquiring their
values at this time are then updated to
their values this is when they acquire
the desired value so therefore all these
updates or transactions were kept in
this time ordered q and then we take up
one time instant at a time lookup all
the transactions which were placed for
this time and these transactions now
fracked if I that means these signals
actually acquire the value which they
were assigned perhaps at an earlier time
after updating these values we notice
which values have changed and if this
updating results in a change in the
value of his signal then we say that an
event has occurred on this signal this
is very important
because only if a signal has changed
that we want to Reese immolate a part of
the circuit we maintained as I had said
earlier its sensitivity list during the
elaboration phase we determine which
pieces of hardware are affected by or
are sensitive to which event and this is
called a sensitivity list the data
structure is optimized for reverse
lookup while describing we describe
hardware and then the hardware is
sensitive to certain inputs but we keep
the data in the opposite way that means
if we know that an event has occurred we
can go back and look up
all the pieces of hardware which were
sensitive to this event so that means
given an event one can quickly get a
list of all hardware which is sensitive
to this
notice that hardware could be sensitive
to a particular kind of change for
example you could have a flip-flop which
is sensitive to a rising edge of the
clock and not a falling edge so
therefore if the event is for a 1 to 0
transition the hardware doesn't bother
about it but on the other hand if the
change is from 0 to 1 then this Hardware
would like to reassign new values to its
output so in short we have a sensitivity
list the sensitivity is to particular
events and then whenever an event occurs
we have an efficient data structure
which then goes around looking for all
pieces of hardware which are sensitive
to this event which has currently
occurred when this event has occurred
then all pieces of hardware which are
sensitive to this event re simulated the
real simulation will then result in
further transactions so the simulation
cycle consists of the following the time
variable is advanced to the earliest
time entry in the time ordered queue of
transactions then we entered the update
phase in which all signals which are
which were to acquire their values at
the current time and then so we update
their values and then delete them from
the cube because after all we have
updated their values then we enter the
event handling phase so remember all
updates are done before you enter the
event handling place when all the
updating is completed then we have a
list of various events which have
occurred and it's only when we have
prepared this list that we enter the
event handling phase and now if the
value of a signal changes due to the
above update it is said to have had an
event and all events which resulted at
the current time are handled by a
scheduler this
we'll handle all the events in a
particular way for this lecture we shall
stop at this particular point and we
shall resume in the next lecture and see
an actual example of a very simple
circuit how it goes through the process
that I have described somewhat
abstractly here it is only when we look
at an actual circuit undergoing those
actions then it will become quite clear
to you how the transactions are handled
in a time-dependent way how the time
ordered queue is maintained how events
occurred due to updating of signals and
how are these events eventually handle
it so we shall do that in the next
lecture we stop here at this point in
this one
you