ASSERTION SUPPORT IN HIGH-LEVEL SYNTHESIS DESIGN FLOW Aurélien Ribon1, Bertrand Le Gal

ASSERTION SUPPORT IN HIGH-LEVEL SYNTHESIS DESIGN FLOW

Aurélien Ribon

¹

, Bertrand Le Gal

¹

, Christophe Jégo

¹

and Dominique Dallet

¹

1

Université de Bordeaux, Laboratoire IMS, CNRS UMR 5218, IPB, 351 crs de la Libération, 33405 Talence, France

{firstname.lastname}@ims-bordeaux.fr

ABSTRACT

The increasing complexity of System-On-Chip applications increases the challenge of the design task, and specifically the verification process. Assertion-Based Verification is one of the key innovations to simplify RTL verification and facilitate design reuse. However, current design automation tools do not take into account assertions found in behavioral source codes during the High-Level Synthesis (HLS) process. This work focuses on a methodology for automatic detection and transformation of behavioral untimed assertions from a transaction-level description into temporal RTL assertions. This process is introduced as a particular task of a HLS design flow. RTL monitors are generated either in PSL or VHDL language, for simulation purpose.

Therefore, this approach contributes to IP-reuse methodologies as input transaction assertions (checking the correctness of data provided by the system) can be exploited in automatically generated IPs.

Index Terms— ABV, architecture, assertion, design, HLS, IP, monitor

1. INTRODUCTION

The recent fast Integrated Circuit (IC) capacity growth affects not only the scale of current designs, but also their complexity. While it enables efficient architectures to solve today’s computation and communication problems, the cost of reliability has never been so high. Latest studies evaluate that up to 70% of design time is spent in testing and debugging processes [1]. Therefore, a number of verification methodologies have been developed and adopted at the Register Transfer Level (RTL) during the last decades [2].

One of these techniques is called Assertion-Based Verification (ABV) [3]. Assertions are the formal translation of design specifications. ABV consists in designing architectures by embedding assertion statements into the RTL source code. As a consequence, they increase the productivity of system debug and the efficiency of designs.

This approach speeds up the debug process by allowing simulators and formal verification tools to identify errors at their source, or close to their source. This greatly reduces the

tedious task of back tracing errors to their root cause. Thus, bugs that could have gone undetected can be exposed.

Moreover, embedding assertions within the RTL code facilitates the reuse of soft Intellectual Property (IP) blocks by ensuring their proper use in the architecture during simulations. The debug of the integration task is made easier thanks to the identification of errors close to their source.

However, to our knowledge, current Electronic Design Automation (EDA [4,5,6]) tools that automatically generate RTL architectures from behavioral description do not support assertions during their synthesis process. As a consequence, there is no propagation of behavioral assertions to the generated RTL descriptions. This disables any possibility of later assertion-based verification.

In this paper, we explain why we consider that the propagation of Boolean assertions from untimed behavioral descriptions to RTL temporal assertions is of utmost importance. We also propose a methodology that takes into account assertions during the HLS synthesis process. It aims at generating RTL monitors, for simulation purpose only, from two kinds of assertions:

1. The Boolean assertions found in the behavioral untimed description,

2. The temporal assertions implied by some synthesis constraints given by the designer.

Generated monitors are described either as Property Specification Language (PSL, a dedicated RTL verification language) statements or as independent non-synthesizable VHDL processes that act as wrappers around VHDL assertion statements. This way, there is no penalty on the circuit behavior and its performances. Generated monitors are used to enable easier design reuse through the validation of transactions. This methodology is built around the Synthesis-for-Verification [7] paradigm

This paper is organized as follows: section 2 explains the motivation of this work. Section 3 details the different types of assertions supported by this work. The proposed methodology is described in section 4 and theoretically developed in section 5. Finally, experimental results are related in section 6. Last section draws a conclusion and provides some perspectives.

2. MOTIVATION OF THIS WORK 2.1. Assertions and design reuse

Assertions-based verification is an efficient technique when it comes to check component transaction during simulations.

