opensource.google.com

Menu

Posts from February 2022

The 2022 Season of Docs application for organizations is open!

Wednesday, February 23, 2022

Organization applications for the 2022 Season of Docs are now open!

Through Season of Docs, Google awards grants to open source projects and organizations to hire technical writers to work on documentation projects. Participating organizations hire and pay the technical writers directly (we use Open Collective to help transfer grant funds). Organizations have up to six months to complete their documentation project. At the end of the program, organizations submit a case study outlining the results of their documentation projects, including the metrics they used to evaluate the success of their new or improved documentation. The case studies from the 2021 Season of Docs program are available online, and we will be releasing a summary report for the 2021 Season of Docs shortly—join our Season of Docs announcements list to be notified when it’s available! 

How does my organization apply to take part in Season of Docs?


Organization applications are now open! The deadline to apply is March 25, 2022 at 18:00 UTC.

To apply, first read the guidelines for creating an organization application on the Season of Docs website.

Take a look at the examples of project ideas, then create a project proposal based on your open source project’s actual documentation needs. Your goal is to attract technical writers to your organization, making them feel comfortable about approaching the organization and excited about what they can achieve.

We strongly recommend reading through the proposals and case studies submitted by organizations participating in the 2021 Season of Docs.

Organizations can submit their applications here: https://goo.gle/3dRyD7P. Organization applications close on March 25th at 18:00 UTC.

How do technical writers take part in Season of Docs?


Technical writers interested in working with accepted open source organizations can share their contact information via the Season of Docs GitHub repository; or they may submit proposals directly to the organizations using the contact information shared on the organization project page. Technical writers do not submit a formal application through Season of Docs.

Technical writers interested in participating in the 2022 Season of Docs should read our guide for technical writers on the Season of Docs website. Please note that technical writer recruiting began on February 3, 2022.

If you have any questions about the program, please email us at season-of-docs@google.com.

General timeline

February 23 - March 25

Open source organizations apply to take part in Season of Docs

April 14

Google publishes the list of accepted organizations, along with their project proposals and doc development can begin.

June 15

Organization administrators begin to submit monthly evaluations to report on the status of their project.

November 30

Organization administrators submit their case study and final project evaluation.

December 14

Google releases submitted case studies. 

May 2, 2023

Organizations begin to participate in post-program followup surveys.


See the timeline for details.

Join us

Explore the Season of Docs website at g.co/seasonofdocs to learn more about participating in the program. Use our logo and other promotional resources to spread the word. Check out the timeline and FAQ, and apply now!

By Kassandra Dhillon and Erin McKean, Google Open Source Programs Office

A New Library for Network Optimization

Tuesday, February 22, 2022

Networks are all around us from the electrical circuits inside our computers to the multitude of internet servers that route packets of data around the globe. Even the web itself is a network of pages connected to each other by a myriad of blue links.

ALT TEXT

A network's structure is referred to as its topology. Network topologies can be physical or logical, centralized or decentralized, and fully or partially connected. Given a network with n nodes, the number of possible topologies grows exponentially with n; even just a dozen nodes admit nearly a trillion trillion possible configurations!

ALT TEXT

We are pleased to announce the open source release of network-opt, a C++ library that supports the optimization of network topologies. Using sophisticated techniques for combinatorial search, this algorithm can efficiently construct instances from a family of so-called series-parallel networks that commonly arise in electrical and telecommunications applications. For example, given 15 1-Ω resistors and a target resistance of π Ω, our tool can produce a circuit that achieves six digits of precision:

ALT TEXT

For more details, refer to our paper: "Search Strategies for Topological Network Optimization," appearing this month at the Thirty-Sixth AAAI Conference on Artificial Intelligence (AAAI-22).

By Michael D. Moffitt, Core Enterprise Machine Learning

FPGA Interchange format to enable interoperable FPGA tooling

Thursday, February 10, 2022

Field Programmable Gate Arrays (FPGAs) have been around for decades and historically, the development of their specific toolchains happened in separate ecosystems that were driven by the vendors themselves. This has changed in recent years with the development of vendor-neutral open source toolchains, but this has revealed a new problem: the need for an abstraction layer to describe and define FPGA architectures through a standard format.

FPGA toolchains are not trivial, but roughly speaking, you can divide the process of “compiling” FPGA-targeted code in a Hardware Description Language (HDL) into three stages: synthesis, place and route, and bitstream generation. A standard format provides a common description of the architectures and serves as a bridge between the open source and closed proprietary tools responsible for various parts of the process.This includes the open source Yosys for synthesis, VtR and nextpnr for place and route, and vendor tooling from Xilinx, Intel, Lattice, QuickLogic, etc.

The introduction of a common format enables a shared methodology where specific building blocks are interchangeable. With that in mind, Google and Antmicro started the FPGA Interchange format project, providing a unified framework to lower the entry barriers for developers to swiftly move from one tool to another. In collaboration, Antmicro and other CHIPS Alliance members are developing the Interchange format definition and related tools aiming to become a development standard that the FPGA industry needs.

