KNOWLEDGE-GUIDEDMETHODOLOGYFOR
SOFTIPANALYSIS
BY
BHANUPRATAPSINGH
Submitted in partial fulfillment of the requirements
For the degree of Doctor of Philosophy
Dissertation Advisor: Dr. Christos Papachristou
Department of Electrical Engineering and Computer Science
CASEWESTERNRESERVEUNIVERSITY
January 2015 CASEWESTERNRESERVEUNIVERSITY
SCHOOLOFGRADUATESTUDIES
we hereby approve the thesis of BHANUPRATAPSINGH
candidate for the PH.D. degree.
chair of the committee DR.CHRISTOSPAPACHRISTOU
DR.FRANCISMERAT
DR.DANIELSAAB
DR.HONGPINGZHAO
DR.FRANCISWOLFF
date AUG 2 1 , 2 0 1 4
∗ We also certify that written approval has been obtained for any propri- etary material contained therein. Dedicated to my family and friends. CONTENTS
1 introduction1
1.1 Motivation and Statement of Problem ...... 1 1.1.1 Statement of Problem ...... 6 1.2 Major Contributions of the Research ...... 7 1.2.1 Expert System Based Approach ...... 7 1.2.2 Specification Analysis Methodology ...... 9 1.2.3 RTL Analysis Methodology ...... 9 1.2.4 Spec and RTL Correspondence ...... 10 1.3 Thesis Outline ...... 10
2 background and related work 11
Abstract ...... 11 2.1 Existing Soft-IP Verification Techniques ...... 11 2.1.1 Simulation Based Methods ...... 11 2.1.2 Formal Techniques ...... 13 2.2 Prior Work ...... 15 2.2.1 Specification Analysis ...... 15 2.2.2 Reverse Engineering ...... 17 2.2.3 IP Quality and RTL Analysis ...... 19 2.2.4 KB System ...... 20
3 overview of methodology 21
Abstract ...... 21 3.1 KB System Overview ...... 21 3.1.1 Knowledge Base Organization ...... 24 3.2 Specification KB Overview ...... 26 3.3 RTL KB Overview ...... 29
iv contents v
3.4 Confidence and Coverage Metrics ...... 30 3.5 Introduction to CLIPS and XML ...... 31 3.5.1 CLIPS Expert System Shell ...... 31 3.5.2 XML ...... 32
4 specification knowledge base 36
Abstract ...... 36 4.1 Spec-KB ...... 36 4.2 Specification Knowledge Representation Scheme ...... 37 4.2.1 Specification Ontology ...... 37 4.2.2 Automating Ontology Generation ...... 43 4.3 Specification Knowledge Extraction Scheme ...... 47 4.3.1 Spec-Extractor Tool ...... 47 4.3.2 Specification Rule-Base ...... 50 4.3.3 Metrics for Specification Analysis ...... 53
5 rtl knowledge base 57
Abstract ...... 57 5.1 RTL-KB ...... 57 5.2 RTL Knowledge Representation Scheme ...... 58 5.2.1 RTL-CLIPS ...... 58 5.2.2 Property Based Model ...... 59 5.3 RTL Knowledge Extraction ...... 62 5.3.1 RTL Rule Base ...... 62 5.3.2 RTL Evaluation in CLIPS ...... 67 5.3.3 RTL Analysis Example ...... 68
6 specification and rtl correspondence 70
Abstract ...... 70 6.1 Back Annotation ...... 70 6.1.1 Specification Tabular Objects ...... 71 6.1.2 Specification Drawing Objects ...... 78 contents vi
6.2 Results: Spec and RTL correspondence ...... 82
7 conclusion and future work 85 i appendix 87 a processing tabular objects 88
a.1 HTML Register Table and Register Test-bench Generation . . . . 88 b processing drawing objects 102
b.1 Extraction of FSM Specfication from SVG ...... 102
bibliography 110 LISTOFFIGURES
Figure 1 Design completion time compared to the project original schedule [1]...... 2 Figure 2 Functional Bugs Resulting in Increasing ASIC Respins . . 2 Figure 3 Verification effort in a project [1]...... 4 Figure 4 Cost of fixing bug vs Time [2]...... 5 Figure 5 Components of an Expert System [3]...... 8 Figure 6 Simulation Based Verification ...... 12 Figure 7 Formal verification process ...... 14 Figure 8 Knowledge Base Generation ...... 22 Figure 9 Knowledge Base Application for third-Party IP Analysis 23 Figure 10 OMAP4470 application processor from Texas Instruments [4]...... 24 Figure 11 Marvell ARMADA 510 (88AP510) Application Processor [5]...... 25 Figure 12 FreeScale i.MX25 Application Processor [6]...... 26 Figure 13 Knowledge Base organization overview ...... 27 Figure 15 Confidence factor merging using parallel combination formula ...... 30 Figure 14 Fragment of semantic network for peripheral interface domain ...... 35 Figure 16 Spec Analysis Flow ...... 38 Figure 17 Fragment of ontology model for FPU design domain . . 40 Figure 18 Tabular representation of IEEE-754 Floating point ontology 42 Figure 19 Overview of Ontology Automation system ...... 44
vii List of Figures viii
Figure 20 Frequency and Location based visualization of words in a FPU Spec ...... 45 Figure 21 Ontology Construction: Statistics of Generated Sugges- tions [7]...... 46 Figure 22 Iteration: Saturation Point [7]...... 46 Figure 23 Spec Word classification based on Lexical, Syntactic and Spatial Attributes ...... 49 Figure 24 Fragment of ARM2 design composition knowledge . . . 52 Figure 25 RTL Analysis Overview ...... 58 Figure 26 Property based model of a FIFO design ...... 61 Figure 27 Fragment of pdg for floating point add function . . . . . 66 Figure 28 Html annotation report ...... 69 Figure 29 Back Annotation overview ...... 71 Figure 30 Proposed IO Description Template ...... 73 Figure 31 Block diagram generated for ARM2 Core using GraphViz package ...... 74 Figure 32 Register Specification Template ...... 76 Figure 33 HTML view of register specification ...... 77 Figure 34 Register Verification Test bench ...... 78 Figure 35 FSM diagram drawn in Dia Tool [8]...... 79 Figure 36 FSM specification extraction from SVG diagram . . . . . 80 Figure 37 Example Timing Diagram ...... 81 Figure 38 Corresponding fragment of TDML XML ...... 81 Figure 39 Wishbone Interface timing diagram drawn using TDML tool and verification of generated assertions in simulation 82 LISTOFTABLES
Table 1 Fragment of Signal Description table from an Opencores FPU Spec ...... 33 Table 2 Spec word clusters ...... 56 Table 3 Specification analysis results using Spec rule base . . . . 56 Table 4 Examples of HDL represented in Knowledge Base . . . . 59 Table 5 Example - Template RTL code fragments and their an- notations ...... 60 Table 6 Test results for six ITC99 Benchmarks [9]. State names and CLIPS rules fired per machine cycle. . . 68 Table 7 RTL Analysis results using RTL rule-base ...... 69 Table 8 Spec Analysis Results ...... 84 Table 9 RTL Analysis and Back Annotation Results ...... 84
ix ACRONYMS
SoC System on Chip
NEFCIS Neuro-fuzzy Concept based Inference System for Specification Mining
UAG Undirected Acyclic Graph
DAG Directed Acyclic Graph
CRV Constrained Random Verification
FPU Floating Point Unit
CLIPS C Language Integrated Production System
HDL Hardware Description Language
HVL Hardware Verification Language
RTL Register Transfer Level
XML Extensible Markup Language
DTD Document Type Definition
NLP Natural Language Processing
KB Knowledge Base
TDML Timing Diagram Markup Language
UVM Universal Verification Methodology
x ACKNOWLEDGEMENTS
First and foremost, I would like to thank my advisor Dr. Christos Papachris- tou for accepting me as his PhD student and guiding me in my research. He has always inspired me with his optimism and his creative ideas. The pro- posed methodology in this work has been conceptualized by him. His ability to quickly understand an issue and ask relevant questions around it has several times helped me to think afresh. He always encouraged me and appreciated my efforts, which kept me motivated during project implementation. Secondly, I would like to thank Prof. Frank Merat, Prof. Daniel Saab and Prof. Hong Ping Zhao, and Dr. Francis Wolff for serving on my dissertation commit- tee, for their time and valuable comments. Especially, I would like to thank Dr. Francis Wolff, who has been closely involved in my research throughout my graduate career. My research at Case would not have been possible without the help and support of my teammates, with whom I have collaborated in my research. I am thankful to Dr. Lawrence Leinweber, Dr. Yuriy Shivanosiki, and Arun- prasath Shankar for numerous interesting project discussions. I would also like to thank my friends at CWRU especially Mike Labarbera, Aswin Krishna, Maryam Hashemian and Moussa Souare, because of whom I had wonderful time at Case. I would like to thank Rockwell Automation (Mayfield Heights) for giving me an internship opportunity and to my manager Dan Weyer, who was very sup- portive. I am also thankful to Steve Clay, with whom I interacted at Rockwell and who has increased my knowledge in IC design. I would like to thank my family for all their love and support. My parents have instilled in me the value of hardwork and patience. Their unconditional
xi acknowledgements xii
love for me, and pride in me keeps me motivated in life. My brothers Vishav and Rishabh, who have always been my support system. I would like to ex- press my deepest gratitude to my wife and my friend, Smriti, for her support and understanding during the past few years. Her support and encouragement made this dissertation possible. Finally, I acknowledge my daughter, Advika, and my son, Aaditya, who had to adjust with their father’s busy schedule and are my bundles of joy. knowledge-guided methodology for soft ip analysis by bhanu pratap singh
ABSTRACT
Demand for increasing functionality in handheld devices is driving integration of more functions (IPs) into System-on-Chip (SoC) designs. The development of such complex designs poses new challenges to the semiconductor industry in terms of productivity gaps and risks meeting quality and time-to-market goals. In SoC design, these goals are critical as rapid advances in process and product technology have shortened product life cycles with a limited feasible marketing window. SoC design teams have been employing IP reuse method- ology to increase their productivity and often integrate third party IPs into their systems. Verification has developed into a major bottleneck in SoC design and has now reached crisis proportions. Verification involves building a complex test environment and the productivity gap affecting verification means that thor- ough verification of third party IPs is generally not done. In practice, there are risks involved in using a third party IP as bugs may creep in due to versioning issues, poor documentation, and mismatches between specification and RTL. As a result of this, third party IP specification and RTL must be carefully eval- uated. The current state-of-the-art lacks a methodology that captures the exper- tise of a design expert by providing knowledge representation, extraction and reuse schemes. New techniques are required that can leverage heuristic knowl- edge of design experts and uncover IP quality issues early in the design cycle. Simulation based verification techniques can also be augmented by engineer’s
xiii abstract xiv
understanding and knowledge of design. This work addresses the issue of third party IP analysis by providing a methodology to find a correspondence between IP specification and RTL. In this research, a knowledge-based system is used to mitigate the risk of using a third party IP. The methodology provides a technique to analyze IP specs and RTL, which are then cross-correlated to discover any discrepancies. The key innovative ideas in our approach are to use prior and trusted experience about designs, which include their specs and RTL code. Also, we have captured this trusted experience into two knowledge bases (KB), Spec-KB and RTL-KB. Fi- nally, knowledge base rules are used to cross-correlate the RTL blocks to the specs. We apply our knowledge-based system to analyze a third party soft IP, pro- vided by its RTL code description and a trusted specification document. The third party IP analysis involves a rule-based search process, which checks the existence of trusted design properties in an untrusted design. Our validation approach complements existing IP validation techniques and acts as a spec vs. RTL lint tool with a behavioral analysis capability. 1
INTRODUCTION
1.1 motivation and statement of problem
Validation for correctness is the most important task in digital system de- sign especially for IP cores and large integrated systems. Validation is a quality assurance process of establishing evidence that provides a high degree of as- surance that a product or system complies with its intended specification [10] [11]. The International Technology Road map for Semiconductors (ITRS) has listed design validation as a major bottleneck resulting in productivity gaps and risking return on investment for semiconductor companies. Hardware as- pects of design continue to witness soaring verification team sizes and test costs [12]. In recent years, the task of validating an IP against its specification is be- coming daunting due to increasing design complexity. The verification com- plexity increases exponentially with design complexity and as such verifica- tion schedules can not be accurately predicted resulting in project schedule slippage. This risks products missing a feasible market window. Fig.1 provides the results of a survey, which shows that on an average 67 % of projects are running behind schedule [1][13]. A major reason for slippage of schedule is late discovery of logical/functional design flaws as shown in Fig. 2, which decreases chances of first silicon success [14][15].
1 1.1 motivation and statement of problem 2
Figure 1: Design completion time compared to the project original schedule [1]
(a) IC/ASIC Having One or More Re-spins by Type of Flaw [14]
(b) ASIC Respin statistics [15]
Figure 2: Functional Bugs Resulting in Increasing ASIC Respins 1.1 motivation and statement of problem 3
Hardware design teams practice IP reuse to increase their productivity [16]. This allows semiconductor companies to focus their R&D effort on de- veloping their differentiating technology and use third party IPs for standard- based IPs, which provide minimal differentiation. A soft intellectual property (Soft IP) core is a reusable unit of logic, which can be synthesized to logic gates. A general assumption is that by reusing silicon proven IP blocks, design risk can be averted, productivity can be improved and time to market goals can be met. SoC design teams typically integrate a number of third-party IPs into their design. It is assumed by the SoC integrators that the third-party IP has been functionally validated by developers. In practice, bugs might still creep in due to the following reasons
• IP design validation ultimately comes down to good engineering judg- ment of engineers. A validation engineer might write his tests influenced by the design implementation rather than basing them on requirement specifications. In such a scenario, if a feature is not implemented or in- correctly implemented in RTL, then the bug is not discovered by the simulation test bench.
• In today’s global economy, IPs are being designed and verified at differ- ent geographic locations. The multi-site development of IPs also increases the risk to design quality.
• It is a common case that the IPs to be integrated might be required to be customized as per the requirements of the system. The vendors thus release a customer specific version and as such modifications are made to a stable RTL version of the IP.
• In case of new design standards, the IP might not have matured and been robustly proven in silicon. 1.1 motivation and statement of problem 4
The third-party IPs can as such be classified as untrusted designs since the user has no insight into IP validation or the quality control process. In a typical project, more than half of the development time is devoted to the verification process [17]. Fig.3 shows the trends in total project time spent in verification [1][13]. The productivity gap affecting design validation means that thorough third-party IP analysis at the user end is not performed. How- ever, the importance of thorough design analysis is not overstated. IP design issues, if discovered later than the RTL sign-off stage, increase the design turn around time and in the worst case result in chip re-spins.
Figure 3: Verification effort in a project [1]
Traditionally, validation has been pursued by simulation and testing tech- niques, using tools at several levels of representation i.e. system architecture, RTL and gate levels [18]. Large sets of functional vectors are applied at the sys- tem and RTL levels, testing just functionality without any fault modeling. At the gate level, ATPG tools use fault models to cover specific defects at the gate level [19]. The problem with functional testing is that it is very expensive as it requires long run times to operate on the large test vector sets. Thus functional 1.1 motivation and statement of problem 5 testing may not provide a high confidence level at a reasonable cost. Formal techniques for hardware system verification based on “Theorem proving” have been proposed in many research works [20][21]. The basis of formal verification is to derive a formal proof of a mathematical model of the system. The most widely used approach to formal verification is “Model check- ing”, which pursues exhaustive exploration of the state space and state tran- sitions of the system model [22][23]. However, model checking needs formal specs, i.e. a formal specification language. Although verification techniques have improved significantly, still the state explosion issue is a challenge in for- mally verifying large systems. A hardware bug is not simple to fix as in software, where a simple software patch can be downloaded via the Internet. A faulty chip means product recalls and extra re-spin costs. Fig. 4 shows the exponential increase in verification cost if the bug is discovered at the customer end [2]. The requirements to pro- duce fault-free chips motivate research to develop techniques to uncover IP quality issues early in the design cycle.
Figure 4: Cost of fixing bug vs Time [2] 1.1 motivation and statement of problem 6
The current state-of-the art lacks a methodology that models the exper- tise of a design expert to uncover IP quality issues by providing knowledge representation, extraction and reuse schemes. This work addresses the issue of third party IP analysis by providing a methodology to find a correspondence between IP specification and RTL using a knowledge base system. Knowledge based techniques use powerful pattern matching algorithms [24][25] to solve a variety of problems including circuit design. Knowledge bases are built on facts and rules and a search engine that can resolve new rules against existing rules in the rule base. Knowledge bases can be used to represent prior and trusted design experience, which can be used to infer by pattern matching the validity of new, possibly untrusted, designs. This is achieved by creating rules to represent properties of a new design and attempt to match these rules against the property rules of prior designs in the rule base. The development of design knowledge bases is a key element in our proposed work.
1.1.1 Statement of Problem
We consider a common scenario, where a SoC design team develops an IP specification (trusted spec) document but outsources the IP design and ver- ification to a third party design house. The SoC team finally receives the IP block as a soft IP core, which has a synthesizable RTL code description and a detailed functional spec document. An important issue is that the RTL design corresponds without discrepancies to its original trusted spec. Our method ad- dresses this issue. The application of our work is also to identify functionality of independently designed IP blocks. Given a third Party IP block specification and its RTL representation, our problem entails:
• Developing a methodology for specification analysis. 1.2 major contributions of the research 7
• Developing a methodology for RTL code analysis.
• Developing techniques to validate correspondence of specification to RTL.
1.2 major contributions of the research
The key innovative ideas in our approach are: first, to use prior and trusted design experience about designs, including their specs, RTL code, synthesis scripts and test benches; second, to capture this trusted experience in two knowledge bases, for specs and RTL information, respectively; third, use pat- tern matching rules against the rules in both knowledge bases to confirm the RTL and infer its relation block by block to the specs. Exploitation of prior and trusted design experience through both knowledge bases and pattern match- ing rules is a key benefit of our approach in contrast to formal methods and functional simulations. The following is a brief description of the main innova- tive items of our research.
1.2.1 Expert System Based Approach
An expert system is a program which is specifically intended to model human expertise or knowledge and is an intelligent software system capable of supporting explicit representation of knowledge. Expert systems are also known as knowledge based system and are generally designed very differ- ently from conventional programs because the problems have no satisfactory algorithmic solution and rely on inferences to achieve a reasonable solution. Engineers often use their past experience or heuristics, to solve a new prob- lem. This is also termed as case based reasoning, which is used by experts to solve a problem using previous similar cases, called precedents [3]. We have used CLIPS, an expert system shell originally developed by NASA, to build 1.2 major contributions of the research 8 our knowledge based system [3].
EXPERT SYSTEM
INFERENCE ENGINE WORKING MEMORY RULE BASE AGENDA FACTS
EXPERT
Figure 5: Components of an Expert System [3]
An expert system consists of a rule-base, inference engine and a working memory of facts as shown in Fig.5. A rule is in IF-THEN format. The part of the rule between IF and THEN is called antecedent or pattern part or condi- tional part. Following the THEN part of a rule is a list of actions to be executed when the rule fires. The term facts means information that is used by the ex- pert system for drawing inferences. A rule uses a set of facts as its conditional part in its antecedent. The inference engine determines which rule antecedents are satisfied by the facts. Two general methods of inferencing used in expert systems are forward chaining and backward chaining. Forward chaining is reasoning from facts to the conclusions resulting from those facts. Backward chaining involves reasoning in reverse from a hypothesis, a potential conclu- sion to be proved, to the facts that support the hypothesis [3]. We have a developed an expert system based methodology for specification and RTL analysis [26][27][28]. Our approach provides techniques to perform CLIPS fact based representation of spec and RTL information. A Spec and RTL rule-base written by experts captures their heuristic knowledge in the system. A forward chaining inference engine then uses the rule-base to draw conclu- sions from spec and RTL facts. 1.2 major contributions of the research 9
1.2.2 Specification Analysis Methodology
IP specification (spec) documents are becoming complex with increasing number of features listed across hundreds of pages. Designers prefer to write specs in natural language (NL) format such as English. However, this is a lim- itation for automating specification analysis. Existing systems for IP spec analysis mainly use keyword based approaches. Keyword-based systems fail to capture and take into account semantic relation- ships between keywords in a design domain. We have developed a spec anal- ysis technique that utilizes the underlying conceptual information embedded in specs to perform concept mining for semantic analysis of specs [27][7].
1.2.3 RTL Analysis Methodology
We have developed a methodology to perform rule-based static and dy- namic analysis of RTL code [26][27]. Our vhdl2clips tool automatically con- verts VHDL constructs into CLIPS facts [9]. The tools serves as the basis for forming the RTL knowledge base of trusted HDL code. We have developed pattern matching rules to perform static analysis of RTL code using the inbuilt inference engine of CLIPS. Our emphasis is recognition of code by matching patterns of operators and program constructs. The local evaluation of code fragments with test vectors is then used to confirm and supplement inferences made by pattern matching rules. Our approach augments the in-built pattern-matching capability of CLIPS with an event-based RTL simulator [9]. This enables the rule-base to use the en- hanced CLIPS expert system shell to identify IP design behavior and perform IP quality checks. 1.3 thesis outline 10
1.2.4 Spec and RTL Correspondence
Our work provides a methodology to validate the cross-correlations be- tween spec and RTL of a third party IP [29]. We have developed techniques to validate register specification and specification of drawing objects such as finite state machines (FSM). The Spec analysis output lists inferred design domain functions, associated features and their attributes such as bus-interface logic (protocol) and input- ouput (IO) features (bit-width, direction). The RTL analysis output provides behavioral annotations corresponding to design functions and IO features. Our back-annotation technique then maps inferred RTL modules block by block to the corresponding sections in spec. This provides feedback to the user about mismatches between specification and RTL.
1.3 thesis outline
The thesis is organized as follows: Chapter 2 discusses existing Soft-IP Val- idation techniques and prior work in specification and RTL analysis. Some examples of KB systems in the hardware domain are also discussed. Chapter 3 provides a brief overview of our methodology and provides an introduction to the CLIPS expert system and XML document format. The chapter also dis- cusses the confidence factor as a key metric in our approach. In Chapter 4, we discuss our specification knowledge representation and extraction schemes. Chapter 5 discusses in detail our RTL knowledge representation and extraction schemes. In Chapter 6, we discuss our back-annotation technique to perform cross-correlation between IP specs and RTL. Finally, Chapter 7 summarizes the conclusions and describes future research. 2
BACKGROUNDANDRELATEDWORK
abstract
In this chapter, current state-of-the-art verification techniques are discussed. Existing techniques are classified under simulation and formal verification based methods. Simulation requires generation of input test vectors while for- mal methods are based on verifying precise mathematical description of de- sign properties. This chapter also discusses related prior work and previous knowledge based systems developed for the hardware domain.
2.1 existing soft-ip verification techniques
2.1.1 Simulation Based Methods
Simulation remains the mainstay for most real-life verification issues, even though it is inherently incomplete due to an input state space that is too large to be enumerated [30]. Simulation involves either directed test case generation or constrained random verification (CRV). Fig.6 provides an overview of the simulation based design verification flow. The simulation of a hardware design involves the following tasks (a) un- derstanding a specification and building a test-plan to list tests for all the spec- ified features, (b) development of a test bench that should ideally exercise the design to provide full functional coverage, (c) building a reference behavioral model from a specification against which the design is compared, (d) build-
11 2.1 existing soft-ip verification techniques 12
Design
Functional RTL Design Spec output IP Design Requirement Spec Simulation Test stimulus Checker Test Spec TestBench pass/fail Coverage Test stimulus
Behavioral Model output
Figure 6: Simulation Based Verification
ing a checker block to do pass/fail analysis, and (e) analyzing the functional coverage results. In all these tasks, it is very important that the verification engineer does not mimic the thought process of the design engineer, as both of them will then commit the same errors and a bug may not be discovered in simulation. Directed test case generation involves much manual effort and test cases have to be explicitly thought of. Each directed test case covers a particular de- sign feature. A hardware design has many corner cases, so this approach can only target easy-to-find bugs. CRV can generate many test scenarios through constrained random genera- tion of stimulus and is better suited for tackling the state space explosion prob- lem. The hardware description languages (HDL) were incapable of effectively modeling test environments to verify the complex designs being developed. This led to the development of hardware verification languages (HVL) such as “systemVerilog” and “e-language” [31]. HVL have accelerated the adoption of CRV based test environments [32]. HVLs are successful, in part, due to the recognition that SoC functional ver- 2.1 existing soft-ip verification techniques 13 ification is really a software problem, not a hardware problem. Where HDLs were adequate to describe the static hardware in a chip, the inclusion of ran- domization, objects and other HVL features allowed the languages to describe more dynamic behaviors required to describe the real world in which chips are expected to operate. Users quickly realized that these environments could be quite complicated and reinventing new environments from scratch for each project was not a viable strategy. Thus was born the concept of verification methodologies to facilitate reuse of verification IP [31]. A number of verification methodologies to architect HVL verification envi- ronments have been proposed such as, e-language Reuse Methodology (eRM) and Open Verification Methodology (OVM) [33]. The recently developed Uni- versal Verification Methodology (UVM) Class library provides the building blocks needed to quickly develop well-constructed and reusable verification components and test environments. CRV based techniques require a complex self-checking environment, which takes a large amount of development time. The major issue in CRV is that there is no direct mapping between a feature and a test case. In directed testing, a test covers a particular feature while in CRV we do not know which features are being covered by a particular test. The effective usage of CRV comes down to good engineering judgment of providing constraints and usage scenarios. A coverage driven metric is used as the key indicator of the verification process. The coverage is very much dependent on the engineer’s knowledge of the de- sign. We cannot rule out bugs creeping in due to faults in the self-checking environment [17].
2.1.2 Formal Techniques
Formal verification is a systematic process that uses mathematical reason- ing to verify that design intent (spec) is preserved in implementation (RTL). 2.1 existing soft-ip verification techniques 14
A formal specification or model of the design is prepared in terms of proper- ties that obey mathematical rules. Now, given a property, formal verification exhaustively searches all possible input and state conditions for failure [34]. Fig.7 provides an overview of formal verification process.
Standard Specification
Functional Property Specification Specification
Implementation Property Modeling
Verification Framework
Satisfiable ?
Figure 7: Formal verification process
The traditional formal techniques (broadly, model checking and theorem proving) can, in principle, analyze and find all bugs in a design model but their applicability in practice is limited. The well known state explosion problem limits model checking, and the cost of theorem proving is prohibitive because of the amount of skilled manual guidance it requires [30]. The simulation based techniques do black box testing of the design under test (DUT). The formal verification techniques use the white box strategy and 2.2 prior work 15
are at a lower level of abstraction as compared to simulation. Assertion based verification is another formal verification technique that provides exhaustive coverage of the design. The assertion based techniques involve building an assertion using design signals. A verification engineer has to be very careful to be independent of the thought process of the designer as he may also repeat the bugs in RTL in his assertion model.
2.2 prior work
There are four broad areas related to our work, (a) Specification Analysis, (b) Reverse engineering, (c) IP Quality and RTL Analysis, and (d) KB System. We summarize the prior work in each of these areas and relate it with our focus and approach.
2.2.1 Specification Analysis
Designers have a preference for writing specification documents in an in- formal natural language format using a variety of notations that include dia- grams, charts, and tables. A lot of research has been done in the past to extract formal specifications from the specification documents. In software, domain ontologies have been used as domain knowledge for requirement elicitation [35]. The proposed approach requires human effort to map requirements to concepts in ontology. Inference rules on the ontology sys- tem are then used to detect incompleteness and inconsistency of requirements description. Our approach is different as it analyzes specs in the hardware do- main and uses heuristic rules to model expertise of a design expert. We assume that ontologies are built by design experts and that description of techniques to automatically build ontologies is beyond the scope of this work. Research has been done in the past to extract ontological concepts by 2.2 prior work 16
applying text-mining techniques to natural language documents [36], which can assist design experts in ontology generation. Various approaches have been proposed for extracting a formal specifica- tion from an informal specification written in natural language such as En- glish [37][38][39]. Our approach is not concerned with generating a formal specification. We are extracting features from a specification document and do feature based specification analysis. In a natural language processing (NLP) approach, knowledge representa- tion schemes in the form of conceptual graphs have been proposed for block diagrams, flowcharts, timing diagrams, and text [37]. This approach provides conceptual graphs for each format with an algorithm for automatically extract- ing conceptual structures from the specification document. The technique as- sumes a restricted subset of English for describing specifications and requires feedback from an expert to verify the extracted conceptual structures. In our proposed method for specification analysis, we avoid natural language process- ing (NLP) techniques or putting any restrictions of having a restricted subset of English in specification documents. In addition, we also propose a format for certain notations in specification documents to capture their description e.g. Register specification template. We also propose a flow to convert finite state machine diagrams to their formal representation when drawn with Dia, an open source tool [8]. For generating formal specifications, limited semantic expressibility of com- putation tree logic (CTL) has been exploited to derive a hierarchy of subsets of English sentences that correspond to a CTL expression [38]. This approach for automatic conversion of English to CTL requires a restricted subset of English to minimize ambiguity with respect to the formal specification language. In reference [40], the authors propose natural language representation of temporal logic formulas by introducing patterns of structured English lan- guage that correspond to Clocked CTL (CCTL) specification. Sentences are 2.2 prior work 17
compiled by a user by selecting these patterns. The user compiles a specifi- cation by selecting patterns and combining them into meaningful sentences, which directly correspond to a CCTL formulae. The approach assumes a sub- set of English and a library of patterns and their mapping to a CCTL represen- tation. In semi-formal techniques, textual use-case based specification of the sys- tem has been proposed [39]. The use-cases define the behavior of a system as a sequence of interaction steps under certain conditions and are written in a structured English language to act as the formal description of design behav- ior. The use-cases are then processed to generate constraints and test-cases for a random verification environment. Our approach is different from the above techniques as it avoids in-depth NLP and does not assume a restricted subset of English in specs. The in-depth NLP based approach is very complex and computationally expensive. NLP is not required for our approach as we focus on a limited domain specific aspect of text. We are not processing documents for general linguistic context. We avoid the difficulties of NLP by using domain specific feature extraction. Our KB system facilitates feature extraction by using design ontology models and a spec rule-base.
2.2.2 Reverse Engineering
IP design process begins with a specification and, through a succession of refinements, produces an implementable design. Reverse engineering is a pro- cess of back-tracing an implementation to its functional specification [41][42]. The application of our work can also be the reverse engineering of RTL design behavior. Reverse engineering has been an active topic of research over the years. There are few approaches related to our knowledge guided IP analy- sis methodology. Most of the techniques proposed for reverse engineering are 2.2 prior work 18
based on analyzing a gate-level net-list or integrated circuit die [43][44]. Our approach addresses reverse engineering of RTL, which is at a higher level of abstraction than gate and die level. Techniques that reverse engineer gate-level net-lists in order to determine the higher-lever structure have been demonstrated on ISCAS-85 benchmark circuits [45]. One technique first identifies library modules, for example, an adder from the gate-level net-list. It then tries to identify repetition of the basic circuit blocks and then higher level functions. In [46], HDL reverse engineering tools are proposed based on structural analysis of the VHDL source code. In this work, reverse engineering is manually accomplished by using graphical representation of design data. An approach has been proposed to reverse engineer a net-list from a pack- aged IC [44]. The proposed solution primarily uses scan operations and IC specification. The circuit connectivity is discovered by generating a set of tests that detect specific input/output dependencies, existing in the specification, and on using the test to assert that the discovered dependencies are imple- mented in the manufactured circuit. The discovered dependencies are com- bined to form an interconnected circuit. The functions are determined by enu- merating the input combinations of the function dependent variables, applying each input combination to the circuit, and computing the behavior at the out- put. In reference [47], a technique has been proposed to extract behavioral pat- terns from the simulation trace of gate-level net-lists and to represent them as a pattern graph. The pattern graph for a untrusted circuit is compared against pattern graphs of a library of trusted circuits using sub-graph isomorphism. This results in input-output correspondences between two patterns graphs. The closest matching component is then chosen and its specification are used for model checking of the gate-level net-list of the untrusted circuit. 2.2 prior work 19
2.2.3 IP Quality and RTL Analysis
Various approaches have been proposed for IP quality evaluation [48][49]. Quality metrics have been proposed in the past such as Quality Intellectual Property (QIP) by virtual socket interface alliance (VSIA) [48]. The VSIA iden- tified four factors that determine overall quality of IP: authoring, verification, the maturity of the IP, and the capabilities of the provider. Our approach pro- vides additional spec coverage and functional identification coverage metrics to quantify IP design quality. In industry, the so called lint tools are primarily used to check RTL design quality. These tools such as Spyglass from Atrenta, HAL from Cadence and Leda from Synopsys catch RTL coding errors early in the design cycle [50]. The lint tools generally have powerful rule sets that check design issues with respect to DFT (Design for testability), synthesis, naming conventions and de- sign style. These tools also do clock domain crossing (CDC) checks. The basic principle used in these tools is static analysis of RTL code. These tools do not analyze specification to RTL correspondences. For IP Quality analysis, an approach proposed by industry is to document all aspects of an IP using an XML data book format as specified in IP-XACT standard (IEEE 1685-2009)[51]. IPXACT provides meta-data to describe com- ponents, design interfaces, ports, registers, component instances, connections between components and configurable attributes of an IP. The limitation of IP-XACT is that it captures part of spec relevant to integration but does not capture the behavioral specifications of the IP. Our approach complements IPX- ACT structural specification by providing design ontology, which can be used to analyze behavioral specification. 2.2 prior work 20
2.2.4 KB System
KB systems based on artificial intelligence (AI) technology have been pro- posed in the past for fast prototyping of hardware designs and for hardware- software partitioning [52][53]. IBM estimates that it has saved more than $100 million during the last decade in direct development costs and reduced time to market by using AI technology for the verification of its processors [54]. Our validation approach is also an AI based technique but the application of our work is analyzing specification to RTL correspondences without performing exhaustive simulations. 3
OVERVIEWOFMETHODOLOGY
abstract
In this chapter, we provide an overview of our knowledge-guided method- ology. We present the organizational structure of our KB system. We provide a brief introduction of our specification and RTL analysis techniques. The key concepts like back-annotation technique and confidence/identification cover- age metrics are also discussed. At the end, we provide a brief introduction to the CLIPS expert system shell and the usage of XML format for representing spec information that can be easily extracted.
3.1 kb system overview
The main elements of our technique are: (a) a KB of trusted Specs and RTL, (b) property based models for common third party IP blocks (c) specification analysis, (d) RTL analysis, and (e) back-annotation of inferred RTL functional- ity to specification. Fig.8 provides an overview of knowledge base generation and Fig.9 provides an overview of knowledge base application for third party IP analysis. We have used the expert system shell CLIPS, with its powerful infer- ence engine to help us generate the Spec and RTL KBs and perform rule based analysis [3]. The generation of the KB is an incremental process, as the KB is en- hanced with addition of new rules, designs and associated knowledge. Every IP in the KB is considered as trusted design, built previously by experienced
21 3.1 kb system overview 22
Knowledge Base
Design standards Spec KB Spec Specs Extraction Spec Ontologies
Spec Rule-base
IP … IP Expert RTL KB
RTL Property-based RTL Analysis Models
RTL Rule-base
Figure 8: Knowledge Base Generation
designers. The third party IP analysis involves a rule-based search process, which checks the existence of trusted design properties in an untrusted design. Thus correspondences between third party RTL and its original trusted spec are inferred through the KB search by matching CLIPS rules. Our methodology can be used to analyze soft IPs based on standards, such as IEEE-754 floating point standard. We also use the concept of design domain, which we define as a family of soft IP designs that have common application, such as a bus interface domain. There are property similarities of designs within a domain. From analysis of specifications of various vendor specs, we observed that new SoC designs are built mostly by reusing and integrating existing IPs that are properly configured according to the specification. Therefore our approach of building spec/RTL rule-base, ontology, and property based models for each 3.1 kb system overview 23
Knowledge Base
Spec 3rd Party Extraction IP Spec Spec KB Spec Spec Ontologies CLIPS facts
Spec Rule-base Spec Analysis
Spec annotations Output Spec 2 RTL mismatches. Specification coverage Back-annotation RTL identification coverage Annotation Reports RTL KB RTL annotation Property-based Models RTL Analysis
RTL Rule-base 3rd Party RTL to CLIPS IP RTL
Figure 9: Knowledge Base Application for third-Party IP Analysis
design domain is a one time exercise while building the KB. The manual effort is high initially and is minimal afterwards. The reuse of the KB across multiple projects justifies the initial effort. In addition, our approach is well suited for platform based SoCs, which is a family of similar chips that differ for one or more components but that are based on the same processor. The knowledge base development is initially done for a limited number of IP’s that are common across SoC’s. Fig.10, Fig.11, and Fig.12 show block dia- grams of SoCs from Texas Instruments, Marvell semiconductor and Freescale respectively [4][5][6]. These SoCs have some common IP blocks such as SPI, UART, USB, I2C, Timers, PWM and we therefore add these designs to the KB. 3.1 kb system overview 24
The bus-interface protocol standards such as AHB/APB [55] are also added to the KB. Electronic design automation (EDA) companies, such as Cadence and Syn- opsys have verification IPs (VIP) for a limited number of design domains that act as reference models in simulation based verification [56][57]. The KB de- velopment effort can be considered similar to the VIP library development done by EDA companies. The differences are that our methodology provides techniques for performing rule-based specification and RTL analysis.
Figure 10: OMAP4470 application processor from Texas Instruments [4]
In the following sections, we briefly describe each element of our technique.
3.1.1 Knowledge Base Organization
The KB has a repository of trusted soft IP’s organized under the IPLIB directory. Fig.13 provides an overview of the KB organization. The KB has a pre-defined directory structure for storing information, and each IP database 3.1 kb system overview 25
Figure 11: Marvell ARMADA 510 (88AP510) Application Processor [5]
acts as a leaf node in this organization. For each trusted IP in the KB, we have its spec representations, RTL code representations, specific CLIPS rules that are executed on specs/RTLs, testing vectors, and design implementation scripts. The KB is structured in a way to simplify search of relevant information in specs or RTL. It also allows a user to selectively apply a part of the KB to analyze an untrusted design. Fig.13 provides an overview of the KB organization. The IPLIB directory is further categorized as per the design domain, the corresponding IP name and its specific vendor. The rules are available at each level. The rules at a do- main level are more generic than rules at the IP level and vendor levels. The directory structure at the IP level provides a uniform representation of each IP in terms of its RTL, Specs, Spec/RTL rules, and test vectors. 3.2 specification kb overview 26
Figure 12: FreeScale i.MX25 Application Processor [6]
3.2 specification kb overview
The Spec-KB is built by extracting knowledge from specification docu- ments of previous trusted designs and through addition of heuristic rules written by design experts. We partition the specification document into spec objects of three major types: (a) Text object, refers to a block of textual descrip- tion of a specification module, which may include its function, object attributes and their values, properties, exception modes, and constraints. For example, a text object for a clock could have a gating clock property, clock frequency at- tribute, and special timing constraints. (b) Tabular objects comprise tables and listings such as instruction formats, register maps, I/O and parameter lists. (c) Drawing objects comprise diagrammatic specification descriptions such as block diagrams, timing diagrams, state charts. As with text objects, properties, attributes and constraints may be extracted from drawing objects. Note that the spec objects (text, tabular or drawing) may contain hierarchies of other ob- 3.2 specification kb overview 27
KNOWLEDGE BASE
LEX IPLIB MISC
DOMAIN Processor Interface Peripheral … Memory Rules Ontology Manifest/Index
STANDARD SSP I2C SPI … UART Rules Ontology
VENDOR Rockwell ST … ARM Rules Ontology
IP-PACKAGE RTL SPEC RTL-FACTS SPEC-FACTS SCRIPTS TEST Rules Ontology
Figure 13: Knowledge Base organization overview jects. An important aspect of our work is to format the spec objects into tabu- lar fields, in particular we use rule-based templates composed of production rules and multi-field facts containing the object characteristics. We have built domain ontologies to capture text-objects that express salient features of each design domain. We extract the specifications from block diagrams and state machine di- agrams by parsing the scalar vector graphics (SVG) format representation of these objects. The spec is finally represented in a CLIPS fact based representa- tion. Any new IP spec is then analyzed by first representing it in a CLIPS fact based format and then performing rule-based analysis to find correspondence with the Spec-KB. The main purpose of specification analysis is to be able to extract relevant functional information about the document and compare it with previously analyzed specification documents in Spec-KB. The ability to extract and com- pare relevant information from the specification document is independent of the design vendor or writing style of the document author. The key elements 3.2 specification kb overview 28 of specification analysis are: (a) specification information extraction, and (b) specification ontology.
Specification Information Extraction
This transforms an English specification document into a unique CLIPS fact based representation, containing most important information about the document, while, providing a framework for uniform comparison between the extracted information from multiple documents. We have developed a spec extractor tool to automatically convert English documents into a CLIPS fact based representation.
Specification Ontology
This captures salient features of the design and builds a concept graph of design keywords, their attributes and relationships. It acts as a semantic net- work for a design domain, which is then used to perform spec analysis. Fig.14 provides a fragment of a semantic network for the serial peripheral interface domain. The key concepts of interface based designs are shown as nodes along with their attributes and are connected through relationships in the network. Relationships help to capture semantic information for a design domain. For example, in Fig.14, the has-a relation signifies a must have lower-level func- tion or feature, while a relationship may-have signifies an optional feature for a node in the semantic network. A specification ontology is superset of keywords for a particular domain (FPU, Memory Controllers, ARM chips, SPI, etc). The ontology is able to de- scribe the functional details for all variations of a particular IP design domain. 3.3 rtl kb overview 29
3.3 rtl kb overview
Our RTL analysis methodology performs static analysis (SA) of RTL code. We also perform local evaluation of code fragments in CLIPS. In general, SA based techniques are used to identify possible bugs in code as well as indicate how closely certain segments of code match specifications. In theoretical com- puter science, through Rice’s theorem and the undecidability of the halting problem, it has been proved that finding any kind of violation of a specifi- cation on the final result of a program is undecidable [58]. The only way to determine how a program will behave is to perform exhaustive simulations. In any case, being forewarned about a bug is valuable as it gives immediate feedback about what may be wrong in the implementation [59]. In our approach, we address the limitations of SA techniques by perform- ing evaluation of code fragments to better approximate design behavior. We are not doing design verification, in the sense of finding bugs in the design. We are validating that the design meets the specifications by levels of confidence. The RTL-KB is built by representing RTL of trusted designs in RTL-CLIPS format. RTL-CLIPS is a semantically equivalent translation of RTL code into CLIPS facts. A property based model for each design domain is also added to the RTL-KB. A property is a partial specification that contains some element of the expected design behavior. A property based model for a design is generated through hierarchical func- tional decomposition of design behavior into behavioral functions and associ- ated attributes. The expert generates the property-based model for trusted de- signs. The RTL-CLIPS fact format is used for rule based pattern matching for concept to code association. The CLIPS rules are written by creating a pattern using a set of RTL-CLIPS facts that are sufficient to make a inference. When a match is achieved, the rule fires and an inference is made, thus asserting new facts. 3.4 confidence and coverage metrics 30
3.4 confidence and coverage metrics
The spec and RTL rules search for matching behavioral properties associ- ated with trusted designs in the third Party IP Specs and RTL. There may only be a partial match of properties between trusted designs and third-Party IP. The matching properties may be of more significance to unmatched properties or vice-versa. Our approach provides a technique where an expert’s knowl- edge about the significance of a behavioral property towards inferring a design functionality is quantified.
Rule A1 Combinational CF1 = 0.1 logic Merge Rule Infer barrel barrel-shift CF = CF1 + CF2 – (CF1* CF2) shifter Rule 2 = 0.64 Logical shift left CF2 = 0.6 operation
Figure 15: Confidence factor merging using parallel combination formula
The methodology has a confidence factor (CF) associated with each rule in the RTL rule-base to support partial matching and accommodate expert knowledge about the significance of a design property. The CF given to the rule by an expert is in the range of zero to one. CF is the likelihood of being ac- curate in inferring a design function when a particular design property exists in Specs or RTL code. The CF allows the rule base to identify high level design functions even for partial matching of the behavioral properties. The CF’s are merged for rules inferring a function at the same hierarchical level using par- allel combination formula. Fig.15 provides an example of CF’s merging for a set of rules, which together infer a barrel-shifter logic based on existence of a logical left shift operation and the operation being combinational logic. We produce the CF of inferring a higher level module, based on the ex- istence of lower modules, by the average (possibly weighted) of the CF’s of 3.5 introduction to clips and xml 31
lower level modules. The CF for inferring a property increases if it is inferred in third party IP Specs by the Spec rule-base, and is also inferred in RTL code by the RTL rule-base. However, the CF decreases if a property found in Specs does not exist in the RTL or vice-versa. Coverage is an important concept in RTL validation and is defined in terms of code coverage metrics. The coverage metrics in our case concern function- ality identification coverage, thus our metrics are expressed in terms of con- fidence factors. Our emphasis is on identifying the functionality of soft IP design modules based on the existence of their behavioral properties. This pro- cess does not necessarily guarantee valid design behavior. Our methodology does produce confidence factors by which a soft IP and all its functions have been correctly identified in the RTL hierarchy.
3.5 introduction to clips and xml
We have used the CLIPS fact based format for spec and RTL knowledge representation. In our method, XML format of specs is used as input for spec analysis. In what follows we provide a brief introduction to CLIPS and XML.
3.5.1 CLIPS Expert System Shell
We have used CLIPS (C Language Integrated Production System) expert system to analyze specification and RTL. CLIPS is an expert system shell origi- nally developed by the Artificial Intelligence section of NASA’s Johnson Space Center and is written in C [3]. It also includes an object-oriented language called COOL (CLIPS Object-Oriented Language), which is directly integrated with the inference engine. CLIPS uses a forward-chaining inference strategy based on the Rete pattern-matching algorithm [24]. The CLIPS shell provides the following basic elements of an expert system: 3.5 introduction to clips and xml 32
• fact-list and instance-list : Global memory for data
• knowledge-base : Contains all the rules, the rule-base
• inference engine : Controls overall execution of rules
A program written in CLIPS may consist of rules, facts, and objects. The inference engine decides which rules should be executed and when. A rule- based expert system written in CLIPS is a data-driven program where the facts, and objects if desired, are the data that stimulate execution via the inference engine [3]. A fact consists of a relation name (a symbol field) followed with zero or some slots (also symbol fields) and their relevant value. The deftemplate construct is used to create a template, which can then be used by non-ordered facts to access fields of the fact by name. The syntax of the deftemplate con- struct is:
1 (deftemplate
One of the primary methods of representing knowledge in CLIPS is an IF THEN rule [3]. A rule is composed of an antecedent and a consequent. The an- tecedent of a rule is a set of conditions (or conditional elements), which must be satisfied for the rule to be applicable. Rules are defined using the defrule construct. The syntax of the defrule construct is:
(defrule
3.5.2 XML
XML stands for Extensible Markup Language. XML is designed to struc- ture, store and transport data, with focus on what data is [60]. The difficulties 3.5 introduction to clips and xml 33 with word processor documents, spreadsheets and other form of documenta- tion is that they mix structure with formatting [61][62]. This makes it difficult to manage content and design, because the two are intermingled. XML can be used for sharing data among applications that hold data in different structures. A predefined XML structure can be used as an intermediate format between different applications. Adobe Acrobat and Microsoft Word are the popular documentation software programs and both support XML output to be stored from the documents written in pdf or doc format. A document type definition (DTD) defines the legal building blocks of an XML document. It defines the document structure with a list of legal ele- ments and attributes. XML document structure consists of elements with a root element, which contains other elements and so on. The data stored in each ele- ment is delimited by a start tag and end tag associated with the element name. A tag acts as boundary for data that the element stores. We use XML format of specification documents as input to our spec-extractor tool. XML provides documents structure, which can be used to extract data along with its location in the document and further classify data that is textual, tabular, or diagram- matic. Table 1 is a fragment of a signal description table from an open cores FPU specification document [63].
Signal Name Width Description clk_i 1 clock signal
Table 1: Fragment of Signal Description table from an Opencores FPU Spec
A text version of same document does not contain any tags and therefore cannot be used to classify/extract tabular data. The corresponding XML frag- ment of the document is shown below and contains the tags
| that identify a table, table row and table column data respectively. Thus, the XML tags aid in extraction of tabular data from the specification. 3.5 introduction to clips and xml 34 1 2 3 4
") 43 file.write(" ") 44 88 A.1 html register table and register test-bench generation 89 45 def regmap_accs(file,temp1,bit,access): 46 file.write(" \n") 48 file.write("access type") 49 file.write(" | \n") 50 for x in range(0,len(access)): 51 x1=0; 52 y1=0; 53 p=str(bit[x]) 54 a= ’:’ in p 55 if a==1: 56 b=p[:3] 57 d=p[3:7] 58 if b >=31: 59 c= ’:’ in b 60 if c==1: 61 x1=b[0:-1] 62 else: 63 x1=b 64 if d >=0: 65 e= ’:’ in d 66 if e==1: 67 y1=d[1:3] 68 else: 69 y1=d 70 if y1>0: 71 for z in range(int(y1),int(x1)+1): 72 file.write("") 73 file.write(access[x]) 74 file.write(" | ") 75 else: 76 file.write("") 77 file.write(access[x]) 78 file.write(" | ") 79 file.write("\n") 85 file.write("reset value") 86 file.write(" | \n") 87 for x in range(0,len(val)): 88 tval=val[x]; 89 pval=tval[2:] 90 if pval.upper()=="A": 91 pval="10" 92 if pval.upper()=="B": 93 pval="11" 94 if pval.upper()=="C": 95 pval="12" 96 if pval.upper()=="D": 97 pval="13" 98 if pval.upper()=="E": 99 pval="14" 100 if pval.upper()=="F": 101 pval="15" 102 value+=int(pval) 103 file.write("\n") 104 if value=="0": A.1 html register table and register test-bench generation 90 | ") 110 file.write("105 value="0x00000000" 106 else : 107 value="0x0000%s"% pval 108 file.write(value) 109 file.write(" \n") 115 file.write("field") 116 file.write(" | \n") 117 file.write("\n") 118 for x in range(0,len(fld)): 119 file.write("") 120 file.write("[") 121 val= str(bit[x]) 122 file.write(val) 123 file.write("]") 124 file.write("") 125 file.write(fld[x]) 126 file.write(":\n") 127 file.write("") 128 file.write(" | ") 138 file.write("") 129 file.write(" ") 130 file.write(" ") 131 file.write(" ") 132 file.write(" ") 133 file.write(" ") 134 file.write(str(des[x])) 135 file.write(" ") 136 file.write(" ") 137 file.write("
285 filep.write( "logic "+intf[i]+"; \n") 286 else: 287 filep.write( "logic ["+bits[i]+"] "+intf[i]+";\n") 288 for i, j in enumerate(sigs): 289 if j == ’pwrite’: 290 if bits[i]==1.0: 291 filep.write( "logic "+intf[i]+"; \n") 292 else: 293 filep.write( "logic ["+bits[i]+"] "+intf[i]+";\n") 294 for i, j in enumerate(sigs): 295 if j == ’psel’: 296 if bits[i]==1.0: 297 filep.write( "logic "+intf[i]+"; \n") 298 else: 299 filep.write( "logic ["+bits[i]+"] "+intf[i]+";\n") 300 for i, j in enumerate(sigs): 301 if j == ’penable’: 302 if bits[i]==1.0: 303 filep.write( "logic "+intf[i]+"; \n") 304 else: 305 filep.write( "logic ["+bits[i]+"] "+intf[i]+";\n") 306 for i, j in enumerate(sigs): 307 if j == ’pready’: 308 if bits[i]==1.0: 309 filep.write( "logic "+intf[i]+"; \n") 310 else: 311 filep.write( "logic ["+bits[i]+"] "+intf[i]+";\n") 312 313 def cb_mas(file,bits,sigs,intf): 314 file.write("\n") 315 file.write("clocking mas @(posedge pclk);\n") 316 file.write(" output ") 317 for i,j in enumerate(sigs): 318 if j == "penable": 319 file.write(intf[i]+",") 320 elif j == "psel": 321 file.write(intf[i]+";\n") 322 elif j == "pwrite": 323 file.write(intf[i]+",") 324 elif j == "pwdata": 325 file.write(intf[i]+",") 326 elif j == "paddr": 327 file.write(intf[i]+",") 328 file.write(" input ") 329 for i,j in enumerate(sigs): 330 if j == "prdata": 331 file.write(intf[i]+";\n") 332 file.write("endclocking\n") 333 file.write("\n") 334 335 def cb_slv(file,bits,sigs,intf): 336 file.write("\n") 337 file.write("clocking slv @(posedge pclk);\n") 338 file.write(" input ") 339 for i,j in enumerate(sigs): 340 if j == "penable": 341 file.write(intf[i]+",") 342 elif j == "psel": 343 file.write(intf[i]+";\n") 344 elif j == "pwrite": A.1 html register table and register test-bench generation 94 345 file.write(intf[i]+",") 346 elif j == "pwdata": 347 file.write(intf[i]+",") 348 elif j == "paddr": 349 file.write(intf[i]+",") 350 file.write(" output ") 351 for i,j in enumerate(sigs): 352 if j == "prdata": 353 file.write(intf[i]+";\n") 354 file.write("endclocking\n") 355 file.write("\n") 356 357 def cb_pas(file,bits,sigs,intf): 358 file.write("\n") 359 file.write("clocking pas @(posedge pclk);\n") 360 file.write(" input ") 361 for i,j in enumerate(sigs): 362 if j == "penable": 363 file.write(intf[i]+",") 364 elif j == "psel": 365 file.write(intf[i]+",") 366 elif j == "pwrite": 367 file.write(intf[i]+",") 368 elif j == "prdata": 369 file.write(intf[i]+";\n") 370 elif j == "pwdata": 371 file.write(intf[i]+",") 372 elif j == "paddr": 373 file.write(intf[i]+",") 374 file.write("endclocking\n") 375 376 def blq_line(file): 377 file.write("\n") 378 379 def strt_run(file): 380 file.write("\n") 381 file.write(" virtual protected task run_phase(uvm_phase phase);\n") 382 file.write(" super.run_phase(phase);\n") 383 file.write("\n") 384 return; 385 386 def cons_wrt(file,port): 387 file.write("\n") 388 file.write(" function new(string name, uvm_component parent = null);\n") 389 file.write(" super.new(name, parent);\n") 390 if port!="nope": 391 file.write(’’+port+’= new("’+port+’",this);\n’) 392 file.write(" endfunction\n") 393 file.write("\n") 394 return; 395 396 def cons_pkt(file,prot): 397 file.write("\n") 398 file.write(’ function new(string name = "’+prot+’");\n’) 399 file.write(" super.new(name);\n") 400 file.write(" endfunction\n") 401 file.write("\n") 402 return; 403 404 def strt_bld(a,b,vif,file): A.1 html register table and register test-bench generation 95 405 file.write(" virtual function void build_phase(uvm_phase phase);\n") 406 file.write(""+a+"_agent agent;\n") 407 file.write(" if($cast(agent,get_parent()) && agent !=null) begin\n") 408 file.write(" vif=agent.vif;\n") 409 file.write(" end else begin\n") 410 if vif!="vif": 411 file.write(" virtual "+a+"_if "+vif+"; \n") 412 file.write(’ if (!uvm_config_db#(’+a+’_vif)::get(this, "", "vif",’+vif+’)) begin\n’) 413 file.write(’ ‘uvm_fatal("’+a+’_agent", "No virtual interface specified for this ’+b+’ instance")\n’) 414 file.write(" end\n") 415 if vif!="vif": 416 file.write(" vif = "+vif+";\n") 417 file.write(" end\n") 418 file.write(" endfunction\n") 419 file.write("\n") 420 return; 421 422 def strt_conn(file,sub_comps): 423 file.write("\n") 424 file.write(" virtual function void connect_phase(uvm_phase phase);\n") 425 file.write(""+sub_comps[0]+".seq_item_port.connect("+sub_comps[1]+".seq_item_export);\n") 426 file.write(" endfunction\n") 427 file.write("\n") 428 429 def run_rd(pro,intf,file): 430 if pro=="apb": 431 file.write(" virtual protected task read(input bit [31:0] addr,\n") 432 file.write(" output logic [31:0] data);\n") 433 file.write("\n") 434 file.write(" this.vif.mcb."+intf[2]+"<=addr;\n") 435 file.write(" this.vif.mcb."+intf[5]+"<=1’b0;\n") 436 file.write(" this.vif.mcb."+intf[6]+"<=1’b1;\n") 437 file.write(" @(this.vif.mcb);\n"); 438 file.write(" this.vif.mcb."+intf[7]+"<=1’b1;\n") 439 file.write(" @(this.vif.mcb);\n") 440 file.write(" data=this.vif.mcb."+intf[4]+";\n") 441 file.write(" this.vif.mcb."+intf[6]+"<=0’b1;\n") 442 file.write(" this.vif.mcb."+intf[7]+"<=0’b1;\n") 443 file.write(" endtask \n") 444 file.write("\n") 445 elif pro=="ahb": 446 file.write(" virtual protected task read(input bit [31:0] addr,\n") 447 file.write(" output logic [31:0] data);\n") 448 file.write("\n") 449 file.write(" this.vif.mcb."+intf[2]+"<=addr;\n") 450 file.write(" this.vif.mcb."+intf[5]+"<=1’b0;\n") 451 file.write(" this.vif.mcb."+intf[6]+"<=1’b1;\n") 452 file.write(" @(this.vif.mcb);\n"); 453 file.write(" this.vif.mcb."+intf[7]+"<=1’b1;\n") 454 file.write(" @(this.vif.mcb);\n") 455 file.write(" data=this.vif.mcb."+intf[4]+";\n") 456 file.write(" this.vif.mcb."+intf[6]+"<=0’b1;\n") 457 file.write(" this.vif.mcb."+intf[7]+"<=0’b1;\n") 458 file.write(" endtask \n") 459 file.write("\n") 460 elif pro=="wsb": 461 file.write(" virtual protected task read(input bit [31:0] addr,\n") 462 file.write(" output logic [31:0] data);\n") 463 file.write("\n") 464 file.write(" this.vif.mcb."+intf[2]+"<=addr;\n") A.1 html register table and register test-bench generation 96 465 file.write(" this.vif.mcb."+intf[5]+"<=1’b0;\n") 466 file.write(" this.vif.mcb."+intf[6]+"<=1’b1;\n") 467 file.write(" @(this.vif.mcb);\n"); 468 file.write(" this.vif.mcb."+intf[7]+"<=1’b1;\n") 469 file.write(" @(this.vif.mcb);\n") 470 file.write(" data=this.vif.mcb."+intf[4]+";\n") 471 file.write(" this.vif.mcb."+intf[6]+"<=0’b1;\n") 472 file.write(" this.vif.mcb."+intf[7]+"<=0’b1;\n") 473 file.write(" endtask \n") 474 file.write("\n") 475 476 def run_wr(pro,intf,file): 477 if pro=="apb": 478 file.write(" virtual protected task write(input bit [31:0] addr,\n") 479 file.write(" input bit [31:0] data);\n") 480 file.write("\n") 481 file.write(" this.vif.mcb."+intf[2]+"<=addr;\n") 482 file.write(" this.vif.mcb."+intf[3]+"<=data;\n") 483 file.write(" this.vif.mcb."+intf[5]+"<=1’b1;\n") 484 file.write(" this.vif.mcb."+intf[6]+"<=1’b1;\n") 485 file.write(" @(this.vif.mcb);\n"); 486 file.write(" this.vif.mcb."+intf[7]+"<=1’b1;\n") 487 file.write(" @(this.vif.mcb);\n"); 488 file.write(" this.vif.mcb."+intf[6]+"<=0’b1;\n") 489 file.write(" this.vif.mcb."+intf[7]+"<=0’b1;\n") 490 file.write(" endtask \n") 491 file.write("\n") 492 493 def drv_run(protocol,intf,a,file): 494 if protocol=="apb": 495 file.write(" this.vif.mcb."+ intf[6]+" <=1’b0; \n") 496 file.write(" this.vif.mcb."+ intf[7]+" <=1’b0; \n") 497 file.write("\n") 498 file.write(" forever begin\n") 499 file.write(""+a+"_rw trans;"); 500 file.write(" @(this.vif.mcb) ;"); 501 file.write("\n") 502 file.write(" seq_item_port.get_next_item(trans);\n") 503 file.write(" @(this.vif.mcb) ;"); 504 file.write("\n") 505 file.write(" case(trans.kind)\n") 506 file.write(""+a+"_rw::READ : this.read(trans.addr,trans.data);\n") 507 file.write(""+a+"_rw::WRITE: this.write(trans.addr,trans.data);\n") 508 file.write(" endcase\n") 509 file.write(" \n") 510 file.write(" seq_item_port.item_done();\n") 511 file.write(" -> trig;\n") 512 file.write(" end\n") 513 file.write(" endtask\n") 514 file.write(" \n") 515 run_rd(protocol,intf,file) 516 run_wr(protocol,intf,file) 517 518 def mon_run(protocol,intf,a,file): 519 if protocol=="apb": 520 file.write(" forever begin\n") 521 file.write(""+a+"_rw trans;"); 522 file.write("\n") 523 file.write(" do begin\n") 524 file.write(" @(this.vif.pas) ;\n"); A.1 html register table and register test-bench generation 97 525 file.write(" end\n") 526 file.write("\n") 527 file.write(" while (this.vif.pas."+intf[6]+" !== 1’b1 ||\n") 528 file.write(" this.vif.pas."+intf[7]+" !== 1’b0);\n") 529 file.write("\n") 530 file.write(’ trans=’+a+’_rw::type_id::create("trans", this);\n’) 531 file.write("\n") 532 file.write(" trans.kind = (this.vif.pas."+intf[5]+"?"+a+"_rw:: WRITE :"+a+"rw:: READ ;\n") 533 file.write(" trans.addr = this.vif.pas."+intf[2]+";\n") 534 file.write(" \n") 535 file.write(" @(this.vif.pas) ;\n"); 536 file.write(" if(this.vif.pas."+intf[7]+"!== 1’b1) begin \n"); 537 file.write(’ ‘uvm_error("APB", "APB protocol violation: SETUP cycle not followed by ENABLE cycle");\n’); 538 file.write(" end\n") 539 file.write(" trans.data=(trans.kind =="+a+"_rw::READ) ? this.vif.pas."+intf[4]+": \n") 540 file.write(" this.vif.pas."+intf[3]+"; \n") 541 file.write(" \n") 542 file.write(" ana_port.write(trans);\n") 543 file.write(" \n") 544 file.write(" end\n") 545 file.write(" endtask\n") 546 file.write(" \n") 547 548 def gen_adapt(file,prot): 549 file.write("class reg2"+prot+"_adapter extends uvm_reg_adapter;\n") 550 file.write("\n") 551 file.write(" uvm_object_utils(reg2"+prot+"_adapter)\n") 552 file.write("\n") 553 value="reg2%s_adapter"% prot 554 cons_pkt(file,value) 555 file.write(" virtual function uvm_sequence_item reg2bus(const ref uvm_reg_bus_op rw);\n") 556 if prot=="apb": 557 file.write(’ apb_rw apb = apb_rw::type_id::create("apb_rw");\n’) 558 file.write(" apb.kind = (rw.kind == UVM_READ) ? apb_rw::READ : apb_rw::WRITE;\n") 559 file.write(" apb.addr = rw.addr;\n") 560 file.write(" apb.data = rw.data;\n") 561 file.write(" return apb;\n") 562 file.write(" endfunction\n") 563 file.write("\n") 564 file.write(" virtual function void bus2reg(uvm_sequence_item bus_item,\n") 565 file.write(" ref uvm_reg_bus_op rw);\n") 566 file.write(""+prot+"_rw "+prot+";\n") 567 file.write(" if(!$cast("+prot+",but_item))begin\n") 568 file.write(’ ‘uvm_fatal("Type Missmatch :’+prot+’","Provided bus_item is not of the correct type")\n’) 569 file.write(" return\n") 570 file.write(" end\n") 571 if prot=="apb": 572 file.write(" rw.kind = apb.kind == apb_rw::READ ? UVM_READ : UVM_WRITE;\n") 573 file.write(" rw.addr = apb.addr;\n") 574 file.write(" rw.data = apb.data;\n") 575 file.write(" rw.status = UVM_IS_OK;\n") 576 file.write(" endfunction\n") 577 file.write("endclass\n") 578 579 class Sv_Interface: 580 def gen_intf(self,xlsfile): 581 import xlrd 582 workbook= xlrd.open_workbook(xlsfile) 583 worksheet= workbook.sheet_names() 584 worksheet1=worksheet[1] A.1 html register table and register test-bench generation 98 585 worksheet= workbook.sheet_by_name(worksheet1) 586 intf= worksheet.col_values(0, start_rowx=1) 587 bits= worksheet.col_values(2,start_rowx=1) 588 sigs= worksheet.col_values(7, start_rowx=1) 589 fo=open("apb_interface.sv","wb") 590 fo.write("interface apb_interface(input bit pclk);") 591 fo.write("\n") 592 fo.write("\n") 593 intf_write(fo,bits,sigs,intf) 594 fo.write("\n") 595 cb_mas(fo,bits,sigs,intf) 596 cb_slv(fo,bits,sigs,intf) 597 cb_pas(fo,bits,sigs,intf) 598 fo.write("\n") 599 fo.write("modport master(clocking mas);\n") 600 fo.write("modport slave(clocking slv);\n") 601 fo.write("modport passive(clocking pas);\n") 602 fo.write("\n") 603 fo.write("endinterface\n") 604 fo.close() 605 return intf; 606 607 #class Uvm_Env: 608 609 #class Uvm_Test: 610 # def gen_intf(self): 611 # print "This message is coming from Uvm_Test Class" 612 # 613 #class Uvm_Sequence: 614 # def gen_intf(self): 615 # print "This message is coming from Uvm_Sequence Class" 616 # 617 class Uvm_Pkg: 618 619 def gen_pkg(self,pkgname,pktname,f1,f2,f3,f4,prot): 620 file=open(pkgname,’w’) 621 file.write(’‘include "’+prot+’_interface.sv"’) 622 file.write("\n") 623 file.write("\n") 624 file.write(’packge ’+prot+’_pkg;\n’) 625 file.write("\n") 626 file.write(’ import uvm_pkg::*;\n ‘include "uvm_macros.svh"\n’) 627 file.write("\n") 628 file.write(’ typedef virtual ’+prot+’_interface ’+prot+’_vif;\n’) 629 file.write(’ typedef class ’+prot+’_agent;\n’) 630 file.write("\n") 631 file.write(’ ‘include "’+pktname+’\n’) 632 file.write(’ ‘include "’+f1+’\n’) 633 file.write(’ ‘include "’+f2+’\n’) 634 file.write(’ ‘include "’+f3+’\n’) 635 file.write(’ ‘include "’+f4+’\n’) 636 file.write("\n") 637 file.write(’endpackge’) 638 639 class Uvm_Pkt: 640 641 642 def gen_pkt(self,pktname,prot): 643 file=open(pktname,’w’) 644 file.write("class "+prot+"_rw extends uvm_sequence_item;\n") A.1 html register table and register test-bench generation 99 645 if prot=="apb": 646 file.write("\n") 647 file.write("typedef enum {READ, WRITE} kind_e;\n") 648 file.write("rand bit [31:0] addr;\n") 649 file.write("rand logic [31:0] data;\n") 650 file.write("rand kind_e kind;\n") 651 file.write("\n") 652 file.write("‘uvm_object_utils_begin(apb_rw)\n") 653 file.write("‘uvm_field_int(addr, UVM_ALL_ON);\n") 654 file.write("‘uvm_field_int(data, UVM_ALL_ON);\n") 655 file.write("‘uvm_field_enum(kind_e,kind, UVM_ALL_ON);\n") 656 file.write("‘uvm_object_utils_end\n") 657 prot1="%s_rw"% prot 658 cons_pkt(file,prot1) 659 file.write("function string convert2string();\n") 660 file.write(’ return $sformatf("kind=%s addr=%0h data=%0h",kind,addr,data);\n’) 661 file.write("endfunction\n") 662 file.write("\n") 663 file.write("endclass\n") 664 file.write("\n") 665 gen_adapt(file,prot) 666 667 class Uvm_Component: 668 669 def gen_comp(self,work,prot,intf): 670 671 if DEBUG==1: 672 print "This is message coming from inside Uvm_Component class." 673 674 comp_name="%s"% work[:-3] 675 work.split("_") 676 f= open(work, ’w’) 677 678 if DEBUG==1: 679 print "%s"% comp_name 680 a,b=comp_name.split("_") 681 if DEBUG==1: 682 print "%s"%a 683 if b=="agent": 684 f.write("class"+""+ comp_name+""+ "extends"+""+ "uvm_"+b+ ";"+" \n") 685 f.write("\n") 686 sub_comps=[’driver’,’sequencer’,’monitor’] 687 for sub_comp in sub_comps: 688 f.write(""+a+"_"+ sub_comp+""+ sub_comp+"; \n") 689 f.write("\n") 690 f.write(""+a+"_vif"+""+ "vif; \n") 691 f.write("\n") 692 693 f.write(" ‘uvm_component_utils_begin("+comp_name+")\n") 694 for sub_comp in sub_comps: 695 f.write(" ‘uvm_component_utils_begin("+ sub_comp+", UVM_ALL_ON) \n") 696 f.write(" ‘uvm_component_utils_end\n") 697 #Call Constructor 698 cons_wrt(f,"nope"); 699 700 f.write(" virtual function void build_phase(uvm_phase phase);\n") 701 for sub_comp in sub_comps: 702 f.write(’’+sub_comp+’=’+a+’_’+sub_comp+’::type_id::create("’+sub_comp+’", this); \n’) 703 f.write("\n") 704 A.1 html register table and register test-bench generation 100 705 f.write(’ if (!uvm_config_db#(’+a+’_vif)::get(this, "", "vif", vif)) begin\n’) 706 f.write(’ ‘uvm_fatal("’+a+’_agent", "No virtual interface specified for this agent instance")\n’) 707 708 f.write(" end\n") 709 f.write(" endfunction\n") 710 strt_conn(f,sub_comps) 711 if b=="sequencer": 712 f.write("class"+""+ comp_name+""+ "extends"+""+ "uvm_"+b+ " #("+a+"_rw);"+" \n") 713 f.write("\n") 714 f.write(" ‘uvm_component_utils("+comp_name+")\n") 715 cons_wrt(f,"nope"); 716 if b=="driver": 717 f.write("class"+""+ comp_name+""+ "extends"+""+ "uvm_"+b+ " #("+a+"_rw);"+" \n") 718 f.write("\n") 719 f.write(" ‘uvm_component_utils("+comp_name+")\n") 720 f.write("\n") 721 f.write(" event trig;\n") 722 f.write(""+a+"_vif vif ;\n") 723 cons_wrt(f,"nope"); 724 strt_bld(a,b,"vif",f); 725 strt_run(f); 726 drv_run(prot,intf,a,f) 727 if b=="monitor": 728 f.write("class"+""+ comp_name+""+ "extends"+""+ "uvm_"+b+ ";"+" \n") 729 f.write("\n") 730 f.write(" virtual"+a+"_if.passive vif; \n") 731 f.write(" uvm_analysis_port#("+a+"_rw) ana_port;\n") 732 f.write("\n") 733 cons_wrt(f,"ana_port"); 734 f.write("\n") 735 strt_bld(a,b,"tmp",f); 736 strt_run(f) 737 mon_run(prot,intf,a,f) 738 f.write("endclass\n") 739 f.close() 740 741 742 743 744 def env_gen(agname,protocol,regfile): 745 746 # Instance of Component Class 747 comp1=Uvm_Component() 748 comp2=Uvm_Component() 749 comp3=Uvm_Component() 750 comp4=Uvm_Component() 751 # Instance of Package Class 752 pkggen=Uvm_Pkg() 753 # Instance of Packet Class 754 pktgen=Uvm_Pkt() 755 # Instance of Interface Class 756 intgen=Sv_Interface() 757 758 # Instance of Enviroment Class 759 # env=Uvm_Env() 760 # Instance of Sequence Class 761 # Instance of Test Class 762 # Instance of Top Class 763 # Instance of Dummy Dut Class 764 A.1 html register table and register test-bench generation 101 765 # Instance of Reg Gen Class 766 reggen=Reg_Gen() 767 768 # Usage of Interface Class 769 interface=intgen.gen_intf(regfile) 770 771 cfile1="%s_agent.sv"% agname 772 cfile2="%s_driver.sv"% agname 773 cfile3="%s_sequencer.sv"% agname 774 cfile4="%s_monitor.sv"% agname 775 pkgfile="%s_pkg.sv"% agname 776 pktfile="%s_rw.sv"% agname 777 778 reggen.data_col(regfile) 779 pkggen.gen_pkg(pkgfile,pktfile,cfile1,cfile2,cfile3,cfile4,protocol) 780 pktgen.gen_pkt(pktfile,protocol) 781 comp1.gen_comp(cfile1,protocol,interface) 782 comp2.gen_comp(cfile2,protocol,interface) 783 comp3.gen_comp(cfile3,protocol,interface) 784 comp4.gen_comp(cfile4,protocol,interface) 785 786 def help(): 787 print "Help Usage:./tbdev.phy PROCESSINGDRAWINGOBJECTS b.1 extraction of fsm specfication from svg 1 #File name - fsmConverter.py 2 #usage - python fsmConverter.py fsm.svg 3 # output - fsm.svg.txt 4 #Note : This script is for processing SVG file generated from Dia open source drawing tool. 5 #The FSM is drawn using Dia software and saved in SVG format, which is then processed 6 #by the script. 7 #-*- coding: utf-8 -*- 8 import os.path 9 import xml.dom.minidom 10 import math 11 import sys 12 13 #define error code 14 SUCCESS=0 15 FILE_NOT_EXIST=1 16 WRONG_FORMAT=2 17 18 CLOSE_DISTANCE= 10 19 20 #check if a point inside an ellipse 21 def inElippse (cx, cy, rx, ry, x1, y1): #x1, y1 is point 22 return (x1- cx) * (x1- cx)/ (rx * rx)+ (y1- cy) * (y1- cy)/ (ry * ry) 23 24 #distance between two point 25 def dist (x1, y1, x2, y2): 26 return (x1- x2) * (x1- x2)+ (y1- y2) * (y1- y2) 27 28 def getText(nodelist): 29 rc=[] 30 for node in nodelist: 31 if node.nodeType == node.TEXT_NODE: 32 rc.append(node.data) 33 return ’’.join(rc) 34 35 def parseSVG (file_name): 36 dom= xml.dom.minidom.parse (file_name) 37 38 elem_list= dom.getElementsByTagName ("g") 39 if not elem_list: 40 return WRONG_FORMAT 41 42 state_list= list() 43 state_pos= list() 44 102 B.1 extraction of fsm specfication from svg 103 45 trans_list= list() 46 trans_pos= list() 47 48 text_list= list() 49 50 #begin and end states of a transition 51 begin_list= list() 52 end_list= list() 53 54 # initial state 55 # initial state was pre - defined by ’Reset’ transition 56 initial_states= dom.getElementsByTagName (’ellipse’) 57 if (initial_states): 58 state_name= ’Initial_State’ 59 60 state_pos.append ((0,0, 1e3000, 1e3000,1)) 61 62 state_list.append (state_name) 63 64 65 for elem in elem_list: 66 # handle states 67 if (elem.getElementsByTagName (’ellipse’)): 68 if (len (elem.getElementsByTagName (’ellipse’))<2): 69 return WRONG_FORMAT 70 71 state_name= getText (elem.getElementsByTagName (’text’)[0].getElementsByTagName (’tspan’)[0].childNodes) 72 pos= list() 73 pos.append (float (elem.getElementsByTagName (’ellipse’)[1].getAttribute (’cx’))) 74 pos.append (float (elem.getElementsByTagName (’ellipse’)[1].getAttribute (’cy’))) 75 pos.append (float (elem.getElementsByTagName (’ellipse’)[1].getAttribute (’rx’))) 76 pos.append (float (elem.getElementsByTagName (’ellipse’)[1].getAttribute (’ry’))) 77 pos.append (elem.getElementsByTagName (’ellipse’)[1].getAttribute (’stroke-width’)) 78 79 state_list.append (state_name) 80 state_pos.append (pos) 81 #handle transitions 82 if (elem.getElementsByTagName (’path’)): 83 if (len (elem.getElementsByTagName (’path’)) !=1): 84 return WRONG_FORMAT 85 86 pos= list() 87 #get 3 points from polygon 88 pos.append (float (elem.getElementsByTagName (’path’)[0].getAttribute (’d’).split (’’)[1].split(’,’)[0])) 89 pos.append (float (elem.getElementsByTagName (’path’)[0].getAttribute (’d’).split (’’)[1].split(’,’)[1])) 90 pos.append (float (elem.getElementsByTagName (’path’)[0].getAttribute (’d’).split (’’)[3].split(’,’)[0])) 91 pos.append (float (elem.getElementsByTagName (’path’)[0].getAttribute (’d’).split (’’)[3].split(’,’)[1])) 92 pos.append (float (elem.getElementsByTagName (’path’)[0].getAttribute (’d’).split (’’)[7].split(’,’)[0])) 93 pos.append (float (elem.getElementsByTagName (’path’)[0].getAttribute (’d’).split (’’)[7].split(’,’)[1])) 94 pos.append (float (elem.getElementsByTagName (’polygon’)[0].getAttribute (’points’).split (’’)[1].split(’,’)[0])) 95 pos.append (float (elem.getElementsByTagName (’polygon’)[0].getAttribute (’points’).split (’’)[1].split(’,’)[1])) 96 #default transition condition 97 pos.append ("1") 98 99 trans_pos.append (pos) 100 101 elem_list= dom.getElementsByTagName ("text") 102 for elem in elem_list: 103 #handle text 104 if (elem.parentNode.nodeName == ’svg’): B.1 extraction of fsm specfication from svg 104 105 text_elem= list() 106 text_elem.append (float (elem.getAttribute (’x’))) 107 text_elem.append (float (elem.getAttribute (’y’))) 108 #handle multi line text 109 text_name=’’ 110 for i in range(len (elem.getElementsByTagName (’tspan’))): 111 text_name += getText (elem.getElementsByTagName (’tspan’)[i].childNodes) 112 text_elem.append (text_name) 113 text_list.append (text_elem) 114 115 #handle transitions: 116 #mapping transition to states and condition 117 begin_list=[None] * len (trans_pos) 118 end_list=[None] * len (trans_pos) 119 trans_list_name=[’1’] * len (trans_pos) 120 #trans_list_index = [-1] * len (trans_pos) 121 for i in range(len (trans_pos)): 122 #transition 123 begin_x= trans_pos [i] [0] 124 begin_y= trans_pos [i] [1] 125 end_x= trans_pos [i] [4] 126 end_y= trans_pos [i] [5] 127 arrow_x= trans_pos [i] [6] 128 arrow_y= trans_pos [i] [7] 129 130 #determine begin and end point 131 d1= dist (begin_x, begin_y, arrow_x, arrow_y) 132 d2= dist (end_x, end_y, arrow_x, arrow_y) 133 134 if (d2> d1): #swap begin and end points 135 temp= end_x 136 end_x= begin_x 137 begin_x= temp 138 temp= end_y 139 end_y= begin_y 140 begin_y= temp 141 142 #to states 143 min_begin_distance= 1e4000 144 min_begin_index=0 145 min_end_distance= 1e4000 146 min_end_index=0 147 for j in range(1, len (state_pos)): 148 #state 149 s_pos= state_pos [j] 150 cx= s_pos [0] 151 cy= s_pos [1] 152 rx= s_pos [2] 153 ry= s_pos [3] 154 s= s_pos [4] 155 156 #check begin state 157 d= inElippse (cx, cy, rx, ry, begin_x, begin_y) 158 if (d< min_begin_distance): 159 min_begin_distance=d 160 min_begin_index=j 161 162 #check end state 163 d= inElippse (cx, cy, rx, ry, end_x, end_y) 164 if (d< min_end_distance): B.1 extraction of fsm specfication from svg 105 165 min_end_distance=d 166 min_end_index=j 167 begin_list [i]= min_begin_index 168 end_list [i]= min_end_index 169 170 distance_name_trans_order= list() 171 confidence_list=[None] * len (trans_pos) 172 #to names 173 for i in range(len (text_list)): 174 text_x= text_list [i][0] 175 text_y= text_list [i][1] 176 177 dist_name_trans= list() 178 for j in range(len (trans_pos)): 179 begin_x= trans_pos [j] [0] 180 begin_y= trans_pos [j] [1] 181 end_x= trans_pos [j] [4] 182 end_y= trans_pos [j] [5] 183 184 distance= dist (text_x, text_y, (begin_x+ end_x)/2, (begin_y+ end_y)/2) 185 dist_name_trans.append ([j, distance]) 186 dist_name_trans= sorted (dist_name_trans, key= lambda dist_name_trans: dist_name_trans[1]) 187 #print trans_list [min_index] 188 189 distance_name_trans_order.append (dist_name_trans) 190 191 if (trans_list_name [dist_name_trans[0][0]] == ’1’): 192 trans_list_name [dist_name_trans[0][0]]= list() 193 194 trans_list_name [dist_name_trans[0][0]].append (text_list[i][2]) 195 196 if (confidence_list[dist_name_trans[0][0]] == None): 197 confidence_list[dist_name_trans[0][0]]= list() 198 199 if (len (dist_name_trans) >=2): 200 confidence_list[dist_name_trans[0][0]].append (1- dist_name_trans[0][1]/ dist_name_trans[1][1]) 201 else: 202 confidence_list[dist_name_trans[0][0]].append (1.0) 203 204 if (text_list[i][2] == ’Reset’): 205 begin_list [dist_name_trans[0][0]]=0 #Initial State 206 207 #sort by confidence level 208 for i in range(len (confidence_list)): 209 if (confidence_list[i] == None): 210 continue 211 for j in range(len (confidence_list [i])): 212 for k in range (j+1, len (confidence_list [i])): 213 if (confidence_list[i][j]< confidence_list[i][k]): 214 tmp= confidence_list[i][j] 215 confidence_list[i][j]= confidence_list[i][k] 216 confidence_list[i][k]= tmp 217 tmp= trans_list_name[i][j] 218 trans_list_name[i][j]= trans_list_name[i][k] 219 trans_list_name[i][k]= tmp 220 221 dom.unlink () 222 return (state_list, trans_list_name, begin_list, end_list, confidence_list) 223 224 #main B.1 extraction of fsm specfication from svg 106 225 def process (input_file): 226 if (not os.path.isfile (input_file)): 227 print ’File not exists’ 228 return FILE_NOT_EXIST 229 (states, trans, begin, end, confidence_level)= parseSVG (input_file) 230 file= open (input_file+ ".txt", ’w’) 231 232 file.write ("--- State list ---\n") 233 for i in range(len (states)): 234 file.write (states [i]) 235 if (i< len (states)-1): 236 file.write (’\n’) 237 file.write ("\n---Transition list---\n") 238 for i in range(len(trans)): 239 start= ’None’ 240 finish= ’None’ 241 if (begin [i] != None): 242 start= states [begin [i]] 243 if (end [i] != None): 244 finish= states[end[i]] 245 file.write (start+ ’->’+ finish+ ’:’) 246 for j in range(len (trans[i])): 247 file.write (trans[i][j]) 248 file.write (’(’) 249 if (trans[i][j] != ’1’): 250 file.write (’CF = %5.3f’%(confidence_level[i][j])) 251 else: 252 file.write (’CF = NA’) 253 file.write(’)’) 254 if (j< len (trans [i])-1): 255 file.write (’,’) 256 file.write (’\n’) 257 file.close 258 259 if (len(sys.argv)<2): 260 print ’Missing input file’ 261 else: 262 process (sys.argv[1]) Conversion to NuSMV syntax 1 # receive the output file of fsmConverter (after manual check) as input 2 # convert this file into nuSMV/nuXMV format 3 #File name - nuSMVConverter.py 4 #usage - python nuSMVConverter.py fsm.svg.txt 5 # output - fsm.svg.txt.smv 6 7 8 import os.path 9 import sys 10 11 #define error code 12 #do not modify 13 SUCCESS=0 14 FILE_NOT_EXIST=1 15 WRONG_FORMAT=2 B.1 extraction of fsm specfication from svg 107 16 17 CLOSE_DISTANCE= 10 18 19 #define reading mode 20 READ_STATE=1 21 READ_TRANSITION=2 22 23 def loadStateMachine (input_file): 24 if (not os.path.isfile (input_file)): 25 print ’File not exists’ 26 return FILE_NOT_EXIST 27 28 #input file 29 i_file= open (input_file, "r") 30 31 #read input file to input data 32 i_data= i_file.readlines () 33 34 #parse input file 35 states= list() 36 trans= list() 37 begins= list() 38 ends= list() 39 40 #reading_mode indicates we are reading state list or transition list 41 reading_mode=0 42 43 for line in i_data: 44 if "State list" in line: 45 reading_mode= READ_STATE 46 continue 47 if "Transition list" in line: 48 reading_mode= READ_TRANSITION 49 continue 50 if (reading_mode == READ_STATE): 51 states.append (line[:-1]) 52 continue 53 if (reading_mode == READ_TRANSITION): 54 arrow_pos= line.index (’->’) 55 if (arrow_pos ==-1): 56 return WRONG_FORMAT 57 begins.append (line[:arrow_pos]) 58 59 colon_pos= line.index (’:’) 60 if (colon_pos ==-1): 61 return WRONG_FORMAT 62 ends.append (line[arrow_pos+2:colon_pos]) 63 64 open_bracket= line.index (’(CF =’) 65 if (open_bracket ==-1): #not recommend 66 trans.append (line [colon_pos+1:]) 67 else: 68 trans.append (line [colon_pos+1:open_bracket]) 69 return (states, trans, begins, ends) 70 71 def writeToNuSMVFormat (output_file, states, trans, begins, ends): 72 file= open (output_file, ’w’) 73 74 if (file == None): 75 return FILE_NOT_EXIST B.1 extraction of fsm specfication from svg 108 76 77 non_duplicate_trans= list(set (trans)) 78 79 file.write (’MODULE main\n’) 80 file.write (’VAR\n’) 81 file.write (’\t’) 82 file.write (’request:’) 83 file.write (’{’) 84 for i in range(len (non_duplicate_trans)): 85 file.write (non_duplicate_trans[i]) 86 if (i< len (non_duplicate_trans)-1): 87 file.write (’,’) 88 file.write (’};\n’) 89 90 file.write (’\tstate:’) 91 file.write (’{’) 92 for i in range(len (states)): 93 file.write (states[i]) 94 if (i< len (states)-1): 95 file.write (’,’) 96 file.write (’};\n’) 97 98 file.write (’ASSIGN\n’) 99 file.write (’init(state):=’) 100 file.write (states [0]) 101 file.write (’;\n’) 102 file.write (’next(state):=case\n’) 103 for i in range(len (begins)): 104 file.write (’\t\tstate = ’+ begins [i]+ ’ & request = ’+ trans [i]+’:’+ ends [i]+’; \n’) 105 file.write(’\t\tTRUE : state; \n’) 106 file.write (’\tesac;’) 107 file.close () 108 109 if (len(sys.argv)<2): 110 print ’Missing input file’ 111 else: 112 (states, trans, begins, ends)= loadStateMachine (sys.argv[1]) 113 writeToNuSMVFormat (sys.argv[1]+ ’.smv’, states, trans, begins, ends) Generated SMV code from Script 1 MODULE main 2 VAR 3 request:{"! dataInStore",Reset,"dataInStore & (! cts_n)", 4 "countExp & cts_n & dataInStore","! dataInStore & countExp", 5 "countExp & (! dataInStore)","! cts_n & dataInStore", 6 "dataInStore & cts_n",doneShiftOut, 7 "dataInStore & (! cts_n) & countExp"}; 8 9 state: {Initial_State,IDLE,SHIFTING,CNT_EXPIRE,IDLE_FC}; 10 ASSIGN 11 init(state):=Initial_State; 12 next(state):=case 13 state= IDLE& request= "dataInStore & (! cts_n)": SHIFTING; 14 state= SHIFTING& request= doneShiftOut: CNT_EXPIRE; 15 state= IDLE_FC& request= "! dataInStore": IDLE; B.1 extraction of fsm specfication from svg 109 16 state= IDLE& request= "dataInStore & cts_n": IDLE_FC; 17 state= CNT_EXPIRE& request= "countExp & cts_n & dataInStore": IDLE_FC; 18 state= CNT_EXPIRE& request= "dataInStore & (! cts_n) & countExp": SHIFTING; 19 state= CNT_EXPIRE& request= "! dataInStore & countExp": IDLE; 20 state= IDLE_FC& request= "! cts_n & dataInStore": SHIFTING; 21 state= Initial_State& request= Reset: IDLE; 22 TRUE: {Initial_State,IDLE,SHIFTING,CNT_EXPIRE,IDLE_FC}; 23 esac; BIBLIOGRAPHY [1] H. D. Foster, “Why the design productivity gap never happened,” in Computer-Aided Design (ICCAD), 2013 IEEE/ACM International Conference on, pp. 581–584, IEEE, 2013. [2] B. Wile, J. C. Goss, and W. Roesner, Comprehensive Functional Verification: The Complete Industry Cycle. Morgan Kaufmann, 2005. [3] J. C. Giarratano and G. Riley, “Expert systems, principles and program- ming, thomson course of technology,” Boston, Australia, 2005. [4] T. Instruments, “Omap 4470 technical specification,” 2011. [5] Marvell, “Marvell armada 510 application processor,” 2009. [6] F. Semiconductor, “Freescale semiconductor data sheet: Technical data imx25cec,” July 2013. [7] A. Shankar, B. Singh, F. Wolff, and C. Papachristou, “Ontology-guided conceptual analysis of design specifications,” in Proceedings of the The 51st Annual Design Automation Conference on Design Automation Conference, pp. 1–6, ACM, 2014. [8] https://live.gnome.org/Dia, “Dia-version-0.97.2.” [9] L. Leinweber, B. Singh, and C. Papachristou, “Expert system simulation of hardware,” in Tools with Artificial Intelligence (ICTAI), 2013 IEEE 25th International Conference on, pp. 207–212, IEEE, 2013. [10] P. G. Maropoulos and D. Ceglarek, “Design verification and validation in product lifecycle,” CIRP Annals-Manufacturing Technology, vol. 59, no. 2, pp. 740–759, 2010. 110 bibliography 111 [11] I. Babuska and J. T. Oden, “Verification and validation in computational engineering and science: basic concepts,” Computer Methods in Applied Me- chanics and Engineering, vol. 193, no. 36, pp. 4057–4066, 2004. [12] ITRS, “International technology roadmap for semiconductor - design,” tech. rep., ITRS, 2011. [13] H. Foster, “Prologue: The 2012 wilson research group functional verifica- tion study,” Retrieved August, vol. 1, 2013. [14] R. Collett, “Ic/asic functional verification study,",” Industry Report from Collett International Research, p. 34, 2004. [15] M. Fujita, “Post-silicon patchable hardware silicon patchable hardware.” http://cmacs.cs.cmu.edu/seminars/slides/fujita.pdf, July 22nd, 2011. [16] M. Keating and P. Bricaud, Reuse Methodology Manual for System-on-a-Chip Designs: For System-on-a-chip Designs. Springer, 2002. [17] W. K. Lam, Hardware Design Verification: Simulation and Formal Method- Based Approaches (Prentice Hall Modern Semiconductor Design Series). Pren- tice Hall PTR, 2005. [18] M. Abramovici, M. A. Breuer, and A. D. Friedman, Digital systems testing and testable design. Wiley-IEEE Press, ist ed., September 27, 1994. [19] M. Bushnell and V. D. Agrawal, Essentials of electronic testing for digital, memory and mixed-signal VLSI circuits, vol. 17. Springer, 2000. [20] C. Kern and M. R. Greenstreet, “Formal verification in hardware design: a survey,” ACM Transactions on Design Automation of Electronic Systems (TO- DAES), vol. 4, no. 2, pp. 123–193, 1999. [21] M. C. McFarland, “Formal verification of sequential hardware: A tutorial,” Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, vol. 12, no. 5, pp. 633–654, 1993. bibliography 112 [22] E. M. Clarke, O. Grumberg, and D. Peled, Model checking. MIT press, 1999. [23] S. Merz, “Model checking: A tutorial overview,” in Modeling and verifica- tion of parallel processes, pp. 3–38, Springer, 2001. [24] C. L. Forgy, “Rete: A fast algorithm for the many pattern/many object pattern match problem,” Artificial intelligence, vol. 19, no. 1, pp. 17–37, 1982. [25] D. P. Miranker, Treat: A better match algorithm for ai production systems; long version. University of Texas at Austin, 1987. [26] B. S. C. Papachristou and F. Wolff, “An expert system based methodology for soft an expert system based methodology for soft ip core validation,” in GoMACTech Conference, 2013. [27] B. Singh, A. Shankar, F. Wolff, D. Weyer, C. Papachristou, and B. Negi, “Knowledge-guided methodology for third-party soft ip analysis,” in VLSI Design and 2014 13th International Conference on Embedded Systems, 2014 27th International Conference on, pp. 246–251, IEEE, 2014. [28] B. Singh, A. Shankar, Y. Shiyanovskii, F. Wolff, C. Papachristou, D. Weyer, S. Clay, and J. Morrison, “Knowledge-guided methodology for specifica- tion analysis,” in Tools with Artificial Intelligence (ICTAI), 2013 IEEE 25th International Conference on, pp. 749–754, IEEE, 2013. [29] B. Singh, A. Shankar, F. Wolff, C. Papachristou, D. Weyer, and S. Clay, “Cross-correlation of specification and rtl for soft ip analysis,” in Design, Automation and Test in Europe Conference and Exhibition (DATE), 2014, pp. 1– 6, IEEE, 2014. [30] J. Bhadra, M. S. Abadir, L.-C. Wang, S. Ray, et al., “A survey of hybrid techniques for functional verification,” IEEE Design and Test of Computers, vol. 24, no. 2, pp. 112–123, 2007. bibliography 113 [31] D. R. Tom Fitzpatrick, “Of camels and committees: Standards should en- able innovation, not strangle it,” in DVCON Proceedings, 2014. [32] S. A. Edwards, “Design and verification languages,” 2004. [33] S. Rosenberg and K. Meade, A practical guide to adopting the universal veri- fication methodology (UVM). Cadence Design Systems, 2013. [34] T. Kropf, Introduction to formal hardware verification. Springer, 1999. [35] H. Kaiya and M. Saeki, “Using domain ontology as domain knowledge for requirements elicitation,” in Requirements Engineering, 14th IEEE Inter- national Conference, pp. 189–198, IEEE, 2006. [36] L. Goldin and D. M. Berry, “Abstfinder, a prototype natural language text abstraction finder for use in requirements elicitation,” Automated Software Engineering, vol. 4, no. 4, pp. 375–412, 1997. [37] W. R. Cyre, “Capture, integration, and analysis of digital system require- ments with conceptual graphs,” Knowledge and Data Engineering, IEEE Transactions on, vol. 9, no. 1, pp. 8–23, 1997. [38] A. Holt and E. Klein, “A semantically-derived subset of english for hard- ware verification,” in Proceedings of the 37th annual meeting of the Association for Computational Linguistics on Computational Linguistics, pp. 451–456, As- sociation for Computational Linguistics, 1999. [39] C. Kirchsteiger, C. Trummer, C. Steger, R. Weiss, and M. Pistauer, “Au- tomatic verification plan generation to speed up soc verification,” in NORCHIP, 2008., pp. 33–36, IEEE, 2008. [40] S. Flake, W. Müller, and J. Ruf, “Structured english for model checking specification.,” in MBMV, pp. 99–108, 2000. bibliography 114 [41] G. H. Chisholm, S. T. Eckmann, C. M. Lain, and R. L. Veroff, “Understand- ing integrated circuits,” IEEE design & test of computers, vol. 16, no. 2, pp. 26–37, 1999. [42] D. James, “Reverse engineering delivers product knowledge; aids technol- ogy spread,” Electronic Design, 2006. [43] P. Subramanyan, N. Tsiskaridze, K. Pasricha, D. Reisman, A. Susnea, and S. Malik, “Reverse engineering digital circuits using functional analysis,” in Proceedings of the Conference on Design, Automation and Test in Europe, pp. 1277–1280, EDA Consortium, 2013. [44] D. G. Saab, V. Nagubadi, F. Kocan, and J. Abraham, “Extraction based ver- ification method for off the shelf integrated circuits,” in Quality Electronic Design, 2009. ASQED 2009. 1st Asia Symposium on, pp. 396–400, IEEE, 2009. [45] M. C. Hansen, H. Yalcin, and J. P. Hayes, “Unveiling the iscas-85 bench- marks: A case study in reverse engineering,” IEEE Design & Test of Computers, vol. 16, no. 3, pp. 72–80, 1999. [46] G. Lehmann, B. Wunder, and K. D. Müller-Glaser, “Basic concepts for an hdl reverse engineering tool-set,” in Proceedings of the 1996 IEEE/ACM international conference on Computer-aided design, pp. 134–141, IEEE Com- puter Society, 1997. [47] W. Li, Z. Wasson, and S. A. Seshia, “Reverse engineering circuits using be- havioral pattern mining,” in Hardware-Oriented Security and Trust (HOST), 2012 IEEE International Symposium on, pp. 83–88, IEEE, 2012. [48] K. Werner, “Can ip quality be objectively measured?,” in Proceedings of the conference on Design, automation and test in Europe-Volume 3, p. 30330, IEEE Computer Society, 2004. bibliography 115 [49] Z. Meng, G. Minglun, and P. C. Chan, “A practical ip quality measure- ment framework,” in ASIC, 2007. ASICON’07. 7th International Conference on, pp. 1313–1316, IEEE, 2007. [50] F. Wickberg, “Hdl code analysis for asics in mobile sys- tems,” Master’s thesis, LINKOPING UNIVERSITY, liu.diva- portal.org/smash/get/diva2:24142/FULLTEXT01, February 2007. [51] I.-X. Standard, “Ieee 1685–2009,” IEEE standard for IPXACT, standard struc- ture for packaging, integrating and reusing IP within tool flows, 2009. [52] G. Koch, U. Kebschull, and W. Rosenstiel, “A prototyping environment for hardware/software codesign in the cobra project,” in Proceedings of the 3rd international workshop on Hardware/software co-design, pp. 10–16, IEEE Computer Society Press, 1994. [53] M. López, C. A. Iglesias, and J. C. López, “A knowledge-based system for hardware-software partitioning,” in Proceedings of the conference on Design, automation and test in Europe, pp. 914–915, IEEE Computer Society, 1998. [54] Y. Naveh, M. Rimon, I. Jaeger, Y. Katz, M. Vinov, E. s Marcu, and G. Shurek, “Constraint-based random stimuli generation for hardware verification,” AI magazine, vol. 28, no. 3, p. 13, 2007. [55] A. Ltd., “Amba 3 specifications.” http://www.arm.com/products/system- ip/amba/amba-open-specifications.php, 2003. [56] Cadence, “Cadence vip catalog.” http://ip.cadence.com/ipportfolio/verification- ip/simulation-vip, 2014. [57] Synopsys, “Synopsys verification ip.” http://www.synopsys.com/VIP, 2014. [58] W. Wögerer, “A survey of static program analysis techniques,” Vienna University of Technology, 2005. bibliography 116 [59] D. Esposito, “Static code analysis and code contracts,” August 2011. [60] H. Williamson, XML: The complete reference. McGraw-Hill Professional, 2001. [61] “Xml basics.” http://www.webucator.com/tutorial/learn-xml/xml- basics.cfm. [62] “Introduction to xml.” http://www.w3schools.com/xml/xml_whatis.asp. [63] J. Al-Eryani. http://opencores.org/project,fpu100. [64] Z. Li and K. Ramani, “Ontology-based design information extraction and retrieval,” AI EDAM: Artificial Intelligence for Engineering Design, Analysis, and Manufacturing, vol. 21, no. 02, pp. 137–154, 2007. [65] S. Nirenburg and V. Raskin, Ontological semantics. MIT Press, 2004. [66] I. S. Committee et al.,“754-2008 ieee standard for floating-point arith- metic,” IEEE Computer Society Std, vol. 2008, 2008. [67] “Protégé.” http://protege.stanford.edu. Accessed: 2013-10-03. [68] S. Opencores, “Wishbone system-on-chip (soc) interconnection architec- ture for portable ip cores,” tech. rep., Technical report, Opencores, 2002. [69] S. C. Shapiro, “Artificial intelligence,” 1982. [70] D. Maynard, Y. Li, and W. Peters, “Nlp techniques for term extraction and ontology population,” in Proceeding of the 2008 conference on Ontol- ogy Learning and Population: Bridging the Gap between Text and Knowledge, pp. 107–127, 2008. [71] M. Poesio and A. Almuhareb, “Extracting concept descriptions from the web: the importance of attributes and values,” in Proceedings of the Confer- ence on Ontology Learning and Population: Bridging the Gap between Text and Knowledge, pp. 29–44, Citeseer, 2008. bibliography 117 [72] Y. Sure, J. Angele, and S. Staab, “Ontoedit: Multifaceted inferencing for on- tology engineering,” in Journal on Data Semantics I, pp. 128–152, Springer, 2003. [73] A. Shankar, B. P. Singh, F. Wolff, and C. Papachristou, “Nefcis: Neuro- fuzzy concept based inference system for specification mining,” in Tools with Artificial Intelligence (ICTAI), 2013 IEEE 25th International Conference on, pp. 337–343, IEEE, 2013. [74] http://www.dilloneng.com/uploads/2/1/2/2/21220816/fp_spec.pdf. [75] http://bitsavers.informatik.uni-stuttgart.de/pdf/weitek/WTL_3167_Floating- Point_Coprocessor_Sep88.pdf. [76] http://www.altera.com/literature/ug/ug_altfp_mfug.pdf. [77] R. Usselmann. http://opencores.org/project,fpu. [78] Xilinx. http://www.xilinx.com/support/documentation/ ip_documentation/floating_point_ds335.pdf. [79] Altium. http://www.altium.com/files/AltiumDesigner/s08/ learning- guides/CR0171. [80] Actel, “Grfpu lite companion core data sheet.” http://www.actel.com/ipdocs/GRFPU_Lite_DS.pdf. [81] C. D. Manning, P. Raghavan, and H. Schütze, Introduction to information retrieval, vol. 1. Cambridge university press Cambridge, 2008. [82] F. Corno, M. S. Reorda, and G. Squillero, “Rt-level itc’99 benchmarks and first atpg results,” IEEE Design & Test of Computers, vol. 17, no. 3, pp. 44–53, 2000. [83] M. Guillermo. http://opencores.org/project,fpuvhdl. [84] D. Lundgren. http://opencores.org/project,fpu double. bibliography 118 [85] A. Kamppi, L. Matilainen, J. Maatta, E. Salminen, T. D. Hamalainen, and M. Hannikainen, “Kactus2: Environment for embedded product develop- ment using ip-xact and mcapi,” in Digital System Design (DSD), 2011 14th Euromicro Conference on, pp. 262–265, IEEE, 2011. [86] J. Ellson, E. Gansner, L. Koutsofios, S. C. North, and G. Woodhull, “Graphviz—open source graph drawing tools,” in Graph Drawing, pp. 483– 484, Springer, 2002. [87] J. Ferraiolo, F. Jun, and D. Jackson, Scalable vector graphics (SVG) 1.0 speci- fication. iuniverse, 2000. [88] e. a. Erik Dahlström, Patrick Dengler, “Scalable vector graphics (svg) 1.1 (second edition).” http://www.w3.org/TR/SVG11/Overview.html, Au- gust 2011. [89] M. H. Walker, N. J. Eaton, and N. Eaton, Microsoft Office Visio 2003 Inside Out. Microsoft Press, 2004. [90] R. Olsen, OmniGraffle 5 Diagramming Essentials: Create Better Diagrams with Less Effort Using OmniGraffle. Packt Publishing Ltd, 2010. [91] A. Cimatti, E. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore, M. Roveri, R. Sebastiani, and A. Tacchella, “Nusmv 2: An opensource tool for symbolic model checking,” in Computer Aided Verification, pp. 359–364, Springer, 2002. [92] S. I. I. (si2.org). https://www.si2.org/?page=435/tdml/dtutorial.zip. [93] T. version 2.0. http://www.timingtool.com. [94] S. Cornor. http://opencores.org/project,amber. [95] R. Hayes. http://opencores.org/project,pit. |