One of the characteristics of VHDL is that it allows a verification testbench to be written in the same language as the design to be verified. However, some aspects of earlier versions of VHDL make it hard to verify designs. In particular, the scope and visibility rules are intended to help us manage name spaces in complex designs by enforcing abstraction of interfaces and hiding of internal information. While they are good for a design in isolation, they can prevent a testbench from accessing items internal to a design. A test-bench may need to monitor the state of internal signals, or force internal signals to particular values.

VHDL-2008 provides a new naming feature, external names, that allows us to write a testbench that accesses items not normally visible according to the hierarchical scope and visibility rules. An external name specifies a hierarchical path through the design hierarchy to reach a declared constant, shared variable, or signal. Thus, a testbench using an external name must have sufficient knowledge of the hierarchical structure of the design for the path to be valid. Validity of the external name is assumed during analysis of the testbench, and is checked during elaboration of the complete design hierarchy.

An external name is written in the following form:

<< class external_pathname : subtype >>

where the class is one of the object classes constant, signal, or variable; the external pathname is the hierarchical path; and the subtype specifies a view of the object, in a way similar to an alias. As an example, a testbench might use the following external name to monitor the value of a signal within a design under verification:

assert <<signal .tb.duv.controller.state:
                  std_logic_vector(0 to 4)>> /= "00000"
   report "Illegal controller state";

Within the testbench, this external name is a reference to a signal nested within the component labeled controller, which is nested within the component labeled duv, which is within the top-level entity tb. The signal is interpreted as a std_logic_vector indexed from 0 to 4. When the testbench is analyzed, the existence and type of the signal is not checked. However, once the complete design hierarchy is elaborated, the signal must exist and be of an appropriate type to match the subtype specified in the external name.

An external name is just a new form of name for a constant, signal or variable, so we can use an external name at any place where a name is appropriate, subject to some rules that we will return to shortly. That means we can refer to a constant or signal value in an expression, and we can assign to a signal or include it in a port map. The rules for forming a pathname only allow us to refer to items declared in concurrent regions of a design (packages, entities, architectures, blocks and generate statements), so an external variable name can only refer to a shared variable. We can use an external variable name to invoke a method of the shared variable, for example:

<<variable .tb.duv_behavior.msg_fifo:
             fifo_type<<.put(corrupt_msg);

For an external name that refers to an object of a composite type, we can refer to an element of the object. For example, given an array signal declared within a design, we can index the array with an external name as the prefix:

<<signal .tb.duv_rtl.data_bus:
           std_logic_vector(0 to 15)>>(8) >= '1';

One common use case is to declare an alias for an external name. If we do that, we need only write the full external name in the alias declaration. Thereafter, we can just use the shorter alias name, making the model more succinct. For example, if we need to refer to the data_bus signal in several places in a testbench, we could declare an alias for it:

alias duv_data_bus is
  <<signal .tb.duv_rtl.data_bus : std_logic_vector(0 to 15)>>;

and then just use the alias in the assignment and other places:

duv_data_bus(8) <= '1';
sign <= duv_data_bus(0);

In an alias declaration, we have the option of specifying a subtype after the alias name, giving us a view of the named object as being of that subtype, for example:

alias identifier : subtype is name;

However, when the name we are aliasing is an external name, the subtype is specified in the external name. We do not repeat the subtype (or specify a conflicting sub-type!) after the alias name. So the following two alias declarations are illegal:

alias duv_data_bus : std_logic_vector(0 to 15) is -- illegal!
  <<signal .tb.duv_rtl.data_bus : std_logic_vector(0 to 15)>>;

alias duv_data_bus : std_logic_vector(15 downto 0) is -- illegal!
  <<signal .tb.duv_rtl.data_bus : std_logic_vector(0 to 15)>>;

We can use an external constant name (or an alias of such a name) in an expression, provided the constant has been elaborated and given a value by the time the expression is evaluated. In some cases, expressions are evaluated during elaboration of a design. For example, initial-value expressions and index-bound expressions in declarations are evaluated when the declaration is elaborated, so an external constant name appearing in those places must refer to a constant that has already been elaborated. We can ensure this is the case by writing the part of the design that includes the constant declaration prior to the part of the design that contains the external constant name. VHDL’s elaboration rules specify that the design is elaborated in depth-first top-to-bottom order. To illustrate how we can take account of this order, suppose we have an entity and architecture for a design that declares a constant, as follows:

entity design is
  port ( . . . );
end entity design;

architecture rtl is
  constant width : natural := 32;
  . . .
begin
  . . .
end architecture rtl;

Suppose also that we have a testbench entity and architecture:

entity testbench is
end entity testbench;

architecture directed of testbench is
  signal test_in:
     bit_vector(0 to <<constant .top.duv.width : natural>> - 1) ;
  . . .
begin
  . . .
end architecture directed;

We now assemble the design and testbench in a top-level entity and architecture:

entity top is
end entity top;

architecture level of top is
begin
  assert false
     "Width = " &
     integer'image(<<constant .top.duv.width : natural>>);
  duv : entity work.design(rtl);
  tb  : entity work.testbench(directed);
end architecture level;

In this case, the instance of the design under verification is elaborated before the testbench instance. Thus, the constant declaration is elaborated and given a value before the external constant name within the tb instance is elaborated. Had we written the two instances in the reverse order, the constant would not have been elaborated at the time of elaborating the external constant name, and an error would occur. The external constant name in the assertion statement, on the other hand, is not evaluated until the model is executed, by which time the model is completely elaborated. Thus, the external constant name is allowed to precede the instance of the design under test in which the constant is declared.

VHDL-2008 has a related rule regarding elaboration of a signal referenced by an external signal name. If such a name (or an alias of such a name) is used in a port map, the signal declaration must have been previously elaborated. The reason is that the hierarchy of signal nets and drivers is built during elaboration. If a signal used in a port map is not yet elaborated, the elaborator would have to revisit elaboration of that part of the design hierarchy once the signal declaration was encountered. In general, allowing such use of external signal names would make elaboration of signal nets indefinitely complicated. The rule preventing such use allows elaboration to proceed in a well-defined order, and is not onerous in practice. It usually just requires that the component instance in which the signal is declared be written before the instance referencing the signal in a port map. The typical scenario is that a design under verification be instantiated before the testbench code containing external names.

The pathname in an external name identifies the location of the referenced object within the design hierarchy. A design hierarchy has an instance of an entity and some associated architecture at the top level. The entity and architecture can contain declarations of objects. We can identify such an object by naming the entity followed by the object name. The entity and architecture can also contain nested regions, which can in turn contain declarations of objects. We can identify an object in such a nested region by joining the object name onto the name for the region and the name for the top-level entity. In the case of a block, the name for the region is the block label. In the case of a generate statement, the name for the region is the generate label. A for-generate also requires a value to indicate which iteration of the generate to use. In the case of a local package (see Section 1.3), the name for the region is the package name. Note that we cannot use the name of an uninstantiated package (see Section 1.2) in this way; we can only use the name of an instance of the uninstantiated package. In the case of a component instance, the name of the region is the component instance label, and the region is that corresponding to the bound entity and architecture. We can apply these rules recursively to build up a chain of region names, starting from the entity at the top of the design hierarchy and leading through levels of nesting to identify any object instantiated within the hierarchy.

The pathnames in the preceding external names are all examples of absolute path-names, which specify the full chain of region names, starting from the top of the design hierarchy containing the external name. An absolute pathname starts with a dot symbol and separates each region name within the pathname with further dot symbols. The pathname ends with the simple name of the referenced object. Thus, the absolute pathname

    .tb.duv_rtl.data_bus

refers to the object named data_bus declared within the entity and architecture bound to the component labeled duv_rtl within the top-level entity tb. Similarly, the absolute pathname

   .tb.duv_rtl.memory(3).addr_bus

refers to the object named addr_bus within the for-generate iteration with index 3 within the component instance mentioned.

library IEEE; use IEEE. std_logic_ll64.all;
entity control is
   port ( clk, reset : in  std_logic; . . . );
end entity control ;