Components

The Interchange format provides three key descriptions to describe an FPGA and to interact with the various tools involved:
  • Device resources: defines the FPGA internal structure and the technological cell libraries describing FPGA logic blocks (basic blocks like flip-flops and complex like DSP cells).
  • Logical netlist: post-synthesized netlist compatible with the Interchange.
  • Physical netlist: collection of all placement locations and physical routing of the nets and resources produced by the place and route tool.
A challenge behind the creation of a standard format lies in the definition of the line between generalization and specificity of an FPGA architecture. By focusing on the only architecture type in mainstream use on the market today, namely island-based (also called tile-based) FPGAs, the standard reaches a level of universality and conciseness, which makes it easy to work with, adopt, and implement.

How it works

As previously mentioned, the FPGA Interchange format aims at lowering the barriers and building bridges between different place and route tools that can read and write using the same convention.

To achieve this, Antmicro and Google chose nextpnr as the first place and route tool to adopt the Interchange format. In the past few months, Antmicro extended nextpnr with FPGA Interchange format capabilities to place and route basic designs for the Xilinx 7-series and Lattice Nexus FPGA families.

To achieve initial support for Xilinx devices, the vendor’s own interesting RapidWright framework has also been introduced to the flow in collaboration with Xilinx’s research team. It is specifically used to write the device database in the Interchange format, consisting of all the device information.

Additionally, RapidWright can read and write the physical netlists to generate design checkpoint files that can be opened in Xilinx’s Vivado tool.

Example flow

The default open source flow for Xilinx devices uses Yosys to synthesize the design and VPR or nextpnr for place and route. The last step, bitstream generation, uses the open source FPGA Assembly FASM format to generate the file used for programming the FPGA. VPR supported this format natively, and nextpnr has been extended to support it as a part of the interchange format support work.


Now, by using the interchange format, you can create your flow from building blocks with the possibility to use a different tool (either open source or proprietary) for each step. A sample which illustrates this mix-and-match nature of interchange-capable tooling may look as depicted in the diagram above.

For processing any design, you need the FPGA device description files. These are generated in the following matter:
  • RapidWright generates the device description in the Interchange format.
  • The device description is translated by a dedicated script into the data-format suitable for nextpnr. The script will be eventually integrated into nextpnr enabling it to read the interchange format device description natively.
The device description has to be generated only once, and will normally be distributed with the toolchain installation package so that the user will not have to bother with this part. With the device architecture in place, a digital design can be processed with the toolchain.

This flow example shows how the Interchange creates a bridge between an open source flow with Yosys and nextpnr, and a closed source one using Vivado, demonstrating the possibility of interchanging tools thanks to a shared format.

To push forward the adoption of the format, the effort was recently onboarded into CHIPS Alliance, whose goal is to build an open source ASIC/FPGA ecosystem—including cores, I/O IPs, interconnect standards as well as digital and analog tooling—to radically transform the ASIC/FPGA design landscape.

Apart from allowing various existing tools to interoperate and share development efforts today, the Interchange format is a natural addition to the CHIPS Alliance in that it opens up smart ways to rapidly design and prototype new FPGA architectures, reduce the iteration times to implement, or add support to a place and route tool for a new architecture.

To further the collaboration around the Interchange Format, Xilinx has just joined the CHIPS Alliance to participate in the newly established FPGA workgroup of the Alliance which will include this and other FPGA-related projects that CHIPS Alliance is hosting.

Plans for the coming months

Besides nextpnr, there are other open source place and route tools slated to adopt the Interchange format as well, such as the Versatile Place and Route (VPR) from the Verilog-to-Routing project (VtR).

VtR can be used to place and route designs on FPGAs such as the Xilinx 7-series and QuickLogic’s eFPGA. This can only be done using the VPR data model and device description for now as it doesn’t support the Interchange format.

Antmicro is now implementing native support of the format within VPR, therefore enabling the use of place and route using different tools interchangeably; e.g. jumping from VPR placement output to nextpnr routing, allowing for faster improvements in algorithms.

Those benefits will extend to not only VPR and nextpnr, but to any other closed source tools, or new open source ones that adopt and implement the Interchange format.

Having a standard Interchange format at the tooling developers’ disposal lowers the barriers to developing new open source tools in this area. As example use cases, it enables new approaches to partial dynamic reconfiguration and the exploration of different place and route algorithms.

Customers will benefit from a wider range of flexible and customizable tools and ultimately get more control over their products. Antmicro provides end-to-end custom FPGA services, which involve reusable open source IP blocks, fast and reconfigurable SoCs, innovative tooling, and helping customers adopt the latest advances in software-driven FPGA development methodologies.


By Alessandro Comodi and Tom Michalak – Antmicro

Google Summer of Code 2022 is open for mentor organization applications!

Friday, February 4, 2022

We are excited to announce that open source projects and organizations can now apply to participate as mentoring organizations in the 2022 Google Summer of Code (GSoC) program. Applications for organizations will close Monday, February 21 at 10am PT.

