=Paper=
{{Paper
|id=Vol-2363/paper8
|storemode=property
|title=Accelerating Circuit Realization via a Collaborative Gateway of Innovations
|pdfUrl=https://ceur-ws.org/Vol-2363/paper8.pdf
|volume=Vol-2363
|dblpUrl=https://dblp.org/rec/conf/iwsg/TaylorBDSGNPV17
}}
==Accelerating Circuit Realization via a Collaborative Gateway of Innovations==
https://ceur-ws.org/Vol-2363/paper8.pdf
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