: Executable Extensions of the Bookshelf - PowerPoint PPT Presentation

About This Presentation
Title:

: Executable Extensions of the Bookshelf

Description:

Basic flows designed with HTML forms. Start with one step' and add more steps ... Security features and basic policies. Sandbox execution and data type checks ... – PowerPoint PPT presentation

Number of Views:40
Avg rating:3.0/5.0
Slides: 34
Provided by: IgorM7
Category:

less

Transcript and Presenter's Notes

Title: : Executable Extensions of the Bookshelf


1
Executable Extensions
of the Bookshelf
  • Igor Markov
  • University of Michigan, EECS

2
Outline
  • A three-slide version of the talk
  • motivations proposal how it will help
  • Basic use models
  • users and interfaces
  • restrictions
  • Existing VLSI CAD Bookshelf
  • Efforts related to our proposal
  • Details of the proposal
  • Sample flows, screenshots and conclusions

3
Motivation
  • Experiences from education
  • e.g., undergraduate courseson algorithms and
    architecture
  • infrastructure for evaluation auto-graders
  • Infrastructure for collaborative research
  • can also benefit from automation
  • must support sharing, modularity and reuse
  • must scale, must be industry-compatible
  • Modularity in implementation platforms

4
Bookshelf.exe
  • Dynamic version of the existing Bookshelf
  • Implementationsbenchmarks algo evaluations?
  • Flow composition and high-level scripting
  • Related efforts
  • SatEx, PUNCH, NEOS, OmniFlow
  • Proposed solution Bookshelf.exe (bX)
  • Application Service Provider
  • Interfaces
  • Online reporting of simulation results
  • Support for optimization-specific concepts
  • Power versus ease-of-use and modularity

5
Why We Need Bookshelf.exe?
  • Design flow prototyping
  • SW maintenance automation (cf. SourceForge)
  • HW/SW incompatibilities, lack of CPU cycles
  • Standardization, consolidation and sharing
  • Many published results cannot be reproduced
  • Simplified sharing and CAD IP re-use
  • Lack of high-level, large-scale experiments
  • Web-based scripting, distributed execution
  • Open-source flows (with or w/o o.-s. components)

6
(No Transcript)
7
Basic Use Models
  • Users (over the Web)
  • anonymous
  • registered (more features)
  • User interfaces
  • HTML forms (including downloads,
    uploads,high-level scripting and job control)
  • email notification
  • XML-RPC for contributed remote CPUs and data
  • NFS (where available) for file sharing

8
Restrictions
  • Uploaded files must match existing formats
  • Interface for adding new formats
  • Execution in a sandbox
  • Cannot make network connections
  • Visible file-system restricted by the chroot()
    call
  • Configurable resource limits (memory, etc)
  • Access permissions
  • Registered users can keep their results private
  • Benchmarks or solvers behind firewalls

9
The VLSI CAD Bookshelf
  • Contents fairly popular downloads
    contributions
  • benchmarks, implementations and comparisons
  • algorithm descriptions and analyses
  • evaluation methodologies (in English)
  • New slots, benchmarks, codes added regularly
  • ICCAD, DAC, ISPD publications use the bookshelf
  • IEEE Design and Test, May/June 2002
  • A static collection
  • Manual addition of material
  • No automatic evaluation, reporting of results

10
Other Efforts Related to .exe
  • SatEx http//www.lri.fr/simon/satex/satex.php3
  • Specialized in satisfiability problems
  • PUNCH http//punch.ece.purdue.edu
  • Very broad selection of software (from StarOffice
    to Capo)
  • Local to Purdue
  • NEOS http//www-neos.mcs.anl.gov/neos
  • Open-source, distributed architecture
  • Used primarily for linear and non-linear
    optimization
  • OmniFlow DAC 2001, Brglez and Lavana
  • http//www.cbl.ncsu.edu/OpenProjects/OmniFlow
  • Distributed Collaborative Design Framework for
    VLSI
  • GUI-based flow control, chaining of design tools

11
SatEx
  • Continual evaluation and ranking of codes
  • Results produced and posted automatically
  • Intuitive interface
  • Popular
  • 93,707 hits March, 2000 September 2001
  • 23 SAT provers, 32,610 runs September 2001
  • Limited scalability
  • One workstation (2yrs of CPU time)
  • Specialized to one application

12
  • Very general execution framework
  • From VLSI CAD to GUI-based office applications
  • Custom-designed file-system (Purdue hosts only)
  • 241,458 runs in 5 years (8,152 in VLSI CAD )
  • 20 publications
  • Only maintainer can add executables
  • No support for evaln and chaining (flows)
  • No stats for results of runs (cf. SatEx top 20)
  • No MIME-like data types
  • Difficult to use when multiple tools are involved

