Vhdl Port Map Assignment Latin
Components and Port Maps
The example above shows the previously defined design entity AOI being used as a component within another, higher level design entity MUX2I, to create a design hierarchy with two levels. The design entity MUX2I also contains a second component, named INV. In order to write the VHDL for this circuit, we need to cover two new concepts: component instantiation (placing the INV and AOI inside another higher-level design, MUX2I) and port mapping (connecting up the two components to each other and to the primary ports of MUX2I). In VHDL, this is how we can model PCBs assembled from individual chips, for example.
The two component declarations (for INV and AOI) must match the corresponding entity declarations exactly with respect to the names, order and types of the ports. We've already seen enough of the AOI gate, let's see how closely the component and entity declarations match for the INV design entity.
entity INV is port (A: in STD_LOGIC; F: out STD_LOGIC);end INV;
component INV port (A: in STD_LOGIC; F: out STD_LOGIC);end component;
The two component declarations (for INV and AOI) appear in the architecture declarative part (that's a VHDL technical term that means that the component declarations are coded before the begin).library IEEE;use IEEE.STD_LOGIC_1164.all;entity MUX2I is port (SEL, A, B: in STD_LOGIC; F : out STD_LOGIC);end;architecture STRUCTURE of MUX2I iscomponent INV port (A: in STD_LOGIC; F: out STD_LOGIC);end component;component AOI port (A, B, C, D: in STD_LOGIC; F : out STD_LOGIC);end component;signal SELB: STD_LOGIC;begin G1: INV port map (SEL, SELB); G2: AOI port map (SEL, A, SELB, B, F);end;
The architecture STRUCTURE of MUX2I makes instances of INV and AOI through the component instantiations at the bottom of the architecture (labelled G1 and G2). The component names (INV and AOI) are references to design entities defined elsewhere. The instance labels (G1 and G2) identify two specific instances of the components, and are mandatory.
The ports in a component declaration must usually match the ports in the entity declaration one-for-one. The component declaration defines the names, order, mode and types of the ports to be used when the component is instanced in the architecture body. Instancing a component implies making a local copy of the corresponding design entity - a component is declared once within any architecture, but may be instanced any number of times. In this example, there is just one instance of the components AOI and INV.
Signals in an architecture are associated with ports on a component using a port map. In effect, a port map makes an electrical connection between pieces of wire in an architecture (signals) and pins on a component (ports). The same signal may be associated with several ports - this is the way to define interconnections between components.
In our MUX2I example, the signal SELB is associated with the F port of the INV instance and the C port of the AOI instance.
Your e-mail comments are welcome - send email
Copyright 1995-2016 Doulos
The length of std_center_height is also define by generics. How can I declare the others a OPEN in an elegant way?
There's a basic issue with your associations:
You specified that std_center_height and std_center_width depended on generics, which means the specified slices are locally static names.
IEEE Std 1076-2008 184.108.40.206 Association lists paragraph 16 (in part):
...Furthermore, every scalar subelement of the explicitly declared interface object shall be associated exactly once with an actual (or subelement thereof) in the same association list, and all such associations shall appear in a contiguous sequence within that association list. Each association element that associates a slice or subelement (or slice thereof) of an interface object shall identify the formal with a locally static name.
The first of these two sentences gives the reason why, you can't determine every subelement is connected at analysis time for a slice that's dependent on a generic.
There's a long chain of references on what makes up a locally static name (8.1 para 6, locally static name, 9.4.2 para 2 locally static range, para 1 g), 16.2.3 Predefined attributes of arrays ('LENGTH is a function).
You can't have a locally static name dependent on a subtype that isn't locally static. That means all three of those associations won't work. You could declare local constants or use a package whose declaration are visible to both the architecture instantiating CenterConfig and the entity declaration for CenterConfig but that doesn't help with the OPEN issue.
Is there something like (others => open)?
Nope. 220.127.116.11 Association lists paragraph 18:
It is an error if an actual of open is associated with a formal interface object that is associated individually. An actual of open counts as the single association allowed for the corresponding formal interface object, but does not supply a constant, signal, or variable (as is appropriate to the object class of the formal) to the formal.
You can't do individual association with some association subelements open it's all or nothing.
We know you can use a non slice name as a formal, the port name itself is a locally static name. We can use actuals that matches the length of the formals, and because you wanted elegant:
You can use aliases of slices of the used signal with the intended name.
And this example analyzes, elaborates and simulates:
ghdl -a center_config.vhdl
ghdl -e instance
ghdl -r instance
center_config.vhdl:71:10:@0ms:(report note): std_center_height length = 16
center_config.vhdl:73:10:@0ms:(report note): std_center_width length = 16
And this avoids the requirement for locally static names using slices or trying to specify open associations based on generics.
answered Apr 4 '16 at 0:54