architecture fsm of control is
   subtype state_type is std_logic_vector(3 down to 0);
   constant idle     : state_type := "0000";
   constant pending1 : state_type := "0001";
   . . .
   signal current_state, next_state : state_type;
begin
   state_reg : process (clk) is . . .
   fsm_logic : process (all) is . . .
end architecture fsm;

library IEEE; use IEEE.std_logic_1164.all;
entity system is
   port ( clk, reset : in std_logic; . . . );
end entity system;

architecture rtl of system is
   component control is
      port ( clk, reset : in std_logic; . . . );
   end component control ;
begin
   control_unit : component control
      port map ( clk => clk, reset => reset, . . . );
   . . .
end architecture rtl;

entity state_monitor is
   generic ( state_file_name : string );
end entity state_monitor;

architecture tracing of state_monitor is
   alias fsm_clk is
      <<signal .tb.system_duv.control_unit.clk : std_logic>>;
   alias fsm_state is
      <<signal .tb.system_duv.control_unit.current_state:
                 std_logic_vector(3 downto O)>>;
begin
   monitor : process (fsm_clk) is
      use std.textio.all;
      file state_file : text open write_mode is state_file_name;
   begin
      if falling_edge(fsm_clk) then
         write(L, fsm_state); writeline(state_file, L);
      end if;
   end process monitor;
end architecture tracing;

library IEEE; use IEEE.std_logic_ll64.all;
entity tb is
end entity tb;

architecture monitoring of tb is
   signal system_clk, system_reset : std_logic;
   . . .
begin
   . . . -- clock and reset generation
   system_duv : entity work.system(rtl)
     port map ( clk => system_clk, reset => system_reset, . . . ) ;

   state_monitor : entity work. state_monitor(tracing)
     generic map ( state_file_name => "fsm_states.dat" );

end architecture monitoring ;

In some testbenches, the testbench code is written in the same region as an instance of the design under verification. In those cases, there is no need to specify the absolute path starting from the top-level entity. Instead, we can use a relative pathname, consisting of the chain of region names starting from the immediately enclosing region, without the leading dot symbol. For example, if a testbench architecture includes an instance of the design under verification labeled duv, then the architecture could also contain the assertion statement:

assert <<signal duv.controller.state :
                   std_logic_vector(0 to 4)>> /= "00000"
  report "Iilegal controller state" ;

Since the starting point for the relative pathname is the enclosing architecture region, the first part of the pathname refers to the component instance, and subsequent parts refer to items nested within the bound entity and architecture.

An important point to note when we are talking about the innermost region for a relative pathname is that only concurrent regions are considered. If we write an external name with a relative pathname within a process or subprogram, that region does not count, since it is not a concurrent region. Moreover, if the name is within a package that is declared within a process or subprogram, the package region does not count either. We need to look outward in the design hierarchy to find an enclosing entity, architecture, block, or generate statement, or a package that is declared in such a region.

architecture monitoring of tb is
   signal system_clk, system_reset : std_logic;

   alias fsm_clk is
      <<signal system_duv.control_unit.clk : std_logic>>;
   . . .
begin

   . . . -- clock and reset generation

   system_duv : entity work.system(rtl)
     port map ( clk => system_clk, reset => system_reset, ... );

   monitor : process (fsm_clk) is
     use std.textio.all;
     file state_file : text open write_mode is state_file_name;
     alias fsm_state is
         <<signal system_duv.control_unit.current_state:
                             std_logic_vector(3 downto 0)>>;
   begin
      if falling_edge(fsm_clk) then
          write(L, fsm_state); writeline(state_file, L) ;
      end if;
   end process monitor;

end architecture monitoring;

A further form of relative pathname allows us to identify an outer region as the starting point for the pathname. We write such a pathname using one or more leading “^” symbols in place of names, for example:

<<constant ^.^.comp.c : real>>

As for the relative pathname without the “^” symbols, we initially start with the innermost concurrent region enclosing the external name. Then, for each “^” symbol, we look in the next enclosing region. In the case of instantiated components, the region enclosing an instance of a bound entity and architecture is the region in which the instantiation is written. Thus, if we use this form of pathname in an entity or architecture, we are making a strong assumption about the context in which the entity and architecture are instantiated. Specifically, we are assuming that context also includes the names written in the pathname. The complete design hierarchy must be built in such a way as to ensure the assumption is met, otherwise an error will occur during elaboration.

entity CPU is
   . . .
end entity CPU;

architecture BFM of CPU is
   use work.CPU_types.all;
   signal fetched_instruction : instruction_type;
   . . .
begin
   . . .
end architecture BFM;

entity platform is
   generic ( num_cores : positive );
   port    ( . . . );
end entity platform;

architecture BFM_multicore of platform is
   . . .
begin
   cores : for core_num in 1 to num_cores generate
     processor : entity work. CPU(BFM) . . . ;
     . . .
   end generate cores;
   . . .
end architecture BFM_multicore ;

entity testbench is
   generic ( num_cores : positive );
end entity testbench;

architecture test_BFM of testbench is
   . . .
begin
   duv : entity work.platform(BFM_multicore)
     generic map ( num_cored  => num_cores )
     port map ( ... );
   monitors : for core_num  in 1 to num_cores generate
     use work.CPU_types.all, work.CPU_trace.all;
     process is
     begin
       ...
       trace_instruction
         ( <<signal
            ^.duv.cores(core_num).processor.fetched_instruction:
               instruction_type>>,
            . . . );
       . . .
     end process;
  end generate monitors;
end architecture test_BFM;

We also need to be able to refer to an object declared in a package referenced by a design. For objects declared in the package declaration, we can just use the package name as a prefix in a normal selected name to refer to the object. However, objects declared in the package body are not visible to designs. They would normally be referenced indirectly using procedures declared in the package declaration. A testbench, on the other hand, can use an external name to refer to such a hidden object. An object in a package is not nested within the design hierarchy, but is considered to be nested within the library containing the package. So the chain of region names starts with the library logical name (the name defined by a library clause) and leads through the top-level package name and any nested package names to the referenced object.

A package pathname takes a similar form to an absolute pathname, but starts with an "@" symbol instead. That is followed by logical name of the library containing the package, then the package name, then the names of any intervening nested packages, and finally the object name. For example, given the following package declaration and body analyzed into the working library:

package p1 is
   . . .
end package p1;

package body p1 is
   . . .
   package p2 is
      signal s : bit;
   end package p2;
   . . .
end package body p1;

we could write the following external name to refer to the signal:

<<signal @work.p1.p2.s : bit>>

When verifying a design, we often would like to be able to override the value assigned to a signal in the normal course of design operation and force a different value onto the signal. One reason for doing this is to set up a test scenario by forcing values to a state that would normally be arrived at through a complex initialization sequence. Forcing the values allows us to bypass the sequence and set up the scenario quickly, and so reduce the verification time significantly. Another reason for forcing values is to inject erroneous values into the design to ensure that it detects the error or otherwise responds appropriately.

In earlier versions of VHDL, there was no way to override the value assigned to a signal by the design, other than using commands provided by a simulator. That meant we could not write VHDL testbench code to force signal values. VHDL-2008 now provides features for forcing and releasing the values of signals. We can force a signal with a force assignment of the form

signal_name <= force expression;

This is a sequential assignment written within a process forming part of the test-bench. The effect is to cause a delta cycle and to force the named signal to take on the value of the expression in that delta cycle, regardless of any value assigned to the signal by any normal signal assignment. The signal is considered to be active during the delta cycle, and if the forcing value is different from the previous value, an event occurs on the signal. Processes sensitive to changes on the signal value would then respond to the value change in the normal way.

The usual rules relating the type of the expression to the type of the target signal apply for force assignments. The target signal name can be a normal signal name, or it can be an external signal name or alias (see Section 2.1). Using external names would be a common use case, since we would often need to force an internal signal of a design from a testbench.

Once a signal has been forced, we can update the signal with another force assignment to change the overriding value, again causing the signal to become active and possibly to have another event. We can do this as often as needed. Eventually, if we want to stop forcing a signal, we can execute a release assignment of the form