Indeed, assertions can be used as formal contracts to ensure that the data sent to or received by a component follow the specifications. This programming pattern is referred as Design-By-Contract (DbC) [8]. While it has been in use for many years now with success in the software development world, its consideration for hardware design is just emerging. Design-By-Contract approach defines three main assertion constructions, as illustrated in Figure 1:

 Preconditions, which check data sent to the component,

 Postconditions, which validate output data,

 Invariants, which have to be verified at any time.

By following the Design-By-Contract paradigm, a designer can facilitate easily implement its IP into a foreign system. Firstly, preconditions make sure that the foreign system follows the input specifications of the IP. Secondly, the integrator can rely on the postconditions to validate the behavior of the IP. All incorrect data sent to or received by the component is caught by the simulator thanks to assertion points. This behavior heavily facilitates the reuse of IPs in complex systems, by means of more efficient debug task.

Since integrators have to make sure that every integrated IPs are correctly used by the system, well placed assertions defined in the IPs immediately report any bad transaction data during functional simulation. It is similar to software development: function calls can check their passed parameters through assertions, and directly stop the application execution if something wrong is detected.

2.2. High-Level Synthesis and assertion transformation High-Level Synthesis (HLS) tools provide a higher level of

design abstraction [6,7]. Thus, a designer can adapt its design to a wide range of targeted devices and application contexts. Indeed, through the definition of hardware-related constraints such as targeted platform, clock frequency or available hardware resources, a same behavioral description can be used to synthesize different dedicated RTL architectures. Such design flow is illustrated in Figure 2.

We think that Assertion-Based Verification can greatly help HLS processes to generate more robust architectures. It can also facilitate architecture integration into different system hosts. Actually, this methodology is a handshake between a system integrator and a designer:

 Preconditions let the designer be sure that the synthesized architecture is correctly used by the system,

int linearize(int x) { // invariant (1)

assert ( current_mode == LINEAR );

// precondition

assert ( X_MIN <= x && x <= X_MAX );

int k = x * CONST_A + CONST_B;

// internal assertion assert ( k > 0 );

int y = k >> 1;

// postcondition assert ( y > 0 );

// invariant (2)

assert ( current_mode == LINEAR );

return y;

}

Fig. 1. Design-By-Contract constructions

Fig. 2. High-Level Synthesis design flow

 Postconditions and invariants would assure the integrator that the architecture behavior, and indirectly the algorithm specification, is correct and does not suffer any corner- case misconception.

In a theoretical point of view, an assertion defined in the behavioral model could be manually hand-coded into the HLS-generated RTL architecture. But in practice, it is far from being so straight-forward. Indeed, HLS tools usually apply many optimization techniques such hardware resource sharing – merging registers and operators – to be as much as possible resource-efficient. Actually, if a behavioral assertion has to be manually transformed into its RTL counterpart, resource-constrained information is necessary.

Such information would include registers where variables are stored, finite-state-machine states when asserted operations are executed and the execution cycle when the assertion statement must be triggered. Figure 3 illustrates the transformation of an assertion from a behavioral description to its RTL counter-part. More information has to be added during the synthesis process, such as register names and timing data. This information can only be found by reverse- engineering the (few hundreds of thousands) lines of code of the generated architecture or thanks to the HLS tool.

For all these reasons, it is necessary that HLS tools handle the assertions present in the input behavioral models, and automatically transform them in temporal assertions at the RTL level to enable assertion-based verification.

2.4. Related works

To our knowledge, only a few recent works dealing with assertion preservation across multiple abstraction layers have been published. Guarehbaghi et al. [9] propose a system-level assertion language and a methodology to automatically convert them into software or hardware monitors during the synthesis of Application Specific Instruction-set Processors (ASIP). Curreri et al. [10]

transform behavioral assertions into synthesizable monitors through a translation from a behavioral assert statement into an if-then block understandable by the Impulse-C HLS compiler.

