David Fiala

Philippe Rigaux

Alice Tacaille

Virginie Thion

Gioqoso

Gioqoso Members

ENSSAT, Lannion Léo Bechet

Vincent Besson

Adrien Guillaud-Rollin

Marco Gurrieri

Olivier Pivert

Data Quality Rules for Digital Score Libraries

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

There is a growing availability of music scores in digital format, produced by numerous individuals and institutions, and often publicly accessible from web sites and social media. This has been made possible by the combination of two factors: mature, easy-to-use music editors, including open-source ones like MuseScore [START_REF] Musescore | MuseScore[END_REF], and sophisticated music notation encodings. Leading formats today are those which rely on XML to represent music notation as structured documents. MusicXML [Good, 2001] is probably the most widespread one, due to its acceptance by major engraver softwares (Finale, Sibelius, and MuseScore) as an exchange format. The MEI initiative [Rolland, 2002[START_REF] Mei | Music Encoding Initiative[END_REF], inspired by the TEI, attempts to address the needs of scholars and music analysts with an extensible format [START_REF] Hankinson | The Music Encoding Initiative as a Document-Encoding Framework[END_REF]. Recently, the launch of the W3C Music Notation Community Group [W3C, 2015] confirms that the field tends towards its maturity, with the promise to build and preserve large collections of scores encoded with robust and well-established standards. We are therefore facing emerging needs regarding the storage, organization and access to potentially very large Digital Libraries of Scores (DSL).

It turns out that building such a DSL, particularly when the acquisition process is collaborative in nature, gives rise to severe quality issues. In short, we are likely to face problems related to validity (measure durations, voices and parts synchronisation), consistency (heterogeneous notations, high variability in the precision of metadata, undetermined or inconsistent editorial rules), completeness (missing notes, directives, ornamentation, slurs or ties), and accuracy (music, lyrics).

There are many reasons for this situation. First, encoding formats have changed a lot during the last decades. We successively went through Hum-Drum and MIDI to finally come up with modern XML formats such as MusicXML and MEI [Selfridge-Field, 1997]. A lot of legacy collections have been converted from one encoding to the other, losing information along the way. Given the cost and time to edit scores, incorporating these collections in a modern repository is a strong temptation, but requires to accept, measure, and keep track of their quality shortcomings.

Second, the flexibility of music notation is such that it is extremely difficult to express and check quality constraints on the representation. Many of the formats we are aware of for instance do not impose that the sequence of events in a measure exactly covers the measure duration defined by the metrics. As another example, in polyphonic music, nothing guarantees that the parts share the same metric and same duration. So, even with the most sophisticated encoding, we may obtain a score presentation which does not correspond to a meaningful content (the definition of which is context-dependent), and will lead to an incorrect layout (if not a crash) with one of the possible renderers.

Third, scores are being produced by individuals and institutions with highly variables motivations and skills. By "motivation", we denote here the purpose of creating and editing a score in digital format. A first one is obviously the production of material for performers, with various levels of demands. Some users may content themselves with schematic notation of simple songs, whereas others will aim at professional editing with high quality standards. The focus here is on rendering, readability and manageability of the score sheets in performance situation. Another category of users (with, probably, some overlap) are scientific editors, whose purpose is rather an accurate and long-term preservation of the source content (including variants and composer's annotations). The focus will be put on completeness: all variants are represented, editor's corrections are fully documented, links are provided to other resources if relevant, and collections are constrained by carefully crafted editorial rules. Overall, the quality of such projects is estimated by the ability of a document to convey as respectfully as possible the composer's intent as it can be perceived through the available sources. Librarians are particularly interested by the searchability of their collections, with rich annotations linked to taxonomies [START_REF] Riley | Ask a Librarian: The Role of Librarians in the Music Information Retrieval[END_REF]. We finally mention analysts, teachers and musicologists: their focus is put on the core music material, minoring rendering concerns. In such a context, part of the content may be missing without harm; accuracy, accessibility and clarity of the features investigated by the analytic process are the main quality factors.

Finally, even with modern editors, qualified authors, and strong guidelines, mistakes are unavoidable. Editing music is a creative process, sometimes akin to a free drawing of some graphic features whose interpretation is beyond the software constraint checking capacities. A same result may also be achieved with different options (e.g., the layer feature of Finale), sometimes yielding a weird and convoluted encoding, with unpredictable rendering when submitted to another renderer.

The authors of the present paper participate in the production, maintenance and dissemination of digital libraries of scores encoded in XML (mostly, MEI). One of these DSLs is the Neuma platform. Neuma is an open repository of scores in various formats, managed by the IReMus 1 , and publicly accessible at http://neuma.huma-num.fr. The CESR2 publishes rare collections of Renaissance music for scholars and musicians (see, e.g., the "Lost voices" project, http://digitalduchemin.org). Both institutions have been confronted with the need to address issues related to the consistent production of high-level quality corpora, and had to deal with the poor support offered by existing tools. The current, ad-hoc, solution adopted so far takes the form of editorial rules. The approach is clearly unsatisfying and unable to solve the above challenges. Even though we assume that the scores are edited by experts keen to comply with the recommendations, nothing guarantees that they are not misinterpreted, or that the guidelines indeed result in a satisfying encoding. Moreover, rules that are not backed up by automatic validation safeguards are clearly non-applicable in a collaborative context where un-controlled users are invited to contribute to the collections. Managing data quality in such a context is then a major issue.

The document is organised as follows. In Section 2, we briefly introduce the process of data quality management and the motivation for designing the catalog of quality rules presented in this document. In Section 3, we present the multidimensional conceptual model, which is specific to DSL data, that we defined in order to classify the quality rules. Sections 4, 5 and 6 compose the catalog of data quality rules, categorized in these three sections according to the conceptual model above mentioned. The concrete implantation and the evolution of the catalog are discussed in Section 7. We conclude this work in Section 8.

Data quality management

Much published data suffers from quality problems [Zaveri et al., 2016]. It is now well-recognised that these endemic problems may lead to severe consequences, and that managing the quality of data conditions the success of most existing information systems [START_REF] Eppler | A framework for the classification of data quality costs and an analysis of their progression[END_REF]. The last two decades have then witnessed an increasing interest in data quality management, from both a theoretical and a practical point of view.

Data quality is a complex concept, which embraces different semantics depending on the context [Redman, 1996]. It is described through a set of quality dimensions aiming to categorize criteria of interest. Classical quality dimensions are completeness (the degree to which needed information is present in the collection), accuracy (the degree to which data are correct), consistency (the degree to which data respect integrity constraints and business rules) and freshness (the degree to which data are up-to-date). Data quality over a dimension is measured according to a set of metrics that allow a quantitative definition and evaluation of the dimension. Examples of metrics are "the number of missing metadata" for the evaluation of the completeness, and "the number of conflicting duplicates" for consistency. These are simple examples but the literature proposes a large range of dimensions and metrics, conceptualized in quality models [START_REF] Batini | Data and Information Quality: Dimensions, Principles and Techniques[END_REF]. Of course, not all the existing dimensions and metrics may be used for evaluating data quality in a given operational context. An important property concerning data quality is that it is defined as being fitness for use of data, meaning that quality measurement involves dimensions and metrics that are relevant to a given (set of) user(s) for a given usage. User u 1 may be concerned by some quality metrics for a specific usage, by some other metrics for another one, and they can be completely different than those needed by user u 2 .

The literature proposes general methodologies for managing data quality [START_REF] Batini | Methodologies for data quality assessment and improvement[END_REF]. We focus here on quality assessment. Roughly speaking, each assessment methodology includes a quality definition stage and a quality measurement one.

The first stage, the quality definition, consists in eliciting data quality requirements of interest. Concretely, this means choosing a set of quality metrics, and eventually thresholds associated with, that allows to measure in what extend the data fit the quality requirements according to data usages.

Because data quality is fitness for use (depends on the context), defining data quality is not trivial. Dedicated methodological guidelines can be followed like the Goal Question Metric paradigm [START_REF] Basili | Encyclopedia of Software Engineering, chapter The Goal Question Metric Approach[END_REF], which proposes to define quality metrics according to a top-down analysis of quality requirements, whose stages are defined hereafter.

1. For each user (or each user role) and for each of his/her usage of data, conceptual business goals are identified. A business goal specifies the intent of a quality measurement according to a usage of data.

(Example) We make this process more concrete by illustrating it on a simple example. Let us assume that a business user retrieves music scores in order to Perform a given algorithm that searches for similar patterns in the parts of a music score. This is a business goal.

2. Each goal is then refined into a set of operational quality questions, which are a first step towards eliciting the quality requirements.

(Example) For the example, the user may express that the results of his/her study is relevant provided that data is complete enough and that the used algorithm computes relevant results provided that data is accurate enough. Quality questions associated with this use case could then be (QQ1) Does the data contain all needed information? and (QQ2) Are the notes accurate?

3. Each quality question is then itself expressed in terms of a set of quantitative quality metrics with possible associated thresholds (expected values).

(Example) The quality question (QQ1) could be refined into two more precise quality questions. A first "quantitative" quality question could be Is the figured bass available?, measured by the quality metric (QQ1/M 1) defined below.

(QQ1/M1) Availability of the figured bass. (Boolean result).

A second quantitative quality question associated with (QQ1) could be Does each measure cover exactly the expected number of beats?, measured by the quality metric (QQ1/M 2) defined below.

(QQ1/M2) Number of satisfactory measures over the total number of measures.

Assuming that the algorithm is robust up to 10% of malformed measures, then the threshold 0.9 could be associated with the quality metric (QQ1/M2).

Concerning the quality question (QQ2), it could be refined into a quality metric that measures the syntactic accuracy of the notes, meaning that each note should be an existing one (which belongs to the usual range of notes). A third quality metric could then be (QQ2/M 3) defined below.

(QQ2/M3) Number of syntactically accurate notes over the total number of notes.

Measuring the quality metrics enables to (partly) answer to the quality questions, and consequently enables to decide whether the data satisfy the requirements for the given business goal. As soon as data quality metrics are defined, one can consider different processes for their computation, including collaborative ones if the information system makes it possible.

Data quality methodologies of literature are designed at a generic level, leading to difficulties for their implementation in a specific context (operational context and available information system and data). Additional context-dependent quality methodologies are then needed [START_REF] Barrau | Gestion de la qualité des données ouvertes liées -État des lieux et perspectives[END_REF]. In particular, the literature proposes a large range of quality metrics [Batini andScannapieco, 2016, Zaveri et al., 2016] but such metrics are general ones. Quality metrics that are specific to the data of the considered domain are still needed, more specifically in the context of DSL data for which, to our knowledge, only few quality metrics were proposed in the literature (the only work of the literature that proposes some quality metrics for DSLs is [START_REF] Besson | A Methodology for Quality Assessment in Collaborative Score Libraries[END_REF]).

In the following of this document, we propose a catalog of quality rules specific to DSL data, which was elaborated according to the authors experience in maintaining and using DSLs. The idea is that this catalog can serve as a basis in order to elaborate users' quality requirements, by "picking" relevant quality rules according to specific use cases.

Overview of quality rules for DSL

Identifying quality metrics started with the work presented in [START_REF] Besson | A Methodology for Quality Assessment in Collaborative Score Libraries[END_REF], where the authors propose a DSL-specific framework for data quality management. Some DSL-specific quality metrics are attached to this framework. The catalog that we propose in the following generalizes and extends this proposal.

Based on the authors' practical experience and skills, we identified a set of quality rules specific to DSL data. A data quality rule expresses a possible quality requirement. It may be used either (i) in order to tag the data where a quality problem occurs, or (ii) in order to compute a quality metric associated with a score or a corpus. For instance, the quality rule "Each note is syntactically correct, meaning that it is an existing one (which belongs to the usual range of notes)" expresses the fact that having syntactically accurate notes is a data quality requirement. Such quality rule can lead to tag syntactically inaccurate notes that appear in music scores of interest. It can also lead to compute a quality metric in order to assess the quality of a music score according to the rule, like the number of syntactically correct notes over the total number of notes appearing in the score. By extension, quality metrics at the corpus level may easily be defined, for instance the average and standard deviation of the corresponding metric at the score level, computed over the set of scores that belong to the corpus.

In order to improve the understandability and the usability of the quality rules (not only in the catalog but also for the rendering of quality reports designed for the end-users), we classified them into a multidimensional conceptual model. Such a model contains two analysis axes:

• a DSL-specific analysis axis reflects the DSL-specific business point of view of the data, and

• a data quality analysis axis reflects the classical data quality point of view organizing the quality issues according to quality dimensions.

Each axis offers different levels of abstraction. The proposed model is illustrated in Figure 1. The DSL-specific analysis axis (see Figure 1) allows to classify quality rules, according to the DSL specific business point of view. It contains the following elements:

Score content issues This part covers all aspects related to the score content, independently from any encoding or rendering concern. Essentially, it captures the structural organization of a score in parts and streams.

Engraving issues Score engraving denotes the mapping of the score content into a set of staves, which will be used for the rendering of the music score.

Metadata issues

Metadata is data about data, i.e., in our case, any content that annotates either the score content or the score engraving.

The title, subtitle, composer are metadata that annotate a score as whole.

This analysis axis is detailed in [START_REF] Foscarin | GioQoso, an On-line Quality Assessment Tool for Music Notation[END_REF].

The data quality analysis axis (see Figure 1) models the simplest way proposed in the literature in order to classify generic quality issues [START_REF] Batini | Data and Information Quality: Dimensions, Principles and Techniques[END_REF]]. More complex classifications, which possibly contain several dimensions (like e.g. the one proposed in [START_REF] Peralta | Multidimensional Management and Analysis of Quality Measures for CRM Applications in an Electricity Company[END_REF]), could be used. In this case, the DSL specific business axis would just have to be added to the set of axes that belong to the quality model. Each quality rule is classified according to the axes of the model. For instance, the quality rule 4 (Available key signature) belongs to the Completeness position of the data quality analysis axis as it aims to measure the completeness of data, and to the Score content / Stream issues position of the DSL-specific analysis axis as its concerns the voices of the music score content.

Such a model allows to perform, if needed, a multidimensional analysis of the results issued from the data quality assessment, for instance using OLAP-based warehouse technologies [START_REF] Jarke | Fundamentals of Data Warehouses[END_REF]].