signal_name <= release ;

This causes a further delta cycle, with the signal being active. However, since the signal is no longer forced, the current values of its sources are used to determine the signal value in the normal way. We can think of this as the design “taking back control” of the signal.

verify_state_recovery : process is
  use work. control_pkg .all ;
  alias clk is <<signal duv.clk : std_logic>>;
  alias current_state is
          <<signal duv.control.current_state : state_type>>;
begin
  . . .
  -- inject corrupt state
  wait until falling_edge(clk);
  current_state   <= force illegal_state_12;
  wait until falling_edge(clk);
  current_state   <= release;
  -- monitor recovery activity
  . . .
end process verify_state_recovery;

Our discussion of force assignments has so far focused on signals. We can also force and release ports of a design, since they are a form of signal. However, for a port, we distinguish between the driving value and the effective value. The driving value is the value presented externally by an entity, and is determined by the internal sources within the entity. The effective value is the value seen internally by an entity and is determined by whatever is externally connected to the port, whether that be an explicitly declared signal or a port of an enclosing entity. Depending on the port mode and the external connections, the driving and effective values may be different. For example, an inout-mode port of type std_logic might drive a ’0’ value, but the externally connected signal might have another source driving a ‘1’ value. In that case, the resolved value of the signal is ‘XI’, and that value is seen as the effective value of the inout-mode port.

VHDL-2008 allows us to force the driving and effective values of a signal or port independently by including a force mode in an assignment. For explicitly declared signals, where the driving and effective values are the same, the distinction makes no difference. For ports and signal parameters, we can force the driving value by including the keyword out in the force assignment:

signal-name  <= force out expression;

Alternatively, we force the effective value by including the keyword in in the force assignment:

signal-name  <= force in expression;

Once we’ve forced a port’s or signal parameter’s driving value, we can stop forcing it by writing a release assignment with the keyword out:

signal-name  <= release out expression;

Similarly, to release a forced effective value, we write a release assignment with the keyword in:

signal-name  <= release in expression;

We can force and release driving values of ports of mode out, inout, and buffer, but not ports of mode in. Similarly, we can force and release driving values of signal parameters of mode out and inout, but not signal parameters of mode in. One of the VHDL-2008 changes for ports and parameters, described in Section 6.3, is that we can read the value of an out-mode port or parameter. This means that ports and signal parameters of all modes except linkage have effective values, and so we can force and release the effective value of a port or signal parameter of any mode except linkage.

If we omit the force mode (out or in) in a force or release assignment, a default force mode applies. For assignments to ports and signal parameters of mode in and to explicitly declared signals, the default force mode is in, forcing the effective value. For assignments to ports of mode out, inout, or buffer, and to signal parameters of mode out or inout, the default force mode is out, forcing the driving value.

. . .
-- Test scenario: break in the output connection
<<signal duv.SDA : std_logic>> >= force out 'Z';
-- Monitor device operation under this fault condition
. . .
-- Restore connection for the next scenario
<<signal duv.SDA : std_logic>> >= release out;
. . .

VHDL allows us to assign a composite value to a collection of signals by writing the collection in the form of an aggregate on the left-hand side of the assignment, for example:

(carry_out, sum) >= ('0' & a) + ('0' & b);

Note, in passing, that this form of aggregate assignment is legal in VHDL-2008 (see Section 6.4). We cannot, however, write an aggregate of signal names as the target of a force or release assignment to force or release each of the signal values. Instead, we must write a separate force or release assignment for each of the signals. For example, if we want to force and release the driving values of the two ports carry_out and sum, we would have to write:

sum <= force out unsigned'("00000000");
carry_out <= force out '1';
. . .

sum <= release out;
carry_out <= release out;

There is a further form of target signal for which we cannot write a force or release assignment. Suppose we define a resolved signal of a composite type, such as an array type. By that, we mean a signal with multiple sources, each of which is a composite value. The resolution function for the signal takes an array of composite values and determines a composite value as the resolved value of the signal. We cannot write a force or release assignment with an element of such a signal as the target. We can only force or release the signal as a whole. This mirrors the requirements that a process driving such a signal have a driver for all elements of the signal, and that sources for such a signal be sources for the entire signal. Note that resolved composite signals are different from signals of resolved elements, for example, signals of type std_logic_vector. We can force and release individual elements or slices of those signals, since each element is resolved individually.

Another case to consider is a force or release assignment written in a subprogram. VHDL has a rule that a signal assignment written in a procedure that is not contained within a process can only assign to a signal parameter of the procedure. The rationale is that assignment to a signal implies a driver for the signal. For signal parameters, the driver used is the driver for the actual signal provided by the process that calls the procedure. For other signals, a driver for the target signal would be implied for every process that calls the procedure. Identifying all of the callers in a large model would be very difficult. Moreover, if the procedure body is written separately from the calling processes, determining what drivers are created for a given process would be difficult. Thus, the restriction makes VHDL designs easier to analyze and understand. Force and release assignments, on the other hand, do not imply drivers. Rather, they would typically occur in testbench code, often referring to the target signals with external names. For these reasons, VHDL-2008 allows force and release assignments in procedures outside of processes to signals other than signal parameters.

One final aspect to discuss is the effect of multiple concurrent force and release assignments. Since they are sequential assignments written in processes, it is possible that multiple forces and releases could occur for a given signal during a single simulation cycle. The VHDL-2008 rules specify that if a force and release both occur, the effect is as though the release is immediately overridden by the force, and so the signal remains forced, but with the new force value. The effect of multiple forces is not defined. We should write our testbench models to avoid that occurring. The effect of multiple releases, however, is the same as a single release, and a release assignment on a signal that is not forced has no effect.

Complex designs often call upon design units from several libraries and make use of several packages. As a consequence, each design unit in the design is preceded by a long list of library and use clauses, many of which are common to all of the design units. VHDL-2008 provides a new form of design unit, a context declaration, in which we can gather a collection of library and use clauses. We can refer to a context declaration before a design unit, rather than having to repeat the collection of library and use clauses. The form of a context declaration is

context identifier is
   ... -- library clauses, use clauses and context references
end context identifier;

Within a context declaration, we write library and use clauses in the same form as in a context clause preceding a design unit. We refer to a declared context with a context reference of the form

context context_name;

or, if we wish to refer to several context declarations:

context context_name, context_name, . . . ;

We can write a context reference in the context clause preceding a design unit, or nested within another context declaration. In each case, the context reference is equivalent to replacement by the list of library clauses and use clauses contained within the named context declaration.

context widget_context is
   library IEEE;
   use IEEE. std_logic_ll64.all, IEEE. numeric_std.all;
   use widget_lib.widget_defs.all;
   use widget_lib.widget_comps.all;
end context widget_context;

This context declaration is analyzed into the widget_lib library. Given that a design needs to include a library clause for widget_lib in order to refer to the context declaration, there is no need to include that library clause in the context declaration itself. A design unit could reference the context declaration as follows:

library widget_lib;
context widget_lib.widget_context;
entity sample is
  ...
end entity sample;

Now suppose the Dongle project within Widgets, Inc., uses additional components provided by a third party, Gizmos Corp., defined by a package gizmo_pkg in library gizmo_lP_lib. The project also maintains a library dongle_lib for verified design units to be used in the project design flow, and a package dongle_comps with component declarations for the design units. The project’s EDA support person can provide a context declaration for these libraries and packages, as well as referring to the organization’s context declaration:

context dongle_context is
  library widget_lib;
  context widget_lib.widget_context;
  library gizmo_IP_lib;
  use gizmo_IP_lib.gizmo_pkg;
  use dongle_lib,dongle_comps. all;
end context dongle_context;

The EDA support person analyzes this context declaration into the dongle_lib library. A designer can then refer to the context in a design unit as follows:

library dongle_lib;
context dongle_lib.dongle_context;
entity frobber is
  . . .
end entity frobber;

The reference to dongle_context expands to include the reference to the organization’s context and the library and use clauses for the third-party IP and the project repository. The reference to the organization’s context in turn expands to include the library and use clauses for the standard packages and the organization’s packages. Thus, the context clause written is equivalent to the following expanded context clause:

library dongle_lib;
library widget_lib;
library IEEE;
use IEEE.std_logic_1164 .all , IEEE.numeric_std.all;
use widget_lib.widget_defs.all;
use widget_lib.widget_comps.all;
library gizmo_IP_lib;
use gizmo_IP_lib.gizmo_pkg;
use dongle_lib.dongle_comps.all;
entity frobber is
 . . .
end entity frobber;

VHDL uses library logical names to refer to physical design libraries. The mapping from a logical name to a physical library is implementation defined, and may vary between analysis of different design units. In order to avoid confusion when using context declarations, VHDL-2008 requires that a library logical name map to the same physical library during analysis of a context declaration and analysis of a reference to that context declaration. For example, if the logical name gizmo_IP_lib in Example 2.6 refers to /home/dongle/gizmo/gizmo_IP_lib when dongle_context is analyzed, the logical name must refer to the same physical library when entity frobber is analyzed.

As further reinforcement of this principle, we can’t include a context clause before a context declaration, as we can for other design units. Thus, the following would be illegal:

library fizz_lib;  -- Illegal: precedes context declaration
context frazzle_ctx is
   use fizz_lib.fizz_pkg.all;
end context frazzle_ctx;

Instead, we should write the library clause inside the context declaration, so that it is included for any design unit that references the context declaration. Another related rule is that we cannot include a library clause referring to the working library, WORK, within a context declaration. Nor can we refer to the library name WORK in a use clause. The reason is that WORK is not defined for a context declaration, since context declarations don’t have preceding context clauses.

Finally, VHDL-2008 defines two standard context declarations within the standard library IEEE:

context IEEE_BIT_CONTEXT is
   library IEEE;
   use IEEE.NUMERIC_BIT.all;
end context IEEE_BIT_CONTEXT;

context IEEE_STD_CONTEXT is
   library IEEE;
   use IEEE.STD_LOGIC_1164.all;
   use IEEE.NUMERIC-STD.all;
end context IEEE_STD_CONTEXT;

A design based on bit values might refer to the first of these context declarations, either in the context clause of a design unit or nested within a project context declaration. Similarly, a design based on std_logic values might refer to the second of these context declarations.

PSL is the IEEE Standard Property Specification Language (IEEE Std 1850). It allows specification of temporal properties of a model that can be verified either statically (using a formal proof tool) or dynamically (using simulation checkers). VHDL-2008 allows PSL code to be embedded as part of a VHDL model. This makes design for verification a much more natural activity, and simplifies development and maintenance of models. Since PSL is itself a significant language, we won’t describe all of its features in detail in this book. Instead, we will just describe the way in which PSL can be embedded in VHDL. For a full description of PSL and its use in verifying designs, the interested reader is referred to other published books on the subject.^[1]

In VHDL-2008 we can include PSL property, sequence, and default clock declarations in the declarative part of an entity, architecture, block, generate statement, or package declaration. We can then use the declared properties and sequences in PSL directives written in the statement parts of entities, architectures, blocks and generate statements.

Any properties that we write in PSL declarations and directives must conform to PSL’s simple subset rules. In practice, this means that we can only write properties in which time moves forward from left to right through the property. Two examples from the PSL standard illustrate this. First, the following property is in the simple subset:

always (a -> next[3] b)

This property states that if a is true, then three cycles later, b is true; that is, time moves forward three cycles as we scan the property left to right. In contrast, the following property is not in the simple subset:

always ((a & next[3] b) -> c)

This property states that if a is true and b is true three cycles later, then c must have been true at the time a was true. The problem with this property is that time goes backward from b being true to c being true. A tool to check such a property is much more complex than one to check properties in the simple subset.

PSL directives require specification of a clock that determines when temporal expressions are evaluated. We can include a clock expression in a directive. However, since the same clock usually applies to all directives in a design, it is simpler to include a default clock declaration. If we write a default clock declaration in a region of a design, it applies to any PSL directives written in that region. We can include at most one default clock declaration in any given region.

There is one case where introduction of PSL embedded within VHDL leads to a possible ambiguity. Both PSL and VHDL include assert statements, but their meanings differ. If we write a statement of the form

assert not (a and b) report "a and b are both true";

it could be interpreted as a regular VHDL concurrent assertion statement that is to be checked whenever either of a or b changes value. Alternatively, in VHDL-2008, it could be interpreted as a PSL assert directive that requires the property not (a and b) to hold at time 0. In the interest of backward compatibility, VHDL-2008 interprets such ambiguous statements as regular VHDL concurrent assertion statements. If we really want to write a PSL assert directive of this form, we could modify the property so that it is unambiguously a PSL property, for example:

assert next[O] not (a and b) report "a and b are both true";

library IEEE; context IEEE.IEEE_STD_CONTEXT;
entity slave is
   port ( clk, reset : in  std_logic;
                req        : in  std_logic;
                ack        : out std_logic;
                ... );
end entity slave;

architecture pipelined of slave is

   signal req_cnt, ack_cnt : unsigned(3 downto 0) ;

   default clock is rising_edge(clk);

   property all_requests_acked is
     forall C in {O to 15}:
       always {req and req_cnt = C} | =>
                     {[*O to 99]; ack and ack_cnt = C};

begin

   req_ack_counter : process (clk) is
   begin
      if rising_edge(clk) then
        if reset = '1' then
            req_cnt <=  "0000"; ack_cnt <= "0000";
        else
            if req = '1' then req_cnt <= req_cnt + 1; end if;
            if ack = '1' then ack_cnt <= ack_cnt + 1; end if;
        end if;
     end if;
  end process req_ack_counter;
  . . .
  assert all_requests_acked;

end architecture pipelined;

all_requests_acked that expresses the verification condition for the design. We also include a default clock declaration for the architecture. It applies to the assert directive that we write in the statement part of the architecture, asserting that the verification condition holds.

In PSL, verification code can be written in verification units (vunit, vprop and vmode units) that are bound to instances of VHDL entities and architectures. VHDL-2008 considers such verification units as primary design units. Thus, they can be declared in VHDL design files and analyzed into VHDL design libraries.

A verification unit can include binding information that identifies a component instance to which directives apply. Alternatively, in VHDL-2008, we can bind a verification unit as part of the configuration of a design. One place to do that is in a configuration declaration. If we want to bind one or more verification units to the top-level entity in a configuration declaration, we include binding information as follows:

configuration config_name of entity_name is
    . . .   -- use clauses, attribute specifications,
            -- group declarations
    use vunit verification_unit_name, . . . ;
    for architecture_name
      . . .
    end for;
end configuration config_name;

Whenever the configuration declaration is instantiated, either at the top-level of a design hierarchy or as a component instance within a larger design, the named verification units are bound to the instance of the named entity and architecture. That means the names used in the verification units are interpreted in the context of the entity instance.

We can also bind verification units to component instances that are configured by a component configuration nested within a configuration declaration. The augmented form of component configuration, assuming the components are bound to an entity and architecture, and the architecture is further configured, is:

for instance_name, . . . : component_name
   use entity entity_name(architecture_name);
   use vunit verification_unit_name, . . .;
   for architecture_name
      . . .
   end for;
end for;

In this case, the named verification units are bound to the instances specified in the component configuration.

The third place in which we can bind verification units in a VHDL design is in a configuration specification in the architecture or block where components are instantiated. The augmented form, again assuming components are bound to an entity and architecture, is:

for instance_name, . . . : component_name
   use entity entity_name(architecture_name);
   use vunit verification_unit_name, . . .;
end for;

This is similar to the form in a component configuration, but without the nested configuration for the architecture. Indeed, in order to make the syntax of a configuration specification more consistent with that of a component configuration, VHDL-2008 allows the reserved words end for to be used in a configuration specification even if there is no verification unit binding. On the other hand, if verification unit bindings are included, the end for reserved words are required.

