FSR-based system configuration

An interactive Manager function is invoked with the setup file as its argument. The Manager parses the setup file and writes an empty spreadsheet template file *.tsv. At this point, the Manger halts and waits for the user instruction. The user then fills and stores the spreadsheet, and types “yes” into the GAP prompt. No further user interaction is required. The Manager function reads back the spreadsheet, which now contains the configuration for the entire FSR-based system, and begins with synthesis for the top-level datapath. All submodules are written in the process.

The spreadsheet lists all possible sources as columns and all possible targets as rows. The structure of the FSR objects is used to write the empty spreadsheet template: each FSR can have only two data inputs, the load data input i_fsr and the input for the external step i_ext, and a single output o_fsr. Furthermore, since the FSR objects are simply enumerated by the FSRid (see the last column in Table11.3) all rows and columns can easily be extracted from the FSR list and the list with top-level data inputs and outputs.

Key 11.2: The top-level datapath and configuration template

The top-level datapath is specified with a spreadsheet template that lists all possible sources as columns and all possible targets as rows. The possible sources are the top-level data inputs and the o_fsr outputs of all FSRs, and the possible targets are the top-level outputs and both the i_fsr and the i_ext inputs of all FSRs in the cipher, see Key11.1. The naming convention follows fsr_FSRid_i_fsr, fsr_FSRid_i_ext, and fsr_FSRid_o_fsr.

The designer has to fill out the spreadsheet using connector rules, the user-specified FSM state keywords, and keyword always. The state keywords are used to extract the multiplexers, and the keyword always is interpreted as a “hard-wired” signal. All state keywords are crosschecked with the information obtained in the setup file, and any deviation triggers an error.

The connectors are listed in the first column in Table11.4: merge, split, select, expand and per- mutation, also depicted graphically. The table contains very simple rules, followed by examples showing the format of each connector.

rules

source(s) target(s) exclusive same

connector range length positions permutation (sub)field example

merge X X X X [2,1,-1],[-1,-1,0]

split X X X [0,1], [2]

select X X X [1,3]

expand X X X [0,1,1,1]

permutation X X X X [1,3,0,2]

The format of the connectors is very intuitive: connectors are lists of indices of the source signal(s). As such, one of the rules is that all the values (indices) fall into the range of the source signal(s). Only the merge connector can have more than one source. The next rule is about the length of the target signal(s): there must be a driver for each coordinate of the target, hence the length of the list(s) must match the length of the target signal(s). Only the split connector can have more than one target. The merge connector example shows two lists of length 3, assuming the target signal has length 3. In the first list, the last index has a value of -1, indicating this index will come from another source. Indeed, the second list has the values -1 twice, and than 0 for the last entry. The positions of the -1 values must be exclusive among all the lists, and eventually, a driver must be found for each position. The select and expand connectors are quite selfexplanatory, and the only constraint on the permutation is that it must be an actual permutation of indices where every index in the range appears exactly once. The last rule checked is the that the indexed values are of the same type and can be connected with a wire. The FSRtoVHDL package works for F2 or F2m, so

this is a simple check. Basis transitions are not yet supported and must be inserted manually. The Manager will recognize the connectors in the filled-out spreadsheet (configuration) and check the rules listed in Table 11.4. For example, if two index lists are found in the same row of the spreadsheet, they are interpreted as a merge connector. Similarly, an index list that is shorter than the length of the source signal is interpreted as the select signal. Note that split can always be regarded as multiple select connectors, which is how the Manager reads the spreadsheet.

i_data_1 i_data_2 fsr_1_o_fsr fsr_2_o_fsr fsr_3_o_fsr fsr_4_o_fsr

o_data_1 × × × × × run

fsr_1_i_fsr load × × × × ×

fsr_1_i_ext × × × × init ×

fsr_2_i_fsr × load × × × ×

fsr_2_i_ext × × [0] run × × init

fsr_3_i_fsr × × [1, 2, 3, 4, −1] [−1, −1, −1, −1, 1] × ×

fsr_3_i_ext × × × [0] × ×

fsr_4_i_fsr × × × × always ×

fsr_4_i_ext × × [0] × × ×

Table 11.5: Grain spreadsheet example

 Implementation detail: The top-level data ports are specified as INOUT objects. These objects have an underlying finite field F, which is added to the list of all fields in the design, and the duplicate free list of finite fields is used to write the field_pkg.vhd. Hence, the fields used for the top-level ports have a field identifier Fid, and their VHDL

data types are defined using this Fid. 

Example 11.3.3 Grain – the filled-out spreadsheet template ,−→

Table11.5 shows the filled out spreadsheet template (Grain configuration), built from information provided in the template from Example11.3.2. The first two columns are the top-level data input ports, i_data_1 and i_data_2, for

the two INOUT objects in top_data_inputs list in Example11.3.2. The other columns are the FSR output ports, obtained from the fsrlist in Example11.3.2. The first row is the top-level data output port, o_data_1, for the INOUT in the top_data_outputs list in Example11.3.2. All other rows are the two possible inputs to the four FSR objects: the primary data input i_fsr and the external step input i_ext. The names of the FSR objects are as listed in last column of Table11.3.1. all fsr_FSRid_* signals will appear as internal signals in the generated VHDL for the top-level datapath. The easiest way to follow Table11.5is to compare it with the schematic in Figure11.3, which has annotations for the i_fsr and i_ext inputs to each FSR.

For example, i_data_1 is connected to the i_fsr input of fsr_1 during load, and the fsr_4_o_fsr is connected to top-level output o_data_1 during run. The fsr_2_i_ext (the nlfsr) is connected to fsr_1_o_fsr[0] dur- ing run, as indicated by the select rule [0], and fsr_4_o_fsr during init. The fsr_3_i_fsr is connected to merged signals from fsr_1_o_fsr[1,2,3,4], which correspond to the lfsr stages S3, S25, S46 and S64, and fsr_2_o_fsr[1], which corresponds to the nlfsr stage S63, see the output taps lists in the constructor calls for the FSRs in Example11.3.2. The keyword always means the fsr_3_o_fsr will be hardwired to the fsr_4_i_fsr.

, −→