UML to Systemverilog Synthesis for Embedded System Models with Support for Assertion Generation

UML to Systemverilog Synthesis for Embedded System Models with Support for Assertion Generation

UML to SystemVerilog Synthesis for Embedded System Models with Support for Assertion Generation Lun Li*, Frank P. Coyle, and Mitchell A. Thornton Department of Computer Science and Engineering Southern Methodist University Dallas, Texas, U.S.A. {lli, coyle,mitch}@engr.smu.edu Abstract However, no such tools are commercially available that SystemVerilog encapsulates both design description can synthesize UML models into a Hardware and verification properties in one language and provides Description Language (HDL) model directly, thus a unified environment for engineers who have the imposing a limitation for the usage of UML in embedded formidable challenge of designing and verifying present system design. day complex systems. However, the gap between the Additionally, it is also observed that assuring correct definition of system specifications and design validation functional behavior is the dominating factor of a assertions that formally describe embedded system successful hardware design. Today, in many circuit properties poses a challenge for HDL design engineers. design projects, up to 80% of the overall design costs are We describe a prototype tool that utilizes UML as a due to verification tasks. system specification language and generates Assertion-based verification plays an important role in SystemVerilog assertions for hardware design today’s large, complex designs. The basic function of an correctness validation with a corresponding Verilog assertion is to specify some behavior that is expected to module describing the hardware. An example is provided hold true for a given design or component. However, for a controller specified in UML with the resultant system specification of a design is usually given in a Verilog-RTL description and SystemVerilog assertion file natural language which is hard to translate into an produced automatically. assertion directly. It is necessary to describe the system specification in a more rigorous and well-formed 1. Introduction language in order to bridge the gap between a system specification and design validation assertions that As Moore’s Law continues to push the boundaries of formally describes such specifications. hardware capabilities, embedded systems designers are In this paper, our main contribution is the development confronted with the challenge of how best to draw the of synthesis and assertion generation tools that utilize line between hardware and software. Functionality that UML version 1.3 as a system specification language and was once relegated to software is now considered for the automatically generate assertions that can be used by a possibility of implementation in hardware while verification engineer to validate the hardware as well as a hardware components must integrate with higher-level synthesizable HDL-RTL module description. We believe software APIs. this is an important contribution since the description of To help address these problems, the area of validation for a particular design developed during the hardware/software co-design has evolved as an time of system specification is as important as property architectural approach to system design where decisions specification at later stages of synthesis. concerning hardware-software allocation are deferred as The remainder of the paper is organized as follows. In late as possible within the design cycle. A Model Driven Section 2, we provide background information about Architecture (MDA) approach is proposed in [1] where UML and SystemVerilog. In Section 3, our tool that system functionality and semantics at a high level of comprises an automatic assertion generator and HDL abstraction is used and then tools are described that synthesis based on a UML description is introduced. An generate different platform specific implementations. example is given to demonstrate the capability of the While MDA is technically neutral about the syntax and tools. Future work and conclusions are provided in structure of high-level models, the Unified Modeling Section 4. Language (UML) [2] has emerged as a common foundation for MDA modeling. Initially proposed as a unifying notation for object-oriented design, UML has 2. Preliminaries and Related Work added a semantic underpinning that makes it possible to In this section, we introduce the use of UML and HDL build platform independent descriptions that can be used for describing hardware and assertions that are used for by designers and architects to make informed decisions circuit validation. about hardware/software tradeoffs. Since UML was initially introduced in the software domain, most 2.1 Unified Modeling Language (UML) commercial tools based on UML descriptions have the UML is a modeling language that is very well accepted ability of generating software code such as Java and C++. in the software domain for system modeling. UML defines twelve types of diagrams which can be divided 2.3 Related Work into three categories: (i) Structural Diagrams which In [10], the authors present a framework for generating include the Class Diagram, Object Diagram, Component VHDL specifications from a subset of UML, and a set of Diagram, and Deployment Diagram, (ii) Behavior rules to map UML class and state diagrams to VHDL. Diagrams which include the Use Case Diagram (used by The authors concentrate on UML behavioral models some methodologies during requirements gathering); described using state diagrams, and use a mapping for Sequence Diagram, Activity Diagram, Collaboration class diagrams that differs from our approach. Bjhrklund Diagram, and State Machine Diagram, and (iii) Model and Lilius [11] generate VHDL code from UML Management Diagrams which include Packages, behavioral models (state and activity diagrams) using Subsystems, and Models. UML has been used across a SMDL as an intermediary language. Authors in [12] wide variety of domains, from computational to physical, present an approach for modeling embedded systems making it suitable for specifying systems independently using extended UML as well as generating SystemC code of whether the implementation is accomplished via from UML class and object diagrams. In [13], software or hardware. Damasevicius and Stuikys examined system level design The recent addition of action semantics to UML has processes that are aimed at designing a hardware system led to the development of executable UML (xUML) by integrating soft IPs at a high level of abstraction. They which supports the direct execution of UML models [2]. combine this concept with object-oriented hardware UML is supported by a wide range of tools such as design using UML and metaprogramming paradigm for IBM’s Rational Toolset [3] and I-Logix’s Rhapsody [4]. describing generation of domain code. However, none of The exchange of models between tools is supported by the above approaches use UML to automatically generate the XMI standard. This standard is an XML-based assertions for the purpose of verifying the functional description language which captures the details of UML correctness of the synthesized code. model diagrams in a portable, machine readable format. Most UML tools can automatically generate XMI which 2.4 Case Study is used as the basis for our prototype tool as described In this section of the paper we introduce an example here. that is used to demonstrate the capability of our tools. This example is a simple traffic light controller. Although 2.2 SystemVerilog and SystemVerilog Assertions we present a simple example, the validation for this (SVA) system is very important and encompasses important The SystemVerilog language evolved from the Verilog properties such as safety, liveness, and fairness. Figure 1 hardware description language as an industrial standard shows the traffic light environment. The highway traffic language to describe hardware design as well as to write light is normally green and the farm road traffic light is assertions supporting the enormous task of verifying the red until a sensor from farm road traffic is detected correctness of a design. The basic function of an assertion indicating a vehicle is waiting for pass-through. is to specify a set of behaviors that is expected to hold true for a given design or component. The capability to Farm road encapsulate a design and a verification strategy in one sensor language provides a unified environment for engineers who have the formidable challenge of designing and verifying present day complex systems. Assertions can Highway dramatically decrease the amount of effort required to define intelligent, self-checking testbenches, and at the Highway same time, increase the effectiveness of a testbench [6]. SystemVerilog provides two types of assertions: sensor immediate and concurrent. Both assertion types are intended to convey the intent of the design engineer and Farm road to identify the source of a problem as quickly and directly as possible. Immediate assertions are procedural Figure 1. Traffic light Environment [7] statements that can occur anywhere within always or initial blocks, and include a conditional expression The system for the traffic light is shown in Figure 2. to be tested and a set of statements to be executed The whole system consists of 5 parts: depending on the result of the expression evaluation. TrafficLightController, Timer, Roadsensor, Concurrent assertions provide the ability to specify HighwayTrafficLight, and FarmTrafficLight. sequential behavior concisely and to evaluate that TrafficLightController is the central part of the system behavior at discrete points

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    7 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us