Defining the Hardware Components

The hardware components of our example are mainly defined in VHDL. For the communication between the FPGA and a PC we shall use the predefined Virtual JTAG component provided by Quartus (see Sect. 11.4), as for the n-bit multiplexers we also use one of Quartus’ Megafunctions. All these components are then combined in a Block Diagram/Schematic File. Starting bottom-up though, we first define the ROs themselves.

When Quartus compiles a design, an analysis for logical redundancies is made and nodes just passing on a value like the RO’s delay elements (cf. Fig. 11.1) are removed automatically. To prevent the compiler from “optimising away” the delay elements, they have to be defined as low-level primitives called LCELLs. Listing 11.1 shows the VHDL code for an RO. Line 5 sets the amount of delay elements (including the RO’s nand gate) as a generic variable. Line 6 defines the input and output as Lines 10 and 11 define the internal signals. In Lines 12 and 13, the LCELL component is stated to be used in Lines 17 and 19, where the first delay element after the nand gate (lc_0) and the remaining delay elements (lc_i) are defined.

Listing 11.2 shows how an arbitrary number of ROs (given as a generic variable in Line 5) is defined reusing the RO definition (Lines 10-13). The ros component has one output for each of its ROs (Lines 6 and 18). In this example, the number of ROs is 16. For simplicity, all ROs are permanently activated (Line 17). In a more elaborate implementation, there could be individual input ports to activate only the desired ROs. Activating all ROs, even though only two are sampled at a time, is a waste of energy but might also be considered a countermeasure against side-channel attacks that extract RO frequencies through electromagnetic emissions [12]. Because when all ROs oscillate, it is more difficult to single out individual RO frequencies.

Listing 11.1 ro.vhd_

LIBRARY IEEE;

  • 2 USE IEEE.STD_LOGIC_1164.ALL;
  • 3
  • 4 ENTITY ro IS
  • 5 GENERIC (length : INTEGER := 16);
  • 6 PORT (enable : IN STD_LOGIC; output : OUT STD_LOGI );
  • 7 END ro;
  • 8
  • 9 ARCHITECTURE arch OF ro IS
  • 10 SIGNAL path : STD_LOGIC_VECTO] (length DOWNTO 1);
  • 11 SIGNAL nand_out : STD_LOGIC ;
  • 12 COMPONENT LCELL PORT (a_in : IN STD_LOGIC; a_out : OUT STD_LOGI< );
  • 13 END COMPONENT;
  • 14 BEGIN
  • 15 nand_out <= enable nand path (length );
  • 16 output <= path(length);
  • 17 lc_0 : LCELL PORT MAP (a_in => nand_out , a_out => path (1));
  • 18 lc_gen : FOR i IN 1 TO (length-1) GENERATE
  • 19 lc_i : LCELL PORT MAP (a_in => path (i), a_out => path(i +1));
  • 20 END GENERATE;
  • 21 END arch;

Listing 11.2 ros.vhd_

LIBRARY IEEE;

  • 2 USE IEEE.STD_LOGIC_1164.ALL;
  • 3
  • 4 ENTITY ros IS
  • 5 GENERIC (ros_number : INTEGER := 16; ros_length : INTEGER := 16);
  • 6 PORT (ros out : OUT STD_LOGIC_VECTOB (ros_number-1 downto 0));
  • 7 END ros;
  • 8
  • 9 ARCHITECTURE arch OF ros IS
  • 10 COMPONENT ro
  • 11 GENERIC (length : INTEGER);
  • 12 PORT (enable : IN STD_LOGIC; output : OUT STD_LOGIC);
  • 13 END component;
  • 14 BEGIN
  • 15 ro_gen : FOR i IN 0 TO ros_number -1 GENERATE
  • 16 ro_i: ro GENERIC MAP (length => ros_length) PORT MAP (
  • 17 enable => '1',
  • 18 output => ros_out(i)
  • 19 );
  • 20 END GENERATE;
  • 21 END arch;

After creating a new Block Diagram/Schematic File in Quartus (e.g. myPUF.bdf), a Symbol File for ros.vhd can be created by right-clicking it in the Project Navigator window and selecting “Create Symbol Files for Current File”. Afterwards, the block symbol of ros can be selected with the Symbol Tool in the view of myPUF.bdf. Figure 11.6 shows the complete myPUF.bdf file. So far, we have only placed the ROs. Next come the 16-bit multiplexers

