El Correo Libre Issue 12

FOSSi Foundation Applies to Join Google Summer of Code 2019

The Free and Open Source Silicon Foundation has announced its application for a mentorship position in the Google Summer of Code (GSoC) programme, as part of its efforts towards expanding and improving the ecosystem.
 “In the Google Summer of Code, Google grants students a scholarship to contribute to open source projects over the summer,” explains Foundation director Stefan Wallentowitz. “The FOSSi Foundation applies as an umbrella organization and thereby enables participation for smaller to medium sized projects.

“We invite you to become part of GSoC and become a mentoring project.”

Those interested in being part of the programme can find more information on the Foundation website, and can apply via email or as a pull request to the GitHub repository.

Workshop on Open Source Design Automation (OSDA) Advanced Programme

The Workshop on Open Source Design Automation (OSDA), to be held in conjunction with the Design, Automation, and Test in Europe (DATE) Conference 2019 in March, has received an updated advanced programme — and the schedule includes a talk from the FOSSi Foundation’s Olof Kindgren on the FuseSoC project.
 Other confirmed presentations during the one-day workshop include Davide Rossi on the PULP Platform, demos from David Shah and Eddie Hung on nextpnr and from Baudouin Chauviere, Aurélien Alacchi, Edouard Giacomin, Xifan Tang, and Pierre-Emmanuel Gaillardon on OpenFPGA, a panel discussion on commercialisation and research on open-source EDA and intellectual property, and Ang Li and David Wentzlaff on the PRGA open-source framework.
 “Looks like a great programme overall,” says FOSSi Foundation director Olof Kindgren, “and I’m excited to meet some new people working on FOSSi projects.”
 The advance programme, which is now to be considered final, is available on the official website, while the event itself is to take place on the 29th of March 2019 in Florence, Italy.

Cocotb Testbench 1.1 Released

The Coroutine-based Cosimulation TestBench (coctb) tool has hit a milestone version 1.1 release, and from here on out FOSSi Foundation director and project maintainer Philipp Wagner promises that users can expect a more streamlined release schedule.
 “This release is the culmination of work done by 50 contributors over a little less than four years,” Philipp explains. “During that time we merged 242 pull requests, resulting in 257 files changed, with 25,426 insertions and 6,289 deletions recorded by git — growing the codebase by 19,137 lines! So what’s behind all these numbers? A lot of refactorings, bug fixes, and new features!

“You might ask: why did it take so long to get this release out? Cocotb has been maintained by Stu [Hodgson] and Chris [Higgs] since the beginning of (cocotb) time. Cocotb as we know it today exists because of their vision of how to produce a great hardware testing framework. They put a lot of time into developing high-quality code and maintaining cocotb — the popularity of cocotb today is the best indicator of how well that worked out. But as the popularity of cocotb grew, so did the maintenance effort.

“In order to be able to grow further, a team of dedicated volunteers agreed to share the maintainership role with Stu and Chris,” Philipp continues. “Based on a well-documented contribution process we were able to pick up speed again, merging a large number pull requests and giving feedback on many open issues. Today, cocotb development is flourishing with many hard issues being tackled, with documentation being improved, and new features being added. One of the issues being worked on is also a more streamlined release process, making it possible to release more frequently.”
 More detail on the changes found in the latest release is available in Philipp’s release announcement, while the software itself is available from GitHub now.

Western Digital Releases SweRV RISC-V Core Source

Storage specialist Western Digital has made good on its promise and released the RTL source code for its in-house SweRV RISC-V Core design, part of its programme to transition storage processing products away from proprietary cores and onto free and open source silicon alternatives.
 “Our SweRV Core and the new cache coherency fabric initiative demonstrate the significant possibilities that can be realised by bringing data closer to processing power,” said WD chief technology officer Martin Fink when the core and related technologies were unveiled late last year. “These planned contributions to the open-source community and continued commitment of the RISC-V initiative offer exciting potential to accelerate collaborative innovation and data-driven discoveries.”
 According to details shared by Cadence, following a presentation at the RISC-V Summit late last year, the SweRV Core is a two-way superscalar in-order design with a nine-stage pipeline hitting 1.8GHz on a 28nm process, boasting 4.9 CoreMarks per megahertz performance. “It will be completely open-sourced,” Martin told attendees. “You can download it in Q1. It is written in Verilator-clean SystemVerilog and has an unrestricted ‘knock yourself out’ licence.”
 Sure enough, the published source is available under the permissive Apache Licence 2.0, which includes provisions for commercial use with or without modifications, redistribution, and an express patent right grant clause.
 SweRV Core is available to download now from Western Digital’s GitHub repository.

Initial RISC-V OpenSBI Supervisor Binary Interface Released

An initial supervisor binary interface (SBI) implementation for RISC-V, dubbed OpenSBI, has been announced by the RISC-V Foundation — though is being maintained as an independent project.
 “OpenSBI is an open source implementation of the RISC-V Supervisor Binary Interface (SBI). SBI serves a critical purpose, enabling an operating system to interact with the supervisor execution environment (SEE),” the Foundation explains. “The RISC-V ISA has defined SBI to provide a cleaner interface for the supervisor OS, streamlining the process of virtualising and bringing up new hardware platforms. Furthermore, there’s no longer a need for the Berkeley bootloader (BBL), making it much easier to use upstream OS kernels and device data.
 “The RISC-V SBI specifications, maintained as an independent project by the RISC-V Foundation at GitHub, define the legacy SBI interface currently in use by various products as well as by RISC-V QEMU virtual machines. OpenSBI also implements SBI compliant early boot firmwares capable of handling various boot flows and payloads on various environments. OpenSBI firmwares have been tested with payloads such as U-Boot and Linux kernel, showing that these open firmwares can fully replace the legacy non-standard BBL intermediate boot loader.”
 The initial release, a conservative version 0.1, supports the SiFive HiFive Unleashed development board, various boards based on the Kendryte K210 system-on-chip (SoC), and the ‘virt’ and ‘sifive_u’ QEMU virtual machines.
 Full details are available on the RISC-V GitHub repository, where the OpenSBI implementation is made available under a two-clause BSD licence.

