4

prepared by P. Bakowski

Signals values are changed by signal assignment statements. The simplest form of a signal assignment is:

signal_name <= value;  -- assigned after delta delay

This expression assigns the value of the signal at the beginning of the next simulation cycle. The left hand side of the signal assignment is referred to as target. When no explicit delay time is provided, the default time is a delay called delta delay.

The target signal may be assigned an explicit delay:

signal_name <= value after time_expression; -- called inertial delay

signal_name <= reject value after time_expression; -- called reject inertial delay

or

signal_name <= transport value after time_expression; -- called transport delay
 
 

signal res, sa, sb : integer;

signal a,b : bit;

a <=  b after 10 ns;

a <= transport b after 10 ns;

res <= sa + sb ;

For example, the simple signal assignment:

a <=  not b after 10 ns;

It is possible to apply  multiple transactions in one signal assignment. In this case the delay times  must be specified in ascending order.

type mlsig is ('0', '1', 'Z');

signal onde: mlsig:='0';

onde <= '1' after 5 ns, 'Z'after 10 ns, '1' after 15 ns, '0' after 20 ns;

..

The selected signal assignment represents an action in which the signal target is assigned the value chosen from a list of provided assignments.

with op_code select

sortie <= a and b after 6 ns when "001";
sortie <= a or b after 5 ns when "010";
sortie <= a nor b after 4 ns when "011";
sortie <= a xor b after 7 ns when "100";
sortie <= a nand b after 4 ns when "101";
sortie <= a when others;

VHDL provides two different models of time delay that correspond to the different sorts of delay encountered in the real word.

• inertial delay
• transport delay

The following are the actions performed by the simulator when  an inertial delay transaction is added to a driver.

• all old transactions scheduled to occur after the new transaction are removed
• new transaction is appended
• all existing transactions scheduled to occur before the new transaction are examined:
• if there is any transaction with a different value from the new transaction,

then all transactions up to the last one with a different value are deleted.
• the remaining transactions with the same value as the new transaction are kept.

sig <= '1' after 50 ns;

Remember that the inertial delay deletes all transient impulses which are shorter than the proposed delay. Suppose a signal sin carrying a transient impulse '0' => '1' => '0' with '1' lasting 3 ns; and following signal assignment:

sout <= sin after 10 ns;

Remark:

When a multiple transactions is specified with inertial delay, only the first transaction uses inertial delay; the rest are treated as being transport delay transactions.

---

reject inertial delay

In order to model the inertial delays more precisely, in VHDL'93 a new inertial delay mode is introduced: inertial delay with pulse rejection window.

Example:

out_sig <= reject 5 ns inertial not in_sig a after 15 ns;

The above assignment models an inverter which has a delay of 15 nanoseconds but ignores all  input signal changes  that persist less than 5 nanoseconds.

 

The second kind of the delay provided by VHDL is transport delay. This kind of delay is useful to model transit delays. For example the integrality of an input signal carried by an ideal transmission line is received at its output.

sig <= transport `Z' after 40 ns;

Inertial delay versus transport delay

The following examples show the output waveform in response to an input waveform entree using inertial assignment (a <= ..) and transport assignment (b <= ..).

In the first case , the inertial delay is probably the right choice because we wish to suppress transient perturbation.

In the second case, when we are going to model serial transmission line, the transport delay is more appropriate because the output waveform must mimic the input waveform exactly, regardless of the delay.

• attributes which define signals themselves

• and functions that provide the information about signals :

Example:

signal entree: bit;

if entree'event and entree='1' then ... -- rising edge

else ...

An example of a complete description of horloge entity:

entity horloge is

generic(period:time:=25 ns);

port(ph0,ph1: out bit);

end horloge;

architecture use_attributes of horloge is

signal con: bit:='0';

begin

con <= not con after period;

ph0 <=con;

ph1 <= con'delayed(period/2);

end use_attributes;

The `stable attribute is a boolean signal whose value is TRUE when an event has not occurred on the signal for the given time; otherwise is FALSE.

Detection of spikes (transients):

entity dff is

port(d: in bit; q : out bit);

end dff;

architecture spike_protected of dff is

begin

process

begin

wait until d'stable(5 ns);

q<= d after 7 ns;

end process;

end spike_protected;

