Once we have seen the white signal, let's make a little remark on the simulation
driven by the VHDL events which will help us understand the importance of
the sentence to ease the process's communication through signals.
And from there, the work of the VHDL simulation cycle.
Simulation lead by events means that the processes simulation is only made on those
moments, in which there has been an event in any signal in.
Only those processes, which are activated by these moment's events are involved.
Time passing between two consecutive events
will not generate any simulation task.
If we look at the VHDL simulations cycle, we can see it has three stages.
First, we initialize the signals, and
then the stages of processes execution and signals update happen.
The processes are executed again.
The signals are updated again, and
this flow happens until the simulation is complete.
If we look at it with a bit more detail, in first place,
all the driver signals initialize.
Once this is done, a first run of all the obtained process is perform or
evaluated base it on a simulation model.
The execution of this processes will project events In a future,
on different signals.
When all this process is being execute, can't await sentence and
stop, we get to the drivers and signals of data stage.
Once the signals drivers are up-to-date,
we must check which is the closest instance.
When there's any event, and we forward the simulation time until this moment.
We'll go back to the process' execution, but now, reactivating all of those,
which in that moment, have a event which awakens or reactivates them.
We'll repeat these execution or update look until there isn't any event
left in any queue, any driver, or we have finished the estimated simulation time.
Look for instance, under darker deride.
We can see an example of the evolution of the simulation directed by events.
During events in times 0, 1, 3, 4, and 5.
And so, in this instance, it's going to processes
that have been activated due to the corresponding events are executed.
Between the times 1 and 3, there aren't events unsold.
Processes aren't evaluated.
If we detect that there has been one or more new event with no delay,
or doubted delay in a dry verse, or time of data stage,
we will evaluate getting the processes affected by these events.
But without going on in the simulation time,
this is what we call delta simulation cycle.
These cycles are represented by the marks we have in the different simulation
time moments, the delta delays consume simulation cycles, but
they don't make the simulation time go on.
After this decide on the simulation led by Boolean elements,
let's go back to the sequential sentences.
The next sentence we'll cover is the if-then-else, which can have nested ifs,
and can be incompletely specified, that is,
having if-then sentences without the need of an else.
Let's see some examples to understand how it works.
First, this scheme here, at the lower left corner, we have already seen it and
model the functionality of a multiplexer through this if-then-else sentence,
in this case, totally specified.
We have also discussed where the three state buffer looks like a multiplexer,
but when the condition isn't accomplished, we are seeing that to the exit
a high impotence value, which is equivalent to the disconnected exit.
There's also a buffered exit, which can have three different states.
The entrance value, which could be zero or one, and the z or high impotence.
The next sample is unlatched.
In this case, we have an if incompletely specified.
I mean, it's an if then, but we don't have an else clause.
How do we interpret this quote?
Well, if the condition 1 equals 1 is satisfied,
then the d entrance is sent to the queue exit.
But if this condition is not accomplished, we don't specify what we should do.
And so, we assume that we must save the last value found in Q.
Later, we will see that this code describes the function idea from memory
element which we call latch.
In this case, we see a nested eve, incompletely as specified.
If the first condition is accomplished, the queue signal takes a value of zero.
But if you listen, then we open a new eve, with an odd condition.
Which is clock and un-clock equals one.
Which means it has been a rising at each clock.
This belongs to the detection of a rising or positive edge on the clock signal, and
when this condition is accomplished, we must set the deep value in here.
And this if is incompletely specified, and
so, when the clock rising in this condition is an accomplish,
we will have to say in queue, the last part we have sent to it.
In short, this is a memory element which changes the [INAUDIBLE] signal.
And we are describing the functionality of a memory element we will call FlipFlop.
Once we have seen the if sentence, let's move to the next sequential sentence,
the case.
You can see the syntax here.
Different cases on the condition can be expressed not only as explicit values.
But also, as alternative values, values inside the range, or simply as others.
When a case isn't completely specified, and it doesn't have a close when others,
it means that for all non-specified cases, we must keep the values
previously associated to their affected variables or signals.
This will give place to a memory element of the latch type.