Therefore, this work differs from existing ones because it is applicable to virtually every HLS tool and behavioral application, and allows a complete control over the assertion treatments before RTL generation.

3. SUPPORTED ASSERTION TYPES

The presented methodology supports two types of assertions: those stated in behavioral descriptions and HLS implicit assertions. Indeed, assertions stated in behavioral descriptions are not sufficient to monitor the correct behavior of the architecture. In a HLS process, a designer has to make some choices during the definition of the constraint set. Some of them may lead to issues in the behavior of the generated architecture, especially in the case of design-reuse. For instance, architectures processing 8 bit data may have to be connected to a 32 bit system bus. In this case, the consequences of such decisions have to be verified.

Another example would be the monitoring of system hangs or throughput breaks. This verification can be done through the automatic generation of specific assertions in the RTL architecture description. We refer to these assertions as implicit assertions.

Therefore, this work also targets the automatic analysis and generation of some useful implicit assertions.

3.1. Behavioral assertions

No preprocess task is necessary in this case. However, the only requirement is that the HLS compiler let them be part of its internal abstract representation of the behavioral description.

3.2. Implicit checking of input ranges

Some architecture input ports may be limited to specific data value ranges that do not directly map on the port bit-widths.

These ranges are typically used to reduce the resource sizes in the datapath [11]. Therefore, it is implied that input ports never receive data that overflow these ranges. To ensure this constraint, input ranges are retrieved from supplied constraints. Then, an assertion is built for each operation assigned on the constrained input port. These assertions ensure the port magnitude limitation.

3.3. Implicit monitoring of unsafe operators

When constraining any application resource consumption, two cases can be distinguished for internal resource bit- width selection:

 Worst case scenario: register bit-widths grow with the required computations, doubling for each multiplication operation.

 Truncated bit-widths scenario: intermediate results are truncated according to their range estimates. They may also take into account probability density functions for computations that are not reliability critical [11].

Sometimes, they are just set to a same pre-defined arbitrary bit-width.

C++ t[34] = sqrt(2 * x – b);

assert (t[34] < a);

PSL assert always (state = s85) ->

prev(reg136, 63) < prev(input1, 85) Fig. 3. Untimed C++ assertion and its temporal PSL transformation

In a design and reuse context, constraint hypotheses are not always achieved. As a result, truncating intermediate results bit-widths may lead to some unwanted behavior appearing with overflowing operators. Thus, for each operator that may overflow (according to the computed input data ranges), an assertion is generated. This assertion performs the computation implied by the monitored operator and checks if the result is bound to the specified range.

3.4. Implicit constraint of architecture throughput The throughput of the generated architecture is often constrained by the designer. This constraint is used during allocation and scheduling steps. However, even if the synthesized architecture meets the required throughput, some interfaced components may introduce unexpected latencies. For instance, if the architecture input part contains references to FIFOs, then channel behaviors can be unpredictable. As a result, a specific pre-processing is necessary if a throughput is specified. It consists of two different approaches:

 If the generated architecture does not embed interface channels (i.e. FIFOs instantiations are not part of the architecture), an assertion is generated to count clock cycles between first and last states of the state machine.

 If FIFOs are directly part of the architecture, one assertion per FIFO is generated. These assertions check that the is_empty flag of each FIFO component is not raised more than a specific number of times during runtime.

4. PROPOSED METHODOLOGY FOR ASSERTION SUPPORT

The methodology described in this section aims at handling the assertions specified in the previous section. Note that the designer can choose to insert all the implicit assertions, part, or none of them. This methodology is composed of height tasks; each one can be seen as an extension of the conventional HLS tool that modifies the internal abstract representation.

Most High-Level Synthesis tools part their synthesis process into many activities, at least including:

 Compilation: a lexical analysis of the behavioral description. An abstract representation, usually an Abstract Syntax Tree (AST) [12], is generated from the original specification. Various transformations can be applied on it. From this representation, a Control-Data- Flow Graph (CDFG) [13] is built. This graph represents the model data propagation and the operations that have to be performed.

 Resource selection and allocation: resources for the RTL implementation are chosen from available hardware libraries. Moreover, the number of registers and operators