In the following, according to the classification above-defined, the quality rules are primary classified into three classes: the rules that concern the content of the music score presented in Section 4, those that concern the engraving of the music score presented in Section 5 and those that concern the metadata attached to the music score presented in Section 6. We now present a review of the quality rules that we identified for each of these categories, refined according to the data quality dimensions above-given, that is to say the completeness, the consistency and the accuracy (syntactic and semantic).

4 Quality rules concerning the score content Quality rules over the content only concern the encoded content of the score, independently from its encoding or rendering. Content issues concern either the structural level or the stream level of the score.

Quality rules concerning the structure of the score content

The structural level concerns the organisation of the score in parts. Structural issues may be studied from the perspective of the completeness, the consistency and the accuracy of the information.

Completeness of the structure The completeness of the structure concerns the availability of the expected parts.

Quality rule 1 (Available parts). Each expected part appears in the music score.

Consistency of the structure The following rule 2 consists in checking the consistency of the parts' length with each other.

Quality rule 2 (Aligned parts). The parts are aligned.

Semantic accuracy of the structure Even if the structure of a music score is consistent, this does not mean that this information is semantically correct, meaning that the information contained in the music score corresponds to the semantically accurate real world information (for instance, a part that does not belong to the real work music score appears, or the parts are aligned but their length is not accurate). Additional quality rules are defined in order to express such a requirement (if computable).

