Leon/grlib design and Configuration Guide

GUIDE, Apr 2018, Version 2018.1

24

www.cobham.com/gaisler

LEON/GRLIB Guide

7

GRLIB AMBA Test Framework

7.1

Overview

GRLIB has a number of packages that can aid in verification of AMBA cores. New developments 

should use the GRLIB AMBA Test Framework (ATF). The test framework consists of an AHB mas-

ter core,  an AHB  slave core  and  an AHB arbiter/controller  core. The AHB  master  and  slave cores 

have debug interfaces that allow them to be controlled using external stimuli.

The sections below give an overview of the components in the framework. The test framework is not 

distributed  as  a  product and there is no  complete user’s  manual. The  test  master and slave is  con-

trolled by procedure calls that are documented in their respective VHDL packages (described below).

ATF  files  are  located  in  the  directory  /lib/grlib/atf/. All  GRLIB  distributions  do  not 

include ATF. If the atf directory is missing from your GRLIB tree, then your version of GRLIB does 

not contain the components described in this section.

NOTE: The GRLIB AMBA test framework is NOT included in the free GRLIB-GPL.

7.2

AT AHB Master

7.2.1  Description

The AT AHB Master (AT_AHB_MST) is a non-synthesizable AHB master core with a debug inter-

face so that the master can be controlled via function calls. 

7.2.2  Initialization and Instantiation

The component for the master is defined in the package grlib.at_pkg and the procedure calls to con-

trol the master is available in the package grlib.at_ahb_mst_pkg. In order to instantiate the master, the 

following libraries should be included:

library ieee;

use ieee.std_logic_1164.all;

library grlib;

use grlib.amba.all;

use grlib.at_pkg.all;

use grlib.at_ahb_mst_pkg.all;

use grlib.testlib.all;

The component for AT_AHB_MST has the following interface:

component at_ahb_mst is

    generic(

      hindex:        in    Integer := 0;

      vendorid:      in    Integer := 0;

      deviceid:      in    Integer := 0;

      version:       in    Integer := 0;

      grlibdatamux:  in    integer := 1);

    port(

      -- AMBA AHB system signals

      hclk:          in    std_ulogic;

      hresetn:       in    std_ulogic;

      --AHB Interface

      ahbi:          in    ahb_mst_in_type;

      ahbo:          out   ahb_mst_out_type;

      --Operation Scheduling Interface

      atmi:          in  at_ahb_mst_in_type;

      atmo:          out at_ahb_mst_out_type

     );

   end component;

The only VHDL generics that require proper assignment are hindex and grlibdatamux. The hindex

generic must match the bus index in the same way as for other GRLIB AHB masters. The grlibdata-

mux generic decides if the core should use AMBA compliant data multiplexing (grlibdatamux => 0) 

or the simplified data multiplexing scheme (grlibdatamux => 1) commonly used in GRLIB (see the 

GRLIB  IP  Library  User’s  Manual,  grlib.pdf,  for  details).  For  use  in  a  normal  GRLIB  system  the 

default value is recommended. An example instantiation of AT_AHB_MST can be found in verifica-

tion/at/at_tb.vhd. At  the  top  of  the  file  the  libraries  mentioned  above  are  included. The  test  bench 

instantiates several AMBA masters, the signals used to control the debug interfaces are created as:

signal atmi  : at_ahb_mst_in_vector(0 to 2);

signal atmo  : at_ahb_mst_out_vector(0 to 2);

---

GUIDE, Apr 2018, Version 2018.1

25

www.cobham.com/gaisler

LEON/GRLIB Guide

The masters are then instantiated using a generate loop:

-- Masters

mstrs01 : for i in 0 to 2 generate

    amst : at_ahb_mst

     generic map(

       hindex         => FIRST_MASTER_INDEX+i,

       vendorid       => 0,

       deviceid       => 0,

       version        => 0)

     port map(

       -- AMBA AHB system signals

       hclk           => clk,

       hresetn        => rstn,

       

       -- Direct Memory Access Interface

       atmi           => atmi(i),

       atmo           => atmo(i),

       

       -- AMBA AHB Master Interface

       ahbi           => ahbmi,

       ahbo           => ahbmo(FIRST_MASTER_INDEX+i));

end generate;

The masters are controlled by calls from the test bench process. Before use, each master debug inter-

face must be initialized. In verification/at/at_tb.vhd this is done by calls to at_init(..):

testbench: process

----- variable definitions removed -----

  begin  -- process testbench

    ---------------------------------------------------------------------------

    -- Testbench initialization

    ---------------------------------------------------------------------------

    Print("----------------------------------------------");

    Print("AMBA Test Framework test bench");

    Print("----------------------------------------------");

    for i in atmi'range loop

      at_init(i, atmi);

    end loop;

    wait until rstn = '1'

7.2.3  Simple Accesses

After initalization has been performed, as described in the previous section, the procedures defined in 

grlib.at_ahb_mst_pkg (lib/grlib/atf/at_ahb_mst_pkg.vhd) can be used to command the master to per-

form accesses. The procedures are either read or write procedures. A read or write procedure can be 

either blocking (call will not return before the access is completed) or non-blocking (call will return 

immediately and another call must be made at a later time in order to complete the command on the 

debug interface). All non-blocking procedures have names ending with _nb, the procedures used to 

complete a non-blocking call have names that end with _nb_fin.

Procedures  that  make  single  accesses  are  named  in  the  following  format:  at_read_(..)  or 

at_write_(..).  Where    can  be  8,  16,  32,  64,  128  or  256.  The  non-blocking  pairs  are 

named at_read__nb(..) / at_read__nb_fin(..) and at_write_nb(..) / at_write_nb_fin(..). 

There  are  also  procedures  that  make  burst  accesses. These  have  the  word  burst  in  their  name,  for 

instance at_write_burst_32(..). The procedure names are overloaded and there can be several variants 

of a procedure, with a different number of parameters.

The simplest way to perform a single access, in this case a write, is to use a call like:

at_write_32(

address => X”h40000000”,

data => X”01234567”,

atmi => atmi(0),

atmo => atmo(0));

The non-blocking variant is (here we assume that we have defined the variable id as an integer and the 

variable ready as a boolean):

at_write_32_nb(

    address => X”h40000000”,

    data => X”01234567”,

    waitcycles => 0,

    lock => false,

    hprot => “0011”,

    back2back => false,

    screenoutput => false,

---