We need do go one step farther. We have seen objects and data types, but what should we do now? Keep in mind, now, we are trying to model a digital system. To go farther, we'll introduce design units. There are five design units which are the entity, the architecture, the package declaration, the package body and configuration. In this brief introduction, we will only talk on three of them which will be the entity, the architecture, and the package. Although it's not a precise definition, we can say the entity would be the you're trying to simulate or implement. The architecture will be the description of how it works. Let me remark, this is not a formal definition. But I think it kind of hard for you to understand the language. The entity identifies a module. It defines its name, its in and outports but with no information of their functionality. The architecture will always be linked to an entity. It has access to the to the in and output ports of this entity, and it describes or models the functionality. For a single entity, we can provide more than one architecture but all of them will share the same block of in and out ports declared in the entity. Anyhow, in most of the examples we will use in this course, there will be only one architecture for each entity. But sometimes, it can be useful describing different architectural solutions for the same entity. We have seen entity and architecture. And now we'll briefly see the package, which contains declarations and definitions of data types. Objects and functions to ease their shared use in different BATL codes. Package contains a declarative part and a body. For our purposes, we will barely use the package body, because we will be able to declare and define everything we mean in the package declaration. But that will come later in the course. Let's get deeper into the design units. We have seen the entity is like a black box, which only defines the interfaces of each module, both in and out. It doesn't provide any information on it's behavior or functionality. In this slide, we can see an example of an entity definition. I'd like to focus on the entity name, or identifier and in the ports. In this example, we name an entity MUX21. We attach three imports, A, B, and Ctrl, and provide one output. As you see, the definition does not provide any idea of what this block is doing inside. That will be the work for the architecture. How does the entity behave or how is it structured? And that's what the architecture will tell us. As we can see here, there's an identifier, with the architecture's name and the reference to the entity. We'll have also a plot for declarations. I'd like to focus on the lines between beginning and end. That's where the behavior or the structure of the circuits you are designing will be described. In this slide we have two architectures for two similar entities. They have been put together for comparison as they have just sent between the begin and end is where the architecture is from. In this case there is a unique process which uses A, B, Ctrl and Z signals which are defined as in our entity. In side the process there is a simple if-then-else construction. If the Ctrl signal equals to 0 then Z take the value of A. And if it doesn't equal to 0, Zed will take the b. This behavior belongs to the one of a multi flexor controlled by control with two data entrances a and b. And the Zed data exit, which is what we have sketched in the slide. On the right side, We analyze the other entity we have defined. It's similar, but this is a generic parameter, 1n. This extension permits the user from associated architecture for a generic multi-plexor. As you see this architecture is exactly identical to the architecture in the first case. So we have also defined a multiplex server now and the ins and outs are not one beat signals but of n beats. The architecture of the previous example as a functional definition. It tells us how the entity behaves. But if you are thinking in a multiplex are created from logic gates BADL allows us to make a description based on this approach. In this case the architecture is a spaced logic gate. On logic gates, which we define as components in the alley, as components in this architecture's declaration part. After that, we make the appropriate instances for these components and we connect them in their in and out to the signals that have also been defined. So we have seen two architectures of the same entity with very different structural levels. Functional unstructural. Both of them behave as expected. And as you probably have noticed, there are other possible intermediate descriptions such as the one which answers to the figure in the upper part of the slide. Where we can see different logic functions in a graph which answers to the data flow. It resides through it's primary entrances. This architecture could be describe as we see here. In our architecture, we have fold data flow of the same to what. Inside which, we have defined its internal signals. Inside the architectural description zone, we set four concurrent designations as they model the logic functions In the graphic we have seen. As important aspect which sometimes can lead to confusion, to confusion, is that this designations are concurrent sentences. So the order in which they appear is irrelevant. To summarize, we have seen that one entity can have many different architectures. And with different abstraction levels. They all have their primary in and out ports in common defined in the entity. Once entity and architecture have been let's talk on the last design unit we will see, package. Package is a way to let me define as a name to genus. Package definitions of data types, objects, functions and processes to easily [INAUDIBLE] or reuse this functions in different [INAUDIBLE] codes. In this slide, you can see there are two different units. The package declaration and the package body. It block with its own syntax. To use package contents inside a certain code, we will use the use sentence which you can see in the bottom of the slide. You'll be able to use your own packages and at the same time use some standard which inside the default packages, which in fact are the most usable ones. STANDARD and TEXTIO are the default packages inside BXCL where we can find really a whole set of values functions and really useful standard logic and arithmetical operations. Based on these packages the designer can define his own packages which will help him to simply the BHCLs modeling words, under reuse of the code to allow the project's collaborative development. You will find the reference to this package in almost any code you read or create. Just as an example, you can review this slide where you see, there were farmings to that. Logic arith and logic 1164 package, commented. And also, in this slide the definition of our user refine package, for reutilization. I would encourage you to read the code presented in this slide as you will see there is also the definition of constant assuming, of constant data types and values to discuss them. Let me finish this short introduction to the packages with a comment regarding some of the IEEE standard packages. Here we have the standard package 1164 which defines a multivalued logic with up to nine different logic values. Not only a zero and one as maybe you may expect. It has a value of U, as non initialized, X for unknown, 0 for strong drive, logic zero, 1 for logic one, Z for height impedance or disconnected Double W for weak noun. L for week or h for height. Finally the hyphen which is redundant or indistinct term. Which means the position of this hyphen can be taken by any other value in the standard. So we mark all the values in this multi-valuated logic are necessary be able to calculate and simulate the digital circuits with bigger partition. Farther than pure binary 0 and 1, and so be able to manage the different situations in which we confine a digital signal inside a simulation. This package also has some simple subtypes. It has some logical arithmetic operations you find against this kind of beta and it also contains some data conversion functions from inter to multivalulated logic and vise versa. We have also another important standard package which is the arithmetic standard, which defines more complex operations and functions then the one's we have just seen and also are a bit more elaborative operations and functions. There are other packages, such as standard logic, signed and unsigned. In which the functions are defined to ease the work with numbers, with signs and numbers without signs. All these define and summarize baggage by weight. IEEE are recognized and used in a optimal way by the modeling simulation and synthesis tool which is, which eases the corresponding processes on the models. We are going to treat, use this package. So I would highly recommend you to make use of this standard practice. As a summary of this first BATL session we have interviews, the concept, and the main objectives of the hardware description. But watch this remember they are modeling simulation. We have introduced BADL Lexicon and syntax through the language of this constants, variables, and signals. Data types and language operators expressions. We have also seen how the language structure and designs. Entity, architecture, and package. And all this has been illustrated with small samples of code. Anyhow, the best to get interviews would be by reading and writing your own VHDL code. And that's all for today. Hope to see you soon in our next lesson.