For each relevant information of the structure:

Quality rule 3 (Semantically accurate structure). The information is semantically accurate.

The semantic accuracy rule concerning the structure is usually rather complex to implement because its necessitates to compare the encoded value with a trustable accurate reference like another reliable source or with a real world value given by a business expert. (Another reliable source or a business expert resources that are rarely available...)

Quality rules concerning the stream of the score content

For each part, the stream (notes) level is considered. The quality issues concerning the streams deal either with the pitch or the rhythm (presented together here but can be separately considered if needed), or the lyrics.

Quality rules concerning the pitch and the rhythm

The content of a music score is a complex information. Much quality rules may be associated to such data, that refer to quality problems according to the completeness, the syntactic accuracy, the consistency and the semantic accuracy of data. These quality dimensions are respectively addressed hereafter.

Completeness according to the pitch and the rhythm According to the completeness of data, several rules may the thought of, concerning the figured bass and the notes.

Quality rule 4 (Available key signature). The key signature is defined.

Quality rule 5 (Available time signature). The time signature is defined.

Quality rule 6 (No missing beat). Each measure is complete, meaning that it covers at least the number of beats defined by the time signature (if not then a note could be missing).

Of course, the rule 6 can be computed only if the time signature is available3 . In the following, we consider that the availability of the elements mentioned in a quality rule is an obvious prerequisite to the computation of the rule.

Quality rule 7 (Ornaments). The performance indications (appoggiaturas, slurs, articulation symbols, ...) are uniformly present.

Syntactic accuracy according to the pitch and the rhythm Even if an information is available, checked by the quality rules dealing with the completeness dimension, this does not mean that the provided information is syntactically accurate. The following rules go further in the inspection of the quality of this information, by checking if each provided information belongs to its respective usual ranges (belong to the intended vocabulary).

A first rule consists in checking if the document respects the encoding format that it is supposed to, meaning that it satisfies the schema associated with its encoding format. For instance, if the document is declared as being a MEI document then it has to respect the MEI standard.

Quality rule 8 (Validity w.r.t. the encoding format). The music score respects the encoding format.

The encoding formats still offer a large degree of freedom. If they relatively constraint the structure of the document (tags and their arrangement), they do not precisely control the domain of range of the information embedded in the tags, known as the syntactic accuracy of the information. Then complementary quality rules must be defined in order to control the syntactic accuracy of the voices.

Quality rule 9 (Syntactic accurate key signature). The key signature belongs to the usual range of key signatures.

Quality rule 10 (Syntactic accurate time signature). The time signature belongs to the usual range of time signatures.

Quality rule 11 (Syntactic accurate of the notes). Each note is syntactically correct, meaning that it is an existing note (which belongs to the usual range of notes).

Quality rule 12 (Syntactic accurate slur). Each slur is syntactically accurate, at least with a start note and an end one that belong to the same part. Slurs do not overlap on a same voice.

Quality rule 13 (Syntactic accurate appoggiatura). Each appoggiatura is syntactically accurate, meaning that, at least, it forms a second interval with the note it prefixes.

Quality rule 14 (Syntactic accurate chord). A chord contains at least two notes.

Let us note that the above rules, which can be relatively easily computed, only control the syntax of the information but do not check the semantic accuracy that would consist, for instance for an instrument associated with a voice, in checking that the provided instrument is the real world accurate one associated with the voice. Consistency rules, given below, are a step towards the detection of semantically inaccurate data. They make it possible to identify suspect data.

Consistency according to the pitch and the rhythm The consistency rules check the consistency of the voices w.r.t. other information available in the music score, for instance the instrument associated with the voices, the key or the time signatures.

A first set of rules consists in expressing the adequacy of the number of beats that appear in a measure w.r.t. the time signature defined for the part the measure belongs to. The following rules may express quality requirements according to this adequacy. These versions may be contradictory or overlapping because they express different points of view for the consistency. The relevant version has to be chosen by the user according to its use case.

Quality rule 15 (Complete measure). Each measure is complete (covers at least the number of beats defined by the time signature).

Quality rule 16 (Non-overflowing measure). No measure overflows (each measure covers at most the number of beats defined by the time signature).

Quality rule 17 (Accurate number of beats in the measure). Each measure covers exactly the number of beats defined by the time signature.

The rule 17 (Accurate number of beats in the measure) expresses the conjunction of the rule 15 (Complete measure) satisfaction and the rule 16 (Non-overflowing measure) satisfaction.

