A Typing Discipline for Hardware Interfaces

Modern Systems-on-a-Chip (SoC) are constructed by composition of IP (Intellectual Property) Cores with the communication between these IP Cores being governed by well described interaction protocols. However, there is a disconnect between the machine readable speciﬁcation of these protocols and the veriﬁcation of their implementation in known hardware description languages. Although tools can be written to address such separation of concerns, the tooling is often hand written and used to check hardware designs a posteriori . We have developed a dependent type-system and proof-of-concept modelling language to reason about the physical structure of hardware interfaces using user provided descriptions. Our type-system provides correct-by-construction guarantees that the interfaces on an IP Core will be well-typed if they adhere to a speciﬁed standard.


Introduction
Hardware Description Languages (HDLs) such as Verilog, SystemVerilog and VHDL are designed to realise both the structure and behaviour of hardware systems.Hardware is modelled as interconnected components (modules) that are connected through ports; ports being individual wires or a collection of wires.Ports carry data, and the flow of data on a port is directional.HDLs abstract over groupings of ports (port groups) as an interface, and present values at higher levels of abstraction such as integers and strings.A component can have multiple interfaces that each send multiple values, and can each be characterised differently.An initiating interface (initiator) initiates communication, and the targeted interface (target) is the recipient of the communication.Modern hardware design is not just about digital circuits, it is also about describing systems of systems.For instance, System-on-a-Chip (SoC) views hardware modules (IP Cores) as boxes connected using well-known and bespoke interfaces.The structure, and behaviour, of these interfaces are described in natural language documents [3,41,4].Such standards documents will present an abstract interface description which is a global view of

A rt ifact
an interface agnostic to its endpoint usage, and will provide salient structural information (using natural language) about each port in the interface required for realisation in a HDL.Details provided include a port's size, sensitivity, necessity, flow, and dependencies between the details specified.Further, these documents describe behavioural characteristics of the interfaces as a whole.For example, how ports are grouped to describe different channels.
While circuit-level designs are required to implement behaviour at a low-level, the designer must also ensure that the components in a SoC design are correctly connected according to the provided specification.Standardised machine readable formats such as IP-XACT capture many of the structural information found within the standards document's natural language descriptions [23].However, interface specifications written using IP-XACT cannot be parameterised, nor can structural dependencies be specified between ports and over interfaces.Further, not all the information contained within a natural language document can be specified using IP-XACT.For instance, IP-XACT does not support the definition of strobe, a signal carried on a separate port that is linked to an individual bit in multi-wire data bus.The number of strobe is dependent on the size of the bus.Conversely, the machine readable specification can present information more clearly than the specification document itself.For example, port necessity for the APB specification is more clearly described in the IP-XACT specification than in the standards document.
Generally speaking, there is a disconnect between the description of an interface's structure in a standards document, its representation in a standardised machine readable format, and its enforcement in a HDL.When instantiating these interfaces in a HDL there are no mechanisms to ensure that the characterised interfaces respect the specifications.As a result, mismatches between the specifications and their implementations are common.

Contributions
The aim of our work is to improve the security and safety of SoC design by utilising state-of-theart concepts from programming language theory to provide greater correct-by-construction guarantees over the structural and behavioural aspects of SoC designs.
Dependent type-systems present a rich and expressive setting that allows for precise program properties to be stated and verified directly in the language's type-system [28].Such type-systems also support modelling of resource usage in the style of substructural typing [40,6].By building upon existing work from hardware design we can use these concepts to construct a type-based formal description of abstract interfaces, and formally validate that concrete component interfaces adhere to these descriptions at design-time using type checking.
Specifically, we make the following contributions: 1.We present a type-driven modelling framework (Cordial) for reasoning about interfaces on components within a SoC design.2. We show the use of Cordial for describing an exemplar protocol Mungo, and discuss how Cordial can be used to model real-world protocol specifications: APB, LocalLink and AXI [4,3,41].3. We describe the formalisation of our framework in the dependently typed programming language Idris [9] that also constitutes a proof-of-concept implementation.
Figure 1 summarises the core constructs that comprise Cordial and their relations.Modelling information is taken from the IP-XACT standard [23] and existing work [30] to construct a model (θ AID ) to represent abstract interface descriptions.Our model construction language (λ AID ) is a simple extension to the Simply Typed Lambda Calculus (STLC) and models parameterised specifications as computable functions, and allows dependencies to be made between signals.The type-system of λ AID follows a substructural design [40,5] allowing correctness guarantees towards labelling of signals to be lifted into the type-system.Model construction is from reduction of λ AID instances to a reduced form (λ redux AID ) which is then evaluated to construct θ AID instances using continuation passing.Concrete interfaces are modelled using θ COMP to present components in a SoC with multiple interfaces.
Inspired by notions of global and local types from Session Types [22] abstract interface specifications are treated as a global description that is characterised to a local descriptionθ proj AID .By embedding the projected model (θ proj AID ) into the type of the interface description (θ COMP ) the model's type-system ensures that a local type is satisfied by its global type.Further, the concept of thinnings [1, § 3] captures a specification's optional ports, and allows optional ports to be knowingly skipped.
Application of Cordial would see it embedded within existing SoC tooling and to enrich existing HDLs with static design-time mechanisms that would make mismatches between interface specification and implementation impossible and thus reduce errors, increase design productivity and enhance safety and security of the SoC designs.The transformations of specification instances, and model projections would be automatic and hidden from users.Protocol designers would have a tool (based on λ AID ) to design interface specifications.During the SoC design phase SoC designers use these specifications to annotate their components (θ COMP ) and ensure their port selections are correct.

