DOCSLIB.ORG

Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment by A

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment by A Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment by Andrey Ermolinskiy A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the GRADUATE DIVISION of the UNIVERSITY OF CALIFORNIA, BERKELEY Committee in charge: Professor Scott Shenker, Chair Professor Ion Stoica Professor Deirdre Mulligan Spring 2011 Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment Copyright c 2011 by Andrey Ermolinskiy Abstract Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment by Andrey Ermolinskiy Doctor of Philosophy in Computer Science University of California, Berkeley Professor Scott Shenker, Chair One of the central security concerns in managing an organization is protecting the flow of sensitive information, by which we mean either maintaining an audit trail or ensuring that sensitive documents are disseminated only to the authorized parties. A promising approach to securing sensitive data involves designing mechanisms that interpose at the software-hardware boundary and track the flow of information with high precision — at the level of bytes and machine instructions. Fine-grained information flow tracking (IFT) is conceptually simple: memory and registers containing sensitive data are tagged with taint labels and these labels are propagated in accordance with the computation. However, previous efforts have demonstrated that full-system IFT faces two major practi- cal limitations — enormous performance overhead and taint explosion. These challenges render existing IFT implementations impractical for deployment outside of a laboratory setting. This dissertation describes our progress in addressing these challenges. We present the design and implementation of PIFT (for Practical Information Flow Tracking) — a hypervisor-based IFT platform that achieves substantial performance improvements over previous systems and largely eliminates the problem of kernel taint explosion. PIFT takes advantage of spare CPU cores to track the flow of information asynchronously and in par- allel with the primary instruction stream. To the best of our knowledge, PIFT is the most efficient full-system IFT platform avail- able at the time of writing and is the only implementation that supports real-time tracking of information flow in graphical desktop environments. 1 Dedicated to my parents Ludmila and Alexandr, to my brother Pavel, and to my loving wife Olga. i Contents Contents ii List of Figures v List of Tables vii Acknowledgements viii 1 Introduction 1 1.1 DesignGoalsforaComprehensiveIFTPlatform . ..... 3 1.2 TheDesignPhilosophyofPIFT . 4 1.3 EvaluatingPIFT................................ 6 1.4 SummaryofContributions . 7 1.5 ThesisRoadmap................................ 8 2 Background and Related Work 9 2.1 InformationFlowControl. 10 2.1.1 StaticLanguage-LevelAnalysis . 10 2.1.2 DynamicEnforcementofInformationFlowRules . ... 11 2.2 DynamicTaintAnalysis. 14 2.2.1 ApplicationsofTaintTrackingTechniques . .... 14 2.2.2 Improving the Performance of Dynamic Taint Analysis . ...... 17 2.2.3 Hardware Extensionsfor Dynamic Taint Analysis . ..... 18 3 The PIFT Architecture and Information Flow Tracking Model 22 3.1 DataLabelsandthePolicyModel . 22 ii 3.2 TheModelofInformationFlowTracking . ... 23 3.3 SystemArchitecture. .. .. .. .. .. .. .. .. 26 3.3.1 PIFT-ext3:ALabel-AwareFilesystem. .. 29 3.3.2 Comparing PIFT to Existing Hypervisor-Based IFT Systems. .. 31 4 Prototype Implementation 33 4.1 TheHypervisor-LevelComponentofPIFT. .... 34 4.1.1 OverviewofXen ........................... 34 4.1.2 Transforming Xen into a Comprehensive IFT Platform . ..... 36 4.2 InformationFlowTrackingwithQEMU . .. 42 4.2.1 OverviewofQEMU ......................... 43 4.2.2 Extending QEMU with Taint Tracking: Approach Overview.... 47 4.2.3 ThePIFTInstructionSet . 52 4.2.4 TaintTrackingCodeGeneration . 59 4.2.5 TaintProcessorInternals . 60 4.2.6 AsynchronousParallelTaintTracking . ... 64 4.2.7 IntegrationwiththeOverallPIFT Architecture . ...... 66 4.3 ATaint-AwareStorageLayer. 68 4.3.1 ext3:DesignOverview. 69 4.3.2 OurExtensionstoext3 . 71 4.3.3 OurExtensionstotheNFSLayer . 74 4.3.4 Xen-RPC: An Efficient RPC Transport for Inter-VM Communication 75 4.3.5 EvaluationofPIFT-ext3 . 80 4.4 PolicyEnforcement.............................. 88 4.4.1 EnforcementforVirtualBlockDevices . .. 89 4.4.2 Enforcement for Virtual Network Interfaces . ..... 91 4.5 ExtendingPIFTtoaDistributedEnvironment . ...... 91 4.5.1 BandwidthOverheadEvaluation . 92 5 Full-System Performance Evaluation 95 5.1 Computationally-IntensiveWorkloads . ...... 96 5.1.1 CopyingandCompressing . 96 iii 5.1.2 TextSearch.............................. 98 5.2 BenefitsandLimitationsofAsynchrony . .... 99 5.3 Interactivity and User Productivity in Graphical Environments . .102 5.4 EvaluationSummary .............................107 6 Correctness of Taint Label Propagation 109 6.1 ExperimentalResults . .. .. .. .. .. .. .. .. 110 6.2 FundamentalLimitations . 113 6.3 EliminatingTaintExplosion . 116 6.3.1 Case Study: Eliminating Taint Explosion in the Linux Kernel . 118 7 Summary and Conclusions 123 7.1 DirectionsforFutureWork . 126 7.1.1 BridgingtheSemanticGap. .126 7.1.2 FurtherPerformanceImprovements . 127 7.1.3 OtherUsesofDynamicTaintAnalysis . 129 7.2 FinalRemarks.................................130 Bibliography 132 iv List of Figures 3.1 An example of instruction-level IFT: the compute_sum function.. 24 3.2 An example of instruction-level IFT: the table_lookup function. 25 3.3 An example of instruction-level IFT: the is_nonzero function. 26 3.4 Thehigh-levelarchitectureofPIFT. ..... 27 4.1 The format of a leaf page table entry on a 32-bit PAE-enabled x86machine. 38 4.2 Theformat ofthe shared_info_xen_qemu structure. 39 4.3 The contents of the hypervisor-level stack upon entry to restore_all_guest............................. 39 4.4 The implementation of the pift_emulate_guest function. 40 4.5 AnexampleofdynamiccodetranslationinQEMU. ..... 45 4.6 An example of code translation with static instruction handlerroutines.. 46 4.7 OurextensionstoQEMU’sdynamiccodetranslator. ....... 48 4.8 An illustrative example of dynamic code translation in PIFT. ........ 49 4.9 The general format of a PIFT taint tracking instruction. ........... 52 4.10 The PageTaintSummary lookupprocedure. 61 4.11 The implementation of the pre-generated handler for Set(Dst=eax, Src=MEM_BYTE) in the source code form (left) and in the final form com- piledforthex86platform(right).. .. 63 4.12 The implementation of the pre-generated handler for Merge(Dst=eax, Src=edx) in the source code form (left) and in the final form compiled for thex86platform(right). 63 4.13 Theon-disklayoutofanext2/ext3filesystem. ........ 69 4.14 The on-disk layout of taint label metadata in PIFT-ext3............ 73 4.15 New VFS callbacks in the inode_operations structure. 75 4.16 The implementation of the get_filerange_taint callback in PIFT-ext3. 76 v 4.17 TheformatofanXDRbufferstructure. .... 77 4.18 Performance of the BTD cache module at varying levels of concurrency. 81 4.19 Performance of the on-disk filesystem under data- and metadata-intensive workloads.................................... 83 4.20 Overall performance of the PIFT storage subsystem under data- and metadata-intensivefilesystemworkloads. .... 86 4.21 Function prototypes of policy enforcement handlers for paravirtualized diskandnetworkdevices.. 90 4.22 The effective network bandwidth, as measured by iperf, for varying amounts of tainted data (P ) and at varying levels of label fragmentation (F ). ...................................... 94 5.1 Performance of PIFT-A(512) and Neon on file copying and compression tasks with a varying amount of tainted data (F )................ 97 5.2 Performance on worst-case CPU-bound computational tasks in all config- urationsofinterest. .. .. .. .. .. .. .. ..101 5.3 Application launch time for Abiword and OOCalc in all configurations of interest. ....................................104 5.4 User-perceptible overhead in the text entry experiment. ...........105 5.5 Time taken to complete the spreadsheet editing task in all configurations of interest. ....................................106 6.1 A time series showing the level of computational activity within the pro- tected VM in Experiment 1. The highlighted overlay illustrates the number of basic blocks that touch at least one tainted operand. ........111 6.2 A schematic depiction of the data flow graph that emerged from our em- pirical study of kernel taint explosion. The shaded nodes depict the two kernel-level functions that are responsible for the initialtaintpoisoning. 119 6.3 The contents of the kernel-level stack upon system call entry in a paravir- tualized Linux guest environment with our taint scrubbing modifications. 120 vi List of Tables 4.1 The components of the guest_cpu_context structure (left) and the sources,fromwhichtheyareinitialized(right). ....... 41 4.2 The sequence of taint tracking actions required to handle the push %ebx instructionwithpreviousapproaches. ... 50 4.3 Tainttrackinginstructionoperands.. ....... 53 4.4 Tainttrackinginstructionopcodes. ...... 54 4.5 Operation throughput for sequential file writes (4KB request size, 100MB file size) across all five benchmark configurations. In C5, each data block carries a Uniform taintlabel. ......................... 86
Load more