Listing 11.3 counter.vhd_

  • 1 LIBRARY IEEE;
  • 2 USE IEEE.STD_LOGIC_1164.ALL;
  • 3 USE IEEE. STD_LOGIC_UNSIGNED.ALL;
  • 4
  • 5 ENTITY counter IS
  • 6 PORT (
  • 7 osc : IN STD_LOGIC;
  • 8 run : IN STD_LOGIC;
  • 9 reset : IN STD_LOGIC;
  • 10 result : OUT STD_LOGIC_VECTOR (63 DOWNTO 0)
  • 11 );
  • 12 END ENTITY counter;
  • 13
  • 14 ARCHITECTURE arch OF counter IS
  • 15 SIGNAL count : STD_LOGIC_VECTOR (63 DOWNTO 0);
  • 16 BEGIN
  • 17 result <= count;
  • 18
  • 19 PROCESS (osc , run, reset)
  • 20 BEGIN
  • 21 IF reset = '1' THEN count <= (OTHERS => '0');
  • 22 ELSIF run = '1' THEN
  • 23 IF RISING_EDGE (osc) THEN count <= count + 1;
  • 24 END IF;
  • 25 END IF;
  • 26 END PROCESS;
  • 27 END ARCHITECTURE arch;
  • (MUXs) (one bit for each RO), which can be found in the Symbol Tool under .../quartus/libraries/megafunctions/gates/mux.

To count the oscillations of the ROs, simple sequential counters can be used as defined in Listing 11.3. The counter value is stored in an internal 64-bit register (Line 15), that is connected to the counter’s output result (Line 10 and 17). The input signal osc is connected to the output of an RO selected by a MUX. At each rising edge of osc, the counter value is incremented by one (Line 23), given that the run input signal is set to 1 (Line 22). By setting the reset input signal to 1, the counter value is reset to zero (Line 15).

Here, a counter width of 64 bits suffices. Depending on how long the RO oscillations are counted and on how fast they oscillate, a smaller or greater number of bits is required. Notice that for very fast ROs, a sequential counter might not be able to capture all rising edges. For such high-frequency RO-PUFs, we recommend using ripple counters instead.

Each RO-PUF response bit is created by comparing the results of two counters with a comparator logic as defined in Listing 11.4. Block symbols for counter and compare can be generated the same way as described above for ros. After connecting the MUXs’ outputs to the counters’ inputs and the counters’ outputs to the comparator’s input (cf. Fig. 11.6), the remaining unconnected signals are the select inputs of the MUXs, the run and reset inputs of the counters, and the result

Listing 11.4 compare.vhd_

LIBRARY IEEE;

  • 2 USE IEEE.STD_LOGIC_1164.ALL;
  • 3
  • 4 ENTITY compare IS
  • 5 PORT (
  • 6 a : IN STD_LOGIC_VECTO (63 DOWNTO 0);
  • 7 b : IN STD_LOGIC_VECTO (63 DOWNTO 0);
  • 8 result : OUT STD_LOGIC
  • 9 );
  • 10 END ENTITY;
  • 11
  • 12 ARCHITECTURE arch OF compare IS
  • 13 BEGIN
  • 14 result <= '1' WHEN a > b ELSE '0';
  • 15 END arch;

output of the comparator. These are the signals that we want to access from outside the FPGA via the JTAG interface. Details about the communication between the FPGA and a PC are given in Sect.11.4 together with a description ofthe controller logic and its VHDL code (Listing 11.7). The controller is connected to a Virtual JTAG component that can be generated in Quartus using the MegaWizard Plug-In Manager. Chose “Create a new custom megafunction variation” and then Installed Plug-Ins/JTAG-accessible Extensions/Virtual JTAG. As file type and filename chose VHDL and vjtag. Next, the instruction register width can be defined. As we do not need more than eight different instructions, three bits are enough. Before finishing the generation of the Virtual JTAG module, check that the symbol file vjtag.bsf is automatically created. Otherwise, it can also be generated afterwards like we have generated symbols from VHDL files before and like we are generating one from controller.vhd. It is only necessary to manually add the newly created vjtag.vhd file to the project files in the Project Navigator. After placing and connecting all block symbols correctly, the complete design in myPUF.bdf looks like the one in Fig. 11.6.

This design can be compiled already. However, there will be several compiler warnings like “Found combinational loop”. As this is exactly what was intended with the ROs, though, these messages may be suppressed for future compiler runs. Even a first test of the PUF is possible. Among the generated signature bit values there should be an almost equal amount of 1s and 0s. An examination of several FPGAs, however, will show that many signature bits are the same for all FPGAs, which is bad PUF uniqueness.

The reason for this can be identified in the Quartus Chip Planner, where the mapping of the design components to the FPGA hardware is visualised. For now, the compiler was free to decide how to place the components, which is in most cases not ideal for the quality of delay-based PUFs. The following sections show how to enforce the placement and routing such that the PUF quality is greatly improved.

The Quartos block diagram of the complete design

Fig. 11.6 The Quartos block diagram of the complete design

 
Source
< Prev   CONTENTS   Source   Next >