Outline
Section 2 presents a running example that further motivates our work.Section 3 introduces our model for abstract interface descriptions (θ AID ) and the specification language (λ AID ) used to construct θ AID model instances.Section 4 details our model (θ COMP ) for describing concrete components and how projected θ AID instances are used to type-check interfaces.Section 5 briefly describes the formalisation of Cordial in Idris, and Section 6 considers use of the framework to model real-world interaction protocol specifications.Section 7 discusses the efficacy of the framework, and considers related work.The paper concludes with a discussion over future work in Section 8.

Notation.
For simplicity the syntax for standard algebraic types are abstracted over.Similar abstractions are used for dependent types.Single-field variant types are presented with a constructor name as the label and the body being a n-ary tuple.Where possible simple typing rules are embedded within the presentation of abstract syntax and types.Model types are denoted using blackboard style letters.Types from construction languages are denoted using uppercase Greek letters.Constructs subscripted with: d are from θ AID ; and p are from θ proj AID .

E C O O P 2 0 1 9 2 The Mungo Protocol
Presentation of Cordial will be aided through consideration of an exemplar protocol (Mungo) that captures salient physical properties common to many interaction protocols.

6:5
Figure 2 shows how Mungo can be realised in SystemVerilog.The interface is parameterised, however, SystemVerilog only allows such interfaces to have a single default parameter.Mungo has multiple default parameters.Two characterised interfaces for both an initiator and target are presented as modports.Error related signals and clock information are optional.Interfaces can take many other valid structural forms.SystemVerilog supports unrestricted use of dangling ports, in which a receiving port is unconnected.In these cases the value received is taken as the default value as dictated by the port's type.A designer can also deviate from the specification and make required ports optional.When connecting two modules together that support Mungo the wrong interface might be left out.Further, not all HDLs support the concept of dangling ports.Figure 3 presents a second use of SystemVerilog to declare two components that support Mungo, and connect them together.Within Figure 3 we present a visualisation of the module interconnections.Within this example, the initiating component has two dangling ports for optional error reporting, and we have deviated from the specification in using different labels.SystemVerilog provides name and positional oriented connection of modules.Ultimately, the programmer is responsible for ensuring that the ports are connected correctly, and can wire or name ports freely.We need to ensure that the interfaces on a module are valid against their respective specifications.

Abstract Interface Descriptions
This section presents a model (θ AID ) for reasoning about abstract interface descriptions, together with a language (λ AID ) for model construction.How λ AID instances are transformed into θ AID instances is also described.Taking inspiration from IP-XACT [23], abstract interfaces are modelled as a named-tuple of port descriptions and other metadata.This is a common approach as seen by existing work [30,19].For each port a variety of emergent properties are also tracked.Dependent types control invariants over model structure and property values.θ AID model instances are not parameterised, the construction language (λ AID ) facilitates creation of parameterised specifications and ensures models created use unique labels using substructural typing.

Properties
Ghica et al. [19] modelled ports according to their size and signal direction.However, there are other important properties as shown by McKechnie [30].Ports are uniquely identified using labels.Similar types of ports share similar behaviour.A port can: communicate data; provide addressing information; provide clock ticks; trigger a reset; signal an interrupt; indicate control; provide port-level behavioural information; or is used in a general sense.Differentiating between these behaviours is important when connecting two (or multiple) ports together.Not all ports in an interface are required, and how a port responds to changes in signal (sensitivity) should also be captured.
For interfaces, salient properties concern the style of communication.Does the interface expect to interact with a set number of other interfaces, or interact directly with another interface?

Model Components
Figure 4 Common terms and their types.
Figure 4 presents the shared terms and types used throughout the models and languages presented.Numbers originate from the set of natural numbers greater than zero.Port labels are specification dependent and assumed to be typed enumerations.Signals are either sensitive or insensitive.Sensitive wires are level sensitive (high, or low) or edge sensitiverising or falling.Signals either originate from a system interface, or from another component -IP Core.An interface's communication style is either broadcast or unicast.
Of interest is how a port's type and label are modelled.A "kind" provides type-level disambiguation between different kinds of labels and ports.θ AID & λ AID support several types of port, and different port types have different shapes.Data and address ports will always be an array of ports.Clocking information, resets, interrupts, and control ports will always use a single wire.General and information ports can have either shape.When describing widths, the shape of the port will dictate possible values.
Ports must be labelled, however, they can also share a common name with a fixed set of other ports -cf.strobes in APB and AXI.A label is either named and is used once, or indexed and used i times.To prevent ambiguities between different label families, the type for labels is indexed with the type associated with the underlying name used.