In some cases, more especially in the case of research-based study of early music, the intent of the composer has to be encoded as faithfully as possible. This means that the encoding must reflect as possible the rendering of the initial music score handwritten by the composer. In this situation, it is not uncommon to see a music note whose beats belong to two adjacent maesures. When musicologists analyse early music, this is not considered as being a quality problem (on the contrary). In order to fit this requirement, a relaxed version of the rule 17 is defined in the rule 18.

Quality rule 18 (Accurate number of beats w.r.t. a frame of measures). Each frame of N measures respects the number of beats defined in the time signature (where N is given as a parameter of the quality rule). More formally, for each measure M, if the measure M does not strictly cover the number of beats defined in the time signature (i.e. the measure M does not satisfy the rule 17) then there is a frame of N adjacent measures including the frame M such that the number of beats of the frame is N times the number of beats defined by the time signature (i.e. the global frame respects the time signature).

More complex variants of these rules, tolerant to appoggiaturas and acciaccatura (which may not be taken into account in the number of beats of the measure), could be defined.

Each note that appears in a part is associated with an musical instrument or a voice by extension. The following rules expresses the consistency of the note w.r.t. the instrument that has to play it.

Quality rule 19 (Notes in instrument tessitura). Each note of a part belongs to the tessitura of the instrument or voice that is associated with the part.

If the rule 19 is not satisfied then this means that either some notes are inaccurate (those that do not belong to the scope defined by the instrument tessitura), or (non-exclusive) that the instrument is inaccurate.

The information of the instrument associated with a part allows to define some other interesting consistency rules.

Quality rule 20 (Chords composition w.r.t. the instrument). If a chord contains two occurrences of the same note, then the instrument allows to play it (a string instrument can play such a chord while most of the wind instruments cannot).

If the rule 20 is not satisfied then this means that either the chord is inaccurate, or (non-exclusive) the instrument is inaccurate.

Semantic accuracy according to the pitch and the rhythm Even if the information of a music score is consistent, this does not mean that this information is semantically correct, meaning that the information contained in the music score corresponds to the semantically accurate real world information. Additional quality rules are defined in order to express such a requirement (if computable).

Quality rule 21 (Semantically accurate key signature). The key signature is semantically accurate.

Quality rule 22 (Semantically accurate time signature). The time signature is semantically accurate.

Quality rule 23 (Semantically accurate voices). Each element of the voices (note, slurs, articulations) is semantically accurate.

Semantic accuracy rules are usually rather complex to implement because they necessitate to compare the encoded value with a trustable accurate reference like another reliable source or with a real world value given by a business expert. (Another reliable source or a business expert resources that are rarely available...)

It is worth noticing that some rules are interdependent. For instance, if an element respects the rule 21 (Semantically accurate key signature) then, by definition, it respects the rule 9 (Syntactic accurate key signature), and then intrinsically respects the rule 4 (Available key signature). By contraposition, if an element does not respect the rule 4 (Available key signature) then it does not respect the rule 9 (Syntactic accurate key signature) and by transition does not respect the rule 21 (Semantically accurate key signature).

Quality rules concerning the lyrics

Like the other quality rules, the rules concerning lyrics apply only if needed and, of course, only concern vocal music.

Completeness of the lyrics The completeness rule consists in checking the availability of lyrics.

Quality rule 24 (At least a lyric per note). A lyric sequence is associated with each (expected) voice.

Quality rule 25 (At least a lyric per note). For each available lyric sequence, a lyric element is associated with each note.

The rules 24 and 25 concern only the availability of lyrics. The lyrics' values are controlled by other quality rules.

Syntactically accuracy of the lyrics The following rules go further in the inspection of lyrics quality, by checking their syntax.

Quality rule 26 (Single lyrics).

There is at most one lyric element associated with each note.

A more constrained version of the rule 26 is the rule 27.

Quality rule 27 (Singable lyrics). Each lyric element associated with a note is singable (each lyric element is a syllable).

Quality rule 28 (Consistent numbering of the verses). The numbering the verses is consistent. More formally, the rule is defined by a recursive definition composed of the two (sub)rules (R1) the first verse has number 1 and (R2) for each other verse, if the verse has number n (with n ≥ 2) then it occurs after the verse n -1.

Consistency of the lyrics Even if a lyric is syntactically correct, this does not implies that it is semantically accurate. Like for the voices discussed before, the semantic accuracy is difficult to control. A first step towards controlling accuracy is to express consistency rules that allow to identify semantically suspect values.

Quality rule 29 (Lyrics associated with note). Each lyric element is associated with a note (the lyrics are consistent with the notes).

Semantic accuracy of the lyrics Even if the information of the lyrics is consistent, this does not mean that this information is semantically correct, meaning that the information contained in the music score corresponds to the semantically accurate real world information. An additional quality rule is then defined in order to express such a requirement (if computable).

For each relevant information of the lyrics: Quality rule 30 (Semantically accurate lyric elements). The information of the lyrics is semantically accurate.

Such a semantic accuracy rule is usually rather complex to implement because its necessitates to compare the encoded value with a trustable accurate reference like another reliable source or with a real world value given by a business expert.

5 Quality rules concerning the engraving Score engraving denotes the mapping of the score content into a set of staves according to engraving rules. The engraving rules take a score content, determine the number of staves, allocate parts to staves, and develop the stream representation on each staff. The score engraving issues concern either the organization of the staves, or the staff parameters or the staff layout.

We consider that this quality facet concerns the consistency of data (the result produced by the engraving step may be consistent according to the score content and the engraving rules). Semantic accuracy of the engraving Of course, the semantic accuracy may also be checked.

Consistency of the engraving

For each relevant information of the engraving issue:

Quality rule 37 (Semantically accurate engraving). The engraving information is semantically accurate.

6 Quality rules concerning the metadata Much metadata may be attached to a music score (see for instance the MEI guidelines describing the MEI header of a document [Music Encoding Initiative Board, 2016]). The quality rules below deal with some classical relevant metadata. Quality requirements could concern the availability of metadata information, and possibly their accuracy (rule 49 if computable).

Completeness of the metadata

Quality rule 38 (Available title). The title of the music score is available.

Quality rule 39 (Available composer). The composer of the music score is available.

Quality rule 40 (Available date). The date of creation of the music score is available.

Quality rule 41 (Available opus reference). Each music score belongs to an opus (a corpus). This reference is available in metadata.

Quality rule 42 (Available copyright). The copyright of the music score document is available.

Quality rule 43 (Available author). The author (producer) of the numeric music score document is available.

Quality rule 44 (Available date). The date of production of the numeric music score is available.

Quality rule 45 (Available instruments

). An instrument is associated with each part.

Syntactic accuracy of the metadata