are computed without taking into account hardware reusing.

 Scheduling and binding: operations and data are scheduled according to the allocated resources and time constraints (latency and throughput). Then, CDFG elements are linked to hardware resources.

However, to authors’ knowledge, assertion support is not part of academic and industrial tools. For this reason, assertion support is undefined and they are either skipped, or are treated as common functions and implemented using hardware resources in an unpredictable way. The proposed methodology is a way to get around this limitation. It aims at removing all the assertion branches from the HLS tool internal model but also at implementing them as temporal RTL monitors dedicated to simulation or formal verification.

If assertions were not removed from the internal graph, they would be implemented using hardware resources, and would degrade circuit performances. The steps involved, shown in Figure 4, are as follows:

1. Pre-processing: system implicit assertions are identified according to the supported types described in section 5.1. Corresponding assertion branches for input range checking, operator overflow monitoring and throughput validation are added to the CDFG representation.

2. Assertion branch discovery: the CDFG is analyzed and assertion branches are identified.

3. Assertion branch adaptation: overlapping assertion branches are separated to build a set of independent branches.

4. Assertion branch removal: assertion branches are removed from the graph, and then the HLS process synthesizes the RTL architecture over an assertion-free graph.

5. Binding: hardware information coming from the HLS process after the schedule-and-bind task is used to bind assertion branches to hardware resources.

6. Assertion sorting: assertion execution dates are computed in order to follow the behavioral model defined sequences.

7. Monitor generation: monitors at the RTL level are finally generated from the assertion branches. The monitor description can be either in PSL or VHDL (assertion statements are wrapped into independent VHDL processes).

8. RTL embedding: generated monitors are embedded into the RTL description of the synthesized architecture.

5. THEORETICAL DEVELOPMENT

As previously explained, most HLS tools manipulate abstract representations of application source codes as a directed acyclic graph (DAG). Firstly, a graph is a pair G = (V, A) where V is a set of vertices (also called nodes) and A

is a set of ordered pairs of vertices, called arcs or directed edges. An arc a = (x, y) is composed of a head x and a tail y.

Secondly, as the graph is acyclic, we can define a set of entry nodes E and a set of sink nodes S (see eq. 1).

 

 

 

 n V n V n n n n A 

S

A n n n n V n V n E

























1 1

1

1 1

1

, , ,

: :

, , ,

:

:

(1)

Thirdly, for every node n ∈ V, we define P(n) as the set of every parent of n and C(n) the set of every child of n.

These definitions are formally described in eq. 2.

     

  n  n V  n n  A 

C

A n n V n n P













2 2

1 1

, : :

, :

:

(2)

Finally, we define a set comprising the application primary outputs, referred as Vout. The following sections detail some of the proposed methodology steps.

5.1. Assertion branch discovery

The set of nodes that are part of at least one assertion branch is defined as VA, with VA ⊂ V. This set is illustrated in Figure 5. Similarly, VApure, described in eq. 3, refers to the set of nodes that are only part of assertion branches, with VApure ⊂ VA ⊂ V.

 



_{A A}



Apure

n V C n V

V :   : 

₍₃₎

Furthermore, as the Boolean result of every assertion statements is an output, we define a subset of S that contains the nodes corresponding to assertion sinks. This set is referred as SA.

The identification of an assertion branch starts from an assertion output node n0 ∈ SA. The branch identification algorithm is repeated for every assertion output. This algorithm scans the graph by going from a node to its parents recursively. It adds the encountered nodes to the current assertion branch until a border node is found. Those border nodes, defined in eq. 4, consist of inputs (Border1), internals (Border2) and outputs (Border3).

 

 

 

 

out

A

V Border

V c n C c V n Border

E Border n

P V n Border





















 :

, :

:

: :

3 2

1

1



(4) Fig. 4. Proposed methodology in a HLS flow

Example algorithm assert(a != 0);