A Model for Abstract Interfaces
Figure 5 presents the core modelling constructs, and typing rules, for θ AID model instances.Within θ AID , signal flow is directional.Signals flow from: initiator to target ( ); target to initiator ( ); bidirectional ( ); always received ( ); or always produced -( ).Ports can be completely optional ( ? ), target optional ( ?t ), initiator optional ( ?i ), or are required -( ! ).Wire ports have width (1 d ), and array ports have width (w d (n)) where n is greater than one.Ports can be specified with an arbitrary width -(∞ d ).The type for port widths is paramterised by a port kind.This enforces the relation that ports will have the correct width for their kind i.e. a wire can only have length one.
A port description is a named tuple comprising of the port's label (l), kind (k p ), type (t), flow ( f ), necessity (o), width (w), sensitivity (s), and origin -(h).The type for ports is a type synonym for the following dependent function: Dependently typed terms allow for an invariant to hold during term construction.The port kind associated with a port type and width, must respect the specified port kind.Thus, if the port has kind WIRE then its width and type must be suitable for a wire.Further, the port type itself (P d (L)) is indexed by the type associated with label.
Ports are grouped in a cons-style collection (ps : PG d (L)) whose type is also parameterised by the type associated with labels.All ports in a group must have the same type of label.An abstract interface is a named tuple containing the interface's communication style, max number of initiators and targets, and a collection of ports.

Example
Figure 6 presents a θ AID instance for Mungo -Table 1.An enumerated type provides labelling information.θ AID instances are, however, not parameterised.Mungo is an interface that can be instantiated with several address and data bus widths.The example instance for Mungo in Figure 6 provides holes ( ) in place of precise widths.Exact values for widths must be presented.Further, there are no restrictions on label use, one can easily duplicate the use of a name.The next section presents a language to present parameterised specifications and ensure label uniqueness.DWU   J. de Muijnck-Hughes and W. Vanderbauwhede 6:9

Specifying Interface Descriptions
Figure 5 presents a model instance that is dependently typed, however, the model design itself has several limitations.First, labels are not required to be unique.Second, model instances cannot be parameterised.We address these issues through creation of a description language λ AID .An extension of the STLC, λ AID describes the construction of model instances.Specifications are a sequencing of port descriptions, and other metadata.Function, and application, in λ AID provide parameterisation of specifications, and descriptions of structural dependencies.Evaluation of λ AID , using continuation passing, constructs instances of a θ AID model.A substructural type-system provides further correct-by-construction guarantees that labels are unique.Construction semantics detail model instance construction from λ AID programs.

Counting Label Usage
Substructural type-system's extend existing type-systems with extra information [40].Labels in θ AID instances are required to be unique.The type-system for λ AID is designed to ensure that label usage is linear: A label can only be used once.
Inspired by the work of McBride [29] we utilise a "rig" to capture label usage.For our bespoke use case a rig of the same style is not required.McBride's rig is for computation (addition and multiplication), and our rig is for usage accounting only.We define our rig as:   and "Pure" form a monadic computation context in which the labels and their usage are the computation in context.Although, sequencing is presented separately from "Let"-bindings, sequencing can also be described as a "Let"-binding where ω is bound to 1 .
The term stop denotes the end of a specification such that all labels are used.Terms are presented to represent functions, and function application.Predicated versions of functions and application exist to restrict parameters of type N * to predefined sets of whole numbers.Whole labels are created using a single term.Port declarations are similar to port construction in Figure 5a, except that rather than a direct label, port descriptions must take a label variable.There are terms for setting communication style, and max number of initiators and targets.Within λ AID , labels are not indexed.Ports with an indexable label are indicated using replicate.
A simple arithmetic language with binary operators to operate on whole numbers is embedded within λ AID .Supported operations are addition, subtraction, multiplication, and division.With this, user provided widths can be used to construct arithmetic dependencies on the number of ports in a specification.This is described using replicate.Allowing for data dependent port specifications (i.e.strobes) to be supported.Figure 8 presents the types for λ AID .Here L is a placeholder to represent a user defined set of labels.Several types are taken from existing constructs (Figures 4 and 5a) without the type for labels, ports, port groups and interfaces.Three new types are introduced.First is the unit type (1) to represent terms that do not represent computations.Second is the type for label variables (Λ (L, u)), indexed by the type of the underlying label value and parameterised with usage information from the "Rig o' 2".Function types follow the standard definition, and predicated functions are restricted to acting on whole numbers.

Type-System
Within λ AID well-typed contexts (Γ) comprise of name type pairings.Contexts can be extended using (+), and named terms updated using (±).
Section 3.4.3presents the typing rules for λ AID .For brevity the typing rules for maths expressions are not provided.Like the syntax definition for λ AID itself, the typing rules follow that of the STLC, but with extensions for describing abstract interfaces.Rules Var,Lam, App, Let, Pure, and Seq follow standard conventions with one noticeable difference that follows from the work of Atkey [5]: Usage information associated with labels presents stateful information.The monad form by "Let", "Seq", "Unit", and "Pure" is a Hoare Monad that allows state information for label usage to be threaded through the entire computation [8].The notation Γ old e Γ new represents updating the context from Γ old to Γ new .The context will change only if the rules are well-typed.Where the notation is not used implies the context does not change.Predicated functions, and their application, mirror their plain counterparts but have a side-condition that requires the predicate to hold true for type-checking to be successful.
The typing rules for labels and ports use the "Rig o' 2" to instantiate and augment the usage count for types for labels -Λ (L, u).These are the type-level computations that enforce correct label usage.Rule LBL presents the typing rule for label creation, initialising the type with usage free.Rule Stop describes the end conditions for λ AID programs, and results in erasure of the context.λ AID programs will successfully type-check only if all label variables have been used.Rule Port specifies a new port, and consumes labels.A label ω with type Λ (L, u), and usage u can only be used if the usage is free.If the label is available to use the type for ω in resulting computations will be Λ (L, used), and thus be unavailable.
Replication of a port description (Rule REP) details that a port will be replicated if the number of replications is greater than two.The remaining rules detail the simple typing rules for the remaining terms.Figure 10 demonstrates how Mungo is specified using λ AID .The concrete set of labels from Figure 6 are reused.The specification for Mungo is parameterised through function specification.This is reflected in the specification's type signature.The use of the specification to create θ AID instances is also restricted to values of x ∈ {32, 16} and y ∈ {8, 4}.A type error will occur if values for x and y were chosen that were not in the provided sets.The type signature also shows the initial and end contexts for the function; start with nothing, end with nothing.Different specification instances are generated through application of the function to different values.

