The best thing is to use generics. Here's an example entity declaration for a shift register:
entity shift_register is
generic (n_bits :integer := 8);
port (clk :std_logic;
din :std_logic_vector (n_bits-1 downto 0);
dout :std_logic);
end entity shift_register;
When you instantiate this shift register you'd do it like this:
signal data :std_logic_vector (15 downto 0);
...
U0: shift_register
generic map (n_bits => data'length)
port map (clk, din, out);
In the entity, I defined the default value of n_bits to 8. When I instantiate it I could have left off the generic map stuff and then the default value of n_bits would be used.
EDIT: To better answer your question. Going in "reverse" doesn't really work that well, and I would avoid it if possible. But if you must, then you can always declare some constants in your package and use them farther up. It's not very clean, but it does work.
Bisg is an INPUT signal not an INOUT despite the fact that it has other uses (driving segment G on the top level).
To see this; reflect that NOTHING in your component actually drives BISG.
So your component is regarded as driving it with an undefined initial level; that is, 'U', and the combination of that 'U' with any external driving level is - as ISIM says - 'U'.
You have 2 options to fix it:
(1) make BISG an INPUT since you aren't driving it. This is the simplest and in this case correct.
(2) Drive BISG in your component with 'Z' - that is, remove the 'U' output from the component. 'Z' means "high impedance : i.e. don't fight whatever external source (your testbench) is driving the pin. This is typically done to allow 2-way communication on a signal. The two ends must agree (somehow) which end is allowed to drive the signal and the other end must drive 'Z'.
In your case, adding the line
BISG <= 'Z';
(after the "begin") to your component BCT should resolve the problem. (Yes, you are modifying the file labelled "do not modify", and the modification WILL disappear when you next compile the schematic to VHDL).
Then re-run the simulation and all should be well.
I do not know if there's a way to implement solution 2 in the schematic - and I don't care : these days the schematic approach is an utter waste of time.
Your whole schematic comes down to (the original entity, and)
architecture HDL of BCT is
begin
Bisg <= 'Z';
Bnisc <= not Bisg;
sf <= not Bisg and not A;
saisdise <= Bisg or not A;
sb <= '1';
end HDL;
And simplifies further if Bisg
is an input...
Which do you think is faster to create, and easier to read?
EDIT : if you need an output to drive segment G, there's nothing wrong with a separate port G, driven directly from input B, as G <= B;
or a wire on the schematic.
Best Answer
One case, that probably doesn't apply, is if you're using a standard older than VHDL-2002. Before than,
buffer
could not connect directly toout
. So in a hierarchical design, the signal path would need to be declared as abuffer
on all levels. Also, when adhering to these older standards, some tools have problems synthesizingbuffer
s correctly. They may or may not warn you about this.These should no longer be an issue if you're using a newer standard. From the VHDL-2002 Standard:
I also often see advice stating that a
buffer
should never be tri-stated. If you need the ability to tri-state a bus, then you would need to useout
. I could find no direct reference to howbuffer
s handled tri-stating in the standard. But it is probably good advice to follow. Again, your tools may or may not complain if you attempt to synthesis a tri-stated buffer.