In this section we look at a number of closely related topics. First, we discuss another kind of resolved signal called a guarded signal. We see how we can disconnect drivers from such signals. Next, we introduce the idea of blocks in a VHDL design. We show how blocks and guarded signals work together with guards and guard expressions to cause automatic disconnection of drivers. Finally, we discuss blocks as a mechanism for describing a hierarchical structure within an architecture. While these aspects of VHDL may be useful in some designs, they are not widely used. Hence, we have deferred consideration of the features to this chapter.

   signal_declaration  ⇐
       signal identifier  {, ...} : subtype_indication  [register | bus]
                                 [:= expression];

   signal interrupt_request : pulled_up bit bus;

   signal stored_state : resolve_state state_type register
            := init_state;

signal_assignment_statement  ⇐
     [label :] name <= [delay_mechanism] waveform;

waveform  ⇐
   (value_expression [after time_expression]
       |null [after time_expression]){, ...}

   architecture top_level of computer_system is
    function resolve_bits ( bits : bit_vector ) return bit is
      variable result : bit := '0';
    begin
      for index in bits'range loop
        result := result or bits(index);
        exit when result;
      end loop;
      return result;
    end function resolve_bits;
    signal write_en : resolve_bits bit bus;
    ...
   begin
    CPU : process is
      ...
    begin
      write_en <= '0' after Tpd;
      ...
      loop
        wait until clock;
        if hold_req then
          write_en <= null after Tpd;
          wait on clock until clock and not hold_req;
          write_en <= '0' after Tpd;
        end if;
        ...
      end loop;
    end process CPU;
    ...
   end architecture top_level;

   architecture rtl of processor is
    subtype word is bit_vector(0 to 31);
    type word_vector is array (natural range <>) of word;
    function resolve_unique ( drivers : word_vector ) return word is
    begin
      return drivers(drivers'left);
    end function resolve_unique;
    signal source1, source2 : resolve_unique word register;
    ...
    begin
    source1_reg : process (phase1, source1_reg_out_en, ...) is
      variable stored_value : word;
    begin
      ...
      if source1_reg_out_en and phase1 then
        source1 <= stored_value;
      else
        source1 <= null;
      end if;
    end process source1_reg;
    alu : perform_alu_op ( alu_opcode,
                           source1, source2, destination, ... );
    ...
    end architecture rtl;

    subtype word is bit_vector(0 to 31);
    type word_array is array (integer range <>) of word;
    function resolve_words ( words : word_array ) return word;
    signal s : resolve_words word bus;

    s(0 to 15) <= X"003F" after T_delay;
    s(16 to 31) <= null after T_delay;

   subtype byte is bit_vector(0 to 7);
   type byte_array is array (integer range <>) of byte;
   function resolve ( bytes : byte_array ) return byte;
   subtype resolved_byte is resolve byte;

   entity tri_state_reg is
     port ( d : in resolved_byte;
            q : out resolved_byte bus;
            clock, out_enable : in bit );
   end entity tri_state_reg;

   block_statement  ⇐
       block_label :
       block [(guard_expression )] [is]
       begin
           {concurrent_statement}
       end block  [block_label];

   concurrent_simple_signal_assignment  ⇐
      name <=  [guarded] [delay_mechanism]  waveform ;
   concurrent_conditional_signal_assignment  ⇐
      name <=  [guarded] [delay_mechanism]
              waveform when condition
               {else waveform when condition}
               [else waveform]
   concurrent_selected_signal_assignment  ⇐
      with expression select  [?]
          name <=  [guarded] [delay_mechanism]
                   {waveform when choices ,}
                  waveform when choices ;

   architecture dataflow of processor_node is

    signal address_bus : resolve_unique word bus;
    ...
    begin

      cache_to_address_buffer :
      block ( cache_miss and dirty ) is
    begin
      address_bus <= guarded
        tag_section0 & set_index & B"0000"
          when replace_section = '0' else
        tag_section1 & set_index & B"0000";
    end block cache_to_address_buffer;

    snoop_to_address_buffer :
    block ( snoop_hit and flag_update ) is
    begin
      address_bus <= guarded snoop_address(31 downto 4) & B"0000";
    end block snoop_to_address_buffer;
    ...
   end architecture dataflow;

   entity latch is
    generic ( width : positive );
    port ( enable : in bit;
           d : in bit_vector(0 to width - 1);
           q : out bit_vector(0 to width - 1) );
   end entity latch;
   --------------------------------------------------
   architecture behavioral of latch is
   begin
    transfer_control : block ( enable ) is
    begin
      q <= guarded d;
    end block transfer_control;
   end architecture behavioral;

   disconnection_specification  ⇐
      disconnect  (signal_name {, ...} |others|all): type_mark
         after time_expression ;

   signal memory_data_bus : resolved_word bus;
   disconnect memory_data_bus : resolved_word after 3 ns;

   mem_write_buffer : block (mem_sel and mem_write) is
   begin
      memory_data_bus <=
          guarded reject 2 ns inertial cache_data_bus after 4 ns;
   end block mem_write_buffer;

   signal source_bus_1, source_bus_2 : resolved_word bus;
   signal address_bus : resolved_word bus;

   disconnect all : resolved_word after 2 ns;

   disconnect address_bus : resolved_word after 3 ns;

   disconnect others : resolved_word after 2 ns;

Using Blocks for Structural Modularity

We now look at the use of blocks to partition the concurrent statements within an architecture body. We can think of a block as a way of drawing a line around a collection of concurrent statements and their associated declarations, so that they can be clearly seen as a distinct aspect of a design. The full syntax rule for a block statement is as follows:

   block_statement  ⇐
       block_label :
       block  [( guard_expression )] [is]
           [generic ( generic_interface_list ) ;
           [generic map ( generic_association_list ) ;]]
           [port ( port_interface_list ) ;
           [port map ( port_association_list ) ;]]
           {block_declarative_item}
     begin
           [concurrent_statement}
     end block [block_label];

The block label is required to identify the block statement. The guard expression, as we saw earlier, may be used to control guarded signal assignments. If we are only using a block as a means of partitioning a design, we do not need to include a guard expression. The generic and port clauses allow us to define an interface to the block. We return to this shortly.

The declarative part of a block statement allows us to declare items that are local to the block. We can include the same kinds of declarations here as we can in an architecture body, for example, constant, type, subtype, signal and subprogram declarations. Items declared in a block are only visible within that block and cannot be referred to before or after it. However, items declared in the enclosing architecture body remain visible (unless hidden by a local item declared within the block).

Example 23.5. Blocks for partitioning timing and functionality

To illustrate how blocks can be used for partitioning a design, we develop a model for a counter, including detailed pin-to-pin propagation delays and some error checking. We can specify the propagation delays as combinations of input delays before the function block and output delays after the function block, as shown in Figure 23.1. The function block implements the behavior of the counter with zero delay.

The entity declaration for this counter is

entity counter is
 generic ( tipd_reset,             -- input prop delay on reset
           tipd_clk,               -- input prop delay on clk
           topd_q : delay_length;  -- output prop delay on q
           tsetup_reset,           -- setup: reset before clk
           thold_reset :           -- hold time: reset after clk
             delay_length );
 port ( reset,                     -- synchronous reset input
        clk : in bit;              -- edge-triggered clock input
        q : out bit_vector );      -- counter output
end entity counter;

We can separate the delay, function and error-checking aspects of the model into separate blocks within the architecture body, as follows:

   architecture detailed_timing of counter is
    signal reset_ipd,                   -- data input port delayed
           clk_ipd : bit;               -- clock input port delayed
    signal q_zd : bit_vector(q'range);  -- q output with zero delay
   begin
    input_port_delay : block is
    begin
      reset_ipd <= reset after tipd_reset;
      clk_ipd <= clk after tipd_clk;
    end block input_port_delay;

    functionality : block is

      function increment ( bv : bit_vector ) return bit_vector is
        variable result : bit_vector(bv'range) := bv;
        variable carry : bit := '1';
      begin
        for index in result'reverse_range loop
          result(index) := bv(index) xor carry;
          carry :=  bv(index) and carry;
          exit when carry = '0';
        end loop;
        return result;
      end function increment;
      signal next_count : bit_vector(q'range);
    begin
      next_count <= increment(q_zd) when reset_ipd = '0' else
                    (others => '0'),
      q_zd <= next_count when clk_ipd = '1' and clk_ipd'event;
    end block functionality;
    output_port_delay : block is
    begin
      q <= q_zd after topd_q;
    end block output_port_delay;
    timing_checks : block is
    begin
      -- check setup time: reset before clk
      ...
      -- check hold time: reset after clk
      ...
    end block timing_checks;

   end architecture detailed_timing;

The first block, input_port_delay, derives delayed versions of the input ports. These are used in the second block, functionality, the zero-delay behavioral implementation of the counter. This block consists of two concurrent signal assignment statements that together implement a finite-state machine. One statement calculates the next count value using the increment function locally declared within the block, and the other implements an edge-triggered register. The signal next_count, also locally declared within the block, is used to connect the two statements. The output of the state machine is used in the third block, output_port_delay, to apply the delay between the function block and the output port. The final block outlined in the architecture body, timing_checks, contains processes that verify correct setup and hold times for the reset signal.

Figure 23.1. A propagation delay model for a counter.

Since a block contains a collection of concurrent statements, and a block statement is itself a concurrent statement, it is perfectly legal to nest blocks one inside another. The same visibility rules that we described for subprograms also apply for items declared in nested blocks. However, in practice, we would rarely write a model with nested blocks. If the design hierarchy is that complex, it is better to use separate entities and component instantiation statements to partition the design. The main reason VHDL allows complex nesting of blocks is that the block structure is used as the underlying mechanism for implementing other VHDL constructs, such as component instantiation (described in Chapter 13) and generate statements (described in Chapter 14). The language definition defines these constructs in terms of the substitution of blocks containing the contents of the architecture body being instantiated or the contents of the generate statement.

External Names and Blocks

As we mentioned in Section 18.1, a block statement forms a concurrent region in a design. When we write external names, we need to include the label of a block in the pathname for any item declared in the block or in an entity instantiated in the block.

Example 23.6. Referring to a block in an external pathname

Suppose the counter design of Example 23.5 in instantiated with a test bench architecture. We can use an external name in the test bench to refer to the next_count signal. The test bench outline is as follows:

   architecture verifying of test_bench is

    signal clk, reset : bit;
    signal duv_q : bit_vector(7 downto 0);

    alias duv_next_count is
      <<signal duv.functionality.next_count :
                 bit_vector(duv_q'range)>>;
    ...
   begin
    duv : entity work.counter(detailed_timing)
      generic map ( ... )
      port map ( clk => clk, reset => reset, q => duv_q );
    ...
   end architecture verifying;

The counter is instantiated using the label duv. In the external name, the relative pathname starts with duv, followed by the block label functionality and then the signal name next_count.

Generics and Ports in Blocks

Another aspect of block statements, also arising from their use as the underlying mechanism for component instantiation, is the possibility of including generic and port interface lists. These allow us to make explicit the interface between the block and its enclosing architecture body or enclosing block. The formal generics and ports can be used within the block in exactly the same way that those of an entity are used within a corresponding architecture body. The actual values for genericts are supplied by a generic map in the block header, and the actual signals associated with the formal ports are supplied by a port map. These are all shown in the syntax rule for block statements on page 744. Since this facility is rarely used in actual model writing, we do not dwell on it.

Configuring Designs with Blocks

In Chapter 13 we showed how to configure a design whose hierarchy was formed by instantiating components. We configure an architecture body containing nested block statements in a similar way. When we write configuration declarations for such architecture bodies, the configuration information must mirror the block structure of the architecture body. We introduce a further level of detail in the syntax rules for configuration declarations, showing how to configure architecture bodies containing blocks.

   configuration_declaration  ⇐
      configuration identifier of entity_name is
          block_configuration
      end  [configuration] [identifier];
   block_configuration  ⇐
      for (architecture_name | block_statement_label)
           {   block_configuration
               |   for component_specification
                       [ binding_indication ; ]
                       [ block_configuration  ]
                  end for ; }
      end for ;

The difference here is that we have added a block statement label as an alternative to an architecture name at the point where we specify the region containing concurrent statements. Furthermore, we have allowed a block configuration as an alternative to component configuration information within that region. If we put these together, we can see how to write the configuration information for an architecture body containing block statements. At the top level of the configuration declaration, we write a block configuration naming the architecture body, just as we have done in all of the previous examples. Within it, however, we include block configurations that name and configure each block.

Example 23.7. Configuration of a design partitioned with blocks

Suppose we need to write a model for an integrated circuit that takes account of propagation delays through input and output pads. The entity declaration and architecture body are shown below. The architecture body is divided into blocks for input delay, function and output delay. The operation of the circuit is described structurally, as an interconnection of cells within the function block.

   entity circuit is
    generic ( inpad_delay, outpad_delay : delay_length );
    port ( in1, in2, in3 : in bit;  out1, out2 : out bit );
   end entity circuit;
   --------------------------------------------------
   architecture with_pad_delays of circuit is
    component subcircuit is
      port ( a, b : in bit;  y1, y2 : out bit );
    end component subcircuit;
    signal delayed_in1, delayed_in2, delayed_in3 : bit;
    signal undelayed_out1, undelayed_out2 : bit;
   begin
    input_delays : block is
    begin
      delayed_in1 <= in1 after inpad_delay;
      delayed_in2 <= in2 after inpad_delay;
      delayed_in3 <= in3 after inpad_delay;
    end block input_delays;
    functionality : block is
      signal intermediate : bit;
    begin
      cell1 : component subcircuit
        port map ( delayed_in1, delayed_in2,
                   undelayed_out1, intermediate );
      cell2 : component subcircuit
        port map ( intermediate, delayed_in3,
                   undelayed_out2, open );
    end block functionality;
    output_delays : block is
    begin
      out1 <= undelayed_out1 after outpad_delay;
      out2 <= undelayed_out2 after outpad_delay;
    end block output_delays;
   end architecture with_pad_delays;

A configuration declaration for this design is

   configuration full of circuit is
    for with_pad_delays -- configure the architecture
      for functionality    -- configure the block
        for all : subcircuit
          use entity work.real_subcircuit(basic);
        end for;
      end for;
    end for;
   end configuration full;

The configuration binds the instances of the component subcircuit within the block functionality to an entity real_subcircuit with architecture basic. The block configuration starting with “for with_pad_delays” specifies the architecture of circuit that is being configured. Within it, the block configuration starting with “for functionality” specifies the configuration of the contents of the block labeled functionality. It, in turn, contains a component configuration for the two component instances. Note that there are no block configurations for the other two blocks in the design, since they do not contain any component instances. They only contain concurrent signal assignment statements, which represent leaf nodes of the design hierarchy.

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 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 website. 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 bits 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 to support cryptographic protection of IP. The features use a standard set of tool directives. 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. The syntax for a tool directive is

tool_directive ⇐ ‘identifier { graphic_character }

A tool directive starts with the “tick” symbol, and ends at the end of the line. The identifier specifies to the tool what form of processing to perform. The remaining text, up to the end of the line, provides any additional information needed.

For IP protection, VHDL defines protect directives, in which the identifier is protect. (Although the identifier is not a reserved word, we write it and other keywords in protect directives in boldface type to indicate that they have special meanings in the directives.) The protect directives are used by an IP provider’s encryption tool to govern encryption of sections of a VHDL design and by a customer’s decryption 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, ... )

The keyword or keywords in a protect directive identify the kind of information conveyed by the directive. 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 23.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   = "aes192-cbc"
   'protect encoding      = (enctype = "base64")
   'protect begin
    signal ...
   begin
    process ...
    ...
   'protect end
   end architecture RTL;

   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   = "aes192-cbc"
   'protect encoding=(enctype="base64", line_length=40, bytes=4006)
   'protect data_block
   encoded cipher-text
   ...
   'protect end_protected
   end architecture RTL;

   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  = "aes192-cbc"
   'protect encoding     = (enctype = "base64")
   'protect begin
    signal ...
   begin
    process ...
    ...
   'protect end
   end architecture RTL;

   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   = "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;

   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   = "aes192-cbc"
   'protect key_block
   'protect data_method  = "aes192-cbc"
   'protect encoding     = (enctype = "base64")
   'protect begin
    signal ...
   begin
    process ...
    ...
   'protect end
   end architecture RTL;

   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 User1"
   '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   = "aes192-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;

   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  = "aes192-cbc"
   '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")
   'protect begin
     signal ...
   begin
      process ...
      ...
    'protect end
   end architecture RTL;

   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   = "aes192-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;

   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   = "aes192-cbc"
   'protect encoding      = (enctype = "base64")
   'protect viewport=(object="accelerator:RTL.state", access="RW");
   'protect begin
     signal state : std_ulogic_vector(3 downto 0);
    ...
   begin
    process ...
    ...
   'protect end
   end architecture RTL;

   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   = "aes192-cbc"
   'protect encoding=(enctype="base64", line_length=40, bytes=4006)
   'protect data_block
   encoded cipher-text
   ...
   'protect end_protected
   end architecture RTL;

   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_ulogic_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;

Now that we have seen how protection envelopes are formed in various scenarios, we will describe the details of VHDL’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:

Note, incidentally, that we have split a number of the longer directives over multiple lines, for reasons of presentation here. In practice, each directive must appear entirely on one line in a VHDL model.

Several directives use strings to specify ciphers, encodings, and hash functions. VHDL 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 23.1 shows the string values for specifying ciphers. Every tool must support at least the DES cipher. Table 23.2 shows the string values for specifying encodings. Every tool must support at least uuencode and base64. Table 23.3 shows the string values for specifying hash functions. Every tool must support at least SHA1 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 23.10.

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 written in a language such as C or C++ 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, predefined in the package standard as follows:

   attribute foreign : string;

An architecture or subprogram decorated with this attribute is not elaborated or executed in the same way as a normal architecture or subprogram. Instead, the value of the attribute is used to identify the VHPI program that 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
   -- powerestlib.a file in your installation.
   powerestlib powerestlib vhpiAppF powerest_reg_f null

   object_lib_name null vhpiLibF reg_function null

VHDL provides a facility, postponed processes, that is useful in delta-delay models. A process is made postponed by including the keyword postponed, as shown by the full syntax rule for a process:

   process_statement  ⇐
       [process_label :]
       [postponed]  process  [(( signal_name  { ,  ... })  | all  ) ]  [ is ]
           [ process_declarative_item  ]
      begin
           { sequential_statement }
      end  [ postponed ]  process  [  process_label  ]  ;

The difference between a postponed process and a normal process lies in the way in which they are resumed during simulation. In our discussion of the simulation cycle in Chapter 5, we said that a normal process is triggered during a simulation cycle in which one of the signals to which it is sensitive changes value. The process then executes during that same simulation cycle. A postponed process is triggered in the same way, but may not execute in the same cycle. Instead, it waits until the last delta cycle at the current simulation time and executes after all non-postponed processes have suspended. It must wait until the non-postponed processes have suspended in order to ensure that there are no further delta cycles at the current simulation time. In addition, during initialization, a postponed process is started after all normal processes have been started and have suspended.

When we are writing models that use delta delays, we can use postponed processes to describe “steady state” behavior at each simulation time. The normal processes are executed over a series of delta delays, during which signal values are determined incrementally. Then, when all of the signals have settled to their final state at the current simulation time, the postponed processes execute, using these signal values as their input.

   entity SR_flipflop is
     port ( s_n, r_n : in bit;  q, q_n : inout bit );

   begin

     postponed process (q, q_n) is
     begin
       assert now = 0 fs or q = not q_n
         report "implementation error: q /= not q_n";
     end postponed process;

   end entity SR_flipflop;

   architecture dataflow of SR_flipflop is
   begin

    gate_1 : q <= s_n nand q_n;
    gate_2 : q_n <= r_n nand q;

   end architecture dataflow;

It is important to note that the condition that triggers a postponed process may not obtain when the process is finally executed. For example, suppose a signal s is updated to the value ‘1’, causing the following postponed process to be triggered:

   p : postponed process is
    ...
   begin
    ...
    wait until s = '1';
    ...  -- s may not be '1'!!
   end postponed process p;

Because the process is postponed, it is not executed immediately. Instead, some other process may execute, assigning ‘0’ to s with delta delay. This assignment causes a delta cycle during which s is updated to ‘0’. When p is eventually executed, it proceeds with the statements immediately after the wait statement. However, despite the appearance of the condition in the wait statement, s does not have the value ‘1’ at that point.

Since each postponed process waits until the last delta cycle at a given simulation time before executing, there may be several postponed processes triggered by different conditions in different delta cycles, all waiting to execute. Since the cycle in which the postponed processes execute must be the last delta cycle at the current simulation time, the postponed processes must not schedule transactions on signals with delta delay. If they did, they would cause another delta cycle at the current simulation time, meaning that the postponed processes should not have executed. The restriction is required to avoid this paradox.

In previous chapters, we described a number of concurrent statements that are equivalent to similar sequential statements encapsulated in processes. We can write postponed versions of each of these by including the keyword postponed at the beginning of the statement, as shown by the following syntax rules:

   concurrent_procedure_call_statement  ⇐
       [  label :  ]
       [ postponed ]  procedure_name  [ ( parameter_association_list ) ]  ;
   concurrent_assertion_statement  ⇐
       [ label : ]
       [ postponed ]  assert condition
                         [report expression ]   [ severity expression ]  ;
   concurrent_simple_signal_assignment  ⇐
      name <=  [ postponed ]   [ guarded ]   [ delay_mechanism ]  waveform ;
   concurrent_conditional_signal_assignment  ⇐
      name <=  [ postponed ]   [ guarded ]   [ delay_mechanism ]
              waveform when condition
               {  else waveform when condition }
               [ else waveform ] ;
   concurrent_selected_signal_assignment  ⇐
      with expression select  [ ? ]
          name <=  [ postponed ]   [ guarded ]   [ delay_mechanism ]
                   {  waveform when choices ,  }
                  waveform when choices ;

Inclusion of the keyword postponed simply makes the encapsulating process a postponed process. Thus, we can rewrite the postponed process in Example 23.18 as

   postponed assert now = 0 fs or q = not q_n
     report "implementation error: q /= not q_n";

In the preceding chapters, we have seen uses of association lists in generic maps, port maps and subprogram calls. An association list associates actual values and objects with formal objects. Let us now look at the full capabilities provided in association lists, shown by the following full syntax rules:

   association_list  ⇐   (  [ formal_part => ]  actual_part  )   {  , ...}
   formal_part  ⇐
      generic_name
       |  port_name
       |  parameter_name
       |  function_name (  (  generic_name  |  port_name  |  parameter_name  )  )
       |  type_mark (  (  generic_name  |  port_name  |  parameter_name  )  )
   actual_part  ⇐
       [ inertial ]  expression
       |  signal_name
       |  variable_name
       |  file_name
       |  subtype_indication
       |  subprogram_name
       |  package_name
       |  open
       |  function_name (  (  signal_name  |  variable_name))
       |  type_mark ((signal_name |variable_name  ))

The simple rules for association lists we used previously allowed us to write associations of the form “formal => actual”. When we are associating signal and variable object, the new rules allow us to write associations such as

   f1 ( formal ) => actual
   formal => f2 ( actual )
   f1 ( formal ) => f2 ( actual )

These associations include conversion functions or type conversions. We discussed type conversions in Chapter 2. They allow us to convert a value from one type to another closely related type. A conversion function, on the other hand, is an explicitly or implicitly declared subprogram or operation. It can be any function with one parameter and can compute its result in any way we choose.

A conversion in the actual part of an association is invoked whenever a value is passed from the actual object to the formal object. For a variable-class subprogram parameter, conversion occurs when the subprogram is called. For a signal associated with a port, conversion occurs whenever an updated signal value is passed to the port. For constant-class subprogram parameters and for generic constants, the actual values are expressions, which may directly take the form of function calls or type conversions. In these cases, the conversion is not considered to be part of the association list; instead, it is part of the expression. Conversions are not allowed in the remaining cases, namely, signal-class and file-class actual subprogram parameters.

subtype word is std_ulogic_vector(31 downto 0);

   function "<" ( bv1, bv2 : bit_vector ) return boolean;

   library ieee;  use ieee.std_logic_1164.all;
   use work.project_util.all;
   entity limit_checker is
    port ( input, lower_bound, upper_bound : in word;
           out_of_bounds : out std_ulogic );
   end entity limit_checker;
   --------------------------------------------------
   architecture behavioral of limit_checker is
    subtype bv_word is bit_vector(31 downto 0);
    function word_to_bitvector ( w : in word ) return bv_word is
    begin
      return To_bitvector ( w, xmap => '0' );
    end function word_to_bitvector;
   begin
    algorithm : process (input, lower_bound, upper_bound) is
    begin
      if "<" ( bv1 => word_to_bitvector(input),
               bv2 => word_to_bitvector(lower_bound) )
         or "<" ( bv1 => word_to_bitvector(upper_bound),
                  bv2 => word_to_bitvector(input) ) then
        out_of_bounds <= '1';
      else
        out_of_bounds <= '0';
      end if;
    end process algorithm;
   end architecture behavioral;

Since an actual for a port can take the form of an expression involving one or more signals, and the expression could be application of a function to a signal, there is potential for ambiguity in the association. If it were interpreted as an expression, it would be equivalent to assignment to an intermediate signal and association of that signal as the actual for the port, as described in Section 5.3. That would involve a delta delay between update of the actual signal and update of the port. On the other hand, if the actual were interpreted as a conversion function applied to the actual signal, then the port is updated in the same simulation cycle as the actual signal, with no intervening delta delay. In order to resolve this ambiguity, we can include the reserved word inertial in the association to specify that the interpretation involving an implicit signal is the one to use. If we omit the reserved word and the association can be interpreted as application of a conversion function or a type conversion, that interpretation takes precedence.

   function increment ( x : unsigned ) return unsigned;

   op_counter : component reg16
      port map ( d_in => increment(op_count), ... );

   op_counter : component reg16
      port map ( d_in => inertial increment(op_count), ... );

A conversion can only be included in the actual part of an association if the interface object is of mode in or inout. If the conversion takes the form of a type conversion, it must name a subtype that has the same base type as the formal object and is closely related to the type of the actual object. If the conversion takes the form of a conversion function, the function must have only one parameter of the same type as the actual object and must return a result of the same type as the formal object. If the interface object is of an unconstrained or partially constrained type, the type mark of the type conversion or the result type of the conversion function must include constraints that define any index ranges not defined by the interface object’s subtype.

A conversion in the formal part of an association is invoked whenever a value is passed from the formal object to the actual object. For a variable-class procedure parameter, conversion occurs when the procedure returns. For a signal associated with a port, conversion occurs whenever the port drives a new value. Conversions are not allowed for signal-class and file-class formal subprogram parameters.

   entity random_source is
     generic ( min, max : natural;
               seed : natural;
               interval : delay_length );
     port ( number : out natural );
   end entity random_source;

   architecture random_test of test_bench is

    subtype bv11 is bit_vector(10 downto 0);
    function natural_to_bv11 ( n : natural ) return bv11 is
      variable result : bv11 := (others => '0'),
      variable remaining_digits : natural := n;
    begin
      for index in result'reverse_range loop
        result(index) := bit'val(remaining_digits mod 2);
        remaining_digits := remaining_digits / 2;
        exit when remaining_digits = 0;
      end loop;
      return result;
    end function natural_to_bv11;
    signal stimulus_vector : bv11;
    ...
   begin
    stimulus_generator : entity work.random_source
      generic map ( min => 0, max => 2**10 - 1, seed => 0,
                    interval => 100 ns )
      port map ( natural_to_bv11(number) => stimulus_vector );
    ...
   end architecture random_test;

The type requirements for conversions included in the formal parts of associations mirror those of conversions in actual parts. A conversion can only be included in a formal part if the interface object is of mode out, inout, or buffer. If the conversion takes the form of a type conversion, it must name a subtype that has the same base type as the actual object and is closely related to the type of the formal object. If the conversion takes the form of a conversion function, the function must have only one parameter of the same type as the formal object and must return a result of the same type as the actual object. If the interface object is of an unconstrained or partially constrained type, the type mark of the type conversion or the parameter type of the conversion function must include constraints that define any index ranges not defined by the interface object’s subtype.

Note that we can include a conversion in both the formal part and the actual part of an association if the interface object is of mode inout. The conversion on the actual side is invoked whenever a value is passed from the actual to the formal, and the conversion on the formal side is invoked whenever a value is passed from the formal to the actual.

   type std_ulogic_vector is array (natural range <>) of std_ulogic;
   type std_logic_vector is array (natural range <>) of std_logic;

   architecture rtl of processor is
    component latch is
      generic ( width : positive );
      port ( d : in std_ulogic_vector(0 to width - 1);
             q : out std_ulogic_vector(0 to width - 1);
             ... );
    end component latch;
    component ROM is
      port ( d_out : out std_ulogic_vector;  ... );
    end component ROM;
    subtype std_logic_word is std_logic_vector(0 to 31);
    signal source1, source2, destination : std_logic_word;
    ...
   begin
    temp_register : component latch
      generic map ( width => 32 )
      port map ( d => std_ulogic_vector(destination),
                 std_logic_vector(q) => source1, ... );
    constant_ROM : component ROM
      port map ( std_logic_word(d_out) => source2, ... );
    ...
   end architecture rtl;

When we introduced ports in Chapter 5, we identified four modes, in, out, buffer, and inout, that control how data is passed to and from a design entity. VHDL provides a further mode, linkage. This mode may only be specified for ports of entities, blocks and components, not for generic constants or subprogram parameters.

Linkage ports were originally included in the language as a means of connecting signals to foreign design entities. If the implementation of an entity is expressed in some language other than VHDL, the way in which values are generated and read within the entity may not conform to the same transaction semantics as those of VHDL. A linkage-mode port provides the point of contact between the non-VHDL and the VHDL domains. Unless a simulator provides some additional semantics for generating and reading linkage ports, a model containing linkage ports anywhere in the hierarchy cannot be simulated.

In practice, linkage ports have not been used as originally intended. One alternative that has been developed is an extension to VHDL for analog and mixed-digital/analog modeling, called VHDL-AMS. It defines alternative classes of ports, called quantities and terminals, for dealing with analog connections. The one place where linkage ports have been used is in the Boundary Scan Description Language, which is a subset of VHDL for describing connections to circuits for test equipment. In that language, linkage ports are used for non-functional connections, such as power, ground, and unconnected pins.