Building Models from Specifications
In this section the set of transformations to construct θ AID instances from λ AID programs are described.We first reduce λ AID programs to core terms, and use continuations to represent model construction as evaluation of a reduced λ AID program.
Figure 11 presents the reduction rules for reducing λ AID programs to core terms following standard conventions.Reduction of N * values mirrors reduction of natural numbers but with smallest value being one not zero.The reduced version of a λ AID program is called λ redux AID , and the reduction of a λ AID program l to its reduced form (l ) by the operation l ⇓ redux l .Much like the STLC reduction of λ AID programs will also be strongly normalising.To construct θ AID model instances, the reduced form, λ redux AID , is first transformed into a continuation (λ cont AID ) in the style of Hatcliff and Danvy [21].This transformation is denoted using l cont , where l is an instance of λ redux AID .Using this approach we can make model construction more easily checkable for termination, and model construction comes from evaluation of λ cont AID instances.For brevity we do not provide the definitions of λ cont AID and l cont , and remark that they follow standard contructions [21].

Evaluation of λ cont
AID instances, which we denote using ⇓ cont , transforms: label variables into labels; port declarations into port descriptions; and repeated port declarations into port groups.Each evaluation of the accessor functions for setting description values replaces the previously see value, and a default set of values are supplied initially.When evaluated, the continuation returns a tuple containing the final interface metadata and collated port groups.
The complete steps to construct a θ AID from λ AID are defined as: Definition 2 (Construction of θ AID from λ AID ).Let m be a θ AID model instance, and l be a λ AID program.The construction of m is defined as the reduction of l to an instance l of λ redux AID .This instance l , is then evaluated to an instance of λ cont AID that is then reduced using ⇓ cont to produce m: Specifying IP Core Interfaces Section 3 described the specification and construction of θ AID instances, these are abstract interface descriptions.This section looks at the specification of components in a SoC design and how guarantees are made that the physical interfaces satisfy given θ AID instances.
A model for reasoning about components (θ COMP ) is introduced.Each component comprises of a set of physical interface models whose interfaces are satisfied by a θ AID instance.Interface satisfaction is a two-step process: first a θ AID instance is projected ( ) using the specified endpoint e, creating the projected model θ proj AID .Second, the projected model is used in the type of an interface to provide a type-level invariant that the presented interface satisfies the projected model.Dependently typed model terms ensures that if an interface is well-typed then the interface satisfies the provided specification.

Projecting Abstract Interfaces
Figure 12 presents the terms, and salient types for a projected interface model instance.
A projected interface represents the local view of an abstract interface.The structure of a projected interface mirrors that of an abstract interface, and values only differ w.r.t. a port's signal flow (direction), and necessity.The type's for ports, port groups, and interfaces are parameterised by the type of labels associated with ports, the endpoint that the term was projected to, and the originating abstract interface.The types are indexed with the originating term to allow for structural invariants, for example a port's shape, to be specified.
-cf.Section 3.3.A projected port is either unidirectional in receiving (+) or sending signals (−); or is bidirectional -(±).A port is required ( ! ) or optional ( ? ).The types for directions and necessity are both dependent, each containing the endpoint being projected and the original projected value.These values are not free to choose.Figure 13 presents the typing rules that constrain the values in the projected model to predetermined pairings.Dependent types ensure the correctness of projection transformation.The projection for port flow and necessity are defined as functions (( d ) and ( n )) that, given a flow or optional description will compute the required direction -or necessity.Their type signatures are: These projection functions will only type check if the given inputs match the allowed pairing of values for the returned type.Figure 14 presents the remaining typing rules for projected interfaces, ports, and port groups.Like the structural definition, the typing rules mirror those for their abstract counterparts, and are indexed by the type associated with labels.However, the types are further indexed by their abstract counterparts, and also by the endpoint the term is being projected under.The θ AID instance provides as a type-level meta-model from which information is sourced.This approach allows for several invariants on the structure of the projected interface to be established.Figure 15 presents the projection semantics for projecting θ AID instances to θ proj AID instances.The type signatures for each projection function are omitted for brevity, but they follow those for ( d ) and ( n ).By design, projections and their invariants are well-typed.Malformed projections will fail to type-check, for example if the widths or calculated directions are wrong.