Since a verification unit may include binding information as part of its declaration, there is potential for that information to conflict with binding information we write in a configuration. VHDL-2008 prevents such conflict by making it illegal to bind a verification unit in a configuration if the declaration of the unit already includes binding information. Hence, we would normally only write verification bindings in configurations for general-purpose verification units, and not for those written with particular instances in mind. In any case, it would be an error if we wrote a verification unit binding for a component instance that had no bound entity and architecture.

In addition to binding verification units directly in their declaration or indirectly in configurations, VHDL-2008 allows a tool to bind additional verification units through implementation-defined means. That might include command-line options, script commands, or selection using a graphical user interface.

vunit complementary_outputs {
   assert always Q = not Q_n;
}

entity D_FF is
  port ( clk, reset, D : in bit;
         Q, Q_n            : out bit );
end entity D_FF;

architecture gate_level of D_FF is
  component and2 is ...
  . . .
begin
  G1 : and2  . . .
  . . .
end architecture gate_level;

configuration fast_sim of D_FF is
   use vunit complementary_outputs;
   for gate_level
      for all : and2
         . . .
      end for;
      . . .
   end for;
end configuration fast_sim;

entity system is
  . . .
end entity system;

architecture RTL of system is
  component shift_reg is
     . . .
  end component shift_reg;
  . . .
begin
  serializer : shift_reg . . . ;
  . . .
end architecture RTL;

configuration verifying of system is
   for RTL
     for serializer : shift_reg
       use entity work.shift_reg(RTL);
       use vunit complementary_outputs;
     end for;
   end for;
end configuration verifying;

architecture RTL of system is
   component shift_reg is
      . . .
   end component shift_reg;
   for serializer : shift_reg
      use entity work.shift_reg(RTL);
      use vunit complementary_outputs;
   end for;
begin
   serializer : shift_reg . . . ;
   . . .
end architecture RTL;

There are some further points to make about PSL embedded in VHDL. First, since we can declare properties and sequences within VHDL, we can also specify attribute values for them. To that end, we can use the reserved words property and sequence in attribute specifications for declared properties and sequences, respectively. For example:

property SingleCycleRequest is
  always req -> next not req;
sequence ReadCycle is
  { ba; {bb[*]} & {ar[->]; dr[->]}; not bb };

attribute enable_heuristics of
               SingleCycleRequest : propery is true;
attribute enable_heuristics of Readcycle : sequence is true;

Second, PSL has a rich set of reserved words, some of which may conflict with VHDL identifiers. In VHDL-2008, the following PSL keywords are VHDL reserved words, and cannot be used as identifiers:

assert
assume
assume_guarantee
cover
default
fairness
property
restrict
restrict_guarantee
sequence
strong
vmode
vprop
vunit

Other PSL reserved words are only recognized as such within VHDL code when they occur in PSL declarations and directives. They can be used as VHDL identifiers, but such identifiers are hidden within PSL declarations and directives. For example, we can legally write the following declaration:

function rose ( x : boolean ) return boolean is . . .;

But if we then declare a sequence:

sequence cover_fifo_empty is
  {reset_n && rose(cnt = 0)};

The reference to rose in the sequence declaration is to the PSL built-in function, not to the declaration written in VHDL.

Finally, PSL includes features for declaring and instantiating macros, and allows for preprocessor directives. These features can only be used in PSL verification units, not in other VHDL design units.

As designs become more complex, designers are increasingly using intellectual property (IP) provided by IP vendors. IP providers invest considerable effort in developing their products, and may be loath to release them without protecting their investment. From the IP provider’s point of view, there are two potential places where their IP may be compromised. First, the IP provider must transmit the IP to a customer. During that process, a malicious third party could eavesdrop on the transmission and intercept the IP. Second, the customer must receive, store, and use the IP. During that process, an unscrupulous customer could reuse the IP without compensating the provider. Hence, the customer is technically treated as a malicious third party, though it would not be politic to express the relationship in those terms! The real recipient of the IP is the customer’s tool, which must use the IP only in ways approved by the IP provider and must avoid disclosing the IP to the customer.

One way of protecting IP is for the provider to encrypt it in a form that can be decrypted and used by a customer’s tools, but that cannot be read by the customer. VHDL-2008 provides a flexible set of features to support such protection. Before we describe them in detail, we will first review some of the basic principles and protocols for encryption so that we can understand how to use the language features.

Information to be communicated between two parties can be protected by transforming it with a cipher. A cipher is a function that takes plain text and a string of bits called a key as input and produces cipher text as output. This process is called encryption. The reverse process, decryption, takes the cipher text and a key as input and reproduces the original plain text. The quality of a cipher is determined by the difficulty of determining the plain text from the cipher text without the key. A good cipher will yield significantly different cipher text for minor changes to the key used for encryption.

There are two forms of cipher in widespread use. A symmetric cipher uses the same key for both encryption and decryption. The key is called a secret key, since it must be kept secret between the communicating parties. Should the secret be revealed to a third party, they could decrypt any intercepted encrypted information. Examples of symmetric ciphers are the Data Encryption Standard (DES), and the Advanced Encryption Standard (AES).

An asymmetric cipher uses a pair of related keys, one for encryption and the other for decryption. Key pairs are generated in such a way that it is infeasible to determine either key from the other. Information encrypted with one key of a pair can only be decrypted with the other key of the pair. Examples of asymmetric ciphers are RSA and ElGamal. Asymmetric ciphers are used in protocols where each communicating party generates a key pair. They keep one key of the pair, the private key, secret. They publish the other key, the public key, through some means of dissemination that associates the public key with the communicating party’s identity. For example, they might publish it on their web site. A sender of information can use an asymmetric cipher to protect information destined for a recipient. The sender encrypts the information using the recipient’s public key. Only the recipient can then decrypt the information, since only they have the corresponding private key.

While asymmetric ciphers can yield more secure communication, they involve significantly greater computation than symmetric ciphers. For that reason, most applications involving asymmetric ciphers use a two-stage encryption process called a digital envelope. First a session key is randomly generated, for use in one communication session only. Next, that session key is used with a symmetric cipher to encrypt the information. In order to communicate the session key to the recipient so that they can decrypt the information, the session key is encrypted using an asymmetric cipher with the recipient’s public key, and sent to the recipient. They are the only party able to decrypt the session key, since only they have the right private key. They can then proceed to decrypt the communicated information using the symmetric cipher with the decrypted session key. The advantage of this approach is that only a relatively small amount of information (the session key) need be processed using the computationally intensive asymmetric cipher. The bulk of the information is processed using the lighter-weight symmetric cipher.

One problem that arises in protected communication is the need to verify that received information did in fact originate with the purported sender, and that it was not changed in transit (either by corruption or maliciously) by a third party. This problem is addressed by having the sender transmit a digital signature for the information. The sender uses a hash function to compute a digest of the information. A hash function takes a (potentially large) string of bit as input and produces a small string of bits, the digest, that depends on all of the input bits. A good hash function has the property that two distinct input strings are highly unlikely to yield the same output string. Examples of hash functions include SHA1, MD2, MD5, and RIPEMD. Having computed the digest of the information, the sender encrypts it using an asymmetric cipher with their private key and transmits the result as the digital signature. A recipient decrypts the signature using the purported sender’s public key to retrieve the digest. The recipient also independently calculates the digest of the received information using the hash function. If the two digests are the same, the information has been received correctly, since only the real sender’s public key could decrypt the digest correctly, and only the real information would yield the same digest. If, on the other hand, the digests differ, then either the transmitted digest was encrypted with someone else’s key, or the transmitted message was changed. Either way, the transmission was compromised, and the recipient knows not to trust the received information.

If we are to apply cryptographic techniques to transmission of VHDL models, we need to consider the way in which the encrypted information is encoded. Plain-text VHDL models consist of printable ASCII or Latin-1 characters and are immune to the way ends of lines are encoded. Consequently, we can store and transmit plain-text models through a variety of media without being concerned about encodings. However, the process of encryption produces a string of bits, which cannot be guaranteed to be interpreted as printable characters. We cannot reliably transmit the encrypted model, since some media might transform sequences of bits interpreted as line ends, or might interpret sequences of bits as in-band control codes. To avoid these problems, we can encode the encrypted model using an encoding method that uses printable characters to represent the string of bits. A sender encrypts information and encodes it for transmission, and a recipient decodes the received information and decrypts the result. Examples of encoding methods include uuencode, base64, and quoted-printable, all of which are described by Internet message-transfer standards.