Quality rule 46 (Syntactic accurate instrument/voice). Each instrument/voice associated with a part is syntactically correct (is an existing instrument/voice).

Such a rule may be automatically computed by checking the occurrence of each instrument/voice in a predefined dictionary or nomenclature (a local repository or a distant source like in an open encyclopedia). Accepted instrument/voices and their number may by restricted to a given subset for specific works.

Consistency of the metadata

Quality rule 47 (Known instrument at the creation). Each instrument existed at the date of creation of the music score.

If this rule is not satisfied, then this means that either the date of creation is inaccurate or (non-exclusively) the instrument is inaccurate. This rule then also appears in the quality rules concerning the content for checking the instrument.

Quality rule 48 (Known instrument by the composer). Each instrument existed during the period of life of the composer.

If this rule is not satisfied, then this means that either the composer is inaccurate or (non-exclusively) the instrument is inaccurate. This rule then also appears in the quality rules concerning the content for checking the instrument.

Semantic accuracy of the metadata For each relevant metadata information:

Quality rule 49 (Semantically accurate metadata). The metadata information is semantically accurate.

7 Evolution of the catalog, the NEUMA platform

The Neuma platform [START_REF] Rigaux | The Design and Implementation of NEUMA, a Collaborative Digital Score Library -Requirements, architecture, and models[END_REF] is a digital library devoted to the preservation and dissemination of symbolic music content (scores). The corpora of Neuma are publicly available, on open access at http://neuma. huma-num.fr. Some of the quality rules presented in the previous sections are currently being implemented in the Neuma platform in the form of a quality module [START_REF] Besson | A Methodology for Quality Assessment in Collaborative Score Libraries[END_REF] that detects quality problems in the data and tags them [Si-Said Cherfi et al., 2017a[START_REF] Cherfi | Formalizing Quality Rules on Music Notation ? an Ontology-based Approach[END_REF]. A graphical user interface allows their visualisation, as illustrated in Figure 2. In such an interface, the user chooses a music score whose quality has to be checked, her/his data problems of interest (in the right frame in Figure 2). After the quality module processing, graphical elements appear in the form of an overprinting layer on the layout of the music score (the coloured points in Figure 2) in order to report identified quality problems.

The set of quality rules that we proposed is obviously not exhaustive. New quality rules are regularly discovered and added to the framework. Refinements of the quality model that allows to classify the quality rules are also discussed. The catalog is then subject to evolutions and enrichments.

An up-to-date version of the quality metrics implemented in the Neuma platform is available at http://neuma.huma-num.fr/quality (in the right frame of the interface, see Figure 2). In this document, we consider the problem of data quality management of encoded music scores in DSL.

After a brief state of the art of general data quality management methodologies, we highlighted the fact that context-dependent data quality concepts are missing for the real live implementation of these methodologies.

We then proposed a catalog of quality rules that are specific to DSL data. The quality rules were exhibited according to the authors experience in maintaining and using DSL. The catalog can serve as a basis in order to elaborate users'quality requirements, by choosing relevant quality rules according to specific use cases. In order to classify the rules, we proposed a specific taxonomy that mixes the classical data quality point of view that organises quality rules/metrics according to quality dimensions and a business vision that introduces supplementary DSL-dependant levels in the taxonomy. Some rules of the catalog are implemented in the Neuma platform [START_REF] Rigaux | The Design and Implementation of NEUMA, a Collaborative Digital Score Library -Requirements, architecture, and models[END_REF], in the form of an open access quality module (see [Si-Said Cherfi et al., 2017a], [START_REF] Cherfi | Formalizing Quality Rules on Music Notation ? an Ontology-based Approach[END_REF] and [START_REF] Foscarin | GioQoso, an On-line Quality Assessment Tool for Music Notation[END_REF] for details).

This catalog is a basis. We believe that it is not static as other quality rules can be thought of. New contributions should enrich this framework soon.

[ Zaveri et al., 2016] Zaveri, A., Rula, A., Maurino, A., Pietrobon, R., Lehmann, J., andAuer, S. (2016). Quality assessment for linked data: A survey. Semantic Web, 7(1):63-93.

Figure 1 :

 1 Figure 1: Two-dimensional model for classifying quality rules

  Concerning the organization of the staves, two quality rules may the thought of. Quality rule 31 (Validity of the staff order). The staff order is valid. Quality rule 32 (Number of parts per staff). Each staff contains the expected number of parts. Concerning the staff parameters, two quality rules may the thought of. Quality rule 33 (Validity of the key signature). The key signature is valid. Quality rule 34 (Validity of the clef). The clef signature is valid. Concerning the staff layout, two quality rules may the thought of. Quality rule 35 (Validity of the duration). The duration is valid. Quality rule 36 (Validity of the beaming). The beaming is valid. These rules can be checked by automatic procedures based on the analysis of the music score content [?].

Figure 2 :

 2 Figure 2: Visualization of quality problems in the Neuma platform

Institut de Recherche en Musicologie, http://iremus.cnrs.fr.

Centre d'Etudes Supérieures de la Renaissance, http://cesr.univ-tours.fr.

The rule also appears in the consistency dimension as it measures the consistency of the information available in the time signature with the number of beats that belong to each measure.

Acknowledgements

This work has been funded by the French National Center for Scientific Research (CNRS) under the défi Mastodons GioQoso [GioQoso, 2016].

List of quality rules


Hannah Badier
email: hannah.badier@ensta-bretagne.org

Jean-Christophe Le Lann
email: lelannje@ensta-bretagne.fr

Philippe Coussy
email: philippe.coussy@univ-ubs.fr

Guy Gogniat
email: guy.gogniat@univ-ubs.fr

Transient Key-based Obfuscation for HLS in an Untrusted Cloud Environment

Keywords: High-Level Synthesis, Cloud, IP theft, Obfuscation

Recent advances in cloud computing have led to the advent of Business-to-Business Software as a Service (SaaS) solutions, opening new opportunities for EDA. High-Level Synthesis (HLS) in the cloud is likely to offer great opportunities to hardware design companies. However, these companies are still reluctant to make such a transition, due to the new risks of Behavioral Intellectual Property (BIP) theft that a cloudbased solution presents. In this paper, we introduce a keybased obfuscation approach to protect BIPs during cloud-based HLS. The source-to-source transformations we propose hide functionality and make normal behavior dependent on a series of input keys. In our process, the obfuscation is transient: once an obfuscated BIP is synthesized through HLS by a service provider in the cloud, the obfuscation code can only be removed at Register Transfer Level (RTL) by the design company that owns the correct obfuscation keys. Original functionality is thus restored and design overhead is kept at a minimum. Our method significantly increases the level of security of cloud-based HLS at low performance overhead. The average area overhead after obfuscation and subsequent de-obfuscation with tests performed on ASIC and FPGA is 0.39%, and over 95% of our tests had an area overhead under 5%.