Example
Figure 16 presents example projections for the θ AID instance for Mungo, applied to parameters 32 and 8 using predicated function application.Figure 16a shows a projection for an initiator interface, and Figure 16b  (Mungo $ {32,16} 32 $ {8,4} 8) AID λ →θ i Target iface p (Unicast, 1, 1,port p (Named(C), WIRE, Clock, +, ? ,1 d , High, System) :: p port p (Named(R), WIRE, Control, +, ! ,1 d , High, IP) :: p port p (Named(W), WIRE, Control, +, ! , directions for each port are mirror images of each other, aside from the constant direction for the system clock and the bi-directional data port.Further, the definition of a port's necessity have been calculated to respect if the port is optional or not.The ports for returning error information are optional if the interface's endpoint is a target interface and required if the endpoint is an initiator.

Specifying Physical Interfaces
Abstract interfaces, and their projections, represent descriptions of a component's interface, we must also model the component itself.Figure 17 presents the terms and types for θ COMP model instances.Figure 18 presents the typing rules.The structure of concrete interfaces mirrors that of the abstract interface and projection.However, a concrete interface does not have optional ports, within our model dangling ports are not allowed.To model skippable ports the concept of thinnings is used [1].A thinning allows for structures to be weakened using some decision procedure [13,2].We can use this concept to weaken the specified ports in an interface's portgroup w.r.t. a given specification.Our decision procedure is simple: a port can be skipped if the projected port is optional.The 6:17

W-Z
i : N * shape : Figure 18 Typing rules for concrete interfaces.

E C O O P 2 0 1 9 6:18
A Typing Discipline for Hardware Interfaces thinning decision procedure does not occur at the value level.Thus a concrete port group is either: empty -∅; extended by a port (::); skipped by an optional port ( ); or an optional port is skipped when extending the group with a port -(::≈).The operator (::≈) can be defined as the combination of the (::) and ( ) operators.That is p :: ( ps) ≡ p ::≈ ps.The typing rules (Figure 18) show how thinning works for interface specifications.The θ proj AID is a type-level invariant, the specification of the necessity of the projected ports is what allows the thinning to occur, or not.
A component is modelled as a collection of interfaces.The type for a component is indexed by a collection (xs) of θ AID -endpoint pairings.The type for a collection of interfaces is indexed by the separated elements of each pair in xs.As a collection of interfaces is constructed, the θ AID instances are projected (at the type-level) by the endpoint type to construct the θ proj AID instance indexing the collected interface.Use of projection at the type-level ensures that the type for a concrete interface is sourced from the specified projection.
In θ AID model instances, wires have width one, arrays have fixed width greater than one, or are unrestricted.When projecting an abstract port, the width does not need to be projected into a local value.However, the port width in a θ COMP instance needs to respect the width in the θ AID .Widths are modelled using a dependent data type that captures, and reasons with, the width of an abstract port.
An instantiated port with an abstract port and an unrestricted width has no restrictions on kind or width.A port with an abstract port of width one must also have a width of one.Similarly, a port with an abstract port of fixed width must also have the same fixed width.

Example
Figure 19 presents two example interfaces that model Mungo.Figure 19b shows the interface with a port to receive the clock, and Figure 19c without a clock port.Within Figure 19c the skip term ( ) allows for the clock to the be skipped.If other required ports were to be skipped this will result in a type error.For both interfaces we have chosen the user defined error message width to be of width 32 and 16.This will not cause a type error as the Mungo allows the signal to have a user-defined width.Further, should other value level information (e.g.port width and label) be incorrectly specified the example will also fail to type-check.

Type-Checking Interfaces
The type of interfaces in θ COMP are parameterised by projected interfaces from θ proj AID .A satisfaction relation is defined to link programs written in λ AID to interfaces from θ COMP .Definition 3 (Interface Satisfaction).Given a λ AID specification ( ν : 1 ), and an interface ϑ : I (L, e, ϑ p ) then the interface ϑ satisfies ν, which is defined as

Implementation
We have realised Cordial using Idris, a general purpose dependently typed programming language [9].This provides both a practical proof-of-concept implementation, and mechanised formalisation that the framework's type-system holds.The models representing interfaces, port groups, and ports translate directly to standard dependently (and non-dependently) Type for both Interfaces.

Case Studies
Using our implementation we have constructed models for several interaction protocols of varying sizes.We describe the structural properties of the protocols and report on their modeling in Cordial as λ AID programs.

ARMs Advanced Peripheral Bus
The first protocol considered was ARMs Advanced Peripheral Bus (APB) [3].The protocol is a legacy protocol comprising of at least eleven signals, and can be connected to many target IP Cores using an intermediary IP Core called an interconnect.This requires that we construct two specifications one for target connections to the interconnect, and the other for The data and address width can be up to 32 bits in width.There are three interesting features of APB worth noting.First, the specification is parameterised depending on the number of IP Cores that an initiator is connecting too.When connecting to x targets, the signal PSelx will be replicated x times in an initiating interface, which will only be seen once in a target interface.Second, the protocol has optional signals for the clock and a signal to enable the clock.The dependency between the two clock signals is not clear from the specification: Can one be skipped when the other is required?Third, the specification requires a set of strobes that connects to every 8 th bit on the data bus.This restricts data widths to multiples of eight.
We chose to implement the specifications using two predicated functions, and one normal function.The two predicated functions was used to ensure that all bus widths are multiples of eight and less than 32 i.e. 8, 16, and 32.The normal function was used to represent the number of targets.Specification of labels and ports followed the known information taken from the specification.The term replicate was used to ensure that the correct number of PSelx signals were generated.For strobes, the maths operations were used to calculate the number of strobes required, based of the size of the data bus.Figure 20 shows part of the APB specification detailing the predicated functions, use of replicate, and strobe specifcation.

Xilinx's LocalLink
The second protocol chosen was a legacy protocol from Xilinx called LocalLink [41].The LocalLink protocol requires seven signals and thirteen optional signals.As with the APB protocol many of the signals were encoded without complications.However, and unlike APB, LocalLink does not specify a set of bus widths and requires that the presented bus width is a multiple of eight.Predicated functions require that the list of possible values are known a priori.Thus, we modelled the specification as a predicated function on bus widths of 8, 16, and 32, together with a normal function that takes the number of channels.
The LocalLink specification contains various size dependencies based on the data bus.The size of the remainder bus is dependent on how they are implemented within the IP Core.Specifically, if the remainder is encoded then the bus size will be log 2 d 8 − 1 .If the remainder is masked then the size is d 8 − 1.Our framework is not expressive enough to encode these differences mathematically, we support simple arithmetic operations and these operations are not simple.Moreover, our framework does not support related specifications that overlap to be collapsed into a single definition.The LocalLink specification is too value dependent.
Another interesting aspect of the LocalLink specification is that of channels.These are a set of optional signals whose flow is dependent on the application context.The size of channel related signals are too calculated using a floating point operation.These three signals are directional, and whether they send data from target to initiator is dependent on the application, and how the other two signals are specified.Although we can represent these channels as being bidirectional our language is not expressive enough to capture these application specific, and inter signal, dependencies.

ARMs Advanced eXtensible Interface
ARMs Advanced eXtensible Interface (AXI) is a widely used family of interaction protocols [4] for transferring addressable data between IP Cores.There are several previous versions of AXI each building upon previous versions.Each version differs by number of signals and changes to specific signal properties.The AXI specification defines three protocols that offer three different interaction styles: Full, Lite, and Stream.The protocol can be directly connected to another interface, or it can be used to connect to multiple other IP Cores using an interconnect.We report on describing version four of the AXI protocol for direct interfaces only.For versions of the protocol that connect to an interconnect, the techniques presented in Section 6.1, can be leveraged.The specification was modelled in λ AID using two predicated functions to control the width of the address and data busses.Each of the signals were translated into the required port descriptions.Like the APB protocol, AXI has the concept of strobes.The same technique as used in Section 6.1 was used.
We chose not to include user-defined signals in this study.Cordial requires that signal details are known a priori.Ideally, designers would create parameterised specifications (functions) that take as parameters the user-defined signals.However, functions in λ AID take pure values as parameters, port declarations modify the typing environment to update label usage information and are thus not pure.This is a restriction from the substructural type-system for λ AID -see Section 7.3.
The protocol specification divides the signals among several channels.Such a grouping is only required for the specification.At the module level these groupings do not exist.Although, Cordial does not support this grouping incorporating this into the framework would be a potential benefit for reasoning about subgroupings of an interface's portgroup.

Discussion & Related Work
This section discusses the efficacy of the framework, and related work.

Discussion
Section 6 described three case studies that modelled three interaction protocols using λ AID .
For each of the protocols we were able to encode most of the ports correctly Cordial is suitable for capturing each port's values.However, both LocalLink and APB illustrated the limitations of λ AID in capturing all of the specification's dependencies.While Cordial can capture limited value dependencies, for example strobes and number of targets within APB, the framework prohibits the construction of concise descriptions based on other value dependencies.Specifically, for ports whose direction is dependent on a mode of operation (LocalLink), and how to version protocols -AXI versions 1-4.Although we can write multiple different versions, a dependently typed construction should be able to capture these properties concisely, and without resorting to copying and pasting protocol specifications.We need to explore what other dependencies there are within a protocol specification, how prevalent these dependencies are, and how we can capture and reason about the relevant dependent properties.
The construction of λ AID exposes the resource tracking of the type systems directly as resources are associated with variables.This does leads to a more verbose language such that for n signals there will be n variables, and n additional ports declared.This is not optimal.An alternative approach would be to embedd the resource tracking directly in our monad's type to remove the need for variables-cf.Swiestra's Hoare & Atkey's parameterised monads [37,5].However, our current formulation is more extensible allowing arbitrary new states to be added by indexing the type of new variables.
The type-level resource tracking in λ AID also prohibits the creation of higher-order descriptions.The typing rule Lam requires a pure value, and sequencing using Let and Seq require that the knowledge contained in the environment is passed from the previous construct to the next.This is a limitation of the Hoare Monad used to sequencing expressions.

Modelling Hardware Interfaces
Many attempts at reasoning about hardware have centred on formalising hardware systems as a collection of digital circuts and capturing the behaviour of signals through the specified circuits.Ghica et al. exploited category theory to investigate connection of components [18,17,19].EDSLs have been developed for Haskell such as Lava [20] and Cλash [35] that take other mathematical approaches to reasoning about hardware behaviour.ΠWare utilises dependent types to reason about hardware [15,16].Vijayaraghavan et al. [38] presents a complete formalisation of the behaviour of SoC designs, however, their approach does not look at the validation of interfaces against a specification, and concentrates on modelling the behaviour of components as a distributed system.Our framework complements existing work by providing guarantees about the physical structure of a component's ports.
Tooling such as Vivado IP Integrator [39] and Kactus2 [24] can automatically construct, and connect, components in a SoC architecture correctly.Such tooling is based on IP-XACT and vendor extensions.Examination of the Vivado toolchain reveals handwritten TCL scripts bespoke for the AXI family of protocols.Our work presents a specification agnostic framework for type-checking hardware interfaces against a richer specification than seen with IP-XACT solutions.We position our work as possible foundation for machine derivable code to develop richer integration and construction checks to that seen with IP Integrator and Kactus2.
Click is an untyped SoC design language for describing the routing of data [25].McKechnie [30] developed a type-system for typing the interconnections found within Click specifications.Our work provides a natural extension to McKechnie's work and provides a means to type components in a Click design against external specifications.

Substructural Typing
The substructural type-system for λ AID is based upon Hoare logic [5,8].Unfortunately, Hoare logics do not support the frame rule, a means to divide and share invariants in a composable manner.This results in λ AID not being able to support higher-order descriptions.
Separation Logic is an advancement that does support the frame rule [34], and has been used to construct substructural type-systems for EDSLs [26], However, it is not clear how straightforward it would be to realise such a type-system for an EDSL within a dependently typed language.
There are other formal models upon which one can realise substructural type-systems for EDSLs, namely TypeStates [31], and Refinement Types from Hoare Types [8,32].All allow for reasoning about type-level resource usage protocols, however, how straightforward these models can be realised within a dependently typed language is not clear.
λ AID was realised as an EDSL, perhaps realising it as a standalone Domain Specific Language (DSL) written in Idris might allow for Idris' rich type-system to better realise the substructural typing for λ AID .Future work will be to investigate how to realise, and implement, the substructural typing for λ AID .

Implementing Cordial
Cordial has been implemented within Idris.Any other dependently typed language that supports full-spectrum dependent types, such as Agda [33], would also be suitable host language.
Although Cordial uses dependent type theory and substructural typing, non-dependently type languages can also realise the framework.The ideas are transferable, but the implementation would not be as clean nor concise.Racket is a general purpose language that supports EDSL creation through fine-grained control over the language's type-system [14].F is a general purpose language with value-dependent types [36].Whereas Idris provides full-spectrum dependent types, F provides value-dependencies using refinement types.This provides a novel, alternate, environment in which to construct "value-dependently-typed" programs.How the approach behind Cordial is transferable to these languages is worth investigating.

Conclusion
We presented a framework (Cordial) to provide correct-by-construction guarantees over interface specifications in SoC designs.We have demonstrated use of the framework to model real world protocols, and noted limitations in the models expressiveness and future work to enrich said expressiveness.There are other areas for future work:

Checking Existing Systems
Our approach lends itself well to the generation of designs from model instances.We can easily extend our Idris implementation to generate stubbs for various HDLs.However, how do we evaluate existing interfaces?To do so, not only do we need to be able to extract interface model descriptions from existing HDL code, but also associate these model descriptions with abstract interface model descriptions.That is, we need to be able to infer from a component specification the concrete interfaces, and for those interfaces their abstract descriptions and which characterisation corresponds to the found interface.The problem of model inference is difficult as component interfaces are not always cleanly defined.Multiple interfaces for a component can be presented as a flat port group, sending ports can send to multiple recipients, and the ordering of ports does not necessarily reflect the ordering in the specification.Further, the names given to ports may not match the labels described in the specification.Developers, and code generation tools, have complete freedom in structuring their components interfaces.Further work will be to explore how to infer models from such "messy" SoC descriptions.

Enriching existing HDL
We have formalised Cordial in an existing general purpose language.A more interesting area for future work, and to increase adoption of the ideas mentioned, would be to develop extensions for various HDL such as SystemVerilog with the presented framework.A similar approach would be to extend existing design environments such as Vivado from Xilinx to incorporate our tooling and ideas.

Checking Behaviour
Our solution reasons about the structural correctness of SoC architectures.These provided guarantees are a design time check.Standards documents also describe a protocol's behavioural correctness.Our models do not capture a component's behaviour, a correctly connected component may show incorrect behaviour (as described in the specification) at run time.We saw this when modelling the AXI family of protocols.Cordial borrows notions of global and local projections from Session Types.We could also look to use Session Types to reason about hardware behaviour.While there have been attempts at extending Session Types to fit communication models similar to those found in hardware [27], none have been directly applied to checking hardware.Future work will be to explore how we can extend our model descriptions to capture the behaviour of a component's interface.

Modelling complete SoC architectures
SoC designs are about connecting components.A natural extension to our work would be to provide an orchestration language that uses θ COMP to model components and their connections.Existing work has investigated verifying IP Core connections using static typing to ensure substructural properties of a SoC design hold -Section 7.2.Integrating the work of McKechnie [30] into the expressive type-system of our framework can serve as the basis for a more complete solution to SoC design.We leave this aspect of future work as an open problem.

Figure 1
Figure 1 Relationships between various languages, models, and intermediate representations.

Figure 3
Figure 3 SystemVerilog module definitions adhering to Mungo, and signal flow indicators.

( a )
Terms and types.

Figure 5
Figure 5 Definition of θ AID .

Figure 6
Figure 6Mungo as a partial θ AID instance.
free} be a set, with an operation use(u) to change a u ∈ R as follows: use(u) free → used used → used 3.4.2Terms e i | n | r | f | k p | s | h | c Constants | (add e e) | (sub e e) | (mul e e) | (div e e) Maths | 1 | ω Unit Values & Variables | e; e | e | let ω be e in e Statements

Figure 7
Figure 7 Terms for λ AID .

Figure 7 9 6: 10 A
Figure7presents the terms for λ AID .Common structures from Figure4are included except for the terms for labels.Terms can be sequenced, and bound to variables using let-bindings.Pure values are indicated with e .Combined the terms "Let", "Seq", "Unit"

Figure 8
Figure 8 Types & typing context for λ AID .

Figure 11
Figure 11 Reduction rules for λ AID .

Figure 13
Figure13 Typing rules for flow and necessity projection.

Figure 14
Figure 14 Typing rules for θ proj AID .

Figure 15
Figure 15 Projection semantics for θ proj AID .

Figure 16
Figure 16 Mungo projected as θ proj AID instances.

Figure 17
Figure 17Terms for concrete interfaces.

Proof.
By construction.The evaluation of ν ( ν ) produces a model (ϑ d : I d (L )), for some (L : Type L ).The type of ϑ is I (L, e, ϑ p ).The projected interface ϑ p has type I p (L, e, ϑ d ).If ϑ d ≡ ϑ and L ≡ L then ϑ d i e ≡ ϑ d i e.If ϑ d ≡ ϑ d or L ≡ L then ϑ would fail to type check.

Figure 19
Figure 19Sample θ COMP instances that show port skipping.

E C O O P 2 0 1 9 6: 20 A
Typing Discipline for Hardware Interfaces initiating connections.At least seven signals are required, and two were target optional.At least seven signals have a known width.

Table 1
Signal descriptions for Mungo.

Table 1
presents the signal descriptions (abstract interface description) for Mungo.Behaviourally the protocol represents the reading and writing of data from the initiating IP Core to the target 1 .Mungo provides unicast style communication, it does not support broadcast communication through a shared bus.A system clock (SYS_CLK) can send signals to both the target and initiator.The clock is optional as the clock source for the specified component might not go through this interface.Reading and writing are dictated by the initiator using control wires CTRL_R and CTRL_W.A data bus is bidirectional and data can have a width of 32 or 16 bits.The address bus is eight or four bits in width.Error reporting is optional where: ERR_MODE indicates the type of error; and ERR_INFO is the message itself.The width of error messages are left to the implementer.All wires have high sensitivity.

2 0 1 9 6:14 A Typing Discipline for Hardware Interfaces
PG p (L, t, ps d ) ∅ p | p p :: p ps p Portgroup i p : I p (L, t, i d ) iface p (c style , n, n, ps p ) Interface e p e d | t | d p | o p | p p | ps p | i p Expressions T p T ∈ T d | E | D (t, f ) | O (t, o d ) Types | P p (L, t, p d ) | PG p (L, t, p d ) | I p (L, t, i d ) p : P p (L, t, p d ) port p (l, k p , t, d p , o p , w d , s, h) Port ps p : proj AID .
ps p : PG p (L, e, ps d ) iface p (c, maxI, maxT, ps p ) : I p (L, e, iface d (c, maxI, maxT, ps d )) PP l : L(L, k l ) k p : K P t y : A (k p ) d : D (e, f ) o : O (e, o d ) w d : W d (k p ) s : S h : H port p (l, k p , t y, d, o, w d , s, h) : P p (L, e, port d (l, k p , t y, f , o d , w d , s, h)) p : PG p (L, e, ∅ d ) p : P p (L, e, p d ) ps p : PG p (L, e, ps d ) p p :: p ps p : PG p (L, e, p d :: d ps d ) IP c : C style maxI : N * maxT : N *

1 .
Non-projected values must match.2.Values parameterising the type of projected values are sourced from the abstract description and must match.3. The endpoint that terms are being projected under must match.4. The structure of the projected interface must match the structure of the abstract interface.
θ AID → θ proj AID port d (l, k p , t,d p , o p , w d , s, h) p e port p (l, k p , t, (d p d e), (o p n e), w d , s, h) ∅ d g e ∅ p p d :: d ps d g e (p d p e) :: p (ps d g e) iface d (cstyle, a, b, ps p ) i e iface p (cstyle, a, b, (ps p g e)) Version four of the protocol requires 47 signals comprising of: two global signals for the clock and a reset; thirteen signals each for specifying writing and reading of an address; seven signals for reading and writing data; and five signals for writing responses from the target to the initiator.Of the 47 signals, 36 are required and eleven are either optional, target optional, or initiator optional.Several signals have user defined widths.The AXI protocol is parameterised such that the address and data busses can be: 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide.Further, the protocol specification supports custom sets of signals that are completely user definable.In fact the AXI standard explicitly warns against their use due to potential interoperability issues if different modules present user-defined signals that behave differently.