13
  • Open-source, distributed framework
  • Wide use, solid code base
  • Adding new implementations requires maintainer
    intervention (lt on PUNCH)
  • Each new code must come with a host
  • Distributed maintenance
  • Loose data typing
  • No type system for data and implementations
  • Compare to MIME

14
NEOS what can be improved
  • Independent eval. and verification of results
  • e.g., PUNCH offers a WL-eval. from the bookshelf
  • Real-time on-line reporting of results stats
  • High-level scripting and flow design
  • Scripts to control the execution and evaluation
    flows
  • Pairing solvers with benchmarks
  • SatEx-like evaluation, but for multiple data types

15
OmniFlow
  • Context collaborative VLSI Design
  • sharing computational resources, but not results
  • Distributed over multiple hosts
  • Provides GUI-based flow control
  • supports chaining of design tools
  • several hard-coded conditions for flow control
  • no support for execution conditional on results
  • no scripting language limited by GUI
  • Cannot dynamically add hosts

16
Bookshelf.exe (1)
  • Best of SatEx, PUNCH, NEOS and OmniFlow
  • Reporting style similar to SatEx ( alternatives)
  • The versatility of PUNCH
  • Scalability and distributed nature of NEOS (or
    better)
  • Flow control as in OmniFlow or better
  • New features
  • MIME-like data types and optimization-specific
    concepts
  • Automatic submission of binaries and source code
  • Chaining of implementations scripting for flow
    control
  • Support for use models with proprietary data or
    code

17
Bookshelf.exe (2)
  • Scalability
  • Computation is distributed (unlike in SatEx)
  • Maintenance is automated (unlike in NEOS)
  • Support for multiple use models
  • adapts to users
  • Multiple levels of expertise
  • Multiple levels of commitment
  • Sharing of public data
  • Hiding/protection of proprietary data
  • Screen-saver mode, cf. SETI_at_Home, Entropia, etc

18
Sample Scenario (IWLS 2002 Focus Group 3)
  • Question is it possible to massage the logic of
    the netlist to improve routing congestion?
  • Proposed research infrastructure
  • IWLS benchmark API (Andreas Kuehlman)
  • Interface to Bookshelf formats
  • Layout generation (available in the Bookshelf)
  • Placement (several placers available in the B.)
  • Congestion maps (next slide)

19
(No Transcript)
20
Interface Issues
  • Transparent error diagnostics
  • Greatly improve learning curve
  • Ownership, privacy, resource limitssample
    policy questions
  • Chaining jobs owned by different users
  • What jobs can be launched anonymously?
  • Script composer versus programming
  • Flexibility versus learning curve
  • GUI implemented using HTML forms(converts clicks
    and fill-in-the-blanks to scripts)

21
Script Composer
  • Built on top of a scripting language
  • Based on PERL (PERL functions available)
  • Basic flows designed with HTML forms
  • Start with one step and add more steps
  • API funcs e.g.,run optimizer 2 store
    results
  • Support for conditionals and iteration
  • Scripts sent to back-end for execution as jobs
  • Scripts can be saved, posted, reused

22
Language-Level Support
  • Type system for submissions, resultsand
    intermediate data
  • Algorithm implementations
  • Deterministic and randomized optimizers, etc.
  • Input data, results, status info (runtime,
    memory,)
  • Common benchmarks
  • Rules for matching submission types
  • E.g., match a placer with a LEF/DEF benchmark
  • Violations are reported to user as fatal errors

23
Data Models
  • Consistent data models needed for serious data
    flows and high-level experiments
  • e.g., integrated RTL-to-layout implementation
  • Plan to use OpenAccess 2.0
  • Specs published in April 2002
  • Implementation and source expected next year
  • Adjustments within bookshelf expectedin terms of
    open-source design flows
  • E.g., for industry SPR integration

24
bX Structure
  • bX front-end mostly Web-based ( email)
  • bX back-end
  • Main server (job scheduling, reporting of
    results, etc)
  • Client software on computational hosts
  • Network communications XML RPC
  • RPC standard
  • XML data encoding
  • HTTP network transport
  • Compatible with C/C, Perl, Python, etc.

25
Implementation Status
  • So far main focus on the back-end
  • Back-end ver 0.1 functional on Linux
  • BX state maintained in a database
  • Persistence, etc
  • Simple one-job demo (1 binary 1 benchmark)
  • Security features and basic policies
  • Sandbox execution and data type checks
  • Front-end supports one-job demo
  • Next mile-stone 10X10 demo (cf SAT 2002)
  • Jobs automatically distributed and results posted

26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
Conclusions
  • Bookshelf popular, but can be improved
  • Bookshelf.exe executable extensions
  • Goals
  • Automate routine operations
  • Create open-source flows
  • Facilitate high-level, large-scale
    experimentation
  • We plan to assimilate best features from related
    works add new ones
  • Started bottom-up implementation
  • Basic version of bX is working

32
  • If we missed anything important, let us know
  • Thank you

33
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com