I. INTRODUCTION

Today's hardware designs have reached a fantastic degree of complexity. To sustain this industrial challenge, design flows are increasingly distributed, with companies relying on third parties for IP development, manufacturing and testing. The recent surge in cloud computing capabilities offers new opportunities to distribute design even further, by outsourcing complex computations to dedicated Software as a Service (SaaS) platforms. In the next years, Electronic Design Automation (EDA), which is compute-intensive, is likely to benefit directly from such services. In particular, HLS lends itself to being offered as a cloud-based service. However, broad adoption by the industry is slowed down by legitimate security concerns about IP theft [START_REF] Bailey | EDA In The Cloud[END_REF]. Indeed, HLS in the cloud services have to be considered as untrusted platforms, possibly vulnerable to insider threats as well as outside attacks and security breaches. A company using such a service would have to trust the platform with its high-level source code. While the files could be encrypted during transfer to prevent Man-In-The-Middle (MITM) attacks, HLS using industry-standard products such as Xilinx Vivado HLS or Catapult from Mentor Graphics can only be performed on valid, plain-text code, meaning that the files have to be decrypted on the server. This leads to vulnerable points both before and after HLS, as depicted on Fig. 1, where Behavioral Intellectual Property (BIP) could be stolen. Fig. 1: HLS in the cloud design flow with vulnerable points Our long-term goal is to enable hardware design companies to safely use a cloud-based HLS service, without having to entrust their security to the service provider. To achieve this, we aim at preventing BIP theft and reuse, before and after HLS in a cloud-based context. These security measures should be applied on the design company's side at algorithmic level, and should not disrupt the HLS process or permanently alter the functionality of the code. Our approach should also have a negligible impact on design performances.

Obfuscation is widely used as a means to protect intellectual property in software and hardware design. According to the definition in [START_REF] Collberg | A taxonomy of obfuscating transformations[END_REF], an obfuscated program is functionally equivalent to the original but more difficult to understand. In this paper, we propose to combine software obfuscation techniques that make the code harder to understand with keybased hardware obfuscation techniques that prevent correct execution and thus reuse of the code. If the design company can provide the correct obfuscation keys, our process removes obfuscation code at register transfer level (RTL) and restores original functionality with low design overhead. In particular, the main contributions of this paper are the following:

• We consider a hardware design flow where HLS is used as a cloud service and where security does not rely on trust in the cloud provider. • We propose a novel low-overhead method for BIP protection through key-based obfuscation. • We offer a fully automated toolset, KaOTHIC, for obfuscation and de-obfuscation.

This paper is organized as follows. Section II discusses works related to IP protection and presents background on obfuscation. In Section III, the proposed approach is presented in detail. Section IV contains the experimental setup and discusses the results. Conclusions and information about future work are provided in Section V.

II. RELATED WORK AND BACKGROUND

A. IP Protection

Due to the growing issue of IP infringement, several IP protection techniques have been studied, at different design steps and different abstraction levels. Most of them aim at protecting IP during manufacturing, which is nowadays usually outsourced to third-party foundries. Watermarking and split manufacturing (e.g. [START_REF] Kirovski | Intellectual Property Protection by Watermarking Combinational Logic Synthesis Solutions[END_REF] [4] [START_REF] Garg | Split Manufacturing[END_REF]) have been widely studied. Many solutions for obfuscation-based approaches have also been proposed. Some focus on low-level techniques based on hardware properties and applied at layout level to prevent netlist extraction, for example by using Physical Unclonable Functions (PUFs) or camouflage gates. Several techniques for IP protection through obfuscation at gate level by adding extra gates to the circuit have also been proposed. However, these techniques do not protect so-called soft IPs at register transfer level (RTL). Several methods have been proposed to add keybased obfuscated to VHDL or Verilog code, either directly at RTL or during HLS. In [START_REF] Chakraborty | RTL Hardware IP Protection Using Key-Based Control and Data Flow Obfuscation[END_REF], a mode-control finite state machine (FSM) is added to the design, so that the circuit only functions in normal mode if the correct key sequence is known. In [START_REF] Lao | Obfuscating DSP Circuits via High-Level Transformations[END_REF] and [START_REF] Sengupta | DSP Design Protection in CE through Algorithmic Transformation Based Structural Obfuscation[END_REF], high-level transformations are used to protect digital signal processing (DSP) circuits. In [START_REF] Islam | High-Level Synthesis of Key Based Obfuscated RTL Datapaths[END_REF] and [START_REF] Pilato | TAO: Techniques for Algorithm-Level Obfuscation during High-Level Synthesis[END_REF], keybased obfuscation is added during HLS by extending the HLS process. In these works, the goal is to obtain obfuscated RTL and to provide protection during manufacturing or for thirdparty vendors of IPs, and HLS is considered to be a trusted design step. However, they do not protect behavioral IPs before and during HLS.

In [START_REF] Veeranna | Efficient Behavioral Intellectual Properties Source Code Obfuscation for High-Level Synthesis[END_REF], a heuristic approach for optimal obfuscation of behavioral IPs is presented. It is based on a study of the impact of commercial or free software obfuscators on HLS quality of results. This method focuses on how to optimally apply software obfuscation techniques to code before HLS and does not modify functionality of the code. While it can increase the difficulty of an attacker to understand stolen BIP, it does not prevent "black-box" usage, where the BIP is directly reused or critical information about it is found by simply analyzing its inputs and outputs. In our approach, we aim at preventing both IP theft and reuse. To achieve this, we rely on key-based obfuscation techniques. However, the methods presented in [START_REF] Veeranna | Efficient Behavioral Intellectual Properties Source Code Obfuscation for High-Level Synthesis[END_REF] are compatible with our approach, which means that both can be jointly used to increase the level of protection.

To the best of our knowledge, there is no work yet using key-based obfuscation to protect BIPs in a cloud-based context.

B. Software Obfuscation

The taxonomy given in [START_REF] Collberg | A taxonomy of obfuscating transformations[END_REF] distinguishes between three different types of software obfuscation. "Layout" obfuscation affects human readability of the code, while "data" and "control flow" obfuscation respectively modify data (for example encoding) and control flow (for example by splitting functions). These techniques are commonly gathered under the name of code-oriented obfuscation, as opposed to model-oriented or cryptographic obfuscation, which aims at protecting the code in a formally verifiable way through cryptographic operations. While cryptographic obfuscation offers a provably secure way of protecting intellectual property, it is not usable in a dayto-day context yet [12] [13]. In this work, we focus on codeoriented obfuscation techniques. We consider a hardware design company desiring to synthesize a design based on an innovative algorithm by using a cloud-based HLS service. Complete security of this service cannot be guaranteed and the design company faces the risk that a malicious adversary gains access to its C level code. This adversary could be either an insider of the HLS service provider or an outside attacker. Following risks must be considered in case of an attacker stealing the code:

III. PROPOSED APPROACH

1) Espionage: the attacker gains information about what type of algorithms or applications the design company is working on. 2) BIP theft: the attacker is able to understand the algorithm and can counterfeit or modify it. 3) Black-box usage: the attacker does not completely understand the algorithm, but can execute the code and reuse it. Because we cannot prevent code theft on the HLS provider's side, our approach aims at minimizing the previously enumerated risks. We secure a traditional HLS design flow by adding two additional steps on the design company's side, before and after HLS, as illustrated on Fig. 2. Protection is thus transient. The tool implementing the approach we propose is opensource, which means that security cannot rely on secrecy of the process. To prevent an attacker from reproducing obfuscation results and thus gaining valuable information on how to deobfuscate, we aim at introducing elements of randomness wherever possible in the obfuscation flow.

The first step, detailed in Section III-B, consists in obfuscating a given C code, thus making it harder to understand. Key-based obfuscation is used to prevent black-box usage. The obfuscated C code is then sent to the cloud provider, where HLS is performed. The resulting RTL code, which is automatically also obfuscated, thanks to the code transformations we apply, is returned to the design company. If the RTL code is directly synthesized at this point, the resulting circuit will not function correctly because the logic added by obfuscation is also synthesized. This is why de-obfuscation by key injection, detailed in Section III-D, is required as a second step. De-obfuscating with the correct keys both ensures that the original functionality is recovered and that, once the circuit is synthesized, the overhead is kept at a minimum.

B. Obfuscation Flow

Fig. 3: Obfuscation flow Fig. 3 shows the obfuscation flow we propose. The inputs are the original source files written in C language that must be obfuscated and the obfuscation level. The outputs are the obfuscated code and a list of obfuscation keys. The process can be parameterized: the user can choose which obfuscation techniques to apply and in what order, as well as the desired obfuscation level, which is defined as the percentage of obfuscated expressions.

The flow is composed of the following steps (see Fig. 3):

1) The C files are parsed and an Abstract Syntax Tree (AST) is generated; 2) A visitor pattern is used to traverse the AST and collect the list of AST nodes that are potential obfuscation candidates; 3) Based on the obfuscation level, nodes are randomly selected among the candidates; 4) One random key per selected node is generated; 5) Each selected node is obfuscated using the technique presented in the next Subsection and replaced in the original code; 6) The key variable names are added as inputs to the main function;

7) The obfuscated code is returned. For a higher level of security, a different key is used for each obfuscated node. This ensures that an adversary guessing or discovering the value of one key does not compromise the secrecy of the other keys. To avoid replay by an attacker, the selection of candidate nodes is also done randomly.

The implemented transformations at this point include control flow flattening, control flow splitting and encoding of literals. Several other techniques can be added at a later point to increase obfuscation resistance and security. A detailed presentation of how control flow splitting is realized can be found in the next Section.

C. Control Flow Splitting by Key-based Predicate Insertion

Fig. 4: Simplified example of a combinational DFG before and after obfuscation. In this example, the correct code only gets executed if "42" is given as input key.

This technique is based on ideas presented in [START_REF] Collberg | A taxonomy of obfuscating transformations[END_REF]. The control flow is split at certain points in the code by adding a predicate. A branch with bogus code is then inserted. This bogus code strongly resembles the original code, in order to increase obfuscation stealth by making it harder for an attacker to distinguish original from bogus code, but presents enough differences to the real code to modify the circuit's behavior. Usually opaque predicates, introduced in [START_REF] Collberg | Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs[END_REF], whose values are known at obfuscation time but difficult to evaluate for an attacker, are used. In our case, we use predicates depending on keys that are inputs to the circuit. An example of this obfuscation technique is presented in Fig. 4.

1) Predicate: For now, the predicate tests an input value against a constant. Depending on how this test evaluates, the real or the bogus code is executed. In this simplified example (Fig. 4), the input is compared to the value "42". If the test is True, the correct code branch is executed. If any other value is given as input, the bogus code is executed. During obfuscation, we randomly assign either the original code branch or the bogus one to execute when the predicate is true. For an attacker, there are thus 2 possibilities to test. Either the input key is equal to the constant, or it is not. For N obfuscated expressions, there are thus N keys and 2 N possibilities to test in a brute-force attack to recover the original code. We assume that a high number of expressions will be obfuscated using this technique in each source code, resulting in a high number of possibilities to test for an attacker. Difficulty of a brute-force attack can be easily increased by adding more than just one bogus branch per obfuscated expression, with the key input being tested against several constant values. where op is a bitwise or arithmetic operator. For each selected binary expression, a similar bogus expression is created. The bogus binary expression contains the same expressions as the original code but a different operator. For example:

a = b + c =⇒ a = b -c
The choice of the operator added in the bogus expression has some importance in improving security but also in reducing overhead. The chosen operator has to be computationally similar to increase stealth (a bitwise operator cannot be added for an operation between two integers for example) and of equal or lower complexity. For example, for a PLUS or a bitwise AND operator in the original expression, we respectively add a MINUS or a XOR operator in the bogus expression.

D. De-obfuscation by Key Injection

In our proposed design flow, after HLS is performed in the cloud, the design company receives obfuscated RTL code. In order to limit design overhead and to allow correct execution of the code, the code needs to be de-obfuscated (see Fig. 2). At RTL level, the keys that were added as arguments to the main function in C, are now inputs of the top component. With the obfuscation method used in our framework, the RTL code has, for each obfuscated expression, a comparison between the key signal and the expected value. Depending on the result of this comparison, a multiplexer then selects which operator to use in the binary expression.

1) Naive key injection: A first approach could consist in injecting the keys externally, at the circuit interfaces, by creating a new top-level component that explicitly states the values of the obfuscation keys and injects them into the kernel.

During logic synthesis, the following behavior is expected: if the correct keys are injected, through constant propagation the predicates should evaluate correctly, and the bogus code branches should be removed by logic simplification. The circuit would then function correctly and the design overhead compared with the original, unobfuscated circuit should be close to null.

However, this procedure is only effective if the data path added by obfuscation is fully combinational. In practice, the scheduling performed during HLS results in most cases in a sequential data path. More precisely, the comparison between the key input and its expected value is often scheduled in a different clock cycle than the obfuscation multiplexer (Fig. 5(b)), which controls whether to use the original or the bogus operator. In this case, the result of the key comparison is stored in a dedicated register ("reg1" on Fig. 5(b)). The value of this register depends not only on the key inserted in the circuit, but also on the state of the FSM responsible for controlling the scheduling. This means that even if the result of the key comparison is fixed by injecting the keys, the value of the register is not a constant and is unknown by the logic synthesis tool. The register cannot be removed during synthesis, and the bogus code, which is tied to this register, is not removed either. The register acts as a barrier against logic simplification. While the circuit is functionally correct, the remaining bogus code (Fig. 5(c)) causes a significant design overhead.

