DOCSLIB.ORG

System Verilog Introduction & Usage

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
System Verilog Introduction & Usage System Verilog Introduction & Usage IBM Verification Seminar Author: Johny Srouji, Intel Corporation IEEE P1800 Chair SystemVerilog Introduction (1) Presentation Objectives • Provide a brief history and status update of SystemVerilog as a HW Design & Verification Language • Provide a high level overview of the language capabilities and usage aspects This is not meant to be a tutorial of the language Parts of this presentation are based on material which was presented in DAC SystemVerilog workshop by technical committees chairs SystemVerilog Introduction (2) Agenda • Background – HW Design Languages – Problem Statement – IEEE P1800 Activity • SystemVerilog Design Modeling • SystemVerilog for Verification – Extensions for Test-Bench Modeling – Assertions • SystemVerilog DPI • A Quiz • Conclusions SystemVerilog Introduction (3) HW Design Languages • Hardware Description Language (HDL) is used to describe digital hardware elements • Various levels of design abstractions are used: – Behavioral: flow control, arithmetic operators, complex delays – Register Transfer Level (RTL): Structural description of the registers and the signal changes between registers – Gate level: combinatorial logic gates (and, or, not,…) – Switch level: layout description of the wires, resistors and transistors (CMOS,PMOS, etc) • Two main subsets: – Synthesizable – reflecting HW / Silicon – Non-Synthesizable – reflecting instrumentation code SystemVerilog Introduction (4) The Problem! e What’s Next? z • Quest for Performance is driving up i S complexity n – Deeper pipelines, increase in logic g i functionality and complexity, power issues, s e explosion in flops D Verilog RTL • Explosion in lines of RTL Code making verification a lot harder Schematics • Low Abstraction level of the RTL is driving 80’s 90’s higher verification effort and lower simulation speed – Trillions of cycles per lead project and s Increasing rate g more pre-silicon bug escapes u b n • Verification effort is reaching 60% of the o c i l i total design cycle s - e r – Usage of different languages makes it even P harder: reference models in C/C++, RTL in # Verilog or VHDL, Test Benches, Assertions, Checkers, Coverage Lead Projects SystemVerilog Introduction (5) Verilog History Verilog-1995 SystemVerilog 3.0 Gateway started to First IEEE Verilog Accellera develop Verilog Standard Extensions to V2K 1984 1990 1995 2001 2002 2003 Cadence bought Verilog-2001 (V2K) SystemVerilog 3.1 Gateway, and Enhancement – 2nd Extensions to 3.0 started pushing IEEE Verilog Verilog Standard SSyysstteemmVVeerriilloogg IIEEEEEE SSttaannddaarrdd iiss eexxppeecctteedd ttoo bbeeccoommee aavvaaiillaabbllee bbyy OOcctt’’22000055 SystemVerilog Introduction (6) SystemVerilog SV3.1 Focus: design SystemVerilog 3.1 - HDVL language cleanup Queues Test Bench Assertions APIs OO Classes Semaphores & Lists SV3.0 Focus: enhance design System Verilog 3.0 language capabilities Data Types Structures Advanced Control Interfaces Casting & Enums & Unions Operators Flow Verilog2K Multi-D Arrays Generate Automatic Tasks Verilog95 Gate Level Modeling & Timing Hardware Concurrency SystemVerilog Introduction (7) SystemVerilog Components Transaction-Level Advanced V Full Testbench g e verification capability Veriolog h A r Language with il c s il for semiformal and r n se o Teestbench r g Coverage V tb t formal methods. s io e IEEE n The Assertion T Language Standard Verilog I for Verilog V 2001 P D e A e ri & c e lo I a s P rf ig g e n D t Design In Abstraction: Interface Direct C interface, semantics, abstract Assertion API and data types, Coverage API abstract operators and expressions SystemVerilog Introduction (8) IEEE P1800 Structure Chair - Johny Srouji Vice chair – Shrenik Mehta IEEE P1800 Secretary - Dennis Brophy SystemVerilog WG Program Mgr: Noelle Humenick Errata Chair: Karen Pieper LRM – Chair: TBD Stu Sutherland P1800 Errata 1364 Verilog Sub-WG Champions Sub-WG SV- SV- SV- SV-CC & BTF Encryption Errata BC EC AC PTF (transfer/merge) SystemVerilog Introduction (9) SystemVerilog Design Modeling SystemVerilog enhances Verilog for Design Modeling • Data Types • Capturing Design Intent – SystemVerilog Data Types – always_* Procedural blocks – Packed & Unpacked Arrays – Unique and Priority Case • Data Organization – Nets and Variables – Structures & Unions • Powerful Syntax – Type Casting – Copy / Buffering – Enumerated Data Types – Port Connections • C-like functionality SystemVerilog Introduction (10) Basic SV3.1 Data Types reg r; // 4-value Verilog-2001 single-bit datatype integer i; // 4-value Verilog-2001 >= 32-bit datatype bit b; // single bit 0 or 1 logic w; // 4-value logic, x 0 1 or z as in Verilog byte b; // 2 value, 8 bit signed integer int i; // 2-value, 32-bit signed integer shortint s;// 2-value, 16-bit signed integer longint l; // 2-value, 64-bit signed integer Make your own types using typedef Use typedef to get C compatibility typedef shortint short; typedef longint longlong; typedef real double; typedef shortreal float; SystemVerilog Introduction (11) Packed And Unpacked Arrays unpacked a0 bit a [3:0]; a1 array of u n u s e d a2 bits a3 packed array of bit [3:0] p; p 3 p 2 p 1 p 0 bits bit [15:0] memory [1023:0]; 1k 16 bit memory[i] = ~memory[i+1]; unpacked memory[i] [15:8] = 0; memory Packed indexes can be sliced 1k 16 bit Can operate on packed bit [15:0] [1023:0] Frame; entire memory always @ (posedge inv) memory Frame = ~Frame; SystemVerilog Introduction (12) Data Organization • Signals are Meaningful In Groups – Instructions: Operation, Operands • Verilog Provides Only Informal Grouping reg [47:0] PktSrcAdr; reg [31:0] Instruction; reg [47:0] PktDstAdr; `define opcode 31:16 reg [7:0] InstOpCde; Instruction[`opcode] reg [7:0] InstOpRF [127:0]; By Name By Vector Location • Better to organize data in explicit, meaningful relationships between data elements • SystemVerilog Structs, Unions & Arrays alone or combined better capture design intent SystemVerilog Introduction (13) Data Organization - Structures struct { addr_t SrcAdr; • Structs Preserve addr_t DstAdr; Logical Grouping data_t Data; } Pkt; • Reference to Struct facilitates more Pkt.SrcAdr = SrcAdr; meaningful code if (Pkt.DstAdr == Node.Adr) LLikikee i nin C C b buut tw witihthoouut t ththee o opptitoionnaal ls strtruucctuturree tags before the { typedef struct { bit [7:0] opcode; tags before the { bit [23:0] addr; } instruction; // named structure type instruction IR; // define variable IR.opcode = 1; // set field in IR SystemVerilog Introduction (14) Data Organization - Packed Structures Consists of bit fields, which are packed together in memory without gaps – They are easily converted to and from bit vectors. struct packed { `define Valid 24 bit Valid; `define Tag 23:16 byte Tag; 15:0 bit [15:0] Addr; `define Addr } Entry; iTag = Entry[`Tag]; iTag = Entry.Tag; iAddr = Entry[`Addr]; iAddr = Entry.Addr; iValid = Entry[`Valid] iValid = Entry.Valid 32 0 unpacked 2 Valid packed struct may struct 1 Tag packed struct may 0 Addr ccoonntatainin o oththeerr p paacckkeedd structs or packed arrays 24 23 1615 0 structs or packed arrays Valid Tag Address packed struct SystemVerilog Introduction (15) Data Organization - Type Casting int'(2.0 * 3.0) A data type can be changed shortint' {8’hFA, 8’hCE} by using a cast (‘) operation 17 ' (x – 2) Any aggregate bit-level object can be reshaped OObbjejecctsts m muusst th haavvee Packed ⇔ Unpacked, Array ⇔ Structure idideenntitcicaal lb biti ts sizizee typedef struct { bit [7:0] f1; f1 A bit [7:0] f2; bit [7:0] f3[0:5]; f2 } Unpacked_s; { typedef struct packed f30 f31 f32 f33 f34 f35 bit [15:0][0:2] f1; bit [15:0] f2; } Packed_s; B Unpacked_s A; Packed_s B; f10 f11 f12 f2 … A = Unpacked_s’(B); B = Packed_s’(A); SystemVerilog Introduction (16) Data Organization - Unions typedef union { union typedef union { int n; byte [5:0] bytes; real f; provide storage for real rlevel; } u_type; either int or real integer ilevel; } Data_u_t; u_type u; struct { structs and unions can be assigned as a Data_u_t Data; whole logic isBytes; can contain fixed size packed or unpacked logic isReal; arrays logic isInteger; } DPkt; Unpacked Unions Enable Single Variable DPkt.Data = 3.124; to Contain Data from Multiple Types DPkt.IsReal = 1; Data Read from Unpacked Union Must Be if (DPkt.IsReal) from Last Field Written realvar = DPkt.rlevel; Requires Type Awareness SystemVerilog Introduction (17) Data Organization – Packed Unions • Packed Unions Enable • Packed Unions Enable Multiple Namespaces for Many Convenient Name Same-Sized, Integer Data References typedef logic [7:0] byte_t; inst.fields.opcode = 16’hDEAD; typedef struct packed { inst.bytes[1] = 8’hBE; logic [15:0] opcode; inst[7:0] = 8’hEF; logic [1:0] Mod; … inst == 32’hDEADBEEF; logic [2:0] Base; } Instruction_t; typedef union packed { byte_t [3:0] bytes; Instruction_t fields; • No Need To Test Type } Instruction_u; • Data Maps To All Instruction_u inst; Members SystemVerilog Introduction (18) Data Organization – Tagged Unions • Provide type-safety and brevity • Improve correctness • Improve ability to reason about programs for FV typedef tagged union { struct { bit [4:0] reg1, reg2, regd; } Add; tagIgInensdsttrur n iiinonsnsttr{r;; ...b..i.t [9:0] JmpU; ccasastsereu(c(itinns{sttrr)) mmaattcchheess ttabagiggtgeed[d1A:Ad0dd]d {c{rcr1,1,,rr22,,rrdd}}:: rrff[[rrdd]] == rrff[[rr11]] ++ rrff[[rr22]];; ttabagiggtgeed[d9J:Jm0mp]p jaj:d: d r; ccaassee ((jj)) mmaattcchheess } JmpC; ttaaggggeedd JJmmppUU aa :: ppcc == ppcc ++ aa;; } Jmp; ttaaggggeedd JJmmppCC {{cc,,aa}}:: } Instr; iiff ((rrff[[cc]]))
Load more