With this overview of cryptography in hand, we can now discuss the features provided in VHDL-2008 to support cryptographic protection of IP. The features use a standard set of tool directives (see Section 9.21). A tool directive is an annotation included in a VHDL design file that provides information to a tool processing the VHDL design. It does not logically form part of the design itself. For IP protection, VHDL-2008 defines protect directives that are used by an IP provider’s encryption tool to govern encryption of sections of a VHDL design and by a customer’s decyption tool to decrypt those sections. The decryption tool is typically a simulator, synthesis tool, or some other tool that deals with VHDL code. It uses the decrypted sections of the design, but does not store them in any form that could be revealed to the customer. Protect directives each takes one of three forms:

'protect keyword
'protect keyword = value
'protect keyword = ( keyword = value, . . . )

Like any tool directive, a protect directive starts with the “tick” symbol, and ends at the end of the line. The keyword or keywords in a protect directive identify the kind of information conveyed by the directive. Note that we write the keywords in boldface here to indicate that they have special meanings in protect directives. They are not reserved words outside of protect directives. The values are literal expressions of various types. If we have a number of consecutive protect directives, we can merge them into a single directive. Thus, we can write the sequence of directives

'protect keyword1 = value1
'protect keyword2 = value2
'protect keyword3

equivalently as

'protect keyword1 = value1, keyword2 = value2, keyword3

An IP provider starts the process by identifying one or more sections of a VHDL design file that they want to protect. They edit the design file to wrap each section in an encryption envelope, consisting of one or more protect directives at the start of the section, and a closing protect directive at the end of the section. The simplest form of encryption envelope is:

'protect begin
. . . -- protected source code in plain-text form
'protect end

This simply delimits the protected source code, and assumes an encryption tool will use default information about the ciphers, keys and encoding for encryption. More elaborate encryption envelopes precede the begin directive with protect directives specifying ciphers, keys, encoding and other optional information.

The IP provider then processes the design file with an encryption tool to produce a version of the design file with each encryption envelope replaced by a corresponding decryption envelope of the following form:

  'protect begin_protected
protect directives and encoded encrypted information
'protect end-protected

We will use a series of examples to show how the various directives are used to form encryption and decryption envelopes for various use cases. In each case we will assume that the decryption tool has access to the required keys, and that the encryption tool knows about those keys. We will return to the topic of key exchange in Section 2.1.

entity accelerator is
   port ( ... );
end entity accelerator;

architecture RTL of accelerator is
'protect data_keyowner = "ACME IP User"
'protect data_keyname  = "ACME Sim Key"
'protect data_method   = "aesl92-cbc"
'protect encoding      = (enctype = "base64")
'protect begin
   signal . . .
begin
   process . . .
   . . .
'protect end
end architecture RTL;

The IP provider leaves the information about the entity’s interface and the name of the architecture unprotected so that the customer can instantiate the design. The entire inner workings of the architecture, however, are not to be revealed to the customer. The data-keyowner and data-keyname directives specify identifiers that the encryption and decryption tools can use to retrieve the key. The data-method directive specifies the cipher to use for encryption and decryption, and the encoding directive specifies the method to use to encode the cipher text produced by the encryption tool.

The IP provider processes the original source code file with an encryption tool, which produces a modified file with the encryption envelope replaced by a decryption envelope:

entity accelerator is
  port ( . . . );
end entity accelerator;

architecture RTL of accelerator is
'protect begin_protected
'protect encrypt_agent      = "Encryptomatic"
'protect encrypt_agent_info = "2.3.4a"
'protect data_keyowner = "ACME IP User"
'protect data_keyname  = "ACME Sim Key"
'protect data_method   = "aesl92-cbc"
'protect encoding=(enctype="base64", line_length=40,   bytes=4006)
'protect data_block
emphasis>encoded cipher_text
. . .
'protect end_protected
end architecture RTL;

The encrypt-agent and encrypt-agent-info directives provide information about the encryption tool. This can help in tracking down any problems that might arise. The directives specifying the key, cipher, and encoding method are replicated in the decryption envelope. In the case of the encoding directive, further information about the maximum line length for the encoded cipher text and the number of bytes of cipher text is also provided. The encoded cipher text then starts immediately after the data_block directive. The end_protected directive marks the end of the decryption envelope.

entity accelerator is
   port ( ... );
end entity accelerator;

architecture RTL of accelerator is
'protect key_keyowner = "ACME IP User"
'protect key_keyname  = "ACME Sim Key"
'protect key_method   = "rsa"
'protect key_block
'protect data_method  = "aesl92-cbc"
'protect encoding         = (enctype = "base64")
'protect begin
   signal . . .
begin
   process. . .
   . . .
'protect end
end architecture RTL;

The key-keyowner and key-keyname directives specify identifiers that the encryption tool can use to retrieve the customer’s public key. The key-method directive specifies the cipher to use to encrypt the session key. The key-block directive marks the end of the key information. Its presence in the encryption envelope specifies use of a digital envelope, since the preceding key directives can be omitted, implying default values. The data-method directive specifies the cipher to use for encryption and decryption with the session key. The encoding directive specifies the method to use to encode both the encrypted session key and the encrypted section of the model.

The IP provider processes this source code file with an encryption tool, which generates a session key and produces a modified file with the encryption envelope replaced by a decryption envelope specifying a digital envelope:

entity accelerator is
   port ( . . . );
end entity accelerator;

architecture RTL of accelerator is
'protect begin_protected
'protect encrypt_agent    = "Encryptomatic"
'protect encrypt_agent_info = "2.3.4a"
'protect key_keyowner = "ACME IP User"
'protect key_keyname  = "ACME Sim Key"
'protect key_method   = "rsa"
'protect encoding=(enctype="base64", line_length=40, bytes=256)
'protect key_block

encoded cipher-text for session key

'protect data_method = "aesl92-cbc"
'protect encoding=(enctype="base64", line_length=40, bytes=4006)
'protect data_block

encoded cipher-text for model code

 ...
'protect end_protected
end architecture RTL;

The directives specifying the key and cipher for encrypting the session key are replicated in the decryption envelope. The encoding directive is also replicated to specify the encoding for the encrypted session key, augmented with information about the maximum line length for the encoded cipher text and the number of bytes in the encrypted session key. The encoded cipher text for the session key then starts immediately after the key-block directive. Next, the data-method directive specifying the cipher for the model code is replicated in the decryption envelope. The encoding directive is also replicated here, augmented with information about the maximum line length and the number of bytes. The encoded cipher text for the model code starts immediately after the data-block directive. The end-protected directive marks the end of the decryption envelope.

entity accelerator is
  port ( ... );
end entity accelerator;

architecture RTL of accelerator is
'protect key_keyowner = "ACME IP User1"
'protect key_keyname  = "ACME Sim Key"
'protect key_method   = " rsa"
'protect key_block
'protect key_keyowner = "ACME IP User2"
'protect key_keyname  = "ACME Synth Key"
'protect key_method   = "elgamal"
'protect key_block
'protect key_keyowner = "ACME IP User3"
'protect key_keyname  = "ACME P&R Key"
'protect key_method   = "aesl92-cbc"
'protectkey_block
'protect data_method  = "aesl92-cbc"
'protect encoding     = (enctype = "base64")
'protect begin
   signal . . .
begin
   process . . .
   . . .
'protect end
end architecture RTL;

Each group of key directives specifies information for encryption of a session key for decryption by a given decryption tool. The first two groups specify encryption using asymmetric ciphers, as is normally done in digital envelopes. However, we can also use a symmetric cipher to encrypt the session key, as specified in the third group of key directives.

As in the earlier examples, the IP provider processes this source code file with an encryption tool, which generates a session key and produces a modified file with the encryption envelope replaced by a decryption envelope specifying a digital envelope:

entity accelerator is
   port ( ... );
end entity accelerator;