David Shah Seeks Testers for “Experimental Analytical Placer” in Nextpnr

Developer David Shah has implemented what he describes as an “experimental analytical placer implementation” in the nextpnr place and route tool, and is seeking volunteers to “try breaking” it.
 “This is a simple analytical placer based on HeAP and SimPL,” he writes. “It uses an iterative approach to minimise HPWL, mixed with recursive cut-based spreading followed by an additional strict legalisation pass to deal with bel validity requirements. In lieu of the iterative refinement described in the paper, after AP finishes regular SA is entered at constant low temperature and diameter (which implements a near-identical algorithm in practice).”
 The main aim of the new algorithm: “to be several times faster than the existing place,” David explains, “with similar QoR.” Early results are promising, too, with one tester finding it cut run time from nearly five hours to under twenty minutes for an example ‘blinky’ project.
 David’s call for testing can be found on Twitter, while the work-in-progress pull request can be found on GitHub.

Adam Greig Releases Nmigen MAC, IP Ethernet Stacks

Developer Adam Grieg has released nmigen gateware for a work-in-progress open Ethernet controller implementable on FPGAs, as part of his Daqnet distributed data acquisition project.
 “My FPGA Ethernet project now responds to ping,” Adam writes in an update on the project posted to Twitter. “The MAC and IP stack are all written in nmigen, the IP stack runs at 100MHz on an iCE40HX. So it takes it 1µs to turn around a ping packet. This uses about 1700 LUTs (of 8) and 12 BRAMs (of 32).”
 The latest source code for the project, published under an MIT licence, is available on Adam’s GitHub repository, though he warns that the project is very much a work in progress.

Michael Field Commits to DisplayPort Verilog Port Project for Open Toolchain Support

Michael Field has publicly pledged to begin a project to port his DisplayPort implementation, last updated three years ago, to Verilog in order that it can be built using a fully open toolchain — and to do so by Easter.
 “PUBLIC COMMITMENT TIME: I will convert my DisplayPort design to Verilog,” Michael writes on his personal Twitter account, “so it can be built with a fully Open Source FPGA tool chain, and improve the rough bits. ETA Easter.
 “If it is running on vendor tools by Easter, the there is a project that me and others can use be used to test transceiver support…”
 Michael’s existing code, published under the MIT licence, is available on his GitHub repository.

“Major” New OpenRAM Release Brings Multi-Port Support, Power Supply Improvements

OpenRAM, a Python framework which assists with the creation of layout, netlists, timing, power, placement, and routing models necessary to use static RAM (SRAM) in ASIC designs, has received a new release bringing improvements including multi-port support.
 “Major Release of OpenRAM,” developer Matt Guthaus announced via Twitter, “[with] multi-port support, power supply improvements, improved abstractions, and many bug fixes.”
 Details on the project, which depends on Ngspice, HSpice, or CustomSim, Python 3.5, and the numpy library and which is published under the BSD three-clause licence, can be found on the official website, while the latest release can be downloaded via GitHub.

Dan Gisselquist on Debugging the ZipCPU

While many column inches have been spent discussing the process of creating a new piece of open hardware, far fewer are devoted to the process of finding and solving bugs in their design — but Dan Gisselquist’s latest blog post helps to redress the balance.
 “Some time ago, Digilent replaced the flash chip within their Arty FPGA board,” Dan writes by way of introduction. “They also created a line of new FPGA boards, so my Arty board has now been rebranded as the Arty A7. I never realised there was a difference until someone wrote to tell me the design didn’t work anymore. With a little bit of digging, he and I discovered that the flash chip had changed. The new flash chip wasn’t just another chip from the same vendor, it was now from a different vendor entirely: from Micron to Spansion. This broke my old flash controller.
 “What about the differences between the two flash chips? I can use AutoFPGA to help me select between configurations of this universal flash controller. The only problem is that the OpenArty design wasn’t an AutoFPGA design to begin with.
 “The next problem is that the original OpenArty design requires an external serial port in addition to the one on the board. Further, when I was struggling to get the flash controller working, I had just had a bad experience with the ZipCPU on the iCE40s that had forced me to change my default linker script(s). After a quick upgrade to AutoFPGA, it now supports multiple custom linker scripts, but that now meant that the bootloader needed to change as well.
 “Other things had changed and needed to be updated as well. For example, the ZipCPU had now been formally verified. I found a lot of bugs in that process some time ago, and so I was excited to be updating the design with the new formally verified CPU. In the middle of this, I chose to switch to Vivado 2018.3 from Vivado 2016.3.
 “Is this starting to sound all too familiar?”
 In this background of yak-shaving, Dan begins his debugging efforts — and the full blog post is well worth reading to see the paths he took along the way, all based on having the incorrect believe that the flash controller was “the only big thing that had changed in this design” at the forefront of his mind.

FOSSi News In Brief

Have feedback or news for inclusion in a future newsletter? Please send this to ecl@librecores.org. Subscribe to get El Correo Libre direct to your inbox.