Recommended publications
  • Mod Perl 2.0 Source Code Explained 1 Mod Perl 2.0 Source Code Explained
    mod_perl 2.0 Source Code Explained 1 mod_perl 2.0 Source Code Explained 1 mod_perl 2.0 Source Code Explained 15 Feb 2014 1 1.1 Description 1.1 Description This document explains how to navigate the mod_perl source code, modify and rebuild the existing code and most important: how to add new functionality. 1.2 Project’s Filesystem Layout In its pristine state the project is comprised of the following directories and files residing at the root direc- tory of the project: Apache-Test/ - test kit for mod_perl and Apache2::* modules ModPerl-Registry/ - ModPerl::Registry sub-project build/ - utilities used during project build docs/ - documentation lib/ - Perl modules src/ - C code that builds libmodperl.so t/ - mod_perl tests todo/ - things to be done util/ - useful utilities for developers xs/ - source xs code and maps Changes - Changes file LICENSE - ASF LICENSE document Makefile.PL - generates all the needed Makefiles After building the project, the following root directories and files get generated: Makefile - Makefile WrapXS/ - autogenerated XS code blib/ - ready to install version of the package 1.3 Directory src 1.3.1 Directory src/modules/perl/ The directory src/modules/perl includes the C source files needed to build the libmodperl library. Notice that several files in this directory are autogenerated during the perl Makefile stage. When adding new source files to this directory you should add their names to the @c_src_names vari- able in lib/ModPerl/Code.pm, so they will be picked up by the autogenerated Makefile. 1.4 Directory xs/ Apache2/ - Apache specific XS code APR/ - APR specific XS code ModPerl/ - ModPerl specific XS code maps/ - tables/ - Makefile.PL - 2 15 Feb 2014 mod_perl 2.0 Source Code Explained 1.4.1 xs/Apache2, xs/APR and xs/ModPerl modperl_xs_sv_convert.h - modperl_xs_typedefs.h - modperl_xs_util.h - typemap - 1.4.1 xs/Apache2, xs/APR and xs/ModPerl The xs/Apache2, xs/APR and xs/ModPerl directories include .h files which have C and XS code in them.
    [Show full text]
  • 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,
    [Show full text]
  • Gotcha Again More Subtleties in the Verilog and Systemverilog Standards That Every Engineer Should Know
    Gotcha Again More Subtleties in the Verilog and SystemVerilog Standards That Every Engineer Should Know Stuart Sutherland Sutherland HDL, Inc. [email protected] Don Mills LCDM Engineering [email protected] Chris Spear Synopsys, Inc. [email protected] ABSTRACT The definition of gotcha is: “A misfeature of....a programming language...that tends to breed bugs or mistakes because it is both enticingly easy to invoke and completely unexpected and/or unreasonable in its outcome. A classic gotcha in C is the fact that ‘if (a=b) {code;}’ is syntactically valid and sometimes even correct. It puts the value of b into a and then executes code if a is non-zero. What the programmer probably meant was ‘if (a==b) {code;}’, which executes code if a and b are equal.” (http://www.hyperdictionary.com/computing/gotcha). This paper documents 38 gotchas when using the Verilog and SystemVerilog languages. Some of these gotchas are obvious, and some are very subtle. The goal of this paper is to reveal many of the mysteries of Verilog and SystemVerilog, and help engineers understand the important underlying rules of the Verilog and SystemVerilog languages. The paper is a continuation of a paper entitled “Standard Gotchas: Subtleties in the Verilog and SystemVerilog Standards That Every Engineer Should Know” that was presented at the Boston 2006 SNUG conference [1]. SNUG San Jose 2007 1 More Gotchas in Verilog and SystemVerilog Table of Contents 1.0 Introduction ............................................................................................................................3 2.0 Design modeling gotchas .......................................................................................................4 2.1 Overlapped decision statements ................................................................................... 4 2.2 Inappropriate use of unique case statements ...............................................................
    [Show full text]
  • A Full-System VM-HDL Co-Simulation Framework for Servers with Pcie
    A Full-System VM-HDL Co-Simulation Framework for Servers with PCIe-Connected FPGAs Shenghsun Cho, Mrunal Patel, Han Chen, Michael Ferdman, Peter Milder Stony Brook University ABSTRACT the most common connection choice, due to its wide availability in The need for high-performance and low-power acceleration tech- server systems. Today, the majority of FPGAs in data centers are nologies in servers is driving the adoption of PCIe-connected FPGAs communicating with the host system through PCIe [2, 12]. in datacenter environments. However, the co-development of the Unfortunately, developing applications for PCIe-connected application software, driver, and hardware HDL for server FPGA FPGAs is an extremely slow and painful process. It is challeng- platforms remains one of the fundamental challenges standing in ing to develop and debug the host software and the FPGA hardware the way of wide-scale adoption. The FPGA accelerator development designs at the same time. Moreover, the hardware designs running process is plagued by a lack of comprehensive full-system simu- on the FPGAs provide little to no visibility, and even small changes lation tools, unacceptably slow debug iteration times, and limited to the hardware require hours to go through FPGA synthesis and visibility into the software and hardware at the time of failure. place-and-route. The development process becomes even more diffi- In this work, we develop a framework that pairs a virtual ma- cult when operating system and device driver changes are required. chine and an HDL simulator to enable full-system co-simulation of Changes to any part of the system (the OS kernel, the loadable ker- a server system with a PCIe-connected FPGA.
    [Show full text]
  • 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".
    [Show full text]
  • Co-Emulation of Scan-Chain Based Designs Utilizing SCE-MI Infrastructure
    UNLV Theses, Dissertations, Professional Papers, and Capstones 5-1-2014 Co-Emulation of Scan-Chain Based Designs Utilizing SCE-MI Infrastructure Bill Jason Pidlaoan Tomas University of Nevada, Las Vegas Follow this and additional works at: https://digitalscholarship.unlv.edu/thesesdissertations Part of the Computer Engineering Commons, Computer Sciences Commons, and the Electrical and Computer Engineering Commons Repository Citation Tomas, Bill Jason Pidlaoan, "Co-Emulation of Scan-Chain Based Designs Utilizing SCE-MI Infrastructure" (2014). UNLV Theses, Dissertations, Professional Papers, and Capstones. 2152. http://dx.doi.org/10.34917/5836171 This Thesis is protected by copyright and/or related rights. It has been brought to you by Digital Scholarship@UNLV with permission from the rights-holder(s). You are free to use this Thesis in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses you need to obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/ or on the work itself. This Thesis has been accepted for inclusion in UNLV Theses, Dissertations, Professional Papers, and Capstones by an authorized administrator of Digital Scholarship@UNLV. For more information, please contact [email protected]. CO-EMULATION OF SCAN-CHAIN BASED DESIGNS UTILIZING SCE-MI INFRASTRUCTURE By: Bill Jason Pidlaoan Tomas Bachelor‟s Degree of Electrical Engineering Auburn University 2011 A thesis submitted
    [Show full text]
  • Lattice Synthesis Engine User Guide and Reference Manual
    Lattice Synthesis Engine for Diamond User Guide April, 2019 Copyright Copyright © 2019 Lattice Semiconductor Corporation. All rights reserved. This document may not, in whole or part, be reproduced, modified, distributed, or publicly displayed without prior written consent from Lattice Semiconductor Corporation (“Lattice”). Trademarks All Lattice trademarks are as listed at www.latticesemi.com/legal. Synopsys and Synplify Pro are trademarks of Synopsys, Inc. Aldec and Active-HDL are trademarks of Aldec, Inc. All other trademarks are the property of their respective owners. Disclaimers NO WARRANTIES: THE INFORMATION PROVIDED IN THIS DOCUMENT IS “AS IS” WITHOUT ANY EXPRESS OR IMPLIED WARRANTY OF ANY KIND INCLUDING WARRANTIES OF ACCURACY, COMPLETENESS, MERCHANTABILITY, NONINFRINGEMENT OF INTELLECTUAL PROPERTY, OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL LATTICE OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (WHETHER DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL, INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OF OR INABILITY TO USE THE INFORMATION PROVIDED IN THIS DOCUMENT, EVEN IF LATTICE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME JURISDICTIONS PROHIBIT THE EXCLUSION OR LIMITATION OF CERTAIN LIABILITY, SOME OF THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. Lattice may make changes to these materials, specifications, or information, or to the products described herein, at any time without notice. Lattice makes no commitment to update this documentation. Lattice reserves the right to discontinue any product or service without notice and assumes no obligation to correct any errors contained herein or to advise any user of this document of any correction if such be made.
    [Show full text]
  • Typedef in C
    CC -- TTYYPPEEDDEEFF http://www.tutorialspoint.com/cprogramming/c_typedef.htm Copyright © tutorialspoint.com The C programming language provides a keyword called typedef, which you can use to give a type a new name. Following is an example to define a term BYTE for one-byte numbers: typedef unsigned char BYTE; After this type definitions, the identifier BYTE can be used as an abbreviation for the type unsigned char, for example:. BYTE b1, b2; By convention, uppercase letters are used for these definitions to remind the user that the type name is really a symbolic abbreviation, but you can use lowercase, as follows: typedef unsigned char byte; You can use typedef to give a name to user defined data type as well. For example you can use typedef with structure to define a new data type and then use that data type to define structure variables directly as follows: #include <stdio.h> #include <string.h> typedef struct Books { char title[50]; char author[50]; char subject[100]; int book_id; } Book; int main( ) { Book book; strcpy( book.title, "C Programming"); strcpy( book.author, "Nuha Ali"); strcpy( book.subject, "C Programming Tutorial"); book.book_id = 6495407; printf( "Book title : %s\n", book.title); printf( "Book author : %s\n", book.author); printf( "Book subject : %s\n", book.subject); printf( "Book book_id : %d\n", book.book_id); return 0; } When the above code is compiled and executed, it produces the following result: Book title : C Programming Book author : Nuha Ali Book subject : C Programming Tutorial Book book_id : 6495407 typedef vs #define The #define is a C-directive which is also used to define the aliases for various data types similar to typedef but with following differences: The typedef is limited to giving symbolic names to types only where as #define can be used to define alias for values as well, like you can define 1 as ONE etc.
    [Show full text]
  • Cyclone: a Type-Safe Dialect of C∗
    Cyclone: A Type-Safe Dialect of C∗ Dan Grossman Michael Hicks Trevor Jim Greg Morrisett If any bug has achieved celebrity status, it is the • In C, an array of structs will be laid out contigu- buffer overflow. It made front-page news as early ously in memory, which is good for cache locality. as 1987, as the enabler of the Morris worm, the first In Java, the decision of how to lay out an array worm to spread through the Internet. In recent years, of objects is made by the compiler, and probably attacks exploiting buffer overflows have become more has indirections. frequent, and more virulent. This year, for exam- ple, the Witty worm was released to the wild less • C has data types that match hardware data than 48 hours after a buffer overflow vulnerability types and operations. Java abstracts from the was publicly announced; in 45 minutes, it infected hardware (“write once, run anywhere”). the entire world-wide population of 12,000 machines running the vulnerable programs. • C has manual memory management, whereas Notably, buffer overflows are a problem only for the Java has garbage collection. Garbage collec- C and C++ languages—Java and other “safe” lan- tion is safe and convenient, but places little con- guages have built-in protection against them. More- trol over performance in the hands of the pro- over, buffer overflows appear in C programs written grammer, and indeed encourages an allocation- by expert programmers who are security concious— intensive style. programs such as OpenSSH, Kerberos, and the com- In short, C programmers can see the costs of their mercial intrusion detection programs that were the programs simply by looking at them, and they can target of Witty.
    [Show full text]
  • REFPERSYS High-Level Goals and Design Ideas*
    REFPERSYS high-level goals and design ideas* Basile STARYNKEVITCH† Abhishek CHAKRAVARTI‡ Nimesh NEEMA§ refpersys.org October 2019 - May 2021 Abstract REFPERSYS is a REFlexive and orthogonally PERsistent SYStem (as a GPLv3+ licensed free software1) running on Linux; it is a hobby2 but serious research project for many years, mostly aimed to experiment open science ideas close to Artificial General Intelligence3 dreams, and we don’t expect use- ful or interesting results before several years of hard work. audience : LINUX free software developers4 and computer scientists interested in an experimental open science approach to reflexive systems, orthogonal persistence, symbolic artificial intelligence, knowledge engines, etc.... Nota Bene: this report contains many hyperlinks to relevant sources so its PDF should rather be read on a computer screen, e.g. with evince. Since it describes a circular design (with many cycles [Hofstadter:1979:GEB]), we recommend to read it twice (skipping footnotes and references on the first read). This entire document is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. *This document has git commit fb17387fbbb7e200, was Lua-LATEX generated on 2021-May-17 18:55 MEST, see gitlab.com/bstarynk/refpersys/ and its doc/design-ideas subdirectory. Its draft is downloadable, as a PDF file, from starynkevitch.net/Basile/refpersys-design.pdf ... †See starynkevitch.net/Basile/ and contact [email protected], 92340 Bourg La Reine (near Paris), France. ‡[email protected], FL 3C, 62B PGH Shah Road, Kolkata 700032, India.
    [Show full text]
  • Spindle Documentation Release 2.0.0
    spindle Documentation Release 2.0.0 Jorge Ortiz, Jason Liszka June 08, 2016 Contents 1 Thrift 3 1.1 Data model................................................3 1.2 Interface definition language (IDL)...................................4 1.3 Serialization formats...........................................4 2 Records 5 2.1 Creating a record.............................................5 2.2 Reading/writing records.........................................6 2.3 Record interface methods........................................6 2.4 Other methods..............................................7 2.5 Mutable trait...............................................7 2.6 Raw class.................................................7 2.7 Priming..................................................7 2.8 Proxies..................................................8 2.9 Reflection.................................................8 2.10 Field descriptors.............................................8 3 Custom types 9 3.1 Enhanced types..............................................9 3.2 Bitfields..................................................9 3.3 Type-safe IDs............................................... 10 4 Enums 13 4.1 Enum value methods........................................... 13 4.2 Companion object methods....................................... 13 4.3 Matching and unknown values...................................... 14 4.4 Serializing to string............................................ 14 4.5 Examples................................................. 14 5 Working
    [Show full text]
  • Union Types for Semistructured Data
    Edinburgh Research Explorer Union Types for Semistructured Data Citation for published version: Buneman, P & Pierce, B 1999, Union Types for Semistructured Data. in Union Types for Semistructured Data: 7th International Workshop on Database Programming Languages, DBPL’99 Kinloch Rannoch, UK, September 1–3,1999 Revised Papers. Lecture Notes in Computer Science, vol. 1949, Springer-Verlag GmbH, pp. 184-207. https://doi.org/10.1007/3-540-44543-9_12 Digital Object Identifier (DOI): 10.1007/3-540-44543-9_12 Link: Link to publication record in Edinburgh Research Explorer Document Version: Peer reviewed version Published In: Union Types for Semistructured Data General rights Copyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s) and / or other copyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associated with these rights. Take down policy The University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorer content complies with UK legislation. If you believe that the public display of this file breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim. Download date: 27. Sep. 2021 Union Typ es for Semistructured Data Peter Buneman Benjamin Pierce University of Pennsylvania Dept of Computer Information Science South rd Street Philadelphia PA USA fpeterbcpiercegcisupenn edu Technical
    [Show full text]