assert(a - b > 2);

y = (a + b) >> 1;

Fig. 5. Illustration of the VA and VApure sets from an example algorithm.

Border2 values depend on the set VA, but VA also depends on Border2. This leads to a dead-end. A workaround for testing if a node n is in Border2 relies in retrieving a set of nodes S(n) ⊂ S, as defined in eq. 5 (Paths(ni, nj) is the set of all paths from ni to nj). Nodes from S(n) are graph outputs that are reachable from n. For each n

∈ V, S(n) ≠ ∅ since G is a directed acyclic graph.

  n : ^  n

₁

^ S : Paths  n , n

₁

 ^{ } 

S

(5)

Therefore, Border2 can be obtained thanks to the following expression:

 

 n V n S n n S

_A



Border

₂

  : 

₁

 ,

₁



(6) As a consequence, for each checked node n, the algorithm retrieves the set S(n) and verifies that n is part of Border2 with the equality stated in eq. 6. The recursive algorithm is given in Figure 6. Additionally, Bi is defined as the set of all nodes that are part of the assertion with id i. An assertion id is a number assigned to an assertion branch from the position of the assertion statement in the behavioral description.

Once an assertion branch (with id i) is found, the sets Bi, VA and VApure is totally or partially populated by the nodes of this branch. This population pattern is expressed as follows:

 All nodes from the branch are added to Bi and VA,

 Nodes verifying eq. 7b are added to VApure. In this

equation, Csts refers to all nodes that represent a constant.

A more formal definition of this set is given in eq. 7a.

V

in

E

Csts :  

(7a)

 

 P n

ⁱ

B

_i

  n Csts  n V

_Apure

B n



















,

(7b)

5.2. Assertion branch adaptation

Assertion branches can overlap with each other. This behavior comes from the coding style of the application behavioral model. For instance, some assertion statements may share a variable that is created explicitly for these statements. Therefore, the lifetime of this variable does not exceed the assertion computations. For this reason, it is candidate for being part of VApure.

If this overlap greatly reduces the number of nodes in the whole graph, in counterpart it makes further per- assertion optimizations much harder to perform. It also reduces the flexibility of a potential selection of important assertions to be kept while others are discarded for the architecture generation. As a consequence, this step is meant to suppress any assertion overlap.

A node verifying eq. 8 is part of multiple assertion branches, and has to be duplicated.

i N

Apure

n

i

B

V

n    

1 (8)

Two assertion branches Bi and Bj overlap if and only if they verify eq. 9.









_{j Apure}

i

B V

B

(9)

5.3. Assertion branch removal

Once branches have been isolated, they can be safely broken up from the rest of the main graph. For each assertion branch Bi, a new graph Gi = (Vi, Ai) is defined. Nodes from Bi∩ VApure are directly removed from V and put into Vi while nodes from Bi∩ VA\VApure are duplicated and left in V. The relation between a node in V and its clone in Vi is kept in an association table.

We define the functions Clonei and Clonei -1 (see eq. 10) to retrieve a clone in Vi from a node in V and vice-versa.

 ^{n V Clone}   ^{n S} 

S Clones

V V Clone

V V Clone

i i

i i i

i i















1 1

: )

