MÓDULO FORMATIVO 2
6. Normativa voluntaria para la industria alimentaria
SIGNAL for an expression defined over The signal domains F28:why both, finite field (element) and
and signals vector space (vector) SIGNALs are needed AppendixD.2 D.2.2
SignalDomain and SIGNAL objects:
X example showing field elements and “just
vectors”
AppendixD.2 D.2.3 SignalPkg example for F24 X D.5.3 Section13.3
13.3.1
SignalPkg example for the tower field
X
D.2.4
The signal package construction F((22)2)2: this SignalPkg will 13.3.2 be used for the running example (13.1) 15.2.1
Section13.3
13.3.2
SignalPkg example for the tower field The signal package construction F((22)2)2- continued:
graphical representation of SignalPkg from Example13.3.1
AppendixD.2 D.2.4
SignalPkg example for different tower
X field constructions of F((22)2)2: both cons- tructions from Example13.2.1
CIRCUIT package part 2: functional description of the algorithm - Chapter14
AppendixD.3 D.3.1
Functional description for the running
X example (13.1) expression defined over
the tower field F((22)2)2
Section Ex. Title and keywords GAP VHDL Related Ex. CIRCUIT package part 3: VHDL-ready design - Chapter15
Section15.2
15.2.1 Datapath synthesis for an expression
Top-down over F((22)2)2 15.3.1
processing – top-down processing Section15.3
15.3.1 Datapath synthesis for an expression
Bottom-up over F((22)2)2
processing – bottom-up processing
AppendixD.4 D.4.1 Example15.3.1continued: X the VHDL-ready design
Section15.3
15.3.2
Declarations for additive constants
X Bottom-up in F((22)2)2: using directed
processing graph for the constant Section15.4
15.4.1 Connectors for the tower field elements X 16.1.1
Connectors and vectors in F((22)2)2
Section15.5 15.5.1 Datapath synthesis for an expression Putting it over F((22)2)2– revisited:
all together summary of Ex.15.2.1and15.3.1
CIRCUIT package part 4: Generating VHDL for the datapath - Chapter16
AppendixD.5 D.5.1 A full field_pkg.vhd example for F((22)2)2 X Section16.1
16.1.1 The connectors_pkg.vhd for the type X 16.2.1
VHDL packages conversion functions: declarations Section16.2
16.2.1 Example of connectors and input registers X
VHDL (sub)modules in the architecture: type conversions Section16.2
16.2.2
Example of architecture body for an expre-
X VHDL (sub)modules ssion defined over F((22)2)2: for the running
example (13.1) Section16.2
16.2.3 Example of registered vector output: X
VHDL (sub)modules submodule Fid2_mult for F22mult
AppendixD.5 D.5.2 Squaring for a polynomial basis: steps for X writing the datapath, partial binding (Key14.2)
AppendixD.5 D.5.3
A F24multiplier - full example:
X X
illustrates AlgDesignWriteTop, full binding (Key14.2), the difference between element and vector ports
Chapter 13
CIRCUIT package part 1: arbitrary finite
fields
13.1 Motivation . . . 163
13.2 The signal domains and signals . . . 167
13.3 The signal package - keeping it all in one place . . . 175
13.4 Summary of key insights . . . 183
alg.
gen. arch.
Overview of the CIRCUIT package part 1:
FSRtoVHDL GAPtoVHDL
CIRCUIT
– support for arbitrary finite fields –
Encoding of the finite fields and bases used in the design is required for VHDL datatypes and for generation of submodules. The GAP object SignalDomain stores information about the underlying finite field, basis used, basis direction, length, and the construction trail across the subfields.
This amount of information is needed to capture tower field constructions and to distinguish isomorphisms. The GAP object SIGNAL allows to view a finite field as a vector space. It holds the SignalDomain and and the “vector (space)” parameters length, direction, and an (optional) interpretation basis. SIGNAL allows for the distinction of (field) elements and vectors. All the VHDL data types used in the design are the SIGNAL objects translated into VHDL. The SignalPkg object holds all SignalDomains and SIGNALs. The sorting of SIGNALs follows the top-down modular approach to hardware design: the submodules are expected for the subfields.
13.1
Motivation
13.1.1
The running example
The following example is used to explain some challenges related to implementing an arbitrary dat- apath, and to show that a new package with capabilities beyond GAPtoVHDL and FSRtoVHDL is needed. Consider the expression with indeterminates a, b, c ∈ F and two arbitrary nonzero coeffi- cients γ1, γ2 ∈ F :
Expression (13.1) is given in ANF (equation (10.1)), and there is no restriction on γ1and γ2being
different. The expression (13.1) is considered over three different finite fields F Fq, q ≥ 2:
• F2, discussed in example13.1.1,
• F28, discussed in example13.1.2, and
• F((22)2)2, discussed in example13.1.3.
Expression (13.1) defined over F((22)2)2 (example13.1.3) will be used as a running example through-
out the remainder of PartIV.
Example 13.1.1 Expression defined over F2
When a, b, c ∈ F2, squaring is idempotent, i.e., a2 = a (recall the generalization of Fermat’s little
theorem in equation (3.2)). Furthermore, since γ1, γ2 ∈ F2 are nonzero, the expression simplifies
to
z= a · b · c + a + 1 (13.2)
The F2addition is implemented as an XOR gate and multiplication as an AND gate. All the ports and
signals are 1 bit wide and implemented in VHDL as std_logic. The circuit schematic is shown in Figure13.2(a).
Example 13.1.2 Expression defined over F28
When expression (13.1) is defined over F28, there are no simplifications. The field elements are rep-
resented using a basis of length 8, e.g., a polynomial basis. Then all the ports and signals are 8 bits wide and implemented in VHDL as std_logic_vector(0 to 7). This example corresponds to the right side of the diagram in Figure13.1.
The F28 addition is implemented as bit-wise XOR, but submodules are needed for multiplication M,
squaring SQ, and multiplication with constant ×γ1. γ1 is called multiplicative constant and γ2 an
additive constant, to differentiate between constants that infer submodules and constants that only require bit-wise XOR gates. The circuit schematic is shown in Figure13.2(b).
Example 13.1.3 Expression defined over F((22)2)2
When expression (13.1) is defined over F((22)2)2, there are no simplifications.
Recall example7.3.1from Subsection7.3.1. An element X ∈ F((22)2)2 is represented using a “per-
level” polynomial basis of the form BF((22)2)2/F(22)2 = {1, ρ}, where ρ is a root of the extension defining
polynomial f3(x): X = x0 + x1ρ, where x0, x1 ∈ F(22)2. The 8-bit wide signals must now be
represented as two coordinates of four bits each. Following Example7.3.1, it is clear that elements in F(22)2 must be represented as two coordinates of two bits each. Each of these two coordinates can
be represented as arrays/vectors of length two, e.g., array(0 to 1), but for F(22)2 and F((22)2)2, the
following question, shown graphically in Figure 13.1, arises: array of ???, i.e., array of what?. It is clear that the what will be the type of the subfield, but it is not yet clear how to capture this information in GAP.
The F((22)2)2 addition is implemented as bit-wise XOR, but submodules are needed for multiplication,
squaring, and multiplication with constants. Because the multiplier is working over a tower field F((22)2)2, it will need multipliers in F(22)2, which in turn will need multiplications in F22. Similarly,
squarers and multipliers with constants will also need submodules.
array(0 to 1) of ??? - F((22)2)2 F28 std_logic_vector(0 to 7) array(0 to 1) of ??? - F(22)2 2 - F22 2 std_logic_vector(0 to 2) F2 8 6 2 std_logic
Figure 13.1: Construction of finite fields F((22)2)2and F28and VHDL signals
13.1.2
Analysis
Examples13.1.1,13.1.2, and13.1.3identify the following problems: (a) are there algebraic simplifications (example13.1.1),
(b) how to obtain the submodules (examples13.1.2and13.1.3)
(c) which data type should be used for the VHDL signals? ( example13.1.3).
The problem (a) was addressed with miscellaneous methods from the FSR package Reduce- MonomialsOverField1 and DegreeOfPolynomialOverField. These methods are the first ex- ample of connecting an expression to a particular finite field.
1CIRCUIT package expects expressions to already have all their exponents reduced, i.e., no further simplifications like the one in example13.1.1are possible
b
a c
1
z
(a) Expression (13.2) over F2
b a c z SQ M M x (b) Expression (13.1) over F28
Figure 13.2: Circuit schematics (top-level modules) for expression (13.1): solid lines represent the ports and dashed lines the internal signals, boxes show the submodules needed: SQ - squarer, M - multiplier, ×γ1- multiplication with a constant γ1
FSR objects operate over one field, stored as the attribute UnderlyingField: feedbacks and filter- ing functions are defined over that field. This is binding per hardware module, not per expression, although each FSR object has only one expression. The first step in addressing problems (b) and (c) is to bind an expression to a finite field. This binding is achieved by introducing a new GAP object2that will hold both the expression and the finite field over which it is defined.
To obtain the submodules, the underlying finite field and the basis used must be known (problem (b)). There are two options: (i.) fetch the appropriate submodule from a library, and (ii.) generate the submodule on the fly. The current CIRCUIT package generates the submodules on the fly, using the FFCSA package methods listed in Table 7.5 to obtain the expressions for submodule implementation. The FFCSA methods for generating submodule expressions require the finite field and/or basis as input, but they do not store this information. Furthermore, as shown in Example
13.1.3, submodules must be generated for different levels of the tower field, implying more than one finite field is needed per design (problem(c)). Hence, there is no strict separation between problems (b) and (c).
Key 13.1: How to obtain the (sub)modules - binding expressions to finite fields
The first step in addressing this problem is to bind the expressions to the finite fields over which they are defined. The submodules are generated for the subfield operations. Knowing the subfield, its basis and direction, the expressions for the submodules are generated on the fly, using the FFCSA methods.
13.2
The signal domains and signals
The encoding of the finite fields (and bases) used in the design is required for the implementation of VHDL ports and signals and for the submodules, as was identified in example in Section13.1. In the case of FSR objects, the encoding of the finite field, i.e., which data type to use for the VHDL signals (motivation problem (c)), was addressed by storing a single UnderlyingField attribute. All ports and signals for the FSR objects were of elements or arrays of elements of the type given by the UnderlyingField . That means that as soon as the FSR object is created, so is the “world” it lives in.
The CIRCUIT package is intended to be more general and hence very powerful. Within the same top-level module, it should be possible to implement expressions
• defined over different finite fields, e.g., F23 and F28
• defined over a tower field, e.g., F((22)2)2
• defined over several isomorphic finite fields using different bases, e.g., PBF28/F2 and NBF28/F2,
including different tower field constructions
The field structure was captured by creating GAP objects SignalDomain (Subsection13.2.1), SIG- NAL (Subsection13.2.2) and SignalPkg (Section13.3). These objects provide a way to systemat- ically enter and build all the data types needed in a particular design.
13.2.1
The SignalDomain
The SignalDomain object serves as an umbrella for UnderlyingField, with additional informa- tion about the basis and direction used. From a mathematical perspective, it seems strange to talk about the length3or direction of a field element, two concepts that are very natural to a hardware designer. Similarly, from a hardware perspective, it is not common to talk about a basis; the basis is merely the mathematical interpretation of the signals.
The basis and direction must be fixed before writing the VHDL. Furthermore, they are mandatory for generating the submodules on the fly, which makes them the most important information. The length is simply the number of basis elements and is stored as attribute Length for convenience. Unless stated otherwise, this work assumes direction “to”. All attributes of SignalDomain are summarized in Table13.1.
The last piece of information is the tower field construction itself, which is stored as a list of all previous SignalDomain objects. It forms the construction trail across the subfields, stored as the SubSGDtower attribute. New notation is introduced for SignalDomain: Sr, where r is a
counter, starting from 1, i.e.,S1 for a SignalDomain object with F2 as the underlying finite field.
Because multiple SignalDomain objects can have the same UnderlyingField attribute, as will be shown in Example 13.2.1, the usual notation with field size, e.g., F((22)2)2 and S((22)2)2, is not
SignalDomainSr attribute comment
UnderlyingField the finite field Fq
UnderlyingBasis basis B used for representation of elements of Fq BasisDirection basis direction “to” or “downto”
Length length of the basis B (degree of extension)
SubSGDtower a list of SignalDomain objects for all subfields, ordered by increasing degree over the prime field, -1 when q= 2 Table 13.1: Main functionality of the CIRCUIT package - the SignalDomain attributes
enough to uniquely identify a particular signal domain. Example13.2.1illustrates why the tower field construction information is mandatory for successful VHDL implementation.
Key 13.2: The SignalDomain: the bases and the field construction trail
Encoding of the finite fields and bases used in the design is required for VHDL data types and for generation of submodules. The GAP object SignalDomain stores information about the underlying finite field, basis used, basis direction, length, and the construction trail across the subfields. This amount of information is needed to capture tower field constructions and to distinguish isomorphisms.
Example 13.2.1 Using different tower field constructions ,−→
The diagram in Figure13.3shows how different constructions of the finite field F((22)2)2. The first and the last level of the tower are constructed in the same manner, using the same (only) irreducible polynomial and the same basis for the representation of the elements. The middle level, however, is constructed in two different ways, yielding two different constructions. The construction on the left branch of the diagram in Figure13.3shows the extension field defining polynomial f2,1(x)= x2+ λx + 1, and the construction on the right branch of the extension field defining polynomial f2,2(x) = x2+ λx + λ. The two polynomials have different roots µ1 , µ2, where f2,1(µ1) = 0 and f2,2(µ2)= 0. The distinction between the left and the right branch is very important: the submodules for computation using basis B1will differ from the submodules for computation using B2. For clarity, all the constants are given w.r.t. a reference field defining polynomial RDP, listed in TableD.1.
Reference Reference field defining Root of Constants w.r.t. finite field polynomial - RDP pi(x) RDP pi(x) root of RDP F28 p3(x)= x8+ x4+ x3+ x2+ 1 p3(ν)= 0 ν3= ν15 F24 p2(x)= x4+ x + 1 p2(µ)= 0 µ1= µ6, µ2= µ7 F22 p1(x)= x2+ x + 1 p1(λ)= 0
Table 13.2: Reference polynomials and their roots
The UnderlyingField attribute stores the information about the degree of extension for each level, e.g., AsField( AsField( GF(2ˆ 2), GF(2ˆ 4) ), GF(2ˆ 8) ), but not about the “per-level” bases (PLB) used. This information is captured by SubSGDtower. The GAP ExampleD.2.1in AppendixD.2shows the two tower field constructions from diagram in Figure13.3captured in GAP as SignalDomain objects.
SD z }| { F((22)2)2 B F((22)2)2 /F(22)2={1,ν3} SE z }| { F((22)2)2 f3(x)=x2+µ3x+1 f3(ν3)=0 B1={1,µ1} SB z}|{ F(22)2 f3 6 SC z}|{ F(22)2 f3 6 B2={1,µ2} f2,1(x)=x2+λx+1 f2,1(µ1)=0 f2,2(x)=x2+λx+λ f2,2(µ2)=0 SA z}|{ F22 f2,2 - f 2,1 S z}|{ F2 f1=p1 6
Figure 13.3: Two different tower field constructions
, −→
13.2.2
The finite field as a vector space and the SIGNAL object
SIGNAL4is a new GAP object, that defines field elements or vectors. A vector is an array of given length, and its coordinates belong to a field. The simple case is an arbitrary vector (“just vector”), and a more complex case is a vector that belongs to a vector space (interpretation of a finite field). The object SIGNAL is a wrapper for SignalDomain, and stores additional information that allows for the distinction between elements and vectors. All VHDL data types needed for the datapath are SIGNAL objects, translated into VHDL.
While it is easy for the designer to switch between an input as an element of the finite field Fqm and
vector space Fm
q, for successful VHDL implementation this information has to be captured in GAP.
The SignalDomain can be implicitly treated as a vector space, but it does not hold “just vectors”. 4using the capital letters to differentiate the GAP object SIGNAL from a VHDL signal
The design can require signals that are vectors, without the notion of a vector space, e.g., the shift register for an FSR object or the input to function h(x) in Grain [46].
Discussion: In the case of tower field construction, e.g., F((22)2)2, the problem is the type
of the lower level, i.e., array of what, array(0 to 1) of ???. The problem was explained in more detail in motivation Examples13.1.2and13.1.3, and represented graphically in the diagram in Figure 13.1. When the finite field is constructed as a single extension, e.g., F28, the ports and
signals are defined as std_logic_vector(0 to 7), which is equivalent to array (0 to 7) of std_logic. VHDL array (vector) types have coordinates5that belong to some given domain. For F2m the coordinates belong to std_logic and the array itself is of type std_logic_vector(0
to m-1). The answer to the question array of what? is the given domain. In the case of the finite field Fqm, q = 2pand p, m > 1, the domain is Fqand the dataype for implementing the field elements
of Fqm an array (vector) type of length m. That is, the data type defines vectors of length m over Fq,
i.e., Fm
q rather than Fqm.
Key 13.3: The SIGNAL: finite field as a vector space and “just vectors”
For the designer it is easy to switch between an input as element of the finite field Fqm
and vector space Fm
q, but for successful VHDL implementation this information has to be
captured in GAP. Furthermore, the given algorithm can require “just vectors”, that are not elements of a given finite field, i.e., vector space, however, these vectors have coordinates from a given finite field, i.e., a given SignalDomain. The SignalDomain was embedded into another GAP object called SIGNAL, which holds the SignalDomain and the “vector (space)” parameters length m, the direction, and an (optional) interpretation basis. They allow a distinction of (field) elements and vectors. All the VHDL data types used in the design are SIGNAL objects, translated into VHDL.
There are two categories of SIGNALs, elements and vectors. The SIGNAL object is shown in Table13.3, and columns mentioned below refer to this table. LetSrbe the SignalDomain for Fq,
q ≥2, andS1 will be used for the special case q= 2. The following distinction (and notation) of
SIGNAL objects is based on the length m:
• an element is a SIGNAL of length m = 1 with the signal domain Sr, denoted:
F (Sr, 1, −, −) ∼ Fr (13.3)
It is a SIGNAL representation, i.e., embedding, of the SignalDomain Sr, and hence an
element of the finite field Fq, represented bySr:
– for q= 2, the F1representsS1and hence elements of F2(column 1).
– for q = q0 p and q0 ≥ 2 and p > 1,Fr representsSr and hence elements of the finite
field Fq, which is an extension the finite field Fq0 (column 2).
5 word “coordinate” is preferred to the word “component” to distinguish between vector coordinates and the hardware components implemented as submodules
• a vector is a SIGNAL of length m > 1 over the signal domain Sr, denoted:
V (Sr, m, d, B) (13.4)
The coordinates ofV (Sr, m, d, B) belong to the finite field Fq of the signal domainSr, but
the vector itself can be either a vector space representation of the next extension (r n for r-next)Sr n for Fqm with direction d and basis B, or a “just vector” over Fq. If it is a vector
space representation of a finite field Fqm, the basis is set to B, otherwise this component is −.
Again, the distinction is made based on Fqof theSr:
– for q= 2, V (S1, m, d, B) represents vectors over F2(column 3)
– for q > 2,V (Sr, m, d, B) represents vectors over an extension field Fq(column 4)
Both element columns in Table13.3 consider vectors of length 1 over the domain specified in the first half of Table13.3: there is no notion of basis or direction (hence − in rows 9 and 10). The two vector (space) columns consider the actual vectors of length m, with coordinates from the SignalDomainS specified in the first half of the table. The row “vector (space)” Fm
q, is implicitly
defined by the underlying finite field Fq (row 2) of its signal domainSr (row 1) and by the length
m (row 8). This interpretation is also valid for the first two columns, with elements viewed as vectors of length m = 1. The “just vectors”, which do not belong to a vector space, also do not have a basis, hence the last row is the only row without the “always exists” checkmarkX. When the vectors represent finite field elements, the basis of that field is considered as an interpretation of the vector coordinates (row 10, note [7] in Table13.3).
VHDL has no notion of basis as such, and the interpretation basis is used by other GAP methods to generate the expressions for implementation of submodules and for the testbenches (note [4] in Table 13.3). The direction is only needed for the VHDL (row 9, note [3] in Table13.3), and for some FFCSA package methods that have adopted the notion of direction from VHDL.
Table 13.4shows three levels of a tower field construction Fq0 → Fq → Fqm, where q = q0 p, the
corresponding signal domains are Sr p → Sr → Sr n. The notation r p stands for “r previous”
and rn for “r next”. This general setting corresponds to column 4 in Table13.3. The elementFr n
is the embedding of the signal domain Sr n into a SIGNAL. The vector Vr n is the vector space
representation of the signal domainSr n; but its coordinates belong to the subfield, i.e., Sr. The
UnderlyingBasis (row 5 in Table 13.3) of an element SIGNAL is the interpretation basis (row 10 in Table13.3) of the vector SIGNAL obtained when viewing the finite field as a vector space. The following abbreviation is used for vector space notation:
V (Sr, m, d, B) ∼ Vr n (13.5)
Similarly, when direction d is fixed, parameters can be omitted from “just vector” notations:
V (Sr, m, d, −) ∼ V (Sr, m) ∼ Vrm (13.6)
The first column in Table13.3 shows elements of the ground field F2 and has the same entries in
both halves of the table. When viewing finite fields as vector spaces, there is an overlap between an elementFrand vectorVr in columns 2, 3, and 4 in Table13.3for the following cases:
SIGN AL