As 2022 begins, so does our 18th edition of Google Summer of Code! With our new updates to the program, we look forward to welcoming not just students, but new and beginner open source contributors over 18 years old into our GSoC community. With increased flexibility in the length of the projects—now offering 175 and 350-hour projects—and the ability to extend the program from the standard 12 weeks to 22 weeks, we hope to spur the interest of more potential GSoC contributors.

Does your open source project want to learn more about becoming a mentor organization? Visit the program site and read the mentor guide to learn what it means to be a mentoring organization and how to prepare your community (hint: have plenty of excited mentors and well thought out project ideas!).

We welcome all types of organizations and are very eager to involve first-timers with a 2022 goal of welcoming 30+ new orgs into GSoC. We encourage new organizations to get a referral from experienced organizations that think they would be a good fit to participate in GSoC.

The open source projects that participate in GSoC as mentor organizations do all kinds of interesting work in security, cloud, development tools, science, medicine, data, and media for example. Projects can be relatively new (about 2 years old) to well established projects that started over 20 years ago. We welcome open source projects big and small and everything in between.

One thing to remember is that open source projects wishing to apply need to have a solid community. While you don’t have to have 50+ community members, the project also can’t have as few as 3 people; the goal of GSoC is to bring new contributors into communities and there should be an established community for them to join.

You can apply to be a mentor organization for GSoC starting today on the program site. The deadline to apply is February 21st at 10am PT. We will publicly announce the organizations chosen for GSoC 2022 on March 7th.

Please visit the program site for more information on how to apply and review the detailed timeline for important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects are excited to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

Announcing Season of Docs 2022

Thursday, February 3, 2022

Google Open Source is delighted to announce Season of Docs 2022!

The Season of Docs program supports better documentation in open source and provides opportunities for skilled technical writers to gain open source experience. 

Participating projects receive funds to create, improve, or expand their documentation, while contributing to our knowledge of effective metrics for evaluating open source documentation through their shared case studies.

About the program

Season of Docs allows open source organizations to apply for a grant based on their documentation needs. If selected, the open source organizations use their grant to hire a technical writer directly to complete their documentation project. Organizations have up to six months to complete their documentation project.


Participating organizations help broaden our understanding of effective documentation practices and metrics in open source by submitting a final case study upon completion of the program. The case study should outline the problem the documentation project was intended to solve, what metrics were used to judge the effectiveness of the documentation, and what the organization learned for the future. All project case studies will be published on the Season of Docs site at the end of the program.

Organizations: start your exploration engines

2022 Season of Docs applications open February 23, 2022. We strongly suggest that organizations take the time to complete the steps in the exploration phase before the application process begins, including:

  • Creating a project page to gauge community and technical writer interest in participating (see our project ideas page for examples)
  • Publicizing your interest in participating in Season of Docs through your project channels and adding your project to our list of interested projects on GitHub
  • Lining up community members who are interested in mentoring or helping to onboard technical writers to your project
  • Brainstorming requirements for technical writers to work on your project (Will they need to be able to test code? Work with video? Have prior experience with your project or related technologies?)

On your mark, get set, project page!

Every Season of Docs project begins with a project page. Your project page serves as an overview of your documentation project, and it should be publicly visible. A good project page includes:
  • A statement of the problem your project needs to solve (“users on Windows don’t have clear guidance of how to install our project”)
  • The documentation that might solve this problem (“We want to create a quickstart doc and installation guide for Windows users”)
  • How you’ll measure the success of your documentation (“With a good quickstart, we expect to see 50% fewer issues opened about Windows installation problems.”)
  • What skills your technical writer would need (break down into “must have” and “nice to have” categories. “Must have: access Windows machine to test instructions”)
  • What volunteer help is needed from community members (“need help onboarding technical writer to our discussion groups”) and links to where the community can discuss the proposal
  • Most importantly, include a way for interested technical writers to reach you and ask questions!

Technical writers: express your interest

Technical writers interested in working with accepted open source organizations can share their contact information via the Season of Docs GitHub repository; or they may submit proposals directly to the organizations using the contact information shared on the organization project page. Technical writers do not submit a formal application through Season of Docs.

General timeline

February 23 - March 25

Open source organizations apply to take part in Season of Docs.

April 14

Google publishes the list of accepted organizations, along with their project proposals and doc development can begin.

June 15

Organization administrators begin to submit monthly evaluations to report on the status of their project.

November 30

Organization administrators submit their case study and final project evaluation.

December 14

Google publishes the 2022 case studies and aggregate project data.

May 2, 2023

Organizations begin to participate in post-program followup surveys.    

See the full program timeline for more details.

Join us

Explore the Season of Docs website at g.co/seasonofdocs to learn more about participating in the program. Use our logo and other promotional resources to spread the word. Check out the timeline and FAQ, and get ready to apply!


By Kassandra Dhillon and Erin McKean, Google Open Source Programs Office

.