DOCSLIB.ORG

An Overview of Formal Hardware Specification Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

An Overview of Formal Hardware Specification Languages Annette Bunker∗ Sally A. McKee Ganesh Gopalakrishnan School of Computing School of Electrical and Computer Engineering School of Computing University of Utah Cornell University University of Utah Salt Lake City, Utah 84112 Ithaca, New York 14853 Salt Lake City, Utah 84112 [email protected] [email protected] [email protected] Abstract standard compliance verification. As in any engineering ef- fort, the tools chosen for a verification project can greatly Verification is widely recognized as one of the most affect its eventual success or failure. One of the most impor- difficult aspects of computer hardware design. The gap tant tools of a formal verification engineer is the language between design and verification capabilities grows, as does used to specify the design. Having a broad view of the spec- the cost of missed flaws. Many researchers investigate ification languages available allows the practitioner to refine ways to formally verify processor designs, interconnects, the candidate language set to those most appropriate to the and protocols, but creating verification methods and tools problem to be solved. will remain a central problem for computer scientists for at To that end, we present a taxonomy of the specification least the next decade. We introduce this field by surveying language space, and we use this taxonomy to structure our formal specification languages. We construct a taxonomy of discussion of the relative merits of each approach. We clas- languages and discuss the applicability of each to standard sify specification languages first according to their form, i.e., compliance verification, or demonstrating that a hardware textual versus graphical or visual. We make finer classifica- design complies to an interconnect standard. tions according to origins: HDLs versus traditional software programming languages in the textual case, and software en- gineering versus hardware engineering versus system engi- 1. Introduction neering in the visual case. This short survey is not intended to be comprehensive, but instead serves to familiarize the Verification is one of the most difficult aspects of com- reader with the variety of languages used in practice and puter hardware design. The cost of missing even a single bug their applicability in our domain. can be staggering. For instance, the floating point division The ideal language for our purposes possesses four char- bug in the Intel R Pentium R processor cost the company acteristics, as outlined below. While we realize it is unlikely $475 million [4]. Validation efforts for modern micropro- that an existing language exactly matches our application, cessor designs can consume months of CPU time on large we prefer to make adjustments to a language that already server farms, yet the total “runtime” for the simulated de- exists rather than developing a new language. sign during this period is equivalent to only a few minutes • Precise semantics. A formal specification provides a of wall-clock time on a 1 GHz CPU [2]. Furthermore, the precise baseline for many implementations developed by gap between industrial design capabilities and verification different organizations. capabilities is growing, rather than shrinking, as is the po- • Short learning curve. The specification is likely to be tential cost of bugs that escape verification teams. used by hardware engineers of all specialties, and thus the In response to this problem, researchers and practitioners language must be easy to learn and understand, even by alike strive to create methods and technologies that can help those not highly trained in formal verification techniques. close the design/verification gap. Current formal verifica- • Connections with automatic verification techniques. tion techniques target many aspects of computer systems, in- Because the same verification may be performed by mul- cluding microprocessor design [12, 15, 26], interconnect de- tiple organizations (the intellectual property designer and sign, protocol design [11, 14], and specification validation. integrator, for example), the verification effort must be However, none of the techniques nor tools yet addresses the significantly less than the total design effort. Languages problem of verifying that register transfer language (RTL) that lend themselves to automatic verification techniques designs comply with interconnect standards. help mitigate verification effort. This paper surveys several formal specification languages • Integration with existing design practice. The transfer that are candidates for our application of interest, interface of formal methods technologies to industrial practice de- pends on their ability to fit neatly into existing or emerg- ∗This work was supported by National Science Foundation Grant CCR- 9987516, and was conducted while the second author was at Utah. ing design practices. 2. Textual Languages Objective VHDL. Objective VHDL (OVHDL) raises the abstraction level at which design activities occur, enhancing Textual languages constitute the majority of current spec- design reuse [23]. This object-oriented version of VHDL ification languages. They resemble hardware description adds type classes for data abstraction and entity classes for languages and conventional programming languages, and structural abstraction. Type classes allow the user to create therefore lend themselves to automated analysis. We divide class data types, such as arrays or records, with inheritance such approaches broadly into those inspired by hardware de- and data hiding. Since VHDL entity-architecture pairs al- scription languages, which tend to describe designs in low- ready implement data hiding, OVHDL developers only add level detail, and those arising from programming languages, inheritance to complete the implementation of entity classes. which tend to specify behavior at a higher abstraction level. Allara, et al., point out that designers require only mini- mal training in using the additional OVHDL syntax [1], and 2.1. Hardware Description Languages automatic formal verification tools exist for which VHDL is the modeling language. The OVHDL tool suite translates We first focus on two HDL approaches, hardware mon- models into VHDL that can be simulated by off-the-shelf itors and Objective VHDL. Hardware monitors have been tools, facilitating integration with existing design practice. used to specify the PCI 2.2 standard and the Intel ItaniumTM As with hardware monitor specifications, the semantics of bus protocol. Objective VHDL was developed to support OVHDL models depend on the chosen VHDL simulators. abstraction and reuse in hardware modeling. Figure 1(a) shows how a hypothetical counter module Hardware Monitors. The use of monitor modules as aids might be specified using OVHDL. The inputs inc and re- for simulation-based verification was proposed as early as set increment and reset the counter’s value, respectively. In 1996 [19]. Shimizu, et al., retarget monitors for formally Figure 1(a), the counter class is declared with a single data specifying hardware designs [25], showing that even the attribute, count, of type integer. Procedures are then de- most complicated hardware protocols can be described in clared to handle the two inputs and implemented to handle this manner [24]. Such a specification consists of a series the inc input and the reset input. of small monitor modules written in the same hardware de- scription language as the implementation, where each mon- 2.2. Programming Languages itor describes one requirement in the specification. Moni- tors used for hardware specification tend to be of two types: Next we consider SpecC and JavaTMfor hardware speci- a small counter machine for an event which must happen fication. SpecC encourages design reuse by providing a sin- within a certain number of cycles of a trigger event; or a flag gle, executable language in which to document many design machine that remembers one piece of information, such as activities. Java, a high-level, object-oriented programming whether the transaction is a read or a write. language, developed at Sun Microsystems R , enables hard- Monitors possess capabilities especially useful for proto- ware/software codesign by providing a single simulation en- col design and verification. First, they can be checked for vironment for the entire system. internal consistency using standard model checking tools, SpecC. SpecC is a formal, executable modeling lan- without the aid of a completed implementation. Second, guage with an accompanying tool suite intended to facili- they can be reused for many verification purposes. Fi- tate hardware-software codesign [8]. The language retains nally, monitor-style specifications can be proven to be im- much of the syntax of the C programming language. At plementable, as demonstrated by Shimizu and colleagues. each stage in the SpecC design cycle, tools generate models Monitor specifications do not require the designer to learn that can be analyzed by typical simulation and debugging a new language to create the specification, since they are tools. Other SpecC tools provide static analysis and esti- written in hardware description languages. Furthermore, mation to ensure that design metrics remain within specified writing the specification in the same HDL as the imple- bounds. SpecC’s formal semantics and familiar syntax com- mentation means that the specification is already fully in- bined with the complete design methodology surrounding tegrated into the design cycle and is supported by appropri- the
Recommended publications
  • Systemverilog

    Systemverilog

    SystemVerilog ● Industry's first unified HDVL (Hw Description and Verification language (IEEE 1800) ● Major extension of Verilog language (IEEE 1364) ● Targeted primarily at the chip implementation and verification flow ● Improve productivity in the design of large gate-count, IP- based, bus-intensive chips Sources and references 1. Accellera IEEE SystemVerilog page http://www.systemverilog.com/home.html 2. “Using SystemVerilog for FPGA design. A tutorial based on a simple bus system”, Doulos http://www.doulos.com/knowhow/sysverilog/FPGA/ 3. “SystemVerilog for Design groups”, Slides from Doulos training course 4. Various tutorials on SystemVerilog on Doulos website 5. “SystemVerilog for VHDL Users”, Tom Fitzpatrick, Synopsys Principal Technical Specialist, Date04 http://www.systemverilog.com/techpapers/date04_systemverilog.pdf 6. “SystemVerilog, a design and synthesis perspective”, K. Pieper, Synopsys R&D Manager, HDL Compilers 7. Wikipedia Extensions to Verilog ● Improvements for advanced design requirements – Data types – Higher abstraction (user defined types, struct, unions) – Interfaces ● Properties and assertions built in the language – Assertion Based Verification, Design for Verification ● New features for verification – Models and testbenches using object-oriented techniques (class) – Constrained random test generation – Transaction level modeling ● Direct Programming Interface with C/C++/SystemC – Link to system level simulations Data types: logic module counter (input logic clk, ● Nets and Variables reset, ● enable, Net type,
  • Development of Systemc Modules from HDL for System-On-Chip Applications

    Development of Systemc Modules from HDL for System-On-Chip Applications

    University of Tennessee, Knoxville TRACE: Tennessee Research and Creative Exchange Masters Theses Graduate School 8-2004 Development of SystemC Modules from HDL for System-on-Chip Applications Siddhartha Devalapalli University of Tennessee - Knoxville Follow this and additional works at: https://trace.tennessee.edu/utk_gradthes Part of the Electrical and Computer Engineering Commons Recommended Citation Devalapalli, Siddhartha, "Development of SystemC Modules from HDL for System-on-Chip Applications. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2119 This Thesis is brought to you for free and open access by the Graduate School at TRACE: Tennessee Research and Creative Exchange. It has been accepted for inclusion in Masters Theses by an authorized administrator of TRACE: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. To the Graduate Council: I am submitting herewith a thesis written by Siddhartha Devalapalli entitled "Development of SystemC Modules from HDL for System-on-Chip Applications." I have examined the final electronic copy of this thesis for form and content and recommend that it be accepted in partial fulfillment of the equirr ements for the degree of Master of Science, with a major in Electrical Engineering. Dr. Donald W. Bouldin, Major Professor We have read this thesis and recommend its acceptance: Dr. Gregory D. Peterson, Dr. Chandra Tan Accepted for the Council: Carolyn R. Hodges Vice Provost and Dean of the Graduate School (Original signatures are on file with official studentecor r ds.) To the Graduate Council: I am submitting herewith a thesis written by Siddhartha Devalapalli entitled "Development of SystemC Modules from HDL for System-on-Chip Applications".
  • Powerplay Power Analysis 8 2013.11.04

    Powerplay Power Analysis 8 2013.11.04

    PowerPlay Power Analysis 8 2013.11.04 QII53013 Subscribe Send Feedback The PowerPlay Power Analysis tools allow you to estimate device power consumption accurately. As designs grow larger and process technology continues to shrink, power becomes an increasingly important design consideration. When designing a PCB, you must estimate the power consumption of a device accurately to develop an appropriate power budget, and to design the power supplies, voltage regulators, heat sink, and cooling system. The following figure shows the PowerPlay Power Analysis tools ability to estimate power consumption from early design concept through design implementation. Figure 8-1: PowerPlay Power Analysis From Design Concept Through Design Implementation PowerPlay Early Power Estimator Quartus II PowerPlay Power Analyzer Higher Placement and Simulation Routing Results Results Accuracy Quartus II Design Profile User Input Estimation Design Concept Design Implementation Lower PowerPlay Power Analysis Input For the majority of the designs, the PowerPlay Power Analyzer and the PowerPlay EPE spreadsheet have the following accuracy after the power models are final: • PowerPlay Power Analyzer—±20% from silicon, assuming that the PowerPlay Power Analyzer uses the Value Change Dump File (.vcd) generated toggle rates. • PowerPlay EPE spreadsheet— ±20% from the PowerPlay Power Analyzer results using .vcd generated toggle rates. 90% of EPE designs (using .vcd generated toggle rates exported from PPPA) are within ±30% silicon. The toggle rates are derived using the PowerPlay Power Analyzer with a .vcd file generated from a gate level simulation representative of the system operation. © 2013 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are trademarks of Altera Corporation and registered in the U.S.
  • VHDL Modelling Guidelines Simulation and Documentation Aspects

    VHDL Modelling Guidelines Simulation and Documentation Aspects

    Second draft, 23 February 1997 CENELEC TC217/WG2 report 2.14 English version VHDL Modelling Guidelines Simulation and Documentation Aspects This CENELEC Report is under preparation and review by the Technical Committee CENELEC TC 217 Working Group 2. CENELEC members are the national electrotechnical committees of Austria, Belgium, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and United Kingdom. CENELEC European Committee for Electrotechnical Standardisation Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung Central Secretariat: rue de Stassart 35, B-1050 Brussels CENELEC TC217/WG2 report 2.142 Second draft, 23 February 1997 3DJH LQWHQWLRQDOO\ OHIW EODQN Second draft, 23 February 19973 CENELEC TC217/WG2 report 2.14 )25(:25' 7KLV 7HFKQLFDO 5HSRUW LV WKH ILUVW GUDIW RI WKH &(1(/(& 7&:* UHSRUW 7KH UHSRUW LV GHULYHG IURP WKH (XURSHDQ 6SDFH $JHQF\ V (6$©V 9+'/ 0RGHOOLQJ *XLGHOLQHV UHIHUHQFH $6,& LVVXH GDWHG 6HSWHPEHU 7KLV GUDIW KDV EHHQ SUHSDUHG WDNLQJ LQWR DFFRXQW FRPPHQWV IURP &(1(/(& :* PHPEHUV SUHVHQWHG RQ WKH GHGLFDWHG HPDLO UHIOHFWRU 7KH DXWKRU ZRXOG OLNH WR WKDQN DOO FRQWULEXWRUV IRU WKHLU YDOXDEOH LQSXW 7KH (6$ 9+'/ 0RGHOOLQJ *XLGHOLQHV KDYH EHHQ XVHG LQ (6$ GHYHORSPHQW DQG VWXG\ FRQWUDFWV WR HQVXUH KLJKTXDOLW\ PDLQWDLQDEOH 9+'/ PRGHOV 7KH\ KDYH EHHQ SUHSDUHG E\ 3HWHU 6LQDQGHU ZLWK VXSSRUW IURP 6DQGL +DELQF ERWK DW WKH (6$(67(& 0LFURHOHFWURQLFV DQG 7HFKQRORJ\ 6HFWLRQ :60 32 %R[ $* 1RRUGZLMN
  • Waveform Editor

    Waveform Editor

    1. Quartus II Simulator QII53017-9.1.0 This chapter describes how to perform different types of simulations with the Quartus II simulator. Introduction With today’s FPGAs becoming faster and more complex, designers face challenges in validating their designs. Simulation verifies the correctness of the design, reducing board testing and debugging time. The Altera® Quartus® II simulator is included in the Quartus II software to assist designers with design verification. The Quartus II simulator has a comprehensive set of features that are covered in the following sections: ■ “Simulation Flow” on page 1–2 ■ “Waveform Editor” on page 1–5 ■ “Simulator Settings” on page 1–13 ■ “Simulation Report” on page 1–16 ■ “Debugging with the Quartus II Simulator” on page 1–19 ■ “Scripting Support” on page 1–21 The Quartus II simulator supports the following device families: ■ ACEX® 1K ■ APEX™ 20KC, APEX 20KE, APEX II ■ Arria® GX ■ Cyclone® III, Cyclone II, Cyclone ■ FLEX® 10K, FLEX 10KA, FLEX 10KE, FLEX 6000 ■ HardCopy® II, HardCopy ■ MAX® II, MAX 3000A, MAX 7000AE, MAX 7000B, MAX 7000S ■ Stratix® III, Stratix II, Stratix, Stratix GX, Stratix II GX 1 The Quartus II simulator does not support newer devices introduced after Stratix III and Quartus II software version 8.1 and onwards. Use the ModelSim-Altera Edition to run simulations on designs targeting device introductions after Stratix III. For more information about the ModelSim-Altera Edition simulator, refer to the Mentor Graphics ModelSim Support chapter in volume 3 of the Quartus II Handbook. In the Quartus II software version 10.0 and onwards, the Quartus II simulator and Waveform Editor is removed.
  • VHDL Verification of FPGA Based ESF-CCS for Nuclear Power Plant I&C

    VHDL Verification of FPGA Based ESF-CCS for Nuclear Power Plant I&C

    VHDL Verification of FPGA based ESF-CCS for Nuclear Power Plant I&C System Restu MAERANI1, and Jae Cheon JUNG2 1. Department of NPP Engineering, KINGS, Ulsan, 45014, Indonesia ([email protected]) 2. Department of NPP Engineering, KINGS, Ulsan, 45014, Republic of Korea ([email protected]) Abstract: Verification becomes the focus of activities during the integration phase of design life cycle in the development of the system. Verification methods that will not take much cost and time should be properly selected, accordance with the Measurement of Effectiveness (MOEs) need. Verification is one phase that must be done after completing the implementation process. Since Instrumentation & Control (I&C) system has a role as a very crucial to the control protection system in Nuclear Power Plant (NPP), then software verification is very essential and shall to be achieved for safety critical issue in system level. According to IEEE 1076-2008 standard, VHDL is a language that is easy to read by machines and humans; and make it easier for process development, verification, synthesis and testing for hardware reliability in the design. Because this design uses VHDL code for Field Programmable Gate Array (FPGA) based Engineered Safety features – Component Control System (ESF-CCS) and by referring to the NUREG/CR-7006 during VHDL verification on behavioral simulation process, it should be equivalent with the post layout simulation. Furthermore, Vivado will be used as the VHDL verifier, where the VHDL code itself is created, in order to simplify the process of verification with this design life cycle phase on re-engineering process.
  • A Classification and Comparison Framework for Software Architecture Description Languages

    A Classification and Comparison Framework for Software Architecture Description Languages

    A Classification and Comparison Framework for Software Architecture Description Languages Neno Medvidovic Technical Report UCI-ICS-97-02 Department of Information and Computer Science University of California, Irvine Irvine, California 92697-3425 [email protected] February 1996 Abstract Software architectures shift the focus of developers from lines-of-code to coarser- grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is also used to classify and compare several existing ADLs. One conclusion is that, although much research has been done in this area, no single ADL fulfills all of the identified needs. I. Introduction Software architecture research is directed at reducing costs of developing applications and increasing the potential for commonality between different members of a closely related product family [GS93, PW92]. Software development based on common architectural idioms has its focus shifted from lines-of-code to coarser-grained architectural elements (software components and connectors) and their overall interconnection structure.
  • Xilinx Development Systems: Product Descriptions, Data Book

    Xilinx Development Systems: Product Descriptions, Data Book

    1 Development Systems: Product Descriptions November 25, 1997 (Version 2.0) 12* Development Systems Descriptions It’s simple to order a Xilinx Development System. Just choose a Foundation or Alliance Series and a few options. Give your local Xilinx Sales Office a call for information about our evaluation kits. Foundation Series • Foundation Base System (PC) • Foundation Base-Express System (PC) • Foundation Standard System (PC) • Foundation Express System (PC) Alliance Series • Alliance Base (PC or Workstation) • Alliance Standard (PC or Workstation) Alliance Series Options • VIEWlogic Workview Office Standard Development System Options (PC) November 25, 1997 (Version 2.0) 2-3 Development Systems: Product Descriptions Foundation Series: Foundation Base System (PC) Overview Package Features - Foundation Base The Foundation Series provides a complete, ready-to-use System design system for the design of Xilinx programmable logic FND FND FND FND devices. The Foundation Base System provides design Feature BAS STD BSX EXP entry (schematic and Abel HDL), simulation, and device √√√√ implementation tools for a broad array of FPGA and CPLD CPLD Devices √1 √√1 √ devices targeted for low density and high volume applica- FPGA Devices tions. Libraries and Interface √√√√ Schematic Editor √√√√ System Features HDL Editor √√√√ • Project manager Graphical State Editor √√√√ • Schematic editor ABEL 6 Entry / Synthesis √√√√ • Integrated HDL editor with support for the Abel 6 HDL VHDL Entry / Synthesis √√ • Functional and timing simulator √√ • EDIF, VHDL (VITAL compliant), and Verilog / SDF Verilog Entry / Synthesis √√√√ design interfaces Schematic-centric Synthesis • Device implementation software for Xilinx CPLDs and HDL-centric Synthesis √ FPGAs Simulator √√√√ • Comprehensive on-line help, on-line documentation, Device Implementation √√√√ and software tutorials Maintenance2 √√√√ • Software maintenance, including hotline support and 11/12/97 software updates Notes: 1.
  • Documentation for JTAG Switcher

    Documentation for JTAG Switcher

    Documentation for JTAG Switcher 18 October 2019 License The MIT License Copyright (c) 2018-2019 Lauterbach GmbH, Ingo Rohloff Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUD- ING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. i Table of Contents 1 Introduction 2 1.1 IEEE 1149.1 aka JTAG . .2 1.2 JTAG overview . .3 1.3 JTAG chaining . .5 2 JTAG Switcher overview 6 2.1 Motivation . .6 2.2 Basic circuitry . .8 2.3 Design decisions . .9 2.3.1 JTAG Switcher should conform to IEEE 1149.1 . .9 2.3.2 Transparency . .9 2.3.3 First in JTAG chain . .9 2.3.4 JTAG slave TCK clock gating .
  • Hardware Description Languages Compared: Verilog and Systemc

    Hardware Description Languages Compared: Verilog and Systemc

    Hardware Description Languages Compared: Verilog and SystemC Gianfranco Bonanome Columbia University Department of Computer Science New York, NY Abstract This library encompasses all of the necessary components required to transform C++ into a As the complexity of modern digital systems hardware description language. Such additions increases, engineers are now more than ever include constructs for concurrency, time notion, integrating component modeling by means of communication, reactivity and hardware data hardware description languages (HDLs) in the types. design process. The recent addition of SystemC to As described by Edwards [1], VLSI an already competitive arena of HDLs dominated verification involves an initial simulation done in by Verilog and VHDL, calls for a direct C or C++, usually for proof of concept purposes, comparison to expose potential advantages and followed by translation into an HDL, simulation of flaws of this newcomer. This paper presents such the model, applying appropriate corrections, differences and similarities, specifically between hardware synthesization and further iterative Verilog and SystemC, in effort to better categorize refinement. SystemC is able to shorten this the scopes of the two languages. Results are based process by combining the first two steps. on simulation conducted in both languages, for a Consequently, this also decreases time to market model with equal specifications. for a manufacturer. Generally a comparison between two computer languages is based on the number of Introduction lines of code and execution time required to achieve a specific task, using the two languages. A Continuous advances in circuit fabrication number of additional parameters can be observed, technology have augmented chip density, such as features, existence or absence of constructs consequently increasing device complexity.
  • An Architectural Description Language for Secure Multi-Agent Systems

    An Architectural Description Language for Secure Multi-Agent Systems

    An Architectural Description Language for Secure Multi-Agent Systems Haralambos Mouratidis1,a, Manuel Kolpb, Paolo Giorginic, Stephane Faulknerd aInnovative Informatics Group, School of Computing, IT and Engineering, University of East London, England b Information Systems Research Unit, Catholic University of Louvain (UCL), Belgium c Department. of Information and Communication Technology, University of Trento, Italy d Information Management Research Unit, University of Namur, Belgium Abstract. Multi-Agent Systems (MAS) architectures are gaining popularity for building open, distributed, and evolving information systems. Unfortunately, despite considerable work in the fields of software architecture and MAS during the last decade, few research efforts have aimed at defining languages for designing and formalising secure agent architectures. This paper proposes a novel Architectural Description Language (ADL) for describing Belief-Desire-Intention (BDI) secure MAS. We specify each element of our ADL using the Z specification language and we employ two example case studies: one to assist us in the description of the proposed language and help readers of the article to better understand the fundamentals of the language; and one to demonstrate its applicability. Keyword: Architectural Description Language, Multi-Agent Systems, Security, BDI Agent Model, Software Architecture 1 Corresponding Author: [email protected] 1 1. Introduction However, as the expectations of business stakeholders are changing day after day; and The characteristics and expectations of as the complexity of systems, information new application areas for the enterprise, and communication technologies and such as e-business, knowledge management, organisations is continually increasing in peer-to-peer computing, and web services, today’s dynamic environments; developers are deeply modifying information systems are expected to produce architectures that engineering.
  • Should Your Specification Language Be Typed?

    Should Your Specification Language Be Typed?

    Should Your Specification Language Be Typed? LESLIE LAMPORT Compaq and LAWRENCE C. PAULSON University of Cambridge Most specification languages have a type system. Type systems are hard to get right, and getting them wrong can lead to inconsistencies. Set theory can serve as the basis for a specification lan- guage without types. This possibility, which has been widely overlooked, offers many advantages. Untyped set theory is simple and is more flexible than any simple typed formalism. Polymorphism, overloading, and subtyping can make a type system more powerful, but at the cost of increased complexity, and such refinements can never attain the flexibility of having no types at all. Typed formalisms have advantages too, stemming from the power of mechanical type checking. While types serve little purpose in hand proofs, they do help with mechanized proofs. In the absence of verification, type checking can catch errors in specifications. It may be possible to have the best of both worlds by adding typing annotations to an untyped specification language. We consider only specification languages, not programming languages. Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifica- tions; D.2.4 [Software Engineering]: Software/Program Verification—formal methods; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and Reasoning about Pro- grams—specification techniques General Terms: Verification Additional Key Words and Phrases: Set theory, specification, types Editors’ introduction. We have invited the following