These are predefined attributes listed in the VHDL language reference manual.
An attribute in VHDL is a meta property that’s attached to a type or object. We can use them to get information about the item that goes beyond the value it carries. Some attributes are only for simulation, while others are also useful for avoiding hard-coded constants in synthesizable code.
Note: This list is still incomplete. I’m adding sections regularly and will remove this notice when finished.
Active
When applied to a signal s, the active attribute works like a function call, returning true if s is active during the current simulation cycle and false if not.
If s is a composite signal, the whole signal is considered active if one of the subelements are.
The term active means that a signal assignment, force, or release is scheduled for the current simulation cycle, even if it’s the same value as the signal already had.
signal s : std_logic := '0';
begin
process
begin
s <= '0';
wait;
end process;
process
begin
report "Active: " & boolean'image(s'active);
wait for 0 ns;
report "Active: " & boolean'image(s'active);
wait for 0 ns;
report "Active: " & boolean'image(s'active);
wait;
end process;
# ** Note: Active: false
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: Active: true
# Time: 0 ns Iteration: 1 Instance: /test_tb
# ** Note: Active: false
# Time: 0 ns Iteration: 2 Instance: /test_tb
Ascending
a‘ascending[(n)]
The ascending attributes can be applied to scalar types or objects of them, including subtypes and aliases. It returns a boolean value that will be true if p has ascending range or false if it’s descending.
When called on an array a, the optional n parameter specifies which index range to check. It defaults to 1 when omitted, which is the only legal value for one-dimensional arrays anyway. But for multi-dimensional arrays, an n > 1 will check the direction of a subdimension.
signal s : std_logic_vector(7 downto 0);
type t1 is array (0 to 9) of bit;
type t2 is array (0 to 9, 7 downto 0) of bit;
begin
process
begin
report "s'ascending: " & boolean'image(s'ascending);
report "t1'ascending: " & boolean'image(t1'ascending);
report "t2'ascending: " & boolean'image(t2'ascending);
report "t2'ascending(1): " & boolean'image(t2'ascending(1));
report "t2'ascending(2): " & boolean'image(t2'ascending(2));
report "integer'ascending: " & boolean'image(integer'ascending);
report "std_logic'ascending: " & boolean'image(std_logic'ascending);
wait;
end process;
# ** Note: s'ascending: false
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: t1'ascending: true
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: t2'ascending: true
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: t2'ascending(1): true
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: t2'ascending(2): false
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: integer'ascending: true
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: std_logic'ascending: true
# Time: 0 ns Iteration: 0 Instance: /test_tb
Base
t‘base
When applied to an object, type, or subtype p, the base attribute returns the underlying type from which it originates. If there are multiple layers of subtypes, you get the root type that’s not a subtype.
You cannot use this attribute standalone. It must appear in conjunction with a second attribute, for example, p‘base‘right.
Language revisions before VHDL-2019 only support calling ‘base on types and subtypes (t).
subtype hex_type is integer range 0 to 15;
subtype dec_type is hex_type range 0 to 9;
signal p : dec_type;
begin
process
begin
report "hex_type'base'right: " & integer'image(hex_type'base'right);
report "dec_type'base'right: " & integer'image(dec_type'base'right);
report "p'subtype'base'right: " & integer'image(p'subtype'base'right);
-- (In VHDL-2019, you can do: p'base'right)
wait;
end process;
# ** Note: hex_type'base'right: 2147483647
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: dec_type'base'right: 2147483647
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: p'subtype'base'right: 2147483647
# Time: 0 ns Iteration: 0 Instance: /test_tb
Converse
VHDL-2019 adds mode views to interfaces and the converse attribute along with them. When called on a mode view m, converse returns a derived view with the modes from m transformed as follows:
| in | → | out |
| out | → | in |
| inout | → | inout |
| buffer | → | in |
| mode view (m) | → | m‘converse |
Consider this record and corresponding mode view:
type spi_if is record
sclk : std_logic;
mosi : std_logic;
miso : std_logic;
end record;
view spi_master_if of spi_if is
sclk : out;
mosi : out;
miso : in;
end view spi_master_if;
We could create an identical view with reversed data directions like this:
view spi_slave_if of spi_if is
sclk : in;
mosi : in;
miso : out;
end view spi_slave_if;
Or we can achieve the same by using the converse attribute:
view spi_slave_if is spi_master_if'converse;
Delayed
When applied to a signal s, the delayed attribute produces a signal that’s a copy of s, but with the transitions delayed by t time units. The derived signal will have a delay of one delta cycle if the optional t argument is omitted.
This example creates a signal b that’s delayed by one nanosecond from a.
signal a : std_logic := '1';
signal b : std_logic;
begin
a <= not a after 5 ns;
b <= a'delayed(1 ns);
The code above produces the following waveform in the VHDL simulator:
This example shows what happens if we don’t specify a time unit t.
signal a : std_logic := '1';
signal b : std_logic;
begin
a <= not a after 5 ns;
b <= a'delayed;
As we can see from the waveform below, signal b lags two delta cycles behind signal a. That’s because the derived signal is one delta cycle behind a, and when we copy it to b, it adds an additional delta delay.
Designated_subtype
When called on an access type or file type, object p, the designated_subtype attribute returns the subtype that the object references.
subtype byte_type is integer range 0 to 255;
type ptr is access byte_type;
-- This signal's type will be byte_type
signal sig : ptr'designated_subtype;
Driving
The driving attribute acts as a function returning a boolean value when applied to a signal s. You can only use this attribute from within a process or equivalent concurrent statement/subprogram. It will return true if the process is driving the signal and false otherwise.
If the s signal belongs to a port, it must have one of the following modes: inout, out, or buffer.
When used in a regular signal, the driving attribute always returns true. That’s because a process controlling a signal will always be driving it. However, that’s not always the case when it comes to guarded signals.
The demo below uses the driving attribute to print information about which process drives a value onto the common s signal bus.
Thanks to Bert Molenkamp for submitting this example to VHDLwhiz!
architecture sim of test_tb is
signal i1, i2, en1, en2 : std_logic := '0';
signal s : std_logic bus; -- Guarded signal
begin
P1 : process(i1, en1)
begin
if en1 = '1' then s <= i1; else s <= null; end if;
if s'driving then
report "P1 is driving s <= " & std_logic'image(s'driving_value);
else
report "P1 is not driving s";
end if;
end process;
P2 : process(i2, en2)
begin
if en2 = '1' then s <= i2; else s <= null; end if;
if s'driving then
report "P2 is driving s <= " & std_logic'image(s'driving_value);
else
report "P2 is not driving s";
end if;
end process;
TEST_PROC : process
begin
i1 <= '1'; i2 <= '0';
wait for 10 ns; en1 <= '1'; en2 <= '0';
wait for 10 ns; en1 <= '0'; en2 <= '1';
wait for 10 ns; en1 <= '1'; en2 <= '1';
wait for 10 ns;
end process;
end architecture;
The listing below shows the Questa simulator’s console printout after we simulate. The value of s'driving immediately reflects the latest signal assignment to s. We don’t have to wait until the next delta cycle for it to update after we assign s <= i1 or s <= null.
# ** Note: P2 is not driving s
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: P1 is not driving s
# Time: 0 ns Iteration: 0 Instance: /test_tb
# ** Note: P1 is not driving s
# Time: 0 ns Iteration: 1 Instance: /test_tb
# ** Note: P1 is driving s <= '1'
# Time: 10 ns Iteration: 1 Instance: /test_tb
# ** Note: P1 is not driving s
# Time: 20 ns Iteration: 1 Instance: /test_tb
# ** Note: P2 is driving s <= '0'
# Time: 20 ns Iteration: 1 Instance: /test_tb
# ** Note: P1 is driving s <= '1'
# Time: 30 ns Iteration: 1 Instance: /test_tb
The waveform below shows the signals during simulation. As expected, s ends up in driver conflict when we enable both driving processes with conflicting values.
Driving_value
When applied to a signal, s, the driving_value attribute works like a function call, returning the value that the enclosing process is driving onto the signal.
You can only use this attribute within a process or subprogram.
Calling driving_value on a signal that the process isn’t driving produces a runtime error. You can use the driving attribute to check if a process currently drives a signal.
architecture sim of test_tb is
signal s : std_logic;
begin
PROC_A : process
begin
s <= '1';
wait for 0 ns;
report "PROC_A drives " & std_logic'image(s'driving_value) &
", but s is " & std_logic'image(s);
wait;
end process;
PROC_B : process
begin
s <= '0';
wait for 0 ns;
report "PROC_B drives " & std_logic'image(s'driving_value) &
", but s is " & std_logic'image(s);
wait;
end process;
end architecture;
As we can see from the output below, the driving value may differ from the actual value of a resolved or guarded signal.
# ** Note: PROC_B drives '0', but s is 'X'
# Time: 0 ns Iteration: 1 Instance: /test_tb
# ** Note: PROC_A drives '1', but s is 'X'
# Time: 0 ns Iteration: 1 Instance: /test_tb
Quiet
When applied to a signal s, the quiet attribute produces a derived signal of boolean type. The resulting signal’s value is true if s was quiet for t time before the current simulation time. Otherwise, it has the value false.
The time value defaults to 0 ns if you omit the optional t parameter.
A signal is quiet if no assignments happen within the given period. When a value is scheduled or forced onto the signal, it is no longer quiet, even if it’s the same value as the signal already had.
signal quiet_50_ns : boolean;
begin
quiet_50_ns <= sig'quiet(50 ns);
Stable
When applied to a signal s, the stable attribute produces a derived signal of boolean type. The resulting signal’s value is false if there were events on s for t time before the current simulation time. If there were no events, it is true.
The time value defaults to 0 ns if you omit the optional t parameter.
An event is when a signal’s value changes. Assigning the same value that the signal already has doesn’t trigger events.
signal stable_50_ns : boolean;
begin
stable_50_ns <= sig'stable(50 ns);
process
begin
wait until falling_edge(sclk);
assert cs'stable(10 ns)
report "Falling SCLK too close to falling Chip Select"
severity failure;
end process;