The `transaction attribute is a bit signal which toggles every time when a transaction has occurred on the signal. Note that the `transaction attribute produces events even if the value of the signal has not changed.
 

begin
inst1:nand_gate port map(in1,in2,result);
output <= result;
accaunt_process:
process
variable counter: integer:=0;
begin
wait on result'transaction;
counter:=counter+1;
end process;

The `active attribute is a boolean signal which is TRUE when a transaction has occurred on the signal during the current simulation cycle. The `event attribute is a boolean signal which is TRUE when an event has occurred on the signal during the current simulation cycle. The following excl_process is sensitive to two input signals but its behavior depends on whether or not each of the inputs has changed.

entity buffer is
port(in1,in2: in bit; output: out bit);
end buffer;

architecture exclusive of buffer is
begin
excl_process:
process

begin
wait on in1,in2;
assert in1'active xor in2'active
report "concurrent input to buffer"
severity warning;
if in1'active then
output<=in1;
else
output<=in2;
end if;

The `last_active attribute returns the amount of time that has elapsed since there was a transaction on the signal. The `last_event attribute returns the amount of time that has elapsed since there was an event on the signal. The `last_value attribute returns the value of the signal before the last event.

entity sh_reg is
port(inbit,clk: in bit; outbit: out bit);
end sh_reg;

architecture pfalling of sh_reg is
begin
shift_process:
process

variable reg: bit_vector(7 downto 0)
begin
if clk'last_value='1' and clk='0' then
outbit<=reg(0);
for i in 0 to 6 loop
reg(i):=reg(i+1); -- in VHDL'93 shr operator
end loop;
reg(7):=inbit;
end if;
wait on clk;

Resolution function

The signals can have multiple drivers. The value of the signal is a function of all the drivers of that signal. The following figure shows an example of a bus signal which is driven by four independent signals. The value bus is computed by a bus resolution function (brf in this example).

The drivers are labeled s1,s2,s3, and s4. The value of the signal dbus is computed by a bus resolution function (brf in our example). Bus resolution functions are user-defined and are evaluated when one of the drivers of the signal receives a new value (event). The 'resolved' value is then generated by the bus resolution function.

Let us take a three-valued (tri-state) logic called TSL as follows and declare the bfr function;

type TSL is ('0','1','Z');

type TSL_V is array (integer range <>) of TSL;

signal dbus : bfr TSL;

subtype res_tsl is bfr TSL;

signal dbus : res_tsl;

function brf (signal ins: TSL_V) return TSL is

variable resolved_value: TSL:='Z';

begin

for i in ins'range loop

if ins(i) /= 'Z' then

resolved_value:= ins(i);

exit;

end if;

end loop;

return resolved_value;

end brf;

In general this assumption is to strong while in reality more than one signal may be active at the same moment. That is why we need a more complete resolution function able to detect the potential conflicts.

function brf_2 (signal ins: TSL_V) return TSL is

variable resolved_value: TSL:='Z';

variable etat: TSL:='Z';

begin

for i in ins'range loop

if ins(i) /= 'Z' then

assert (etat = 'Z')

report "second active driver"

severity warning;

resolved_value:= ins(i);

etat:= ins(i);

end if;

end loop;

return resolved_value;

end brf;

Remark:

All complete simulation environments provide standard logic package. This package defines resolution function used with std_logic signals

The variable assignments:

variable a,s,t: integer;

...

a := s + t;

b := a * r;

signal a,s,t: integer;

...

b <= a * r; -- second process with sensitivity list of a and r (equivalent to)

a <= s + t; -- first process with sensitivity list of s and t (equivalent to)

In our example the next value for signal a will be ready after a delta time. This in turn will activate the second process and generate a new value for signal b after a following delta time. Note that the order of execution of signal assignments is independent of their typographic order. This kind of execution is called non-procedural.
 

begin
a <= s + t;
end process proc_1;

begin
b <= a * r;
end process proc_2;

The following tables provide the comparison between variable and signal evaluations for a given example.
 

Now we can consider an example of a simple rs flip-flop. The process below describes the operations of this flip-flop using two signal assignments.

rs_p: process(r,s)

begin

q <= r nand nq;

nq <= s nand q;

end process rs_p;

Is it possible to describe the function of this rs flip-flop using variable assignments ?