9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 Accelerating Circuit Realization via a Collaborative Gateway of Innovations Ian J. Taylor†∗ , Adam Brinckman† , Ewa Deelman‡ , Rafael Ferreira da Silva‡ Sandeep Gupta§ Jarek Nabrzyski† , Soowang Park§ , and Karan Vahi‡ † Center for Research Computing, University of Notre Dame, Notre Dame, IN, USA ∗ School of Computer Science & Informatics, Cardiff University, Cardiff, UK ‡ Information Sciences Institute, University of Southern California, Marina del Rey, CA, USA § Department of Electrical Engineering, University of Southern California, Los Angeles, CA, USA Emails: {itaylor1, abrinckm, naber}@nd.edu, {deelman, rafsilva, vahi}@isi.edu, {sandeep, soowangp}@usc.edu Abstract—The CRAFT repository seeks to develop new fast- Framework (OSF) [4]. We make use of the OSF’s REST API track circuit-design methods, multiple sources for integrated for the integration. We have further reused some of the Web circuit fabrication, and a technology repository. This paper graphical interfaces by virtual co-locating of an OSF server presents the design decisions and implementation to build a collaborative repository that capitalizes on the recent advances instance alongside our customized CRAFT Web application. in open-source collaborative frameworks, and answers the needs This approach involved some effort in the minor customization for the DARPA’s CRAFT program. The repository has been of the OSF instance e.g., LOGO, titles, etc., but also allowed us developed as an EmberJS application (front-end), which interacts to include several pieces of functionality without modification with an instance of the Open Science Framework (OSF). (e.g. file browser and visualizing, adding contributors, a WIKI, Keywords—Collaborative Environments; Design Flows; Chip Design and so on). The CRAFT application implementation was con- fined to CRAFT-specific additions to support the collaborative tools for chip design and the remaining parts of the OSF I. I NTRODUCTION seamlessly work together in an extremely interactive on-line The Circuit Realization at Faster Timescales (CRAFT) experience. This paper describes the architecture, design, and DARPA (Defense Advanced Research Projects Agency) pro- implementation of the CRAFT repository and it’s collaborative gram [1] aims at reducing the design cycle time needed for tools. Our CRAFT specific additions enhance the overall chip creating custom integrated circuits. Currently, the design of design process by facilitating re-use of circuit modules and a custom integrated circuit for a specific task can take more rapid adoption of new design flows across CRAFT project than two years, require a large team of engineers, and can participants. cost up to $100 million. Such timescales and economics are not practical and therefore DoD (Department of Defense) II. C RAFT R EQUIREMENTS engineers instead use readily available inexpensive general- To derive the key characteristics of the repository, we began purpose circuits and implement the specialized operations by analyzing the goals of the CRAFT program. First and using software. The resulting chips require more power, which foremost, CRAFT requires the development of radically new is not ideal for hand-held devices that are deployed in the chip design approaches that will dramatically reduce the time battlefield or for use in unmanned aerial vehicles. required for the first successful tape-out for ASIC designs. CRAFT’s program goal is to reduce the timescale for de- The community of researchers and industry experts working signing power-efficient high performance chips (or ASICS— to address this challenge will develop completely new tools, application-specific integrated circuits) for military applica- new types of libraries, and new design flows (a design flow is tions to months. In this paper, we use chips and ASICS a sequence of steps, each carried out by a tool; we describe interchangeably). In order to facilitate this goal, the CRAFT it in more detail later on). Second, the program requires repository also aims to provide innovative tools so that meth- CRAFT researchers to transfer immediately all their new tools, ods for fast design, documentation, and intellectual property libraries, and flows to a few selected DoD ASIC design teams, can be re-purposed, rather than re-invented, with each design and requires these teams to use such tools to design ASICs. and fabrication cycle. Third, the program requires rapid refinement and adoption of Our team has been working on designing and building the new tools, libraries of module designs, and design flows the CRAFT repository [2], with the aim of it being a col- by the wider community of DoD ASIC design teams. laborative gateway for circuit designers to be able to work The CRAFT repository therefore should expose many of on chip designs together and share their methods, tools, and these tools to help the CRAFT community organize infor- designs. For developing this repository, we have taken a hybrid mation and to allow the different teams to communicate approach by integrating a CRAFT-specific Web front-end, efficiently with each other. At the same time, the various written in EmberJS [3], with the preexisting Open Science teams need to have control over their content and the reposi- 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 tory’s flexible architecture to create different permissions for returns the client to the application, passing along a security different projects and topics enables this. The following five ticket. The application then validates the ticket by contacting sections discuss the underlying requirements and the high level CAS over a secure connection and providing its own service concepts we use to attain CRAFT goals. identifier and the ticket. CAS then gives the application trusted information about whether a particular user has successfully A. A Collaborative Space For Chip Designs authenticated. CAS allows multi-tier authentication via proxy The CRAFT project centers collaboration around a design address. A cooperating back-end service, like a database or flow. Therefore, the repository requires a way to encapsulate mail server, can participate in CAS, validating the authenticity the tools within some kind of collaborative space. To meet of users via information it receives from web applications. this requirement, we decided to organize the repository using the concept of a project, in a way very similar to other on- C. Project Permissions, Communication, and Privacy line tools, such as Bitbucket [5] and GitHub [6]. Each project should have a project overview page, which provides access Each project should have a project leader (project admin- to the ensemble of features of the project, as well as an istrator e.g., the PI could be a project administrator), who overview of the components, files, tags, history, comments, can manage that particular project and its sub-projects. The and other components (e.g., wikis, associated with the project). project administrator should be able to invite collaborators to Participants should also be able to participate in discussions their project and assign them certain privileges. Additional by leaving comments within a project, effectively creating a roles include: (1) read privileges, allow contributors to see project-wide chat. Further, notifications should be enabled for the contents of the project or component; and (2) read and any project, allowing users to be notified via email when a write, which allow the contributor to see the contents of the new comment is added to a project. A user can also choose project, upload and delete files, create, and edit new projects. to receive email notifications when someone replies to their Administrators encompass read and write privileges, as comment, similar to how they would do on Facebook. well as the ability to add or delete contributors, controlling Each project should be able to provide documentation (e.g., permissions, and controlling the overall settings of the project, a WIKI), describe itself (tags), and allow files to be uploaded or even deleting the project. and browsed. Sub-projects should be allowed and should be All projects should be private by default. However, a project distinct, encapsulated parts of a project and have their own administrator can choose to make a project publicly available. contributor lists and permissions. For example, the user should However, projects that are public can still contains sub-projects be able to create a data component that remains private even with their own privacy settings, i.e. making a project public when other parts of the project are made open to other does not make all of its sub-projects public. Users may want collaborators, and lists contributors that were vital for data to provide more limited access to external users for a variety collection but are not involved in other parts of the project. of circumstances. For example, editors or reviewers might get Thus, projects have a hierarchical collaborative space. read-only access to a private project during the review process. Each project therefore should provide a container to allow a user to organize files and content into meaningful groups like D. Version Control catalog of design flows, standard reference flows, proposed The repository should support version control as part of flows, datasets, code, circuit modules designed, or other re- its services. Project members can keep things up to date by search contributions. Each project should also have a unique, uploading new versions of documents to the repository and persistent URL, meaning that it can be referenced or linked have the repository keep track of older versions of those to individually. Every action/event should be automatically documents. documented with date-time stamps, and the log presented We also plan to support “releases”, which create a frozen, on the project dashboard. Additionally, a project should be time-stamped version of a project that cannot be edited or capable of being completely open or private. deleted. The release will have its own unique, persistent URL B. Authentication that is always linked back to the frozen project. The meta-data should be permanently stored with a registration. Users should authenticate via a secure central authentication service (CAS). The CAS protocol involves at least three E. Visualizing and Editing Design Flows parties: (1) a client web browser, (2) the web application requesting authentication, and (3) the CAS server. It may also The design flows should be captured using a machine involve a back-end service, such as a database server, that does processable format, which is capable of being visualized by not have its own HTTP interface but communicates with a web Web-based tools. From our initial requirements gathering, our application. When the client visits an application desiring to users have indicated that a graph view and a table view are authenticate to it, the application redirects it to CAS. CAS val- the two initial visualization tools we should provide for the idates the client’s authenticity, usually by checking a username design flows. For editing the flows, initially these will be input and password against a database (such as Kerberos, LDAP, manually but in the second phase of the project, we target the or Active Directory). If the authentication succeeds, CAS support of editable components via the table or graph viewers. 2 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 III. A RCHITECTURE AND D ESIGN science research and has a main focus on the reproducibility of research. However, more recently it has evolved into a more In order to produce a repository that met the requirements general framework for enabling core project-based functional- of the CRAFT community, architectural design decisions ity through an OSF REST API [9]. Research collaboration needed to carefully taken to optimize development and enable is built around the concept of a project (called a node or sustainability. We then were faced with different approaches component in OSF) and a user can invite other people to that would allow us to converge to an efficient system: collaborate on a project and assign them administrator, read, (1) architecting and implementing the system from scratch; or read/write permissions. It has a number of tools to facilitate (2) customizing an existing system to meet the needs; (3) creat- import and exporting data into the repository, and it also ing a new dashboard to an existing system using a REST API; interfaces with several popular cloud-based storage systems, or (4) creating a dashboard for CRAFT-specific features to an e.g., Dropbox [10], Google Drive [11], and Box [12]. The existing system using a REST API, and leveraging existing file system also supports versioning. This allows a user to tools using a hybrid architecture. create new versions of a file by re-uploading the latest copy Although option 1 is generally the simplest approach, as without changing the name. Each file has a set of revisions there are no other systems to learn and integrate with, and that are accessible. The OSF includes forking and registration creating an architecture with such clear requirements is a of projects that enables us to make immutable releases. It also straight forward engineering task, this approach has major includes preprints for publishing a paper (or documentation) disadvantages. First, the timescale we had to work within about a project. Within a project, there are multiple tools for was around 7 months, from the project requirements gathering visualizing files, for adding comments and it includes a full to a first production release of the repository, which would WIKI capability, for integrating documentation. OSF supports have been a challenging target using our allocated 1.5 full almost all of the underlying features that CRAFT needs, time developers. Second, many of these features already exist and the REST API supports all of the functionality through on other websites; e.g., Github and Bitbucket already have a JSON-API [13] compatible REST interface. The OSF is many of the project-oriented features implemented, amongst written in python, it uses the Django Rest Framework [14] to a number of others. Third, sustainability is not guaranteed, host the API, and provides an EmberJS [3] toolkit that allows and would require on-going additional effort to maintain the third party implementations to reuse the models of the OSF code (which would be a poor practice for reinventing the API from a Javascript application. wheel). Given the limited timescale, we aimed to assess In the context of the CRAFT project, OSF presented sev- several external well-established systems against our needs. eral advantages over HUBzero. The full access to the OSF The results of this study led to two candidate systems which functionality via REST API allows a complete and clear sep- were investigated in depth. aration of the development of CRAFT-related tools from the HUBzero [7] is an open source software platform for build- base system. It also has far more comprehensive support for ing websites that support scientific activities. The signature projects, includes collaborative tools, such as chat surrounding service of a hub is its ability to deliver interactive graphical all project entities; and also provides versioning of files and simulation tools; you can zoom in on a graph, rotate a even projects (through registration and forking). We therefore molecule, probe isosurfaces of a 3D volume—interactively, decided to capitalize on the recent advances of OSF to base without having to wait for a web page to refresh. Each hub the development of the CRAFT repository. is a place for users to come together and share information. Initially, we explored option 3 above by building the repos- The sharing mechanism enables users to create and manage itory entirely in EmberJS, and by recreating the tools we their own groups of users. Any registered user can create a needed into our GUI. However, after prototyping the initial group and invite others to join it. The creator can accept or dashboard we found several graphical features of the OSF reject group members, and can promote various members to Website itself compelling to reuse, rather than rewrite. Further, help manage the group. Resources associated with a group since DARPA had a requirement that all data to be hosted at a can be kept private, meaning that their access is limited to private server in Notre Dame, we were required to deploy our members of the group. You can also share files and each hub own instance of the OSF. This resulted in a hybrid architecture, supports the creation of “topic” pages, which are similar to which is shown in Figure 1. the Google “knol” model for knowledge articles. HUBzero is The architecture for the CRAFT repository therefore con- written in PHP and supports most of the CRAFT requirements. sists of two symbiotic servers: an EmberJS CRAFT ap- However, it only supports option 2 above, and the CRAFT plication [2], which contains the custom additions needed repository would have to be integrated into the HUBzero for the CRAFT project, and a marginally customized OSF code base. Although there are good interfaces to support this instance [15], which is a re-skinned OSF instance with minor development, there is no comprehensive Web API that can modifications. The modifications to the instance were archi- be used to separate the HUBzero instance from the Web tected to be captured in a script and just change three aspects dashboard. of the OSF repository: the LOGO, the OSF name is changed to The Open Science Framework (OSF) [4], [8] is an open CRAFT; and the menus are modified to include the EmberJS source software project that facilitates open collaboration in application links and to remove some of the OSF functionality 3 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 for CRAFT therefore is focused on the CRAFT-specific, data, metadata, and project-specific ontologies required by the CRAFT program. A. CRAFT Design Flow Specification As part of the DARPA CRAFT program, each CRAFT performer team is developing a user-oriented version of its new design flow. A major requirement for the CRAFT repository is the ability to capture, document, store, and visualize such flows in a systematic way, where the flow representation should be flexible and generic enough to accommodate the specificities of each flow. Therefore, we have developed a common template to capture and integrate design flows from all teams—which has been revised/expanded continually as needed. The goal is to capture the steps a DoD designer will have to take to use the flow. In the first step of the process of design of this representation, we conduct several requirements Fig. 1. Overview of the CRAFT repository architecture. gathering meetings (in-person, telecons, email exchanges, etc.) to create a high-level view of the design flow (no flow that are not required. This minor overlay allows us to easily specific information are required at this point, e.g., options and upgrade our OSF instance and take advantage of any new controls). In the second step, we extract expert knowledge to additional features and bug fixes that are included in future expand the high-level flow into a complete running example releases of the OSF framework. flow, which includes information about options, flow controls, The CRAFT architecture was conceptualized as tying the and data. The final step, is to publish the flow into the two servers together into a seamless repository: the application repository, where an interactive visualization tool allows other menus contain links to functionalities hosted on both servers; designers to explore detailed information about the flows. and the CRAFT EmberJS application would copy the look and IV. I MPLEMENTATION feel of the OSF repository, so that it appears as a single appli- The underlying project-based implementation is provided cation to the users. A major challenge of this integration was through the OSF REST API. Our Web dashboard is imple- to accommodate OSF’s bootstrap-based development, with mented using EmberJs and uses the Ember OSF toolkit [17] to Semantic UI [16] components used in CRAFT application. The model the REST API. Since we capitalize on OSF capabilities resulting user experience from such a design is summarized (provided by our OSF instance) for most of the GUIs and as follows: tooling (e.g., file management, etc.), the implementation of • User logs in via the CRAFT application; the CRAFT EmberJS application is focused on five areas of • The CRAFT application redirects to the Oauth CAS development: server to get a user token for authentication. This token 1) Authentication to the OSF CAS; is cached in the browser to satisfy both the CRAFT 2) The main dashboard page; application and the OSF instance; 3) The project overview Page; • The CRAFT application shows the user a customized 4) The Craft Design Flows tooling; and dashboard composed of a set/collection of CRAFT com- 5) The Discussion Forum. munication channels and flows; In addition to these specific functional elements, the Em- • When a user clicks on a project, s/he enters the CRAFT berJS application also implements the more general look-and- project main page; feel features (e.g., menus, CSS, etc) for the application. • The CRAFT application implements two custom pages: the overview page for describing the flow and the Craft A. Authentication page, which integrates the view and editing capabilities A customized login screen was created for the CRAFT for the design flow; application, as shown in Figure 2. This login screen allows • The two EmberJS pages are included on a project menu a user to login or the user can rotate the “shape” widget to along with the remaining links of the OSF instance. This register with the OSF. The registration method simply redirects creates a unified experience across both servers. the user to the OSF instance for registration with the server. Using this approach, CRAFT can take advantage of the When the user logs in, authentication in the application is various project-oriented features in the OSF instance to expose achieved using the Ember OSF plug in which runs the Oauth files, revisions and releases, tags, history, comments and other flow to the OSF CAS, which redirects the user to the redirect components (e.g., WIKIs) associated with the project. It can URL specified in this flow. The redirect URL is defined to be also use the OSF Oauth mechanism without modification to the dashboard page of the EmberJS application, which sends enable centralized authentication (CAS). All implementation the user to the CRAFT main dashboard. 4 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 Fig. 2. CRAFT login screen: authentication is performed via Oauth from OSF CAS. Fig. 4. CRAFT project overview screen. can also click to the right of the tags to add a new tag). On the lower part of this tab, a project overview description is provided. This segment employs the use of the Medium Editor [18], which is a simple intuitive HTML5-based editor. It provides a popup toolbar that allows text formating (bold, italic, headings, etc.), adding hyperlinks, and also dragging and dropping images from a desktop. Although, this is very Fig. 3. CRAFT main dashboard screen. simple, it provides an efficient mechanism to allow users to create a general project overview description. B. CRAFT Dashboard D. CRAFT Design Flows The main dashboard shows the list of private and public In the initial phase of the project, we defined the template to projects. A screen-shot of the private project part of this capture design flows as an Excel spreadsheet (facilitates visual dashboard is shown in Figure 3. Private projects are projects communication with the performer teams). However, in order that restrict access only to the members of those projects to enable flow validation (syntactically and semantically), and public projects provide view access to everyone. The and automated visualization/edition, subsequently flows are dashboard makes use of the Ember OSF pagination filtering described in a JSON format1 . This format is only used for mechanism to filter the projects to show a predefined number internal purposes, i.e., to store the flow into the repository. of projects per page. Projects navigation is done via the Performers only interact with the visualization graph tool pagination buttons, and/or using the search mechanism—the (Figure 5) or a tabular viewer (mimics the initial spreadsheet CRAFT repository capitalizes on the tag-based search features template, Figure 6) of the flow. provided by OSF. Using a a combination of these features the Flow visualizations are automatically generated from the user can locate desired projects quickly. Lastly, the dashboard JSON file. The graph visualization tool provides an interactive allows the user to create a project and uses a modal dialog interface to visualize the flow (based on the open source pop-up to allow the user to enter the details of the new project. Cytoscape.js project [19]). Users can click on the boxes (repre- C. Project Overview Page senting stages, input/output data) and edges (representing de- pendency and control flows) to visualize detailed information Figure 4 shows a screen-shot of a project overview page, about each tool and its control options. A tabular visualization which is composed of a project overview tab, and a list of (develop with the Handsontable library [20]) facilitates to activities tab (e.g., for auditing project usage). The project visualization/edition of detailed information at once. Versions overview is separated into two panels. The upper part of (history of changes) of the flow are automatically recorded in the overview’s tab shows (1) the project title, (2) a list of the repository. In the repository, each project manages a single contributors (members of the project), with links to their flow. We chose this approach to foster collaborative efforts, respective profiles, (3) a short description of the project, since all discussions and files within a project, are tied to a (4) a list of sub-projects (if this project has a sub-project) visible only to members of the sub-projects, and (5) a list 1 CRAFT Flow template schema: https://github.com/pegasus-isi/craft/tree/ of comprehensive tags that characterizes the project (the user master/schema 5 9th International Workshop on Science Gateways (IWSG 2017), 19-21 June 2017 topic, will be notified (via email) once any other contributor answers/replies a comment. Discussions follow the project visibility, i.e., the discussion forum will only be public if the project is also public. For instance, a general discussion forum (e.g., DARPA announcements), can be made through a separate public project created only for this purpose. The discussion feature is built on top of OSF’s chat feature, where we have re-defined the concept of simple messages into topic threads, and message replies into thread replies. V. C ONCLUSION This paper presented the CRAFT repository, a collabora- tive science gateway for accelerating circuit realization. The main goal of the repository is to capture and document, in a systematic way, the design flow process for chip design Fig. 5. CRAFT design flow represented in a graph format. development. The repository is built using a hybrid approach, where the front-end has been developed as an EmberJS appli- cation, which interacts with an instance of the Open Science Framework. The application was customized to fulfill CRAFT program requirements, in particular the development of tem- plates and schema to capture the design flows. Currently, the repository is only available to CRAFT performers but will be made available to wider DoD community soon. CRAFT per- formers include: Carnegie Mellon University, Harvard Univer- sity, Princeton University, Stanford University, University of California Berkeley, University of California, San Diego, and the University of Southern California. Industry collaborators and government organizations include the Boeing Company, Cadence Design Systems, Inc., DARPA, NVIDIA Corporation, Fig. 6. CRAFT design flow represented in a tabular format. Northrop Grumman Corporation, and Synopsys, Inc. Future work include the development of a service to capture and document intellectual property (IP) cores. Usability studies will follow. Acknowledgements. This work was funded by DARPA under contract #HR0011-16-C-0043 “Repository and Workflows for Accelerating Circuit Realization (RACE)”. R EFERENCES [1] “Circuit Realization at Faster Timescales (CRAFT),” http://www.darpa. mil/program/circuit-realization-at-faster-timescales. [2] “The Craft Repository,” https://craftproject.org/. [3] “EmberJS,” http://emberjs.com/. [4] “The Open Science Framework,” http://www.osf.io/. [5] “The Bitbucket Website,” http://bitbucket.org/. [6] “The Github Website,” http://github.com/. [7] M. McLennan and R. Kennell, “Hubzero: a platform for dissemination and collaboration in computational science and engineering,” Computing in Science & Engineering, vol. 12, no. 2, 2010. [8] J. R. Spies, The open science framework: improving science by making it open and accessible. University of Virginia, 2013. [9] “The Open Science Framework REST API,” https://api.osf.io/v2/. Fig. 7. CRAFT discussion forum. [10] “Dropbox,” https://www.dropbox.com. [11] “Google Drive,” https://www.google.com/drive/. single flow. Sub-projects can be used to represent multiple [12] “Box,” https://www.box.com/. [13] “JSON-API Specification,” http://jsonapi.org/. flows from a single performer. [14] “Django Rest Framework,” http://www.django-rest-framework.org/. [15] “Craft OSF Repository,” https://osf.craftproject.org/. E. Discussion Forum [16] “Semantic UI,” http://semantic-ui.com/. [17] “The Ember OSF Toolkit,” https://github.com/samchrisinger/ember-osf. The CRAFT repository provides a topic-based discussion [18] “HTML5 Medium Editor,” https://github.com/yabwe/medium-editor. forum (Figure 7), where any contributor can start or com- [19] “Cytoscape.js,” http://js.cytoscape.org/. ment a new topic. Contributors that have interacted with a [20] “Handsontable – javascript spreadsheet,” https://handsontable.com/. 6