architecture RTL of accelerator is
'protect begin_protected
'protect encrypt_agent      = "Encryptomatic"
'protect encrypt_agent_info = "2.3.4a"
'protect key_keyowner = "ACME IP Userl"
'protect key_keyname  = "ACME Sim Key"
'protect key_method   = "rsa"
'protect encoding=(enctype="base64", line_length=40, bytes=256)
'protect key_block

encoded cipher-text for session key

'protect key_keyowner = "ACME IP User2"
'protect key_keyname  = "ACME Synth Key"
'protect key_method   = "elgamal"
'protect encoding=(enctype="base64", line_length=40, bytes=256)
'protect key_block

encoded cipher-text for session key

'protect key_keyowner = "ACME IP User3"
'protect key_keyname  = "ACME P&R Key"
'protect key_method   = "aesl92-cbc"
'protect encoding=(enctype="base64", line_length=40, bytes=256)
'protect key_block

encoded cipher-text for session key

'protect data_method = "aes192-cbc"
'protect encoding=(enctype="base64", line_length=40, bytes=4006)
'protect data_block

encoded cipher-text for model code ...

'protect end_protected
end architecture RTL;

In this case, the decryption envelope includes a group of key directives and a key block corresponding to each group of key directives in the encryption envelope. Each of the targeted decryption tools, when it processes the decryption envelope, checks whether it has access to the key specified by each group of key directives. If it has one of the keys, it can use that key to decrypt the session key, and thus decrypt the model code.

entity accelerator is
  port ( ... );
end entity accelerator;

architecture RTL of accelerator is
'protect key_keyowner = "ACME IP User"
'protect key_keyname  = "ACME Sim Key"
'protect key_method   = "rsa"
'protect key_block
'protect data_method  = "aesl92-cbc"
'protect digest_keyowner  = "GoodGuys IP Author"
'protect digest_keyname    = "GoodGuys   Signing Key"
'protect digest_key_method = "rsa"
'protect digest_method     = "shal"
'protect digest_block
'protect encoding = (enctype = "base64")
'protect begin
   signal  . . .
begin
   process  . . .
   ...
'protect end
end architecture RTL;

The digest directives in the encryption envelope specify that a digital signature should be generated for the model code contained in the envelope. The digest_method directive specifies the hash function for computing the digest, and the digest_keyowner, digest_keyname and digest_key_method directives specify the cipher and key to use to encrypt the digest. The digest_key_method directive must specify an asymmetric cipher, since digital signatures are predicated on the use of such ciphers.

The IP provider processes this source code file with an encryption tool, which computes and encrypts the digest to form the digital signature. It uses the private key of the key pair specified by the digest key directives. It includes the digest in the decryption envelope corresponding to the encryption envelope:

entity accelerator is
   port ( . . . );
end entity accelerator;

architecture RTL of accelerator is
'protect begin_protected
'protect encrypt_agent      = "Encryptomatic"
'protect encrypt_agent_info = "2.3.4a"
'protect key_keyowner = "ACME IP User"
'protect key_keyname  = "ACME Sim Key"
'protect key_method   = "rsa"
'protect encoding=(enctype="base64", line_length=40, bytes=256)
'protect key_block

encoded cipher-text for session key

'protect data_method    =   "aesl92-cbc"
'protect encoding=(enctype="base64", line_length=40, bytes=4006)
'protect data_block

encoded cipher_text for model code

...
'protect digest_keyowner   = "GoodGuys IP Author"
'protect digest_keyname    = "GoodGuys Signing Key"
'protect digest_key_method = "rsa"
'protect digest_method     = "sha1"
'protect digest_block
'protect encoding=(enctype="base64", line_length=40, bytes=16)
'protect digest_block

encoded cipher-text for digest

 . . .
'protect end_protected
end architecture RTL;

Our trusted IP provider places this model on the file server for us to download. Now suppose the unscrupulous third-party IP provider performs their network hack and substitutes a buggy model. In their first attempt, they substitute the buggy code, encrypted with a session key that they generate, and encrypt the session key with our public key. Our decryption tool successfully decrypts the session key and uses it to decrypt the model. However, since we want to verify that we have the right model, the decryption tool computes the digest of the decrypted model using the hash function specified in the digest-method directive. The tool also uses the public key of the key pair identified in the digest key directives to decrypt the transmitted digest. Since the model code is different from the original code provided by the trusted IP provider, the two digests are not the same. Our decryption tool alerts us to this fact, and we contact our trusted IP provider to attempt to remedy the problem.

Now suppose the unscrupulous third-party IP provider realizes their ruse was unsuccessful, and tries a different tack. As well as substituting the buggy model, suitably encrypted, they also generate a digital signature for the buggy model and substitute it for the real digital signature. They use their own private key to encrypt the digest, and include digest key directives that identify their key pair. Again, our decryption tool successfully decrypts the model and calculates the digest. The tool also attempts to decrypt the transmitted digest in order to compare with the computed digest. At this point, there are two possible outcomes. First, if the tool does not have access to the unscrupulous provider’s public key, it will be unable to proceed and will warn us that it could not verify the digital signature. Alternatively, if the tool does have access to the unscrupulous provider’s public key, it will use it to decrypt the transmitted digest and compare it with the computed digest. In this case, the digests will match. It will be up to us to check that signature verification was performed with the key we expected. This illustrates that we need to be vigilant when checking digital signatures, so that we are not duped by a simple key substitution. We will discuss this more in Section 2.1, where we address the issue of key exchange.

entity accelerator is
   port ( . . . );
end entity accelerator;

architecture RTL of accelerator is
'protect data_keyowner = "ACME IP User"
'protect data_keyname  = "ACME Sim Key"
'protect data_method   = "aesl92-cbc"
'protect encoding      = (enctype = "base64")
'protect viewport=(object="accelerator:RTL.state", access="RW");
'protect begin
   signal state : std_logic_vector(3 downto 0);
   . . .
begin
   process . . .
   . . .
'protect end
end architecture RTL;

While most of the inner workings of the architecture are not revealed to the customer, the viewport directive provides the pathname of the object representing the internal state signal and grants read/write access. The IP provider processes the source code file with an encryption tool, which includes the viewport directive in the decryption envelope:

entity accelerator is
   port ( ... );
end entity accelerator;

architecture RTL of accelerator is
'protect begin_protected
'protect encrypt_agent      = "Encryptomatic"
'protect encrypt_agent_info = "2.3.4a"
'protect viewport=(object="accelerator:RTL.state", access="RW");
'protect data_keyowner = "ACME IP User"
'protect data_keyname  = "ACME Sim Key"
'protect data_method   = "aesl92-cbc"
'protect encoding=(enctype="base64", line_1ength=40, bytes=4006)
'protect data_block

encoded cipher-text

...
'protect end_protected
end architecture RTL;

The customer can instantiate the IP in a design and use an external name to refer to the state signal:

architecture monitoring of tb is
  . . .
begin
  . . . -- clock and reset generation
  accelerator_duv : entity work.accelerator(rtl)
    port map  ( ... );
  monitor : process (clk) is
    use std.textio.all;
    file state_file : text open write_mode is state_file_name;
    alias accelerator_state is
          <<signal accelerator_duv.state:
                          std_logic_vector(3 downto 0)>>;
  begin
    if falling_edge(clk) then
       write(L, accelerator_state); writeline(state_file, L);
    end if;
  end process monitor;

end architecture monitoring;

While the viewport directive provides access to the internal signal, it does not provide complete information. The IP provider would also need to provide documentation describing the type of the signal and other relevant information.

Now that we have seen how protection envelopes are formed in various scenarios, we will describe the details of VHDL-2008’s IP protection mechanism. As we have mentioned, it is based on a set of tool directives. The full list of directives is as follows:

‘protect begin

‘protect end

‘protect begin_protected

‘protect end_protected

‘protect author = “author name”

‘protect author_info = “author info”

‘’protect encrypt-agent = “encrypt agent name”

‘protect encrypt-agent-info = “encrypt agent info”

‘protect key-keyowner = “key owner name”

protect key-keyname = “key name”

protect key-method = “cipher name”

