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. Based on some previous definitions of data of signal type, you'll be able to understand a case of use, in this case of use of the case sentence. You can see a couple of examples in this slide. Let's now see an example a bit more elaborated combining these two sentences if and case. We want to model and the LatMux scheme of the field, and to do so, we will declare an entity and an architecture. In the entity, we will see how we have have defined the entrance, exits, the in and outputs of this big box, the box. And next, we define an architecture we have called. There, we declare a mix signal, which we will use in this architecture to connect the to the multiplexor's output to the large input. And aside the architecture, between the begin and the end, we see how there are two processes, two model, two sub blocks. The first process model's the multiplexor with a case sentence. The second process model's, the latch with an incompletely specified if sentence which, as we have already seen, was one of the ways to model a latch. And these two processes are conquering among themselves. Although, each of them binds sequential sentences together. Be sure to understand this example before proceeding. As it contains processes, if then and case clauses. Once you have understood the previous example, let's see a small exercise. It's about describing the neo-architecture for this same model. And with the same entity in the previous example, but with that unique process. Can you give it a try? The idea will be fusing the two previous blocks multiplexer and launch in a single process. Ready? Okay, here we have it, a complete process which will model the complete functionality. Inside the process, we begin with some incompletely specified infrastructure, it only has the if clause, but doesn't have else which will model the latch. And inside this if, when the condition load is 0. If accomplished, in the then part we have included the case which models the multiplexor. This way, we have encapsulated algorithmically, and in a single process, the complete functionality of that LatMux value. We have seen how to decide based on that condition. BATL gives also the possibility to implement loops. BATL provides different way to control loops. There are three kind of loops as we can see in this slide. With while, you can implement loops controlled by a condition. While the condition is true, you'll keep in the loop. You can also loop based on repetition index with for, or either perform an infinite loop. If it doesn't have a while or a for sentence, this loop is an infinite loop. As an example, you can take a look at the n bits other. Here, we have the part of the n bits entity, which goes from the bit 0 to the bit n minus 1 through these four sentence. I like also to remark, BATL provides sentences to break into normal iteration segments in a loop. They are exit and next. Exit finishes the execution of the loop when it meets certain condition. And next doesn't finish the loop execution, but it jumps to the loops next iteration. And finally, let's see the functions and processes which followed the same guidelines as the vast majority of programming languages. Functions operate with input parameters, and they bring back a value through their return sentence. To make the code reusable, functions are usually defined in packets as we already said in a previous lesson, BATL. In this slide, you can see function declaration and examples of excuse. Procedures, as well as their anonymous software, operate within parameters, and their return values through their exit parameters. As for functions, we have also so examples of the declarations of use of the procedures in this slide. Again, we would like you to review the code and remember, reading and writing code is the best way to achieve knowledge of BATL. And finally, and let's have a look at the assert sentence, which we use to check situations, we can identify thus condition. When the Boolean expression is false, we print the corrected string, and we report the kind of problem we have detected, which can be just about warning, attention, or error or maybe failure. On the contrary, if the Boolean expression is true, we don't do anything. This slide, you can see also some easy and intuitive samples of how we can analyze these assert sentence. Finally, the report is a simplification of the assert, and it reports a message. So, the planet actions are made, depending on the severity level reported. We could say it's like an assert sentence, but with fixit to false, with a Boolean expression fixit to false. In fact, in this slide, you can see an accumulance of the report and the assert with explicit false condition. Let us summarize this session. As a summary, we could say that we have identified the main characteristics and difference among the sequential and the congruent rules in VHDL. We have a detailed a subset of all the sequential sentences available in this language, and we have also introduced you how to manage time in VHDL. Introducing, at the same time, the fundamental elements on the temporal simulation. Driven by events in which this language is based. And all these, along with samples to ease its comprehension. I said in the previous lesson on VHDL. Reading, writing code will be the best way to learn the language. And that's all for today. See you next time.
