Experience

Our case study is the design of a controller ( TLight) for a traffic light at the intersection of a highway and a farm-road. It is a variation of the controller given in [5]. The behaviour of the controller is as follows. The highway lights remain green as long as there are no cars on the farm-road. When the highway lights have been green for a minimum of ten seconds, a car on the farm-road will cause the highway lights to go yellow for three seconds and then red. Then the farm-road lights will turn green and remain green for a minimum of three seconds. The presence of other cars on the farm-road beyond the three seconds will enable the farm-road lights to remain green for a maximum of ten seconds. The farm-road lights will then go yellow for three seconds and then red.

The controller has four states, highway green ( HG), highway yellow ( HY), farm-road green ( FG) and farm-road yellow ( FG). In state HG, the highway lights are green and the farm-road lights are red. In state HY, the highway lights are yellow and the farm-road lights are red. In state FG, the farm-road lights are green and the highway lights are red. In state FY, the farm-road lights are yellow and the highway lights are red. The controller has five control signals: clear, car , sto, lto and clk. The control signal clear is asynchronous. All other control signals are synchronous. When clear is asserted, the controller resets to state HG. When car is asserted, a car is present on the farm-road. When lto is asserted, a long-delay timer has reached the ten second mark. When sto is asserted, a short-delay timer has reached the three second mark. State transitions are shown in Figure 1.

  
Figure 1: Traffic Light Controller FSM

The entity declaration for TLight is:

entity TLight is
   port (clear, car, sto, lto, clk: in bit;
   hwred, hwyellow, hwgreen, farmred, 
   farmyellow, farmgreen: out bit);
end;

There are five single-bit inputs and six single-bit outputs. The five inputs correspond to the control signals described earlier. Three of the outputs correspond to the red, green and yellow lights visible from the highway. The other three correspond to the red, green and yellow lights visible from the farm-road.

The following VHDL definitions are used in the driver.

constant Td:time:= 20 ns; 
constant Id:time:= 5 ns;  
constant HGLIGHTS: bit_vector := "001100";
constant HYLIGHTS: bit_vector := "010100";
constant FGLIGHTS: bit_vector := "100001";
constant FYLIGHTS: bit_vector := "100010";
constant NumOutputs: integer := 6;
constant NmInp: integer := 3;
constant MaxInpVal: integer := 7; 
-- 2 to the power of NmInp less 1

type LightState is (HG, HY, FG, FY);

variable s: LightState;
variable i, choice: integer;
variable test_vector: bit_vector (0 to NmInp-1);
alias t_car: bit is test_vector(0);
alias t_sto: bit is test_vector(1);
alias t_lto: bit is test_vector(2);

The constant Td is the time the clock is asserted. The constant Id is the minimum time that clear must be asserted to reset the controller. The constants HGLIGHTS through FYLIGHTS are output bit patterns corresponding to valid traffic light settings. The variable test_vector is used to accumulate test values for the car, sto and lto signals. It ranges in value from zero to MaxInpVal.

The testing interface for TLight consists of the following procedures and functions:

procedure TLInit  is
begin
   clear<='1', '0' after Id;
   wait until clear'event and clear='0';
end;

procedure TLSetInputs 
          (x: in bit_vector(0 to NmInp-1)) is
begin
   car<=x(0);
   sto<=x(1);
   lto<=x(2);
   clk<='1', '0' after Td;
   wait until clk'event and clk='0';
end;

function TLGetOutputs return bit_vector is
   variable x: bit_vector (0 to NumOutputs-1);
begin
  out_capture(x); -- capture output bit vector
  return (x);
end;

procedure TLLoadState(n: in LightState) is
begin
   case n is
      when HG => TLInit;
      when HY =>
         TLInit;
         TLSetInputs("101");
      when FG =>
         TLInit;
         TLSetInputs("101");
         TLSetInputs("010");
     when FY =>
         TLInit;
         TLSetInputs("101");
         TLSetInputs("010");
         TLSetInputs("001");
  end case;
end;

TLinit asserts the control signal clear. TLSetInputs allows for the selective assertion of the control signals car, sto and lto. TLGetOutputs returns controller output. TLLoadState sets the state of the controller. It is included to aid testability.

We have developed test cases to exhaustively test the behaviour of the controller. The following is an extract from our test script:

tcase(TLLoadState(HG), TLGetOutputs, HGLIGHTS)
tcase(TLLoadState(HY), TLGetOutputs, HYLIGHTS)
tcase(TLLoadState(FG), TLGetOutputs, FGLIGHTS)
tcase(TLLoadState(FY), TLGetOutputs, FYLIGHTS)

for s in HG to FY loop
   for i in 0 to MaxInpVal loop
      test_vector := conv_bit_vector(i,NmInp);
      case s is
         when HG => 
            if not ((t_car='1') and 
                   (t_lto='1')) then
               tcase(TLLoadState(s); 
                     TLSetInputs(test_vector),
                     TLGetOutputs,
                     HGLIGHTS)
            else
               tcase(TLLoadState(s);
                     TLSetInputs(test_vector), 
                     TLGetOutputs, 
                     HYLIGHTS)
            end if;
         when HY => 
            ...
         when FG => 
            ...
         when FY => 
            ...
      end  case;
   end loop;
end loop;
...

The first four test cases check for correct output when the controller is in one of its four states. For a particular state, the inner for loop applies all possible input values for the control signals car, sto and lto to the CUT and, checks for correct state-transition and output. The outer loop repeats the process for all controller states.

Notice how the testing interface provides a view of the CUT that allows the test-engineer to concentrate on behavioural verification. The test-engineer is not distracted by the CUT's interaction with other components. This is taken care of within the testing interface. This separation of concerns increases test controllability and observability and, facilitates the construction of test code that is more maintainable.

Exhaustive testing is not feasible for systems with a large number of states and a large number of inputs. For large systems, we select our tests-cases in a manner analogous to selecting test cases for software modules [2].