‘protect key-block

‘protect data-keyowner = “key owner name”

‘protect data-keyname = “key name”

‘protect data-method = “cipher name”

‘protect data-block

‘protect digest_keyowner = “key owner name”

‘protect digest-keyname = “key name”

‘protect digest-key-method = “cipher name”

protect digest-method = “hash function name”

‘protect digest-block

‘protect encoding = ( enctype = “encoding name”, line-length = integer, bytes = integer)

‘protect viewport = ( object = “object pathname”, access = “access type” )

         "my_entity.cycle_monitor.cycle_count"

If the object is declared within an architecture, the design unit name is the combination of the entity name and the architecture name, separated by a colon, for example,

         "my_entity:RTL.current_state"

If the object is declared within a package body, the design unit name consists of the package name, followed by ":body", for example,

         "IP_pkg:body.trace_file"

The access type string must be one of "R", "W", or "RW" (or the lowercase equivalents), indicating read access, write access, or read/write access, respectively.

‘protect decrypt-license =( library = “library name”,entry = “acquisition routine name”, feature = “feature name”,exit = “release routine name”, match = integer)

‘protect runtime-license =( library = “library name”,entry = “acquisition routine name”, feature = “feature name”,exit = “release routine name”, match = integer)

‘protect comment = “comment string”

Several directives use strings to specify ciphers, encodings, and hash functions. VHDL-2008 defines particular string values for these directives. If a tool supports the given cipher, encoding, or hash function, it must use the defined string value to specify it. A tool may also support other methods, in which case it uses an implementation-defined string value. Table 2.1 shows the string values for specifying ciphers. Every tool must support at least the DES cipher. Table 2.2 shows the string values for specifying encodings. Every tool must support at least uuencode and base64. Table 2.3 shows the string values for specifying hash functions. Every tool must support at least SHAl and MD5.

We can now describe the rules for forming an encryption envelope in a model. The rules allow for considerable flexibility, but we must at least include the begin and end directives to mark out the source code to be encrypted.

We can precede the begin directive with a key-block directive if we want to specify use of digital envelopes. We can specify the cipher and key to use to encrypt the session key by including a key-method and a key-keyowner directive (and optionally a key-keyname directive). If we don’t specify the cipher and key, the encryption tool chooses a default cipher and key. The key-method, key-keyowner and key-keyname directives can appear in any order, but must immediately precede the key-block directive. We can include more than one group of key-related directives, as we described in Example 2.11.

We can also precede the begin directive with a data-method directive if we want to specify the cipher to use to encrypt the source code. If we are not using digital envelopes and we include a data-method directive, we must also include a data-keyowner directive and optionally a data-keyname directive to identify the key. If we are using digital envelopes, the encryption tool generates the session key, so we do not include directives to identify the key. If we omit the data-method directive, the encryption tool chooses a default cipher. All of the directives relating to encryption of the source code must appear together in an encryption envelope.

If we want to include a digital signature, we precede the begin directive with a digest-block directive. We can specify the cipher and key to use to encrypt the digest by including a digest-key-method and a digest-keyowner directive (and optionally a digest-keyname directive). If we don’t specify the cipher and key, the encryption tool chooses a default cipher and key. Similarly, we can specify the hash function to use by including a digest-method directive. If we don’t specify a hash function, the encryption tool chooses a default hash function. The digest-key-method, digest-keyowner, digest-keyname, and digest-method directives can appear in any order, but must immediately precede the digest-block directive.

Beyond these specifications, we can include directives to identify the IP author, describe licenses and viewports, and specify the encoding to use. If we don’t specify the encoding, the encryption tool chooses a default encoding. We can also include comment directives anywhere within the encryption envelope, including in the source code between the begin and end directives.

The rules that an encryption tool must follow to form a decryption envelope are somewhat more prescriptive. Groups of directives must appear in a specified order, even if the corresponding directives in the encryption envelope appeared in a different order or distributed among other directives, though not all groups are required in every decryption envelope. The layout of a decryption envelope is:

'protect  begin_protected
author directives
license directives
encrypt agent directives
viewport directives
key block directives
data block directives
digest block directives
'protect end_protected

The author, license, and viewport directives are those that appear in the encryption envelope, if any. The encrypt-agent directive and optionally and encypt-agent-info directive are included by the encryption tool. If a digital envelope is used, there is a group of key block directives for each encryption of the session key. The directives occur in the following order, with only the key-keyname directive being optional:

key_keyowner directive
key_keyname directive
key_keymethod directive
encoding directive
key_block directive
encoded cipher text for session key

The data block directives occur in the following order, with the data-keyowner and (optional) data-keyname directives only appearing if a digital envelope is not being used:

data_keyowner directive
data_keyname directive
data_method directive
encoding directive
data_block directive
encoded cipher text for source code

If a digital signature is used, the digest block directives occur in the following order, with only the digest_keyname directive being optional:

digest_keyowner directive
digest_keyname directive
digest_key_method directive
digest_method directive
encoding directive
digest_block directive
encoded cipher text for digest

VHPI is an application-programming interface (API) to VHDL tools. Using VHPI, a program can access information about a VHDL model during analysis, elaboration, and execution of the model. VHPI allows development of add-in tools, such as linters, profilers, code coverage analyzers, timing and power analyzers, and external models, among others. Use of the VHPI to develop such tools is quite complex, and is beyond the scope of this book. Instead, we will describe the way in which we can invoke VHPI programs as part of a VHDL simulation.

VHPI programs are divided into two classes: foreign models and foreign applications. A foreign model corresponds to an architecture or a subprogram decorated with the "FOREIGN attribute. The VHPI program implements the behavior of the architecture or subprogram, respectively. A foreign application does not have a counterpart in the VHDL code. It is executed as part of simulation and performs application-specific processing. Both forms of VHPI program can use API calls to obtain information about the VHDL model, to react to changes in the simulation state, and to cause changes in the simulation state.

"VHPIDIRECT object_lib_path elab_function exec_function"

entity cpu32 is
  generic ( . . . );
  port ( ... );
end entity cpu_32;

architecture bus_functional of cpu32 is
  attribute FOREIGN of bus_functional : architecture is
     "VHPIDIRECT /usr/local/cpu32/cpu32.a " &
     "cpu32_bf_elab_f cpu32_bf_exec_f";
begin
end architecture bus_functional;

"VHPIDIRECT object_library_path exec_function"

package display_pkg is
   impure function create_digit (title : in string)
                                       return natural;
   attribute FOREIGN of create_digit : function is
     "VHPIDIRECT displaylib. a null" ;
   procedure update_digit (id : in natural;
                               val : in bit_vector(0 to 7));
   attribute FOREIGN of update_digit : procedure is
     "VHPIDIRECT displaylib. a null" ;
end package display_pkg ;

object_lib_name model_name vhpiArchF elab_function exec_function

"VHPI object_lib_name model_name"

cpu32lib cpu32-bf vhpiArchF cpu32_bf_elab_f cpu_bf_exec_f

architecture bus_functional of cpu32 is
  attribute FOREIGN of bus_functional : architecture is
    "VHPI cpu32lib cpu32-bf";
begin
end architecture bus_functional;

object_lib_name model_name vhpiProcF null exec_function

object_lib_name model_name vhpiFuncF null exec_function

"VHPI object_lib_name model_name"

displaylib create_digit vhpiFuncF null null
displaylib update_digit vhpiProcF null null

package display_pkg is
  impure function create_digit (title : in string)
                                   return natural;
  attribute FOREIGN of create_digit : function is
     "VHPI displaylib create_digit";
  procedure update_digit (id : in natural ;
                            val   : in  bit_vector(0 to 7)) ;
  attribute FOREIGN of update_digit : procedure is
     "VHPI displaylib update_digit";
end package display_pkg;

object_lib_name application_name vhpiAppF reg_function null

-- VHPI tabular registry for the PowerEst foreign application.
-- Map library name powerestlib to the pathname for the
-- powerest1ib.a file in your installation.

powerestlib powerestlib vhpiAppF powerest_reg_f null

object_lib_name null vhpiLibF reg-function null