2) Proposed key injection:

We propose a second approach to circumvent the previously presented issue and to deobfuscate more thoroughly. Instead of injecting the keys externally and relying purely on logic collapsing, we locally modify the RTL code itself by performing the following operations. For each obfuscated expression, we compare the key input and its expected value. The result of this comparison is computed as 0 or 1 (0 on the example Fig. 5(d)). The aforementioned barrier register thus depends on a constant (0 or 1) and the state of the controller. While logic synthesis alone cannot bypass this register, our approach enables us to know what value should command the obfuscation multiplexer. This allows to completely remove the key comparison and the associated (if any) register in the RTL code, and instead directly inject this value into the command of the obfuscation multiplexer. Because the multiplexer command is forced, the synthesis tool is able to deduce which operator must be used and thus which code branch to remove. With this approach, functionality of

IV. EXPERIMENTAL STUDY A. Experimental Setup

We implemented our approach in a dedicated toolset: KaOTHIC (Key-based Obfuscating Tool for HLS in the Cloud). KaOTHIC is written in Python and uses a series of fully automated steps for obfuscation and de-obfuscation. To parse the original C files before obfuscation, an in-house compiler front-end is used. In order to evaluate our obfuscation approach, 6 benchmarks from MachSuite [START_REF] Reagen | MachSuite: Benchmarks for Accelerator Design and Customized Architectures[END_REF] and CHStone [START_REF] Hara | Proposal and Quantitative Analysis of the CHStone Benchmark Program Suite for Practical C-based High-level Synthesis[END_REF] were used: advanced encryption standard (AES), adaptive differential pulse code modulation encoder (Adpcm), optimal sequence alignment algorithm (Needwun), mergesort algorithm (Merge_sort), simplified Mips processor (Mips) and three-dimensional stencil computation (Stencil3d).

We performed a series of tests for each benchmark by obfuscating it with varying obfuscation levels from 5 to 100%. For each test, 4 logic syntheses were performed: the original design, the obfuscated design, the naively de-obfuscated design and the fully de-obfuscated design. This allowed us to compare design overhead of the different approaches.

For HLS we used Xilinx Vivado HLS. Logic synthesis was performed with Synopsys Design Compiler, using the Synopsys SAED 90nm educational library for ASIC, as well as with Xilinx Vivado for a Nexys 4 DDR Artix-7 FPGA board. It is important to note that DSP blocks were disabled for FPGA logic synthesis in order to restrict our surface analysis to LUT and register count.

B. Results and analysis

Using the previously presented method and KaOTHIC tool, we performed a total of 164 tests on ASIC and FPGA.

The average runtime overhead for HLS is negligible (under 5%). In over 95% of our tests, the area overhead is below 5%, which we consider an acceptable overhead threshold. On ASIC, the delay overhead is below 5% in 91% of the tests. In respectively 80% and 60% of the tests, the register and delay overhead on FPGA are also below 5%. Fig. 6 represents the distribution of the 164 test results in terms of area and delay overhead for ASIC, and in terms of LUT, register and delay overhead for FPGA. Additionally, the tables on Fig. 7 show the detailed average results for each benchmark, without de-obfuscation and with both deobfuscation approaches. The results indicate that design overhead is high when no de-obfuscation is performed. When using a naive de-obfuscation approach, overhead slightly decreases. Finally, overhead can be strongly reduced by smartly deobfuscating the circuits through our proposed key injection approach. This proves that we are successfully able to remove the code added during obfuscation. To ensure the correctness of our obfuscating method, i.e. to verify that the obfuscated code has the same functionality as the original code, we simulated the code at RTL level using GHDL, an open-source VHDL compiler. Simulation results show that the original code without obfuscation and the obfuscated code after correct key injection have the same behavior, while obfuscated code with wrong keys injected does not behave correctly. Our approach is thus able to safely remove the additional code without jeopardizing the functionality of the circuit.

In some test cases (e.g. Mips on ASIC), we obtained a negative overhead. This may happen when the increased code size forces the HLS tool to make different optimization choices, thus sometimes resulting in a smaller design than the original one. The small remaining overhead (e.g. Stencil3D) is in our opinion due to resource sharing and to the impact that the syntax variations created by the obfuscation process have on HLS tools. On FPGAs, overheads may vary more importantly, while remaining acceptable, because of the components (LUTs, registers, interconnects...) used to make these devices reconfigurable and the associated logic synthesis techniques. Further work will focus on better mastering overheads to offer a quality of results similar to the ASIC ones. Through a series of tests done with obfuscation levels ranging from 5% to 100%, we studied correlation between overhead and obfuscation level. Our results indicate that there is no correlation between obfuscation level and area or delay overhead, as shown on Fig. 8. We can for example note that area overhead varies between approximately -2% and 2%, and does not increase with obfuscation level. These results demonstrate that the maximum level of obfuscation, i.e. 100%, can always be chosen. To evaluate the security of the proposed obfuscation technique, we calculated the cyclomatic complexity. While not a precise indicator of the difficulty of attack, a higher complexity does usually imply that the code is more difficult to understand. Our results show that after obfuscation, the complexity increases on average by 109%. Furthermore, the increase in complexity is positively correlated with the level of obfuscation, see Fig. 9 for an example with Needwun benchmark, which is representative of the results obtained for other benchmarks. Increasing the level of obfuscation can thus be a simple way to improve security without incurring a significant increase in overhead.

Fig. 2 :

 2 Fig. 2: HLS in the cloud design flow secured by obfuscation A. Secure HLS in the Cloud Design Flow

Fig. 5 :

 5 Fig. 5: Illustration of the de-obfuscation process

Fig. 6 :Fig. 7 :

 67 Fig. 6: Histograms of the distribution of tests by overhead

Fig. 8 :

 8 Fig. 8: Average overhead per obfuscation level for all performed tests

Fig. 9 :

 9 Fig. 9: Cyclomatic complexity increase of Needwun source code after obfuscation per obfuscation level

V. CONCLUSIONS AND FUTURE WORK

In this work, we proposed using obfuscation methods to secure BIPs during HLS in a cloud context. Experimental results show that we are able to obfuscate using a key-based technique and to de-obfuscate safely after HLS with minimal overhead. In the future, the very positive first results on ASIC and FPGA encourage us to continue exploring this approach both by trying to optimize and further reducing overall overhead, and by diversifying the obfuscation techniques to achieve a higher level of security. We also plan to work on a more detailed evaluation of security.