Recommended publications
  • Comparison of Contemporary Real Time Operating Systems
    ISSN (Online) 2278-1021 IJARCCE ISSN (Print) 2319 5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 4, Issue 11, November 2015 Comparison of Contemporary Real Time Operating Systems Mr. Sagar Jape1, Mr. Mihir Kulkarni2, Prof.Dipti Pawade3 Student, Bachelors of Engineering, Department of Information Technology, K J Somaiya College of Engineering, Mumbai1,2 Assistant Professor, Department of Information Technology, K J Somaiya College of Engineering, Mumbai3 Abstract: With the advancement in embedded area, importance of real time operating system (RTOS) has been increased to greater extent. Now days for every embedded application low latency, efficient memory utilization and effective scheduling techniques are the basic requirements. Thus in this paper we have attempted to compare some of the real time operating systems. The systems (viz. VxWorks, QNX, Ecos, RTLinux, Windows CE and FreeRTOS) have been selected according to the highest user base criterion. We enlist the peculiar features of the systems with respect to the parameters like scheduling policies, licensing, memory management techniques, etc. and further, compare the selected systems over these parameters. Our effort to formulate the often confused, complex and contradictory pieces of information on contemporary RTOSs into simple, analytical organized structure will provide decisive insights to the reader on the selection process of an RTOS as per his requirements. Keywords:RTOS, VxWorks, QNX, eCOS, RTLinux,Windows CE, FreeRTOS I. INTRODUCTION An operating system (OS) is a set of software that handles designed known as Real Time Operating System (RTOS). computer hardware. Basically it acts as an interface The motive behind RTOS development is to process data between user program and computer hardware.
    [Show full text]
  • From Signal Temporal Logic to FPGA Monitors
    From Signal Temporal Logic to FPGA Monitors Stefan Jaksiˇ c´∗, Ezio Bartocci†, Radu Grosu†, Reinhard Kloibhofer∗, Thang Nguyen‡ and Dejan Nickoviˇ c´∗ ∗AIT Austrian Institute of Technology, Austria †Faculty of Informatics, Vienna University of Technology, Austria ‡Infineon Technologies AG, Austria Abstract— allows very long tests that are not possible with simulation- based methods. Design emulation is used both to explore Due to the heterogeneity and complexity of systems-of- systems (SoS), their simulation is becoming very time consuming, the behavior of digital and analog components. In the latter expensive and hence impractical. As a result, design simulation is case, the (possibly mixed signal) component is approximated increasingly being complemented with more efficient design em- with its discretized behavioral model. By combining these two ulation. Runtime monitoring of emulated designs would provide approaches, we provide a rigorous method for runtime verifi- a precious support in the verification activities of such complex cation of long executions resulting from mixed signal design systems. emulations. In addition to design emulations, our proposed We propose novel algorithms for translating signal temporal solution can be used to monitor real mixed-signal devices in logic (STL) assertions to hardware runtime monitors imple- post-silicon validation in real-time. mented in field programmable gate array (FPGA). In order to We choose Signal Temporal Logic (STL) [13] as our accommodate to this hardware specific setting, we restrict our- selves to past and bounded future temporal operators interpreted specification language. STL allows describing complex timing over discrete time. We evaluate our approach on two examples: relations between digital and analog “events”, where the latter the mixed signal bounded stabilization property; and the serial are specified via numerical predicates.
    [Show full text]
  • Software De Sistemas Introduccion
    SOFTWARE DE SISTEMAS INTRODUCCION • EL CONCEPTO DE SOFTWARE VA MAS ALLA DE LOS PROGRAMAS DE COMPUTACION EN SUS DISTINTOS ESTADOS QUE ABARCA TODO LO INTANGIBLE RELACIONADO Algodesl.wordpress.com t i ¿QUE ES? p o s d e s o f t w a r e . c o m • Parte esencial para clasificar sistemas operativos • Conocido como software base • Conjunto de programas de software que permite interactuar con el hardware y operarlo junto con configuraciones y funciones de entrada y salida ¿Que hace? • Permite utilizar sistema operativo e informático, incluyendo herramientas de diagnostico • Su propósito es aislar un programa o hardware de aplicaciones tanto como sea posible proyectoova.webcindario.com Ejemplos de programas de software de sistema a d • Potenciales ejemplos: r ia n ▪ cargadores a l is s e ▪ Enlazadores t .b lo ▪ Utilidad de software g s p o ▪ Interfaz grafica t ▪ Celdas ▪ Bios ▪ Hipervisores ▪ Gestores de arranque losejemplos.com *si el software del sistema se almacena en memoria volátil se denomina firware Tipos • Como tal no existen varios tipos de software de sistema pero se pueden dividir en 3; O k • Sistema operativo h o s • t Controladores i n g • . Programas de utilería c o m Tipos; SISTEMA OPERATIVO • Parte que se encarga de administración de hardware como los componentes de computadora y encargado de que todos se unan para funcionar en 1 solo objetivo m i n d 4 2 . c o m SISTEMAS OPERATIVOS • MICROSOFT WINDOWS ▪ Núcleo: monolítico (versiones basadas en MS­DOS) e hibrido (versiones basadas en Windows NT) ▪ Plataformas: ARM, arquitectura Intel, MIPS, Alpha, Power PC SISTEMAS OPERATIVOS • MAC OS ▪ Núcleo: XNU basado en mach y BSD, es tipo hibrido ▪ Plataformas; power PC SISTEMAS OPERATIVOS • LINUX: ▪ Núcleo: núcleo Linux ▪ Plataformas; DEC Alpha, ARM, POWER PC, superH, SPARC, ETRAX CRIS, MIPS, MN103… etc.
    [Show full text]
  • Improving Performance of Virtual Machines by Virtio Bridge Bypass
    www.ijecs.in International Journal Of Engineering And Computer Science ISSN:2319-7242 Volume 6 Issue 4 April 2017, Page No. 20931-20937 Index Copernicus value (2015): 58.10 DOI: 10.18535/ijecs/v6i4.24 Improving performance of Virtual Machines by Virtio bridge Bypass for PCI devices 1Shirley Kotian, 2Kirti Menon, 3Kirti Menon, 4Utsav Mundada, 5Neeraj Vilas Auti 1234PICT, 5PICT [CS] ABSTRACT Inspired by the Virtio module of virtualization, we propose an alternate method to directly communicate with PCI devices such as NIC without the use of any kernel modules. This method uses a specialized module written by us which will avoid the mechanism of bridges like the ones used in Virtio that increase latency. This module will be present in the userspace of the guest OS and we are specifically targeting the e1000 device for this purpose and later plan to make it generic for all PCI devices. Our motivation is to avoid unnecessary communication with the kernel which slows down the system. For the first step. we do resource mapping to map the PCI device memory into userspace. Then, we expose PCI configuration space through a userspace module using ACPI cables. Thus, we create a userspace PCI driver which will decrease the latency in access time and increase speed of execution. The applications in the Guest OS that request communication with the PCI devices will be redirected to our application. This will take some load off the kernel and reduce its overhead. Finally, we boot a VM that actually talks to our PCI device emulator. GENERAL TERMS Virtio, UPCI, e1000, QEMU, virt-manager, UIO.
    [Show full text]
  • An Implementation of Lola-2 Or Translating from Lola to Verilog
    An Implementation of Lola-2 or Translating from Lola to Verilog N.Wirth, 30.11.2014 1. Introduction The hardware description language Lola (Logic Language) was designed in 1990 as an effort to present a simple and effective textual description of digital circuits. At that time, the conventional style was still graphical (circuit charts), and it was not evident that textual descriptions would replace them entirely within 20 years. Also, there were no means available to automatically transfer them into physical circuits of electronic components. However, field-programmable gate arrays (FPGA) appeared, and although they were far too restrictive (small) for most practical purposes, they seemed to be a promising gateway towards introducing textual specifications with the hope of future automatic generation of real circuits. That this hope was well-founded is now evident. The difficult part of implementation in 1990 was not the compilation of the textual descriptions into net lists of gates and wires. It was rather the placement of components and routing of wires. And this still remains so. But even if this task is achieved, the compiled output is to be down-loaded into the FPGA. For this purpose, the format of the data, the bit-stream format, must be known. Whereas at the time we obtained this information from two FPGA manufacturers, it is now strictly proprietary in the case of the dominating manufacturers, a severe case of interface secrecy. In the course of reviving activities of 25 years ago around Oberon, also the hardware description language (HDL) Lola reappeared. Now textual descriptions of hardware are common place, the preferred languages being Verilog and VHDL.
    [Show full text]
  • Virtualization for Embedded Software
    JETS VIRTUALIZATION FOR EMBEDDED SOFTWARE Seasoned aerospace organizations have already weathered the VIRTUALIZATION WITH JETS: change from bespoke systems and proprietary languages to COTS A KEY ENABLER OF DEVOPS TRANSFORMATION and open-source, as well as paradigm shifts from high-overhead FOR AEROSPACE AND DEFENSE waterfall and spiral development models to lightweight and agile methodologies and are considering moving to scalable agile Like all companies in the technology industry, aerospace and defense methods. As with previous seismic shifts in the industry, most suppliers are facing increased pressure to reduce cost and increase defense and aerospace firms will have to follow, especially as best-of- productivity, while meeting their market’s demand for higher breed tools, talent and processes are all refactored to take advantage overall quality and rapid adoption of new platforms, development of DevOps’ unique productivity and quality improvements. DevOps paradigms and user experiences. is a collective term for a range of modern development practices that combines loosely-coupled architectures and process automation In recent years, the rapid pace of innovation for consumer tech, with changes to the structure of development, IT and product teams. together with a new generation of ‘digital native’ users that demand Adoption of DevOps (See Figure 1). more capability than previous generations, has left many in the industry playing constant catch-up. Adoption of DevOps includes a shift from long, structured release cycles to continuous delivery, and relies on heavy use of automation to improve productivity and quality. This can be complicated by The commercial software world is shifting again, several factors common to the defense and aerospace industry.
    [Show full text]
  • A Language for Parametrised and Reconfigurable Hardware Design
    Pebble: A Language For Parametrised and Reconfigurable Hardware Design Wayne Luk and Steve McKeever Department of Computing, Imperial College, 180 Queen’s Gate, London SW7 2BZ, UK Abstract. Pebble is a simple language designed to improve the pro- ductivity and effectiveness of hardware design. It improves productivity by adopting reusable word-level and bit-level descriptions which can be customised by different parameter values, such as design size and the number of pipeline stages. Such descriptions can be compiled without flattening into various VHDL dialects. Pebble improves design effectiven- ess by supporting optional constraint descriptions, such as placement attributes, at various levels of abstraction; it also supports run-time re- configurable design. We introduce Pebble and the associated tools, and illustrate their application to VHDL library development and reconfigu- rable designs for Field Programmable Gate Arrays (FPGAs). 1 Introduction Many hardware designers recognise that their productivity can be enhanced by reusable designs in the form of library elements, macros, modules or intellectual property cores. These components are developed carefully to ensure that they are efficient, validated and easy to use. Several development systems based on Java [1], Lola [2], C [3], ML [5], VHDL and Ruby [7] have been proposed. While the languages in these systems have their own goals and merits, none seems to meet all our requirements of: 1. having a simple syntax and semantics; 2. allowing a wide range of parameters in design descriptions; 3. providing support for both word-level design and bit-level design; 4. supporting optional constraint descriptions, such as placement attributes, at various levels of abstraction; 5.
    [Show full text]
  • Mexican Sentimiento and Gender Politics A
    UNIVERSITY OF CALIFORNIA Los Angeles Corporealities of Feeling: Mexican Sentimiento and Gender Politics A dissertation submitted in partial satisfaction of the requirements for the degree Doctor of Philosophy in Culture and Performance by Lorena Alvarado 2012 © Copyright by Lorena Alvarado 2012 ABSTRACT OF THE DISSERTATION Corporealities of Feeling: Mexican Sentimiento and Gender Politics by Lorena Alvarado Doctor of Philosophy in Culture and Performance University of California, Los Angeles, 2011 Professor Alicia Arrizón, co-chair Professor Susan Leigh Foster, co-chair This dissertation examines the cultural and political significance of sentimiento, the emotionally charged delivery of song in ranchera genre musical performance. Briefly stated, sentimiento entails a singer’s fervent portrayal of emotions, including heartache, yearning, and hope, a skillfully achieved depiction that incites extraordinary communication between artist and audience. Adopting a feminist perspective, my work is attentive to the elements of nationalism, gender and sexuality connected to the performance of sentimiento, especially considering the genre’s historic association with patriotism and hypermasculinity. I trace the logic that associates representations of feeling with nation-based pathology and feminine emotional excess and deposits this stigmatized surplus of affect onto the singing body, particularly that of the mexicana female singing body. In this context, sentimiento is represented in film, promotional material, and other mediating devices as a bodily inscription of personal and gendered tragedy, ii as the manifestation of exotic suffering, or as an ancestral and racial condition of melancholy. I examine the work of three ranchera performers that corroborate these claims: Lucha Reyes (1906-1944), Chavela Vargas (1919) and Lila Downs (1964).
    [Show full text]
  • LOLA: Runtime Monitoring of Synchronous Systems
    LOLA: Runtime Monitoring of Synchronous Systems Ben D’Angelo ∗ Sriram Sankaranarayanan ∗ Cesar´ Sanchez´ ∗ Will Robinson ∗ Bernd Finkbeiner y Henny B. Sipma ∗ Sandeep Mehrotra z Zohar Manna ∗ ∗ Computer Science Department, Stanford University, Stanford, CA 94305 fbdangelo,srirams,cesar,sipma,[email protected] y Department of Computer Science, Saarland University z Synopsys, Inc. [email protected] Abstract— We present a specification language and algo- the specification. Offline monitoring is critical for testing rithms for the online and offline monitoring of synchronous large systems before deployment. An online monitor systems including circuits and embedded systems. Such processes the system trace while it is being generated. monitoring is useful not only for testing, but also under Online monitoring is used to detect violations of the actual deployment. The specification language is simple specification when the system is in operation so that and expressive; it can describe both correctness/failure assertions along with interesting statistical measures that they can be handled before they translate into observable are useful for system profiling and coverage analysis. and cascading failures, and to adaptively optimize system The algorithm for online monitoring of queries in this performance. language follows a partial evaluation strategy: it incre- Runtime monitoring has received growing attention in mentally constructs output streams from input streams, recent years [1], [2], [3]. While static verification intends while maintaining a store of partially evaluated expressions to show that every (infinite) run of a system satisfies for forward references. We identify a class of specifica- the specification, runtime monitoring is concerned only tions, characterized syntactically, for which the algorithm’s with a single (finite) trace.
    [Show full text]
  • Review of FPD's Languages, Compilers, Interpreters and Tools
    ISSN 2394-7314 International Journal of Novel Research in Computer Science and Software Engineering Vol. 3, Issue 1, pp: (140-158), Month: January-April 2016, Available at: www.noveltyjournals.com Review of FPD'S Languages, Compilers, Interpreters and Tools 1Amr Rashed, 2Bedir Yousif, 3Ahmed Shaban Samra 1Higher studies Deanship, Taif university, Taif, Saudi Arabia 2Communication and Electronics Department, Faculty of engineering, Kafrelsheikh University, Egypt 3Communication and Electronics Department, Faculty of engineering, Mansoura University, Egypt Abstract: FPGAs have achieved quick acceptance, spread and growth over the past years because they can be applied to a variety of applications. Some of these applications includes: random logic, bioinformatics, video and image processing, device controllers, communication encoding, modulation, and filtering, limited size systems with RAM blocks, and many more. For example, for video and image processing application it is very difficult and time consuming to use traditional HDL languages, so it’s obligatory to search for other efficient, synthesis tools to implement your design. The question is what is the best comparable language or tool to implement desired application. Also this research is very helpful for language developers to know strength points, weakness points, ease of use and efficiency of each tool or language. This research faced many challenges one of them is that there is no complete reference of all FPGA languages and tools, also available references and guides are few and almost not good. Searching for a simple example to learn some of these tools or languages would be a time consuming. This paper represents a review study or guide of almost all PLD's languages, interpreters and tools that can be used for programming, simulating and synthesizing PLD's for analog, digital & mixed signals and systems supported with simple examples.
    [Show full text]
  • Generating Hardware from Openmp Programs Y.Y
    Generating Hardware From OpenMP Programs Y.Y. Leow, C.Y. Ng, and W.F. Wong Department of Computer Science National University of Singapore 3, Science Drive 2, Singapore 117543 [email protected] Abstract— Various high level hardware description languages already enjoyed significant support will be gaining further have been invented for the purpose of improving the productivity grounds. in the generation of customized hardware. Most of these We have created backends that generate languages are variants, usually parallel versions, of popular synthesizable VHDL [12] or Handel-C [13] code from software programming languages. In this paper, we describe our OpenMP C programs. We have successfully executed these on effort to generate hardware from OpenMP, a software parallel programming paradigm that is widely used and tested. We are a FPGA platform. We shall first give a very brief introduction able to generate FPGA hardware from OpenMP C programs via of OpenMP. This will be followed by the descriptions of our synthesizable VHDL and Handel-C. We believe that the addition Handel-C and VHDL backends. In the Section 5, we will of this medium-grain parallel programming paradigm will bring describe results from experimenting with our tool. This will be additional value to the repertoire of hardware description followed by a description of the related works and the languages. conclusion. I. INTRODUCTION II. OPENMP Along with Moore’s Law and the need to contain recurring OpenMP [10] is a specification jointly defined by a number engineering cost as well as a quick time to market, there has of major hardware and software vendors.
    [Show full text]
  • Low Latency Audio Visual Streaming System
    LOLA: Low Latency Audio Visual Streaming System LOLA Low Latency Audio Visual Streaming System Installation & User's Manual © 2005-2014 - Conservatorio di musica G. Tartini – Trieste, Italy Version 1.4.0 http://www.conts.it/artistica/lola-project [email protected] 1 LOLA: Low Latency Audio Visual Streaming System Index 1. Introduction......................................................................................................................................3 2. Hardware and Operating System requirements................................................................................4 2.1. Audio input/output hardware requirements.............................................................................................................................4 2.2. Video input hardware requirements.........................................................................................................................................4 2.3. Video output hardware requirements.......................................................................................................................................6 2.4. PC hardware requirements......................................................................................................................................................6 2.5. Network requirements.............................................................................................................................................................7 2.6. LOLA v1.4.x backward compatibility.....................................................................................................................................9
    [Show full text]