( : :

(10) getAssertionBranch(Node n)

(1) (2) (3) (4) (5)

(6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17)

branch = new list of nodes add n to branch

if P(n) = ∅ or n ∈ Vout then return branch

end if

compute S(n) := {n1 ∈ S : Paths(n, n1) ≠ ∅} for n1 ∈ S(n) do

if n1 ∉ SA then return branch end if

end for for p ∈ P(n) do if p ∉ branch then

branch = branch ∪ getAssertionBranch(p) end if

end for return branch

Fig. 6. Algorithm of the research of assertion branches

Similarly, Clonesi(S) is a set composed by clones of S elements. Gi is defined in eq. 11.

 

     

   

    _ ^{  }



 





 

 



 









 















x y A

Clone V y x V

y V x

A y A x

V V B Clones V

B V

A V G

i i i

i i

Apure A

i i Apure

i i

i i i

, : : ,

: , :

, :

1

2 (11)

5.4. Binding assertion graphs to hardware resources This step does not require any computation. It only consists in retrieving information assigned during the architectural synthesis. Indeed, the latter properly works on the assertion- free graph after the previous step. Scheduling and allocation tasks, as well as any optimization, is safely triggered. Then, hardware resources assigned to the graph nodes are associated (binded) to the corresponding nodes in the multiple assertion graphs sets (Vi). Required information is:

 RTL register names: it corresponds to the names that hold an assertion input data during each time.

 Data availability date: the date (clock cycles) when previously mentioned registers hold the data corresponding to a given assertion input variable.

By this way, assertion graphs (Gi) contain enough information to generate the monitors. However, this generation needs one more step.

5.5. Assertion graphs sorting

Assertion graphs need to be sorted. Designers usually define sets of assertions in a specific and relevant order. For instance, before asserting that a division is bound to a particular range, the division result has to be checked to ensure that it is not equal to zero. Therefore, the latter would be asserted first and the former secondly. As a consequence, assertion branches have to respect their definition order, which is sequential in the application behavioral model. For this purpose, an execution date is added to each assertion branch.

The default execution date is the date when every assertion input variable has been read. This date is stored in a table. After every default execution date is determined, the table is sorted by assertion execution order as defined by the behavioral model. This process is as follows: the table is browsed linearly and if an execution date is found to be lesser than the previous one, it is changed to this previous date.

5.6. Monitor generation

Monitors are generated either as VHDL processes or as PSL assertions, from the information backed by assertion graphs.

These monitors are passive and resource-free. They do not modify the architecture characteristics. VHDL monitor descriptions are useful for simulators which are not PSL- ready.

Considering either PSL or VHDL monitor generation, register or input data are read as defined during the binding step, and assertion checks are triggered at a specific clock cycle. On the one hand, PSL generation makes heavy use of the built-in prev(arg [,N]) function to retrieve data stored in registers at defined clock cycles. On the other hand, VHDL monitors are built in two different ways: using multi-process or single-process description. Multi-process approach wraps each monitor into a dedicated process while the other approach builds a single process that contains all the monitor statements. With the latter approach, maintainability is harder, but the simulation time overhead introduced by the monitors is much lower.

6. EXPERIMENTAL RESULTS

The proposed methodology has been implemented in the GraphLab HLS tool [14]. Experimentations have been done to evaluate the correctness of the generated monitors as well as the simulation runtime impact of monitors. The cost of generated PSL/VHDL lines has been also considered.

Applications are: an 8x8 2D Discrete Cosine Transform (DCT) with two different latency constraint sets, a standard 8x8 1D DCT and a JPEG compression standard. The number of behavioral assertions ranges from 16 for the 1D DCT, up to 896 for the JPEG transformation, in order to reflect some real-case uses. VHDL architecture simulations were performed using ModelSim SE rev 6.6. Timing results (see Table 1) are provided for 300 iterations of each application. The different tests were divided in two categories:

 First, randomized stimuli were applied both on the behavioral model and the generated RTL description to validate the correctness of the generated monitors. Such validation is only possible if every assertion failure happens in both cases.

 Then, stimuli were constrained to fulfill the algorithm preconditions in order to measure the simulation runtime overhead. Indeed, since an assertion failure would stop the simulation, no failure should happen during a complete measure pass.

Results show that the simulation runtime overhead is limited (< 5%), and that embedding every monitor into a single VHDL process has virtually no impact on the simulation. Nevertheless, using one process per assertion

checker increases the overhead significantly. As expected, higher monitor maintainability goes with lower simulation performances.

7. CONCLUSION

Assertions-Based Verification can greatly speed up the debug process of the integration or the reuse of an IP.

Therefore, the automatic propagation of behavioral assertions to the RTL level during an HLS synthesis leverages the debug possibilities with a minimal effort.

The methodology defined in this paper enables HLS generation of architectures that are more suitable for direct functional verification and in-circuit transaction verification.

Future works will target direct behavioral assertion transformation into fully synthesizable monitors in a single architecture (computation data path and monitors), in order to enhance verification during the implementation steps for emulation or silicon-debugging purposes.

8. REFERENCES

[1] Bortolami J., Leveraging system models for RTL functional verification. (2007). http://www.eetimes.com

[2] Bhadra J., Abadir MS., Wang L-C., Ray S., A Survey of Hybrid Techniques for Functional Verification. IEEE Design and Test of Computers, vol. 24, pp. 112--122 (2007)

[3] Foster H., Lacey D., Krolnik A., Assertion-Based Design. 2nd ed. Norwell, MA, USA. Kluwer Academic Publishers (2003) [4] Lavagno L., Martin G., Scheffer L., Electronic Design

Automation for Integrated Circuits Handbook - 2 Volume Set.

Boca Raton, FL, USA. CRC Press, Inc. (2006)

[5] Coussy P., Takach A., Special Issue on High-Level Synthesis.

IEEE Design and Test of Computers, vol. 26 (2009)

[6] Martin G., Smith G., High-Level Synthesis: Past, Present, and Future. IEEE Design and Test of Computers, vol. 26, pp. 18-- 25 (2009)

[7] Kundu S., Lerner S., Gupta R., High-Level Verification. IPSJ Transactions on System LSI Design Methodology, vol. 2, pp.

131-144 (2009)

[8] Meyer B., Applying “Design by Contract”. Computer IEEE, vol. 25, pp. 40--51 (1992)

[9] Gharehbaghi a, Yaran B, Hessabi S, Goudarzi M, An assertion-based verification methodology for system-level design. Computers & Electrical Engineering, vol. 33, pp. 269- -284 (2007)

[10] Curreri J., Stitt G., George AD., High-level synthesis techniques for in-circuit assertion-based verification. In:

Parallel & Distributed Processing, Workshops and Phd Forum (IPDPSW), pp. 1--8 (2010)

[11] Carreras C., López JA., Nieto-Taladriz O., Bit-Width Selection for Data-Path Implementations. In: Proc. 12th intl.

symposium on System synthesis, pp 114--119 (1999) [12] Aho AV., Lam MS., Sethi R., Ullman JD., Compilers -

Principles, Techniques, and Tools (2nd Edition). Addison Wesley (2006)

[13] Kavi KM., Buckles BP., Bhat U., A formal definition of data flow graph models. IEEE Transactions on Computers vol.

100, pp. 940--948 (2006)

[14] Le Gal B., Casseau E., Word-Length Aware DSP Hardware Design Flow Based on High-Level Synthesis. Journal of Signal Processing Systems, Springer. Online, pp 1--17 (2010) T^ABLE 1.Experimental results (simulation times are for 300 iterations)

Application # assertions # behavioral assertion lines

# PSL monitor lines

# VHDL

monitor lines Simulation mode Simulation

time Overhead

8x8 1D DCT 16 8 (using loops) 16 109

Normal 0.281s

VHDL Single-process 0.285s +1.49%

VHDL Multi-process 0.289s +2.85%

8x8 2D DCT

(Low Latency) 320 17 (using loops) 320 1089

Normal 45.828s

VHDL Single-process 46.039s +0.46%

VHDL Multi-process 46.906s +2.30%

8x8 2D DCT (High

Latency) 320 17 (using loops) 320 1125

Normal 25.516s

VHDL Single-process 25.664s +0.58%

VHDL Multi-process 26.633s +4.20%

JPEG Transformation

(Low Latency)

896 26 (using loops) 896 2777

Normal 183.891s

VHDL Single-process 184.625s +0.40%

VHDL Multi-process 186.406s +1.35%

JPEG Transformation

(High Latency)

896 26 (using loops) 896 2883

Normal 131.125s

VHDL Single-process 132.109s +0.74%

VHDL Multi-process 134.844s +2.76%